There are many kinds of mobile applications and many different categorizations. It's useful to consider the differences between connectionless and connected applications. Connectionless applications generally work without access to any remote device or server (although they may periodically "sync" with other systems). Connected applications generally work in concert with a remote system (although they may also have periods where access to the remote system is unavailable). And of course, systems can be a mix of both.
Connectionless applications tend to focus on personal productivity - storing memos, accessing phone numbers, etc. On the other hand, enterprise users generally need access to enterprise information - data that is not generally available on the mobile device itself and so can only be leveraged in a connected application. Until now most applications on mobile devices have been of the connectionless variety. There are many reasons for this, but the most significant have been the lack of reliable connectivity and the complexity of developing such applications. However, as wireless networks become more and more pervasive, and as enterprise applications continue to migrate out of the back-offices, the demand for connected applications will increase.
Indeed we already see signs of this demand in the embracing of J2ME by various wireless companies as well as a flurry of Java Specification Requests (JSRs) on the topic (JSRs 62, 120, 124, and 129, for example). The thrust of these efforts is to give developers the components and tools that they need to create applications that run over wireless networks in the same ways that developers are able to create applications for wired networks today.
Unfortunately, the shift from "wired" to "wireless" is more than simply a question of how to move data through the air. The move to the wireless world presents connected applications with a host of problems including platform heterogeneity, limited device computing capacity, and tool immaturity as well as the obvious problems of limited bandwidth and foreign communication protocols.
There are hundreds of different wireless devices, from cell-phones to pagers to PDAs. Consider that the Motorola Web page offers more than 30 types of cell phones that have networking capabilities. While certain devices have received a lot of public attention (Palm, RIM's BlackBerry, etc.) there is currently no leading platform and no de facto standard on the horizon. And of course, the hardware choices offer very different functionality -- infrared communication, data backup, color displays, etc.
Added to the complications of hardware choices is the fact that the operating systems and software on these devices are not standardized -- some devices even have their own proprietary programming languages (FLEX for Motorola and BREW for Kyocera, for example), While individual companies have started to standardize across their lines of devices, there is not a dominant OS. And when you consider software and tools, the commonality within a single company's offerings begins to disappear. On one hand, these choices offer more options to a developer; however, they also mean that if you are trying to create an application where you can't dictate the choices of your users (or you just don't know what they're going to be), you have a real problem.
As if the hardware and software heterogeneity didn't make your life hard enough, the networking situation might push you over the edge. While there is lots of talk about standardization of networks and protocols (GSM, 3G, WAP, etc.), the reality is that currently there is no right way to send information to wireless devices. Some networks allow lots of data but have high latency periods; others are fairly responsive but have a small bandwidth. Some carriers only support WAP, while other make IP-based connections -- and so on.
The bottom line is that these problems make it hard to write connected enterprise applications without a lot of careful consideration of the components and architecture that your application will be using. In 2000, Applied Reasoning decided to port its Classic Blend product to wireless devices, to help developers build connected enterprise applications. While we were porting the product, we ran into (and solved) problems -- in this article I describe the choices we made and why.
Our overall goal was to allow users to develop wireless applications with as little regard as possible for the idiosyncrasies and limitations of the target device. The caveat in the last sentence is critical -- we recognized that "write once, run anywhere" solutions were even less applicable in the wireless world than in the wired one. However, the goal of limiting device dependence was still valid.
Classic Blend is a presentation server that allows developers to build dynamic, real-time Internet applications and control them from the server. (For more information on Classic Blend, visit www.appliedreasoning.com.) As with the original Classic Blend product, our mobile version (called Mobile Classic Blend) allows developers to lay out their UIs with tools appropriate for the target platform (PilrcEdit for PalmOS, Platform Builder for WinCE, and so on). However these interfaces are controlled by application logic that is running remotely on the server. In short, our goal was to create a server-centric application architecture that would allow developers to be minimally impacted by diverse platforms, but at the same time, be able to customize their interfaces appropriately for each device.
The sample below is an example of the specification of a Palm interface built using the standard Palm format. Following the samples is a view of the interface in a GUI builder. The top part of the definition is standard interface definition elements while the bottom part (beginning with STRINGTABLE) contains information for Classic Blend. Some lines of code in this example and in those that follow have been split so that they can be displayed here.
#include "chat.h"
ICON ID bitmapIcon "cbAppIcon1bpp.bmp"
LAUNCHERCATEGORY "Classic Blend"
// Forms and Alerts
FORM ID ChatLogonForm AT (2 90 156 68)
MODAL
BEGIN
TITLE "Chat Logon"
LABEL "User Name:" ID NoID AT (5 29) FONT 0
FIELD ID UserNameField AT
(PREVRIGHT+5 PREVTOP-1 48 AUTO)
FONT 0 UNDERLINED MAXCHARS 10
LABEL " " ID StatusLabel AT
(5 48) FONT 0
BUTTON "Login" ID LoginButton AT
(117 29 AUTO AUTO) FONT 0
GRAFFITISTATEINDICATOR AT (144 54)
END
FORM ID ChatForm AT (0 0 160 160)
NOFRAME
BEGIN
TITLE "Classic Blend Chat"
LIST "" ID ParticipantsList AT (122 17 36 AUTO)
FONT 0 VISIBLEITEMS 10
BUTTON "Send" ID SendButton AT
(RIGHT@PREVRIGHT PREVBOTTOM+4 40 AUTO)
FONT 0
FIELD ID MessagesList AT (2 17 110 110) FONT 0
UNDERLINED MULTIPLELINES MAXCHARS 32767
HASSCROLLBAR
SCROLLBAR ID MessagesListScrollBar AT (113 17 7 110)
VALUE 0 MIN 0 MAX 10 PAGESIZE 1
FIELD ID EntryField AT (4 130 101 13) EDITABLE FONT 0
UNDERLINED MAXCHARS 30
LABEL " " ID StatusMessage AT
(PREVLEFT-2 PREVBOTTOM+3) FONT 0
GRAFFITISTATEINDICATOR AT (150 147)
END
STRINGTABLE ID Properties ""
"host" "127.0.0.1"
"port" "55551"
"applicationname" "palm"
"serverobject" "chatpresenter"
"onewaytimeout" "250"
"event.1002.ctlSelectEvent" "loginUser"
"event.1102.ctlSelectEvent" "sendPressed"
"scrollBarFieldLink.1106" "1103"
|
Figure 1: The chat GUI
The sample below shows the application logic that is written to control the user interface described above. This code runs on the server and not the client. Notice that the developer writes his code as if the widgets were resident on the server. This gives the developer the best of both worlds -- device-specific UIs and server-centric programming.
public void addChatParticipant(ChatUser aChatUser) {
getParticipantsList().add(aChatUser.getUserName());
getStatusInfoArea().setText(aChatUser.getUserName()
+ " has joined");
}
|
This server-centric architecture is well suited for enterprise wireless applications but it significantly constrained our choices in hardware, software, and networking. Because access to the server is critical, the network was one of the primary concerns. We needed a network that had a relatively low latency. Since all application processing would occur on the server, it was important to be able to dispatch requests and receive responses quickly. We knew from our experience with previous versions of the product that bandwidth would not be an issue (messages between the client and server are typically 5 - 200 bytes), so we looked for solutions that had low latency, regardless of bandwidth limitations.
We also wanted to be able to wake up applications that weren't active to deliver them data. For example, we wanted a user to be able to receive an e-mail notification and have the application react to the e-mail, even if the application wasn't being used at the time. This pointed us to devices that had SMS capabilities that we could leverage.
We needed to make sure that the client components that we built would be responsive and wouldn't require too large a footprint on the device. We assumed that our system would not be the only application on the device, and we didn't want ours to be ten times the size of any other application on the device.
Of course, there were also non-technical considerations. While there was no clearly dominant player, there were some companies that had larger shares of the market and were better positioned for deployment of enterprise applications. We couldn't allow purely technical consideration to blind us from the fact that we wanted our system to be used by many people.
Finally, while our analysis was based on the current state of technology, we knew that technology wouldn't stand still. The conclusions and choices that we made now might be obsolete in six months. So we wanted to build our system to be as easily portable to other devices as possible.
We planned to reuse as much of our server component as possible and so Java technology was the natural choice for the Server. Aside from the existing code base, we knew from experience that the rich tool support was critical. The development tools (we used IBM VisualAge for Java) made team development highly productive and the presence of application servers (we used both IBM WebSphere and BEA WebLogic) made it possible to develop scalable and fault-tolerant applications.
The first real choice was to also use Java technology on the devices. While the language was far from ubiquitous, it had fairly wide acceptance and industry support. And in addition, we felt that it held the best hope of being a universal client software platform in the long run. It also had the advantage of a number of evolving standards (such as J2ME) that promised to eventually standardize the usage, programming, and access to wireless devices.
Networking was also a big issue. It was clear that eventually there would be networks that provided all the capabilities that we were looking for, but we wanted to release our product in the middle of 2001 and the 2.5G networks were still far off. In order to support the response times we were looking for, we decided we needed "direct connections" -- in other words, we didn't want to be at the mercy of the high latency of current packet-based networks.
We also needed to pick the hardware to use. We had narrowed our list to a couple of different devices based on their market penetration and UI capabilities. We wanted to be able to develop interesting applications with our first product release. The top choices were the Palm, WinCE devices, and RIM devices. We leaned toward the Palm devices because of their large market share and strong Java support.
The decision was made easy when we learned of intended release of the Kyocera SmartPhone. This unit had both a Palm and a phone built together, and most importantly, had the Palm's networking integrated with the phone's modem. This meant that we could use the PalmOS to display the user interfaces and have the phone provider (Verizon or Sprint) set up the connection that would have sub-second response times (average roundtrip time <300 ms).
All that was left to do was to pick an actual Java Virtual Machine and tools for our client development. The most obvious choice was Sun's KVM. Since this was the reference implementation for the Palm platform, it seemed that it was most likely to have the capabilities that we wanted. However, we quickly found ourselves on the bleeding edge of the evolving wireless standard. The KVM and its accompanying libraries (CLDC and MIDP) only supported emulated widgets. This meant that applications built with them wouldn't look and feel like Palm apps. In addition, our tests showed the IU interactions to be sluggish and our applications performed poorly. These issues, coupled with the large virtual machine footprint (> 300K) and the lack of access to basic Palm features, made us look elsewhere. Note: Since that time, MIDP for PalmOS and newer versions of the KVM have been released and have helped resolve some of these issues.
We turned our attention to IBM's J9 virtual machine. This virtual machine also had a high degree of platform support. In addition, it was well integrated with VisualAge Micro Edition, which meant that our developers could develop, test, and deploy code from within the highly productive VisualAge environment. The remote debugging that allowed VisualAge Micro Edition to monitor an application running on a PalmOS simulator was especially useful.
With a footprint of only 100K, J9 performed extremely well. The sample UIs we built were just as snappy as native Palm applications. And because it allowed access to the underlying Palm UI component as well as other Palm specific features, the applications also had the look and feel of a native Palm app.
The access to native elements was critical for creating responsive UIs that would have a familiar look and feel for users. The sample below shows an example of how the method that sets the text for a TextField is executed by accessing system functions via the J9 virtual machine.
public void
labelSetText(FormLabelType receiver, String str)
{
try {
WM.beginDraw(this);
if (isOpen()) {
OS.FrmHideObject(getForm(),
getObjectIndex(receiver));
}
setLabelText(receiver, str);
if (isOpen()) {
OS.FrmShowObject(getForm(),
getObjectIndex(receiver));
}
} finally {
WM.endDraw();
}
}
|
It was also critical for our application to be responsive despite having a relatively slow processor. A number of our optimizations required access to the underlying system that would have been impossible with J2ME, but were very easy with J9. One such example is string copying -- an operation that occurs in many different areas of the system, but is central to changing the contents of the text widgets. For large strings, using the standard method for setting the contents of the text field involves string copying and is very expensive. In order to reduce this cost, we used J9's access to the underlying system to allow us to copy the bytes of the string directly into the memory of the text field. This device-specific optimization improved our performance by over 400% -- reducing a 3+ second wait to less than half a second. The code that performed this optimization is shown below.
MemHand hndTxt = OS.FldGetTextHandle(txtField);
OS.FldSetTextHandle(txtField, MemHand.NULL);
if (OS.MemHandleSize(hndTxt) < fieldSize + 1) {
int err = OS.MemHandleResize(hndTxt, fieldSize + 16);
getPalmOrb().sysCall("Unable to resize memory for field",
err, err == 0);
}
CharPtr txt = new CharPtr(OS.MemHandleLock(hndTxt));
OSBase.memCopy(txt.getCPointer()
+ offset, str, 0, fieldSize - offset);
txt.setCharAt(fieldSize, 0);
|
J9 also provided a solution for the SMS access we wanted. Sending an SMS message from the server is straightforward and is provided by the JavaMail API. The server code is shown below. In order to receive this message, it was necessary to leverage platform-specific code, provided by the phone manufacturer, that would receive and process the SMS message. This code takes the message and passes it to a small program that decides whether to wake up the target Java application and deliver the message's contents immediately or to wait for the user to return to the application. The key to this process was being able to leverage the vendor provided API to receive SMS messages -- J9 allowed us this access, standard J2ME did not.
public void send() throws MessagingException {
Message msg=new MimeMessage(getSession());
msg.setFrom(new InternetAddress(_mailFromAddress_));
msg.setRecipients(Message.RecipientType.TO,
InternetAddress.parse(getToAddress(), false));
msg.setSubject(getSubject());
msg.setText(getMessage());
Transport.send(msg);
}
public Session getSession() {
Properties props = new Properties();
props.put("mail.smtp.host",getMailhost());
props.put("mail.host",getMailhost());
props.put("mail.from",_mailFromAddress_);
props.put("mail.smtp.user",_mailFromAddress_);
session = Session.getInstance(props, null);
session.setDebug(false);
return _session;
}
|
The common thread in these examples is that while it was beneficial to write most of our application in a device-independent, cross-platform manner, there were times when it was critical to be able to access device-specific capabilities. These instances, while relatively few, were the difference between a mildly interesting, somewhat useful app and a responsive, compelling, highly productive application. The ability to access the underlying system that J9 provided was one of the keys to the system's success and would have not been possible with J2ME.
The choice to go with J9 (and VisualAge Micro Edition) also seems to have been a good long-range plan. While the initial versions of J9 haven't been J2ME compliant (which is an important issue to some of our customers), future releases are moving in that direction (and the J2ME spec is moving closer to some of the J9 approaches).
The first version of Mobile Classic Blend was completed in August, 2001, along with a number of demo applications. These applications demonstrated the power of the Classic Blend approach, live bank portfolios, stock tickers that updated in real time, and mail readers that would pull down mail as soon as it was received by the server and notify the user by "waking up" the device. In addition, these applications run side-by-side with their wired versions, allowing wired and wireless users to interact seamlessly.
However, these applications work not just because of Classic Blend, but also because of the technology choices that Classic Blend was built upon. The choices of hardware, software, and networking have a profound impact on the enterprise applications that run across them. And in the wireless world, where the choices are highly divergent, this impact is even greater.
The choice of the PalmOS as our first platform was important, and made more so by the emergence and popularity of the SmartPhone. Our decision to use Java technology on our client was likewise critical. The decision to go with J9 left the product well positioned to serve both the J2ME-compliant and non-compliant worlds. In short, the time and effort that we spent in making the appropriate choices are now bearing fruit. In time, we expect them to pay for themselves many times over.
- Get more information about Classic Blend and Mobile Classic Blend from the Applied Reasoning Web site and in this white paper (PDF).
- Get an overview of wireless network protocols and technologies from this site:
- GSM World has information about GSM, WAP, and SMS.
- Find out more about VisualAge for Java at the product site or on
VisualAge Developer Domain.
- Explore the intricacies of wireless development in developerWorks' Wireless zone.
- Read about the upcoming Samsung phone, which also integrates a mobile phone and PalmOS.
- Get more information on J2ME.
Dan Drasin has been working with Object Oriented technology since 1989. At Applied Reasoning (www.appliedreasoning.com), he has been responsible for the development and delivery of a number of different products, including Classic Blend. Additionally, he has helped numerous Fortune 500 customers develop distributed systems. Recently, Dan has been working on the development of Applied Reasoning's Java-based mobile computing solutions. Dan can be reached at drasin@appliedreasoning.com.
