J2ME Programming Guide

I’ve submitted a follow-up article to my introductory SOA and Java ME article. The new article focuses on asynchronous calls, and I’ll post an announcement here when it goes live. However, I wanted to talk further about one of the claims I made in the article on how Java ME and AJAX are related.

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

My new Java ME Tech Tip Service-Oriented Architecture and Java ME has been published on the Sun site. It’s a general introduction to SOA, with a Java ME twist of course. More SOA tips are to follow.

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

You may wonder why I’ve chosen to create a separate blog, BlackBerry Developers At Work!, to discuss development issues for Research In Motion’s BlackBerry platform. The BlackBerry platform is a Java ME platform, after all, and RIM is on the JCP’s ME executive committee and on several expert groups for important Java ME standards, such as MIDP 3.0. So why treat BlackBerry programming separately from Java ME programming?

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