What is Android?
Android is an open source mobile operating system that combines and builds upon parts of many different open source projects. What does this mean to you as a developer? You have access to the source code of the platform that is running on the phone. This can help you better understand how interface controls and the various other pieces work. If you happen to find a bug, you can also submit a patch for the issue, though this is a more advanced practice. Google has also pulled together a large group of companies (called the Open Handset Alliance) that both contribute to and use the Android OS in their hardware devices. This means that there is industry-wide support for Google’s OS, promising wide adoption across well-known vendors.
There are many advantages to developing for the Android platform:
- Zero startup costs to begin development. The development tools for the platform are free to download, and Google only charges a small fee to distribute applications on the Android Market.
- Freedom to innovate. The Android OS is an open-source platform based on the Linux kernel and multiple open-source libraries. In addition to building applications to run on Android devices, developers are free to contribute to or extend the platform as well.
- Freedom to collaborate. Android developers are not required to sign an NDA and are encouraged to collaborate and share source code with each other. According to a survey by Black Duck Software, the number of open source mobile apps and libraries grew at a rate of 168% from 2008 to 2009, faster on Android than any other platform. This means more code that you can reuse in your own projects to bring them to market much faster.
- Open distribution model. Very few restrictions are placed on the content or functionality allowed in Google’s Android Market, and developers are free to distribute their applications through other distribution channels as well.
- Multi-platform support. There are a wide variety of hardware devices powered by the Android OS, including many different phones and tablet computers. Development for the platform can occur on Windows, Mac OS or Linux.
- Multi-carrier support. A large number of telecom carriers currently offer Android powered phones.
Prerequisites before continuing with this article include:
You must download and install the Eclipse IDE. Choose the “Eclipse IDE for Java Developers” option.
You must download and install the Android SDK.
Install the Android Development Tools (ADT) Eclipse plugin.
The Eclipse IDE
Eclipse is a complex, multi-language, and extensible Integrated Development Environment (IDE). The learning curve can be steep, but the power of the environment can greatly increase your efficiency.
After opening Eclipse for the first time, select a workspace to save your project within. You will see an introduction screen with multiple icons. Select the “go to workbench” option, and you will be presented with the default project screen.
Assuming you have already installed the Eclipse ADT plugin, you will need to configure Eclipse for Android development by manually setting the filepath for the Android SDK. To do this, select Eclipse > Preferences from the main tool bar, and then select Android from the dialogue box that appears. Update the “SDK Location” option to point to the directory where you installed the SDK. You should now have the IDE configured for Android development.
It is important to note that Eclipse uses something called “perspectives” to group commonly used tasks. Switching perspectives will switch out parts of the menu and toolbars, and will show and hide views related to them. Perspectives can be opened by clicking on the Open Perspective button or by choosing Window > Open Perspective. Some perspectives that you will use frequently include Java, Debugging and DDMS.
The Java Perspective
The Java perspective is the default perspective in Eclipse, and it is where you will probably spend most of your time.
Among the most important views in this perspective is the Package Explorer view, by default located on the left hand column of the workbench. This view is an overview of your entire project. It also shows the states of individual files with regard to compile issues, version control, etc.
Another important view in the Java perspective is the Problems view, by default located in the bottom center panel of the workbench. This is where you will find compile warnings and errors listed. You can double-click an item to be taken directly to the error in the Java or XML file.
The DDMS Perspective
DDMS is short for Dalvik Debug Monitor Server, which communicates with the low-level services of a device or emulator. Switch to the DDMS perspective now by selecting Window > Open Perspective > DDMS.
The Devices view, located in the left column of the workbench, is where you will see any Android devices available to your computer. This includes both phones attached to your machine and running emulators. Under each device, you will see all the running processes. There are toolbar buttons on the view for launching the debugger on a process, getting information about heaps and threads, stopping processes, and taking screenshots.
The Emulator Control view, also in the left column, lets you do the following:
Set the status of the voice connection.
Set the status, speed and latency of the data connection.
Simulate an incoming call or SMS from a supplied phone number.
Provide a simulated set of points for the GPS via a latitude/longitude point, or GPX/KML file.
Using the File Explorer view, accessible as a tab at the top-right of the center column, you can browse the file system of a device. For an emulator or a rooted phone, you will have access to the private directories /data and /system. For non-rooted phones, you will only have access to /sdcard.
The Debugging Perspective
The debugging perspective will provide in-depth information about your applications. Switch to the debugging perspective now by selecting Window > Open Perspective > Debug.
The Debug view will show you the running apps being analyzed, and, when stopped on a breakpoint or exception, the call stack of the application as well. The Variables view displays the contents of any local variables at the current breakpoint.
The LogCat view in the lower right hand corner displays all logging output using the android.util.Log class. You can filter based on tags, or different log levels such as debug, information, error, etc.
Your First Application
To begin creating an Android application, switch back to the Java perspective and select File > Menu > Android Project. Doing so will launch the application creation wizard, and you will be prompted to enter meta-information about your project in three categories: Contents, Build Target, and Properties.
Name the application “DemoApp” and leave the Contents section with all the default values.
The Build Target section defines the version of the SDK that our demo app will be compiled against. For this tutorial, choose API level 23 (Android 6.0) because it will run on a wide range of hardware and the API will allow us to handle different screen resolutions.
Next is the Properties section, which provides the wizard with more information about what classes to generate and what they should be named. The Application Name setting will be displayed under the application icon, as well as the application’s title bar when launched. The Package name provides the base Java namespace for your generated classes. In order to create a default activity, make sure Create Activity is checked and provide an activity name. The last option is the Min SDK version. This value determines what version of Android needs to be on a phone in order for this application to be installable. This is generally set to the same API level that you chose under Build Target.
Once you enter all this information and click Finish, you will have a basic “Hello World” application that is almost ready to run on a phone or an emulator. Before we setup an emulator and run the application, take a few minutes to examine the standard template content generated:
The AndroidManifest.xml file
The AndroidManifest.xml file provides metadata about your application that the Android OS will need to run the app properly. The name of the application, used for both the app icon and the activity titlebar, and the app icon are defined under Application Attributes. You will notice that the Name field doesn’t actually contain the name text, but “@string/app_name” instead. This is a string reference and can be used anytime a string is expected. The actual string text is then defined in one of the XML files found under the res/values folder. The app creation wizard generated a file there called strings.xml.
The Application Nodes section is where all the activities are defined for the application. Our app’s single activity is called MainActivity and listed here.
The /res folder
The res folder is where most application resources are stored. The main content categories include drawables, layouts, and values.
Drawables are generally bitmaps images in the form of .PNGs. Drawables can also be nine-patch images, which are .PNGs with special data in the image that help Android do a better job when stretching the image. Nine-patch images can be created with the nine-patch tools in the SDK, or with an image creation tool like Photoshop.
Layouts are where you define your screens. To view the XML for the layout on screen, click the main.xml tab.
Values are where you define (in XML) your globally used colors, dimensions, strings and styles. The strings.xml file allows you to add and edit values for your project.
The /gen folder
This is where code is generated for all the resources defined in your res folder. This is how you can access layouts and controls defined within your code.
The /src folder
The src folder contains all of your custom source code, grouped into packages. Packages are simply there to help categorize your source code into logical (and manageable) groups.
The /assets folder
The assets folder is a place to store miscellaneous files you need to access in your code as raw data. All files in the res folder have methods to load the specific types, whereas the only way to load something from assets is to programmatically open it as a file.
Creating an Android Virtual Device
Virtual devices make it possible to run and test your code without owning an actual Android phone. Since there are several different version of the OS you can target, you will eventually need to create multiple versions of virtual devices, but for now, we’ll create one using API level 23 (6.0). You can do this via the AVD Manager. From the main toolbar, select Window > Android SDK and AVD Manager.
Once you’ve opened the manager and are viewing your list of virtual devices, click the “New” button to create your virtual device.
I generally name my virtual devices using the OS version number along with the preset resolution that I choose, so in this case, 1.6-hvga. It’s good to also create an SD Card for the emulator which I usually set to 1024MB, unless I know I will need more space. Click the Create AVD button, and you will see your device listed.
Go ahead and start the virtual device by selecting it and clicking the “Start” button.
Running & Debugging Your First App
Eclipse, along with the Android Developer Tools, offers a great environment for debugging applications. For debugging, you’ll use both the Debugging and the DDMS perspectives. The debugging perspective will be used for stepping through code, viewing values of variables, and setting breakpoints. The DDMS perspective will be used to control the emulator, view threads, and view memory allocation.
Since this is our first time running the application, we need to create something called a run configuration. Run configurations are the settings that Eclipse will use to run (or debug) your application. Each application can have multiple configurations. One might be set up to always deploy and run on an attached phone, and another could be setup to only run in a specific emulator instance. At this point, disconnect your phone if you happened to have it attached to your machine so you can see the app run on the emulator first.
To create the run configuration, select DemoApp in the Package Explorer, then choose Run > Run from the main menu. In the next dialog, choose Android Application and click OK. The emulator that we created earlier should launch. When the emulator first starts up, it may appear with the lock screen; just click menu to be taken to your new app. You should now see the text “Hello World” on screen!
Our next step will be to set a breakpoint. Open the MainActivity.java file by double-clicking it in the Package Explorer. It is located under /src > com.demo.demoapp. Next, on the line that contains:
double-click in the gray column to the left of the line (where you see the blue circle in the screenshot below). If you were successful, there should now be a blue circle indicating the break point.
Now switch to the debugging perspective by selecting Window > Open Perspective > Debug . To debug the application, select Run > Debug.
In the Debug view, you should see a list of items under DalvikVM/Thread. This is the call stack since we are now stopped at the breakpoint we set earlier. The Variables view will show all local variables at the current breakpoint. You can expand the item “this” to see all the values of our MainActivity instance.
Finally, LogCat will display all logging information coming from the emulator.
To continue running the app, you can use the toolbar on the Debug view (as seen in the screenshot above), or choose the same actions from the run menu. Choose Run > Resume to let the app continue running.
This tutorial took you through the various parts of Eclipse and ADT that you need to be familiar with to begin Android development. Although we didn’t cover the details of the application source code, it is important to start with a strong understanding of the tools you will use every day during development. In coming articles, we will continue to dig deeper into writing progressively complex applications and creating a compelling UI.