The Basic Content Transformation Problem
The first route often chosen to overcome the Mobile Presentation Challenge is called "screen scraping" or transcoding; this requires repurposing and reformatting HTML presentation content. Transcoding involves taking in the dynamic HTML pages, removing the tags (i.e., scraping the page), storing the data in a Meta format, and retagging the content in a different markup language. This can be achieved with a combination of servlets and JSPs. It is not scalable, though, due to the time required. In addition, the tightly interwoven design of the presentation and application logic increases the ongoing maintenance cost exponentially as the number of supported devices rises.
The second route involves first defining an XSL (Extensible Style Sheets) library, which is used to transform the single XML presentation layer into a markup language suitable for each client device. Although this approach has better separation of application logic from presentation logic, the XSL presentation logic becomes so complex that it soon requires its own application logic, written in XSL command sequences. This basic approach of building style sheets for each device becomes costly to maintain and upgrade as new devices become available, since the embedded conditional presentation logic needs reworking each time.
A more effective approach might be to model each device by specifying its features (e.g., display size, supported markup language, etc.), develop a set of style guides for each device feature, and dynamically assemble the style sheets based on the features of the device making the request. Although you would be authoring a significant amount of presentation conversion logic, you may, in this way, be able to avoid some of the maintenance time of updating a style sheet library as new devices become available. XSL, while well-positioned to process text and convert among XML trees, is not a structured programming language. Thus, XSL is not the ideal choice for creating the complex presentation conversion logic required to dynamically assemble style sheets. If this route is chosen, mixing and matching with different programming languages may be required, presenting the familiar burden of ever- increasing complexity and maintenance costs.
After the first step of defining the XSL library, the developer builds a servlet and within it constructs a string buffer of the XML or a DOM (Document Object Model) for the presentation. The developer must then pass the string buffer or DOM and the appropriate style sheet (which may or may not be dynamically assembled based on device features) to an XSLT (XSL Transformer), which then passes the device-specific markup language in the servlet request. This development is typically intricate enough that in most implementations there is a significant amount of integration and coding that must occur within the servlet. For example, you would be required to identify the appropriate device, identify the relevant features, and assemble the style sheet based on these features. A more elegant approach simply uses JSP to lay down the XML and automatically call the right tranform, so that you focus more on building the application and less on building and tweaking the presentation look and feel.
Although challenging on its own, as seen in the two route choices above, basic mobile presentation is only the beginning of a long, circuitous journey as far as mobile application challenges are concerned. Unfortunately, neither approach has the capability to solve the more perplexing problems that one may face ahead.
|
