Channels ▼
RSS

Tools

The Android Developer Experience


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).

Figure 7: Creating a New Android Project with wizard assistance from the Android Developer Toolkit.

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.

[Click image to view at full size]
Figure 8: Examining the generated Android project files.

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.

Figure 9: Dr Dobbs says 'hello' from the Android emulator.

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.

[Click image to view at full size]
Figure 10: DroidDraw is a very useful donation-ware utility for quickly assembling Android UI layouts..

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






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips 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.
 

Video