Best practices for SQLite DB and ContentProvider

Question

My Android app is reading and writing to a local SQLite database from several different activities and services. Pretty standard. But I am not happy that I have all the database data stored as constants, which I then use wherever I access the database. I recommend wrapping the database in ContentProvider. Sounds good. While I was reorganizing my code, I decided that I would ask:

• What are your best practices for storing database data locally in Android?
• Where and how do you store CREATE TABLE statements, column names, other SQL?
• Could you share a list of the classes you create and what is included in each (ContentProvider, DatabaseProvider, DatabaseHelper ...)?
• How do you coordinate the structure of your local Android database with the server database, accessible via the REST interface?

Yes, I understand that I am in a multi-year “context framework for binding objects to Android objects”? question. At the moment, I'm mostly interested in learning how you structure your Android applications with what is available in the standard SDK.

As always, thanks for the pointers!

Answer 1

We've been tweaking ORMLite on Android for a while, and it works well. ORMLite supports Android with its own database calls, and also supports other databases through JDBC. You comment on your classes / fields and use the DAO base classes to continue SQLite.

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

Hope this will be somewhat helpful.

Answer 2

Currently, I'm mostly interested in learning how you structure your Android applications with what is available in the standard SDK.

I am not a real fan of SQL and the way it is processed in android, so I use the NeoDatis object database . Basically, it just allows you to store / retrieve Java objects in a flat file stored on the device, very easily. db40 is also another alternative object database that will run on android.

You had no problems using this approach, you may notice that including the NeoDatis library will increase your APK size by ~ 700 kb.

Answer 3

I don’t know that I have an answer, except that I don’t really like how it is handled, and I find it very dirty. I usually follow the pattern in the example with the notebook that comes with the SDK.

In this regard, I am working on my own ORM mini-structure, using annotation and managing all this. So far, everything is working fine, but I still haven't worked.

Answer 4

You can also watch Androrm . This is an open source Orm tool designed specifically for android. This should help you with all the materials related to the database.

Answer 5

Just to complete the list more and more ... Another ORM is the ORM solution provided by the BARACUS Framework . He is not going to create databases of corporate size, the more to store several objects in the database and makes it available for the application. There are no cogeneration approaches inside it; you just write your pojo object, rowmapper and def table. So you can use DAO, Injection Dependency Injection, IOC style lifecycle support, and more.

Features of ORM:

• Lazy Loading (Collections + Lazy References)
• CRUD operations for free
• Request for example
• several aspects (autotimestamp, etc.)
• Conservation-level lifecycle support across multiple application releases

For more complex database material (using ORM is a little manual work, for example, in the old spring rowmapper time). I am now thinking of adding ormlite integration.

For more details on the code, just check out the github tutorial app