I'm currently re-working an app of mine which updates it's internal SQLite database by fetching raw data from an website, not an official API.
As this is quite error-prone I'd like to move the data processing out of the client into an backend server. The idea is to have a script running on the server multiple times a day - similar to the client behaviour before - and storing the data in a Firebase Realtime Database. Then, all clients no longer have to process the data themselves but rather request parsed data from the Firebase DB.
I'm just wondering what's the best approach to keep the data synced. I came up with two ideas, but as I'm not too familiar with Firebase I don't know what's preferable.
For one I could imagine keeping the data on the client in sync by using keepSynced()
and setPersistenceEnabled()
on some nodes.
But I'm unsure whether this will keep data up to date when the app is in background. As well I'm worried about the battery and network usage of this approach.
A third point is the amount of simultaneous connections, I quess with this approach every client will be connected all the time, right?
The second approach would be to use FCM to notify the client whenever there is a change in one of his interested nodes, e.g. using Firebase Cloud Functions to listen for event and trigger the message.
Then the client would goOnline()
to sync with the database and goOffline()
again. This would avoid the huge amount of connections as well as reduce battery and network usage.
But I'm unsure on how to keep all the data on the device while offline?
I don't want to use a SQLite database to keep data on the device.
Is setPersistenceEnabled()
sufficient to keep a particular amount of database notes on the device?
Or is a mix of both the way to go? Setting keepSynced()
and setPersistenceEnabled()
on the needed nodes and goOnline()
/goOffline()
depending on cloud messages?
Any help or advices based on own expiriences welcome!
Your first approach is trying to ensure the Android app always has an open connection to the Firebase Database backend. This has been asked/tried before(see here, here), and is definitely possible. But you'll be fighting with Android updates, which are specifically trying to reduce battery usage by this type of behavior in apps.
The second approach is indeed better. I often refer to it as "push to sync", since you're sending a push notification (through FCM) to trigger a data sync. (plus: it's a word play on the "pull to sync" pattern so many apps follow). An example of an app using this approach is Google's I/O app for Android from 2016, the code for which is on Github. The code is a bit convoluted, but the actual sync is here and (iirc) it is triggered through this.
FCM would be a great choice for you considering that using only push data without notification as this forces the sent to data to be received in the onReceive method in your mobile application. If your device is offline it will resend the data again while it comes online again.
Whenever any change happens in your backend send push data to your devices using their presaved tokens.