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!
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
