I'm trying to put all the DatabaseRequests inside a module in Android to centralize all the acces to DDBB in the same place.
I'm wondering if I'm making any mistake doing that. The apps works in the right way but I'm concerned about best practices doing that.
I have an static class called DatabaseRequest where all the requests are inside, for instance:
public static void insertUser(Context context, User user) {
DataBaseHelper mDataBaseHelper = OpenHelperManager.getHelper(context, DataBaseHelper.class);
try {
Dao<User, Integer> dao = mDataBaseHelper.getUserDao();
dao.createOrUpdate(user);
} catch (SQLException e) {
e.printStackTrace();
} finally {
if (mDataBaseHelper != null) {
OpenHelperManager.releaseHelper();
}
}
}
The context param is the context of the activity that's making the request.
Is there any performance issue related with this code?
Thanks in advance ;)
No, as Gray (ORMlite creator) said in this post:
is it ok to create ORMLite database helper in Application class?
What is most important with your code is that it guarantees a single
databaseHelper instance. Each instance has it's own connection to the
database and problems happen when there are more than one (1)
connection opened to the database in a program. Sqlite handles
multiple threads using the same connection at the same time but it
doesn't handle multiple connections well and data inconsistencies may
occur.
And in your case you may have multiple connections at one time.
I can preset you my approach on how I'm using ORMlite, I have one singleton class public class DbHelper extends OrmLiteSqliteOpenHelper which takes care of creating database connection and holds all Dao fields. You will have database upgrade code there and some other stuff so consider making facade classes. In my case each facade holds one Dao object for one model class, where i keep logic for complex item retrieving (and for simple cases i just delegate it to Dao object.
Related
I am trying to make my Sq-lite database globally accessible throughout my Android application using a singleton pattern:
What are some of the design options for the synchronizing the read/write of a sq-lite database in an android app -My question is how to design the SQLite DB access for the scenario
"using a singleton pattern " as you mentioned, it ensures that only one db connection is made to connect to database.
It's difficult to answer your question, but i think at least there are some things you should
try.
1. Extend the sqliteopenHelper for create database. -> This is the place you should apply the singleton pattern:
e.x:
private DummyDBHelper _instance = null;
public static DummyDBHelper getInstance(Context mContext) {
if(_instance == null) _instance = new DummyDBHelper(mContext);
return _instance;
implement the CRUD operations
Define each object seperately in each file
Call open/close in your activity
According to ORMLite documentation, all created Dao objects are cached inside DaoManager. But in ORMLite examples, I've seen Dao classes are again cached inside DatabaseHelper class. Do we really need it? ex.
public Dao<SimpleData, Integer> getDao() throws SQLException {
if (simpleDao == null) {
simpleDao = getDao(SimpleData.class);
}
return simpleDao;
}
My plan is to obtain Dao object when ever I need it and not to cache it inside my code base(In DatabaseHelper class), just want to allow DaoManager to cache Dao.
This is what I'm planing to use
DatabaseHelper databaseHelper = OpenHelperManager.getHelper(this, DatabaseHelper.class);
Dao<SimpleData, Integer> myDao = databaseHelper.get.getDao(SimpleData.class);
Any performance issue if I obtain dao like this, instead of caching it inside DatabaseHelper?
Any performance issue if I obtain dao like this, instead of caching it inside DatabaseHelper?
No this is certainly fine. You are doing a Hashmap.get(..) call each time but that is a very small hit -- especially when compared to any DAO operations or IO.
I would recommend not doing one of these for every call to the DAO:
databaseHelper.getDao(SimpleData.class).create(...);
databaseHelper.getDao(SimpleData.class).update(...);
But if you want to just get it at the start of the method and then perform a couple of operations then this should perform fine.
So I have a custom subclass of OrmLiteSqliteOpenHelper. I want to use the ObjectCache interface to make sure I have identity-mapping from DB rows to in-memory objects, so I override getDao(...) as:
#Override
public <D extends Dao<T, ?>, T> D getDao(Class<T> arg0) throws SQLException {
D dao = super.getDao(arg0);
if (dao.getObjectCache() == null && !UNCACHED_CLASSES.contains(arg0))
dao.setObjectCache(InsightOpenHelperManager.sharedCache());
return dao;
}
My understanding is that super.getDao(Class<T> clazz) is basically doing a call to DaoManager.createDao(this.getConnectionSource(),clazz) behind the scenes, which should find a cached DAO if one exists. However...
final DatabaseHelper helpy = CustomOpenHelperManager.getHelper(StoreDatabaseHelper.class);
final CoreDao<Store, Integer> storeDao = helpy.getDao(Store.class);
DaoManager.registerDao(helpy.getConnectionSource(), storeDao);
final Dao<Store,Integer> testDao = DaoManager.createDao(helpy.getConnectionSource(), Store.class);
I would expect that (even w/o the registerDao(...) call) storeDao and testDao should be references to the same object. I see this in the Eclipse debugger, however:
Also, testDao's object cache is null.
Am I doing something wrong here? Is this a bug?
I do have a custom helper manager, but only because I needed to manage several databases. It's just a hashmap of Class<? extends DatabaseHelper> keys to instances.
The reason I need my DAO cached is that I have several foreign collections that are eager and are being loaded by internally-generated DAOs that are not using my global cache and thus are being re-created independently for each collection.
As I was writing this up, I thought I could just have my overridden helpy.getDao(...) call through to DaoManager.createDao(...), but that results in the same thing: I still get a different DAO on the second call to createDao(...). This seems to me to be totally against the docs for DaoManager.
First, I thought it looked like registerDao(...) may be the culprit:
public static synchronized void registerDao(ConnectionSource connectionSource, Dao<?, ?> dao) {
if (connectionSource == null) {
throw new IllegalArgumentException("connectionSource argument cannot be null");
}
if (dao instanceof BaseDaoImpl) {
DatabaseTableConfig<?> tableConfig = ((BaseDaoImpl<?, ?>) dao).getTableConfig();
if (tableConfig != null) {
tableMap.put(new TableConfigConnectionSource(connectionSource, tableConfig), dao);
return;
}
}
classMap.put(new ClassConnectionSource(connectionSource, dao.getDataClass()), dao);
}
That return on line 230 of the source for DaoManager prevents the classMap from being updated (since I'm using the pregenerated config files?). When my code hits the second create call, it looks at the classMap first, and somehow (against my better understanding) finds a different copy of the DAO living there. Which is super weird, because stepping through the first create, I watched the classMap be initialized.
But where would a second DAO possibly come from?
Looking forward to Gray's insight! :-)
As #Ben mentioned, there is some internal DAO creation which is screwing things up but I think he may have uncovered a bug.
Under Android, ORMLite tries to use some magic reflection to build the DAOs given the horrible reflection performance under all but the most recent Android OS versions. Whenever the user asks for the DAO for class Store (for example), the magic reflection fu is creating one DAO but internally it is using another one. I've created the follow bug:
https://sourceforge.net/tracker/?func=detail&aid=3487674&group_id=297653&atid=1255989
I changed the way the DAOs get created to do a better job of using the reflection output. The changes were pushed out in the 4.34. This release revamps (and simplifies) the internal DAO creation and caching. It should fix the issue.
http://ormlite.com/releases/
Just kidding. Looks like what may be happening is that my Store object DAO initialization is creating DAO's for foreign connections (that I set to foreignAutoRefresh) and then recursively creating another DAO for itself (since the DAO creation that started this has not completed, and thus has yet to be registered w/ the DaoManager).
Looks like this has to do w/ the recursion noted in BaseDaoImpl.initialize().
I'm getting Inception flashbacks just looking at this.
I am trying to create an android application using ORMLite package. I have a few activities and services and also use https://github.com/tomquist/Android-Error-Reporter to be able to receive errors from clients' pdas. ORMLite requires that all activities and services extend OrmLiteBaseActivity etc or add appropriate code to each activity to be able to get database helper and release it after the activity is finished. so this isn't very convenient to add this code to every activity or service. i also have some helper classes which can use database
I also have an application class that holds some global information and methods. So I decided to open ormlite helper in application class and use it through all activities/classes like this:
public class MyApplication extends Application {
private volatile DatabaseHelper databaseHelper = null;
#Override
public void onCreate() {
super.onCreate();
}
#Override
public void onTerminate() {
if (databaseHelper != null) {
OpenHelperManager.releaseHelper();
databaseHelper = null;
}
super.onTerminate();
}
public DatabaseHelper getHelper() {
if (databaseHelper == null) {
databaseHelper = OpenHelperManager.getHelper(this, DatabaseHelper.class);
}
return databaseHelper;
}
}
and use it in other classes this way:
((MyApplication) getApplicationContext()).getHelper();
do you think it is a good idea to use it this way or there can be some memory leaks or other problems with this? My concern is that onTerminate never works on real devices... I am on the stage of "trying new stuff out" so would like to hear any comments about this to eliminate problems I can get in the future with a wrong approach and not having to rewrite the code.
The overall mechanism looks fine #Alex but as far as I know, onTerminate() is only used in emulated environments so doesn't have much use. You program gets killed by the Android OS when it terminates on a real device so there is no reason to be worried about memory leaks and the such.
What is most important with your code is that it guarantees a single databaseHelper instance. Each instance has it's own connection to the database and problems happen when there are more than one (1) connection opened to the database in a program. Sqlite handles multiple threads using the same connection at the same time but it doesn't handle multiple connections well and data inconsistencies may occur.
I was just starting to work on an database application when I realized I should implement MVC pattern as the application is quite complex and involves a number of database operations.
In regards to this, I have decided to create a separate model class for handling database operations. This class will have all methods which will return me the data after executing Sqlite command(Select for instance) OR will simply execute the SQLite command(Delete for instance). But what I want is to separate this class from Database Adapter class, where I open, create and close my database.
Let me put my concept into code :
public class DataModel
{
/*
Private members
*/
// Method to Select data from Student table
public ArrayList<String> FetchStudents (parameter 1)
{
private ArrayList<String> arrStudent;
DatabaseAdapter objDB= new DatabaseAdapter();
objDB.open();
/*
Some code
*/
objDB.close();
return arrStudent
}
//Method to delete record from Student table
public DeleteStudent(parameter 1)
{
DatabaseAdapter objDB= new DatabaseAdapter();
objDB.open();
//Some code
objDB.close();
}
/*
Rest of methods
*/
}
//DatabaseAdapterClass
private static class DatabaseHelper extends SQLiteOpenHelper {
DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
/**
* onCreate method is called for the 1st time when database doesn't exists.
*/
#Override
public void onCreate(SQLiteDatabase db) {
Log.i(TAG, "Creating DataBase: " + CREATE_STUDENT_TABLE);
db.execSQL(CREATE_STUDENT_TABLE);
}
/**
* onUpgrade method is called when database version changes.
*/
#Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
Log.w(TAG, "Upgrading database from version " + oldVersion + " to "
+ newVersion);
}
}
Question:
What I want to ask is this the correct approach of implementation? Is it fine if create separate class for database methods? What limitations or issues you guys think might trouble me later on? Also, is there a better way to implement the above concept?
Thanks
Stone
What you are referring to as a 'model class' is more commonly known as a data access object (DAO). Your model would usually be a set of classes that hold your data and business logic. In you case, probably a Student class having an ID, name, GPA, etc. properties. If you want to separate data access from your model, you would have your data access class (DatabaseHelper) query the database and use the data it gets to return Student objects or a List<Student>. There is really not much point in separating the data access class from the database helper, it is better to have all of your database-related code in one place.
Using model classes (only), however, may not always be practical on Android, because it has native support for getting and displaying data from a Cursor (CursorAdapter, etc.). If you want to use any of that, you would have to expose your data not as model objects but as Cursor's. As for content providers, have a look at those too, but if you don't need to expose your data to other applications, writing a ContentProvider might be overkill.
On another note, you don't want to be opening and closing the database on each query. It is actually safe to leave it open, it will be automatically closed when your app's process dies.
I do this in my application and it works wonderfully, the code is clean and it doesnt impact performance at all, especially with the hardware phones have today. I tried all of the other approaches and even used a content provider but it just over complicated things in my opinion.
android's native approach data modeling is contentproviders. Link
it kind of abstracts the type of data source as well.
i used to do it in a similar way. but again its also subjective.