MakeText show

Note the use of to refer to the activity when making the . That is the global set by the activity to reference back to itself. You could call this global variable anything you want, so long as the call and the script code use the same name.

When you click the Go! button, you get the result shown in Figure 21‑2.

Figure 21‑2. The AndShell BeanShell IDE, executing some code

And now, some caveats.

First, not all scripting languages will work. For example, those that implement their own form of just‑in‑time (JIT) compilation, generating Java bytecodes on the fly, would probably have to be augmented to generate Dalvik VM bytecodes instead of those for stock Java implementations. Simpler languages that execute from parsed scripts, calling Java reflection APIs to call back into compiled classes, will likely work better. Even there, though, not every feature of the language may work if the feature relies upon some facility in a traditional Java API that does not exist in Dalvik – for example, there could be stuff hidden inside BeanShell or the add‑on JARs that does not work on today’s Android.

Second, scripting languages without JIT will inevitably be slower than compiled Dalvik applications. Slower may mean users experience sluggishness. Slower definitely means more battery life is consumed for the same amount of work. So, building a whole Android application in BeanShell, simply because you feel it is easier to program in may cause your users to be unhappy.

Third, scripting languages that expose the whole Java API, like BeanShell, can pretty much do anything the underlying Android security model allows. So, if your application has the permission, expect any BeanShell scripts your application runs to have the same permission.

Last, but certainly not least, is that language interpreter JARs tend to be… portly. The BeanShell JAR used in this example is 200KB. That is not ridiculous, considering what it does, but it will make applications that use BeanShell that much bigger to download, take up that much more space on the device, etc.

…And Not a Drop to Drink

Not all Java code will work on Android and Dalvik. Specifically consider the following:

• If the Java code assumes it runs on Java SE, Java ME, or Java EE, it may be missing some APIs that those platforms provide that Android does not. For example, some charting libraries assume the existence of Swing or Abstract Window Toolkit (AWT) drawing primitives, which are generally unavailable on Android.

• The Java code might have a dependency on other Java code that, in turn, might have problems running on Android. For example, you might want to use a JAR that relies upon an earlier (or newer) version of the Apache HTTPComponents than the one that is bundled with Android.

• The Java code may use language capabilities beyond what the Dalvik engine is capable of using.

In all these cases, if you have only a compiled JAR to work with, you may not encounter problems at compile time, but rather when running the application. Hence, where possible it is best to use open‑source code with Android so you can build the third‑party code alongside your own and find out about difficulties sooner.