James Turner

Now that our Android app lets you choose what planet you’re on, we should use that information to update our “Hello, world” message based on the selection. To do that, we’re going to need to handle the selection event on the spinner we created.

To do this, we need to set the setOnItemSelectedListener property on our spinner to something that implements the OnItemSelectedListener interface. The simplest way to do this is to implement it in our activity.

public class MainActivity extends Activity 
                               implements OnItemSelectedListener {
.
.
.
boolean spinnerActive = false;

public void onItemSelected(AdapterView<?> parent, View view, 
            int pos, long id) {
    	if (!this.spinnerActive) {
    		spinnerActive = true;
    		return;
    	}
    	TextView message = (TextView)findViewById(R.id.textView1);
    	String planet = (String) parent.getItemAtPosition(pos);
    	if (planet.equalsIgnoreCase("pern")) {
    		message.setText("Hello, Lessa");
    	}
    	if (planet.equalsIgnoreCase("barsoom")) {
    		message.setText("Hello, John Carter");
    	}
    	if (planet.equalsIgnoreCase("equestria")) {
    		message.setText("Hello, Twilight Sparkle");
    	}
    	if (planet.equalsIgnoreCase("ringworld")) {
    		message.setText("Hello, Louis Wu");
    	}
    }

    public void onNothingSelected(AdapterView<?> parent) {
    	TextView message = (TextView)findViewById(R.id.textView1);
    	message.setText("Hello, World");
    }

This is pretty straight-forward stuff. You use the parent.getItemAtPosition call (where parent is the spinner) to get the item that you selected. The item is just the string value of the selection, so we can use a simple string compare to select the appropriate message. In the same way that we got the spinner using it’s id, we can get a handle on the text view at the top of the screen, and then set the message using setText.

There are a couple of things to point out here, however. For one, the onItemSelected message gets called when the widget is created, a fact that irritates the heck out of Android developers. This means that you need to ignore the first call to the method. Thus, the purpose of the spinnerActive flag. Secondly, because we’re using the Activity as the listener, you could end up with problems if you have multiple spinners on the screen, since they would all call the same listener. You could either use the AdapterView value to determine which spinner fired the event, or use private inner classes to handle the various spinners.

Now that we’ve got our listeners implements, the last step is to tell the spinner to use the Activity as the handler.

    protected void onCreate(Bundle savedInstanceState) {
.
.
. 
     spinner.setOnItemSelectedListener(this);
    }

Now when we fire up the app and select a value from the spinner, we get a personalized welcome message!

Like many hardcore iOS developers, I’ve eschewed learning “the other platform” because I was happy in Apple-land. In addition, the few forays I’ve made into Android development seem to show that it was a more complex and difficult platform to work with. However, recent developments (e.g., a new job) have placed me in a position where I’m going to need to have at least a casual familiarity with Android development, so I thought I’d bring you all along on my journey.

Getting the Development Environment Set Up on OS X

The good news is that, unlike iOS, Android is a development-platform agnostic OS. If you go to the Android developers site on a Mac, you’re going to be immediately presented with the option to download a zip file with the complete Android Developer Tools package. Fair warning that it’s pretty large, nearly 400MB. Of course, for folks used to downloading multi-gigabyte XCode drops, that may seem pretty reasonable.

Once it’s downloaded, unzip the file and move the resultant adt-bundle-mac folder into somewhere permanent. The install documentation recommends the /Developer folder, but since /Developer has been deprecated lately, you might want to just create a top level /Android folder instead.)

# sudo mkdir /Android
# sudo mv adt-bundle-mac-x86_64-20130522 /Android/
# cd /Android/adt-bundle-mac-x86_64-20130522/eclipse/
# mv Eclipse.app ADT-Eclipse.app

One additional step I took was to rename the version of Eclipse that ships with ADT to ADT-Eclipse. I already have a version of Eclipse that I use for general Java development, and I don’t want to launch the wrong one from Spotlight accidentally.

Once you’ve finished installing ADT, you can launch their version of Eclipse from Spotlight and, just like every other version of Eclipse, the first thing you’ll be asked is where you want to create your workspace. Just as with the renaming of the Eclipse application, I gave my workspace a unique Android-y name, and told Eclipse not to ask me again. This should prevent me from accidentally opening my normal Java development workspace.

Writing Your First App

Once Eclipse launches, it’s going to ask you if you want to send anonymous statistics to Google. This is a choice between you, your maker, and the NSA, so choose whatever makes you feel happy. The next thing that you’ll be presented with is a welcome popup, with the option to either create a new Android app, or run through some basic tutorials.

The tutorials aren’t actually built into the ADT. Instead, clicking on one of the links will bring you to a web page with a walkthrough. There’s not a lot of value in having me take you through a tutorial that’s already been written in detail, so I’ll hit the high points.

To start, create a new Android project. If you still have the welcome screen up, you can do that by clicking on the New Android Application... button. Otherwise, you can get to it from the File->New->Android Application Project toolbar item. You’ll immediately be presented with the New Android Application dialog.

The Android New Project Screen

There are a couple of important decisions you need to make here. The first is the package name for the project. This is equivalent to the bundle identifier in iOS development, and it needs to be unique. Luckily, iOS chose to adopt a Java-like reversed domain-name structure for bundle identifiers, so you should already be familiar with this concept.

The other big decision is the minimum version of the SDK that you will support. In iOS, we’re used to dropping support for old versions of iOS on a regular basis. Most iOS developers don’t support iOS4 anymore, and it’s not uncommon to see iOS6 as the required version for newer apps. This is because Apple has been very aggressive about carrying forward devices to new versions of the operating system; about the only things left behind by iOS6 were the original iPad and some iPod touch models.

By contrast, most Android users are at the mercy of their carriers for OS upgrades, and the story isn’t pretty. If you check Google’s own adoption stats, nearly half of all Android users are still stuck back on Gingerbread, a release now more than two years old. And, in fact, the wizard recommends you go back even further, to Froyo.

Does this mean that you can’t take advantage of the latest and greatest features in Android, and still deploy an app that the majority of users can run? No, but it does mean that you’re going to have to fail gracefully when new features aren’t available. iOS developers have had to occasionally do this in the past. For example, when new callback methods were delivered in iOS6, we had to keep both versions around to make iOS5 work. But the long, long version tail of Android means that you will have to take this practice to the next level.
Read more…