Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Master J2ME for live data delivery

Support multiple applications on multiple devices with this J2ME framework

By John Chamberlain, JavaWorld.com, 05/31/02

Page 2 of 6

Experienced J2ME developers will want to use an integrated environment for greater convenience, but alternatives—such as using KToolbar, or even compiling, preverifying, and debugging from the command line—are completely workable. For wireless applications, how you organize your architecture end-to-end is much more important than your development tools in determining a given application's overall maintainability. This is why basing your projects on a sound design is so important.

Overview of live data requirements

To architect J2ME applications that require live data updates from a server, you must first analyze the functionality range you desire. Figure 2 shows the typical case.

On the client side, MIDlets support any Java-enabled device. The device's MIDlets divide conceptually into three separate code regions along the lines of the Model-View-Controller (MVC) pattern:

• Model: Preferences, constraints, and application data
• View: Display logic
• Controller: Communication and application logic

The controller should support both data polling and listening for notifications. Currently, the MIDP specification does not support listening, but the upcoming MIDP 2.0 will. In addition, some devices, such as RIM's BlackBerry, currently have extensions to support listening for server push. You must prepare the display logic to render appropriate interfaces over a range of resolutions. The data model includes user preferences, application constraints, and the presentation data.

The idea behind application constraints is that different data model versions can be appropriate for different device types. For example, if the device does not support sound, then the server should not waste bandwidth by including application sound files in its data transmissions. Likewise, the server might send different logo and image sets depending on whether the device has a medium-sized display (160 by 160 pixels) or a small display (120 by 120 pixels).

On the server side, the architecture should be prepared to deliver its data via a variety of interfaces, including WML and servlets. Under normal circumstances, servlets are the preferred method of communicating with a MIDlet. With WML presentation capability, you have a backup in case the user cannot install the client for some reason or has trouble operating it. Being able to implement the framework with J2EE interfaces is also an important server-side consideration because most commercial clustering systems only work with Enterprise JavaBeans (EJBs).

Servers should also have a notification engine that lets them send and receive out-of-band messages, such as SMS (short message service) messages and email. This capability can be an integral part of your application and can also act as a backup system. If you have users who do not have Java-enabled devices, your notification engine might be the only way to reach them.