The Open Remote Android Console

Check out the Android Console we did for OpenRemote. They had an existing iPhone app. The Android console is designed to be compatible.

Key highlights:

• SVN browse the source
• The manifest requires INTERNET permission and specifies a modified "theme" which forces absolute black (compatibility with iphone app) which is defined here and "black" is defined here.
• Strings are externalized to be nice and internationalization friendly
• This stuff is out of the android kit to handle the animated transitions when you "glide" your finger across the screen
• In order to read the iphone.xml and get usable objects, I've got a moronically simplistic XML-object binding implementation in one class. There is no jaxb in Android and besides that sucking down all of jaxb for one xml file would be large and large is bad for cellphones (esp with a default 1gb sd card)
• The OpenRemote iphone.xml schema objects are bound to the Java Objects here. There are interfaces in the event you don't want say "Activity" to conflict with Android activity which are prefixed ORActivity for instance.
• All button presses get delegated to a simple utility class that calls HttpClient and returns an error code.
• Juha thought I was showing off, but all images are loaded in a separate thread. I also populate the buttons in that thread. This was mainly because I was testing on a slow network and kept getting "not responsive" error messages when loading in the same thread. It even caches the images for easy finger play. The populating bit is a little overkill but when the network connection was slow it profiled to make a decent difference.
• When you first start the app, you're directed to a ConfigureActivity which sets preferences namely the url it can find your iphone.xml at. You also end up there for any error reading the iphone.xml with a big red error.
• The Main activity drives the initial read of iphone.xml or redirect to ConfigureActivity (above), then draws the list of "activities" like "watch tv" or "deal with the lights". If you select an activity it delegates to the ActivityHandler (below) passing the objects bound from the iphone.xml.
• The ActivityHandler does most of the work. It renders the screens, detects finger gestures, lays out the images.

Some key methods:

• ActivityHandler.constructScreen - this crazy absolute layout is basically "iphone default layout emulator". Juha@OpenRemote gave us an iphone.xml with the various features and we made it layout as closely as possible to the iphone version. This precluded using Android XML for much. This also meant using Absolute Layout since the table layout doesn't work like the iphone (controls must respect their bounds). We also do some "should this be an imagebutton or just an image?" decisions based on the size.
• To capture gestures the ActivityHandler implements OnGestureListener, the ActivityHandler.onFling method and ActivityHandler.moveRight,ActivityHandler.moveLeft work with the ViewFlipper containing the screens.
• The Main.onCreate(){onItemClick()} passes the selected activity to the ActivityHandler in an "intent" for this reason the bound objects from iphone.xml have to be Serializable.

Overall it is a pretty simple UI, all the hard parts were making it work like the iPhone version, simulating the layout, etc. I was pleased with the response, it quickly became the talk of the Twittersphere (@acoliver). The OR guys seemed enthusiastic for the Android platform. It really is a more developer-friendly platform for sure. Apple is kind of abusive (force you to develop on a mac, you can't do scripting, or this or that).