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.
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.
In any event, since we’re just getting started, we’ll take the defaults. On the next screen, you’ll be asked if you want to create a custom launch icon and activity, and if you take the defaults, the next screen will let you specify what icons you want to use. Leaving those set at defaults, you finally get to another screen you may recognize from your iOS days. You’re being asked to select what kind of activity you want to create. When you hear activity in Android, think “View Controller.” You really only have two choices, if you picked Froyo for your minimum version, because the Master/Detail flow only became available in Honeycomb. One is a full screen activity, which hides all the normal Android top and bottom content, and the other is a blank activity, similar to an empty view controller project in iOS.
If we pick a blank activity, we need to choose an activity name, a layout name (kind of like an XIB file), and a navigation type. We’ll leave everything as is, following the directions in the tutorial. Once you finally hit finish, you’ll be dropped into Eclipse with the layout editor for your main screen open:
The final step for today will be to try running our new Android application. Since we’re all iOS developers here, I’m going to assume that none of us is carrying an Android device on our person, so we’ll be using the emulator. You first need to create a virtual device by launching the Android Virtual Device Manager, which hides in the Window toolbar item. Once launched, you select the
New... button to open the new device dialog. There are a few interesting options here, including using your system’s webcam to fake a front and rear phone camera. For the moment, I’ve created a Nexus 4 emulator.
Once the device is created, you can select it and hit
Start from the device manager. Another thing that iOS developers are going to have to get used to is the long startup time for the emulator. Think minutes, not seconds. For this reason, it’s a good idea to keep the emulator up while developing, so you’re not constantly waiting for the emulator to boot up. Finally, go back to Eclipse, and select
Run->Run As... Pick
Android Application, and your application should install into the running emulator and start.
Next time, we’ll actually start to build some functionality into our application, and see just how different Android development is from iOS.