AndroidOrm

== The Android ORM Project

This is the example project(s) for my http://andevcon.com[AnDevCon 2014] talk on http://tsn2.bzmedia.com/tradeshows/classinfo.aspx?id=19446&showid=34[not using Content Providers].

---

Obsolete Warning - Android now provides the Room (the name is cute, and could stand for Relational Object Oriented Mapper) ORM tool. Room is now Google's offically-recommended way of doing database work in Android.

---

Having worked with JPA and Hibernate for years, I was a bit, um, "surprised" by the design of Android's "ContentValues" and "ContentProvider" wherein everything is reduced to mush, or at least hash, before it can be processed. So I undertook this little study.

The goal is to save a "Person" object, which may be a subclass called Customer, and may or may not have an Address object associated with it, and read it back in again.

The first half of each project is in CommonCode, which provides JPA-annotated entities and a "Signup" name-and-address form. When you submit the form, it passes the Person object on to an ORM-specific SavingActivity, which is expected to do the technology-specific "save the Person to sqlite" action, and display "success".

=== Technologies

Here is the list of Android ORM technologies found so far:

include::Table.adoc[]

=== Research Goals

I started this looking for a "small, simple, lightweight but powerful" (everybody's favorite conflicting needs, right) Java ORM for Android. Would settle on an ActiveRecord implementation if it otherwise met the criteria. As a bare minimum it would have to support relationships (Person" has-a Address) and at least one level of inheritance ("Customer is-a Person"; ideally, "save this object without being told which it is").

=== To Add A New Technology Demo

The goal is to use a singular main activity (++EntryActivity++), and have it pass control to a tech-specific ++SavingActivity++ to save the Person. Because of difficulties using a single Person class, Person became an Interface. The implementation name of the +SavingActivity+ as well as any domain-specific Domain implementatiions must be listed in the androidorm.properties file; see the examples.

The Main activity's class name must be listed in your AndroidManifest, and the target-specific "save and display" must be listed in a Java Properties file. In more detail:

. Clone this entire project if you didn't already. . copy the entire TemplateTech project to a new project, named after your technology (use the names below if implementing one of these?). . UPDATE THE README FILE to give an idea what it's about . Change the package name from "templatereceiver" to your ORM's name (lower case) . Make the corresponding change in androidorm.properties . Make the corresponding change in AndroidManifest.xml . Add your technology's JAR files into libs/ . Write the "saving" code at the first XXX, and the "read back" at the second, in SavingActivity. Note that for threading reasons, all this has to be done in a background thread, but the updating of the UI has to be done on the UI thread; please respect the overall structure that is set up here. . For clarity, "grep -ri templatereceiver" should not find anything! . Now you can try compiling, either with Eclipse ADT or with Maven.

Please DO NOT:

. Go changing any other config files; Android build is kinda sensitive to changes, and we have it working such that TemplateTech's main activity is coming from the library project, it passes control to SavingActivity, and it "just works" as it stands. . Tart up the UI in SavingActivity; it's just a POC, don't waste your time on frills.

If you want to build build with Maven, Gradle, etc., there is a POM file in the CommonCode project if you want to go that route; just do +mvn install+ and depend on it (batoo-jpa is done this way).

When it works, commit it, and send me a pull request!