Android database best practice

Question

Coming from a perl background and having done some simple OO in that, I am struggling to grasp the android/Java way of interacting with databases.

In my experience I would create a file or class for each object, and an object would match/represent a table in the database.

Within that object would be a constructor, variables for the data, methods/functions to return individual variables but also the DB queries to read and write from the DB, doing all the necessary CRUD functions.

From what I read on the web, in Android I would create the objects similarly but without the DB interaction. This would happen in either a single class with all my DB functionality in it, or multiple DB classes, one per table.

My questions are all to do with best practices really.

Can I do my app how I would in Perl. If not why not, and if so,what are the pros and cons and limitations?

What do the terms DAO, Adapter and POJO mean?

Should I make an application class and globally declare the DB there?

Should I create one handler in each activity or in the application class only?

I have read so many tutorials now my head is spinning, all with a diff way of doing things and mostly only with a single table and few showing actual objects directly representing tables.

I'm happy to hear opinion, be linked to tutorials or just have the odd term explained.

Thanks in advance

score 1 · Answer 1 · answered Sep 24 '12 at 23:00

1

If I am reading you correctly, ORMLite may be your best bet. It uses reflection for database creation and maintenance which seems to be how Perl does it.

answered Sep 24 '12 at 23:00

ahodder

11,353
14
71
114

I'm not sure this is what I want. It still seems to have a separate db class for each object, and the object itself. I'll write up some mock code later as an example of what i'd like – Russ Wheeler Sep 25 '12 at 10:30

score 1 · Answer 2 · answered Sep 24 '12 at 23:01

POJO is Plain old java object which means it is just a normal class.

An adapter would be the class that contains the CRUD stuff and manages the database itself. There are quite some patterns around in the Android world and talking about can fill a book. I prefer the pattern, that I open the database once in my Application class and I never close it (Android does that when it kills the app). A sample from a very old project I had might show you the basic idea.

DAO is Data Access Object and can fill dozens of books. If would just start programming and see where you're heading...

score 1 · Answer 3 · edited May 23 '17 at 12:27

The other poster is correct in putting out ORMLite as a great way to manage code relationships that mirror your database. If you're looking to do it on your own, however, there are a ton of ways to do things, and I wouldn't say the community has really gravitated toward one over the other. Personally, I tend to have my entities represented by Plain Old Java Objects (POJO - implies no special connectivity to other things, like databases), where the various attributes of the table correspond to field values. I then persist and retrieve those objects through a Data Access Object (DAO). The DAO's all have access to a shared, open, Database object - against which they execute queries according to need.

For example: if I had a table foo, I would have a corresponding entity class Foo, with attributes corresponding to columns. class FooDAO would have mechanisms to get a Foo:

public Foo getFooById(Integer id) {
   String[] selection = {id.toString()};
   String limit = "1"
   Cursor c = mDatabase.query(FOO_TABLE, null, "id=?", selection, null, null, null, 1);
   // Create a new Foo from returned cursor and close it
}

A second entity bar might have many foo. For that, we would, in Bar, reference the FooDAO to get all of bar's member foo:

public class Bar {
  public List<Foo> getFoo() {
    return mFooDAO.getFooByBar(this);
  }
}

etc... the scope of what one can do in rolling your own ORM like this is pretty vast, so do as much or as little as you need. Or just use ORMLite and skip the whole thing :)

Also, the android engineers frown on subclassing Application for globally accessible objects in favor of Singletons (see hackbod's answer), but opinions vary

Android database best practice

3 Answers3