6

In my app I have SQLite db. I want to introduce sync between devices of my users. Firebase DB looks like an acceptable solution, but Firebase DB is cloud db at first. So, I can't use it as local db if user will reject auth dialog and let him use app, but without cloud-sync.

Now I think about combining my local SQLite db with cloud Firebase db.

For example, when user adds new row to local SQLite db, my app will also put data into Firebase DB. Other devices of this user will catch this event and update their local db. When the user uses authentification and installs app on new device, I want it to download all rows and put them into local SQLite db. That's my idea: use Firebase DB only for synchronizing data, not for storing it at device. Main reason for it is to let user use my app without authentification&synchonization. The second is that Firebase DB is not designed to be used as local db.

I'm right? Is it okay to use Firebase DB with another local DB?

Related question:

link He want the same as I want:

my plan is to offer the user the option to stay offline

Alexandr
  • 3,859
  • 5
  • 32
  • 56
  • 2
    If you want synchronization [Couchbase](http://www.couchbase.com/use-cases/mobile-applications) provides a good option. – OneCricketeer Aug 19 '16 at 00:16
  • You seem to not be looking for an online/synchronized database, but more for a messaging system that guarantees delivery. While you can build such a messaging system on top of Firebase (and likely any other of the named databases), it might be better to look for a more direct fit to your use-case. Recommending a library is off-topic at Stack Overflow though. – Frank van Puffelen Aug 19 '16 at 02:07
  • 1
    But if you intend to build this on Firebase it doesn't have to be difficult. You'll need to figure out your deletion criteria: when do you delete the data from the cloud. You can do that after a certain time-out, once you have confirmation that all other users have gotten the data, or by a mix of both. – Frank van Puffelen Aug 19 '16 at 02:09
  • 1
    @FrankvanPuffelen there is my idea: I don't want to delete data from the cloud. I want to use `Firebase DB` as shadow-db for local one. – Alexandr Aug 19 '16 at 07:46

2 Answers2

2

Some options for HTML5 hybrid apps

This is not what the OP asked about, but hopefully useful to some seekers.

You can use any combination of client and server database to implement storing remotely-maintained data in the device so it will be available when offline.

Some client options :

Some server options :

kris
  • 11,868
  • 9
  • 88
  • 110
  • 2
    I'm not sure this answer addresses Native applications or how to sync a SQLite database – OneCricketeer Aug 19 '16 at 00:20
  • @user1290746 Thanks! PouchDB/CouchDB looks great but I don't want to start my own server as I can use Firebase for now. Moreover, the last commit of PouchDroid was in 2014. I can't rely on code, running inside WebView without any author support as I'm not JS developer. – Alexandr Aug 19 '16 at 00:27
  • Sorry @Alexandr & cricket_007 - I saw Sqlite and assumed it was hybrid code. – kris Aug 19 '16 at 00:28
2

If your firebase structure is not too complex you could also make a interface which defines methods like 

void addData(Data data);
Data getData(long id);
void editData(Data data, long id);
void deleteData(long id);

then create 2 classes implementing that interface, one using Firebase the other using SQLite.

DatabaseImplementation
FirebaseImplementation

Inside your Firebase implementation, you would publish the data like normal, and publish one new node to something like root/requestUpdate/userId/push/ and push would contain information on where you request an update, and what deviceId published it.

Then have a ValueEventListener tied to that mentioned node, and if it gets a new child, have it look whether the deviceId is the same or not. If it is not, have the FirebaseImplementation getData using the information you got, and then use the DatabaseImplementation, to addData.

That would make sure that whenever a change is made, any other logged in client will know to update its firebase. If the client is not online, the next time he will be online he will do it as ValueEventListener triggers when it is attached. Make sure to loop through all the requested updates to make sure all are made. Also store the push keys of any updates you did complete on a local database that way you dont end up updating more than once.

Basically the firebase will always be up to date and store any changes a user made on a seperate node which is listened to by all clients.

Obviously this solution still has many problems you would need to fix, like figuring out when to delete the requestUpdate node. Logically after every user has synced but how do you determine this? ...

As for the first login, you would need to write a populateDatabaseFromFirebase() method which will do a whole lot of getDatas and addDatas. How you would do that will depend on how your DB looks. You then would store that the user has already logged in with SharedPreferences and the firebase UID.

That all being said, this will only work if your firebase is pretty flat. If you have a complex database, then everything becomes much more complicated and entangled and then it might be worth looking into an external library.

Linxy
  • 2,525
  • 3
  • 22
  • 37
  • You mean that I must use `Firebase DB` to store&share 'data changed' `event` objects? My idea was to use it as shadow db with local one. And sync any other authenticated user device's local DB with this `Firebase DB`. Even after first login. – Alexandr Aug 19 '16 at 07:44
  • Yeah thats exactly the point in making that `requestUpdate` node. If you add a Item to your "DB" then use FirebaseImplementation and DatabaseImplementation to save it. Any other user will see that data has changed in the firebase with the requestUpdate node and can download the changes to his local database automatically – Linxy Aug 19 '16 at 07:54