A newbie’s guide to Android development

By William J. Francis

Takeaway: William J. Francis covers Android development basics, such as the necessary tools to get started and a typical project hierarchy.

Introduction

Android is a great platform. The development tools are free, all the documentation is online, and you don’t need to purchase a special developer phone or register your hardware as a development device. In fact, thanks to the very slick and functional emulator that comes with the Android SDK, you don’t even have to own an Android-powered device (not that I recommend releasing an app without running it on real hardware).

There are more guides on the Internet for setting up an Android development environment than your average java-script program has semicolons. And not only are there just as many tutorials for writing an Android version of the revered “Hello World!” program, but there is actually a wizard included with the Android Eclipse plug-in that will generate it for you.

Yet despite the wide availability of information and a low-to-no startup cost, I still hear complaints from new developers and experienced developers transitioning to Android from another platform that it’s overwhelming to know where to start. Setting up a development environment and writing a “Hello World” app is vastly different from understanding Android conceptually, and the unique approach required to writing an app that does something useful. I get asked all the time what an Android project looks like, how the layout manager works, and what are the overriding design best practices for implementing Android applications.

My goal with this guide is to answer some of the common questions, and also open a dialogue with TechRepublic readers. I’d like to hear lingering questions of developers new to Android, as well as insights from experienced Android developers. Perhaps collectively we can make the road to creating that first killer app a little smoother.

What is Android?

According to Google’s official documentation, Android is not just an operating system, but rather it is a software stack. Part of that stack is an operating system (a forked Linux kernel to be exact), but Android is also a set of middleware, core applications, and an SDK that ties it all together. Android provides all the required components needed to run the device, a base level of functionality, and a highly optimized virtual machine for running a variant of Java-byte code. It is in this Java-based layer that third-party application developers are given the tools and the necessary ecosystem to extend the functionality and usefulness of Android-powered consumer devices via the wonderful world of apps.

What tools do I need?

Unlike many other development environments, you don’t need to purchase expensive hardware and software to start writing your first Android app. Android development can be done on a Mac, a Windows PC, and just about any flavor of Linux. You need Eclipse, the Android SDK, and the ADT Plugin. All of these tools are free.

If you have an Android-powered tablet, the Allow Usb Debugging setting in the configuration menu will enable you to connect the device to your development environment, download code to it, and invoke the debugger. If you don’t yet have an Android-powered device, you can use the emulator that comes with the SDK.

How do I set up my development environment?

For my money, the installation guide put together by the folks at Google is probably the most comprehensive and actively updated on the net. There you can find documentation for installing everything you need, for whichever host operating system will house your development environment.

What does an Android project look like?

When you create a new Android project using the ADT plugin, a development scaffolding is created for you. This structure helps to keep your layout cleanly separated from your source code, and it makes it easy to support things like internationalization out of the box. Below is a typical Android project hierarchy with a brief explanation of each node.

• src- : This is the folder where our Java classes reside.
• gen- : This folder contains folders that get built for us automatically by the toolset. A good example of what you will find in here is the Android-specific file R.java. This file is updated by the system whenever we add a new id to one of our layout resources.
• Android x.x- : This folder is the reference to the SDK version our app is using. This is something we get to configure when we create the project.
• assets- : The assets folder provides a repository for raw resources.  For example, if your app plays sound effects, placing the wave files in the asset folder makes those resources available to the application at runtime. You might think it would be a good idea to include your bitmap images in this folder as well, but you will learn in a moment that Android provides a specific set of folders for graphic resources, and using those folders hold certain advantages.
• bin- :This is where Eclipse will place your compiled binaries.
• res- :The res folder is very important, but it doesn’t contain any files directly. The res folder contains a series of subfolders.
• res/drawable: There is a series of drawable folders. The folder names represent the screen density (as an example res/drawable-hdpi contains all your image resources for high-resolution devices). If you size your graphic resources correctly and include them in the right folder, the operating system will pick out the best possible image at runtime, depending on the size and density of the user’s display.
• res/layout: The layout folder is where you use Android’s XML meta-language to describe how your screens should be displayed. Like the drawable folder, the layout folder can be used to represent multiple resources, in this case portrait and landscape layouts, allowing the operating to choose the most appropriate option at runtime.
• res/values: The values folder is used largely for string resources. The contents consist of key-value pairs, and the folders can be modified (e.g., values-ENG) to support various language prompts at runtime.
• AndroidManifest.xml: The manifest file is responsible for providing essential information to the operating system about a particular application. This information includes things like the package name, the minimum SDK needed, screen sizes supported, security permissions required by the app, and versioning to name a few.