current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite
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.

share|improve this question

migrated from serverfault.com Jun 11 '13 at 8:09

This question came from our site for professional system and network administrators.
    
Slightly relevant: serverfault.com/q/89329/110769 –  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
1  
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

1 Answer 1

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

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

Your Answer

 
discard

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.