Android development
12 July 2014Android development is something that I had been meaning to get into for some considerable time, my first attempt being around June last year, but for various reasons did not get much further than installing the development kit. I made a more serious attempt around Christmas & the new-year, but that effort stalled when the solid-state drive in my system corrupted. The last month or so I decided to give it another try, and as it turned out I got further then I had remembered doing, so this time round I managed to actually create something beyond experimentation. Although the choice of Android for my current handset was not influenced by a future intention to program it, unlike with my previous Windows Mobile handset, having a high-end Android handset that I was familiar with removed any reason not to have another crack at writing software for it.
My motive for making this attempt is due to current trends in software development, as it had for some time become obvious that the type of programming I like is now mainly the domain of mobile & embedded devices, and is pretty rare on the desktop these days. In fact the desktop development as whole is becoming mainly DevOps and web development, neither of which I have any special regard for, and systems-level development is something where you usually have to have a decade or so of commercial experience references signed off with blood.
I had considered getting an iPhone 3 back in 2008 as back then the selection of Android handsets basically sucked, but back then iPhone was not available on Vodefone and I was not prepared to mess around with changing phone contracts. By the time this exclusivity had been ended, getting a new handset was off my agenda, and in any case the iPhone was rapidly losing its technological lead. These days the choice between iPhone and the high-end Androids is in large part a philosophical statement with the iPhone being seen as the style-over-substance option. Although I am told the iPhone development kit is a lot better than the Android SDK, the former does suffer from the upfront capital costs of the kit only being avaialble on the iMac. The Google app store is also somewhat more libertarian than the Apple store, and the iPhone is getting a reputation as the domain of people with more concern for fashion than technical knowledge.
However it is cut Android is the market gorilla, and the likes of Palm, Microsoft, & AIM (aka Blackberry) are pancakes behind the streamroller. Apple has the premium market, and Android has everything else. If there is anything that comes even close, it is mobile web development making extensive use of Javascript. There are a lot of mobile apps out there that should really be implemented as mobile websites, but Javascript still has a lot of loose threads, and they don't have quite the same marketing appeal as Google Play or Apple Store.
Android vs. iPhone vs. Windows Mobile
Although Windows Mobile was already a bit dated back in 2009 I opted for the Sony Xperia X1 as my mobile handset, because I saw Windows Mobile 6.x as a reasonably stable API that was also reinforced by its similarity to the desktop Win32 API. With Windows Mobile 7, which from reliable information sources was modelled on .NET rather than Win32, all this familiarity was thrown away. I took the view that if learning a new API from scratch was the order of the day, then the decision of which API to learn became a non-technical decision based on market penetration. Far as I was concerned, Windows Mobile had sunk without trace long before I decided to get my current Android handset. Although I had fairly extensive experience with WindowsCE, including some commercial development, Windows Mobile development is as good as dead as far as I am concerned.
Getting started with Android
Fixing up an Android development environment is disproportionately tricky, taking far more time than either Windows Mobile or even JavaME ever did, and as a result proved to be more frustrating than usual. My previous attempt was on the verge of ending in frustration when externalities put an end to it, resulting in me forgetting how far I managed to get, but a lot of it all came back surprisingly quickly on this attempt. In hindsight I think it was not possible to get into Android development from scratch in one go, so the break was needed.
What about Xamarin Studio
I have come across Xamarin Studio due to its relationship with MonoDevelop, and certainly on the surface it looks very attractive: Cross-device and uses C# rather than Java. Although a commercial application they did provide a trial version, and I obtained a registration key. As it happened I never used this key, even though I did install Xamarin Studio onto my laptop.
At the time I was still somewhat adverse to GUI meta-programming via XML, but it became clear that a large part of Android programming would be such XML GUI work, with the differences between Xamarin and the Android SDK accounting for only a small portion of the actual effort. Without access to an iPhone and/or a Windows Phone in addition to an Android trying out Xamarin Forms (the cross-device GUI) is not really worthwhile, and given that the main effort would be learning Android concepts, I decided Xamarin's annoyances were not worth its attractions.
The Eclipse headaches
My single biggest gripe about Android's tutorials (and Android-related materiel in general) is they as a general rule assume you are using Eclipse, which is a piece of software I have crossed paths a few times in the past, and on every occasion found its usability to be somewhat marginal. Eclipse reportedly automatically handles import statements for you, so very frustratingly almost no code snippet deals with the pile of dependencies required. As a result until you locate the API index of all classes, which was a bit harder to find that it should have been, you will soon run into the brick wall of missing references due to lack of imports.Emulators
Although I get the (possibly false) impression that Android emulation has improved a lot relatively recently, there are nevertheless a lot of emulation options (phone model, architecture, skin, etc) that have less-than-straightforward bearing on whether the end result are full speed or painfully slow. Even with speed aside, emulation always seems to bring with it various gotchas, such as less tolerance for not doing things quite right. I did try Android x86 which runs reasonably fast in a VirtualBox VM and seemed to be easier to get up and running, but it is far from a turn-key solution.However things are cut, getting emulation working in a way bearable for actual development is in itself a non-trivial task, so resign yourself to using actual hardware for the entire development of your first program or two. Learning the quirks of Android is hard enough without the additional headacahe of less-than -ideal emulation, with add-ons such as Google Maps being particularly hit-and-miss under emulation. If you've not actually got an Android device, forget it - learning the ins-and-outs of Android GUIs is not something to do in parallel with learning how to program them. Mouse control is often a frustratingly poor emulation of touch support, which doesn't help.
Since most Android development uses a custom version of Java, whether your emulator uses ARM or ix86 should not really matter, as Java's runtime sort all of that out. This is a good thing as in these days of hardware-supported visualisation the latter will be a lot quicker. While not quite as fast as an actual device, emulation using ix86 certainly is sufficiently fast that it is not in itself an annoyance. I always feel that bit jumpy of repeatedly uploading new binaries to my mobile just to see them crash, so once I got to grips with Android development and got round to getting a decent emulator setup, I tended to do most work using it.
Android API targeting
Android provides backward compatibility by providing support libraries that implement new features for previous releases of the Android API. The most recent feature additions were in API 13 (the last of three Honeycomb releases), which was fragment support. I decided I did not want to mess around with any of these support libraries, as the 20% market share pre-13 devices have is in rapid decline. Most of this 20% is API 9-10 (aka Gingerbread) devices which I think Google Play (the Android app market) does not support anyway. Android developer guidelines consider using the support libraries as good practice, but I foresee them being of footnote relevance by the time I actually release a production Android app. The Android manifests list both a minimum and a target API, which allows for various compatibility hacks to kick in if an app was developed & tested using an earlier version of the Android API, but given that I am developing & testing on the latest production API version this setting is of little relevance. I suspect such hacks are mostly the domain of API versions predating the most recent support library anyway.Android development proper
Native development (i.e. via C & C++) is somewhat discouraged, and given that it would involve the speed penalty of not using an ix86 emulator, I am inclined to go along with this advice. It seems the NDK is geared towards having only components of an app written in native code, either via JNI native library access, or via natively implemented activities. On high-end Android devices I am inclined to believe that native development is not worth the effort, with today's high-end being tomorrow's mid-range and then next-week's low-end. Pedal-to-the-metal hooking into OpenGL ES is well of my radar. The way Android splits things up into Activities that communicate via Intents feels not that far off some multi-process programming methodologies I have come across in the past, although it does take quite a while to get to grips with all the concepts.Mobile Java
I remember using Java ME (Mobile Edition) circa 2004, and together with Eclipse it struck me as something that was impractical for real usage. At the time this was due to very pessimistic (albeit justifiably) assumptions about what could be done, and this was on top of other problems Java had. My biggest complaints about Java in the past was an obviously slow run-time system and the Java interface libraries, and because of this it is a good thing that Android decided to blow both away. Android uses a custom-made Java run-time called Dalvic, and an entirely mobile-optimised standard library that is actually built for mobile devices. Although I still think C# is a better language overall, with C# properties in particular being missed, Android Java has taken on board some lessons such as doing away with a dearth of checked exceptions. Of all ironies the preferred use of the Java language on Android seems to be one of the few places that has not been negatively affected by Oracle suing Google over it, and apart from the.java extension, the Android SDK documentation seems to shy away from using the word ‘Java’.
Going back to Java having used Python and C# revealed some idiosyncrasies with the former which I found rather annoying. One is the multitude of different ways of getting an item count from something such as an array, which dependent on object type makes use of size(), length (a variable), and length() (a function). More annoying is headaches caused by Java making the use of this optional, whereas the Python equivalent of self is mandatory, avoiding variable shadowing problems. Java also has a thing for somewhat deep directory hierarchies to mirror package paths, as well as lots of long class names that get annoying very quickly without some form of auto-completion. Sometimes I wish I could just do something like import *.*.* to avoid missing references. To be fair it had been a long time since I last used Java properly, and some of these gripes are not unique to Java.