1

I currently have a SQLite DB on my server that is needed by an android app I am currently developing. I download the DB to the android device using HTTP each time the contents are changed.

Does anyone have any suggestions as to how to do this more efficient. ie. when the database gets large I don't want the android user to have to download the whole database again just because one record was added.

Improve this question
4
  • Slightly relevant: serverfault.com/q/89329/110769
    – ohaal
    Commented Jun 11, 2013 at 7:50
  • Just to be clear, is it a native app based off the Android Java/Native SDK, or is it a mobile device optimized, HTML-based website?
    – JustinC
    Commented Jun 11, 2013 at 8:41
  • 1
    May I ask, why was I down voted?
    – Keagan Ladds
    Commented Jun 11, 2013 at 14:36
  • @JustinC A native android sdk application. If it where a "device optimized, HTML-based website" I would not need to copy the database to the device as everything can be handled server-side
    – Keagan Ladds
    Commented Jun 11, 2013 at 14:38

2 Answers 2

Reset to default
2

I don't think there's a good off-the-shelf solution at the database level. The way would approach this is roughly this:

  • The database schema includes versioning information; this can be as simple as created/modified timestamps on each row, or you can fully historize everything, depending on your practical needs. The key here is that you need to be able to check what the changes were after a given date/time.
  • The server exposes data through a web service; since all you need here is basic CRUD, a RESTful API would be appropriate. The API should expose a way of querying for changes, e.g. http://example.com/api/modifications/things?refdate=20130601 would give you all the modifications to the things table since 06/01/2013.
  • The client app would use API calls to download recent changes from the server, and push local changes back up. It would run its own sqlite database locally, but you'd never exchange the database files directly.

So instead of pushing the entire database back and forth, you selectively push and pull just the changes, with the API acting as the interface.

Improve this answer
1
  • This approach also lets you use something other than SQLite on the server side, when you start getting big.
    – Michael Hampton
    Commented Jun 11, 2013 at 17:28
0

Is it required to use HTTP? Can you use a TCP connection?

If so, you can use the litereplica library.

Make the server db file be the primary (writable) db and the mobile have the secondary (read-only) db.

If the mobile app needs to write to the db, it can use another file for its own content. You can even use another pair in the opposite direction, what serve as a backup and the server can even read it.

And the db updates are incremental. This means that only the changed pages are transferred instead of the whole database.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.