What is AJAX?

According to the seminal article about AJAX (I wish things I wrote were referred to as “seminal”, it sounds so impressive), the term “AJAX” stands for asynchronous JavaScript and XML. The idea is fairly simple. Instead of building a web application using the traditional “dumb client” approach (all logic on the server), move as much logic as you can to the browser (writing it in JavaScript) and communicate with the server asynchronously (in the background), receiving data in XML or some other JavaScript-friendly (like JSON) format.

The benefits of AJAX are threefold. First, it reduces the server’s workload — it’s not spending most of its time generating pages in response to changes on the client. Second, applications become much more responsive due to the local logic — no roundtrips to the server and back in order to expand a tree node, for example. Third, there’s nothing to install on the client — the user just starts up a browser and navigates to the right URL; as long as they have Internet access, they’re in.

Oh Yeah? Try Mobile App Development!

One of the things I’ve always found funny about the AJAX programming metaphor is that many developers think it’s new technology. The truth is that mobile application developers have long faced the same underlying issues. It’s kind of inevitable, really: when the network is slow or unavailable, you generally have two choices for building network-enabled (as opposed to completely standalone) applications. The first choice is to replicate the entire application, or its equivalent, on the device. You have a database application running against a big database server? Port it to the mobile platform and have it run against a local database, then have the local database synchronize itself with the database server whenever possible. (Advertisement: SQL Anywhere has two different mobile database engines that can sync to all the big name database servers.)

The second choice is to use an asynchronous model. Talk to the server using a queuing methodology. Send out the requests, but don’t wait for them to come back. Let the user continue to work. When the responses do arrive, process them. There are many ways to do this. (Advertisement: QAnywhere is one way.)

Mobile AJAX?

You might think that AJAX is the perfect technology for building cellphone-based applications. Especially with the powerful mid-range and high-end phones now available. And you might be right, except of course that most mobile browsers don’t support the functionality needed to run AJAX applications.

I say “most” because there is actually a “mobile AJAX” product on the market right now called M-Business Anywhere that lets you develop web applications with JavaScript-based local logic on mobile devices — it certainly sounds AJAXish, doesn’t it? In fact, it’s the basis for the AvantGo service, which mobilizes web content for free. But M-Business Anywhere can go further than that and mobilize enterprise web applications. No, it’s not strictly-speaking AJAX because there’s no XMLHttpRequest object, but it’s nevertheless an async development model. I know, because write now I’m developing the BlackBerry client for the service.

AJAX = Asynchronous Java and XML?

But our focus here is Java, and Java ME specifically. How do AJAX and Java ME relate to each other?

Not directly, it would seem, unless you change your definition of AJAX. Maybe for Java ME developers “AJAX” really stands for asynchronous Java and XML. It’s what we do today to get our apps working well: background communication over HTTP using simple data exchange protocols, with local logic for the user interface.

Maybe we’re more bleeding edge than we thought!

Eric Giguere is a software developer at Sybase iAnywhere who has published extensively about Java ME programming. This entry is from his J2ME Programming Guide.

Technorati Tags: AJAX, wireless, mobile, mobile AJAX, Java ME, asynchronous

Technorati Tags: Java ME, J2ME, SOA, service-oriented architecture, tech tip, Eric Giguere

The truth is that BlackBerry programming is different in many ways from “regular” Java ME programming. Here are some of the differences:

• Enterprise mindset. Although it’s true that RIM is pushing its way into the conumer market with the recent introduction of the BlackBerry Pearl 8100 smartphone, the BlackBerry platform is still primarily thought of as an enterprise-focused mobility solution. A BlackBerry can be tightly integrated with an enterprise-level messaging system using RIM’s BlackBerry Enterprise Server in a way most J2ME devices cannot.
• Different APIs. Although the BlackBerry supports a number of different JSRs, each device also comes with an extensive set of RIM-specific APIs that are often more powerful and more comprehensive than what you’ll find in those JSRs, including a user interface model entirely separate from MIDP’s. While it’s true that MIDlets will run BlackBerry devices, it’s more common to write a BlackBerry-specific version of an application that uses the RIM-specific APIs than to depend entirely on what’s available in the Java ME standards.
• Consistent and documented deployment model. Unlike Java ME, where application deployment methods vary greatly from device to device, application deployment is handled consistently across all devices and carriers. Want to use certain APIs to access system or user information? No problem, fill out a form and pay a small fee to get your signing key, then program away. Want OTA deployment? No problem. Want to control what applications can do? No problem.
• Different development tools. This surprises Java ME developers, but you can’t just take a Java class file and install it on a BlackBerry. The BlackBerry’s VM is not actually a Java VM, it’s a Java-like VM with its own bytecodes that was developed specifically for the BlackBerry architecture. So Java class files need to be transformed into COD files before they can run. So yes, you can use Ant, Eclipse and/or NetBeans for code development, but you’ll still end up using RIM’s tools (at a minimum, their compiler and their signature tool) to build your application.

