Introduction
The Mobile applications marketplace is changing the face of
the software development industry. All major mobile operating system manufacturers
pitch their systems to developers trying to get them into their programming
camps and thus stake the territory to guarantee future growth. The major
players with their respective systems are:
- Apple (iOS)
- Google (Android)
- RIM (Blackberry/Playbook)
- Microsoft (Windows Phone)
Each operating system is rather unique; it has requirements
for specific programming language(s) and offers a multitude of SDKs, APIs and
various value-added services. The programming languages supported by these
operating environments are:
- iOS –
Objective-C
- Android –
Java
- Blackberry/Playbook
– Java/ActionScript
- Windows Phone
– C#/VB.NET (or any other language compilable to CLR)
The
diversity can quickly grow into a nightmare when you set the goal of developing
an application to be accessible on all devices, regardless of the operating
system they run. The idea of rewriting your app in three or four different
languages is not attractive and Java’s promise from the 1990s of
“develop once run everywhere” is
as timely as ever. One
could argue that Java is a great materialization of such a vision. Indeed, it
is, but not on the client-side. Will things turn out to be different on mobile
devices?
Adobe is on the mission to prove it to all of us. Please welcome
Adobe Flash Builder 4.5, an Eclipse-based IDE, enabling, among many other
things, single-source development of mobile applications targeting Android,
Blackberry Playbook and iOS devices.
Article Overview
This article provides an overview of the new technology from
Adobe. It focuses on the aspect of applying Flash Builder for rapid
cross-platform development and enabling mobile application developers to get to
market faster. It pays particular attention to the subjects of client-server
integration between mobile applications developed with Flash Builder and Java, .NET
and PHP server-side environments.
As it was mentioned earlier, Flash Builder is an
Eclipse-based IDE. Most available Eclipse extensions such as source control
plugins and debugging tools are available and directly applicable to mobile
development. The development model is based on the ActionScript language with
the MXML markup used to express the layout of the user-interface and custom
components.
Benefits and Shortfalls
One of the greatest benefits of the new Flash Builder 4.5 release
is the possibility of developing an application once and finding that it looks
the same on all major mobile devices. Flash Builder has predefined target platform
settings, so developers can easily select a target platform for the build. Even
though the same application can be deployed to different mobile environments,
it is important to be aware of the differences between the platforms and
devices. For example, even within the same target environment, for instance
Android, Motorola Droid 2 and Google Nexus will have different display
specifications. As a result, either the application needs to be aware of the
differences in how it is rendered, or different application “profiles” should
be created for the targeted device/platform.
Another very significant benefit is the integrated WYSIWYG
UI editor, which significantly simplifies the process of designing and laying
out the user interfaces. This is guaranteed to be a major time saver for cross-platform
mobile development, due to the reduced development effort.
When weighing in the benefits of Flash Builder, it would be
important to be aware of the limitations. Although AIR SDK supports a number of
native UI components, major native Android and iOS components and services are
not available yet and, as a result, the AIR platform might be appear to be awkward
when it comes to incorporating critically important native UI components. As a
workaround, the AIR SDK supports custom UI components, so it should be possible
to mimic the missing elements.
In addition to the UI components, mobile applications rely
on a variety of services provided by the operating system. These typically include
access to camera and microphone, geolocation, Bluetooth, notification service,
in-app payment, etc. Unfortunately, not all core APIs and services are supported
in AIR. In some cases, developers will have only one way to achieve their goal
and that is to develop a native application that runs on a particular mobile
platform (or reinvent the wheel as many times as the number of platforms they
want to support). In other cases, with a competent risk assessment, one should
be able to determine if adopting a non-native, cross-platform approach is a
better way to go.
Client - Server Integration
Unless your goal is to build yet another flatulence app,
odds are your application will require client-server integration. Fortunately,
mobile AIR offers a variety of choices. The client-side provides APIs and support
for:
- SOAP web services
- Plain HTTP GET/POST requests and responses
- Socket-based connections
- Binary (over HTTP) remote procedure calls (AMF)
- Implementation of real-time protocol for data messaging and media
streaming (RTMP).
Complexity, performance and the cost of integration using
these approaches vary significantly. Typically, binary communication mechanisms
(AMF/RTMP) will result in greater performance and tighter integration by
providing better cross-language bindings and object-oriented data flow between
client and server environments.
Any client-server integration requires both the client and
the server to offer integration capabilities. From the server-side perspective,
it can be as basic as staging a web server to serve the HTTP requests or
deploying a web services stack to host the services. Other integration
technologies may require some additional pieces of software enabling the
integration. Most backend environments support the integration technologies
included into AIR either natively or through the third party tools. The table
below illustrates the integration compatibility matrix:
The first three options are better known and understood by
developers. The AMF and RTMP options might be new to those who are not familiar
with Flash/Flex. The AMF protocol and the supporting APIs conceptually are very
similar to SOAP Web Services. The major difference is in on-the-wire
representation of the remote procedure call (RPC) data. An AIR client running
on a mobile device can easily invoke remote methods and receive results at the
object level. All complexity of object serialization and deserialization is
hidden from the developer. The RTMP protocol is better suited for data
messaging scenarios, specifically applications requiring publish/subscribe
functionality. Additionally, the protocol enables video/audio streaming from
devices for subsequent broadcast as well as recording of the media streams on
the server-side. As the table above shows, both AMF and RTMP approaches require
third party solutions on the server-side. Fortunately, there are plenty of
choices to choose from. The table below illustrates available options:
A quick summary of the products listed above:
- FluorineFX – free, open source
- WebORB for .NET – free (Community Edition), commercial license
(Enterprise Edition)
- WebORB for Java - free (Community Edition), commercial license
(Enterprise Edition)
- WebORB for PHP – free, open source
- Adobe BlazeDS – free, open source
- Adobe LCDS – commercial license required
- ZendAMF – free, open source
- AMFPHP – free, open source
- Red5 – free, open source
- Wowza Media Server – commercial license required
The number of options for all major server-side environments
provides a good choice for a variety of different business scenarios. This
article does not go into the analysis for selecting the right tool for the
server-side as it focuses on the value of Flex for the mobile platforms as it
relates to the server-side developers.
One of the greatest advantages of using the Flex/AIR SDK for
building mobile applications is the uniformity and universality of the
client-side API. In fact, the same API enables client-server integration
between all supported mobile operating systems and a variety of the server-side
environments. The APIs available out of the box include support for the
following use-cases:
- Remote method invocation – this can be achieved with at least
three different approaches: using the
HttpService,
WebService or RemoteObject classes - Publish/Subscribe messaging using the Producer/Consumer
classes.
- Video broadcasting from the device’s camera using the
NetConnection/NetStream and the Camera
classes. - Recording video from the device’s camera on the server using the
same classes as in the “video broadcasting” use-case.
- Using Remote Shared Objects for data exchange between
concurrently connected clients using the
SharedObject
API.
Specific examples of applying these APIs will be covered in
a future article. However, the main point is to demonstrate that Flex/AIR can
be a viable alternative for many “single-source” mobile development strategies.
