Database helper class and DAO methods on an Application- or on an Activity instance?

[Johan Pelgrim]

Hi Satya / Dave,

When working with databases which do you prefer and why? Defining an SQLiteOpenHelper instance and DAO methods on an Application instance, or on a (the main) activity? Both provide a context, but apparently the application context is created before- and outlives any activity context. Some consider working with an Application context as working with 'global variables' and thus bad practice. But is it such a bad thing in your opinion? (not in mine by the way )

Cheers,

Johan

[Dave MacLean]

One thing to consider is how much sharing of the database access you want. Have you considered wrapping the database with a content provider? (Chapter 4 in Pro Android 3 by the way ;-) This then abstracts the database so your activities can work with a content provider rather than you worrying about whether or not to use the application or the activity.

If I can genericize your question, if you have objects that should exist through an activity destroy/create cycle, as happens when there's a configuration change of the device, where's the best place to anchor them? The advice from the Android team is to not extend the Application class, although it is doable. Their advice, and I agree with it, is to define a singleton class when needed. You'd be able to reference the singleton anytime you need it, you wouldn't need to extend the Application class (with the requisite modifications to the AndroidManifest.xml file), and your activities can live and die without affect. In Pro Android 2 I showed how to extend the Application class to share an HttpClient with my activities. In Pro Android 3, I switched to a singleton for my HttpClient. The code is cleaner, and it just feels right.

- dave

[Bill Mote]

Dave MacLean wrote:The advice from the Android team is to not extend the Application class, although it is doable. Their advice, and I agree with it, is to define a singleton class when needed.

Would you mind sighting that reference? I would love to read more about that.

Bill Mote

[Dave MacLean]

The discussion with Dianne Hackborn was on the android-developers group, but here's an archive of that discussion with her post indicating a preference for singletons. In fact, she states that she wishes the Application class was never introduced.

http://www.mail-archive.com/[e-mail]/msg124493.html

At the same time, I've seen plenty of posts from developers who say there's nothing wrong with extending Application. At this time, I think you could extend Application and not get into too much trouble. The problem is that Android is still evolving and somewhere down the road, the semantics of Application could change and affect all those who took that path.

- dave

[Satya Komatineni]

This is certainly a thought provoking question.

An application is a nice abstraction to have. I hope they keep it.

I like the idea that from anywhere in my code irrespective of its place I can ask for an application object and I get the same single application object. then i can discover where the app is installed, where are the log files, how I can read configuration etc.

However the right way to use an application is to use it as a conduit to get access to various services including the discovery of single instance objects (not necessarily implemented using singletons).

Again this is theory.

Until now in Android the application object if fairly simple. Given that if one needs to use its context then one can call the

Context.getApplicationContext()

static method from anywhere in the code.

If you were to use the inheritance approach the application interface will get crowded with many many methods which could have been broken down into their own abstractions.

I wish Android has a unified factory/configuration service that would have completely eliminated the need for singletons. For example the framework I developed and regularly use for web work called AspireWeb has this abstraction (much like spring) and I found it extremely useful. In that world any application instance will have the following methods

IApplication
{
IFactory getFactoryService();
ILog getLoggingService();
IConfig getConfigurationService()
}

Then each application be it desktop or web will implement its own idea of what these services are. Once you get hold of an application object it is guaranteed to have these services. Out of these the IFactory works much like Spring.

Anyways coming back to your question

Implmenting the DAOs as singletons will give you better scoping because you can use multiple singletons and not corrupt the application name space.

I will still say find a way to implement or borrow a "spring" like abstraction to eliminate singletons but still get the same affect.

No. I haven't done this on Android.

I am hoping I will get time in about 10 years to port the AspireWeb framework to Android.

[Johan Pelgrim]

Thanks again guys, for some great feedback!