Strange! The width and height are larger than the screen resolution. You can fix this by adding the following to the HTML page:

<meta name="viewport" content="target-densityDpi=device-dpi; user-scalable=0;" />

And now it will look like:

Now that looks right! This also turns off the two-finger / pinch zooming feature for the page (which is more important for content that hasn’t been optimized for a mobile profile).

I hope this is useful for those of you embarking on new adventures with Flash / Flex on mobile devices!

Ok, hopefully that worked for you. I’ve tested this in the latest Chrome, Firefox, Safari, and IE and they all seem to work. It should also work on your iPad, iPhone, or Android device.

Now for those gory details… AMF is a protocol initially created in Flash Player as a way to serialize data for storage on disk or transfer over a network. Typically in web apps we use text-based serialization protocols (like JSON or RESTful XML) for data transfer. But there are some advantages to using binary protocols – primarily much better performance. There are two versions of the AMF protocol, AMF0 and AMF3. Both are publicly documented by Adobe and numerous server-side implementations of AMF exist. AMF is just a serialization technology, not a transport. So you can put AMF encoded data into any transport (like HTTP / HTTPS). Typically Flash Player is the client that reads / writes AMF data.

I recently had a conversation with Stephan Janssen who runs Parleys.com (an amazing Flex app), which started me on this fun project. The Parleys.com PC-profile web client and the Adobe AIR desktop client both use BlazeDS and AMF as the primary serialization protocol for moving data between client and server. This is a great choice for those clients because it makes the apps snappy. But for the HTML5 client Stephan wants to reuse his AMF endpoints. This is where amf.js comes in.

Flash Player has a ByteArray API that can be used for a lot of amazing things. One of those things is to read and write AMF. If you have an object in Flash Player and you create a new ByteArray and then call “byteArray.writeObject(myObject)” you will get a ByteArray with the AMF representation of that object. Likewise if you get some AMF and you call “byteArray.readObject()” you get the object(s) from the AMF. In Flex there are high level APIs (like RemoteObject, Consumer, etc.) that use this native AMF support in Flash Player.

To create a pure JavaScript AMF library the first thing that is needed is a pure JavaScript ByteArray library since JavaScript doesn’t natively have one. I used one from adamia.com since it was similar to the ByteArray in Flash Player, seemed fast, and seemed to parse floats correctly. This ByteArray has some of the basic functions like readByte, readFloat, etc. But what about that cool readObject function? Well, that has to be built from scratch. And it should support both AMF0 and AMF3.

Using the AMF specs and code from BlazeDS & pyamf as a reference I was able to add the other functions to the ByteArray. But there was a problem. Using XMLHttpRequest as the method of getting the AMF was not working right. Some bytes were incorrect. It turns out XMLHttpRequest uses UTF-8 and that screws up some of the bytes above 128. I tried other charsets and each one would change some range of bytes. That is not good because I need the bytes to be exactly what the server sent. Then I came across this gem:

//XHR binary charset opt by Marcus Granado 2006 [http://mgran.blogspot.com]
req.overrideMimeType('text/plain; charset=x-user-defined');

Using the “x-user-defined” charset left the bytes alone. Perfect! Except that IE doesn’t support the req.overrideMimeType function. But IE does actually have a real ByteArray available in req.responseBody via VBScript. For now in IE I just change the ByteArray into a string (like req.responseText in the other browsers) although a lot of optimization could be done to just use the VBScript ByteArray directly.

Right now amf.js is just a basic JavaScript library for reading AMF data. It doesn’t support using a BlazeDS MessageBrokerServlet yet because I need to be able to assemble a AMF object in JavaScript and send that in the HTTP request to the servlet. But it works fine with a custom servlet that uses BlazeDS’s AMF library to just write AMF into the HTTP response. It should also work with pyamf, AMFPHP, and other AMF server libraries.

To use amf.js start by dumping some AMF into an HTTP response. In Java with BlazeDS I did this:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
{
    response.setHeader("Content-Type", "application/x-amf;charset=x-user-defined");
    ServletOutputStream out = response.getOutputStream();
    ActionMessage requestMessage = new ActionMessage(MessageIOConstants.AMF3);
    MessageBody amfMessage = new MessageBody();
    amfMessage.setData(someSerializableObject);
    requestMessage.addBody(amfMessage);
    AmfMessageSerializer amfMessageSerializer = new AmfMessageSerializer();
    amfMessageSerializer.initialize(SerializationContext.getSerializationContext(), out, new AmfTrace());
    amfMessageSerializer.writeMessage(requestMessage);
    out.close();
}

In a HTML web page add the amf.js script:

<script type="text/javascript" src="amf.js"></script>

In JavaScript make a XHR request for some data:

var url = "TestServlet";
var req;
 
