Getting Started With Android Development

I posted some time back about developing for Android and getting set up with the Android SDK, the Eclipse plugin, and all that. For the last six months, I haven’t really had time to get back to that. But now I’m starting to delve into Android development in earnest, so this (and potentially other upcoming posts) is going to be about my experience starting to write an Android application. I think I can offer some interesting perspective here. I am an experienced software developer with breadth of experience as well as depth in some technologies, but I am completely new to Android SDK. Hopefully, my experiences and overcome frustrations can help people in a similar position. This also means that you’d be learning along with me–it’s entirely possible that some of the things I post may be wrong, incomplete, or misguided in the beginning.

This post kind of assumes that your knowledge is like mine. I have a good, if a bit rusty from a year and a half of disuse, working knowledge of Eclipse and J2EE development therein. I’m also familiar with web development and WPF, so the concept of object-oriented plumbing code with a declarative markup layout for the view is quite familiar to me.

Notes about Setup

Just as a bit of background, I do have some things set up that I’m not going to bother going through in this particular post. I have Eclipse installed and configured, running on a Windows XP Pro machine. I also have, at my disposal, a Samsung Epic 4G running Android 2.3. (I forget the name of the food that accompanies this version, and, to be perfectly honest, something strikes me as sort of lame about naming your releases after desserts. Different strokes, I guess.) I also have installed ADB and the drivers necessary for connecting my computer to my phone. And finally, I have the Android virtual machine emulator, though I think that just comes with the Eclipse SDK plugin or something. I don’t recall having to do anything to get that going.

Creating a new Android project

One of the things that’s difficult when you’re new to some kind of development framework is separating what actually matters to your basic activities and what doesn’t. Any framework-oriented development, in contrast to, say, writing a C file and compiling it from the command line with GCC, dumps a lot of boilerplate on you. It’s hard to sort out what actually matters at first, especially if your “training” consists of internet tutorials and trial and error. So I’m going to note here what actually turned out to matter in creating a small, functional app, and what didn’t so far.

When you create a new project, you get a “SRC” folder that will contain your Java classes. This is where you’re going to put a class that inherits from “Activity” in order to actually have an application. I’ll get to activities momentarily. There’s also a “Gen” folder that contains auto-generated Java files. This is not important to worry about. Also not important so far are the “assets” folder and the Android2.1-update1 folder containing the Android jar. (Clearly this is quite important from a logistical perspective, as the Android library is necessary to develop Android apps, but it makes no difference to what you’re actually doing.)

The res folder is where things get a little interesting. This is where all of the view layer stuff goes on. So if you’re a J2EE web developer, this is the equivalent of the folder with your JSPs. If you’re a WPF/Silverlight developer, this is the equivalent of a folder containing your XAML. I haven’t altered the given structure, and I would’t suggest doing it. The layout subfolder is probably the most important, as this is where the actual view files defining UI components in XML go. In other subfolders, you’ll find places where your icon is defined and where there are centralized definitions for all display strings and attributes. (I haven’t figured out why it’s necessary to have some global cache of strings somewhere. Perhaps this is to take advantage of some kind of localization/globalization paradigm in Android, meaning you don’t have to translate yourself for multi-lingual support. Or maybe I’m just naively optimistic.)

The other thing of interest is the AndroidManifest.xml. This contains some application-wide settings that look important, like your application’s name and whatnot. The only thing that I’ve bothered so far to look at in here is the ability to add an attribute to application called “android:debuggable=”true”. Apparently, that’s needed to test out your deployable on your device. I haven’t actually verified that by getting rid of the attribute, but I seem to recall reading that on the Android Dev forum.

Those are all of the basic components that you’ll be given. The way that Android development goes on the whole is that it is defined in terms of “Activities.” An activity can loosely be thought of as a “screen.” That is, a very basic application will (probably, unless it’s purely a background service) consist of one activity, but a more complex one is going to consist of several and perhaps other application components like services or content providers. Each activity that you define in your application will require a class that extends the “Activity” class and overrides, at least, the “OnCreate(Bundle)” method. This is what you must supply to have a functioning application–at the very least, you must set your activity’s content.

To summarize, what you’re going to need to look at in order to create a hello world type of app on your phone is the Java file you’re given that inherits from activity, the main.xml file in layout, and the manifest. This provides everything you need to build and deploy your app. Now, the interesting question becomes “deploy it to where?”

Deployment – Emulator and Phone

I quickly learned that the device emulator is very, very slow. It takes minutes to load, boot, install your deployable in the virtual environment. Now, don’t get me wrong, the VM is cool, but that’s fairly annoying because we’re not talking about a one-time overhead and quick deployment from there. It’s minutes every time.

