Pure Java DB implementation

@Noisyfox What are you passing as android.content.Context implementation when creating subclass of SQLiteOpenHelper? There is a android.content.ContextImpl in MOE, though it is using MOE_TMP_DIR env variable as a source for the base path for the database location and I’m not sure if that’s a good idea or even what it resolves to on iOS device.

For my app document storage I’m usually using something like this:

NSFileManager fileManager = NSFileManager.defaultManager();

NSArray<? extends NSURL> urls = fileManager.URLsForDirectoryInDomains( //
    NSSearchPathDirectory.DocumentDirectory, //
NSURL url = urls.firstObject();
String baseDir = url.fileSystemRepresentation();

For the constructor public SQLiteOpenHelper(Context context, String name, CursorFactory factory, int version)
Pass an new ContextImpl() as the context arg, then a absolute path to the db file as the name arg. Remaining args are the same as Android:

// initialise the databases in the document directory
NSArray nsa = NSFileManager.defaultManager().URLsForDirectoryInDomains( NSSearchPathDirectory.DocumentDirectory, NSSearchPathDomainMask.UserDomainMask );
NSURL nsu = ( NSURL ) nsa.firstObject();
File dbFile = new File( nsu.path(), "xxxxx.db" );

SQLiteOpenHelper helper = new SQLiteOpenHelper( new ContextImpl(), dbFile.getAbsolutePath(), null, 1 );

Thank you… I still wondering why the difference from Android.
Can’t step trough in debugger on a real device - install from Eclipse and MOE 1.3.8 hangs at 40% on verifying app when doing it on device…

See the code here:

Thanks for the reference to git repo.
It seem like directory depends env variable MOE_TMP_DIR if path doesn’t start with “/”.
The env variable is set at:

All in all, it seem unavoidable to use full path on iOS as you suggested.