Writing an Android Application
Creating an Android application is relatively painless, though due to the forced abstraction of resources including layout, strings for easier internationalization and raw resources such as audio clips and images, a bit more forward thinking and manual wiring of the interface elements is required.
Assuming all the prerequisites have been met and the API demo successfully launched on either the emulator or the developer device, the Android Eclipse plug-in can be called upon to generate a skeleton Android application, complete with required class wrappers, files and folder layouts. However, logic and interface code needs to be written and wired up before seeing anything meaningful on the Android display.
After launching Eclipse, select File --> New --> Project... and select Android Project. Name the project (for example, "HelloDDJ") along with a Package name (following the Java package namespace convention; for example, "com.ddj.android.hello"), Activity name (the name of the subclass from Android's Activity class; for example, HelloDDJ) and lastly, a human-readable Application Name (Hello, Dr Dobbs).
Clicking the Finish button will automatically generate the basic code and layout xml, enough to execute and display a simple window with the name of the application in the titlebar and a Hello World, (followed by the Activity name, in this example's case, HelloDDJ) text string in the body. However, before doing so, let's first explore what files the wizard generated. Expanding the HelloDDJ src tree reveals two auto-generated class files:
- The HelloDDJ.java containing the HelloDDJ class, extended from Android's Activity class.
- R.java final class.
This R class contains pointers to string, images, layouts, audio, video and other application assets. The R class is automatically managed and updated by the ADT whenever file assets are added or removed to the project's resfolder. I discovered that this R generator doesn't like files that begin with numbers, so name your image and audio files beginning with standard ASCII characters.
Examine the contents of the resfolder and note the three sub-folders: drawable (containing images such as the generic program icon, as well as other bitmap graphics in PNG or JPEG formats), layout (containing the program's various layout definitions in XML format), and values (containing the program's strings structured in XML format). One folder that isn't auto-generated but required if adding file assets such as audio (AAC, AMR, MIDI, MP3, OGG, WAV and WMA encoded files are valid Android audio playback formats) and/or video (H.263, H.264 and MP4 encoded video files are valid Android video playback formats) is the raw folder.
Because Android enforces strings to be referenced rather than embedded in the code, using a System.print.out() statement to display text in a window isn't valid. Instead, the strings are identified in the strings.xml file and referenced in the AndroidManifest.xml and vairous layout xml files (for example, main.xml). This keeps all the program strings in a single file, greatly simplifying localization and generally organizing all the strings displayed in the program. Of course, the Text properties of the various Android display elements like the TextView class can be programmatically modified, but the static strings like those found in about boxes, forms and dialogs are contained in the strings.xml file.
Thus, to modify the HelloDDJ string, open the strings.xml file, select the hello string value and replace it with "Dr Dobbs says hello from Android!" Save the project and run the application. This will fire up the emulator (or send the application straight to the G1 if it is configured and hooked up to the host computer) and display the Hello, Dr Dobbs window containing the edited welcome message.
Once the rudimentary steps of creating a simple Android application are understood, go to the next level by writing a few conceptual tests that call upon frequently accessed features, such as setting an alarm, displaying alerts, displaying a web page or capturing images from the built-in camera. The Android SDK documentation has a section dedicated to such tips.
One of the deflating aspects of the ADT is the lack of any kind of GUI builder in the current release. Instead, each layout needs to be described in manually constructed XML. Once well formed, this XML can be rendered in the layout view to check for accuracy and positional placement. Android offers several layout models depending on the application's requirements such as screen orientation, form resizing, absolute positioning and others. Fortunately, Android developer Brendon Burns has created both an applet and standalone Java-based design tool called "DroidDraw" that helps UI designers create and export valid Android XML layout files. While I expect the Android development team to eventually incorporate round-trip drag-and-drop GUI construction within Eclipse, DroidDraw supplies a more than adequate placeholder for Android UI generation.
As the Android developer community continues to expand, I expect more tools like DroidDraw to spring up, helping developers scratch the itches created by deficiencies in the SDK. And if Android's marketshare expands to the percentages projected by Google and other mobile industry analysts, there will no doubt be commercial add-ons, libraries, widgets and code management tools created for an eager and demanding Android developer audience.
Books, Websites, Cool Apps, and other Developer Resources
As enthusiasm for Android development continues to expand, more websites, books and articles will add to the already adequate amount of information available today. Some of the more useful resources I discovered while working on my own Android development efforts include the following:
- Android Essentials by Chris Haseman, published by Apress. This was one of the first Android developer titles on the market, and while the content is still relevant, more recent titles have eclipsed its emulator-centric tutorials.
- Hello Android by Ed Burnette, published by Pragmatic Bookshelf. Just over 200 pages, this short book gets impatient developers like me up to speed quickly on pro grammatically controlling Android's most compelling features. Visit dobbscodetalk.com for my more comprehensive review of this title.
- Professional Android Application Development by Reto Meier, published by Wrox. One of the most comprehensive books on Android development available today.
- Android SDK Documentation. A first stop for anyone interested in writing Android applications. Do not pass go, do not start writing a line of code or post questions in the various Android website forums until this reference material has been read and digested.
- Android Development Community. A community-driven Android developer website chock full of reviews, tutorials, coding problem threads and other discussion groups, each of which can be subscribed to via RSS.
- Android Developers Google Groups. Google monitored developer discussion forum with over 14,000 members at the time of this article's publication.
- Google Maps (standard application on the G1). This application raised the roof at early Android demonstrations. While the compass mode in Streetview isn't the most efficient way to peruse street-level imagery, it undoubtedly continues to be the coolest.
- ShopSavvy by Big in Japan. One of the big winners in the Android Developer Challenge (code.google.com/android/adc.html), ShopSavvy uses the G1's built-in camera to capture a product barcode, identify the product and present best price options online and local retail outlets based on the user's GPS coordinates.
- Twidroid by Ralph Zimmermann and Thomas Marban. Twitter client with built-in geotagged photo blogging support. This mobile microblogging client is also one of the first to support Laconi.ca's PHP-based open microblogging platform.
Conclusion
I have been developing applications on various mobile platforms since the days of the original Palm OS, spending most of that timespan within various incarnations of the Windows CE environment. When the first generation iPhone shipped without an open SDK, my desire to do anything interesting on that device quickly wained. Besides, I already had everything I needed on my Windows Mobile gadgets anyway. Of course, the iPhone was a game-changing device that brought to the less technical crowd what I had already been doing for years.
Android represents an attempt to satisfy both the extreme-tech and the non-tech audiences. I suspect that for the time being, Android will serve code-hungry developers for a while but will struggle to gain significant marketshare in the segment that Apple's iPhone is serving so effectively. But as a result of the open conversations and open platform, faster innovation is more likely on Android compared to any other modern day mobile OS. How this will translate into commercial ventures is still murky, but from a pure development standpoint, I can't recall when I had this much fun (coupled with a few brief bouts of frustration) writing applications for a mobile device. Even with its first generation flaws, the Android is the smartphone that currently goes in my pocket every morning, leaving my other mobile devices behind to collect dust on the retired gadget shelf back home.
Related Reading
More Insights
 |
To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy. |
Best of the Web
First C Compiler Now on Github
The earliest known C compiler by the legendary Dennis Ritchie has been published on the repository.
HTML5 Mobile Development: Seven Good Ideas (and Three Bad Ones)
HTML5 Mobile Development: Seven Good Ideas (and Three Bad Ones)
Building Bare Metal ARM Systems with GNU
All you need to know to get up and running... and programming on ARM
Amazon's Vogels Challenges IT: Rethink App Dev
Amazon Web Services CTO says promised land of cloud computing requires a new generation of applications that follow different principles.
How to Select a PaaS Partner
Eventually, the vast majority of Web applications will run on a platform-as-a-service, or PaaS, vendor's infrastructure. To help sort out the options, we sent out a matrix with more than 70 decision points to a variety of PaaS providers.
