I finally got a chance the other day to sit down and spend some quality time with the Android SDK, and I have to admit, I really like what I see so far. Now, I use Eclipse all day at work for my development environment and so whenever I get the chance to do a little "hobby" programming I usually try to avoid it (I also usually try to avoid Java for that matter, but that's another rant altogether). So, in the interest that anyone else out there would like to do the same and develop an Android application without all the overhead of installing the Eclipse development tools and using Eclipse to manage your project, I'll be showing you how to do so in this post. So, let's get started by installing the Android SDK and getting our first Android application up and running using nothing but the SDK and text editor.
Installing the Android SDK
To develop programs using the Android SDK you'll need a few things on your system. First, and most obvious is a recent Java Development Kit. I'm running JDK v1.5, and a quick glance in the build.xml file suggests that the SDK targets the 1.5 version of the JDK (at least on OS X it does). Next, you'll need the Apache Ant build system to build your Android applications. Finally, you'll need the Python programming language (v2.2 or later) to run many of the scripts that come with the Android SDK such as the activitycreator script that is responsible for creating a base Android project for us. If you want to do any serious development for the Android platform, you'll also want to download the Eclipse IDE (v3.2 or later) and the Android Eclipse Tools plugin, but for this post we're going to use just a simple text editor to do all of our work (I'll be using TextMate since I'm on a Mac). Everything is that we'll need is provided by the SDK. Now let's get the SDK installed and create our first application.
The rest of this section goes over the installation of the SDK on a *nix based system, so if you're on a Windows box, you may want to skip the rest of this section and instead read over the Windows install instructions found on the actual Android website.
Start by downloading the SDK package for your chosen development environment. There's absolutely nothing to installing the SDK. Basically, you just unzip the file you downloaded and move the directory someplace where you want to store it (I put mine in my /usr/local directory). The following are the commands you'll need to do all of that:
After you've moved the SDK directory to your chosen location, you'll need to add the tools directory to your PATH environment variable. Depending on how your .bash_profile file is setup, you can either add it to .bash_profile or .bashrc. I personally prefer keeping everything in my .bashrc file, so I setup my .bash_profile file with the following lines to have it execute my .bashrc file upon login:
If you've added the above to your .bash_profile, add the following line to your .bashrc files, otherwise add it to your .bash_profile file:
Once you've added the above to either your .bash_profile or .bashrc file, you can source it and have your environment updated with the new PATH information.
% source ~/.bashrc
You now have the Android SDK installed on your system and you can begin creating your very first application for the now Mobile OS, so let's go ahead and do that now.
Creating Your First Android Application
All the tools you'll need to create an Android application are available to you from the command line, the Eclipse Development Tools just provide a nice wrapper around everything, but for those of you comfortable with the command line and build tools such as Apache Ant, developing Android applications without Eclipse will be really straight forward. How straight forward you ask? Well try this on for size:
That's it. That is literally all there is to creating, building, and installing an Android application onto a mobile device. So what just happened here? Let's walk through each of the above lines and find out what took place.
First, we called the activitycreator script. If you're on a *nix based system, this will be a Python script (we all know how much Google loves Python) and if you're on a Windows system (I'm sorry, BTW) then this will be a batch script. This script just creates the bare bones Android project and the Ant build script that you'll be using to build and install the application. Notice that you specified the name of the project with the -o (or --out, if you prefer a more verbose command line) option. The second portion of the command---com.android.hello.HelloAndroid---specifies the main class and the package in which it will reside. The script is named activitycreator because, as you'll see shortly, the script is creating an Android Activity for us, which is basically synonymous with a single screen in your application.
After we create our new project, we cd into its root directory and start the Android emulator as a background process. Then we run the ant install target which will build and install our new application on the running emulator. We could split this out into separate build and install commands if we wanted to by using ant to build and package the application into an .apk file and adb (the Android Debug Bridge) to install the application on the emulator, but this is the most convenient way to get the app on the phone as quickly as possible. The reason I mention the other options is that the adb tool allows you to specify the device upon which you wish to install your application which may come in handy later when your developing with both a piece of actual hardware and the emulator simultaneously.
Now that we have created our very first application and understood the process that got us there, we can start digging a bit deeper into the development of Android applications. We'll do that next by starting with an in-depth look at the directory structure that was created for us by the activitycreator script.
What's in an Android Project
Let's take a look inside of the HelloAndroid directory that activitycreator created for us and see what a simple Android application project looks like. Below is an image of the directory structure of our sample project as it looked when it was freshly created by the activitycreator script (i.e., yours may look slightly different since you've already built your sample app).
Most of what you see in the image above is self explanatory. The build.xml file is the Ant build script for the project. Go ahead and open it up and see what targets are available to you. There are several useful targets for doing everything from simply compiling the Java files to generating the resource class (R.java) for the resources in the application, but the two you'll find most useful are the install and reinstall targets. The bin directory is where the product of running the build script (i.e., the *.apk package, *.class files, and the Android byte code---*.dex files) are located. The src directory is where you'll find the actual *.java files and where you'll be spending most of your time when developing applications for the Android OS. The libs directory is where you'll store any third party libraries you wish to use in your application. That just leaves us with the AndroidManifest.xml file and the res directory, both of which are unique to Android, so I'll go over these in a little more detail below.
We'll start with the AndroidManifest.xml file. This file contains references to all of the global values in your project as well as the major components of the application. So, you'll find things here like the path to the icon to use for the application and a list of all the Activities in your application. An Activity is what your application is made out of, by the way. It can be thought of as one unit of activity between your app and the user. So, typically a single screen and the actions available to it will be an Activity, and all Activities in the application must be listed in this file even if they are not visible to the user but used only internally by your application. This isn't really an issue if you use the Eclipse toolset for all of your application development as the tools will keep this file up to date for you whenever you add new Activities to your app, but if you're doing everything from the command line, you'll need to manage this file by hand.
The res directory is interesting because of what's inside. You'll notice in our sample application that there are two directories within the res directory, the layout directory and the strings directory. The strings directory is where you store most of the string values for your application. I am assuming that the reason for partitioning the strings away from the code is for localization purposes, but I'll have to dig a bit deeper into the documentation to find out for sure.
The layout directory does for your GUI elements what the strings directory does for the strings in your application---it separates them from the code. In this directory you'll find an XML file for each of the graphical components in your application. I'm a little confused about the decision to move the interface components into a separate XML file rather than just constructing the GUI in code. I understand the MVC arguments, but you can program a perfectly MVC compliant application solely in code, so the move to XML isn't necessary for that alone. The only thing that I can figure out here is that the XML based UI was done to make it easier for designers to create the interfaces rather than developers and/or to make it easier to integrate the interface development with a drag 'n drop interface builder such as Matisse in the Netbeans IDE (which I believe also uses XML to store its user interface components).
By the way, while we are on the subject, you don't actually have to use either of these directories in your development. You could just store all of the strings directly in the application and do all of your GUI creation directly in the code, but I'm sure that if you are using the provided Eclipse development tools it will be easier to not go against the grain. Nevertheless, for our purposes, that is, to get a little taste of what's going on inside of the Android development platform, I think its a good idea to do a bit of both just to have a better understanding of what's going on under the hood. In the next section we'll modify our application slightly using both the XML based method and the pure code method to get a real feel for how GUI's are designed in Android.
At Last, Some Code!
Up until now we've literally done no coding whatsoever to create a working Android application. Now, however, we are going to modify our project ever so slightly to try to get a better idea of how to develop an Android application. The application we are going to create is a very simple app that has a text box allowing the user to input a line of text, and a button that, when clicked, will execute a simple callback function that will take the text the user entered and print it to a separate text view below our simple form. The application I'm describing will look like the following image when we're finished.
There are two ways to create the GUI for our application as I've described above and we'll cover both in detail in the next two subsections. We'll begin with the pure code method of creating a GUI as that will likely be the most natural to most of us familiar with designing a traditional Java GUI using Swing. Then we'll cover the way that UI's are supposed to be created in Android with the use of XML.
HelloAndroid - Pure Code GUI
To create our GUI using nothing but code, we'll begin by creating the main layout object for the components in our application. If you've done any Swing programming in the past, you're probably used to the idea of designing your GUI's using several layout managers. Android's GUI's work in much the same way. We'll be adding our code to the onCreate method that was created for us by the activitycreator script since that is where all of your Activity initialization code should reside. To add the main layout, you'll first need to import the LinearLayout class from the android.widget package. LinearLayout is just what it says---it's a layout object that allows the developer to layout their widgets in a linear fashion using either a vertical or horizontal orientation. This layout is essentially the same as the Java FlowLayout manager if you're familiar with Swing. After you've added the layout import statement to your application, you can proceed to adding the actual layout object. Once you've done that your onCreate method should look like the one below:
One thing you'll notice here is that we've replaced the R.layout.main ID that we were using before to set our content view with the newly created layout object. the setContentView method is overloaded to accept either a View object (which LinearLayout inherits from) or an integer representing a layout resource (i.e., an XML file that resides in the res/layout directory). Previously we had set the content view using a layout resource and we will be doing so again in the next section, but for now we are setting the content view with an actual View object. Doing this means that our application will now ignore the layouts that we have in the res/layout directory. Go ahead and run the ant build and install script again to see that we are no longer seeing the "Hello, world, HelloAndroid" message that was in the XML version of or GUI. One thing to note here is that since you've already installed the application on the emulator before, you'll get an error stating that the app is already installed, to bypass this and install it anyway use the reinstall target from the build script like so: ant reinstall. One more thing to notice before we move on, is that we've set the orientation of the layout to be vertical (i.e., the widgets are placed in the layout from top to bottom), we only need to do this for vertical layouts since the default orientation is horizontal for the LinearLayout class.
Now that we've added the main layout view for our application we need to go ahead and create the rest of the GUI components. We'll need an EditText view to allow the user to enter some text, a Button to trigger our action, and a TextView to print up the results of our action. We're going to also add another LinearLayout view, but this one will have a horizontal orientation. This will allow us to layout our EditText and Button views in the same row. Here is how your onCreate method should look after adding the code for everything listed above:
Given what we've seen so far, there's nothing really very new here. You are seeing how we add a view to a layout here with the addView method and you're also seeing how to set a few of the attributes of our widgets here as well. One thing to take notice of though is that we have made both of the text views final because we need to use them in a method in our anonymous abstract class we've created for the button's callback method, otherwise you'll get a compiler error.
Below is the final product with all of the necessary import statements. If you're lazy, you can just copy and paste the code directly into your HelloAndroid.java file and run the ant reinstall target again to see the fruits of your labor.
HelloAndroid - XML Based GUI
In this section, we're going to create our GUI the way that Google intended it to be done, with XML. If you've ever done any type of web development, especially with a Java based framework such as Struts or WebObjects, then this style of developing a GUI will feel fairly comfortable to you. Nevertheless, I'll go ahead and go over all of the steps that we need to take to get our app up and running with an XML layout.
First, you'll need to create the layout file and design your GUI in XML using the attributes defined by the android XML namespace. Then, you'll tell your application to use the layout you created to render the GUI. Finally, you'll need to get a handle to any of the GUI elements to which you may need to add actions such as our callback method for the "Click Here" button.
Since we already have a layout created for us by the activitycreator (remember that res/layout/main.xml file) we are going to start with the second step and tell our application to render our GUI using that layout resource. Go ahead and wipe out all of the code in your onCreate method that we added in the previous section---basically, everything but the line to call the onCreate method of the parent and the line setting the content view. Then we'll change the line setting the content view back to the way it originally was when it was using the layout. The resultant file should look like this:
By running the ant reinstall target again you should be able to verify that you've gotten the code right and when the application is selected on the phone, you should be staring at our original application with the "Hello, World, HelloAndroid" message in the TextView. Before we continue, let's take a little closer look at what's going on with the setContentView method. If you remember, in the previous section, I stated that this method was overloaded to accept either a View object or an integer value representing a resource. What we are passing in here is the integer value that represents our main.xml layout. This ID was created for us by the SDK when we built our application. Take a look in the R.java file in the src directory (you should find it in the same directory as the HelloAndroid.java file). Inside of this file, you'll see a set of resource identifiers for our application, one of which will be the ID for the main layout. So by passing in R.layout.main to our setContentView method, we are telling our application which resource (in this case, a layout resource) to use to generate our GUI. I won't go into any more detail here on how that GUI is generated from the XML, but suffice it to say that for performance purposes (as XML files can tend to be quite large), the actual XML file is not included in the application package (aka, the *.apk file) but rather a binary version of the file is created at build time and included in the application package.
Let's move on and begin designing our interface for our application using XML. Below is the final version of the main.xml file that you should have in your res/layout directory. Go ahead and copy and paste the markup below into that file and we'll go over the details of the file after the break.
If you've used XML before you'll recognize the first line. Basically, you're just stating the version and character encoding scheme for the file. The next line is important. You'll always want to make sure that you set the xmlns:android attribute of the root tag in your layout document to "http://schemas.android.com/apk/res/android". What this does is declare the android namespace and allow you to use the attributes defined by the Android SDK (you can find a listing of those attributes here).
After those first two points the rest is pretty self-explanatory. We are declaring again a LinearLayout with the orientation set to vertical to be our main layout. Then we create a second horizontal layout to hold the EditText and Button items and embed it within the main LinearLayout. Finally we add the TextView to our main layout just as we did in code. The only other issue I would like to point out here is how we get a hold of a GUI element from within the code if we've constructed the GUI in XML. To do that we need some way of identifying the individual elements. That can be done by adding the android:id="@+id/element_name" attribute that we see in some of the elements above. The android:id attribute tells the SDK what the ID for a particular component is, and by specifying @+id in our id clause, we are telling the SDK that we want it to generate a unique identifier for us for that particular element. To see it in action flip back over to the command line and run the ant resource-sr target to build the R.java file for your application. After the build finishes, switch back over to the source files and open up the R.java file. In it you'll notice that the recent build has added a new static class for our unique ID's, inside of which, you should see three new ID's, one for each of the elements on which we added the android:id="@+id/element_name" attribute. These ID's will be how we get a handle on our GUI elements from the code. Again, go ahead and run the ant reinstall script and take a look at the application, now you should see the GUI the way we designed it in the previous section, but now we are creating our GUI in XML rather than code.
The final task for us today, before we call this little exercise complete, is to add an action to our GUI. To do this we'll have to get a handle for each of the elements that we specified in our XML file and then set the callback method just the same way that we did in the last section when we crafted everything in code. The code below is the final version of our HelloAndroid.java file, so go ahead and copy and paste it over to your project and do another reinstall to see the GUI actually working.
Everything above should look pretty familiar to you from the previous section. Two things to note though are that we call the setContentView method before doing any other work, whereas in the previous section we called it last. The reason for this is that you need to make sure that GUI elements actually exist (I believe the phrase is the GUI has been inflated) before trying to get a reference to them. Second, you'll notice the findViewById method is being used to actually get a reference to each of the elements. This is a method of the Activity class and it will expect an integer value to be passed into it. The value that we will be passing in will be the unique identifier that was created for us by the SDK and that can be found in the R.java file. Also, this method returns a generic Object so you'll need to make sure that you cast the returned object to the type of GUI element that you are expecting.
The only thing left to do now is to run the ant reinstall target one last time and test out our application. Once you've verified that the callback function is indeed working you can sit back and take a well deserved break while I briefly go over all that we've covered today and give you my closing thoughts on the platform and its future.
Conclusion
In this post, we've gone from being absolute Android amateurs to understanding quite a bit of what's going on in the SDK. We've developed a very simple application for the Android platform using the recommended methodology (i.e., XML based GUI design) and we've also written our GUI in pure code to get a better understanding of what the SDK is doing for us. Along the way we've learned a few things about the makeup of an Android project and gotten our hands a bit dirtier than we normally would when developing an Android application by doing it all without the help of the intended IDE.
I've really enjoyed the time I've spent so far with Android. I've found it to be a very clean and intuitive SDK. It's beyond easy to get a simple application up and running as soon as possible, so much so that, at times, I felt like I was working with Ruby on Rails rather than a typical Java framework. All in all, I really like the Android framework so far and in a future post I hope to compare and contrast Apple's mobile offering to Google's. With news that Google is going to introduce a content distribution system similar to Apple's App Store with the exception that it will be totally open to developers, and with an actual piece of hardware slated for the market in October, it looks like the OS and its accompanying SDK are going to be of major interest to developers in the coming months. That said, I hope this article has been able to whet your appetite and give you enough of an insight into Android development to get you started down the path to becoming an Android guru.