Don’t think, though, that all is perfect in the BlackBerry world. The documentation is often maddeningly incomplete, obscure, or sometimes just wrong. The dependency on RIM for the development tools is frustrating (why can’t we have a signature tool that lets you specify the password for the certificate repository on the command line so that we can do automated builds?). The BlackBerry developer community is smaller than the Java ME community at large, making it hard to get in-depth help without joining RIM’s partner program. Every serious BlackBerry developer will have a similar list of “gotchas”.

So this is why I feel it’s important to keep the Java ME and BlackBerry discussions separate, hence the need for two different blogs. If you’re interested in BlackBerry programming, you should subscribe to both blogs, but if you’re a general Java ME enthusiast this blog is enough to read.

Anyhow, onwards and upwards!

Technorati Tags: Java ME, J2ME, BlackBerry, Research In Motion, BES, MIDP

import com.sonyericsson.junit.framework.*;

public class MyTest extends TestCase {
    public void testOnePlusOne(){
        assertBoolean( 1 + 1 = 2 );
    }
}

You can build entire test suites of test cases and automatically run the tests using test runners that display their results either on the console or in a window (there are runners for AWT and for Swing).

Mobile JUnit is a rewrite of JUnit specifically for CLDC-based platforms. Because JUnit depends on reflection and reflection is not available with the CLDC, Mobile JUnit takes a different approach and gathers testing information at compile time and generating helper classes to actually run the tests. (As a side note, Mobile JUnit is based on JUnit 3.8.1 — later versions of JUnit have dependencies on Java 1.5 features like annotations.) It then compiles everything into a MIDlet and runs the MIDlet in the emulator for you. You can even do on-device testing (for Sony Ericsson phones) if necessary, without having to install the MIDlet on the device — Mobile JUnit takes care of that for you.

Even though Mobile JUnit is from Sony Ericsson and by default assumes you’re using it with the Sony Ericsson SDK for CLDC programming, Mobile JUnit can be used with any tool that is based on Sun’s Wireless Toolkit (WTK). If you’re looking to add some automated testing to your build procedure (Mobile JUnit integrates well with Ant) then check it out.

Technorati Tags: J2ME, Java ME, JUnit, Mobile JUnit, unit testing, testing

The basic idea is quite simple: define a common interface (Persistent) with methods that are invoked whenever the application wants the object to save or restore its state. It’s not automatic by any means, because the creator of the class has to write the code that does the saving (persist) and the restoring (resurrect). But with our trusty friends DataInputStream and DataOutputStream it’s pretty easy to do and with some forethought (put a version number at the start of the serialization stream) you can even write persistence code that is upwardly compatible.

Restoring the object is not as elegant as it could be, however. This is because we can only create objects via the newInstance method of the Class object. So what we do is create a prototype object using the null constructor (which, due to the lack of reflection, is the only one available to us) and then invoke resurrect to initialize the new object’s state.

This particular reader was having problems with the speed of the object restoration in my VectorHelper class. VectorHelper is a convenience class used to persist and restore Vector objects, as long as the Vector contained nothing but strings, integers or objects that implement Persistent.

Here’s the restoration code in question:

   public static Vector resurrect( byte[] persisted )
                            throws IOException {
        ByteArrayInputStream bin =
                    new ByteArrayInputStream( persisted );
        DataInputStream      din =
                    new DataInputStream( bin );

        Vector v = new Vector();
        int n = din.readInt();

        for( int i = 0; i < n; ++i ){
            int type = din.readByte();
            if( type == NULL ){
                v.addElement( null );
            } else if( type == INTEGER ){
                v.addElement( new Integer( din.readInt() ) );
            } else if( type == STRING ){
                v.addElement( din.readUTF() );
            } else if( type == PERSISTENT ){
                String cname = din.readUTF();
                int    len = din.readInt();
                byte[] tmp = new byte[ len ];

                din.readFully( tmp );

                try {
                    Class cl = Class.forName( cname );
                    Object o = cl.newInstance();
                    ((Persistent) o).resurrect( tmp );
                    v.addElement( o );
                }
                catch( IOException e ){
                    throw e;
                }
                catch( Exception e ){
                    throw new IOException( "Exception " +
                        e.toString() );
                }
            } else {
                throw new IOException( "Unknown " +
                   "type " + type );
            }
        }

        return v;
    }

