X Forward

Android for iPhone Developers - Part 1

Apr 4, 2009

Familiar with iPhone application development? Want get your learn on with Android? Then this article is for you.

Android Development for iPhone Developers

Learning a new development platform can be a time-consuming and frustrating experience. Especially after you’ve invested so much time learning one platform, just to have a new pop up. We all know the troubles, not every platform vendor has the same idea of how certain fundamental architectural concepts should be implemented, namely MVC (model-view-controller). And often times the documentation is either sparse, or so vast that you don’t know where to start.

That is why I am writing this article. To help you recycle as much of your learned iPhone knowledge into building Android applications. Thus, this article is intended for developers who have a firm grasp of the iPhone development platform and its key concepts. It will also help if you have at least a small familiarity with Java fundamentals like packages and such (if you’ve never used Java before, don’t worry, keep reading you should be able to keep up).

If you have developed applications for the iPhone OS, then you are familiar with how Apple has chosen to implement MVC, and what classes and interfaces they provide with the SDK. So you’re probably comfortable with how views are managed by the system and how to perform expensive tasks using timers, delegate callbacks, and sometimes threads. But will this knowledge carry over to the Android world? Or will you have to start from scratch all over again?

Hopefully, the concepts I outline in this writing will allow you to recycle a significant amount of your iPhone development knowledge so you can spend more time building your application, and less time building “hello world”.

The IDE
This is a good place to start. There’s a big difference in development environments for Android and iPhone. The most obvious and glaring one is that Android is a Java-based platform. So, you can kiss XCode and Interface Builder goodbye and give Eclipse a big hug hello (OK, that was corny, but you get my point).

Eclipse is the recommended IDE for building Android applications (recommended by Google, and myself). You’ll be happy to know that Eclipse runs on OS X flawlessly, so you won’t need to dig up a Windows PC to do your Android development.

Getting it all set up is not very difficult, and I’m not going to outline the process of downloading, installing, and configuring it. I trust that if you’re reading this article that you know how to do that (installation instructions can be found here: http://developer.android.com/sdk/1.1_r1/installing.html). So, on to the basics.

The Starting Line
You need to start somewhere, so the best place is with a really simple application. Actually, I’m going to use an empty Android application, as created by the Android Eclipse plugin, to explain key concepts. So, let’s make one.

Launch Eclipse, then go to File->New->Project and select “Android Project”. Enter a project name, package name, activity name, and optionally an application name (the project name will be used as the application name if this is left blank). Before you click “Finish”, let me explain what these fields are.

Project Name: Pretty self-explanatory, this is the name of the project as it will appear in the left hand pane.

Package Name: If you’re familiar with Java packages, skip to the next item. If not, here’s a real simple explanation. In Java every class must exist in a package. A package is really just a directory hierarchy where you’re source code will be stored. So, a package named foo.bar.baz is really just a directory structure of foo/bar/baz. And any classes in that package would be in the last node of that tree. The most common and accepted naming convention for packages is the reverse domain name. You know the appID you created in the iPhone developer portal? Well the package name should be basically the same. For example, my android projects use com.xforward.android.ApplicationName as their base package.

Activity Name: This should be completely new to you. What the heck is an Activity? Think of it as a UIViewController. Without a subclass of UIViewController your iPhone app isn’t going to do much, right? It’s where all the logic that controls your view lives, getting data from the model and bubbling it up to the view. That’s what an Activity is, it’s a view controller. This particular field wants to know the name of your main Activity, the Activity (or view controller) that will be the first instantiated and shown to the user when the application is started.

Application name: This is the visible name of your application. It will be shown under the application icon in the OS.

Now click “Finish”. Not so bad right? Good. On to more good stuff.

AndroidManifest.xml WTF is that?
This is a very important part of every Android application. And by very important, I mean *very* important, as in your application is basically useless without it. So what is it’s purpose?

I struggled to find an analog for this file to the iPhone world and there really isn’t one. It’s kind of like an info.plist, but it’s a lot more than that. This is going to have to be one of those “from scratch” things you’ll have to learn. But don’t worry, the basics are easy to understand.

The AndroidManifest.xml file describes your application to the OS. It tells it about your root package so it can find classes to load, it tells it about your application icon and name, it tells it what class to launch when the icon is clicked, and a whole lot more. Let’s look at our sample one. Double-click on the AndroidManifest.xml, by default you’ll see the overview view, but we need to look at the actual XML so click on the “AndroidManifest.xml” tab at the bottom of the pane.
Find the “application” tag and take note of its attributes and child elements. The 2 attributes of the application tag define the application name and icon as will be displayed by the OS. The child element named “activity” is a little more interesting.

The activity tag declares an activity that will be used by the application. In this case our sample app only has one activity, the main activity. You can see that the name attribute is actually the class name of your activity (complete with leading “.”). Now look at the intent-filter child elements of the activity. We’re not going to get into intents right now, but just know that this particular intent defines our activity as the main activity that should be created on application launch.

What else goes in here? There’s quite a bit of stuff that goes into the AndroidManifest.xml file, but in the spirit of getting you up and running quickly, let’s just hit the 2 major ones.

More activities! I’d wager that most of your iPhone applications have more than one subclass of UIViewController, well the same is with android apps and activities. Say you application has a main menu view(controlled by your main activity), and a settings view. You’d want the settings view to be controlled by a different activity than the one that controls the main menu view, so you create a subclass of Activity. But that’s not all, in order for you to be able to use that second settings activity, you have to declare it in the AndroidManifest.xml file. If you don’t, you’ll get a runtime exception when you try to start the activity.

Declaring a new activity is easy, the most basic way is like so: