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 understand how interface controls and the various other pieces work.
If you happen to find a glitch, 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.
Why Android?
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.
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 4 (Android 1.6) 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......
android-developers-tools
android-developers-tools
android-developers-tools
android-developers-tools
android-developers-tools
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 4 (1.6). 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 16MB, 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:
"super.onCreate(savedInstanceState)"
"super.onCreate(savedInstanceState)"
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 breakpoint.
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.
Conclusion
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.