I am building a POS like Android app which needs to work even if Data connectivity is temporarily lost.
The idea is to report all transactions to the server immediately if Data connectivity is available. If not, store it locally in SQLite and sync later when connectivity becomes available.
The first plan was to save individual transactions in the same general DB structure as is maintained on the server, but since there are so many different types of transactions and relationships on the server, this would effectively replicate the entire DB structure from the server on the phone itself.
An alternate to this, is to just save the final HTTP requests that are being used to inform the server of the changes. The advantage of such an approach is that it only requires one table, to just store the URL, request content, method etc. But there could be some calls that require code to be executed on the response, which would be implemented as anonymous inner classes. The only problem with this approach seems to be serializing these anonymous inner classes so that they can be loaded from DB and executed even after a (possible) phone restart.
What would be the best way to implement this? Option A or Option B? And if Option B, is it really possible to serialize and unserialize anonymous inner classes(which are effectively being used as closures here)?
For option A, you may wish to consider CouchDB to handle device/server replication.
