As a reviewer, I found it interesting to see other people’s approaches, offering just a bit of guidance here and there to follow common/best practices used my most Android developers. In one chapter in particular, you learn how to create a game called SpotOn that makes use of property animation (from Honeycomb) to create moving targets. This is a great use of property animation that not only demonstrates a core feature in Honeycomb, it also shows how easily you can use the SDK to accomplish what would otherwise take a lot more code.

If you’re considering learning Android app development or know the basics but want to broaden your understanding, definitely take a look at Android for Programmers: An App-Driven Approach. (And I don’t earn any royalties; I just love the “real code” approach that this book takes.)

OMG! The emulator is slow!

There are two things to note here: the default AVDs tend to have limited resources and the devices you’re targeting are likely running with a different chipset than the computer you’re developing on. The first limitation can be easily overcome; the second is a much bigger issue, particularly with Android 3.x and attempting to develop for Honeycomb tablets without actually having a Xoom, Asus Eee Pad Transformer, etc. Currently, it’s not very feasible to develop a 3.x app without a tablet.

Back to that first limitation: When creating a new AVD, you can specify hardware settings, which can dramatically improve performance. The most important setting is the device RAM size; I tend to want the emulator to be as fast as possible, relying on on-device testing for a sense of “real-world speed,” so I usually give my phone emulators 512MB of RAM. That’s the equivalent of most good smartphones from 2010. The 1.x AVDs seem to run fine on 256MB, so you can potentially drop to that if your machine is limited (the Motorola Droid/Milestone had 256MB of RAM as well). You can also try upping the cache partition size (128MB is a good start) and the max VM application heap size (48 is plenty) for a minor improvement.

LinearLayout mistakes

LinearLayout is a very useful and very simple ViewGroup. It essentially puts one View after another either horizontally or vertically, depending on the orientation you have set. Set an orientation!

LinearLayout defaults to horizontal, but you should always manually specify an orientation. It’s very easy to throw two Views in there and not see one because the first View is set to match_parent for width. That said, LinearLayout also processes layouts linearly, which is what you’d expect, but that means that setting a child View to match_parent can leave no room for subsequent Views. If you aren’t seeing one of your Views in a LinearLayout, verify you’ve set the orientation and that none of the Views are taking up all the available space. Within a LinearLayout, you should generally rely on layout_weight to “grow” the View. Here’s an example:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_height="match_parent"
  android:layout_width="match_parent"
  android:orientation="vertical"
>
    <SomeView
      android:id="@+id/childview1"
      android:layout_height="0px"
      android:layout_weight="2"
      android:layout_width="match_parent"
    />

    <SomeView
      android:id="@+id/childview2"
      android:layout_height="0px"
      android:layout_weight="3"
      android:layout_width="match_parent"
    />
</LinearLayout>

The heights are set to 0, but both child Views have weights. The first has a weight of 2 and the second has a weight of 3. Out of a total of 5, the first is taking 2 (40%) and the second gets 3 (60%), so their heights will actually use that portion of the parent View’s space (if that View has a 100px height, the first child will be 40px tall). The weights are relative, so you can set whatever values make sense for you. In this example, the second layout could have had a set height and no weight and the first could have had a weight of 1, which would have made the first take up all space that the second didn’t use.

Stupid Android! It keeps restarting my Activity!

The default behavior when a configuration change happens (e.g., orientation change, sliding out the keyboard, etc.) is to finish the current Activity and restart it with the new configuration. If you’re not getting any dynamic data, such as loading content from the web, this means you probably don’t have to do any work to support configuration changes; however, if you are loading other data, you need to pass it between configuration changes. Fortunately, there’s already a great post on Faster screen orientation changes. Read it and remember that you should not pass anything via the config change methods that is tied to the Activity or Context.

Density

Density should only be considered in terms of density not size. In other words, don’t decide that MDPI means 320px wide. It doesn’t. It means that the device has around 160dpi like the G1 (320px wide) and the Xoom (1280px wide). Fortunately, you can combine multiple qualifiers for your folders to give precise control, so you can have a drawable-large-land-hdpi/ containing only drawables that are used on large HDPI devices that are in landscape orientation.

One other important thing to note: Support for different screen sizes and densities came in Android 1.6. Android 1.5 devices are all MDPI devices, but they don’t know to look in drawable-mdpi/ because there were no different densities then. So, if you’re supporting Android 1.5, your MDPI drawables should go in drawables/. If your minSdkVersion is 1.6 or above, put the MDPI drawables in drawable-mdpi/.

What the heck is ListView doing?