function getAMF()
{
    if (window.ActiveXObject)
    {
        req = new ActiveXObject("Microsoft.XMLHTTP");
    }
    else if (window.XMLHttpRequest)
    {
        req = new XMLHttpRequest();
        //XHR binary charset opt by Marcus Granado 2006 [http://mgran.blogspot.com]
        req.overrideMimeType('text/plain; charset=x-user-defined');
    }
    req.onreadystatechange = processReqChange;
    req.open("GET", url, true);
    req.send(null);
}

And when the response comes back decode the AMF:

function processReqChange()
{
    if (req.readyState == 4)
    {
        if (req.status == 200)
        {
            var o = decodeAMF(req.responseText).messages[0].body;
        }
        else
        {
            alert("There was a problem retrieving the data:\n" + req.statusText);
        }
    }
}

For details on how to support IE, check out the source code for censusTest.html.

While amf.js works in my tests there is more work to be done. I need to add the write functions so that AMF can be sent to the server. Then supporting BlazeDS’s MessageBrokerServlet should be pretty straightforward. I’d also like to create pure JavaScript implementations of Flex’s RemoteObject, Consumer, and Producer APIs. Also, I need people to test amf.js with their AMF to make sure that I’ve implemented things correctly. All of the code is on github.com so go ahead and fork it! Let me know what you think.

• File Promises
• Mass Storage Detection
• Native Process
• Open with default app
• Socket Server

Also there are some great examples of the new Flash Player 10.1 and AIR 2 APIs including:

• Gestures
• Global Error Handler
• Globalization / Internationalization
• Microphone access

Those are some great examples but my favorite is still Doug McCune’s Physics Form followed closely by the real-time Tour de Flex Dashboard. :)

If you already have Tour de Flex installed then it should auto update to the latest version when you launch it. Otherwise install it now using the badge installer below.

Take a look a some of the quick demos I’ve built with Flex running on Android in Flash Player and AIR:

You can get the source code for all of these demos from github.

Also Christophe Coenraets has posted some great Flex mobile demos. Check out his Employee Directory and Stock Trader demos.

These are very exciting times for developers!

If you want to check out the Flash Player 10.1 beta for Android it will be available in the Android Marketplace for Android 2.2 devices. You can try Adobe AIR for Android today by signing up for the prerelease.

I’ve posted the code for this second version of the touch scrolling demo. It was pretty trivial to optimize it this far. With a little more work it’ll be as smooth as silk and as fast as Apolo Ohno. :)

Over the past few days I’ve received some questions about the performance of Flex apps on mobile devices. My Census RIA Benchmark has been a great way to compare the performance of various data loading techniques and technologies. Now that I have my Android based Nexus One mobile device with an early build of Flash Player 10.1 I wanted to see how fast I could load and render large amounts of data in a Flex application. I’m really impressed with the results! 20,000 rows of data loaded from the server and rendered on my phone in about 2 seconds! Those 20,000 rows can then be sorted on the device instantaneously. Pretty amazing performance for such a little device! Check out the video:

You can run the mobile version of the Flex AMF Census Test and check out the source code. Let me know what you think.

One of the challenges of running existing web content on mobile devices is that user interactions differ between mediums. For instance, on a normal computer with a mouse, scrolling though lists is often done by clicking on scroll bars or mouse wheels. On mobile devices that lack a pointing device this is not the best interaction paradigm. On devices with touch screens the paradigm for scrolling is usually a swipe gesture.

In Flash Player 10.1 there are APIs for gestures and multitouch events. I thought it would be fun to hook up the list scrolling on a Flex 4 List to the TouchEvent on my Nexus One. Check out the video:

If you want to see how I created this simple demo, check out the source code. Let me know if you have any questions.

BTW: The app I created for the demo is available at bit.ly/tdfmdb.

• An article I wrote has been published on the online Flash & Flex Developer’s Magazine: Flex and The Cloud: Is this really just Client/Server 2.0?
• I’ll be speaking on Thursday, February 18 2010 at the Denver Flex User Group about Flex and The Cloud
• The recording of a webinar I co-hosted on the new Salesforce.com Cloud platform for developers has been posted
• Jeff Douglas has posted a video walk through showing how to use the new Salesforce.com Flash Builder 4 extension for Flex + Cloud apps

Exciting stuff! Let me know what you think!

Adobe released security updates for the Flash runtimes: Flash Player 10.0.42.34 and Adobe AIR 1.5.3. The Flash Player update fixes an issue with mouse scroll wheels not working in Flash when using Safari.

Recently, Adobe also released public betas for Adobe AIR 2 and Flash Player 10.1. This Flash Player release fixes the “Incorrect unicode input in Linux” bug. Both AIR 2 and Flash Player 10.1 have a new API for Global Exception Handling (which was one of the highest rated feature requests on bugs.adobe.com). Check out Tour de Flex for some new samples on how to use this new and other new APIs.

