views:

73

answers:

1

I'm building an app where I have a table for events and a table for venues. I want to be able to grant other applications access to this data. I have a few questions related to best practices for this kind of problem.

  1. How should I structure the database classes? I currently have classes for EventsDbAdapter and VenuesDbAdapter, which provide the logic for querying each table, while having a separate DbManager (extends SQLiteOpenHelper) for managing database versions, creating/upgrading databases, giving access to database (getWriteable/ReadeableDatabase). Is this the recommended solution, or would I be better off either consolidating everything to one class (ie. the DbManager) or separation everything and letting each Adapter extends SQLiteOpenHelper?

  2. How should I design content providers for multiple tables? Extending the previous question, should I use one Content Provider for the whole app, or should I create separate providers for Events and Venues?

Most examples I find only deal with single table apps, so I would appreciate any pointers here.

A: 

I recommend checking out the source code for the Android 2.x ContactProvider. (Which can be found online). They handle cross table queries by providing specialized views that you then run queries against on the back end. On the front end they are accessible to the caller via various different URIs through a single content provider. You'll probably also want to provide a class or two for holding constants for your table field names and URI strings. These classes could be provided either as an API include or as a drop in class, and will make it much easier for the consuming application to use.

Its a bit complex, so you might also want to check out how the calendar as well to get an idea of what you do and do not need.

You should only need a single DB adapter and a single Content provider per database (not per table) to do most of the work, but you can use multiple adapters/providers if you really want to. It just makes things a bit more complicated.

Marloke