Monday, August 31, 2009

The invisible applet

How about deploying a Java applet that you can't see?

It's no secret that Java has not been successful as a client-side platform. We often use HTML/Ajax or Flash/Flex on the browser and Java on the server. Maintaining 2 distinct platforms has a major disadvantage: it's hard to share code.


Imagine this scenario: you have built a beautiful UI for the browser, and like any respectable shop you maintain your business logic in Java on the server. Suppose you design a screen where your user can do what-if analysis by fiddling with sliders and watching pretty graphs and numbers change in real time. Unfortunately, the code that does all that complex computation is in Java on your server. Your options:

  • Write a parallel ActionScript codebase that duplicates the Java logic. You have the burden of keeping both codebases correct and in sync, and there could be subtle inconsistencies in the resulting logic.
  • Keep the logic on the server, and execute the computation there. Every time the user jiggles a slider, the Flex app bundles all the relevant data and transmits it to the server. The server in turn does the computation and sends back the results. 
My reaction to these alternatives is "yuck". I would have to pay a cost in either development burden or network traffic and performance. This would be one example where a Java "engine" on the browser might be exactly what you need, even if it does no UI duty.

Implementing an invisible Java applet to provide services to your UI code via JavaScript is surprisingly easy. Your applet tag needs a MAYSCRIPT attribute to enable the Java-to-JavaScript interface:

<applet ...="" height="0" id="myapplet" mayscript="" width="0">
...
</applet>


Note that this is a 1x1 box. If the applet is zero size or wrapped in a hidden div, the applet won't start. Once your applet is running you can call public methods in your Applet class directly from JavaScript:

document.getElementById('myapplet').myJavaMethod();

Conversely, you can call your JavaScript methods from within your applet. Since JavaScript is single-threaded, for longer operations you might want to use an asynchronous call/callback pattern where the Java code would spawn a separate thread that returns the result by way of a callback into your JavaScript code. You can do it like this:

JSObject.getWindow(applet).call("myJsMethod", new Object[] { arg });

One odd behavior I found when calling Java methods from JavaScript is that even when the applet is signed, the Java code executes in a thread with reduced privileges. Jumping onto the Swing event thread will gain you the signed privileges, but now you are tying up the event thread. If you want privileged, multithreaded execution, you could do something like this (looks bizarre, I know):

SwingUtilities.invokeLater(new Runnable() {
   public void run() {
      new Thread() {
         public void run() {
            doWhatIReallyWantToDo(); 
         } 
      }.start(); 
   } 
});

That seems easy enough, but there still aren't many situations that justify using Java on the client side. The dominance and ubiquity of Ajax and Flash on the browser means you need a really good reason to burden your users with the Java runtime. Deployment remains Java's big weakness on the client. Some possible reasons:
  • To share logic on both client and server.
  • To use functionality from some complex third-party library on the client side. 
  • Get multithreaded, fast execution.
  • Need for extensive filesystem access.
  • Some combination of the above. 

Sunday, August 23, 2009

Why BlackBerry?

As I said before, I write BlackBerry software. It's certainly not the most trendy platform. At a gathering of mobile developers, I saw from a show of hands that attention is going to more glamorous platforms like the iPhone and Android. So why BlackBerry? BlackBerry fans can articulate numerous reasons why they like their phones. As a developer, I have my own reasons, some of them quite subjective. I'm going to list a few of them in this post.

It's Java

The BlackBerry development platform is Java. It is the standard Java ME (or J2ME) MIDP 2.0/CLDC 1.1 plus the usual JSR extensions for multimedia, PIM, filesystem, location etc. RIM also adds additional APIs for BlackBerry-specific functionality. As an experienced Java developer looking for a hobby, Java ME seemed like the natural progression for me into mobile development. Development in Java ME reminds me of the early days of JDK 1.1 with a simple class library, before J2EE, generics and other features piled complexity into the Java ecosystem. While I certainly appreciate the richness of the Java platform, the sheer minimalism of Java on the phone is also fun in its own way.

