Introduction

Note January, 2011: Android is changing quickly. We are now exploring features of Android 2.2 and Android 3.0. The early days of Android had many bugs and performance problems and few devices. Now the situation has changed. There are dozens of devices from a dozen major manufacturers, and devices are stable and fast, and Android is the dominant choice for the next generation of enterprise mobile deployments. It's been a wild and great ride and it's only getting better! I have not changed any of the text in the original article, and my predictions of two years ago have come through perfectly. Android has taken the dominant position from the iPhone, because of its openness and because all the manufacturers out there can use it. It has brought manufacturers such as HTC out from behind the scenes. It has brought new manufacturers and devices, like the Pidion BIP-6000, into the market.


Originally posted April 11th, 2008

Android developer challenge This is the first article in a series I will be doing on Android application development. You probably know by now that Android is the new mobile application platform released by Google. Some might see it as an answer to the Apple iPhone, but it isn't; it's much more than iPhone. At Chiral Software, we believe that the Android platform will far overtake the iPhone. We believe that Apple is making the same mistake with the iPhone that it made with the Mac OS 20 years ago: it's binding the platform to Apple-brand hardware. Google is doing with Android what IBM did with the PC and MS-DOS: it's making the platform available to all manufacturers. As happened with the PC, we believe that this model will result in much wider availability of handsets and a much larger user base.

In addition to making the platform available, Google has also made an excellent Software Development Kit (SDK) available, for free. This move will encourage development of applications, and it's also in contrast to Apple's closed SDK. Now Apple has made the iPhone SDK available, but it may be too little, too late. Google's kit is well-designed and works smoothly on various desktops, and with or without various Integrated Development Environments (IDEs).

Chiral Software is excited about Android and will be developing a series of applications for it. We believe that the best way to get started learning about something is to get started using it, and then, after some experience, step back and look at the larger picture. This article shares our first look. It's not a Hello World program. For that, see Google's Hello World with Android. Rather, this is our observations on how to get started: which tools to use and how to perform common tasks.

The Android platform itself

The Android platform is a Linux 2.6 kernel, a custom-made Java Virtual Machine called Dalvik, and a set of Java classes specially tailored for mobile use. The Google pages devoted to Android have lots of technical details. One important thing to understand is that all Android applications are in Java, and they all run as separate Linux processes. The Android system assigns each process a unique Linux user ID; this is the basis of the Android security model.

The SDK

You need to download the Android SDK as the first step.

Google recommends using the SDK as an Eclipse plugin. We found little value in doing that. We are mainly a NetBeans shop. We found that the easiest way to get started is simply to use the command-line tools.

And the tool to use is activityCreator.py, which creates an Activity. An Activity corresponds roughly to a "screen". You're building an application, which normally consists of a few Activitys. Applications can have other components, such as Services, but we'll start with Activitys.

activityCreator --out /home/me/MyApplication \
        chiralsoftware.androidapp.MainActivity

This creates an activity called MainActivity in the chiralsoftware.androidapp package, in the /home/me/MyApplication directory. It also creates a helpful build.xml file.

The package is complete and ready to run. Let's try it out before making any changes.

Start the emulator. No arguments are needed:

emulator

You have two ways of deploying the application to the emulator. The easiest is to use the build.xml script, but we'll show you the command-line way first.

Build the app:

% ant
Buildfile: build.xml

dirs:
    [mkdir] Created dir: /tmp/droid/bin/classes

resource-src:
     [echo] Generating R.java...

aidl:

compile:
    [javac] Compiling 2 source files to /tmp/droid/bin/classes

dex:

package-res:

package-res-no-assets:
     [echo] Packaging resources...

package-dex:
     [echo] Packaging dex...

package:

BUILD SUCCESSFUL
        Total time: 3 seconds

This creates a file called bin/MainActivity.apk. Normal Java applications are shipped as Java Archive (JAR) files, which are essential ZIP files containing Java class files. Android applications instead use a .apk file, which is also a ZIP archive, but with a different format from a JAR file. In particular, a APK file does not have a META-INF or a MANIFEST.MF. It does have an AndroidManifest.xml file. It looks like this:

