CODEWITHSUNDEEP
androidfirebasefirebase-realtime-database
jontycg
jontycg

Reputation: 337

Maintaining connection to Firebase realtime database after app is closed if there is data that is still queued to be stored?

I'm using Firebase's realtime database on Android and the way I understand how it works is that even if the app disconnects from the network, Firebase will simply queue the transactions that the user has initiated and then perform then when connectivity is resumed. This works really well but if the app is closed then this queue seems to be discarded.

The Firebase docs on handling offline capabilities states the following:

Transactions are not persisted across app restarts

Even with persistence enabled, transactions are not persisted across app restarts. So you cannot rely on transactions done offline being committed to your Firebase Realtime Database. To provide the best user experience, your app should show that a transaction has not been saved into your Firebase Realtime Database yet, or make sure your app remembers them manually and executes them again after an app restart.

But as far as I know, there is no way of knowing whether or not data has finished being written to the database.

How exactly would you go about making the app manually remembering what still needs to be written to the database? Is there some way of accessing the queue of transactions that is yet to be carried out? Or is there some way of keeping the app running in the background after being closed that could just sync the data when connectivity resumes?

Thanks in advance.

Upvotes: 2

Views: 1798

Answers (2)

cutiko
cutiko

Reputation: 10517

I think I had the problem you are facing, in my case was a simple confusion. That Firebase warning is not about "transactions" in general, is about the "transaction" method provided by them.

In Android this is reference().runTransaction().

The "transaction" method is used to validate data first, by example, if more than one user can subscribe to an event simultaneously, you can make sure that the last vacant was available.

Since the "transaction" method query the database gives you the data, and the upload data, if there is no network connectivity there is no way to make sure that will work on app restart because there was never a first query to see the data you have to validate.

This seems logical to me, a "transaction" method will create a sort of bridge between the client and the database, this is not random, but because is part of the business logic, then you should warn the user visually that their changes might not be saved since it is offline, or even if it is sensitive not allow the user to do it.

In other cases, the data is indeed stored locally and then uploaded when the app is restarted. So if you do something like

reference.child(key).setValue(myObject);

Thant change will be local until the next time user has an internet connection.

You have to make sure to add the keepSynced to the references you actually need. Setting the syncing to the root, won't solve the problem as a waterfall, make sure to be specific with nodes you need to keep synced, this way the user will see the changed reflected visually in the app.

//Won't work
DatabaseReference root = FirebaseDatabase.getInstance().getReference();
root.keepSynced(true);

//This will work
root.child("event_list").keepSynced(true);
root.child("user_events").child(uid)keepSynced(true);

Upvotes: 1

Frank van Puffelen
Frank van Puffelen

Reputation: 599031

But as far as I know, there is no way of knowing whether or not data has finished being written to the database.

There actually is. The Transaction.Handler interface has a [onComplete method](https://firebase.google.com/docs/reference/android/com/google/firebase/database/Transaction.Handler.html#onComplete(com.google.firebase.database.DatabaseError, boolean, com.google.firebase.database.DataSnapshot)). The boolean that is passed to that argument is a flag to indicate if the transaction was committed:

committed
True if the transaction successfully completed, false if it was aborted or an error occurred

For more information, see the Firebase documentation on transactions.

Upvotes: 1

Related Questions