Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from Jun 11 '13 at 8:09

This question came from our site for system and network administrators.

Slightly relevant: – ohaal Jun 11 '13 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 Jun 11 '13 at 8:41
May I ask, why was I down voted? – Keagan Ladds Jun 11 '13 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 Jun 11 '13 at 14:38
up vote 2 down vote accepted

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. 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.

share|improve this answer
This approach also lets you use something other than SQLite on the server side, when you start getting big. – Michael Hampton Jun 11 '13 at 17:28

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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