ICEmobile is best-in-class mobile application development framework for enterprise JSF developers. ICEmobile-Faces provides a JSF-based development environment for building hybrid mobile enterprise applications.
Key features of ICEmobile mobile app framework include:
1) Provide web-based user interfaces that match the look and feel of native applications.
2) Automatically adapt to different mobile platforms including iOS, Android, & Blackberry.
3) Leverage HTML5/CSS3 capabilities of mobile browsers wherever possible.
4) Provide access to native device capabilities not currently available in HTML5.
5) Minimize client resource and bandwidth requirements.
6) Produce enterprise-strength deployments that conform to Java Enterprise standards.
7) Leverage existing enterprise Java development techniques, tools, and developer skills.
Ride the Storm: Navigating Through Unstable Periods / Katerina Rudko (Belka G...
ICEmobile - Enabling Enterprise Mobility for JSF
1. ICEmobile
ENABLING ENTERPRISE MOBILITY WITH JSF
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.
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322
2. 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.
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322
3. 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"/>
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322
4. 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.
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322
5. 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 When the camera button is After the photo is taken and The upload button uploads the
upload button are rendered in the pressed, the native camera saved, a thumbnail of the image captured image to the server,
web page. control is activated. is displayed. 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.
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322
6. 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.
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322
7. 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.
USA & Canada: 1 877 263 3822 (Toll Free)
Europe: +41 31 329 09 00
w ww .ICE so ft .org Other: +1 403 663 3322