Contents: What every wireless developer should know What every wireless developer should avoid The challenges every wireless developer faces Greatest success versus biggest failure The lady's killer application In conclusion Resources About the author Rate this article Related content: See previous columns Subscriptions: dW newsletters dW Subscription (CDs and downloads)

John Papageorge (mailto:john@mediaoverdrive.com?cc=&subject=Nancy Lehrer)
President, Media Overdrive
2 October 2003

Nancy Lehrer's skills formulated in her artificial intelligence (AI) work for the U.S. government. Nowadays, the mobile applications she's creating are benefiting quite nicely from her unusual bank of knowledge. We pass it on to you.

Nancy Lehrer's forte in artificial intelligence was image understanding, and that dates back to one of her first gigs in the early 1980s when she landed a job at a small company that, almost exclusively, did applied research on government-funded projects under DARPA (Defense Advanced Research Projects Agency).

"At this company we did planning work, knowledge representation work, and information integration work. When I left 9 years later, I was the head of the Information Integration Technology group, and I had gotten the opportunity to work directly with a huge number of AI/Computer Science researchers throughout the country. I worked with the first versions of C++, CORBA, OODBMS, UML tools, and Java.

"But I wanted to learn about applying this technology in the Internet space and this began the second part of my career journey. During this time I've worked as the Directory of Architecture at GoTo.com (now Overture Services, recently bought by Yahoo) and as the Director or Software Engineering at HomeStore.com." explains Nancy.

When Lehrer got caught in the middle management down-sizing during the big tech bust in late 2001, she returned to her developer roots and joined Jeff Bonar, CEO of JumpStart Wireless, where she's currently applying her skills and energy.

Lehrer has been porting the JumpStart Wireless DispatchSuite product from Reflex (running on Skytel 2-way pagers) to J2ME. She specifically targeted the new Nextel phones (i55 and i85). "I did not realize then that I would be one of the first to write a substantial business application in J2ME," she says. "It felt really good to get back to hacking out the code. I also found a never-ending supply of interesting challenges in the DispatchSuite product."

Here's Nancy's mobile toolkit of choice, as she explains:

• eMacs: "I love editors that understand the language you are working in."
• Cygwin: "It gives me a Linux-like development environment all in the comfort of a Windows desktop".
• Jshrink: "Because it lets me put 100 lbs. of potatoes in a 50 lb. sack (it's an obfuscator and code pruning application)" she says. "I could use a good symbolic debugger and profiler, but alas...."

Phones: Nextel iDEN phones (i55, i58, i85, i88, i90, i95cl) In emulation: Nokia 6600 (and other Series 60 phones), Sanyo 8100, Blackberry RIM (OS 3.6)

In beta: Pocket PC on IBM MIDP 2.0 (pre-release) Real soon now: Palm on IBM MIDP 2.0 (pre-release)

Technologies: J2ME MIDP 1.0 (currently porting to MIDP 2.0)

Lehrer's secret weapon?

Lehrer says simply that her extensive background in knowledge representation, distributed computing, and AI, combined with her consuming quest to figure out the right paradigms for any particular programming tool or language, are her secret weapons.

"It is pretty easy to figure out what you can do with a tool or language, but it is another matter to figure out the best way to use it and what the best problems to apply the tool or language to are," she says. "So, I'd say my biggest secret weapon is using the right tool (language, representation) for the job. And to do this, you need to figure out the right way to use each tool or language."

What every wireless developer should know
Lehrer says that everyone should be familiar with such issues as the MIDLet life cycle, the limitations of the WAP interface, and "why you don't want to build the desktop application on the wireless device; instead, you want to 'extend' the desktop to the hand-held."

What every wireless developer should avoid
Lehrer notes that developers will want to avoid Canvas graphics unless they're really needed; they are quite expensive and, as proprietary APIs, do not port across platforms.

The challenges every wireless developer faces
Lehrer believes that a common challenge for developers is using a mobile device's UI effectively. Lehrer says that mobile developers often battle with the trade-off between maintainable coding style and trying to add one more feature when you have already reached the limit of what can be loaded on in 256 K of heap.

Another struggle that Lehrer deals with is porting across the multitude of devices ("trying to find the java specs for each!") and understanding the many different ways to load applications onto devices.

Greatest success versus biggest failure
On the other hand, she claims her worst failure was initially designing the applications with six threads synchronized by reading objects from data queues. "It was a great design, but behaved miserably on the devices and crashed a lot," she says.

The lady's killer application
Lehrer's opus and favorite mobile application is the JumpStart Wireless DispatchSuite, which allows office workers to create work for mobile workers and send "business forms" to their dispatched workers. Business forms capture both information sent to the mobile worker (customer name, address, problem description, and so on) as well as information coming from the dispatched worker back to the office (for example, start and stop times, activities performed, charges to be made). Business forms are stored on the wireless device so the worker has access to data and forms even when out of coverage.

The DispatchSuite application on the hand-held is a general-purpose business forms browser -- business forms consisting of collection fields. "We currently support a number of field types including static text, text entry, activity time capturing, activity start and stop times, catalog entry capturing, a set of line items (typically used for capturing parts used, but they are very flexible), yes/no confirmation, and a few others," explains Lehrer. "Our server sends descriptions of forms to the hand-held and the forms browser is responsible for displaying the business form, supporting user navigation, and transmitting data from the field back to the office operations. Business forms are specified on the server. Each customer, across all verticals (trucking, property management, HVAC), runs the very same wireless application but each appears to be running their very own custom app. Just to emphasize the point, when a business wants to change their form, there is no software change. There is no ongoing software management. We create the new form on the server and new work is generated using the new form."