A full explanation of ListView would take quite a while, but here’s a quick summary: A ListView’s associated Adapter’s getView method is called for each child View it needs to construct to fill the ListView. If you scroll down, the top View that leaves the screen is not garbage collected but is instead passed back to the getView method as the “convertView” (second param). Use this View! If you don’t, not only does it need to be garbage collected, you have to inflate new Views. You should also use the ViewHolder paradigm where you use a simple class to store View references to avoid constant findViewById() calls. Here’s an example:

@Override
public View getView(int position, View convertView, ViewGroup parent) {
    final ViewHolder holder;
    if (convertView == null) {
        convertView = mInflater.inflate(R.layout.some_layout, null);
        holder = new ViewHolder();
        holder.thumbnail = (ImageView) convertView.findViewById(R.id.thumbnail);
        holder.title = (TextView) convertView.findViewById(R.id.title);
        convertView.setTag(holder);
    } else {
        holder = (ViewHolder) convertView.getTag();
    }

    final MyObject obj = (MyObject) getItem(position);
    holder.thumbnail.setImageDrawable(obj.getThumbnail());
    holder.title.setText(Html.fromHtml(obj.getTitle()));

    return convertView;
}

/**
 * Static ViewHolder class for retaining View references
 */
private static class ViewHolder {
    ImageView thumbnail;
    TextView title;
}

This method is first checking if the convertView exists (when the ListView is first laid out, convertView will not exist). If it doesn’t exist, a new layout is inflated with the LayoutInflater. A ViewHolder object is instantiated and the View references are set. Then, the holder is assigned to the View with the setTag method (which essentially allows you to associate an arbitrary object with a View). If the convertView already exists, all that has already been done, so you just have to call getTag() to pull that ViewHolder out. The “bulk” of the method is just grabbing MyObject (whatever object your Adapter is connecting to) and setting the thumbnail ImageView and the title TextView. You could also make the ViewHolder fields final and set them in the constructor, but I tried to keep this example as simple as possible. This method no longer requires View inflation while scrolling nor does it require looking through the Views for specific IDs each time. This little bit of work can make a huge different on scrolling smoothness.

One last thing about ListViews… never set the height of a ListView to wrap_content. If you have all your data locally available, it might not seem so bad, but it becomes particularly troublesome when you don’t. Consider the above example but instead of the setImageDrawable call, it triggers an image download (though it’s better to have the Adapter handle that). If you use wrap_content on your ListView, this is what happens: The first getView call is done, convertView is null, and position 0 is loaded. Now, position 1 is loaded, but it is passed the View you just generated for position 0 as its convertView. Then position 2 is loaded with that same View, and so on. This is done to lay out the ListView since it has to figure out how tall it should be and you didn’t explicitly tell it. Once it has run through all of those positions, that View is passed back to position 0 for yet another getView call, and then position 1 and on are loaded with getView and no convertView. You’re going to end up seeing getView called two or three times as often as you would have expected. Not only does that suck for performance, but you can get some really confusing issues (e.g., if you had been passing a reference to an ImageView with an image download request, that same ImageView could be tied to all of the download requests, causing it to flicker through the images as they return).

The problem was actually that I use my GAFYD email address on my Android devices; however, logging in with it would then show my older @gmail.com email address at the top. Continuing to search, I found that your Google Apps account has to be transitioned to the new system. Basically, Google Apps accounts used to be second class citizens, unable to use many of Google’s services. Unfortunately, I had tried to transition a couple of months ago and got this message:

I clicked “Learn more” and found that the page basically said that I had a conflicting account. I read another page to finally understand the problem.

Let’s say my email address was me@example.com. Before using GAFYD, I used my own server for handling mail, so me@example.com existed before my Google Apps account did. At some point, I used a Google service and associated it with my me@example.com address. When my me@example.com email address was supposed to be transitioned to a full fledged Google account, the system saw that email address already used, creating a conflict.

I found four steps to resolve the conflict:

1. Visit www.google.com/accounts and sign in with your personal Google Account
2. Click ‘Change email’ under ‘Personal Settings’
3. Enter a different email address where you can receive mail, enter your password, and click ‘Save email address’
4. Check your other email address and click the link in the verification message from Google to confirm your change

I signed in and found that my GAFYD address was listed as an alternate email address for my old @gmail.com account. I simply removed the me@example.com address, since it was little more than an alias. I then tried to sign into www.google.com/accounts with that address and it failed, so I knew it was no longer associated with any Google services. After that, I just had to pick to transition my account again. A few minutes later, it had succeeded. I logged into the Android Market and was able to see my devices:

All is well again.

SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"

You may need to run sudo reload udev and/or disconnect and reconnect the N1. Check adb devices again and hopefully you’ll see “HT9CSP123456 device” or similar.