Why does so much DB interaction happen in the Singleton?


#1

Why does so much DB interaction happen in the Singleton class and not in the activity in the CriminalIntent and RunTracker examples? I ask because I’m working on an app for my capstone project that will use three tables and it seems to me it would be better to localize the database interaction in the activity that is being used to collect the data and just use the Singleton to retain the minimum amount of information necessary i.e runId. With that information, if the activity/fragment gets interrupted for some reason, it can retrieve the runId from the Singleton and get the record itself instead of having the Singleton get it.

I’m also curious why the examples use a Singleton class instead of an application object. Isn’t an application less likely to get garbage collected than a class?


#2

Good question! The big reason is an incredibly useful rule of thumb for designing your apps: separation of concerns.

Classes that are responsible for one specific thing are easier to understand than classes that are responsible for many things. They give you some structure, some lines that you can’t scribble outside of.

Putting the database code in the singleton makes one thing very clear: the database code and the activity code are separate. The activity can use the database code by calling methods on the singleton, and that’s great. There’s no significant downside to this.

This helps with a few things. For one, it makes the code more readable: database code is in one place, UI code is in another. But it also helps when (as inevitably happens) the UI changes dramatically. If the database is in a separate class, it can remain unchanged. That’s because the concerns were separated. On top of that, the database object may be used elsewhere when appropriate - you couldn’t do that with the code in the activity.

Now the last bit - Singletons versus the application object. Singletons cannot be garbage collected, so that’s not a concern. Neither can the application, of course, but the application has one major downside: you can only have one. So we use singletons instead.


#3

So then are you saying that a multi-table application should have a singleton class for each of the tables?


#4

The typical pattern is not to have a separate interface (and singleton) for each table, but to have one central interface for each store of data. The store could represent a web service, a file, but more often than not it’s a SQLite database.


#5

I may be getting way off topic and you might want to take this off line.

the last two responses seem to contradict themselves.

“but the application has one major downside: you can only have one”

As far as Singletons in response to this questions So then are you saying that a multi-table application should have a singleton class for each of the tables? “The typical pattern is not to have a separate interface (and singleton) for each table, but to have one central interface for each store of data. The store could represent a web service, a file, but more often than not it’s a SQLite database.”

The second response seems to indicate that a application object would be just fine.

I really learned a lot in your book by the way that I’m incorporating in my capstone project, i.e. loaders and fragments. The trouble I’m having is that I was using an application class to…

OK here’s my project. It’s a construction management project which has a database with three tables: a project table, a visit table and a photo table. You have a project. You go on a visit to the project and you take pictures during the visit.

You create a project and it gets entered in the project table. You go on a sight visit and it gets entered in the visit table. You take pictures during the site visit and they get entered in the photos table. I was using the application class to keep track of where I was. If I selected a project, it stored the projectId. If I went on a visit it stored the projectId and the visitId. If I took a picture during the visit it stored the projectId, visitId and photoId. As I backed out from photo to visit to project it would store less and less. I was using the application class to store these ids.

I had an abstract DB adapter that created the database and tables and opened and closed them. Then each table had a DB adapter that handled the CRUD for each table.

So what am I getting at? I guess I’m asking

  1. did the two responses conflict because I’ve kind of adopted your philosophy but pulled the DB access out of the Singleton and put it back in the activity/fragment

  2. which way is more efficient, the way I was doing it with the db adapters or the way you’re doing in it one db helper class if you have multiple tables

Or maybe I’m not getting that your Singleton is my db adapter class.


#6

!

I’ll clarify:

First, singletons vs. application objects. A singleton, like the application object, has only one instance in the entire app. However, you can create a variety of singleton classes that each have a different purpose. You can’t do that with the application object - you can only hook up one application class to your app.

And second, the design question. I don’t think a singleton for each table makes sense - I think a singleton for the database makes sense. My apologies if I was unclear.