This is part 2 of a 5-part series on introductory Android development. If you’re just arriving, you should head on over to Part 1.
In the first part of the tutorial, we got Eclipse, the Android SDK, and the ADT set up. In this part, we’ll get into our environment, create our first project and poke around in it, and test out the Android emulator.
Fire It Up
Go ahead and fire up Eclipse, and if it asks, choose a workspace (the default’s probably fine for now). Click on the “new android project” button or go to File -> New -> Android Project.
Click the New Android Project button.
Choose a name and settings for your project – we’ll call ours Twitternator. I’m choosing to target Android 1.5 for now, since that’s what’s running on most current production phones. 1.6 allows for some neat new features, but nothing we’re going to use here, so we may as well go for the lowest baseline possible. We’ll also leave out the Google APIs for now (those are used for Maps), since we won’t need them.
The New Android Project screen.
By targeting a specific SDK version and specific vendor libraries, developers have the ability to write apps for a base platform without worrying about users on older hardware and software – they simply won’t see the app in the Android Market, and will see a helpful error if they try to install it manually.
Then click Finish (there’s also an option to create testing code, which we’ll skip for now) and we’ll explore the structure of the folders we have now.
The structure of the project in Eclipse
The AndroidManifest.xml describes your application to the rest of the Android system – what version of the OS it supports, what permissions it needs (for Internet access, GPS information, etc.), how other applications will use it (via Intents and ContentProviders, advanced ways for applications to call each other and share data), what the different screens (Activities) are in the app, and so on.
“src” contains our Java code, and the wizard pre-created an Activity for us. Think of Activities as the code representation of one screen of your application. Here’s the pre-created outline of an activity, which simply tells the system to render the view from a layout file called “main” (more on those in Part 3).
The initial code for our Activity
The “res” folder contains non-code resources; usually “drawable” will contain image files, “layout” will contain XML files you can use to build UI for your application in an easy-to-read way rather than writing it all out in Java code, and “values” will contain things like internationalized strings files, color definitions, or theme styling definitions to apply to your views.
Finally, the “gen” folder contains automatically created code you can think of as placeholders for items in your res folder, so you can easily point to a particular button, string, or image from your code. This speeds up references to that information and makes code completion easy, and it’s done automatically in the background while you work.
We actually already have a working Android app created here. Let’s test it out in the emulator.
Emulation Nation
There are already a half dozen phones in the wild running Android; dozens more will be coming out in the months to come. Each one has a variety of screen resolutions, software versions, and hardware controls. There’s no substitute for testing on actual devices, of course, but the Android SDK includes a good solution for modeling a variety of these in software.
The emulator in Android is based on the open-source qemu emulator, and you can create models called AVDs (Android Virtual Devices) with a variety of hardware and software capabilities. For this project, we’ll create a basic Android 1.6 device with an HVGA screen, a 32MB SD card, and the basic APIs.
Where the AVD Manager is hiding.
Open the AVD Manager and create the new device.
The AVD Creator.
Then go back to the Java view of our project. Let’s go back to TwitterPoster.java and debug it from Run -> Debug -> Android Project. It should auto-launch the emulator here.
Give it a minute for the first boot, then go ahead and your app should launch right up:
Aww, look, our first running Android process! You should go have that bronzed to commemorate the occasion.
Usually, you’ll keep the emulator open for your entire development session. One really great thing about debugging Android applications is that you can quickly edit your code, which builds in the background, then push it into a running instance of the emulator and see the results in seconds. You don’t have to wait to rebuild your code or launch new emulators; you get feedback nearly instantly.
So far, we’ve gotten our environment set up, explored the project layout, and launched the emulator. In our next post, we’ll pretty things up and explore the layout editing tools.
Tags: android, twitternator-tutorial
Pingback: Ground-Up Android: Getting Started with App Development « Active Frequency
Pingback: Ground-Up Android, Part 3: Describing Your Layout « Active Frequency