Pure Java DB implementation

Support
1

Can anyone recommend a good pure Java BD in order to keep all model and data layers inside the common module?

2

Try H2, it is pretty good.

3

thanks, H2 was on my list. I’m just wondering if integrating it into MOE is possible as I haven’t read of anyone using it.
I read on some hack (bridging the iOS version) to use realmDB which is my current DB , but I’d like to use native android as much as possible.

4

Hi,

I would advise against a pure Java DB in mobile environments, when there are alternatives.

  1. Sqlite

    Sqlite is present on both Android and iOS. I think, we had a sample in the old days, where we used Sqlite on both Android and iOS with the same Java API. It looks like it is not in the samples repo, but it would make sense to offer a common Sqlite API for Android and iOS. The best option here would be to get the Android Sqlite API running on MOE, so the Android Database API would be available on iOS as well, thus you could use it in the common module.

  2. RealmDB

    You mentioned, that you already use Realm. The core of Realm is a C++ library on every platform. I already recommended it in an earlier topic about Realm: you just need to get their JNI bindings to compile on MOE (and it seems some minor Android -> MOE porting will be also required), and you can use the same Realm Java API on Android and iOS. No need to use Nat/J based bindings in this case. See my earlier answer in that topic: Using Realm on MOE

    Other members of the community used the Nat/J Generator to successfully generate Java bindings to the Objective-C API of Realm. It is a functional approach, but not what you need, because in this case you will have 2 Java APIs.

Best Regards,
Gergely

5

Gergely

Can you elaborate on why you would suggest not using a pure java db, such as H2 or Hsqldb? Is it due to a technical reason or is it perhaps due to a native implementation being optimized more?

6

Thanks a lot for the quick reply. I’m afraid I’m not proficient enough in MOE to port anything yet.

I’m actually just evaluating MOE as a platform for future projects and having the business logic and data layer completely in Java for both platforms was a huge plus. I haven’t found many examples of DB apps using MOE though (the one in the tutorial looks really dated). Any tips for a MOE newbie?

7

Hi Juan - I agree with Gergely that SQLite is a better option than H2, as the database is more robust, performs great, have advanced features (ex: JSON support), evolves constantly, is fully extensible… In order to use SQLite on MOE, you have to compile the code and provide a JNI or JNA interface to the C functions.
We have done this work as part of our commercial platform “Darwino”. We have SQLite working on iOS with MOE, Android and even laptop/desktop OS with the regular JRE (MacOS, Windows…). Finally, we also integrated SQLCipher to get the DB encrypted.
As I said, this is part of a commercial platform but, if you’re interested by the database piece, please drop me a note at [email protected]

8

As @kisg said, MOE has build in sqlite support with the same API as on android. If you are looking for SQLiteOpenHelper in MOE, just simply copy the source code from AOSP and you don’t even have to change much of its code – MOE has build in stub classes like android.content.Context. I use this trick in company’s project and it works perfectly.

9

I’m a little confused. Is SQLite support part of MOE or do we need to compile SQLite source as part of our project?

10

MOE is more like bring the entire android framework to the iOS so is contains the SQLite just like the android does.

11

Hi,

Just to clarify a little bit what @Noisyfox wrote to manage expectations :slight_smile:

MOE is based on Android ART and the Android runtime library, but it only includes a very small subset of the Android specific APIs. The Sqlite binding is one of those few APIs. The higher level APIs like view system, sensor access or intents / Binder based messaging is not available in MOE.

Instead, native APIs for iOS are provided through the Nat/J bindings.

Best Regards,
Gergely

12

Hey Phillipe, I wrote you some weeks ago, let me know if you have some time to talk.

13

Hey Juan - Sorry I missed the post earlier this week
We can surely talk - Please drop me an email [email protected] or [email protected]. Then we can set up a call.

14

Hello @Noisyfox

I need SQLiteOpenHelper to port a project, so I did went to AOSP and copied the source code of it. Then I noticed that the SQLiteDatabase from moe-core does not provide OpenParams and some other things from the SQLiteDatabase of AOSP.

After that I basic copied the android.database.sqlite from moe-core to my project and started editing and adding things that I needed. The problem is that when I go use this custom version I modified, I get errors on native calls. For example:

No implementation found for long custom.android.database.sqlite.SQLiteConnection.nativeOpen(...

I don’t understand how the native calls and bindings are done by moe-core, or how add new ones to it. Have you been to a situation similar to that?

15

Remember MOE is based on android 6, so you should copy the code of SQLiteOpenHelper from android 6 source which does not use OpenParams and other things missing from MOE.
You can find it here. Our company uses exactly what I said here and it works fine so far without any problem.

16

oh… That makes sense now. Thanks for the info!

17

Hi Levino!

In my project I did not like to think to build more dependencies on android. I thought: “It’ll be cooler to be as close to pure java, instead of having dependencies on Android AND iOS at the same time”. So I only use platform dependent SQLite3 connections by using SQLdroid on android and ios and passing the opened driver connection down to the core-module of the app. This way I can also test the integrity of the database with pure java while staying on my development host-machine.

In my core module I can then easly just use the default SQLite classes of java. In my initializing code on the platforms I just had to select the correct db driver then:

on iOS it would look something like this:

DriverManager.registerDriver((Driver) Class.forName("org.sqldroid.SQLDroidDriver").newInstance());
NSArray<String> paths = Foundation.NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory.DocumentDirectory, NSSearchPathDomainMask.UserDomainMask, true);
String documentsDirectory = paths.get(0);
String url = "jdbc:sqldroid:" + documentsDirectory+"/database.db";
connection = DriverManager.getConnection(url);

on Android it would look like this:

DriverManager.registerDriver((Driver) Class.forName("org.sqldroid.SQLDroidDriver").newInstance());
String url = "jdbc:sqldroid:" + context.getFilesDir().getPath() + "/database.db"
connection = DriverManager.getConnection(url);

When you reform it to make it a bit more abstract you then can just pass the connection instance to your database service.

And when you test on your local machine you are also able to use:

// register your db driver
Class.forName("org.sqlite.JDBC");
String url = "jdbc:sqlite:database.db";

… and so on.

Hope this helps a bit!

2 Likes
18

I’m running MOE 1.3.8 (a 1.3.12 of moe gradle plugin) and this version of SQLiteOpenHelper class is chocking on Context.openOrCreateDatabase method:

The method openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory, DatabaseErrorHandler) is undefined for the type Context

Any idea what’s the issue?

19
20

Makes sense! Thanks a lot.