While I called it minimalist, Java on the BlackBerry remains Java. It is a "civilized" language with an ample class library and garbage collection. It lets me concentrate more on writing the app itself rather than tedious plumbing like memory management.

It fixes the signing problem

While portable MIDlet development sounds like a fine idea, the MIDlet signing problem cripples Java ME in practice. The basic problem is that the Java security model severely restricts what your Java app can do on the phone. Security is a good thing in itself, except that it's hard to get out of that security sandbox. And escape the security sandbox you must, if you want to do anything substantial like access the filesystem or the network. 

To sign a Java ME app, you need to buy a certificate from an authority like Verisign for a couple hundred bucks. Actually, you will need to buy from several signing authorities because different phones support different authorities. On top of that, the networks may apply their own layer of restrictions and certification process. This adds up to a lot of money. T-Mobile (through their testing/certification partner True North) charges $195 or $250 per build, on top of a $500 deposit. So to release a bug fix on T-Mobile alone will cost you $250, assuming it passes certification the first time. This heavy burden is likely one reason why Java ME apps seem to consist largely of games and other insubstantial apps.

The BlackBerry world is simpler. You pay just $20 to RIM to register as a developer, and that gets you unlimited code signing. You can continue to write Java ME code or use BlackBerry-specific APIs, and your signed app can now access restricted APIs. Of course, this gives you restricted API access only on BlackBerries, but with 20 to 30 million users out there, it is a big user base.

It's open

Unlike the iPhone, BlackBerries are open platforms in that you can install any software you like on your phone. Like your PC, you can install apps from a number of different web sites or straight from your PC. While RIM's App World received a lot of attention lately as the BlackBerry counterpart to Apple's App Store, it is in fact one of numerous app stores available to a BlackBerry owner. On my part, I can choose to publish my software at one of numerous app stores, or even directly from my own website. My ability to write and publish software is not limited by the whims of any one app store. 

It's cheap

This is where my role as a phone user and a developer coincide. As a phone user, I like the fact that you don't need a $20-$30 data plan to use a BlackBerry. Personally, I don't want the crackberry lifestyle where I would pounce on my phone every time it buzzes or blinks red (red LED means message waiting). I also have WiFi access most of the time, so a WiFi-equipped BlackBerry like my Curve 8320 does not really need mobile data. To sign up for an iPhone or an Android phone means that I need a data plan for the next 2 years. That adds up to hundreds of dollars: much more than the original cost of the phone.

As a developer, I appreciate that all the tools I need are free: Eclipse and RIM's plugin, phone simulators and documentation. All I really needed is $20 for the code signing privilege. It is true that RIM's App World requires $200 up front to be listed, but competing stores like MobiHand and Handango will let you publish your app for free. 

It's small

While Apple likes to boast of an enormous selection of apps, it's not always a good thing for a software publisher: it's hard to get noticed. By contrast, the number of apps available for BlackBerry is still manageable. You can still find the usual apps that make rude body noises, but you can also reasonably expect to browse the entire collection without getting lost. I met a couple of entrepreneurs at the mobile gathering I mentioned earlier, who said that they wanted to target BlackBerry as their preferred mobile platform precisely because the iPhone market is so saturated. Another software publisher mentioned that their downloads break down evenly (50:50) between iPhone and BlackBerry. The old cliche still holds that you can be a big fish in a small pond.

Reality check

I don't mean to imply that the BlackBerry platform is perfect. After all, there is a reason why so much developer attention is going to other platforms. And while I have only published a few modest applications, I have had a fair number of frustrations with the platform's limitations. All I wanted to do with this post is to point out a few reasons why I like it.

Friday, August 21, 2009

First post!

Welcome to my development blog. I am a software engineer working in the Boston area. By day, I write software based on a conventional enterprise Java stack: Spring, Hibernate, Tomcat and a typical SQL database server on Linux. My tools should be familiar to anyone who works in the Java ecosystem: Eclipse, Ant and other Apache stuff, Log4j, JUnit, Hudson etc. After hours, I toss all those things aside (except Eclipse) and write BlackBerry software. On this blog, I will cover topics pertaining to these two separate development activities.