USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322 w ww .ICE so ft .org

JSF is not new to the mobile landscape. As early as 2007, the ICEfaces framework was being used to deliver JSF-based applications to mobile devices. Advanced browser capabilities on devices like the iPhone, coupled with advanced Ajax-based frameworks like ICEfaces, enabled JSF developers to adapt desktop-targeted Rich Internet Application (RIA's) to mobile devices in an effective manner. So what has changed in the last five years that out-dates these early techniques, and what modern approaches can be applied to deliver a true native user experience to today's wide spectrum of smart phones and other mobile devices? A brief review of the recent and astounding history of smartphones will shed some light on this question and its answer. Smart Phone Explosion The first Apple iPhone was launched in 2007, and was pretty much in a class of it's own, bringing support for full-featured web browsing capabilities. Google Android phones were a year away from first availability, and while Blackberry was the dominant device of the time, its browser was sadly lacking any support for Ajax, making RIA's impossible to support. So the iPhone's mobile Safari browser, and a handful of devices running the Opera Mobile browser were really the only devices capable of supporting RIAs. By 2008, Android-based devices arrived, and Blackberry introduced a next-generation browser capable of supporting Ajax, so the number of devices that could support RIAs began to grow rapidly, but an opposing force was at work too. In early 2008, Apple released the iOS SDK, enabling developers to build native applications for the iPhone, and followed that up later in the year with the launch of the App Store, instantly creating a marketplace for iPhone applications. The Android Market was launched later that same year, as RIM struggled to keep pace, opening the Blackberry App World in 2009. The explosion of native applications compounded the explosion of smart mobile devices, and user expectations for the mobile experience were profoundly altered. Even though mobile web browsers now provided the necessary support, could RIA's compete with predominant native application features? Not without some technological advancements they couldn't. The Enterprise Dilemma The increased use of mobile devices in the workplace was inevitable, as devices and applications proliferated. User expectations for native features are undeniable, but native mobile application development in the enterprise is fraught with peril. The need for cross-platform support drastically increases development costs, and entirely new development skills are required. Haunting the whole native approach are the ghosts of the desktop application era, and its accompanying IT nightmares, which ultimately lead to the advent of Enterprise Java technologies and applications. The predominance of web-based applications in the Enterprise stands in stark contrast to the predominance of native mobile applications in the consumer space. The ideal solution for Enterprises is to maintain the web-based application model, while meeting user expectations for native mobile look and feel, which is now entirely possible with ICEmobile. A Web-based Architecture for Mobile The primary motivation for the ICEmobile architecture is to enable Java Enterprise developers to build web applications that provide native look, feel and capabilities of the mobile devices they are accessed from. Key requirements that the architecture satisfies include:

Provide web-based user interfaces that match the look and feel of native mobile applications Automatically and seamless adapt to different mobile platforms including iOS, Android, and Blackberry Leverage HTML5/CSS3 capabilities of mobile browsers wherever possible Provide access to native device capabilities not currently available in HTML5 Minimize client resource and bandwidth requirements Produce enterprise-strength deployments that conform to Java Enterprise standards Leverage existing enterprise Java development techniques, tools, and developer skills.

ICEmobile ENABLING ENTERPRISE MOBILITY WITH JSF

w ww .ICE so ft .org

USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322

The high-level architecture for ICEmobile, Faces Edition, is illustrated below:

Major elements of the architecture include:

JSF 2: Provides the standards-based foundation. ICEfaces 3: Extends JSF in key ways that improve developer efficiency, including Direct-to-DOM Rendering, Automatic Ajax,

and Ajax Push. ICEfaces is a server-centric architecture that reduces client resource requirements, making it mobile friendly. ICEpush: Provides the underpinnings for Ajax Push and Cloud Push ICEmobile Components: Provides the mobile UI controls, device detection, and cross-platform styling to build UIs that

seamlessly adapt to different mobile devices. Devices Containers: Provide native integration to mobile platform capabilities not available through HTML5 and

device-specific browser implementations.

We will now examine the major features provided by this architecture, and describe how they satisfy the requirements established for it. Native Look and Feel The most demanding requirement for ICEmobile is to deliver a user experience that matches native mobile applications, and does so in a way that adapts seamlessly to various device platforms that the application is accessed from. The mobile WebKit browser provides the basic features required to support this, and the ICEmobile Component Suite provides all the controls, styling, and device detection.

Device Detection ICEmobile device detection is based on the browser's user agent. The ICEmobile components use this agent to optimize their look and feel for the device. Device detection not only influences the style of user controls, but in some cases the functionality of these controls. Automated device detection frees the developer from platform-specific concerns, and fosters "Write Once" application development.

Device-specific Styling Device-specific styling is based on the device detected, and tailors the CSS delivered with the page to match the device. Device-specific themes are loaded with the mobi:deviceStylesheet component as follows: <html.....xmlns:mobi="http://www.icesoft.com/icefaces/mobile/component"> <h:head> <mobi:deviceStylesheet/> </h:head>

and produce a device-specific style for the same page.

w ww .ICE so ft .org

USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322

Android Theme iOS Theme Blackberry Theme

Of course the stock device-specific CSS files can be modified to produce your own corporate look and feel for each device, or the theme can be fixed across all platforms by specifying a particular CSS file. HTML5 HTML5 offers a broad range of input and media playback controls that bring native device capabilities to web applications via the browser. Unfortunately, at this point in time, HTML5 implementations are incomplete and inconsistent across device types. Different devices and platform vintages all support different subsets of HTML5. Given these current inconsistencies, ICEmobile cannot rely entirely on HTML5 support, but the motivation is to leverage it wherever possible, and work around it where necessary.

Input Controls A wide range of HTML5 input types are supported, resulting in proper keyboard selection, and providing basic validation of user input. For instance input types of "text" and "number" result in the follow keyboard instances.

<mobi:input type="text"/> <mobi:input type="number"/>

In some cases, if an HTML5 input control is available, it will be used, otherwise a suitable substitute will be rendered in the page. For instance the mobi:dateSpinner will render the HTML5 control on iOS5 where it is supported, and an ICEmobile-specific control on other platforms where it is not.

<mobi:input type="text"/> <mobi:input type="number"/>

w ww .ICE so ft .org

USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322

Media Output Controls ICEmobile media components leverage HTML5 controls to provide access to media playback capabilities of the device, as illustrated below. Later in this article we will discuss how media capture is achieved with ICEmobile.

Touch Screen Support ICEmobile components support normal touch screen interactions. The browser itself handles much of this, but wherever necessary, ICEmobile components incorporate touch screen support via JavaScript. The mobi:carousel component is an example of this, supporting horizontal touch screen scrolling of a list of items.

Device Containers - Beyond HTML5 As we have seen, HTML5 holds promise for expanding the native feature set available to web applications, but the specification does not currently address all the native capabilities of smart phones that may be of interest to application developers. Native device containers provide integration with native capabilities not currently supported in HTM5 and mobile browser implementations. Device containers are native applications that are installed on a device, like any other native application. The container provides a web container capable of rendering the web application markup, but provides additional device integration via JavaScript-to-native interfaces that expose specific device capabilities to the web application. The basic architecture of the device container is illustrated below.

w ww .ICE so ft .org

USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322

Key elements of the container architecture include:

Device Container: The native application that is installed on the device. It can be configured and branded to your specific requirements.

Web Container: The web browser view where the web page is rendered to present the user interface. Native JavaScript: The container includes JavaScript that provides JavaScript to native integration APIs to expose device

capabilities. While the JavaScript implementation is platform specific, the public API is consistent across platforms. Native Capability Integration: A native implementation, which is called from the Native JavaScript, and provides access

to a particular device capability. Page Markup: The web page that is rendered to produce the user interface. This markup includes JavaScript that calls the

Native JavaScript, which in turn calls the native integration APIs to provide access to the device capabilities from the web page.

ICEmobile offers device containers for Android, iOS, and Blackberry, making them conveniently available on the respective mobile application stores, as well as providing them in the download bundle, so they can be branded to your own specifications.

Device Integration Components ICEmobile includes JSF components that work in conjunction with the containers to provide simple and portable access to native device capabilities. The basic mechanism works as follows:

1. Include an ICEmobile device integration component in a JSF page. 2. The component rendering in the page includes JavaScript calls to the Native JavaScript. 3. The Native JavaScript triggers a particular device capability. 4. That device capability is activated and produces some artifact (image, video, audio, ...). 5. Control returns to the web page, where the artifact can be handled (typically uploaded to the server).

The following series of screen shots show the process of capturing an image with the camera on an Android phone, and illustrates the use of mobi:camera, and mobi:thumbnail components from the ICEmobile component suite.

The camera, thumbnail, and upload button are rendered in the web page.

When the camera button is pressed, the native camera control is activated.

After the photo is taken and saved, a thumbnail of the image is displayed.

The upload button uploads the captured image to the server, where it is available to the web application and can be displayed in the web page.

Mobile-friendly Markup While component capabilities and styling are paramount to producing a native mobile user experience, it is equally important that the component markup is efficient, minimizing client resource and network bandwidth requirements. The ICEmobile component suite is tailored to deliver the most efficient markup possible. To begin with, component resources are loaded only when required, eliminating the need to download large JavaScript libraries. Additionally, JavaScript and CSS resources can be compressed, and SmartSprites are used for image loading efficiency, making ICEmobile markup completely mobile friendly. These features are additive to the server-centric nature of the ICEfaces framework itself, making ICEmobile "ultra-light" from the mobile client perspective.

w ww .ICE so ft .org

USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322

Mobile Push - A Cloudy Issue Ajax Push is a key feature of ICEfaces, and is necessary when web applications are expected to match native mobile application capabilities. Ajax Push can deliver asynchronous presentation changes to the client UI, as the state of the application changes - a standard capability for native mobile applications. The question is, does Ajax Push fit into the mobile paradigm? The answer is yes, but some upgrades from the standard mechanism are warranted.

Adaptive Heartbeating Ajax Push uses "long polling" or "blocking HTTP" from the client browser to achieve its function. A server-driven heartbeating mechanism is required to keep blocking connections healthy during periods of inactivity, but the tolerance in the heartbeating interval in mobile networks can vary significantly, and short heartbeat intervals can impact power efficiency. ICEmobile solves these problems with an adaptive heartbeating mechanism that continually seeks out the optimal heartbeating interval. The optimal heartbeat uses the longest interval that keeps the connection stable, and it is calculated continually to adapt to changing mobile network conditions. This makes Ajax Push reliable and power-efficient for mobile deployments.

Cloud Push User notification is a standard technique, available in mobile devices, to alert the user to something of importance, even when the user is not actively engaged with the phone, or is presently engaged in some other activity on the phone. Sound bites, vibrations, and status bar symbols are all forms of user notification available to native mobile applications. These notifications can be triggered by a device-resident state change, but are often triggered by a state change in some network-based resource. We refer to this type of notification as a cloud-based notification. All the major platform vendors offer cloud notification infrastructure that can be utilized in a native application, but of course each approach is proprietary.

Apple Push Notification Service Android Cloud To Device Messaging Blackberry Push Service

So how does all this play into the web application domain? First of all, the idea of push in a standard web application was completely foreign until the advent of Ajax Push, but can Ajax Push be adapted to provide cloud notification? As described earlier, the standard Ajax Push mechanism relies on a blocking HTTP connection, but if the web application or the browser itself is idle, there is no way to maintain the necessary connections, and even if you could, for power considerations, you simply wouldn't want to. Now if the Ajax Push mechanism could detect the idle condition, and it had the right cloud notification credentials for the idle client, it could use an alternate transport to deliver the notification. But that is not quite enough, as you still need client-side support to receive and process the notifications, so a standard browser is insufficient. ICEmobile provides a comprehensive solution to cloud notification, utilizing an augmented Ajax Push mechanism, and the device containers. Ajax Push is augmented with a Cloud Push mechanism that leverages a connector architecture to integrate with the various device-specific cloud notification mechanisms. The containers provide the device-specific integration to the user notification mechanisms on the client. The complete architecture is illustrated below.

w ww .ICE so ft .org

USA & Canada: 1 877 263 3822 (Toll Free) Europe: +41 31 329 09 00 Other: +1 403 663 3322

The sequence of events culminating in a cloud notification, illustrated above, includes:

1. Cloud credentials are passed from the client container to the Ajax Push/ICEpush mechanism for future use. 2. The Ajax Push mechanism detects when the container goes inactive. 3. Some state change occurs in the application that warrants cloud notification. 4. Ajax Push determines that the client is idle, and pushes over the appropriate cloud connector, using the client credentials. 5. Cloud notification is received at the device container and presented to the user, who can then reactivate the application and

take action.

Connectors are available for Android, iOS, and Blackberry notification mechanisms, and the user notification mechanisms are integrated into the respective device containers. There is also a generic email connector that can send email messages. The email connector can be used without the containers, but the web application must provide appropriate client credentials to the ICEpush bridge. While the supporting infrastructure for cloud push is complex, from the developer's point of view, using cloud push is dead simple. The Ajax Push API is extended with an additional rendering call that supplies a cloud push message to be sent when the client is inactive. Two lines of code is all it takes.

PushMessage myMessage = new PushMessage("myMsgSubject", "myMsgBody"); PushRenderer.render("myGroup", myMessage);

With cloud-based user notification you can communicate critical state changes to your clients, even when they are not actively using the application, or the phone itself.

Enterprise-hardened Mobile Enterprise Java standards are at the heart of the ICEmobile solution, as it leverages JSF and the enterprise-hardened ICEfaces 3.0 core framework. This means your trusted Java EE deployment and security infrastructure can be reused for your mobile applications without compromise. More often than not, enterprises are looking to migrated applications from the desktop to mobile clients, and moving forward with web-based solutions for both results in significant cost savings, versus introducing a whole new set of development technologies required to build and maintain native mobile applications across multiple device types. With ICEmobile, you can use your existing Java EE development tools and expertise to bring uncompromising mobile applications to your enterprise today.