Avoid 6 'Gotchas' in Enterprise Mobile Dev
The increasingly common job of "mobilizing" existing applications should not be approached with the same mindset that integration developers used to create applications in the past, according to enterprise wireless experts from Intel and IBM at last week's Software Development 2004 Best Practices event in Boston.
When conducting a wireless integration project for the enterprise user, special attention must be placed on three key factors, the panel said:
- The nature of the "occasional connectedness" of a device (and whether that device will need to operate independent of a wireless connection to a host);
- The value of documents being accessed and/or passed; and
- The special demands of constrained mobile device resources.
Integration Developer News provides some detailed tips on spotting these potential gotchas, and designing and developing wireless apps to avoid them.
Gotcha Tips for Enterprise Wireless Devs
1. Reliability C.V. Vick, a senior software architect for Intel Corp., describes the differences devs should watch for: In previous distributed systems, he explained, "most applications have been written for dial-up or Ethernet [connections], which are extremely reliable." In contrast, wireless nets are inherently unreliable. "Someone opening up a microwave oven can blow your whole wireless network out," Vick said. Many of the failures of first-generation web-oriented wireless networks arose, he said, because designs and developers assumed the "reliability" of such technologies.
2. Synchronization Vick also pointed out that while synchronization with LANs is pretty straightforward, that's far from the case in the wireless domain. Developers should take care when formulating what Vick calls "granularity of the synch" -- in other words, requiring too large a start-of-day download, or even too many step-downloads, in some wireless settings, can spell disaster. So, keep it simple and in small steps, especially at start-up, Vick advised.
3. Resource Limitations IBM's senior software architect David Reich said that Big Blue is in the process of fine-tuning its app dev tools to enable better deployment of wireless apps to small clients. Two key features are: (a) support for on-board databases; and (b) new J2ME components (that have migrated to Java wireless from the J2EE server-side domain.).
"We have a set of wizards based on the J2SE and J2EE programming model, and these will generate code," Reich said. "For mobile developers, we have a set of tools that let you further optimize the code and assist you in overriding everything that gets generated for you." Thus, elements of J2SE and J2EE styles can be brought down to the less familiar J2ME space, and, in turn, off-load servers and reduce trips between device and server.
Tools should help developers partition the new wireless app, he said, helping them decide how much is going to be done offline locally, where transactions can be queued up for future sends, and which functions should be isolated and invokedonly when the user is hooked up to the server.
In Reich's view, one key step to optimizing development for enterprise wireless is to override those handy code generators. "When it comes to development tools, let's face it, we all write really fat code these days. We assume tons of disk space. These devices don't have it," he said.
4. Context-Sensitive Development While Intel's Vick didn't offer any new insights on Intel's wireless toolset, he did offer devs a view into how such "limited resources" should affect how they design and develop an application. "The [wireless] devices are portable. What this means is that there are resource constraints," such as smaller screens, less memory, limited battery life, etc. -- and worse: "Devices get lost and stomped on," Vick said.
Devs should protect against these pitfalls by considering whether important application data should to be timed to expire, Vick said In other words, there are "context" issues to be considered. Examples of context-sensitive development for enterprise wireless could be: the location of the user may even determine the level of secure connection needed. A device's amount of remaining power the device might need to be determined before allowing a large client-host synch to be initiated. And, even if these sound like good steps to take, the designer/devs should make sure they are done using system architectures, rather than individual devices, to ensure that all policies stay consistent regardless of the device in use.
A solution designed to make it easier for designers, devs and IT staff to invoke "context-sensitive" capabilities is coming from Tailwind Solutions, an enterprise wireless management software firm in San Mateo, Calif. Tailwind's FieldSpace software tracks digital asset deployments to distributed workforces, and was designed expressly for "occasionally connected" devices. FieldSpace enables IT staff to set policies so some groups have access to certain sets of information while working offline, while other apps are set to allow access only if users are in a high-bandwidth environment.
David Koehn, founder and CEO of Tailwind, described the designer/dev challenge this way: "Now that information is moved off the network, off the web server, and onto the mobile device, and now that some of the application logic itself has moved onto the mobile device, we have to determine what happens to the information resident on the mobile device." Koehn cut his teeth on these types of wireless dataflow issues at wireless pioneer AvantGo.
To figure of what should "happen" to the data/logic that is now local to the device, Koehn suggests devs ask two key questions:
- "Is there some particular date or time when I need it to expire?" and
- "Which users do I want to have which access to which pieces of information?"
5. Leveraging Legacy Docs, Apps As daunting, and customized, as enterprise wireless development may seem, at least one panelist held out hope that designers and devs can leverage a great deal of resources from their desktop-driven development. The key is the use of "document-centric architectures," according to Yogen Patel, vice president of products for Sunnyvale, Calif.-based Sandhill Systems.
"A document-centric computing model," Patel said, "leverages the fact that there are these containers sitting on all these devices, allowing you to remove the whole client dependency headache from the equation." Moreover, "an interactive document can be used to communicate, collect information, and interact with users," said Patel. The document can have the intelligence to send or cache the data, Patel said, depending on circumstances.
What kind of documents are we talking about? Many familiar faces, including Word, PDFs, Excel and XML, Patel said.
"One thing you can do as a developer is rely on the standard containers that are available on computing devices," Patel said. "For example, Adobe Reader is a standard container that is universally available. Microsoft Office 2003 is becoming widely available, as is Macromedia Central." Recent improvements to PDF and Excel document specs better support such capabilities, he added.
Developers should ask themselves how they can use applications that run within these standard containers, given that "the developers of these containers are taking care of making sure that [for example] Adobe Reader is working across these devices."
6. Wireless Extensions to Legacy Apps Panelists shared some basic tips for integrators that are extending apps on the wireless frontier:
- "Keep it simple and keep it extensible," said Tailwind's Koehn. When moving web applications to wireless, people too often start out with too big a problem, he said. They later learn they have to support a new interface or add new features, he said, and that "the path they have chosen can't accommodate these additional desires."
- "When you're looking to mobilize an application, look at your business process model, and then look for tasks that run in parallel," said Intel's Vick.
- "When you're mobilizing an existing application, explore alternative architectures," said Sandhill's Patel. Your app may have an underlying database, and the first thing that may come to mind is replicating SQL, he noted. "But that might not be the best way to go about doing it," he said, suggesting that it may at times be easier to have an XML flat file data store on the local machine, and to use web services to do necessary synchronization.