Can you guess where the bottleneck might be?

It’s the code that restores Persistent objects:

    Class cl = Class.forName( cname );
    Object o = cl.newInstance();
    ((Persistent) o).resurrect( tmp );
    v.addElement( o );

The problem is that dynamically looking up a class (Class.forName) and/or instantiating it (cl.newInstance) is very slow on some devices. The solution for my reader was to speed up this process by removing the generic class lookup and instantiation code and replacing it with code specific to his application. For example, say you had two classes Employee and Student that both implemented Persistent. Then you could code:

    Object o;
    if( cname.equals( "com.mypackage.Employee" ) ){
        o = new Employee();
    } else if( cname.equals( "com.mypackage.Student" ) ){
        o = new Student();
    } else {
        throw new UnknownClassException(); // oops!
    }
    ((Persistent) o).resurrect( tmp );
    v.addElement( o );

And suddenly the restoration code is much faster.

The whole point of this example is that Java ME programming often boils down to writing specialized code instead of writing generic code. The examples in my J2ME Tech Tips and other articles tend to be generic because they need to work over a wide variety of platforms. And writing generic code often feels like the “right” or “correct” thing to do. But correctness in programming isn’t about conforming to abstract notions of what’s good and what’s bad, it’s about writing code that works and meets user expectations. This is particularly true with Java ME programming. You can get away with a lot of fat on desktop or server Java — you just run it on a faster machine or give the VM more memory. You can’t do that with Java ME applications.

Somedays when I’m feeling prickly I think that all Java programmers should learn Java on an old Motorola or Nokia phone with a 50K limit to the size of the application. Because it really forces you to think carefully about your algorithms and how you’re using memory. And in the end I think it makes you a better programmer. If I had to choose between hiring someone who’d learned Java by doing J2ME programming versus someone who’d learned it doing J2EE programming, I’d hire the J2ME coder.

Any Java coder can learn new APIs, but learning the mindset of efficient and effective Java coding is much harder to do if it’s not ingrained from day one.

Technorati Tags: J2ME, Java ME, serialization, coding, programming, CLDC, learning Java

What Does J2ME Stand For?

J2ME is an acronym for Java 2 Micro Edition, known more formally as Java 2 Platform, Micro Edition. When Java 2 was introduced in 1999 as the formal name for the Java programming environment (renaming what until then had been known simply as “Java 1.2″), the Java platform was split into three variants:

• Java 2 Standard Edition (J2SE), aka “desktop Java” — the Java we all knew and loved
• Java 2 Micro Edition (J2ME), aka “wireless Java” — Java for mobile phones, handheld devices, and other constrained environments
• Java 2 Enterprise Edition (J2EE), aka “server-side Java” — Java for server-side, database- and message-centric computing

Of course, if a name changes once, there’s nothing to prevent it from changing twice…

What does Java ME Stand For?

In 2005, Sun decided that the “2″ in “Java 2″ no longer made any sense as a platform designation, given that Java 5 (aka Java 1.5) was now the standard and that Java 6 was in development. Henceforth, the three variants of the Java platform would be known as:

• Java Standard Edition (Java SE)
• Java Micro Edition (Java ME)
• Java Enterprise Edition (Java EE)

So J2ME officially became Java ME. Sun sucked it in and went and renamed all references to these technologies on its websites and documents.

J2ME Just Sounds Better

So given that Java ME is the official shorthand term for wireless Java, why do I still refer to J2ME?

Call it force of habit… I’ve been writing about J2ME since 1999, when I first started writing Java 2 Micro Edition: Professional Developer’s Guide. This continued with the publication of my J2ME Tech Tips and various articles on Sun’s developer site. And of course the second book. In short, the term is ingrained.

But I also find that “J2ME” rolls off the tongue much more easily, at least in English. “Java ME” is longer, and “JME” sounds like someone’s name. So that’s another reason to stick with J2ME. I suspect many of the old-timers (hello everyone on the KVM-INTEREST mailing list) feel the same way, though I’ve never asked anyone else.

What To Expect From This Guide

The Java ME Programming Guide J2ME Programming Guide is my new site for J2ME-related material, a replacement of sort for Eric’s J2ME Pages, which I never really fleshed out. Rather than refashion those pages, I’ve decided to start anew.

What you can expect here is the occasional post with tips, tutorials and news about J2ME programming. I’ll be updating some of my older material, announcing the publication of new material, and posting the occasional comment or essay about J2ME.

It’s my new window into the world of Java ME programming, and I hope you’ll ride along with me.

Technorati Tags: J2ME, Java ME, Java, wireless, J2SE, J2EE