Editors note: This is the second in a two-part series of articles on the basic features and capabilities common to all Android platforms, excerpted from the authors' book The Android Developer’s Cookbook.
Three elements are needed for an excellent application: a good idea, good coding, and good design. Often, the last element is paid the least attention because most developers work alone and are not graphic designers.
Google must realize this because it has created a set of design guidelines: icon design, App Widget design, activity and task design, and menu design.
Good design cannot be stressed enough. It sets an application apart, improves user adoption, and builds user appreciation. Some of the most successful apps on the Market are a result of the collaboration between a developer and graphic designer.A significant portion of an app’s development time should be dedicated to considering the best design for an app.
Maintaining Forward Compatibility
New Android versions are generally additive and forward compatible at the API level. In fact, a device can be called an Android device only if it passes compatibly tests with the Android APIs. However, if an application makes changes to the underlying system, compatibility is not guaranteed.To ensure forward compatibility of an application when future Android updates are installed on devices, follow these rules suggested by Google:
- Do not use internal or unsupported APIs.
- Do not directly manipulate settings without asking the user.A future release might constrain settings for security reasons. For instance, it used to be possible for an app to turn on GPS or data roaming by itself, but this is no longer allowed.
- Do not go overboard with layouts.This is rare, but complicated layouts (more than 10 deep or 30 total) can cause crashes.
- Do not make bad hardware assumptions. Not all Android devices have all possible supported hardware. Be sure to check for the hardware needed, and if it does not exist, handle the exception.
- Ensure device orientations do not disrupt the application or result in unpredictable behavior.
Note that backward compatibility is not guaranteed with Android. It is best to declare the minimum SDK version so the device can load the proper compatibility settings.
In the same vein as compatibility support, applications should be designed and tested for robustness. Following are a few tips to help ensure robustness:
- Use the Android libraries before Java libraries.Android libraries are constructed specifically for embedded devices and cover many of the requirements needed in an application. For the other cases, Java libraries are included. However, for cases where either can be used, the Android library is best.
- Take care of memory allocation. Initialize variables.Try to reuse objects rather than reallocate.This speeds up application execution and avoids excessive use of garbage collection. Memory allocations can be tracked using the Dalvik Debug Monitor Server (DDMS) tool
- Utilize the LogCat tool for debugging and check for warnings or errors.
- Test thoroughly, including different environments and devices if possible.
Using Android’s Software Development Kit
The Android SDK is comprised of the platform, tools, sample code, and documentation needed to develop Android applications. It is built as an add-on to the Java Development Kit and has an integrated plugin for the Eclipse Integrated Development Environment.
There are many places on the Internet that discuss detailed step-by-step instructions on how to install the Android SDK. For example, all the necessary links can be found on the Google website . Therefore, the general procedure outlined here serves to emphasize the most common installation steps for reference.These steps should be done on a host computer used as the development environment and include:
- Install the Java Development Kit (for example, install JDK 6.0 for use with Android 2.1 or above; JDK 5.0 is the minimum version needed for any earlier version of Android).
- Install Eclipse Classic (for example, version 3.5.2). In the case of Windows, this just needs to be unzipped in place and is ready to use.
- Install the Android SDK starter package (for example, version r06). In the case of Windows, this just needs to be unzipped in place and is ready to use.
- Start Eclipse and select Help – Install New Software…, and then type https:// dl-ssl.google.com/android/eclipse/ and install the Android DDMS and Android Development Tools.
- In Eclipse, select Window – Preferences and select Android. Browse to the location where the SDK was unzipped and apply.
- In Eclipse, select Window – Android SDK and AVD Manager – Available Packages, and then choose the necessary APIs to install
- From the same Android SDK and AVD Manager menu, create an Android virtual device to run the emulator or install USB drivers to run applications on a plugged in phone.
- In Eclipse, select Run – Run Configurations and create a new run configuration to be used with each Android application (or similar for a Debug Configuration). Android JUnit tests can be configured here, too.
Now, the environment should be configured to easily develop any Android application and run on the emulator or an actual Android device.To upgrade to a new version of the SDK, it is simply a matter of selecting Help ➞ Software Updates… in Eclipse and choosing the appropriate version.
Software Features and API Level
The Android OS periodically rolls out new features, enhancements such as improved efficiency, and bug fixes.A main driver in OS improvement is the increased capability of hardware on new devices. In fact, major releases of the OS are generally coordinated with new hardware roll-outs.
Some legacy Android devices cannot support the new version requirements and are not updated with new OS releases.This leads to a user base with a variety of different possible experiences. The developer is left with the task of checking for device capability or at least warning devices of required features.This can be done through a check of a single number: the API level.
Android is starting to mature in that releases are less frequent.Although possible, the over-the-air updates are logistically tricky and carriers prefer to avoid them. Hardware manufacturers also appreciate a level of stability, which does not mean the first flashed devices in stores need an immediate update.However, when a release is made, the level of additional features for developers remains high and worthwhile to utilize.
Emulator and Android Device Debug
The emulator launches awindow on the development computer that looks like an Android phone andruns actual ARM instructions. Note the initial startup is slow, even onhigh-end computers.Although there are ways to configure the emulator totry to emulate many aspects of a real Android device such as incomingphone calls, limited data rate, and screen orientation change, somefeatures (such as sensors and audio/video) are not the same.
Theemulator should be considered a useful way to validate basicfunctionality for devices not available to the user. For example, thetablet screen size can be tried without purchasing a tablet. Note that atarget virtual device must be created before the emulator can properlyrun. Eclipse provides a nice method to manage Android Virtual Devices(AVD).A handy list of keyboard shortcuts for emulator functions is shownin Table 2 .
Ingeneral, the first testing is best done with an Android phone. Thisensures full functionality and real-time issues that cannot be fullyrecreated with the emulator. For an Android device to be used as adeveloper platform, just hook it to the USB using the USB cable thatcame with the phone and ensure the USB driver is detected (this isautomatic with a MAC; the drivers are included with the SDK for Windows;and see Google’s web page for Linux).
Some settings on theAndroid device need to be changed to enable developer usage. From thehome screen, select MENU – Settings – Applications – Unknown sources andand MENU – Settings – Applications – Development – USB debugging toenable installation of applications through the USB cable.
Using the Android Debug Bridge
Itis often convenient to use the command line to access the Androiddevice.This is possible when it is connected to a computer using the USBcable.The Android Debug Bridge, which comes with the SDK, can be usedto access the Android device. For example, to log into the Androiddevice as if it were a Linux computer, type the following:
> adb shell
Then, many UNIX commands are usable on the device. Use exit to exit the shell. A single command can be appended to this to be executed without needing to enter and exit the shell:
> adb shell mkdir /sdcard/app_bkup/
To copy files off the device, use pull and rename it as needed:
> adb pull /system/app/VoiceSearchWithKeyboard.apk VSwithKeyboard.apk
To copy a file onto the device, use push :
> adb push VSwithKeyboard.apk /sdcard/app_bkup/
To delete an application, for example com.dummy.game, from the device, type the following:
> adb uninstall com.dummy.game
These commands are the most commonly used, but more are available.
Signing and Publishing
Foran application to be accepted on the Android Market, it needs to besigned.To do this, a private key needs to be generated and kept in asecure place.Then, the app needs to be packaged in release mode andsigned with the private key.
When an application is upgraded, thesame key needs to sign it to ensure a transparent update for the user.Eclipse automatically does all of this. Just right-click on the projectto be signed and select Export…→ Export Android Application toinitiate packaging. A password can be used to create a private key,which is saved for future applications and upgrades.
Then,continue through the menu to the creation of an APK file.This is apackaged version of the Android project in release mode and signed withthe private key. It is ready for upload to the Android Market.
Afteran application is designed, developed, tested, and signed, it is readyto be deployed into the Android Market.To use Google’s Android Market, aGoogle Checkout account needs to be created. It is used not only to payfor the initial developer fee, but is also used for payment back to thedeveloper for any charged apps.
Public exposure to a developer’screation is often exciting. Within hours of upload, the application canget hundreds of views, downloads, ratings, and reviews from around theworld.
This article is based on content from The Android Developer’s Cookbook , by James Steele and Nelson. Used by permission from Addison Wesley, Pearson Education.
Nelson To has developed many applications in the Android market for suchcompanies and organizations as Think Computer, AOL, Stanford Universityand Logitech.
James Steele , previously a post-doctoralcandidate at Massachusetts Institute of Technology, now works in SiliconValley aiding companies in bringing research projects to productionsystems in both the consumer and mobile markets.