Mobile Communication and Control Flow

   

Now that you have seen the basics of MIDP programming, let us consider the communication between a MIDP program and a JavaServer Faces application. What data needs to be transferred, and how should the data be formatted?

Let's start at the beginning. The midlet requests a page from the JSF application. Had the request come from a browser, the result would be a page description in HTML. However, a midlet doesn't render HTML. It renders a set of predefined forms and canvases. Thus, the JSF application should tell the midlet

  • which form to display next

  • how to populate the form items (text fields, choice groups, etc.)

If the next displayable is a canvas, the midlet needs information that is customized for the canvas (such as the seating pattern and the set of available seats for a seating chart).

How should that information be formatted? There are a number of choices.

  • An XML document

  • A serialized Java object

  • An ad hoc format

Unfortunately, the current version of MIDP does not include an XML parser. Lightweight XML parsers that you can bundle with your application are available. A popular choice is the kXML parser, available at http://kxml.org. However, parsers with a small footprint tend to have painful APIs, lacking amenities such as XPath. And XML files tend to be verbose, with higher transmission costs than strictly necessary. Many MIDP developers shy away from XML for these reasons.

Communication through Java serialization certainly avoids all parsing overhead since the Java library already knows how to do the parsing. However, the CLDC technology, which underlies MIDP on cell phones, does not currently support serialization. It would also take quite a bit of effort to produce JSF renderers for this purpose.

In our sample application, we use an ad hoc format. We simply send a set of URL encoded name/value pairs, such as

 

 form=login user=John+Q%2e+Public password= 

This format is easily achieved with custom JSF components whose renderers produce the name/value pairs.

For instance, the preceding example is the output of the JSF page

 

 <j2me:form >   <j2me:input  value="#{user.name}"/>   <j2me:input  value="#{user.password}"/> </j2me:form> 

The indentation in the JSF page produces additional white space that the client must ignore.

Note that the j2me:form and j2me:input components are not a part of any standard. Later in this chapter we show you how to implement them.

NOTE

graphics/note_icon.gif

You may wonder why we don't simply use the time-honored Properties format to encode name/value pairs. The reason is that the MIDP library does not include the Properties class, so we would have to produce our own decoder. Moreover, the Properties format doesn't escape trailing spaces.


Conversely, the MIDP application needs to send user input to the web application. The easiest method is a simple HTTP POST of URL-encoded form data. A JSF application is prepared to process POST data and to present the request parameters to the various component decoders.

For example, if the user fills in a login screen, the client simply posts data such as

 

 form=login&uname=John+Q%2e+Public&password=secret 

You may wonder why you should bother with JSF when the entire presentation logic appears to be located in the client. Perhaps the client should communicate directly with the server-side business logic, using a protocol such as RMI or SOAP?

Actually, as you will see in our sample application, JSF adds a lot of value. JSF has a well-developed model for the binding between presentation and business logic. It is better to reuse this model than to try to reinvent it. Moreover, many navigation decisions are best handled on the server. For example, if a customer places an order and an item is out of stock, the server is best equipped to determine the impact on navigation. JSF has a good navigation model, so why not take advantage of it?

Of course, some of the presentation logic is best handled by the client. Simple validation and navigation between data entry screens need not involve the server at all. This is not a problem. The midlet can gather user data, using as many screens and validation steps as necessary, and then post all data to the server in one step.

In summary, here are the main points to keep in mind when you are developing a MIDP application with JSF.

  • The midlet draws predefined screens rather than rendering arbitrary markup.

  • As with HTML rendering, the JSF components are proxies for the client-side components.

  • The controller is split between the midlet and the JSF application. Fine-grained navigation and validation decisions are handled by the midlet, and all other presentation logic is handled by the JSF application in the usual way.



core JavaServer Faces
Core JavaServer Faces
ISBN: 0131463055
EAN: 2147483647
Year: 2003
Pages: 121

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net