Lehrer pointed to this application model as quite different from most vendors of wireless business applications who approach each business solution as a custom development effort, possibly using a set of in-house application building blocks.

"Because we have created a business forms browser," Lehrer says, "we can deploy our forms for customers quickly and easily and at very low cost ($25/mo per worker). The ROI for the customer is enormous in reduced paperwork and increased timeliness of invoicing and feedback from the field."

JumpStart Wireless adheres to strict J2ME standards and is, therefore, portable to new devices and able to support businesses with a heterogeneous set of devices in the field.

Lehrer pointed out a number of features built into their product that the company considers essential for a business application and which are typically found only in applications targeted for larger devices:

• All data is store and forward. Works in the elevator, the boiler room, or out in Timbuktu.
• Data is self-repairing/self-synchronizing with the server (unexpected power failure and OS crashes are two of the primary reasons the data might become corrupt or unusable). If data becomes corrupt, it is repaired transparently without need for interaction from either the mobile worker or the office staff.
• Consistent UI across all form field types, with bookmarks allowing workers to quickly get back to the form field where they left off.

Code sample
The following code comprises a MIDlet illustrating the implementation and use of a Semaphore. The MIDlet shows the following:

• A time-consuming startup (initialization) and shutdown (finalization) procedure using a thread
• Does not allow initialization to occur during the finalization sequence or visa versa
• Creates a "polling" thread and shuts down the thread from the main application upon exit, but not upon pause.

package com.jumpstart.utils; // Generated package name

/**
 * Basic class to implement a multi-state semaphore. The semaphore can
 * be READY, OPEN, CLOSED, FINISHED. The semaphore can transition from
 * READY to OPEN, from OPEN to CLOSED, from CLOSED, to OPEN, and from
 * CLOSED or OPEN to FINISHED. The Semaphore cannot be restarted once 
 * it is FINISHED.
 *
 * 
 *
 * Given the asynchronous nature of threading it is important when
 * exiting a MIDlet to have a Semaphore that cannot be restarted even
 * if a timer goes before all processing required to exit before the 
 * MIDlet is completed.
 *
 *
 * Created: Fri Feb 22 17:00:00 2002
 *
 * @author <a href="mailto:"></a>
 * @version
 */

public class Semaphore
{
   /** hold the state of the semaphore. Use short's to save RAM */
   private short state;
   
   /** initial state */
   public static final short READY = 0;
   /** permission granted */
   public static final short OPEN = 1;
   /** permission denied */
   public static final short CLOSED = 2;
   /** semaphore can not be restarted, lifecycle over */
   public static final short FINISHED = 3;

   /**
    * Creates a new Semaphore instance in the READY state.
    *
    */
   public Semaphore()
   { 
      state = READY;
   }

   /**
    * Sets the state of the semaphore. Does not allow transitions out of
    * the FINISHED state.
    *
    * @param newState the new state
    */
   public synchronized void setState(short newState) 
   {
      // don't allow transition from the FINISHED state
      if (state != FINISHED) {
         state = newState;
         // notify all threads waiting on state changes for this semaphore
         notifyAll(); 
      } 
   }

   /**
    * Wait for the semaphore to be opened.  Returns immediately if the
    * semaphore is already open.  Returns true if the semaphore
    * successfully transitions to an open state before transitioning 
    * to a FINISHED state. Returns false if the semaphore transitions 
    * to a FINISHED state.
    *
    * @return true if successful transition to OPEN state, false if FINISHED.
    */
   public synchronized boolean waitForOpen()
   {
      // loop over any InterruptedException rechecking the state exiting only if
      // the semaphore is actually OPEN or if it is FINISHED.
      while (state != OPEN && state != FINISHED) {
         try {
            wait();
         } catch (InterruptedException e) {
            // state change occurred
         } 
      }
      return state == OPEN;
   }

   public synchronized boolean isOpen() {
      return state == OPEN;
   }

} //Semaphore

In conclusion
Lehrer believes that the new MIDP 2.0's features will make mobile development much easier than the looser features found in MIDP 1.0. In addition, with mobile manufacturers embracing J2ME, the ability to get specs to deploy across several different devices should become easier, too.

Resources

• Get more information about JumpStart Wireless.
  
  
• A working example of how to access and run Web apps from a mobile device. (developerWorks, September 2003)
  
  
• Also helpful to you may be this recent tutorial (developerWorks, June 2003) on how implement Push technology with J2ME and MIDP.
  
  

About the author John Papageorge has worked with some of the bigger names in the high-tech industry, launching products and Web initiatives for such companies as CNet, Macromedia, NBCi, Sun Microsystems, and MSNBC. John launched the groundbreaking CNet/Intel project Mediadome in 1996 and Macromedia's Shockwave.com in 1998. He also created NBCi's Media Sharehouse in 1999. John has worked as a consultant to forecast and explore the applications of Java technology for Sun Microsystems/Netscape's iPlanet site. John is currently working on his latest venture, Buzzphone, to create compelling voice-based fan club programs for pop music, sports film, NASCAR, and celebrity chefs. This patent-pending initiative has allowed Buzzphone to create relationships with some of the world's hottest talent. He can be reached at http://www-106.ibm.com/developerworks/java/library/john@mediaoverdrive.com.

What do you think of this document? Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1) Comments?

developerWorks > Wireless