This is part 1 of a 5-part series on introductory Android development.
Thinking about testing the waters with Android development? Jump right in. We’ll build a neat little application that interacts with a web service.
Yup.
Which one? Twitter, of course.
This is a web form of a talk I gave with Henry Cipolla, CTO of Localytics, at BarCamp Boston 4 and in a longer form at FITC Mobile 2009, updated to cover the 1.6 (”Donut”) release of the Android SDK. The slideshow portion of that talk covers the basic concepts of the platform and slides are available online. I recommend checking it out.
Who is this for?
I assume you’re familiar with development in general, and you’ll find it easiest if you’ve done a little Java programming before and have actually used an Android device, but I assume no in-depth experience with the platform.
Platform Basics
The slides linked to above give a good visual overview, too, and the Android Developers website is an invaluable resource for finding more details on everything Android development related. But here’s the absolute minimum you need to know to get started.
The Android Platform is a full software stack for mobile devices that includes a Linux operating system, hardware drivers, and a bunch of neat low-level libraries you’ll probably never touch directly. It provides end users with a nice interface and handy applications to do things like browse the web, sync their email, and even make phone calls.
It also provides a way for users to securely run applications of their choice, simultaneously, and a set of tools and libraries developers can use to build their own applications — powerful enough to replicate or even replace many of the built-in “core” applications like the home screen or phone dialer.
Android applications are written in Java (J2SE, not a pared-down Java Mobile/Micro (Java ME) as found on many low-end phones) using an open-source J2SE implementation based on Apache Harmony along with tons of Android-specific libraries for things like UI and handy third-party libraries for things like HTTP requests and JSON parsing. That Java code is compiled and then transformed into Android-specific files in a format called .dex, and runs on the phone in a highly optimized VM runtime called Dalvik. Luckily, you’ll almost never have to think about any of those pieces in between writing your code and running it on the phone, since the tools take care of them for you.
Your code eventually runs in its own private highly-optimized virtual machine — it has its own memory space, and even runs as its own system user. This keeps bad code from blowing up the rest of the system and keeps your code secure from malicious software, eliminating risks from things like buffer overflow attacks or memory leaks that can affect other platforms.
Why Android?
The unspoken question here is usually “Why not the iPhone?” From a developer’s perspective, they both offer very good development environments and libraries, powerful testing and debugging tools, and a similar baseline of fairly speedy hardware devices. But the fact is, right now there are many times as many iPhone users and applications as there are Android users and apps. And there’s just plain more money being spent on iPhone apps right now, so from a business perspective, you absolutely can’t rule the iPhone out. There are really a few reasons to think seriously about Android for an application, though:
- Store independence. Your app can never be caught up in “approval limbo” – there’s no waiting period and you can update your app whenever you want. And if you’re unhappy with the Android Market itself, you can look to third-party stores like SlideME or even distribute apps for users to install themselves.
- Device independence. There’s only one iPhone device (or more accurately, 3 phone and 3 iPod Touch models with nearly-identical appearances and hardware) on one carrier (AT&T). Android is on devices from several major and minor manufacturers in a variety of form factors, and will be on phones for T-Mobile, Verizon, and Sprint by the end of the year.
- J2SE. Love it or hate it, there’s a lot of resources for learning it, tons of well-tested libraries, and no need to learn Objective C.
- Background processes. There are things you just can’t do with push notification.
- Little pond. Now that the initial App Store rush is over, it can be difficult to get attention in a store with dozens of new applications in your category every day. The Android Market is comparatively uncrowded, and the user base is likely to grow quickly as new carriers and devices come to market. While Active Frequency’s RockOut application was the only virtual guitar on the Android Market for several months, there are dozens of competitors for the iPhone.
Rather than talk the platform up any more, I’ll jump into writing an app and explain features as I go through it. For now, I’ll just say Android is an open platform and has some cool features like the Intents system, good native UI widgets, a sane and reasonable permissions system, and background processes, along with safeguards against bad code and access to a full J2SE stack.
What will I learn?
The point of this series isn’t to memorize APIs or the right sequences of incantations to do specific tasks, it’s to learn the general process of writing apps for Android.
Specifically, I tell the people watching this presentation live to keep an eye on the quick “prototype-run-test-edit-run…” cycle the tools make quick and simple, on the ease of debugging and getting useful, filterable console output, and in general on getting the a feel for effectively using the build tools and environment to get started quickly. You won’t learn the intricacies of all available tools and libraries in this one tutorial, and there’s no substitute for reading the documentation — but the documentation can’t show you what a typical development cycle looks like.
Know your tools
Most Android developers are using Google’s excellent tool chain. You can ignore some or all of it and write your code in the editor of your choice, interacting with build scripts and testing tools only when you want to, but the tools handle a lot of boring parts for you and give you one interface to handle a lot of functionality.
You’ll want a recent version (3.4 or 3.5) of the Eclipse IDE (Integrated Development Environment) for J2SE, the Android SDK, and the Eclipse ADT plugin to interface with those tools and provide project templates. Be sure to check out Google’s complete installation instructions for details.
Alternatively, you can install the all-in-one Motodev Studio, which includes all of those parts in a simple installer. However, I can’t really recommend that option right now as it’s still in beta and is a full version behind the SDK from Google (1.5, vs. 1.6) as of this writing. For this tutorial, I’m using Eclipse 3.5 for Mac OS X (Cocoa/64-bit) with ADT 0.9.3 and SDK 1.6r1 — the latest production releases as of October 1 2009, but you should be able to follow along just fine from Windows or your Linux/Unix of choice once you set up Eclipse, the SDK and the ADT.
… OK, all set? Great. Let’s move on to Part 2 and start our project.
Tags: android, twitternator-tutorial