Click here to Skip to main content
Click here to Skip to main content

What’s New in Adobe®Flash® Builder™ 4.5 – Implications for PHP, Java, and .NET Developers

, 27 Jun 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
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.

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:

table-1.png

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:

table-2.png

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

mapableuser

United States United States
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.141220.1 | Last Updated 27 Jun 2011
Article Copyright 2011 by mapableuser
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid