Android Wireless Application Development, Second Edition, Now Shipping!

Android Wireless Application Development,
Second Edition

We hope everyone is enjoying their gingerbread and the last few days of 2010. Additionally, we'd like to share that the second edition of Android Wireless Application Development is now shipping and on shelves.

Enjoy!

Happy Holidays!

Holiday Cheer or Fear?

Here's a little something to entertain and amuse:

Reader Feedback: Manifest Permissions Editor

[UPDATE: 13 Feb, 2011: This problem now longer exists in ADT 9.0.0 (the version right after 0.9.9).]

The Android Manifest file editor within Eclipse provides a number of useful editing tabs to wrangle the complexities of this file. One such tab is the Permissions tab. Use the Permissions tab to manage the permissions that your application uses and grants to others.

If you've been working with Android for a while, then you may be familiar with the permissions listed in the drop-down when you register a new permission using the uses-permission tag. We refer to this feature in both our books; specifically in Sam's Teach Yourself Android Application Development in 24 Hours, Hour 5, "Configuring the Android Manifest File."

Unfortunately, a recent update to the Android Development Tools plugin removed this drop-down. We're not sure if it's a bug or not yet, but the drop-down disappeared in the software update between ADT 0.9.8 or ADT 0.9.9.

What used to look like:

Permissions tab from ADT 0.9.7 showing the drop-down list of values

Now looks like:

Permissions tab from ADT 0.9.9, with the corresponding Browse... dialog

When you press the Browse... button, the dialog comes up.

The field provided still works for typing in permissions values by hand, instead of selecting them from a list. The alternate method, editing the XML file directly from the last tab, hasn't changed at all.

So where is one to get these values to type in yourself? On page 90 and 91 of the SAMS book, we've listed a number of the most common permission values. However, the best place to get the appropriate values for your applications is from the Android SDK documentation. Permissions are defined in the documentation for the android.Manifest.permission class. Also conveniently listed with these values is a short description of what they enable the application to do. Before including a permission within your application, always check the documentation to determine if that is the most appropriate one to use.

Building an Android Application: Book Excerpt

Sometimes publishers allow sites to publish entire chapters of books. ComputerWorld recently published a complete chapter from Sam's Teach Yourself Android Application Development in 24 Hours. We think this is a particularly good excerpt, too, as it has broad topic coverage.

This excerpt, from Hour 3, covers topics from application design to resources to Android Activities. And then it goes on, and covering Activity lifecycle and even Intents and various things you can do with them as a developer. You even get information about debug logging. It's not just a preview of Hour 3, it's nearly the whole chapter.

Check it out at ComputerWorld!

¡Hola! Writing Android Apps for Different Languages and Locales

Find out how this
screen is localized!

It's easy to write Android applications in multiple languages and locales. By clever storage of localized resources in specially named project directories, most of the work in application internationalization is done for the developer. Whether you want to write an application that supports English and French, or Austrian German vs. Swiss German, you can learn how in our tutorial on Mobiletuts+.

Resources need not just be strings, either. Learn how to localize and internationalize your strings, colors, images, and more in Android SDK: Building a Localized Phrasebook.

Reader Feedback: Missing Code! Creating Android Widgets

Not all of the feedback we get is from our books. We write articles for numerous sites around the net and in print form. On most of these systems, we don't have a good way of updating or changing the article once it's posted. Recently, we came across an issue where a series of articles lost their download links for the source code. This series was written back in October of 2009 and discussed creating widgets for Android on the then-new Android 1.5.

We have moved all of the widget tutorial code to Google Code hosting so it should stick around for longer.  The tutorials are still available from developer.com:

• Creating a Home Screen App Widget on Android
• Handling User Interaction with Android App Widgets
• Handling Lengthy Operations with Android App Widgets

Android 2.2 Spreading Wide

We visited the sculptures
after Google IO 2010

Android 2.2 has been getting a lot of news lately. Instead of just being available on the Nexus One, it's now available on many devices, and even shipping on news ones like the Droid 2. A while back we wrote a few articles about Android 2.2 (aka FroYo!). These are relatively high level overviews, but for some they can serve as a reminder of some of the features that we were excited about yet forgot all about because it's been so long since the announcement.

Recall ten of the most anticipated items us developers were looking for in Top 10 Android 2.2 Features Developers Can't Wait to Use. Anticipated, but have they lived up to the hype? You tell us. Interestingly, Cloud to Device Messaging is still not widely available. And, although it's a user feature, we're definitely seeing that not all carriers are taking the Tethering option as it was developed. The Nexus One could very well be alone in it's implementation.

We took a look at past desserts of Android and compared them to the latest, FroYo (mmm, Frozen Yogurt!), in Android 2.2 and Its Previous Versions: A Sweet Developer Review. Although most of the full API level updates have been fairly minor (especially, for instance, API Level 6 to 7), when you look all the way back to API Level 1, the changes have been substantial. Not only have the APIs changed, but the tools have vastly improved. They started out being surprisingly good for a very young platform. Now they're better than even more mature platforms.

Lastly, we wrote an overview of Android 2.2 for users and developers alike, printed in Linux User & Developer magazine, a UK publication. Hey, Android is available worldwide, mates!  This one covers many of the same topics, naturally. (What, did you expect Android 2.2 to change?)

With Android FroYo old news now, what are you most looking forward to in Gingerbread, the next expected release of the SDK (presumably API Level 9)?

Reader Feedback: Trivia Quiz Server Bug

Bugs happen! 

In Hour 17 of Sam's Teach Yourself Android Application Development in 24 Hours, you learn about AsyncTasks. You use one to send a request to the server to add a friend based upon their email address. What's supposed to happen is that the server looks up the email address and if it finds a match, it adds that user to your list of friends, which is stored on the server. Then, when the Scores Screen is updated to download scores of your friends, the server will return XML containing just that. It will not return email address or anything like that -- we don't want privacy leaks.

What was happening?

Nothing!

Nothing? That's right. The server was failing to find any friends -- regardless of the email address. It was, however, returning the correct status. We just didn't bother with doing anything more with the status than printing it out to LogCat. Whoops.

Fixed

The fix was simple. The Google App Engine server has been updated to version 3 and, after some brief testing, we promoted this to the default server.

If you were having trouble with adding friends, now you know why.

This report was sent in by a reader. If you have troubles, please don't hesitate to contact us at androidwirelessdev@gmail.com or right here on this blog. We see all comments. It might just be a bug!

Reader Feedback: Educational Materials

We're frequently asked by professors, teachers, and other educators about materials they can use in their lectures or coursework above and beyond those found in our books. Our publisher has a great site for this purpose: Pearson Education. They create slides and other teaching materials for the various books, including Android Wireless Application Development and Sam's Teach Yourself Android Application Development in 24 Hours. We don't know exactly when the materials are available, but it is usually some time after the book is available for purchase. If you have any trouble obtaining teaching materials on a particular topic, don't hesitate to contact our publisher, Pearson Education team support or us directly and we will try to accommodate your requests as best we can.

Unit Testing with Android JUnit

Mobiletuts+ Android JUnit Testing Article

Testing is an important part of any software project. Testing for mobile is no different. One way of ensuring correctness of code at all levels is via automated unit testing.  Through automated unit testing, you can define expected results on the normal cases, in addition to edge case failures, standard failures, and everything in between. The popular JUnit framework is often used when writing these unit tests for Java.

The Android framework includes powerful unit testing support. Learn how to get started with Android JUnit with our Mobiletuts+ article on JUnit testing with Android.

Creating Useful AVDs

Various Android Virtual Devices

Many new Android developers just use a basic, default Android Virtual Device (AVD) for development purposes. This is fine when you're just getting started, but when you get serious about designing and developing apps for specific devices, you'll want to give some thought to configuring AVDs to match devices your users actually own.

In some cases, you can just switch to testing on real hardware instead of the emulator. If you have a lot of devices for your team, you can probably just switch to using devices. However, if you can't afford devices for everyone on the development and test team or can't get your hands on some unusual devices with unique hardware characteristics, you can create AVDs to simulate these. Head over to Mobiletuts+ and read our tutorial about creating AVDs that come as close as possible to simulating the following devices:

• HTC Evo 4G
• Google/HTC Nexus One
• Motorola Droid
• T-Mobile/HTC G1
• Archos 5 Internet Tablet

Reader Feedback: On Log Tags

Sam's Teach Yourself
Android Application Development
in 24 Hours

For the Sam's Teach Yourself Android Application Development in 24 Hours book, we received a question regarding debug tag code in Hours 9 and 10.

Log.d(DEBUG_TAG, "SHARED_PREFERENCES"); 
// (From Hour 10, Page 177)

A couple of readers have asked us: What is DEBUG_TAG? Where is it defined?

The short answer is: you need to define it! By this point in the book, we aren't displaying every line of code you need for the application to compile--only the relevant new code for that particular lesson. We assume that you've mastered certain fundamental Android skills in the previous chapters of the book. One of these skills is understanding the Log calls, such as Log.v or Log.d. which were discussed in detail in Hour 3, Page 54.  This skill is essential for debugging Android applications and is used regularly throughout the book.

Log method calls simply display diagnostic information to the Logcat logging tool, providing the developer with important information as the application executes. These calls have no impact on the actual application functionality. The calls just log string output for debugging purposes. You can include these logging calls in your applications or simply leave them out (and not provide diagnostic logging). If you want to log information using the logging calls, you will need to supply a tag string as the first parameter for each Log method. In Hour 3, we suggest that you define a logging tag for each and every Android project or class you create.

The logging tag is shown in the log output of logcat, so you can tell that the information is coming from your application, Activity, class, or method. It's that simple.

LogCat output showing all device logs. Cluttered.

You can also filter on just the tag, which shows the real power of it.

LogCat, with filter to show only the tag "GestureFunActivity"

So, when you run across a line in the book that uses such a call, we do not provide the definition of DEBUG_TAG variable. Instead, we assume you know that this is a generic logging call, and you should supply the definition of the variable somewhere in your class. For example, if you want to add logging calls to an Activity class called QuizHelpActivity, class, you should add a definition such as:

private static final String DEBUG_TAG = "QuizHelpActivity";

Or maybe you'd prefer:

private static final String DEBUG_TAG = "QuizHelpActivity Logging Info: ";

Or even something for your entire application:

private static final String DEBUG_TAG = "MyAppLogging";

Those of you who have Java experience will likely recognize that the DEBUG_TAG variable is a constant. That is to say, it has the static final qualifiers. Since the input type to the Log functions are String objects, you then know this to be a static final String. Remember that the logging tag should be descriptive for the specific application or class. In fact, it's often set to the class name, but there is no requirement to do so.

We hope this helps clear up this question. As always, feel free to email us or post a comment right here!

Second Edition of Android Wireless Application Development Available as a Rough Cut

Rough Cuts eBook cover

We're current working on the update of our first book, Android Wireless Application Development. We're adding lots of new content, refreshing most content, and adding entirely new chapters.
For those with access to Safari, the Rough Cuts version is available. Right now, that's the first twelve chapters, but the others will be put up not long after we finish them until, finally, the book is shipped in print.
Get Rough Cuts Android Wireless Application Development, Second Edition, now, while it's hot!

Android Debug Key Expired? So Did Your Debug Maps API Key!

As an Android developer, you've probably run into an expired debug key by now. If you use the Maps API, you'll inevitably run across the other issue: your maps key is tied to your debug certificate and it also stops working. This happened to me because of a lengthy break from use the Maps API. My old code had a Maps API key in it tied to an equally old debug key. Naturally, using the new debug key meant this didn't work at all.

Now, if you've followed our advice and created a certificate that won't expire for a long, long time, then you can create a debug maps key that will work with it for a long, long time.

It's all pretty simple:

First, create your new debug.keystore file, using all the mandatory values:

keytool -genkey -keypass android -keystore debug.keystore -alias androiddebugkey -storepass android -validity 10000 -dname "CN=Android Debug,O=Android,C=US"

Next, get the certificate fingerprint for use in generating the Maps API key:

keytool -list -keystore debug.keystore -storepass android

Like so:

Command results for keytool

Finally, use that to generate your new Maps API Key. The results will look like this:

After generating new Maps API Key

If your debug.keystore file is now stored in a non-standard location, don't forget to update your build tools. In Eclipse preferences, this is the screen that needs to change:

Edit the path to your debug.keystore file

Not a Programmer? You Can Still Create Android Apps!

Google has introduced a new tool today called App Inventor. It uses the Open Blocks Java library to allow visual creation of applications, online.

This could be useful for regular developers to prototype quick apps. But, the real use is for non-developers or young folks. What would your kid create if they could create something with no coding required? Might it be silly? Might it be something other kids would have fun with? If you're not a developer, what would you create?

The tool, as it stands now, isn't fully open to the public. You have to fill out a form and then Google will eventually add access. The form is definitely aimed at educators. It's clear Google is looking at this as a teaching tool of sorts. We've always thought mobile programming would make a great target for teaching. This is evidence we aren't alone in that thought.

Sam's Teach Yourself Android Application Development in 24 Hours NOW AVAILABLE!

Our new book, Sam's Teach Yourself Android Application Development in 24 Hours, is now IN STOCK at Amazon! You might even have it already if you pre-ordered it. ;)


Remember, this is a full color book. Figures are color, code is syntax-highlighted. Color and a lower price? How do they do that? Anyway, it's more beginner oriented than our first book, Android Wireless Application Development, but it also covers some new topics. We're underway on an update to our first book, too.

Our New Android Book Printed!

We just got our first copy of Sam's Teach Yourself Android Application Development in 24 Hours in both print form and "folded and gathered" form. (That's for us to make corrections on, but it's kind of neat.) It's still pre-order on Amazon, but it should be available pretty soon! So, don't forget to pre-order and be amongst the first to get one. :)

It's a full-color book, too. The code samples are color coded which, to us, makes them far easier to read. Images are easier to view, too.

Don't Mess with Android!

Korean operator SK Telecom has created what we think are the best series of Android commercials to date. Enjoy!
















Rawr! Korean Android is Spunky!

Working with the Android Calendar

Last December, we wrote an article at developer.com about how to use the undocumented Android Calendar content provider. At the time, we'd written the code for Android SDK 1.6. Numerous updates later, this code still worked on Android 2.1. Now, however, Android SDK 2.2 finally broke it. Interestingly, the fixes were rather straight forward, though.

Instead of trying to update the article, write a new one, or try to post all the changes somewhere, we've decided to open source the code so others can see it and, if they'd like, contribute to it. The idea of the code is to demonstrate how to use the calendar content provider. Right now, it shows how to add, edit, and delete a basic entry as well as read the contents. If you'd like to see more, why not contribute to the code so others can see more to?

This uses an undocumented content provider. As it has changed, it may continue to change. The use of this code is at your own risk. Any damage it does is not our fault. You've been warned.

We also don't necessarily recommend this method of controlling a user's calendar. It interfaces with Google Calendars, which has an API of its own that is well documented and can perform everything needed. This avoids any complications with the Android client, will work even if the devices doesn't have a calendar (a non-Google Android device, for instance), and its documented. :)

In any case, we've tested the current code on our Nexus One with Android 2.2 and our Evo 4G with Android 2.1-update1. It works, but it may not work on your devices. Use with care.

Book Updates

