Part VII
Alternative Application Environments
Chapter 44
The Role of Alternative Environments
You might think that Android is all about Java. The official Android Software Development Kit (SDK) is for Java development, the build tools are for Java development, the Android discussion groups and blog posts are all about Java, and, yes, most Android books are for Java development. Heck, most of this book is about Java.
However (and with apologies to William Goldman), it just so happens that Android is only mostly Java. There's a big difference between mostly Java and all Java. Mostly Java is slightly not Java.
So, while Android's “sweet spot” will remain Java-based applications for the near term, you can still create applications using other technologies. This chapter and the three that follow introduce some of those alternative technologies.
This chapter starts with an examination of the pros and cons of Android's Java-centric strategy. It then enumerates some reasons why you might want to use something else for your Android applications. The downsides of alternative Android application environments—lack of support and technical challenges—are also discussed.
In the Beginning, There Was Java...
The core Android team made a fairly reasonable choice of language when they chose Java. It is a very popular language, and in the mobile community it had a clear predecessor in Java 2 Platform, Micro Edition (J2ME). Lacking direct access to memory addresses (so-called pointers), a Java-based application will be less prone to developer errors that might lead to buffer overruns and expose the application to possible hacks. And there is a fairly robust ecosystem around Java, in terms of educational materials, existing code bases, integrated development environments (IDEs), and so on.
However, while you can program Android in the Java language, an Android device does not run a Java application. Instead, your Java code is converted into something that runs on the Dalvik virtual machine. This is akin to the technology used for regular Java applications, but Dalvik is specifically tuned for Android's environment. Moreover, it limits the dependency of Android on Java itself to a handful of programming tools, which is important as Java's stewardship moves from Sun to Oracle to wherever.
The Dalvik virtual machine is also capable of running code from other programming languages, a feature that makes possible much of what this book covers.
...And It Was OK
No mobile development environment is perfect, and the combination of Java and Android is no exception.
In the beginning, Java, as implemented for the Dalvik virtual machine, was interpreted, without any of the just-in-time (JIT) compiler tricks regular Java uses to boost performance. This is a bigger problem in mobile, since the devices Android runs on tend to be less powerful than your average desktop, notebook, or web server. Android 2.3 added a JIT compiler, which helps a lot, but it is still slow compared to native compiled code. Hence, there will be some things you just can't do on Android with Java because it is too slow.
Java uses garbage collection to save people from having to keep track of all their memory allocations. That works for the most part, and is generally a boon to developer productivity. However, it is not a cure-all for every memory and resource allocation problem. You can still have what amounts to “memory leaks” in Java, even if the precise mechanics of those leaks differ from the classic leaks you get in C, C++, and other languages.
Most importantly, though, not everybody likes Java. It could be because they lack experience with it, or perhaps they have had experience with it and did not enjoy that experience. Certainly, Java is often seen as a language for big enterprise systems and, therefore, not necessarily “cool.” Advocates of other languages will have their own pet peeves with Java as well (e.g., to a Ruby developer, Java is really verbose).
So, while Java was not a bad choice for Android, it was not perfect, either.
Bucking the Trend
Just because Java is the dominant way to build apps for Android, that does not mean it is the only way, and for you, it may not even be the best way.
Perhaps Java is not in your existing skill set. You might be a web developer, more comfortable with HTML, CSS, and JavaScript. There are frameworks to help you with that. Or, maybe you cut your teeth on server-side scripting languages like Perl or Python—there are ways to sling that code on Android as well. Or perhaps you already have a bunch of code in C/C++, such as game physics algorithms, that would be painful to rewrite in Java. You should be able to reuse that code, too.
Even if you would be willing to learn Java, it may be that your inexperience with Java and the Android APIs will just slow you down. You might be able to get something built much more quickly with another framework, even if you wind up replacing it with a Java-based implementation in the future. Rapid development and prototyping is frequently important, to get early feedback with minimal investment in time.
And, of course, you might just find Java programming to be irritating. You would not be the first, nor the last, to have that sentiment. If you are getting into Android as a hobby, rather than as part of your “day job,” having fun will be particularly important to you, and you might not find Java to be much fun.
Fortunately, Android is friendly toward alternative ways of building applications, unlike some mobile platforms.
Support, Structure
However, “friendly” and “fully supported” are two different things. Some alternatives to Java-based development are officially supported by the core Android team, such as C/C++ development via the Native Development Kit (NDK) and web-style development via HTML5. Some alternatives to Java-based development are supported by companies. Adobe supports the Adobe Integrated Runtime (AIR), and recently also acquired Nitobi, famous for their support of PhoneGap (described in detail in Chapter 46), Rhomobile supports Rhodes, and so on. Other alternatives are supported by standards bodies. For example, the World Wide Web Consortium (W3C) supports HTML5. Still others are just tiny projects with the backing of only a couple of developers.
You will need to make the decision for yourself which of these levels of support will meet your requirements. For many development activities, support is not much of an issue, but in some cases, support might be paramount (e.g., enterprise application development).
Caveat Developer
Of course, going outside the traditional Java environment for Android development has its issues, beyond just how much support might be available.
Some environments may be less efficient, in terms of processor time, memory, or battery life, than Java. C/C++, on the whole, is probably better than Java, but HTML5 may be worse, for example. Depending on what you are writing and how heavily it will be used will determine how critical that inefficiency will be.
Some environments may not be available on all devices. Right now, Flash is the best example of this; some devices offer some amount of Flash support, while other devices have no Flash support at all. Similarly, HTML5 support was added to Android only as of Android 2.0, so devices running older versions of Android do not have HTML5 as abuilt-in option.
Every layer between you and officially supported environments makes it that much more difficult for you to ensure compatibility with new versions of Android, when they arise. For example, if you create an application using PhoneGap, and a new Android version becomes available, there may be incompatibilities that only the PhoneGap team can address. While they will probably address those quickly—and they may provide to you some measure of insulation from those incompatibilities—the response time is outside of your control. In some cases, that is not a problem, but in other cases, that might be bad for your project.
Hence, just because you are developing outside of Java does not mean everything is perfect. You simply have to trade off between these problems and the ones Java-based development might cause you. Where the balance lies is up to each individual developer or firm.