|  | ICEmobile - Enabling Enterprise Mobility with JSF
by Stephen Maryka
16 May 2012 03:00 EDT |
Stephen Maryka, Chief Technical Officer at ICEsoft Technologies Inc., provides an overview of ICEmobile, which enables Java Enterprise developers to build web applications that provide the native look, feel, and capabilities of the mobile devices from which they are accessed. ICEmobile delivers a user experience that matches native mobile applications, and it does so in a way that adapts seamlessly to the various device platforms.
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.
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 led 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.
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
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 it does so in a
way that adapts seamlessly to various device platforms from which the
application is accessed. 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:>
<h:head>
<mobi:deviceStylesheet/>
</h:head>
and produce a device-specific style for the same page.
|
|
|
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.
|
|
iOS 5
|
Android 2.2
|
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 HTML5 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.
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:
- Include an ICEmobile device integration component in a JSF page.
- The component rendering in the page includes JavaScript calls to
the Native JavaScript.
- The Native JavaScript triggers a particular device capability.
- That device capability is activated and produces some artifact
(image, video, audio, ...).
- 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.
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 Heartbeat
Ajax Push uses "long polling" or "blocking HTTP" from the
client browser to achieve its function. A server-driven
heartbeat mechanism is required to keep blocking connections healthy
during periods of inactivity, but the tolerance in the heartbeat
interval in mobile networks can vary significantly, and short heartbeat
intervals can impact power efficiency. ICEmobile solves these
problems with an adaptive heartbeat mechanism that continually seeks
out the optimal heartbeat 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.
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.
The sequence of events culminating in a cloud notification, illustrated
above, includes:
- Cloud credentials are passed from the client container to the
Ajax Push/ICEpush mechanism for future use.
- The Ajax Push mechanism detects when the container goes inactive.
- Some state change occurs in the application that warrants cloud
notification.
- Ajax Push determines that the client is idle, and pushes over the
appropriate cloud connector, using the client credentials.
- 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 migrate applications from the desktop to mobile clients. 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.
Resources
Stephen Maryka, Chief Technical Officer at ICEsoft Technologies Inc., leads R&D initiatives at ICEsoft. He brought the original ICEfaces project to market, and is now focused on the mobility strategy at ICEsoft. Prior to joining ICEsoft in 2004, Stephen was co-founder of AudeSi Technologies where he served as VP Technology and led Java product development for Internet appliances. After Wind River's acquisition of AudeSi, Stephen served as a Principal Technologist for Wind River, working on embedded Java, device management, and high availability technologies. Stephen has been involved with Java technologies since 1997 when he engaged with Nortel Networks as the chief software architect for the world's first commercial embedded Java telephone. Stephen earned his BSc. in Mathematics and Computer Science from the University of Victoria in 1984. |
|
