Permanently Offline Android app? Local storage only?

[Nicolai Buch-Andersen]

Hi

I have an Android app that currently uses an SQLite backed Content Provider to store data locally. I would like to add Firebase data storage as an option in future versions of the app. That is, the user should be able to continue to use the app with "local storage" as usual, or create an account / login with Google and enjoy the benefits of Firebase cloud storage.

Obviously, I could just keep my old SQLite/Content Provider code and only push data to Firebase when and if the user has completed the sign-in "onboarding" process. But honestly, the Firebase JSON data model and the Firebase event based data querying and so on is pretty far from the traditional Android way of doing things. I like the Firebase approach very much, but it would be a pain to build an abstraction layer that hides the storage strategy from the rest of the app. I would prefer to go all in on Firebase and just discard the SQLite stuff.

I investigated offline disk persistence in the Firebase SDK, and it seems that Firebase already have a robust "local storage" mode when offline. Can I initialise Firebase in offline mode and just leave it offline permanently if the user has opted out of cloud storage?

Firebase.setAndroidContext(context);

Firebase.getDefaultConfig().setPersistenceEnabled(true);

Firebase.goOffline();

From the documentation it seems that the goOffline(), and offline mode in general, is build to handle temporary periods where the device is offline, and sync data back in to the cloud as soon as the device becomes online again. Would the Firebase offline mode be capable of handling a "permanent offline" scenario? Or would forcing Firebase to go "permanently offline" lead firebase to just accumulate more and more "meta data" for a never occurring future sync to the cloud? Or discard old data at some point? Or run out of offline cache disk space when a max cache size is reached? 

/Nicolai

[Frank van Puffelen]

Cross-post: http://stackoverflow.com/questions/32788751/firebase-sdk-offline-data-storage-with-the-option-to-sync-at-a-later-date (although on StackOverflow it's about iOS)

[Nicolai Buch-Andersen]

Well. hopefully the guy who posted the iOS question on SO will get an answer. I guess the principles of the offline mode in Android and iOS is probably similar, so I'll be able to adapt the answer to Android.

If it turns out that the current offline mode is unsuitable for storing data offline permanently, I hope that the Firebase team will consider adding it in the future. In addition to helping me with my scenario, it would be cool to have a strong noSQL alternative to the build-in SQLite storage option - and it would provide a nice entry point for new developers curious about Firebase.

I could image doing something like:

localFirebaseRef = new Firebase("localhost");

localFirebaseRef.addValueEventListener(...);

localFirebaseRef.setValue(someData);

... and so on, and then later - when both I and my users are ready to go online - I just make a new reference to a "real" Firebase URL and start taking advantage of cloud storage and the server-side rules and so on. 

[Nicolai Buch-Andersen]

It seems the guy on StackOverflow managed to get a response from Firebase support:

While you can use goOffline() to force the client offline for a long time, performance will deteriorate over time. The Firebase clients will queue intermediate state changes, instead of updating the stored state as the server does.

...which pretty much confirmed my suspicion, unfortunately.

It would be great if Firebase added a "local only" mode in the future (see my previous post).

[Dennis Smolek]

Would PouchDb/CloudDb not be a better solution for you? Don't get me wrong I'm a firebase fan for sure but the lion's share of the data is the same and has pretty great support. Then if you had something that you wanted to use firebase for it's speed/auth/whatever you could just sync it back onto your pouchDb for when it goes offline. 

I'm doing a ton of offline first stuff so I'd love to get your thoughts on it..

-D

[Nicolai Buch-Andersen]

Hi Dennis

PouchDb seems to be JavaScript specific, so it's not really an option on Android. Apache CouchDb is apparently build using Erlang, and even though there's a Java API it wont run on Android either, as far as I can see. But Couchbase maintains a somewhat similar almost-clone for Android here: https://github.com/couchbase/couchbase-lite-android 

The documentation for Couchbase is nowhere near as good and as easy to read as the documentation for Firebase. Really, the clear, well-structured documentation for Firebase was one of the main reasons I was attracted to Firebase to begin with. Still, with Couchbase being a noSQL database it has much more in common with Firebase than SQLite, and it does indeed offer an offline "local data only" mode. Using Couchbase to store offline data and Firebase for online (user authenticated) data seems feasible. 

These are my options, as I see them:

1) Continue to store local data in SQLite until user has signed in and then switch to Firebase. I can make this dual storage strategy easier by changing my SQLite tables to mimic a noSQL database - i.e. just one or two tables storing JSON with unique strings as "document keys." Then write a thin data access layer on top of SQLite and Firebase that takes the cursors from SQLite and the callbacks from Firebase and transforms them into my custom, domain specific callbacks.

2) Use Couchbase for local storage and Firebase for cloud storage. I still need my thin data access layer and still need to capture the callbacks from both Couchbase and Firebase and transform them to conform to a unified callback interface. But the data access layer will probably be thinner and hopefully a bit easier to write when using noSQL for both types of storage. On the other hand, I'll end up with two dependencies in my app and have to maintain code for two similar but (most likely) subtly different technologies.

3) HACK Firebase: Generate a dummy email address and a password using a random UUID when the app is first launched, store these in a local, app-private file. If the user opt-out of the oboarding then authenticate with Firebase using the dummy values. This is not very secure and it just seems dishonest to sync data to the cloud even when the user has opted out of the onboarding. Also, it requires an internet connection for creating the initial dummy email user, and also for syncing once in a while so as not to degrade the offline performance.

4) Drop Firebase and go all-in with Couchbase instead. The great strengths of Firebase is the superb documentation, simple API and the fully hosted backend (with a simple pricing model!). Couchbase seems more complicated overall and less well documented by contrast - and I have to deal with hosting the database and sync gateway myself. But I can deal with it in two steps: Change my app to use Couchbase as local storage in place of SQLite and release a new version of my app relatively quickly; then for the next version I can set up a Cloudbase backend, add optional sign-in/onboarding in my app, and start a sync with the backend if and only if the user completed the new onboarding.

Right now I'm leaning mostly towards option 4.

[Mr M. Mz]

Hi,

I'm in same boat as what you have described here. I can't really come up with a good solution to use Firebase and keep data on user-based decision indefinitely offline. I was wondering what solution you ended up with eventually ?