Our upcoming book, Sam's Teach Yourself Android Application Development in 24 Hours, is finally done with the editing process. This means it's heading off to the printers and will be on shelves in due time. (This is not the quickest of processes; those darned real world items! Be patient, but don't forget to pre-order to be first on the block.)

Generally, the downloadable code is made available only to folks who have purchased the print copy. However, due to popular demand, our publisher has made available the downloads as part of the Rough Cuts program. If you have access to Rough Cuts via Safari, the downloads are now available! Enjoy.

Finally, have we mentioned that there's another book in the pipeline?

Android Fragmentation

Android is fragmented. There, we said it (okay, so we said it yet again)!

Seriously, it's the so-called elephant in the room. According to Wikipedia , there are 3 dozen Android smartphones, and a handful of tablets and e-readers currently on the market. The list of upcoming Android devices is just as lengthy. But are all the new handsets running the latest and greatest Android platform? Of course not! Some recently released phones are still running Android 1.6. Older models are still running Android 1.5. Even the Motorola Droid is still rolling out the Android 2.1 update-this week! And remember, Android 2.0 (API Level 5) barely exists in the real world, as it was quickly replaced by Android 2.0.1 (API Level 6). It's not easy to keep track of all the Android devices out there, with their varied SDK versions, screen sizes and hardware capabilities. And that, my friend, is exactly what we're talking about when we say fragmentation.

Just How Fragged are We?

The Android platform has reasonably addressed the task of targeting different screen sizes, resolutions and orientations-not to say it's trivial, but at least there are methods of going about doing so. It still adds work as more variations reach the market, but goes a long way towards reducing the burden compared to some other platforms. In addition, various hardware configurations are relatively straightforward to query for or, at least, put smart error handling in for. (Admittedly, some devices don't behave correctly when they're missing certain hardware, and even if considered a bug, in many cases the burden is on the developer to create work-arounds.)

The answer largely depends on what type of developer you are.

What's an Android Developer to Do?

If you're a hobby developer, you'll likely want to target the handset you own. After all, who wants to write an app that can't run on their own phone? Perhaps start with the Android phone you've got, and then move on to the biggest and most stable Android handsets available to your target users.

If you're a mass market developer, you'll likely need to target the lowest available version that allows your application to perform the features it requires. You'll need to target as many phones as possible.

If you're a game company or technology company designing awesome new features, you'll probably want to target the Android devices with the very latest version of the platform, and those with the best performance so all of your nifty features run smoothly.

Is Fragmentation Going to Get Better, or Worse?

Better, and worse-but there is hope on the horizon. Google has recently come forward saying they have a plan on addressing at least part of the fragmentation issue. To us, the fact that Google has stepped forward and admitted that fragmentation is a problem is a very good sign.

Technically speaking, Android is a community developed, open source project run by the Open Handset Alliance. Google is but one of about 70 member companies, and not even the biggest though they may be one of the most influential. But, the reality is the Android is Google's baby. They created it and they should really control it, open source or not-someone's got to. Sure, getting community involvement is great, but direction must be provided by someone; going democratic only works when everyone (developers, manufacturers, operators) is on the same page and they just aren't. Platforms like the Apple iPhone haven't had this problem because they are a tightly locked down platform with a reasonably small set of devices, limited operators, and more controlled versioning; the iPhone is also a more mature platform and not going through rapid and successive improvements in a short time frame-it pisses their loyal user base off royally if they release one device only to have a new and improved one available three months later. On the Android platform, we've got an explosion of devices with a very broad range of features, price ranges, and networks.

Android Team to Adjust SDK Releases Based on Fragmentation Concerns

Anyway, Google has said that they will slow down the rollout of new Android SDK versions. The Android tools were separated from the SDK in Android 1.6, so now tools can be updated separately from the SDK. Google will also separate out the Android apps that generally ship with the platform so they can be updated on demand without a new SDK rollout to the field. This is basically the desktop model. Apple doesn't need to ship a new Mac OS X to ship a new version of Safari, iTunes, or Xcode. Microsoft doesn't need to ship a new version of Windows to update Internet Explorer, Outlook, or Visual Studio. So, why should Google ship a new version of the Android SDK just to get a new version of the browser, map app, email client, or any of the other apps out?

By splitting the Android SDK into components, its users, developers, handset manufacturers, and carriers should be able to work more effectively. Users won't have to wait for their manufacturer and carrier to approve a full firmware release just to get a security bug fix in the browser. Developers will have fewer platform targets to worry about; instead, there may be more downloadable, add-on components to manage. Manufacturers won't have to try to keep up with the crazy speed with which the Android platform has been progressing. (During our current book project, we saw the number of platform levels go from 3 to 7. That's pretty crazy!) And, finally, carriers won't be burdened by so many full firmware updates that always leave them at risk of confused users or broken handsets. Remember, the operator is the first line of support. Large rollouts are costly for them. With the desktop model, people call their manufacturer or developer first, not their ISP or OS maker; the opposite is true for phone apps and carriers.

Where Do We Go From Here?

The exact nature of how this will play-out is unknown. Claims that everything will settle down and become totally managable are likely overly optimistic. Will the Android team truly be able to add new platform features through add-ons rather than full platform upgrades? Hopefully, but we'll see.

Android Wireless Application Development Review: The Best

Edmon at Toolbox for IT recently posted a review of our first book, Android Wireless Application Development. He says, in this blog post:

Android Wireless Application Development is so far, in my opinion, the best book for all interested in learning about almost all aspects of application development on Android.

Thanks, Edmon!

Korean Translation of Android Wireless Application Development Available

한국어를 아시나요? According to Google Translate, that's something close to "Do you know Korean?"

We ask because our book, Android Wireless Application Development, is now available in Korean!

However, the cover implies that the book supports Android SDK 2.0 (and it is Android 2.0/2.1 compatible for the most part). In fact, it was written to Android SDK 1.5r3, but we are currently working on updating it to Android SDK 2.1 (or later). Stay tuned!

UPDATE: Turns out, what the cover says is that there is a new appendix (not written by us) that talks about updates to 2.0. Interesting!