Question

My Android app is reading and writing to a local SQLite DB from a few different Activities and a Service. Pretty standard. But I’m not happy with the way I’ve got all the DB details stored as constants that I then use anywhere I access the DB. I’ve been advised to wrap the DB in a ContentProvider. Sounds good to me. While I’m refactoring my code, I figured I’d ask:

• What are your best practices for local DB data storage in Android?
• Where and how do you store “CREATE TABLE” statements, column names, other SQL?
• Would you mind sharing a list of the classes you instantiate and what goes into each (ContentProvider, DatabaseProvider, DatabaseHelper…)?
• How do you coordinate the structure of your local Android DB with a server-side DB available through a REST interface?

Yeah, I realize I’m getting at the perennial “where’s the Android object-relation-mapping framework?” question. For now, I’m mainly curious to hear how you structure your Android apps with what’s available in the standard SDK.

As always, thanks for the pointers!

Answer 1

We have been tuning ORMLite on Android for a while now and it is working well. ORMLite supports Android with native database calls and also supports other databases via JDBC. You annotate your classes/fields and use base DAO classes to persist to SQLite.

• CREATE TABLE statements are handled my ORMLite’s utility classes. Most SQL is taken care of by the DAO classes.
• The Android section of the online documentation explains the class hierarchy. You implement a DatabaseHelper which helps create an update your database. Your activities extend OrmLiteBaseActivity (or service or tab) which gives access to helper and DAOs.
• ORMLite does not provide a solution for merging with remote REST servers.

Hope this is somewhat helpful.