Category Archives: AIR

Toying with Realtime Data & Web Sockets

Recently I was acting as a “second set of eyes” to help out fellow Adobe Evangelist Kevin Hoyt track down a quirk with a websockets example that he was putting together. Kevin has a great writeup to familiarize yourself with web sockets & streaming communication that I highly recommend checking out.

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.

Again, rather than trying to put lots of confusing code snippets inline in this post, check out the full client side source at: https://github.com/triceam/Websocket-Streaming-Example/tree/master/client

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.

Enjoy!

Flex 4.6 is Available AND I’m on TV!

(Adobe TV, that is)

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.

You can download the open source Flex SDK at: http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4.6.

Or, you can download Flash Builder 4.6 from: https://www.adobe.com/cfusion/tdrc/index.cfm?product=flash_builder.  Flash Builder 4.6 release notes are available at http://kb2.adobe.com/cps/921/cpsid_92180.html

Note: you must uninstall Flash Builder 4.5.1 to install Flash Builder 4.6.  

You can read specifics about what’s new in Flash Builder 4.6 on the Adobe Developer Connection at: http://www.adobe.com/devnet/flash-builder/articles/whatsnew-flashbuilder-46.html, and what’s new in Flex SDK 4.6 at: http://www.adobe.com/devnet/flex/articles/introducing-flex46sdk.html

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…

Captive Runtime for Mobile

Captive Runtime for Desktop

My Projects on Github

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’.

Source: https://github.com/triceam/URL-Monitor
Detail: http://www.tricedesigns.com/url-monitor/

In the wild:


Mobile Serialization Tester

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.

Source: https://github.com/triceam/Flex-Mobile-Serialization-Tester
Detail: http://www.tricedesigns.com/2011/11/07/amf-vs-json-in-air-mobile-applications/

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.

You can preview a video of this application in action at:
http://www.youtube.com/watch?feature=player_embedded&v=zimrDQsmSks

Source: https://github.com/triceam/Enterprise-Tablet-Visualization
Detail: http://www.tricedesigns.com/2011/09/28/visualizing-complex-enterprise-data-in-a-tablet-world/

More on the Future of Flex & Flash

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:

http://www.adobe.com/devnet/flashplatform/articles/recent-updates.html

You can read the FAQ at:

http://www.adobe.com/devnet/flex/articles/flex-announcements.html

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.

No, Flex & Flash Are Not Dead

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.

Andrew and Deepa from the Flex team have posted some questions and answers raised by these conversations. I highly recommend reading these in their entirety, as they will answer a lot of the questions about the future of Flex. Key takeaways:

Is Adobe still committed to Flash Builder?

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.

-http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html

Adobe’s Mike Chambers has also posted information explaining a bit more detail, and providing insight into the future of Flash and AIR.   Key takeaways:

Adobe AIR

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.

-http://www.mikechambers.com/blog/2011/11/11/clarifications-on-flash-player-for-mobile-browsers-the-flash-platform-and-the-future-of-flash/