To complement the white paper released last week covering the future of Flex and the transition to Apache, Adobe has released a white paper covering the the roadmap for the Flash and AIR runtimes. Flash is very much alive and well, and is continuing to innovate to be able to bring uncompromising rich experiences to the web, desktop, and mobile devices. You can read the white paper online at:
Here is an excerpt, be sure to read the entire white paper for a clear outline of the future of Flash runtimes. The future is going to be awesome.
Summary
For the past decade, Flash Player and, more recently, Adobe AIR have played a vital role on the web by providing consistent platforms for deploying rich, expressive content across browsers, desktops, and devices. Beginning as a platform for enabling animation, the Flash runtimes have evolved into a complete multimedia platform, enabling experiences that were otherwise not possible or feasible on the web.
Looking forward, Adobe believes that Flash is particularly suited for addressing the gaming and premium video markets, and will focus its development efforts in those areas. At the same time, Adobe will make architectural and language changes to the runtimes in order to ensure that the Flash runtimes are well placed to enable the richest experiences on the web and across mobile devices for another decade.
Back in the summer, I was lucky enough to get my hands on some early builds of Stage3D for mobile. I built some simple examples, including basic geometric shapes and simple 3D bubble charts inside of mobile Flex/AIR applications. I have been asked numerous times for the source code, and I’ve finally given in, and am sharing some source code.
I am not posting the full mobile application source code, since Stage3D for mobile is not yet available. However, I have ported the 3D bubble chart example to run in a Flex application targeting the desktop (Flash Player 11). The bubble chart example extends the concepts explored in the basic geometric shapes example.
Before you say “shoot, he didn’t give us the mobile code”, let me explain… When I ported the code from the mobile project to the desktop Flex project, all I changed was code specific to the mobile Flex framework. I changed <s:ViewNavigatorapplication> to <s:Application> and the corresponding architecture changes that were required, and I changed the list item renderers to Spark item renderers based on <s:Group> instead of mobile item renderers. In the mobile item renderers, all my drawing logic was done using the ActionScript drawing API. For simplicity in the port, I just used <s:Rect> to add the colored regions in the desktop variant.
That is all I changed!
The stage3D code between the desktop and mobile implementations is identical. You can see the desktop port in action in the video below:
The source code was intended to be exploratory at best… I was simply experimenting with hardware accelerated content, and how it can be used within your applications. There is one big “gotcha” that you will have to watch out for if you want Stage3D content within a Flex application… Stage3D content shows up behind Flex content on the display list. By default, Flex apps have a background color, and they will hide the Stage3D content. If you want to display any Stage3D content within a Flex application (regardless of web, desktop AIR, or mobile), you must set the background alpha of the Flex application to zero (0). Otherwise you will pull out some hair trying to figure out why it doesn’t show up.
The source code for the web/Flex port of this example is available at:
Do you want to learn more about the future of Flex?
Do you want to learn more about the Flex transition to the Apache Software Foundation?
How can you contribute and help make Flex thrive?
Do you have questions that you would like to voice to Adobe?
As promised, Adobe is kicking off The Flex User Group Tour to discuss recent events surrounding Flex and the Flash Platform. These meetings are intended to help you understand the changes happening with Flex and Flash, the impact to related tools, as well as to educate about the process & transition to Apache. You can learn more about the user group tour and get an up-to-date listing of dates & cities from the Flex Team blog - be sure to check back periodically for updates. Initial cities include New York, Boston, Denver, Seattle, Los Angeles, Sand Diego, and Dallas. Expect more cities & countries to be announced at a later date.
We hope to see you at one of the upcoming events. I’m scheduled to speak at the Dallas event in April, and I hop to see you there!
One growing trend that I have seen in mobile & tablet applications is the creation of tools that enable your workforce to perform their job better. This can be in the case of mobile data retrieval, streamlined sales process with apps for door-to-door sales, mobile business process efficiency, etc…
One of the topics that comes up is how do you capture a signature and store it within your application? This might be for validation that the signer is who they say they are, or for legal/contractual reasons. Imagine a few scenarios:
Your cable TV can’t be installed until you sign the digital form on the installation tech’s tablet device
You agree to purchase a service from a sales person (door to door, or in-store kiosk) – your signature is required to make this legally binding.
Your signature is required to accept an agreement before confidential data is presented to you.
These are just a few random scenarios, I’m sure there are many more. In this post, I will focus on 2 (yes, I said two) cross-platform solutions to handle this task – one built with Adobe Flex & AIR, and one built with HTML5 Canvas & PhoneGap.
Watch the video below to see this in action, then we’ll dig into the code that makes it work.
The basic flow of the application is that you enter an email address, sign the interface, then click the green “check” button to submit to the signature to a ColdFusion server. The server then sends a multi-part email to the email address that you provided, containing text elements as well as the signature that was just captured.
If you’d like to jump straight to specific code portions, use the links below:
Let’s first examine the server component of the sample application. The server side is powered by ColdFusion. There’s just a single CFC that is utilized by both the Flex/AIR and HTML/PhoneGap front-end applications. The CFC exposes a single service that accepts two parameters: the email address, and a base-64 encoded string of the captured image data.
<cffunction name="submitSignature" access="remote" returntype="boolean">
<cfargument name="email" type="string" required="yes">
<cfargument name="signature" type="string" required="yes">
<cfmail SUBJECT ="Signature"
FROM="#noReplyAddress#"
TO="#email#"
username="#emailLoginUsername#"
password="#emailLoginPassword#"
server="#mailServer#"
type="HTML" >
<p>This completes the form transaction for <strong>#email#</strong>.</p>
<p>You may view your signature below:</p>
<p><img src="cid:signature" /></p>
<p>Thank you for your participation.</p>
<cfmailparam
file="signature"
content="#toBinary( signature )#"
contentid="signature"
disposition="inline" />
</cfmail>
<cfreturn true />
</cffunction>
Note: I used base-64 encoded image data so that it can be a single server component for both user interfaces. In Flex/AIR you can also serialize the data as a binary byte array, however binary serialization isn’t quite as easy with HTML/JS… read on to learn more.
The Flex/AIR Solution
The main user interface for the Flex/AIR solution is a simple UI with some form elements. In that UI there is an instance of my SignatureCapture user interface component. This is a basic component that is built on top of UIComponent (the base class for all Flex visual components), which encapsulates all logic for capturing the user signature. The component captures input based on mouse events (single touch events are handled as mouse events in air). The mouse input is then used to manipulate the graphics content of the component using the drawing API. I like to think of the drawing API as a language around the childhood game “connect the dots”. In this case, you are just drawing lines from one point to another.
When the form is submitted, the graphical content is converted to a base-64 encoded string using the Flex ImageSnapshot class/API, before passing it to the server.
You can check out a browser-based Flex version of this in action at http://tricedesigns.com/portfolio/sigCaptureFlex/ – Just enter a valid email address and use your mouse to sign within the signature area. When this is submitted, it will send an email to you containing the signature.
package
{
import flash.display.DisplayObject;
import flash.display.Graphics;
import flash.display.Sprite;
import flash.events.MouseEvent;
import flash.geom.Point;
import mx.core.UIComponent;
import mx.graphics.ImageSnapshot;
import mx.managers.IFocusManagerComponent;
import spark.primitives.Graphic;
public class SignatureCapture extends UIComponent
{
private var captureMask : Sprite;
private var drawSurface : UIComponent;
private var lastMousePosition : Point;
private var backgroundColor : int = 0xEEEEEE;
private var borderColor : int = 0x888888;
private var borderSize : int = 2;
private var cornerRadius :int = 25;
private var strokeColor : int = 0;
private var strokeSize : int = 2;
public function SignatureCapture()
{
lastMousePosition = new Point();
super();
}
override protected function createChildren():void
{
super.createChildren();
captureMask = new Sprite();
drawSurface = new UIComponent();
this.mask = captureMask;
addChild( drawSurface );
addChild( captureMask );
this.addEventListener( MouseEvent.MOUSE_DOWN, onMouseDown );
}
protected function onMouseDown( event : MouseEvent ) : void
{
lastMousePosition = globalToLocal( new Point( stage.mouseX, stage.mouseY ) );
stage.addEventListener( MouseEvent.MOUSE_MOVE, onMouseMove );
stage.addEventListener( MouseEvent.MOUSE_UP, onMouseUp );
}
protected function onMouseMove( event : MouseEvent ) : void
{
updateSegment();
}
protected function onMouseUp( event : MouseEvent ) : void
{
updateSegment();
stage.removeEventListener( MouseEvent.MOUSE_MOVE, onMouseMove );
stage.removeEventListener( MouseEvent.MOUSE_UP, onMouseUp );
}
protected function updateSegment() : void
{
var nextMousePosition : Point = globalToLocal( new Point( stage.mouseX, stage.mouseY ) );
renderSegment( lastMousePosition, nextMousePosition );
lastMousePosition = nextMousePosition;
}
public function clear() : void
{
drawSurface.graphics.clear();
}
override public function toString() : String
{
var snapshot : ImageSnapshot = ImageSnapshot.captureImage( drawSurface );
return ImageSnapshot.encodeImageAsBase64( snapshot );
}
override protected function updateDisplayList(w:Number, h:Number):void
{
super.updateDisplayList(w,h);
drawSurface.width = w;
drawSurface.height = h;
var g : Graphics = this.graphics;
//draw rectangle for mouse hit area
g.clear();
g.lineStyle( borderSize, borderColor, 1, true );
g.beginFill( backgroundColor, 1 );
g.drawRoundRect( 0,0,w,h, cornerRadius, cornerRadius );
//fill mask
g.clear();
g = captureMask.graphics;
g.beginFill( 0, 1 );
g.drawRoundRect( 0,0,w,h, cornerRadius, cornerRadius );
}
protected function renderSegment( from : Point, to : Point ) : void
{
var g : Graphics = drawSurface.graphics;
g.lineStyle( strokeSize, strokeColor, 1 );
g.moveTo( from.x, from.y );
g.lineTo( to.x, to.y );
}
}
}
The HTML5/PhoneGap Solution
The main user interface for the HTML5/PhoneGap solution is also a simple UI with some form elements. In that UI there is a Canvas element that is used to render the signature. I created a SignatureCapture JavaScript class that encapsulates all logic for capturing the user signature. In browsers that support touch events (mobile browsers), this is based on the touchstart, touchmove and touchend events. In browsers that don’t support touch (aka desktop browsers), the signature input is based on mousedown, mousemove and mouseup events. The component captures input based on touch or mouse events, and that input is used to manipulate the graphics content of the Canvas tag instance. The canvas tag also supports a drawing API that is similar to the ActionScript drawing API. To read up on Canvas programmatic drawing basics, check out the tutorials at http://www.adobe.com/devnet/html5/html5-canvas.html
When the form is submitted, the graphical content is converted to a base-64 encoded string using the Canvas’s toDataURL() method. The toDataURL() method returns a base-64 encoded string value of the image content, prefixed with “data:image/png,”. Since I’ll be passing this back to the server, I don’t need this prefix, so it is stripped, then sent to the server for content within the email.
You can check out a browser-based version of this using the HTML5 Canvas in action at http://tricedesigns.com/portfolio/sigCapture/ – Again, just enter a valid email address and use your mouse to sign within the signature area. When this is submitted, it will send an email to you containing the signature. However, this example requires that your browser supports the HTML5 Canvas tag.
You can check out the SignatureCapture code below, or check out the full project at https://github.com/triceam/Mobile-Signature-Capture/tree/master/html%20client. This class will also work in desktop browser applications that support the HTML5 canvas. I used Modernizr to determine whether touch events are supported within the client container (PhoneGap or desktop browser). The main application workflow is within application.js.
Also a note for Android users, the Canvas toDataURL() method does not work in Android versions earlier than 3.0. However, you can implement your own toDataURL() method for use in older OS versions using the technique in this link: http://jimdoescode.blogspot.com/2011/11/trials-and-tribulations-with-html5.html (I did not update this example to support older Android OS versions.)
While working with Kevin’s code, I started tinkering… “what if I change this, what if I tweak that?” Next thing you know, I put together a sample scenario showing subscription-based realtime data streaming to multiple web clients using web sockets. Check out the video below to see it in action.
You are seeing 9 separate browser instances getting realtime push-based updates from a local server using web sockets. When the browser loads, the html-based client makes a web socket connection, then requests all symbols from the server. The server then sends the stock symbol definitions back to the client and displays them within the HTML user interface. From there, the user can click on a stock symbol to subscribe to updates for that particular symbol. DISCLAIMER: All that data is randomly generated!
I put together this example for experimentation, but also to highlight a few technical scenarios for HTML-based applications. Specifically:
Realtime/push data in HTML-based apps
Per-client subscriptions for realtime data
Multi-series realtime data visualization in HTML-based apps
The server is an AIR app started by Kevin, based on the web sockets draft protocol. It is written in JavaScript, and the client is a HTML page to be viewed in the browser.
If you don’t feel like reading the full web sockets protocol reference, you can get a great overview from websocket.org or Wikipedia.
One thing to keep in mind is that web sockets are not widely supported in all browsers yet. There is a great reference matrix for web socket support from caniuse.com:
If you still aren’t sure if your browser supports web sockets, you can also check simply by visiting websocketstest.com/. If you want to test for web socket support within your own applications, you can easily check for support using Modernizr. Note: I didn’t add the Modernizr test in this example… I only tested in Chrome on OSX.
OK, now back to the sample application. All of the source code for this example is available on github at: https://github.com/triceam/Websocket-Streaming-Example. To run it yourself, you first have to launch the server. You can do this on the command line by invoking ADL (part of the AIR SDK):
cd "/Applications/Adobe Flash Builder 4.6/sdks/4.6.0/bin"
./adl ~/Documents/dev/Websocket-Streaming-Example/server/application.xml
You’ll know the server is started b/c an air window will popup (you can ignore this, just don’t close it), and you will start seeing feed updates in the console output.
Once the server is running, open “client/client.html” in your browser. It will connect to the local server, and then request the list of symbols. If you click on a symbol, it will subscribe to that feed. Just click on the symbol name again to unsubscribe. You’ll know the feed is subscribed b/c the symbol will show up in a color (matching the corresponding feed on the chart). Again, let me reiterate that I only tested this in Chrome.
You can open up numerous client instances, and all will receive the same updates in real time for each subscribed stock symbol.
The “meat” of code for the server starts in server/scripts/server/server.js. Basically, the server loads a configuration file for the socket server, then creates a ConnectionManager and DataFeed (both of these are custom JS classes). The ConnectionManager class encapsulates all logic around socket connections. This includes managing the ServerSocket as well as all client socket instances and events. The DataFeed class handles data within the app. First, it generates random data, then sets up an interval to generate random data updates. For every data update, the ConnectionManager instance’s dispatch() method is invoked to send updates to all subscribed clients. Rather than trying to put lots of code snippets inline in this post (which would just be more confusing), check out the full source at: https://github.com/triceam/Websocket-Streaming-Example/tree/master/server
The client code all starts in client.html, with the application logic inside of client/scripts/client.js. Once the client interface loads, it connects to the web socket and adds the appropriate event handlers. Once subscribed to a data feed, realtime data will be returned via the web socket instance, transformed slightly to fit the data visualization structure, then rendered in an HTML canvas using the RGraph data visualization library. RGraph is free to get started with, however if you want to deploy a production app with it, you’ll need a license. You’ll notice that each feed updates independently, based upon the client subscriptions. Note: The data visualization is not temporally aligned… if you want the updates in time-sequence, there is a litte bit more work involved in the client-side data transformation.
This example is intended to get your minds rolling with the concepts; it is not *yet* an all-encompassing enterprise solution. You can expect to see a few more data push scenarios here in the near future, based on different enterprise server technologies.
In case you had not seen on the Flex team blog, twitter or through some other medium, Flex SDK 4.6 and Flash Builder 4.6 were released today! Go get them, if you have not done so already. Flex 4.6 marks a huge advancement for the Flex SDK, especially regarding mobile applications.
Flash Builder 4.6 is a FREE update for Flash Builder 4.5 users. From the Flex team blog:
A lot is included in this update, so much so that we couldn’t deliver it in the Adobe Application Manager. This means Flash Builder 4.5 users won’t automatically be notified about the update and will have to download the full Flash Builder 4.6 installer and enter their Flash Builder 4.5 serial number.
Coinciding with the Flex & Flash Builder releases, new content around Flex and Flash Builder 4.6 have been posted on Adobe TV. There is a bunch of great new content worth checking out, including fellow evangelist Michael Chaize’s adaptive UI for different platforms and device form factors. In addition, here I am speaking out the new Captive Runtime feature introduced in AIR 3…
I’ve finally caught up with some of my to-dos and have uploaded code for several of my recent projects to github. You can see a list of all of my projects at https://github.com/triceam. As I blog, I’ll attempt to maintain a copy of all source code on github. As I get a chance, I’ll try to post some additional samples that I have sitting around. So far, I’ve uploaded the following:
URL Monitor
This includes my URL Monitor application, available for iOS, Android, and BlackBerry, developed using Adobe AIR. The URL Monitor tool is a simple diagnostic application that will allow you to quickly and easily monitor the status of various URL endpoints. Simply enter a URL into the text box and add it to the list. A polling HTTP request will be made every 10 seconds to determine the availability of a given endpoint. HTTP codes 200, 202, 204, 205 and 206 will be identified as a success with a green check. All other HTTP codes will indicate a problem as a red ‘X’.
The Flex Mobile Serialization Testing application is a basic scenario for testing performance between AMF and JSON in a Flex application. The mobile app makes requests of simple data objects from a ColdFusion CFC. In each test iteration, a request is made for 1, 10, 100, 1000, and 10000 value objects, in both AMF and JSON formats. The total round trip time from request to deserialization is measured and compared for each case, for a total of 5 iterations through each cycle. The application displays end-to-end performance metrics for both AMF and JSON requests.
This application was built using Adobe Flex 4.6 and Adobe AIR 3.1
Enterprise Tablet Visualization
The Enterprise Tablet Visualization application is a sample application built using Adobe Flex and AIR. The application is not a production application. It demonstrates realtime data push to a mobile application using LiveCycle Data Services, realtime multimedia collaboration using LiveCycle Collaboration Services, as well as multi-form-factor UI for both tablet and phone devices, including map integration and interactive data visualizations.
Late last week, Adobe released official statements and a FAQ to address the recent confusion around the Flex, the Flash/AIR platforms and mobile. You can read the official statement at:
Here are a few excerpts from the official statement:
Adobe Flash Player on desktop Adobe reaffirmed its commitment to the Adobe Flash Player in desktop browsers, and its role of enabling functionality on the web that is not otherwise possible. Flash Player 11 for PC browsers just introduced dozens of new features, including hardware accelerated 3D graphics for console-quality gaming and premium HD video with content protection.
…
Adobe AIR for mobile Adobe reaffirmed its commitment to Adobe AIR for mobile devices, which allows developers and designers to create standalone applications using Adobe Flash technologies that can be deployed across mobile operating systems, including Apple iOS, Google Android and RIM BlackBerry Tablet OS.
Adobe AIR for desktop Adobe reconfirmed its commitment for its continued support for Adobe AIR applications running on the desktop. Adobe is actively working on the next version of Adobe AIR for the desktop.
…
Adobe Flex Adobe announced its intention to contribute the Adobe Flex SDK open source project to the Apache Software Foundation for future governance.
Last week Adobe announced information about the company’s evolution and future plans of Flex. It was also announced that Adobe Flex would be contributed to an open source software foundation. The result of which, was mass speculation, fear, uncertainty, and doubt. Rest assured, Flash is not dead, nor is Flex.
Yes. Flash Builder will continue to be developed and Adobe will work to ensure Flex developers can use Flash Builder as their development tool with future releases of Flex SDK.
Will Adobe continue to support customers using Flex?
Yes. Adobe will continue to honor existing Flex support contracts.
What specifically is Adobe proposing?
We are preparing two proposals for incubating Flex SDK and BlazeDS at the Apache Software Foundation.
In addition to contributing the core Flex SDK (including automation and advanced data visualization components), Adobe also plans to donate the following:
Complete, but yet-to-be-released, Spark components, including ViewStack, Accordion, DateField, DateChooser and an enhanced DataGrid.
BlazeDS, the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex applications.
Falcon, the next-generation MXML and ActionScript compiler that is currently under development (this will be contributed when complete in 2012)
Falcon JS, an experimental cross-compiler from MXML and ActionScript to HTML and JavaScript.
Flex testing tools, as used previously by Adobe, so as to ensure successful continued development of Flex with high quality
Isn’t Adobe just abandoning Flex SDK and putting it out to Apache to die?
Absolutely not – we are incredibly proud of what we’ve achieved with Flex and know that it will continue to provide significant value for many years to come. We expect active and on-going contributions from the Apache community. To be clear, Adobe plans on steadily contributing to the projects and we are working with the Flex community to make them contributors as well.
Flex has been open source since the release of Flex 3 SDK. What’s so different about what you are announcing now?
Since Flex 3, customers have primarily used the Flex source code to debug underlying issues in the Flex framework, rather than to actively develop new features or fix bugs and contribute them back to the SDK.
With Friday’s announcement, Adobe will no longer be the owner of the ongoing roadmap. Instead, the project will be in Apache and governed according to its well-established community rules.In this model, Apache community members will provide project leadership. We expect project management to include both Adobe engineers as well as key community leaders. Together, they will jointly operate in a meritocracy to define new features and enhancements for future versions of the Flex SDK. The Apache model has proven to foster a vibrant community, drive development forward, and allow for continuous commits from active developers.
What guarantees can Adobe make in relation to Flex applications continuing to run on Flash Player and Adobe AIR?
Adobe will continue to support applications built with Flex, as well as all future versions of the SDK running in PC browsers with Adobe Flash Player and as mobile apps with Adobe AIR indefinitely on Apple iOS, Google Android and RIM BlackBerry Tablet OS.
We are continuing to develop Adobe AIR for both the desktop and mobile devices. Indeed, we have seen wide adoption of Adobe AIR for creating mobile applications and there have been a number of blockbuster mobile applications created using Adobe AIR.
Flash Player for Desktop Browsers
We feel that Flash continues to play a vital role of enabling features and functionality on the web that are not otherwise possible. As such, we have a long term commitment to the Flash Player on desktops, and are actively working on the next Flash Player version.
Recently, I’ve been asked more than once which is better: AMF or JSON for AIR mobile applications. This post is to highlight some performance comparisons, and a sample testing application that I put together. First, it is important to know what both AMF and JSON are.
AMF
Action Message Format (AMF) is a compact binary format that is used to serialize
ActionScript object graphs. Once serialized an AMF encoded object graph may be used
to persist and retrieve the public state of an application across sessions or allow two
endpoints to communicate through the exchange of strongly typed data.
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others.
Both AMF and JSON are compact serialization formats and provide efficient data transport. The main differences between the two formats are as follows:
AMF is a binary format that is not easily readable by humans, JSON is a text-based format that is easily readable.
AMF allows for serialization of strongly typed objects in transactions between the client and server, JSON only supports generic or loosely-typed objects.
Former Adobe Evangelist James Ward put together a suite of benchmarks comparing JSON, SOAP, and AMF that show comparable performance between AMF and JSON. Recently, AIR 3.0 and Flash Player 11 brought native JSON support, which greatly improves JSON parsing in Flash & AIR runtimes. This is a huge boost, especially for mobile applications that consume JSON data.
I put together a very basic test case where a mobile application makes requests of simple data objects from a ColdFusion CFC. In each test iteration, a request is made for 1, 10, 100, 1000, and 10000 value objects, in both AMF and JSON formats. The total round trip time from request to deserialization is measured and compared for each case, for a total of 5 iterations through each cycle. My findings are that AMF and JSON have comparable performance in smaller record sets. However, AMF seems to have better performance as data sets grow. In my test cases, the 1000+ record results were consistently faster using AMF. However, in smaller data sets, JSON was often faster (however not consistently, or by much of a margin). I tested these times on both an iPhone 4 and Motorolla Atrix, both running on the carrier networks (not over wifi).
Below is a video of the serialization testing application at work.
Here are a few screenshots of the application.
The Tests
For these tests I created two basic CFCs (ColdFusion Components). One is a simple data value object. The other CFC is a gateway to expose a remote service that returns the value objects to the client. I chose a ColdFusion CFC for this case b/c it can easily be serialized as AMF or JSON just by changing the endpoint used to consume the service.
Here is the service CFC used to return data to the client:
component {
remote array function getRecords(numeric records=1) {
var result = [];
for (var x = 0; x < records; x=x+1) {
var item = new SampleVO();
item.itemId = x;
ArrayAppend( result, item );
}
return result;
}
}
Obviously, this is a fictional data object with randomly generated values. However, it still represents a reasonable service payload for data serialization. By accessing the data via the ColdFusion Flex/Remoting gateway, you access the remote services via AMF3.
remoteObject = new RemoteObject("ColdFusion");
remoteObject.source = "com.tricedesigns.mobileTest.Services";
remoteObject.endpoint = "http://tricedesigns.com/flex2gateway/";
var token : AsyncToken = remoteObject.getRecords( RECORD_COUNT[ recordCountIndex ] );
token.addResponder( new mx.rpc.Responder( onAMFResult, onFault ) );
By accessing the data via an http endpoint, with returnformat=josn, you will invoke the same CFC remote method exposed as JSON.
httpService = new HTTPService();
httpService.url = "http://tricedesigns.com/com/tricedesigns/mobileTest/Services.cfc?method=getrecords&records=" + RECORD_COUNT[ recordCountIndex ] + "&returnformat=json";
var token : AsyncToken = httpService.send();
token.addResponder( new mx.rpc.Responder( onJSONResult, onFault ) );
The JSON-formatted data will look something like this:
In the mobile client application, I have a SerializationTestController class that handles all of the test logic and communications back and forth with the server. The time for each test is measured from immediately before the the request is made to the server, until after the data has been deserialized to an ArrayCollection. You can view the SerializationTestController class below:
package control
{
import flash.events.Event;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.utils.getTimer;
import model.TestSummaryVO;
import model.TestVO;
import mx.collections.ArrayCollection;
import mx.rpc.AsyncToken;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.rpc.http.HTTPService;
import mx.rpc.remoting.RemoteObject;
import views.SummaryView;
[Event(name="testStatusChange", type="control.TestUpdateEvent")]
[Event(name="testUpdate", type="control.TestUpdateEvent")]
public class SerializationTestController extends EventDispatcher
{
private var remoteObject : RemoteObject;
private var httpService : HTTPService;
private var _testing : Boolean = false;
private var testIndex : int = 0;
private var iterationIndex : int = 0;
private var recordCountIndex : int = 0;
private var testInstanceIndex : int = 0;
private var _results : ArrayCollection;
private var currentTest : TestVO;
public static const ITERATIONS : int = 5;
public static const RECORD_COUNT : Array = [1,10,100,1000,10000];
public static const TESTS : Array = [ TestVO.TYPE_AMF, TestVO.TYPE_JSON ];
public function SerializationTestController(target:IEventDispatcher=null)
{
super(target);
remoteObject = new RemoteObject("ColdFusion");
remoteObject.source = "com.tricedesigns.mobileTest.Services";
remoteObject.endpoint = "http://tricedesigns.com/flex2gateway/";
httpService = new HTTPService();
_results = new ArrayCollection();
}
[Bindable(event="testStatusChange")]
public function get testing ():Boolean
{
return _testing;
}
public function get results():ArrayCollection
{
return _results;
}
public function get chartResults() : ArrayCollection
{
var result : ArrayCollection = new ArrayCollection();
for ( var index : int = 0; index < ITERATIONS; index++ ) { var summaryVO : TestSummaryVO = new TestSummaryVO(); summaryVO.iteration = index+1; result.addItem( summaryVO ); } for each ( var vo : TestVO in results ) { summaryVO = result.getItemAt( vo.iteration ) as TestSummaryVO; if ( vo.type == TestVO.TYPE_AMF ) summaryVO[ "amfDuration" + SerializationTestController.RECORD_COUNT[ vo.recordIndex ] ] = vo.endTime - vo.startTime; else summaryVO[ "jsonDuration" + SerializationTestController.RECORD_COUNT[ vo.recordIndex ] ] = vo.endTime - vo.startTime; } return result; } public function startTest() : void { if ( _testing ) return; _testing = true; testIndex = 0; iterationIndex = 0; recordCountIndex = 0; testInstanceIndex = 0; updateTest(); dispatchEvent( new TestUpdateEvent( TestUpdateEvent.TEST_STATUS ) ); dispatchEvent( new TestProgressEvent( "STARTING TEST..." ) ); } private function completeTest() : void { _testing = false; dispatchEvent( new TestUpdateEvent( TestUpdateEvent.TEST_STATUS ) ); dispatchEvent( new TestProgressEvent( "TEST COMPLETE" ) ); } private function createTestVO() : void { currentTest = new TestVO(); currentTest.startTime = getTimer(); currentTest.index = testInstanceIndex; currentTest.iteration = iterationIndex; currentTest.recordIndex = recordCountIndex; currentTest.type = TESTS[ testIndex ]; } private function finalizeTestVO(error : Boolean = false) : void { if ( error ) currentTest.endTime = -1 else currentTest.endTime = getTimer(); _results.addItem( currentTest ); dispatchEvent( new TestUpdateEvent( TestUpdateEvent.TEST_UPDATE, currentTest ) ); dispatchEvent( new TestProgressEvent( "task completed in " + (currentTest.endTime - currentTest.startTime) + " milliseconds" ) ); currentTest = null; } private function updateTest() : void { if ( iterationIndex >= ITERATIONS )
return completeTest();
createTestVO();
if ( TESTS[ testIndex ] == TestVO.TYPE_AMF )
{
doAMFTest();
recordCountIndex ++;
if ( recordCountIndex >= RECORD_COUNT.length )
{
recordCountIndex = 0;
testIndex++;
}
}
else if ( TESTS[ testIndex ] == TestVO.TYPE_JSON )
{
doJSONTest();
recordCountIndex ++;
if ( recordCountIndex >= RECORD_COUNT.length )
{
recordCountIndex = 0;
testIndex = 0;
iterationIndex ++;
}
}
testInstanceIndex++;
}
private function doAMFTest() : void
{
dispatchEvent( new TestProgressEvent( "AMF Requesting " + RECORD_COUNT[ recordCountIndex ] ) );
var token : AsyncToken = remoteObject.getRecords( RECORD_COUNT[ recordCountIndex ] );
token.addResponder( new mx.rpc.Responder( onAMFResult, onFault ) );
}
protected function onAMFResult( event : ResultEvent ) : void
{
var result : ArrayCollection = event.result as ArrayCollection;
finalizeTestVO();
updateTest();
}
private function doJSONTest() : void
{
dispatchEvent( new TestProgressEvent( "JSON Requesting " + RECORD_COUNT[ recordCountIndex ] ) );
httpService.url = "http://tricedesigns.com/com/tricedesigns/mobileTest/Services.cfc?method=getrecords&records=" + RECORD_COUNT[ recordCountIndex ] + "&returnformat=json";
var token : AsyncToken = httpService.send();
token.addResponder( new mx.rpc.Responder( onJSONResult, onFault ) );
}
protected function onJSONResult( event : ResultEvent ) : void
{
var resultString : String = event.result as String;
var result : ArrayCollection = new ArrayCollection( JSON.parse( resultString ) as Array );
finalizeTestVO();
updateTest();
}
protected function onFault( event : FaultEvent ) : void
{
trace( event.fault.toString() );
finalizeTestVO(true);
updateTest();
}
}
}
Also, here is the TestVO value object that shows the information captured for each test:
package model
{
public class TestVO
{
public static const TYPE_JSON : String = "json";
public static const TYPE_AMF : String = "amf";
public var index : int;
public var iteration : int = 0;
public var startTime : int;
public var endTime : int;
public var type : String;
public var recordIndex : int;
public function TestVO()
{
}
}
}
Summary
Both JSON and AMF are acceptable serialization formats for mobile applications built with AIR. Both are compact serialization formats that minimize packet size. Both have native parsing/decoding by the AIR runtime. AMF will generally provide better performance for larger data sets. JSON *may* provide marginally better performance for small data sets. AMF also allows for strongly typed object serialization & deserialization, where JSON does not.
The answer to the question of “should I use AMF or JSON” is subjective… What kind of data are you returning, and how much data is it? Do you already have AMF services built? Do you already have JSON services built? Are the services consumed by multiple endpoints, with multiple technologies? Do you rely upon strongly typed objects in you development and maintenance processes? Both AMF and JSON are viable solutions for mobile applications.
Tomorrow (Thurs) I'm presenting an "Introduction to Mobile Development with PhoneGap" at Towson University http://t.co/Qch6pD93 Come on out! 3 hours ago
If you hadn’t heard already, 
This includes my URL Monitor application, available for iOS, Android, and BlackBerry, developed using Adobe AIR. The URL Monitor tool is a simple diagnostic application that will allow you to quickly and easily monitor the status of various URL endpoints. Simply enter a URL into the text box and add it to the list. A polling HTTP request will be made every 10 seconds to determine the availability of a given endpoint. HTTP codes 200, 202, 204, 205 and 206 will be identified as a success with a green check. All other HTTP codes will indicate a problem as a red ‘X’.
The Flex Mobile Serialization Testing application is a basic scenario for testing performance between AMF and JSON in a Flex application. The mobile app makes requests of simple data objects from a ColdFusion CFC. In each test iteration, a request is made for 1, 10, 100, 1000, and 10000 value objects, in both AMF and JSON formats. The total round trip time from request to deserialization is measured and compared for each case, for a total of 5 iterations through each cycle. The application displays end-to-end performance metrics for both AMF and JSON requests.
The Enterprise Tablet Visualization application is a sample application built using Adobe Flex and AIR. The application is not a production application. It demonstrates realtime data push to a mobile application using LiveCycle Data Services, realtime multimedia collaboration using LiveCycle Collaboration Services, as well as multi-form-factor UI for both tablet and phone devices, including map integration and interactive data visualizations.
Recent Comments