From MemberWiki

This page is where we are constructing the Mobile Ajax whitepaper. Please make contributions in the appropriate place within the document structure. Please leave the bullet lists in place as reminders of the scope of each section. Add subsections to hold new content or add contributions to existing subsections where they already exist. Proposed Title: An Introduction to Mobile Ajax 1.0: Top 10 Tips for Developers. - by the OpenAjax Alliance.

Contents 1 Introduction 2 Characterizing Mobile Ajax Support Today 3 Challenges and Opportunities for Developers 4 Good Practice for Developers 5 Future

Introduction

• Like Peanut Butter and Jelly, Asynchronous JavaScript and the Extensible Markup Language (XML) have come together to form the unique web-application experience known as Ajax. The Ajax design pattern has revolutionized the desktop web experience with its responsive, light weight applications.

With the rapidly increasing processor power and decreasing costs of mobile computing, user expectations of the mobile web are on the rise. End users demand quick and easy access to information anytime, anywhere and from any device. Ajax is the right technology at the right time. This whitepaper highlights key issues associated with delivering Ajax-based solutions to mobile devices, drawing upon the experiences and current initiatives of the OpenAjax Alliance membership. This document is the result of a collaborative effort by the OpenAjax Alliance membership.

Characterizing Mobile Ajax Support Today

• Underlying browser support continues to improve
• Applications are beginning to appear.
  The example(s) here will have to be edited to avoid looking like commercial advertisements. The whitepaper needs to be as neutral as possible.
  • Mobile Ajax applications are beginning to appear in several places. JON: As much as I would like to promote successful usage of SVG on mobile devices, we can't use this example because SVG != Ajax. We have a clear definition of Ajax in our first white paper at [1] which says "Ajax is a design approach and a set of techniques for delivering ... in popular HTML browsers...Ajax builds on open standards that are widely available as native features (i.e., without plugins) in popular browsers." When an example uses a standalone SVG engine, then that is SVG, not Ajax as we have defined it. (Note: when SVG is a native feature in browser engines, then SVG is part of Ajax because it is a native browser feature.) Therefore, we need a different example. One substitute example could be the ICEsoft application that Steve has demonstrated at recent conferences or we could look at what Google is doing on the iPhone. A good example of a live mobile application based on the Ajax paradigm is the "Bundesliga player" available in Vodafone networks in Germany. It is a service bringing lots of football information to the users of non-3G phones as a complement to Vodafone’s "Vodafone live Football Flatrate" service which offers live viewing of all Bundesliga matches to UMTS phones.
    The Football Package application is a portal to the latest news about the Bundesliga, the German soccer league and is targeting soccer fans, who can get online information about games and results. By including advanced support for multimedia the portal allows the user to view videos, highlights and replays from games. The user can select which information to view and is always up to date with what is going on.
    Key to success for such a service is user experience; fast response to user actions and smooth updates of information. In addition, in order to attract the users the application must have a look and feel that appeals to the general user audience as well of course having the relevant and fresh information. As with all mobile services, processing power of the device and network bandwidth are limited resources. This makes the application suitable for the Ajax paradigm, which, for example, allows videos to play smoothly in one part of the screen while other areas are updated.
    Due to the lack of a preinstalled common Ajax platform on the targeted devices, an Ajax platform was supplied together with the application. To enable rich graphical features and multimedia support and yet have a mobile profile on the platform, SVG Tiny 1.2 was selected as the base language. SVG Tiny 1.2 is an open standard XML language for advanced vector graphic features and multimedia support, defined by W3C and contains a DOM interface with bindings to ECMA script. SVG is suitable for graphically rich applications with multimedia components. The DOM integration also makes it work well for Ajax applications.
    The application itself is build up of one main page, which contains most of the references to the graphics and logic to be used during the full execution of the application. At the start of the application the main page and its DOM is loaded and during the remaining execution of the application modifications are made to the DOM according to user actions and preprogrammed changes. In effect this means that only one full page will be loaded during the entire execution of the application.
    Data used to update the display is fetched from the server using the XMLHttpRequest interface and by updating URIs to images and multimedia objects. From a user perspective this means that the screen will never be blank due to the loading of an entire page. Changing one graphic object to another is either instant, if the object is already loaded, or takes place as soon as the new object has been fetched over the network.
    The resulting service can not be distinguished from a native application in terms of user experience. The responsiveness is for most functions as good as on a native application and graphics both runs and is updated smoothly.
    The current lack of interoperable deployed mobile Ajax platforms limits the reach of this service to devices with open operating systems, since the platform itself has to be downloaded. The application is a nice example of how Ajax can overcome the latency problem in mobile applications and help to bring interesting live services to the mobile and offer a rich user experience.