For those looking to build Flex applications in the enterprise, Adobe has posted two great resources. First is a third-party study that says enterprise penetration of Flash Player 9 (or better) is at 97.6%! Second is a fantastic white paper about The Business Benefits of Rich Internet Applications – a must read for anyone in the enterprise who is evaluating Flex.

Last is a short video of me at Adobe MAX 2009 where I talk about the progress that Adobe is making in getting the Flash Platform onto the many screens in our lives and why that is exciting for developers. Let me know what you think!

Since Rich Internet Applications built with Flex, Silverlight, etc usually try to do more on the client side, for example mash-up data from multiple sites, the same-origin policy presents a problem.

In most cases Flash Player sticks with the typical browser sandbox concepts. But there are a few places where it goes outside this boundary such as with microphone and webcam access. Another area is by allowing opt-in to cross-domain communication bypassing the browser’s regular same-origin policy. Other plugins such as Silverlight and JavaFX also do this. This cross-domain capability is powerful but also very dangerous. The primary reason it’s dangerous is that a malicious application can potentially make requests on behalf of the user and access data from domains that the application didn’t originate from. To protect against these types of attacks Flash Player and other plugins have implemented a cross-domain policy system. This policy system is one of the most misunderstood aspects of web security.

To illustrate the problem I’ve create a few demos. Let’s say that I’m building an application for www.jamesward.com that will fetch some data from the www.firststepsinflex.com site.

Here’s that application on www.jamesward.com – open it in a new window.

The application correctly pulled the data from the www.firststepsinflex.com site but in order to allow the request I blindly put a crossdomain.xml policy file on www.firststepsinflex.com that looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <site-control permitted-cross-domain-policies="master-only"/>
    <allow-access-from domain="*"/>
</cross-domain-policy>

What this policy file does is instruct Flash Player to allow requests from any website to get around the same-origin policy and make requests to www.firststepsinflex.com – on behalf of the user. Sounds harmless, right? At this point it is, as long as all of the data on www.firststepsinflex.com is publicly available data. But let’s suppose that not all of the data should be publicly available. Perhaps I’m protecting access to some data though cookie authentication or HTTP basic authentication. In this case I am (for the purpose of the demo).

See the protected data by opening up http://www.firststepsinflex.com/private/bankaccounts.html using “username” and “password” (without quotes) for the user name and password.

Now imagine that someone starts posting Twitter links (obfuscated through a URL shortener) phishing for people to open a malicious application (open it in a new window – I promise it doesn’t do anything bad).

So let’s recap… There is a protected resource that only you should be able to see in your browser. Other applications should NOT be able to see that data. But a malicious application was able to load that same data and do whatever it wants with it. Scary.

Here’s how it works… The malicious application requests the protected page. It was able to make the request because you were authenticated already. And the malicious application can now read the data contained in the page and do whatever it wants with it (probably send it back to a server somewhere).

OK. Now do you understand why crossdomain.xml policy files are dangerous? Imagine if Facebook, MySpace, or YouTube had a misconfigured policy file on their servers! Well they have – but they’ve since been fixed. Imagine if your bank or a corporate intranet had a misconfigured policy file. There are some very serious ramifications to these types of attacks.

There are also some great uses of crossdomain policy files. For instance, api.flickr.com has an open crossdomain.xml policy file. This allows applications loaded from anywhere to access Flickr data and it’s safe because api.flickr.com doesn’t use cookies or basic auth – they use web service tokens, which are not automatically transmitted by the browser and are only known to the application that performed the authentication.

I often hear from Flex / Flash developers that when they run into security sandbox issues the first thing they try is to open things up with a global (i.e. “*”) policy file. I hope this article discourages that practice. Developers should understand why the security error is happening and consider alternatives before blindly opening up their website to the possible attacks. One alternative is to leverage a server proxy. A server proxy can be configured so that an application doesn’t violate the same-origin policy. For instance, if an application on foo.com needs data from bar.com then a proxy can be configured such that requests to foo.com/bar are forwarded on the server to the bar.com site. This helps avoid attacks because users’ cookies (or basic auth tokens) will not be sent to bar.com since all requests are actually being made to the foo.com site. But be careful not to expose intranet servers through proxies. Here is a sample Apache config for setting up a forward proxy:

  ProxyRemote  /bar/*  http://bar.com/
  ProxyPass /bar http://bar.com
  ProxyPassReverse /bar http://bar.com

BlazeDS also includes a proxy service.

If you really need to use a crossdomain policy file then be very careful! NEVER put a crossdomain policy file on a site that uses cookie or basic auth and NEVER put a crossdomain policy file on an intranet site – unless you really know what you are doing. To learn how to safely use crossdomain policy files here are some great resources:

• Policy file changes in Flash Player 9 and Flash Player 10
• Cross-domain policy file specification

I hope this helps create better understanding of web security. Please let me know if you have any questions.