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 it. Instead, you should probably check out the source code from Subversion[27] and execute ant jarcore to build it, then copy the resulting JAR (in BeanShell’s dist/ directory) to your own project’s libs/. Or just use the BeanShell JAR that accompanies the source code for this book, in the Java/AndShell project available in the Source Code area at http://apress.com.
From there, using BeanShell on Android is no different from using BeanShell in any other Java environment:
1. Create an instance of the BeanShell Interpreter class.
2. Set any globals for the script’s use via Interpreter#set().
3. Call Interpreter#eval() to run the script and, optionally, get the result of the last statement.
For example, here is the XML layout for the world’s smallest BeanShell IDE:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<Button
android:id="@+id/eval"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="Go!"
/>
<EditText
android:id="@+id/script"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:singleLine="false"
android:gravity="top"
/>
</LinearLayout>
Couple that with the following activity implementation: