I'm using ORMLite in an android project, and I'm not wanting to use the extended activities because I'm inserting values into the database on an AsyncTask.
In the docs it says:
"If you do not want to extend the OrmLiteBaseActivity
and other base classes then you will need to duplicate their functionality. You will need to call OpenHelperManager.getHelper(Context context, Class openHelperClass)
at the start of your code, save the helper and use it as much as you want, and then call OpenHelperManager.release()
when you are done with it."
It also says to add the database helper class in the strings.xml
, which I have. So I'm not sure what I'm doing wrong.
I'm using a class called DataAccess
for my data tier that looks like this:
public class DataAccess {
private Context context;
private DBHelper dbHelper;
public DataAccess(Context _context) {
this.context = _context;
dbHelper = getDBHelper(_context);
}
private DBHelper getDBHelper(Context context) {
if (dbHelper == null) {
dbHelper = (DBHelper) OpenHelperManager.getHelper(context, DBHelper.class);
}
return dbHelper;
}
}
And I'm using the extended helper class:
public class DBHelper extends OrmLiteSqliteOpenHelper {
private static final String DATABASE_NAME = "database.db";
private static final int DATABASE_VERSION = 1;
private Dao<SomeObject, Integer> someObjectTable = null;
private ConnectionSource connectionSource = null;
public DBHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db, ConnectionSource connectionSource) {
this.connectionSource = connectionSource;
try {
TableUtils.createTable(connectionSource, SomeObject.class);
} catch (SQLException e) {
throw new RuntimeException(e);
}
}
@Override
public void onUpgrade(SQLiteDatabase db, ConnectionSource connectionSource, int oldVersion, int newVersion) {
}
public Dao<SomeObject, Integer> getSomeObjectDao() throws SQLException {
if (someObjectTable == null) {
dateTable = getDao(SomeObject.class);
}
return someObjectTable;
}
The idea is to create the DataAccess
class and have it create the DBHelper
if it hasn't already.
Can someone tell me if this is right or wrong, or if I'm on the right path?
Thanks!
You are on the right track but a little off @Matt. Frankly I'd never done a project without extending our base classes. But it is a good exercise so I've created this ORMLite example project which uses an
Activity
and manages its own helper.Your
DBHelper
class is fine but really you do not need yourDataAccess
class. In each of your activities (or services...) you will need to have something like the following:You [obviously], then use this in your code by doing something like:
So whenever you call
getHelper()
the first time, it will get the helper through the manager, establishing the connection to the database. Whenever your application gets destroyed by the OS, it will release the helper -- possibly closing the underlying database connection if it is the last release.Notice that the
OpenHelperManager.getHelper()
needs theContext
as the first argument in case you do this without even anActivity
base class.Edit:
If you do want to create a
DataAccess
type class to centralize the handling of the helper class then you will need to make the methods static and do your own usage counter. If there are multiple activities and background tasks callinggetHelper()
then the question is when do you callreleaseHelper()
? You'll have to increment a count for each get and only call release when the counter gets back to 0. But even then, I'm not 100% sure how many lines you'd save out of your activity class.I could nitpick but essentially you are doing it correct.
The call
Looks up the
DBHelper
class and instantiates it for the context. If you have defined it in your strings.xml, you can leave off the DBHelper.class at the end.onUpgrade
in youDBHelper.java
, you may want to consider dropping the table you create inonCreate
and then callingonCreate
(to make sure you don't have conversion issues from update to update). You could do a more complex update if you wanted.Other than that, it looks good. If you end up wanting data accessory methods for your DB objects beyond the base DAO methods, you will eventually want to create more thorough implementations of your object DAOs, but this is a good start.