Beginning Android

Here your.app.package is the Java package for your application (e.g., com.commonsware.android) and your-db-name is the name of your database, as supplied to createDatabase().

Note, however, that the Android 0.9 SDK appears to be missing the sqlite3 command, though it has returned in Android 1.0.

The sqlite3 program works, and if you are used to poking around your tables using a console interface, you are welcome to use it. If you prefer something a little bit friendlier, you can always copy the SQLite database off the device onto your development machine, then use a SQLite-aware client program to putter around. Note, though, that you are working off a copy of the database; if you want your changes to go back to the device, you will need to transfer the database back over to the device.

To get the database off the device, you can use the adb pull command (or the equivalent in your IDE), which takes the path to the on-device database and the local destination as parameters. To store a modified database on the device, use adb push, which takes the local path to the database and the on-device destination as parameters.

One of the most accessible SQLite clients is the SQLite Manager[23] extension for Firefox (Figure 20-1), as it works across all platforms.

Figure 20-1. The SQLite Manager Firefox extension

You can find other client tools[24] on the SQLite Web site.[25]

CHAPTER 21 Leveraging Java Libraries

Java has as many, if not more, third-party libraries than any other modern programming language. Here, “third-party libraries” refers to the innumerable JARs that you can include in a server or desktop Java application — the things that the Java SDKs themselves do not provide.

In the case of Android, the Dalvik Virtual Machine (Dalvik VM) at its heart is not precisely Java, and what it provides in its SDK is not precisely the same as any traditional Java SDK. That being said, many Java third-party libraries still provide capabilities that Android lacks natively and therefore the ones you can get working with Android’s flavor of Java may be of use to you in your project.

This chapter explains what it will take for you to leverage such libraries, and the limitations on Android’s support for arbitrary third-party code.

The Outer Limits

Not all available Java code, of course, will work well with Android. There are a number of factors to consider, including the following:

• Expected Platform APIs: Does the code assume a newer JVM than the one Android is based on? Or does the code assume the existence of Java APIs that ship with J2SE but not with Android, such as Swing?

• Size: Existing Java code designed for use on desktops or servers need not worry too much about on-disk size, or even in-RAM size. Android, of course, is short on both. Using third-party Java code, particularly when pre-packaged as JARs, may balloon the size of your application.

• Performance: Does the Java code effectively assume a much more powerful CPU than what you may find on many Android devices? Just because a desktop computer can run it without issue doesn’t mean your average mobile phone will handle it well.

• Interface: Does the Java code assume a console interface? Or is it a pure API that you can wrap your own interface around?

One trick for addressing some of these concerns is to use open-source Java code, and actually work with the code to make it more Android-friendly. For example, if you’re only using 10% of the third-party library, maybe it’s worthwhile to recompile the subset of the project to be only what you need, or at least to remove the unnecessary classes from the JAR. The former approach is safer in that you get compiler help to make sure you’re not discarding some essential piece of code, though it may be more tedious to do.

Ants and JARs

You have two choices for integrating third-party code into your project: use source code or use pre- packaged JARs.

If you choose to use the third-party source code, all you need to do is copy it into your own source tree (under src/ in your project) so it can sit alongside your existing code, then let the compiler perform its magic.

If you choose to use an existing JAR, perhaps one for which you do not have the source code, you will need to teach your build chain how to use the JAR. If you are using an IDE, that’s a matter of telling it to reference the JAR. If, on the other hand, you are not using an IDE and are relying upon the build.xml Ant script, put the JAR in the libs/ directory created for you by activityCreator, and the Ant build process will pick it up.

For example, in a previous draft of this book, we had a MailBuzz project. MailBuzz, as the name suggests, dealt with email. It leveraged the JavaMail APIs and needed two JavaMail JARs: mail-1.4.jar and activation-1.1.jar. With both of those in the libs/ directory, the classpath told javac to link against those JARs, so any JavaMail references in the MailBuzz code could be correctly resolved. Then, those JARs were listed, along with the MailBuzz compiled classes, in the task that invokes the dex tool to convert the Java code into Dalvik VM instructions. Without this step, even though your code may compile, it won’t find the JavaMail classes at runtime and will fail with an exception.

As it turned out, though, the Dalvik VM and compiler supplied with the Android 0.9 and newer SDKs no longer supported some Java language features used by JavaMail. And, while the JavaMail source code is available, it is under an open-source license (Common Development and Distribution License; CDDL) that… has issues.

Following the Script

Unlike other mobile-device operating systems, Android has no restrictions on what you can run on it, so long as you can do it in Java using the Dalvik VM. This includes incorporating your own scripting language into your application, something that is expressly prohibited on some other devices.

One possible Java scripting language is BeanShell.[26] BeanShell gives you Java-compatible syntax with implicit typing and no compilation required.

So, to add BeanShell scripting, you need to put the BeanShell interpreter’s JAR file in your libs/ directory. The 2.0b4 JAR available for download from the BeanShell site, unfortunately, does not work out of the box with the Android 0.9 and newer SDKs, perhaps due to the compiler that was used to build