jar tf bin/MainActivity.apk
res/layout/main.xml
AndroidManifest.xml
resources.arsc
        classes.dex

Where are the classes? They are in the classes.dex file. This is a special binary file format which wraps a set of ordinary Java classes.

AndroidManifest.xml seems like it would be a simple copy of the AndroidManifest.xml that's in the application source directory. It isn't. It's some binary format, which presumably contains the same information in a format which is quicker for Android to process.

With the emulator running, use the adb tool to copy the MainActivity.apk file over into the emulator's virtual memory:

adb install bin/MainActivity.apk
        45 KB/s (4130 bytes in 0.088s)

adb can connect to the emulator because the emulator listens on certain TCP ports which adb knows.

Click "all" on the emulator and the activity shows up:

Google Android

Click on the app to run it, and you'll see the Hello World message.

The easier way to do all this is to run the emulator, and then use the build.xml script:

ant clean install

That does it all.

Getting work done

The main functionality you'll use is the Activity.

You can lay out the display using code, but this is not recommended. Instead, it is best to create the layout in a separate layout XML file. This layout file creates UI components with IDs. In this case, the layout file is in res/layout/main.xml. We can put assign the objects IDs in the layout file like this:

<EditText
android:id="@+id/password"
android:layout_width="164px"
android:layout_height="wrap_content"
android:padding="10px"
android:textSize="18sp"
android:password="true"
>
        </EditText>

Then, the build.xml file's resource-src task uses the aapt program to generate a file called R.java. R contains references to all the objects with IDs in the layout file, so in R we have:

public final class R {

    public static final class id {
        public static final int password=0x7f04000a;
            

Now, within the activity, we can get the password field and read text from it as follows:

final EditText passwordField = (EditText) findViewById(R.id.password);
        String password = passwordField.getText().toString();

It's different from how we think of Swing or web layouts. It's also better. Layout should not be in code. Swing and other systems are moving in this same direction.

Visual design: using DroidDraw

Hand-coding the necessary layout files is a pain. The best way to do it is to use a visual design tool. That tool is DroidDraw, Android's answer to NetBeans' Matisse. Download and run the DroidDraw JAR, and try some layout.

Google Android

Remember to go to the Properties tab of the layout components to give them an ID which you can refer to using the R class.

Save the file directly into the res/layout directory.

Debugging

Do make use of the logging class, like this:

import android.util.Log;

        Log.i("LogTag", "This is a log message", exception);

When the Log.i method is called, a log message is generated. You can view logs easily with the adb logcat command:

adb logcat
I/DEBUG   (  494): debuggerd: Feb 28 2008 17:13:08
D/AndroidRuntime(  496):
D/AndroidRuntime(  496): AndroidRuntime START
I/AndroidRuntime(  496): Assertions enabled for ALL code (-ea and -esa)
I/runtime (  497): Startup: sys='/system' asset='/system/app' data='/data'
I/runtime (  497): Entered boot_init()!
D/runtime (  497): ProcessState: 0x124e8
I/runtime (  497): Binder driver opened.  Multiprocess enabled.
        D/AndroidRuntime(  496): --- registering native functions ---

Log messages will show up in this stream.

Conclusion

Developing with Android is a pleasure. We're confident that Android will be a major platform in the near future, and we're looking forward to continuing to develop for it.

Future articles will discuss how to use Activitys, including adding them to the AndroidManifest.xml file, and calling one Activity from another. We'll also discuss our favorite topic, which is client-server. With the right class libraries, it's not difficult to use SOAP for client-server interactions. We'll demonstrate Android using SOAP to communicate with JBoss Seam web services.

If your business needs to kick start its Android development to have products ready when the first Android handsets hit the stores for this year's gift season, contact us at 310 356 7869, or at sales@chiralsoftware.net, and we can discuss getting your Android project started.

For JBoss Seam consulting or training, call us at 310 356 7869 to discuss your needs.