Until they optimize that sucker a little, I’d suggest using your phone (or Android tablet, if applicable, but I’m only going to talk about the phone) if it’s even remotely convenient and assuming that you have one. As I discovered, when you run your Eclipse project as an Android app, assuming you’ve set everything up right, the time between clicking “run” and seeing it on your phone is a couple of seconds. This is a huge productivity improvement and I didn’t look back once I started doing this.

Well, let me qualify that slightly. The first time I did it, it was great. The second time I deployed, I got a series of error messages and a pop up asking me to pick which deployment environment I wanted: the emulator or my phone. I wanted my phone, but it was always shown as “offline.” To counter this problem, I discovered it was necessary to go on the device itself and, under “Settings,” set it never to sleep when connected. Apparently, the phone going to sleep sends the ADB driver into quite a tizzy. If you have hit this, just changing the setting on your phone won’t do the trick. You’ll need to go into the platform-tools directory of wherever you installed the Anrdroid SDK and run “adb.exe kill-server” followed by “adb.exe start-server”. For you web devs out there, think of this as clicking on the little tomcat dude with the stop and then the little tomcat dude. 🙂

Now with this set up, you should be able to repeatedly deploy, and it’s really quite impressive how fast this is considering that you’re pushing a package to another device. It’s honestly not noticeably different than building and running a desktop app. The server kill and start trick is useful to remember because there is occasional weirdness with the deployment. I should also mention a couple of other things that didn’t trip me up, but that was because I read about them in advance. To debug on your phone, the phone’s development settings need to be configured for it. In your phone’s settings, under “Applications,” you should check “Allow Installation of Non-Market Applications” and, under “Debugging,” check “USB Debugging”. (On my phone, this is also where you find “Stay Awake,” which caused the problem I mentioned earlier, but YMMV.)

Changing the Icon

One of the first things that you’ll notice is that your “Hello World” or whatever you’re doing deploys as the default little green Anrdoid guy. Personally, when I’m getting acquainted with something new, I like to learn about it by changing the most obvious and visible things, so very quickly I decided to see how changing the icon worked. In your “res” folder, there are three folders: “drawable-hdpi”, “drawable-ldpi”, and “drawable-mdpi”. A little googling showed me that these correspond to high, low, and medium resolution phones. Since Android developers, unlike their iOS counterparts, need to worry about multi-device support, they need to have a vehicle for providing different graphics for different phones.

However, at this point, I wouldn’t (and didn’t) worry about this. I took an image that I wanted to try out as my icon and put it into these folders, overwriting the default. Then, I built and I got some error about the image not being a PNG. Apparently, just renaming a JPG “whatever.png” isn’t enough to trick the SDK, so I opened it in MS Paint and did a “Save As,” selecting file type PNG. This did the trick. As best I can tell, your icon will be capped in size, so it’s better to err on the side of making it slightly too big.

Changing the App Name

When I set all this up last winter, I followed a tutorial that had me build an app called “SayHi”. I was trying to prove the concept of taking an Eclipse project and getting it to run something, anything, on my phone. As such, when I picked it back up and started playing with it, the app was still called “SayHi”. However, I don’t want this app to say hi. It’s actually going to be used to turn lights on and off in my house in conjunction with my home automation. So, I’d like to call it something catchy–something imaginative, you know, like “Light Controller.”

This is actually refreshingly easy for someone who has been working with Visual Studio and Clear Case–a tandem that makes renaming anything about as convenient as a trip to the DMV. Under “res->values,” open the “strings.xml” file. You’ll have tabs at the bottom to view this as raw XML or as a “Resources” file. Either way, the effect is the same. You’ll change the “app_name” string to the value that you want, and that’s it. On the next deployment to your phone, you’ll see your app’s new name. Pretty cool, huh? Two easy changes without any code or having an app that actually does anything, and it at least looks like a real app until you open it.

At this point, I should probably mention something that may not be familiar to you if you’re just getting started. In Eclipse and with the Android SDK, you have various options for how you want to view the XML files. The manifest one seems to have a lot of options. The strings one has the XML versus resource choice. From what I recall, this is a feature of Eclipse in general–I believe plugins can supply their own view of various file extensions. If you want to see what all is theoretically available for any file, XML or not, right click on it and expand “Open With.” That’ll show you all the options. It’s important to remember that even though you may get defaulted to some kind of higher level, GUI-driven editor, you always have the raw text at your disposal. Having said that, however, my experience editing layouts taught me that, for beginners, it’s a lot easier to use the SDK’s layout editor. You’ll save yourself some headaches.

This post has gotten pretty long, so I’ll save my adventures with layouts and GUI components until next post.