• It is possible to do useful things
  • Despite the lack of complete implementations of major toolkits JON: I'm not sure what this sentence is trying to say. Major Ajax toolkits have been complete for quite a while now with an amazing set of features. Perhaps what this comment is trying to say is that the major toolkits do not have robust support yet for devices that support mobile Ajax, but even that is a questionnable statement since devices like the iPhone support desktop Ajax.
• Applications less complete than on desktops
• Widgets are beginning to appear
• Need to try and avoid the fragmentation that has bedeviled J2ME, for example
• Lack of standardization (yet) for device APIs. Windows mobile, Java, Symbian etc. provide different interfaces. Still security issues about their use.

Challenges and Opportunities for Developers

• Note that presentations from the Mobile Ajax Workshop listed additional challenges. We should add them to this section
• Unique Opportunities for developers
  Mobile devices provide new and interesting forms of interaction, and access to information previously unavailable. This presents many unique opportunities for developers to create novel applications.
  • Location
    It is possible in some cases to identify the location of a desktop user of the Web, with an accuracy approaching the typical city. However, inaccuracies as big as continents can also occur. In contrast, the mobile device is capable of identifying its location to within an accuracy of a room or car, including altitude. This is made possible by signal triangulation, or through Global Positioning Satellites. Assuming the application developer has access (and permission), this information can be used to inform the behavior of the application.
  • Camera
    Many mobile devices are equipped with digital cameras, and being mobile means they have more opportunity to take photographs of something interesting (unlike the desktop, which doesn't usually have a camera and even if it did, one would probably not find much use for it). Social networking that incorporates images is a growing phenomenon, and is being supported by custom applications. Many other mobile applications using the camera are possible: comparison shopping, barcode reading, emergency communication, medical services, gaming and other entertainment etc.
  • Messaging
    Mobile devices are generally used in an asynchronous fashion. Presence, is increasingly a significant part of this technology, providing the means to control messages. Maintaining the end user state (busy, available, un-interruptible, call-me etc.) is a key feature of Presence. Mobile applications should interoperate seamlessly in asynchronous environments, permitting interruptions, making use of available Presence information and where possible, taking advantage of the messaging infrastructure.
• Differences in UI capabilities
  In contrast to much of the desktop PC world, mobile Web-enabled devices exhibit considerable diversity in levels and types of capabilities. Size and portability constraints often mean that the capabilities are inferior to desktops, but there are also opportunities resulting from their mobile nature that given them superior capabilities. Ajax technologies need to be adaptable for these differences, gracefully degrading in the presence of limited capabilities and also making use of the opportunities presented by enhanced capabilities.
  • Smaller displays
    The most obvious difference in capability is the limited display area. This is often exhibited as a limit in the pixel resolution. However, the display may have a high resolution, perhaps even comparable to desktop computers, but physically the screen will remain relatively small. Space on such displays should therefore be used sparingly. Icons, graphic delimiters and other chrome effects consume a disproportionately large amount of space, even if their intention is to compress the display usage. For example, a +/- icon is often used to toggle the visibility of a section of content, but many of these icons on a display will themselves waste precious space. In general, scripted features should avoid creating too many visual artefacts when dealing with small screens.
  • Often very poor for text display
    The small physical size of the screen can present difficulty for end users, so regardless of the screen resolution, there is a limit to the amount of text that can be displayed. The range of fonts supported on a mobile device is also often significantly less than that of a typical desktop environment.
  • Different input capabilities
    The typical desktop input mechanisms are a full-sized keyboard and a mouse. Mobile devices often do not have the luxury of full keyboards and therefore make use of multi-tap, soft-keys or other innovative approaches. Pointing devices are equally complex. A mouse would be an unusual rarity for mobile devices, but there are plenty that have a stylus, or a four-way scroller, a wheel, or simply a tabbing button to move from "hot" zone to "hot" zone in the display. User interaction should not assume the presence of typical desktop input mechanisms. For example, in the absence of a keyboard the UI should avoid asking the user to enter text.
  • Poor pointing capabilities
    Perhaps this can be wrapped into the Different input capabilities topic above?
• Lower speed networks
• Constraints of resources in the device
  • Issue of battery use vs. XHR use
    • Data transmission consumes power
      Transmission of data via a mobile network is a significant drain on the available power of the device. This includes maintaining an open connection even if very little data is transmitted. When the only source of power is an electric storage battery, it must be treated as a finite and short-term resource. Consequently, mobile use of XmlHttpRequest (XHR) needs to be balanced against the power consumption this implies. Polling is a design methodology that is best avoided as it consumes the finite power resource while seldom doing anything more than maintaining the status quo. Event-driven mechanisms should be employed instead.
    • XML processing consumes power
      Another issue is the fact that the use of XHR generally implies a lot of XML manipulation, which can be processor intensive and consequently a further drain on power. Where possible, applications should be designed to offload as much of this processing to the server as possible.JON: I don't think we should pick on XML in particular. First off, large parts of the Ajax world don't use XML for data and instead use JSON or other format. Second, the Ajax toolkit community tells us that DOM operations are more CPU bound than JavaScript operations. Third, it is possible that redrawing the bits on the display might drain the power more than any calculation logic that precedes that. So, perhaps talk in general about client-side logic draining the battery, but let's not single out XML.
• Having also to support devices that are not Ajax capable
  Suggest this be wrapped into the paragraph on device independence, as it's a case of providing thematic consistency despite the absence of Ajax support JON: I would reword this. Lots of sites are going to decide that they just won't support mobile devices until those devices support desktop-capable web browsers. So, lots of people don't have to support devices that are not Ajax capable.
• Security
• Relationship to:
  • Mobile Web development
    The challenges faced by the developers of mobile Ajax solutions are similar to those identified by the developers of mobile Web content. These are mainly characterized as limitations (screen size, support for certain data formats, processor capability etc.) and domain-specific features (GPS location, voice call initiation, push messaging etc.). Many of the challenges were identified in the W3C MWI BPWG's scoping document.
  • Device Independence
    A particularly challenging issue is device independence, by which is meant the ability for an Ajax application to operation in a thematically consistent manner across a wide range of diverse platforms. This should be visible to end users as a graceful improvement/degradation in service across a range of devices with more/less capabilities. For example, on simple devices an application may signal a user alert with the use of a simple tone, while on more powerful devices featuring support for polyphonic sounds, a more expressive alert sound can be employed. This approach applies particularly in the case of varying input mechanism, which offers notable diversity and innovation. An application should be able to make use of a wide variety of input mechanisms, including push keys, soft keys, switches, sliders, rockers, wheels, touchpads, touchscreens, accelerometers, voice commands and much more. The W3C Device Independence group (now the UWA) has produced significant documentation on the challenges and solutions to adapting to such diversity on the Web.

Good Practice for Developers

• Dealing with UI differences
  • Be aware of the UI capabilities of different devices
  • Avoid making general assumptions about features being present
  • Design in an abstract sense: use late binding to UI features
• Dealing with differences in input capabilities
  • Support more than one input mechanism
  • Don't rely on a single input mechanism
• Supporting devices that are not Ajax-capable
  • Detect that you are dealing with non-Ajax devices
  • Degrade applications gracefully
  • Always have a non-scripted alternative for each feature
  • Use the server for processing when necessary
• Dealing with Security
  • Assume insecurity, unless you can prove security
  • Use secure connections for all security-sensitive communications
  • Don't rely on browser chrome to reflect security status
  • Remember that built-in certificates vary significantly on mobile devices
• Keeping applications small, simple and portable
  • Only deliver what is necessary
  • Avoid designs based on custom device features
• Battery-friendly applications
  • Avoid status polling
  • Store data to avoid repeating expensive loops
  • Use optimal algorithms
  • Avoid eye-candy animations
• Use thrifty methodologies
  • Avoid polling
  • Only download what you know you will need
  • Only store what is essential to store
• Optimizing communications
  • Trim the data to the essentials
  • Avoid overly complex data structures
  • Close unnecessary connections
  • Use XHR sparingly
  • Set caching headers appropriately on Web resources

Future

• Information to developers about likelihoods of which they should be aware and which might affect them in the future (?)
• Capture ideas that came from the Mobile Ajax Workshop
  • e.g. availability of desktop-like features on mobile
• Likely appearance of standard device APIs