I'm designing an Android app for data collection that is expected to be used in outdoor areas with spotty network coverage, so robustness of client-to-server messaging is important. If the user tries to submit something and the request fails or there is no network, the app needs to remember that and try again later, either on demand or when the connection is restored.
We're considering Firebase for our data model, but also want to evaluate a more traditional server/DB/API solution. One big advantage to Firebase is their "offline" support via the client SDK:
Your Firebase app will remain responsive regardless of network latency or Internet connectivity. All writes to a Firebase database will trigger local events immediately, before any data has been written to the server. Once connectivity is re-established, the client will receive any changes it missed, synchronizing it with the current server state.
Getting that for free is great if we go with Firebase. Alternatively, what would give me a similar client side capability to support a typical RESTful API? Preferably a library of some kind that would handle the state for me rather than tracking individual attempts.
I've looked into offline database sync solutions like SymmetricDS, but that seems like overkill in this case. In fact I'd rather the client not have direct database access. The messages sent from the app will be stand-alone entries like a photo or comment, and don't need to perform complex queries, synchronized writes, etc. I just need to ensure that whatever the user submitted will eventually make it to the server once a connection is restored, and confirm that it did.
If you were considering a hybird-app you could use PouchDB in a WebView (it supports Cordova and Android with SQL Lite and could be re-used for iOS this way). It can be used only on the local-side instead of using it's sync capabilities which are easy and powerful but would require giving clients direct database access. Although, you can configure R/W access permissions and multiple users on the db and each db can be per client/project, in fact this is how CouchDB is intended to be used making scale-ability very simple.
It is simple to use and obfuscates the underlying browser technology that is required and varies by browser to store the data. So you don't have to worry what browser supports which tech eg SQL or localstorage etc. Similar to Firebase, it may be more flexible for your situation.
Instead of the simple .sync() you can do from PouchDB in browser to a CouchDB server you can use traditional REST when a data connection becomes available. Data to View layer will be PouchDB and then you could manage the sync separately with the server and track responses to verify it updated. However, it would be much simpler to use the sync functionality if it could meet your requirements.
http://pouchdb.com/learn.html