Persistence Behavior

By enabling persistence, any data that theFirebase Realtime Database client would sync while online persists to disk and is available offline, even when the user or operating system restarts the app. This means your app works as it would online by using the local data stored in the cache. Listener callbacks will continue to fire for local updates.

TheFirebase Realtime Database client automatically keeps a queue of all write operations that are performed while your app is offline. When persistence is enabled, this queue is also persisted to disk so all of your writes are available when the user or operating system restarts the app. When the app regains connectivity, all of the operations are sent to theFirebase Realtime Database server.

If your app usesFirebase Authentication, theFirebase Realtime Database client persists the user's authentication token across app restarts. If the auth token expires while your app is offline, the client pauses write operations until your app re-authenticates the user, otherwise the write operations might fail due to security rules.

Keeping Data Fresh

TheFirebase Realtime Database synchronizes and stores a local copy of the data for active listeners. In addition, you can keep specific locations in sync.

let scoresRef = Database.database().reference(withPath: "scores")scoresRef.keepSynced(true)

FIRDatabaseReference*scoresRef=[[FIRDatabasedatabase]referenceWithPath:@"scores"];[scoresRefkeepSynced:YES];

TheFirebase Realtime Database client automatically downloads the data at these locations and keeps it in sync even if the reference has no active listeners. You can turn synchronization back off with the following line of code.

scoresRef.keepSynced(false)

[scoresRefkeepSynced:NO];

By default, 10MB of previously synced data is cached. This should be enough for most applications. If the cache outgrows its configured size, theFirebase Realtime Database purges data that has been used least recently. Data that is kept in sync is not purged from the cache.

Querying Data Offline

TheFirebase Realtime Database stores data returned from a query for use when offline. For queries constructed while offline, theFirebase Realtime Database continues to work for previously loaded data. If the requested data hasn't loaded, theFirebase Realtime Database loads data from the local cache. When network connectivity is available again, the data loads and will reflect the query.

For example, this code queries for the last four items in aFirebase Realtime Database of scores

letscoresRef=Database.database().reference(withPath:"scores")scoresRef.queryOrderedByValue().queryLimited(toLast:4).observe(.childAdded){snapshotinprint("The \(snapshot.key) dinosaur's score is \(snapshot.value ?? "null")")}

FIRDatabaseReference*scoresRef=[[FIRDatabasedatabase]referenceWithPath:@"scores"];[[[scoresRefqueryOrderedByValue]queryLimitedToLast:4]observeEventType:FIRDataEventTypeChildAddedwithBlock:^(FIRDataSnapshot*snapshot){NSLog(@"The %@ dinosaur's score is %@",snapshot.key,snapshot.value);}];

Assume that the user loses connection, goes offline, and restarts the app. While still offline, the app queries for the last two items from the same location. This query will successfully return the last two items because the app had loaded all four items in the query above.

scoresRef.queryOrderedByValue().queryLimited(toLast:2).observe(.childAdded){snapshotinprint("The \(snapshot.key) dinosaur's score is \(snapshot.value ?? "null")")}

[[[scoresRef queryOrderedByValue] queryLimitedToLast:2]observeEventType:FIRDataEventTypeChildAdded withBlock:^(FIRDataSnapshot *snapshot) {NSLog(@"The %@ dinosaur's score is %@", snapshot.key, snapshot.value);}];

In the preceding example, theFirebase Realtime Database client raises 'child added' events for the highest scoring two dinosaurs, by using the persisted cache. But it will not raise a 'value' event, since the app has never executed that query while online.

If the app were to request the last six items while offline, it would get 'child added' events for the four cached items straight away. When the device comes back online, theFirebase Realtime Database client synchronizes with the server and gets the final two 'child added' and the 'value' events for the app.

Handling Transactions Offline

Any transactions that are performed while the app is offline, are queued. Once the app regains network connectivity, the transactions are sent to theRealtime Database server.

How onDisconnect Works

When you establish anonDisconnect() operation, the operation lives on theFirebase Realtime Database server. The server checks security to make sure the user can perform the write event requested, and informs your app if it is invalid. The server then monitors the connection. If at any point the connection times out, or is actively closed by theRealtime Database client, the server checks security a second time (to make sure the operation is still valid) and then invokes the event.

Your app can use the callback on the write operation to ensure theonDisconnect was correctly attached:

presenceRef.onDisconnectRemoveValue { error, reference in  if let error = error {    print("Could not establish onDisconnect event: \(error)")  }}

[presenceRefonDisconnectRemoveValueWithCompletionBlock:^(NSError*error,FIRDatabaseReference*reference){if(error!=nil){NSLog(@"Could not establish onDisconnect event: %@",error);}}];

AnonDisconnect event can also be canceled by calling.cancel():

presenceRef.onDisconnectSetValue("I disconnected")// some time later when we change our mindspresenceRef.cancelDisconnectOperations()

[presenceRefonDisconnectSetValue:@"I disconnected"];// some time later when we change our minds[presenceRefcancelDisconnectOperations];

Server Timestamps

TheFirebase Realtime Database servers provide a mechanism to insert timestamps generated on the server as data. This feature, combined withonDisconnect, provides an easy way to reliably make note of the time at which aRealtime Database client disconnected:

let userLastOnlineRef = Database.database().reference(withPath: "users/morgan/lastOnline")userLastOnlineRef.onDisconnectSetValue(ServerValue.timestamp())

FIRDatabaseReference*userLastOnlineRef=[[FIRDatabasedatabase]referenceWithPath:@"users/morgan/lastOnline"];[userLastOnlineRefonDisconnectSetValue:[FIRServerValuetimestamp]];

Clock Skew

Whilefirebase.database.ServerValue.TIMESTAMP is much more accurate, and preferable for most read/write operations, it can occasionally be useful to estimate the client's clock skew with respect to theFirebase Realtime Database's servers. You can attach a callback to the location/.info/serverTimeOffset to obtain the value, in milliseconds, thatFirebase Realtime Database clients add to the local reported time (epoch time in milliseconds) to estimate the server time. Note that this offset's accuracy can be affected by networking latency, and so is useful primarily for discovering large (> 1 second) discrepancies in clock time.

letoffsetRef=Database.database().reference(withPath:".info/serverTimeOffset")offsetRef.observe(.value,with:{snapshotinifletoffset=snapshot.valueas?TimeInterval{print("Estimated server time in milliseconds: \(Date().timeIntervalSince1970 * 1000 + offset)")}})

FIRDatabaseReference*offsetRef=[[FIRDatabasedatabase]referenceWithPath:@".info/serverTimeOffset"];[offsetRefobserveEventType:FIRDataEventTypeValuewithBlock:^(FIRDataSnapshot*snapshot){NSTimeIntervaloffset=[(NSNumber*)snapshot.valuedoubleValue];NSTimeIntervalestimatedServerTimeMs=[[NSDatedate]timeIntervalSince1970]*1000.0+offset;NSLog(@"Estimated server time: %0.3f",estimatedServerTimeMs);}];