Two years ago I began writing a book about writing applications for Android.
Back then, most people had not heard of Android — in fact, unless you’re a phone-geek or a Linux fan, you may still not have heard of Android.
When asked to describe my project, I simply described it as a book for folks like me who want to write software for the “Google Phone”.
Of course, a “Google Phone” really didn’t exist at the time. But now, as 2010 approaches, rumors abound about the new phone built just for Google, named the “Nexus One”.
I am no insider — no one at Google has called to let me know what is going on — nor do I have one of these devices handy. I have not seen the device and am relying on information from the web just like most of us. Regardless, it looks like a Google Phone is on the horizon, so what do we know about this device?
Here are some of the (rumored) details about the Google Phone.
The new Google phone has been given to Google employees as a test population — to put the phone through its paces.
It is an unlocked GSM phone. This means that it can work with T-Mobile and AT&T in the US, though the device’s FCC testing on T-Mobile’s network suggests that T-Mobile is the first target network, as the T-Mobile and AT&T 3G networks are supposedly incompatible. Source
Being unlocked means that it may or may not be available as a subsidized device. For those grappling with what subsidized means — think “two year contract required”.
Touch screen only — no keyboard — it is supposed to be thinner than the iphone. Bummer. I really like the tactile feel of a physical keyboard. This fact alone makes it hard to imagine switching away from my CrackBerry device, though I am confident that I will be making the switch to an Android device sometime in 2010. That will depend on the availability of a solid Android device for AT∓T which at present is still lacking.
The device will run version 2.1 of the Android OS. Great, just what we need is another SDK release to keep up with!
The topic of a new SDK is generally speaking a good thing for consumers, but a challenge for software developers and a potential source of frustration for the early adopters; the Sprint Hero is currently stuck at rev 1.5 of the Android SDK. Hopefully Sprint makes an upgrade available soon to Hero customers. Even the Droid from Motorola/Verizon is at 2.0 and will already be behind a minor release revision.
Everyone expects the new device to be faster, cooler and better than sliced bread, etc. However, the truth is that the phone will be measured by one and only one yard-stick: “is it better than the iPhone”? Time will tell.
Writing a technical book is a non-trivial task. Writing a technical book for a moving target like Android can be classified as somewhere between ambitious and lunacy.
When I first embarked on the project to write a book about an as-yet-unreleased mobile operating system, it seemed like a fun idea. Things were new and exciting — kind of like the first snow of the season. After a while dealing with SDK changes was like clearing the driveway from heavy snow — again. It was quite a bit of work to keep up.
By the time the book was half-written, the SDK had changed multiple times and there were long stretches of “hurry up and wait” between updates and rumors of SDK updates. Some other books came out before us and were (arguably) of marginal value due to the signfiicant changes in the early SDK.
Today the SDK sits at version 2.0 2.0.1. With the talk of the new Google device, we’re looking at version 2.1 at minimum, perhaps even higher once the device is actually shipping to an audience broader than Google’s employees. Fortunately, Google has made some enhancements to the developer tools to better facilitate moving between different SDK releases.
Up through SDK release 1.5, each time a developer wanted to work with a different SDK, the full SDK was downloaded and the development tools would be modified to point to the new SDK. If you wanted to do a build for a different SDK target, you would have to switch to another “directory” on your development environment to “compile and link” against the appropriate SDK. Having multiple SDK’s in play concurrently was a bit of a challenge.
With SDK version 1.6 and beyond, an Android developer need only install the SDK once and then the SDK itself contains tools for keeping your development environment up to date.
Android SDK and AVD Manager
Today, when you download the SDK, you get the latest version of the Android SDK and Virtual Device (AVD) Manager.
This tool is accessible from the Eclipse toolbar as shown below.
Start the SDK and AVD Manager
When invoked, the SDK & AVD Manager permits three major activities.
View Installed packages. This new approach to SDK management is very modular — you can install only the components and tools of interest. If you are like most Android developers today, you probably will care little for working with the 1.1 SDK. However, if you have a need to work with it, you can install that version. As new versions become available (like 2.0.1 did just after the Droid launch), you can simply download the new packages and test your projects against the latest code.
Browse installed packages
Browse Available packages. This option lets you see which packages are available, including a choice to optionally see only updates to currently installed packages. Packages available to upgrade or install
The Virtual Devices option lets you manage Emulator instances — connecting the appropriate SDK to the appropriate Emulator tool. In this way, an Android developer can manage, and even run, multiple SDK versions concurrently. Creating a new virtual device is easy using the tools, just select New and fill out the form as desired. Manage Android Virtual Devices
Once the new device has been defined, you can selectively start one or more instances of the Android Emulator. Pick a Virtual Device
When you want to run your Android application against a particular SDK level, you need to specify which “target virtual device” you want to run as shown below.
Select a Virtual Device to run
That’s it — you can now use multiple versions of the Android SDK in your own development environment.
2010 promises to be an exciting and hopefully break-through year for Android enthusiasts everywhere. Google is getting into the game with a device — whether it is good or bad for Android, only time will tell. The one fact it demonstrates is that Google is continuing to invest in this platform, and that cannot be bad news. The SDK is ready for a continuously forward-looking horizon. And yes, I am writing an update of the Android book. Ambitious? Yes. Lunacy? Perhaps.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62