Question

Some people want to port my Android open-source software to Blackberry and PC (also using SQLite).

I separated the UI code from the domain/database code. But next problem, the domain/database code contains imports like this one:

import android.database.Cursor;

… which makes it not portable.

I guess many other developers have the same problem, so an SQLite OS-abstraction layer must exist somewhere. What would you suggest?

Note: I use SQLite-specific features, so an ORM or a database abstraction layer will not do.

Answer 1

I am currently developing an ORM project, especially for Android.

https://github.com/ahmetalpbalkan/orman

Which SQLite-specific features do you use?

Maybe you can create an interface, compile it with both android.jar and the_jar_for_blackberry.jar so that you can do something like in the code

Database db = null;    
if (environment is android){
    db = new AndroidSQLiteDatabaseImpl();
} else {
    db = new MyBlackberrySQLiteImpl();
}

and when both classes implement the same interface, then you won’t be in the trouble. Because if you say

import android.database.Cursor

only in AndroidSQLiteDatabaseImpl.java and if you don’t initialize it at all, no exceptions will be thrown.

You can look at source code of our project. At build-time, we compile it with android.jar however, when we ship only a single jar file, all desktop program users can use it for MySQL and native SQLite. Because they don’t initialize AndroidSQLiteDtabase class and no exceptions will be thrown.