I’ve been fiddling with CB lite for a while now and I’m starting to encounter a few problems as a result of not approaching it from the right angle. I basically have a couple of activities that use the database and I haven’t been able to handle it well. What I did at first was to create a new instance of the StorageManager (which is the class that provides the database) on both activities and, since the database would be the same, I thought this would be ok for synchronization. This has created a lot of problems (specially when restarting the Replication pusher every time I resume an activity) and I thought it would be better to look it up here in the forum.
I’ve seen some recommendations about using a singleton or a content provider, as well as having a service running in the background doing all the syncing.
Using a simpleton is not recommended in android unless you use a library that manages the threads, and making a content provider seems like overkill to me.
Is there a sample case for this that I haven’t come by yet? am I missing something?
Thanks in advance.
While one has to be careful about misusing the singleton pattern , it is an appropriate pattern for implementing the Couchbase database manager. This manager would be shared across activities and would be responsible for database initialization , managing replications etc. (Unless @hideki has a different opinion)
This is a deep subject of debate in Android, as you’ve noted.
Accessing the database is an example of a situation where you want easy access to a single instance (which does not necessarily mean using the Singleton Pattern), potentially from different parts of the application, but where the information you access is both idempotent and is by nature immutable. This gets rid of some of the reasons to avoid a Singleton.
You still have issues with testability. There are other problems, too (memory management, strong coupling), but for a lot of apps and the typical usage pattern of the database, I think testing is the dominant one. (Note threading isn’t an issue, in part because of CBL design, and some simple approaches you can use to make instantiating your Singleton thread safe. I prefer the Holder pattern for this.)
There’s a big move to use dependency injections (via libraries) in Android. I can’t say I’m a fan in this case, but it’s one alternative.
I often do just go to a Singleton. As @priya.rajagopal mentions, the arguments against Singletons often boil down to meaning you need to be careful how you use them.
You could use a Service Locator pattern. This is probably my preferred solution for more sophisticated needs. You can implement it as a (fake) Content Provider as a means to make sure it gets initialized early, and to give access to an ApplicationContext.
Here’s a reference I think does a good job of going through the Singleton issue, and has a great follow on writeup on Service Locators: http://gameprogrammingpatterns.com/singleton.html