##CONTINUE##
When Google announced its Linux-based Android platform that hosted applications written using Java syntax, my mobile development interests were quickly realigned to the open platform mantra that Google was chanting. And yet, even though Google released the Android SDK earlier last year, it wasn't until the physical hardware development units became available in December 2008 did I decide to take a more serious look at this alternative mobile OS.
Signing Up
To become a privileged member of the Android Developer Program, you must first visit the Android Market and create a Gmail account if you don't already have one. The Gmail account is required for Google Checkout, employed for the one-time $25 charge of being granted the permission to post Android applications to the Android Market after agreeing to the lengthy developer agreement. It is also through this marketplace that developers can purchase a single G1 developer device.
The Hardware
Unlike the G1 model currently sold at T-Mobile and other stores, the developer G1 is an unlocked model that permits SIM cards from other carriers besides T-Mobile to be used with the device. More importantly, this G1 version offers root user access, giving you full access to the Android filesystem as well as the ability to re-flash the device without constraints. Indeed, adventurous hackers have already created a minimal Debian-based Linux distribution that can be flashed onto the G1. This delightful experiment is nowhere near ready for prime time use, but the fact that it can even be done at all will unquestionably motivate other Linux mobile enthusiasts to charge ahead with even more innovative hacks. Needless to say, the developer unit isn't a device for the technically challenged. As a mark of special exclusivity, the developer unit G1's rubberized back plate has a custom Android polygon design imprinted across it for additional "Android Club" geek-cred points.
Based on the T-Mobile G1 developed by prolific Windows Mobile hardware designer HTC and modeled upon the HTC Touch, the developer version is everything initial reviews of the consumer G1 said it was: a good first attempt with adequate single touch screen resolution, feature laden with 2G/3G, Bluetooth, GPS and WiFi radios, accelerometer, digital compass and... an abominable battery life. Since I have been using the G1, I have yet to make it through the day without charging it at least twice. However, barring the fact that this ambitious platform performs miserably in the power consumption category, it nevertheless provides a stable development reference platform to create and test Android applications in the real world.
There were other hardware issues that bothered me enough to have to correct with additional accessory purchases. First and foremost, the 1 GB microSD card included with the phone is simply too anemic by today's multimedia standards. While I debated upgrading to a 16 GB card, I opted for a much less expensive 8 GB capacity instead. Another truly bone-headed design limitations (or greedy aftermarket accessory approach, depending on the conspiracy factor) is the G1's proprietary HTC miniUSB-like adapter that is used for both the unattractive, bulky earbuds as well as the power recharge connection. Without additional adapters, G1 users cannot, for example, listen to music and charge their device at the same time. Fortunately, an inexpensive splitter from Amazon (search for "2-in-1 mini USB adapter") solved this annoying dilemma at the expensive of additional bulk clipped to the base of the phone. Finally, what seems to be a standard omission for most mobile smartphone devices these days is a protective carrying case. I decided I had invested enough in phone extras and instead simply left the Mylar cover on that protected the screen during shipping.
Incidentally, in keeping with the burgeoning Android OS hacks, a few enterprising Linux netbook hobbyists have succeeded in compiling the Android source targeting an Asus eeePC sub-notebook. While this certainly generated a buzz in the Android community, using such a device as a G1 replacement isn't practical due to the lack of hardware support such as the sensors and various drivers. Regardless, the feat further strengthens the reality of Android's open source platform promise.
The Software
The OS version shipping on the developer G1 that I received was an unlocked Nov 3 1.0 build running the Linux 2.6.25 kernel. While this first generation version is a remarkable achievement for the Android team, there are unsurprisingly a few rough edges. I've read Android reviews stating how stable it is and how it's nearly crash-proof. That didn't turn out to be the case for me. I had the OS unexpectedly and forcibly reboot on me several times, most often when using Android's Music application and listening to MP3 file playback.
There is also the fact that the Android designers took the iPhone approach of masking the underlying file system such that files, even those being stored on the microSD card, cannot be easily accessed and manipulated from a standard file management/browser approach using the standard application set. Instead, a visit to the Android Market is necessary to more easily access the file system when un-tethered from the host development environment. The two I found most helpful are a third-party simple file browser called OI File Manager, and Google's own Terminal shell program. On consumer G1 models, the Terminal program isn't very helpful since root access is locked, but on the developer G1 model, root access is helpful, even a necessity at times. Since the version of OI File Manager I used can only affect a single file at a time, I more frequently call upon the Terminal program to perform most of my file manipulation.
More importantly, the Terminal helped me alleviate one of the most painful design oversights of the Android Market and various Google applications like the Maps and Browser. This ravenous storage eater is the current version's inability to have these standard applications store their downloaded data caches on the microSD card and not the main onboard memory of the device. Googling for Android Market and cache together will yield a litany of angry complaint links from end users and developers alike of how their G1's are rapidly exhausted of memory as a result of these two applications lacking such an obvious feature.
As of this writing, the Android team is working on an update to the Android OS, codenamed "Cupcake", that is expected to fix this glaring oversight as well as add new features such as stereo Bluetooth (known as A2DP) support and a few other nice enhancements. In the meantime, hard-pressed developers equipped with the Terminal program have come up with a very easy Unix-like solution to the cache problem. After downloading and installing the Terminal application from the Android Market, launch it, su to root and create a new directory called /sdcard/marketcache (this can be named anything, and even reside in a deeper subdirectory). Navigate to the /data/data/com.android.vending directory, delete the cache folder located there (rm -R cache) and create a symlink to a new cache folder location on the microSD card (in this example, execute ln -s /sdcard/marketcache cache as root). This caching issue is a problem not just with the Android Market app, but several others as well, including the Browser, Maps and even some third-party Android programs that prefer to keep cached data on the device instead of providing an option to store locally cached data on removable storage. Because this is such a prevalent problem, community contributors at modmygphone.com have created a wiki entry outlining the steps needed to alleviate the cached storage constraints with various Android applications. Visit modmygphone.com/wiki/index.php/Caches_To_SD_Card for details. Note that because these cache relocations require root level access, they can only be performed easily on the developer G1 models. End consumers will either have to hold out for Cupcake, cold reset their devices to clear out the cache (and everything else they had installed) or embolden themselves with attempting to unlock the commercial G1 handset on their own and possibly bricking the phone in the process.
If you prefer not to mess with the file system and want to minimize the cache size, you do have another option. Developer Jay Freeman has created an Android Market front end at cyrket.com that anyone can visit with a web browser. This helpful site also allows non-Android owners to see what the Android Market has to offer. As long as Jay keeps cyrket.com alive, I will continue to visit it first before perusing the latest market updates via the Android Market application.
The Development Environment
Setting up the optimal configuration for Android development is a fairly easy process that takes less than 15 minutes, not including download time for the software. The Sun JDK 1.5 or higher is an obvious initial requirement to run both the Eclipse IDE and the Android Developer Toolkit (ADT) plug-in set. I chose to use the latest 1.6 release. Once the JDK version requirement is met, download and install the Eclipse IDE. The nice thing about Android development is that it can be performed on Windows, Mac, or Linux, the same platforms that Eclipse runs on. Any Eclipse version 3.2 or higher will do. I chose the latest 3.4.1 Ganymede release. While the Eclipse IDE isn't absolutely essential, the Android team has written the ADT exclusively for the Eclipse environment that makes launching and managing the Android emulator much easier. There are reports of some brave attempts to wire up these pieces within Sun's own NetBeans IDE, but unless there is some serious aversion to Eclipse, this effort appears to be more trouble than it's worth.
Next, download and install the Android SDK. This can be installed anywhere as long as the Eclipse plug-ins can consistent locate the installation path. Finally, launch Eclipse and grab the ADT via the usual Eclipse plug-in install route. Select "Software Updates" from the Eclipse "Help" menu, click on the "Available Software" tab, then the "Add Site" button and enter the location of the ADT. Restart Eclipse and enter the installation path of the Android SDK in the Window --> Preferences --> Android dialog box.
Windows and Mac users should be ready to go, but Linux 64-bit users will need to ensure they have the 32-bit emulation libraries (ia32-libs) installed; otherwise the proprietary, closed source emulator compiled in 32-bit code for the Linux environment will fail to run on that 64-bit host.
Check to make sure everything is correctly configured by launching Eclipse, importing the APIDemos project from the Android SDK demo folder and running it. Doing so should launch the emulator and, once confirmed running (initial instances take between 30 seconds and a minute depending on host computing resources), select Run. This will compile the the project's source code and various resources into a single Android package called an "apk" file, download and instantiate APIDemo in the emulator. Fortunately, subsequent Android runs will occur much faster as long as the emulator is allowed to keep running in the background.
The emulator itself is for the most part an accurate reflection of a real Android device like the G1. Unfortunately, the emulator used during the writing of this article could not emulate the sensors or radios such as the accelerometer or GPS. However, the aforementioned folks at OpenIntents have created a helpful alternative to help simulate such inputs at the cost of modifying an Android project's code to get it to talk to OpenIntent's Sensor Simulator. However, I suspect that if the development community clamors loudly enough, the Android SDK team will respond with such capabilities built into future SDK releases.
Once acclimated to the emulated environment, it's time to test sending applications to the actual G1. Windows users first need to download and install the Android USB Windows driver. Linux users have more work to do. A rule has to be added to the host computer (example, for Ubuntu Hardy users, a new file needs to be created at /etc/udev/rules.d/50-android.rules containing the following: SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666". Once saved, chmod a+rx the file and the host computer should be able to identify and communicate with the Android device when plugged in via the USB port. Mac users fortunately do not have to mess with any drivers or settings, as the Android SDK tools and Eclipse environment will automatically recognize the device. As Google's SDK installation documentation boasts, "it just works." And they're right -- it does.
The Android plug-ins will automatically assist Eclipse in targeting the attached device and download and run the desired apk accordingly. Simple.
With both the emulator and device successfully receiving and running the API demo, you're ready to start writing your own Android applications.
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.
BY Mike Riley
Source：Dr. Dobb's
© 2009 TechWeb, Privacy Policy, Terms of Service, United Business Media LLC.
Posts
0 comments:
Post a Comment