4 ms·

The part of cross-platform mobile dev that increasingly drives me insane is duplicating the persistent data model code across platforms. I'd be very interested

The part of cross-platform mobile dev that increasingly drives me insane is duplicating the persistent data model code across platforms. I'd be very interested if the Inbox people can share how they approached this (hint!). Generally the SQLite approach feels quite lowest common denominator, mainly because on Android the SQLite wrapper is so clunky. Get over that and you're into raw files territory, which has made me consider things like building LevelDB for bundling in.

terhechte 12y ago
What about Realm (http://realm.io/ http://realm.io/)? I've only briefly touched it, but I've heard good stuff about it. I wouldn't know how easy it is to access it from Java for cross-platform development, but at least there's full iOS & Android support.
julianpye 12y ago
The way how I do this is by having written a code-generator that takes a simple YAML like file with a data model description and generates SQL models/NOSQL models for backend storage, POJO access code to that and POJO access for a rest API; then an angular backend that accesses the api and locally stores it and directives to display it; then an android sqlite local database wrapped in a content provider to access it, async task helpers to retrieve the content via sync providers and adapters to display them. I haven't yet started with iOS. Any wellfunctioning code that I have written I pack into my content generator and give access to via the YAML. The whole thing has gotten really ugly and desperately needs refactoring (it's in Perl and I am rewriting it in Stringtemplate) but it does help me with: - the changes in the model that cascade down the frontends - fixing a bug in one application that needs fixing in several others - the fact that multi-platform model really is stressful since the brain needs to switch rapidly between different languages and platform APIs and this allows me to write code once and perpetuate data model changes on to all platforms. So I think, take code of yours that works and wrap a codegenerator around it. It's better than using a framework where you don't know what's underneath. All the code is something you know and built.
- fidotron 12y ago
  I've considered extending protocol buffers to do it. If you already have protobufs for on the wire (it tends to be what I use) then it should be possible to auto-generate a schema and all the code for keeping the same data inside a DB. Have annotations in the proto files which do things like hint about primary keys, indexing etc.
kyrra 12y ago
How Google Inbox does it: Java and GWT There was a presentation at GWTCreate where Ray Cromwell laid out some of the magic on how they used GWT to handle this. The slides for the talk are here[0]. One of the key pieces here is that coding in Java gets you the web (with GWT), Android, and iOS using j2objc[1]. They posted a demo app showing this off[2]. The videos aren't up for the talks yet, but the Keynote from GWTCreate is posted (Ray gave that talk as well)[3]. [0] http://goo.gl/5zNFEm http://goo.gl/5zNFEm [1] https://github.com/google/j2objc https://github.com/google/j2objc [2] https://github.com/Sfeir/jhybrid https://github.com/Sfeir/jhybrid [3] http://gwtcreate.com/videos/ http://gwtcreate.com/videos/
- Tobu 12y ago
  The cross-compilation stuff is already addressed in the article. The jhybrid demo is a calculator and doesn't do storage.
dweis 12y ago
We use LevelDB.
72deluxe 12y ago
I never found the Android SQLite interface to be too clunky unless you try to use the helper functions. I always just used SQLiteDatabase.rawQuery() - what did you use? All the helper functions felt like the ODBC abstractions that used to be all the rage, where you ended up typing 400x more code to abstract it than just writing some SQL.
Zigurd 12y ago
> mainly because on Android the SQLite wrapper is so clunky Go straight for a ContentProvider, even if you are not sharing access to the data in SQLite. That makes it easier to build an observer pattern in Android. You can then build a SyncAdapter on the "back side" of this ContentProvider. Et voila, a synch'ed app.

terhechte 12y ago

What about Realm (http://realm.io/ http://realm.io/)? I've only briefly touched it, but I've heard good stuff about it. I wouldn't know how easy it is to access it from Java for cross-platform development, but at least there's full iOS & Android support.

julianpye 12y ago

The way how I do this is by having written a code-generator that takes a simple YAML like file with a data model description and generates SQL models/NOSQL models for backend storage, POJO access code to that and POJO access for a rest API; then an angular backend that accesses the api and locally stores it and directives to display it; then an android sqlite local database wrapped in a content provider to access it, async task helpers to retrieve the content via sync providers and adapters to display them. I haven't yet started with iOS. Any wellfunctioning code that I have written I pack into my content generator and give access to via the YAML. The whole thing has gotten really ugly and desperately needs refactoring (it's in Perl and I am rewriting it in Stringtemplate) but it does help me with: - the changes in the model that cascade down the frontends - fixing a bug in one application that needs fixing in several others - the fact that multi-platform model really is stressful since the brain needs to switch rapidly between different languages and platform APIs and this allows me to write code once and perpetuate data model changes on to all platforms. So I think, take code of yours that works and wrap a codegenerator around it. It's better than using a framework where you don't know what's underneath. All the code is something you know and built.

fidotron 12y ago
I've considered extending protocol buffers to do it. If you already have protobufs for on the wire (it tends to be what I use) then it should be possible to auto-generate a schema and all the code for keeping the same data inside a DB. Have annotations in the proto files which do things like hint about primary keys, indexing etc.

kyrra 12y ago

How Google Inbox does it: Java and GWT There was a presentation at GWTCreate where Ray Cromwell laid out some of the magic on how they used GWT to handle this. The slides for the talk are here[0]. One of the key pieces here is that coding in Java gets you the web (with GWT), Android, and iOS using j2objc[1]. They posted a demo app showing this off[2]. The videos aren't up for the talks yet, but the Keynote from GWTCreate is posted (Ray gave that talk as well)[3]. [0] http://goo.gl/5zNFEm http://goo.gl/5zNFEm [1] https://github.com/google/j2objc https://github.com/google/j2objc [2] https://github.com/Sfeir/jhybrid https://github.com/Sfeir/jhybrid [3] http://gwtcreate.com/videos/ http://gwtcreate.com/videos/

Tobu 12y ago
The cross-compilation stuff is already addressed in the article. The jhybrid demo is a calculator and doesn't do storage.

dweis 12y ago

We use LevelDB.

72deluxe 12y ago

I never found the Android SQLite interface to be too clunky unless you try to use the helper functions. I always just used SQLiteDatabase.rawQuery() - what did you use? All the helper functions felt like the ODBC abstractions that used to be all the rage, where you ended up typing 400x more code to abstract it than just writing some SQL.

Zigurd 12y ago

> mainly because on Android the SQLite wrapper is so clunky Go straight for a ContentProvider, even if you are not sharing access to the data in SQLite. That makes it easier to build an observer pattern in Android. You can then build a SyncAdapter on the "back side" of this ContentProvider. Et voila, a synch'ed app.