Author’s Update, June 1, 2010
This article describes how and why you need to modify the WebORB for PHP internal PHP code so that you can transfer photos from the PHP server to the Flex client, arriving as ActionScript 3 ByteArray data type. This internal PHP code modifications, described later in this article are no longer necessary. I recently identified a new way perform this photo data transfer by replacing the WebORB for PHP application server with Zend’s Zend Framework application server. Zend Framework supports photo data transfers without requiring internal code modification of PHP code within the framework. See my DevelopRIA article Flex 4 / PHP Data-Centric Photo Transfers for details on how to replace WebORB for PHP with Zend Framework.
Transferring photos from the PHP server to the Flex client via AMF 3 RemoteObject data streams is currently one of my favorite RIA topics. That’s because it took me more than a few days to figure out why I was able to display my photos when they were on the PHP server, but I could no longer display them by the time they were received by my Flex client. I’m anxious to share what I know about this in the hope that others do not have to go through what I did to get this working properly. The subtleties of what happens during the server-to-client photo data transfer are enough to drive you up the wall.
Here’s the scenario, what you’ll require and the specific solution that helped me.
In my SQGallery application article in DevelopRIA, we were discussing a Flex-based photo rendering RIA named SQGallery that pulls the photos from a MySQL database with Action Message Format (AMF3) Messaging through the WebORB for PHP application server. The dilemma is that the PHP data types are somewhat restricted in what’s available to meet our needs. Principally, the PHP data types are four scalar types: boolean, integer, float (floating-point number, a.k.a. ‘double’) and string; two compound types: array and object; and finally two special types: resource and NULL.
When the WebORB PHP application server loads photo data — effectively an array of bytes — from the SQPhoto MySQL database, PHP insists on typing photos as a string data type. Ah, I thought, all sounds well and good. I will simply return the photo PHP string photo byte array to the Flex client, receiving the photo data as an ActionScript 3 (AS3) String object. Then I will cast the String AS3 object to a ByteArray AS3 object so that the photo can be rendered and displayed using the Loader AS3 class.
The above is a great idea, but it did not work. I wondered why. After all, PHP strings are AS3 Strings … or are they? The AS3 String objects are formatted UTF-8, which means single-byte strings — the same as PHP server-side strings, right? You are wrong by 100%. In ActionScript, if the eighth bit (bit 7) of any byte is set (1), then the UTF-8 single byte is extended to a two-byte UTF-8 sequence. And guess what? Many of the photo string (array of bytes) have the eighth bit set. Talk about messing the photo content up! No wonder photos won’t display in the SQGallery Flex client.
I thought of an easy fix. Just cast the server-side PHP photo string to a ByteArray and receive the photos as AS3 ByteArray objects on the Flex client. After all, I know by looking at Adobe’s AMF 3 specification that the ByteArray data type is supported.
Two issues broke what I thought was a clever solution. First, while there is no PHP compile error, casting photos to PHP (ByteArray) does not work. PHP still insists that my photo array of bytes is a string. That’s because there is no ByteArray data type in the PHP language syntax.
The lack of a ByteArray (or, for that matter, a byte) data type in PHP is the cause of the second issue as well. While the AMF 3 specification says yes to of support ByteArray data types, WebORB for PHP does not support this data type. One cannot support what does not exist.
So there I was, trapped with a neat server-to-client photo search request to render and display photos with no way to transfer the photo data. Panic set in! Should I just scrap my code and move on to another endeavor-or jump from PHP to using Adobe’s ColdFusion or Adobe’s BlazeDS application servers? I knew these two server solutions both directly support AMF 3 RemoteObject data transfers.
But wait, there’s more! Eureka, at last I came up with a solution, albeit a bit of a kludge, that would surely work. I knew that JPEG and Portable Network Graphic (PNG) photos each have a unique set of identifying header bytes at the start of the photo byte data. Furthermore, the format specifications of these photo header bytes are easily obtainable via a couple of Google searches.
I couldn’t find an available AMF 3 ByteArray writer within the WebORB application server. So first I developed an AMF 3 ByteArray writer class in PHP. The writer class is simple and short because all it needs to do is call other WebORB code classes to perform the work. Next, I went inside the WebORB classes to find the AMF 3 String Writer class. (Hint: All the WebORB AMF 3 Writer classes are in the Writer folder.) I located the AMF 3 String Writer in WebORB’s MessageWriter class. Next, I added PHP code to intercept the AMF 3 String before it’s serialized into an AMF 3 stream and then performed two tests, both of which must be true before moving forward with any translation action:
- Is the string an arbitrarily long string-like 300 bytes?
- Do the first few header bytes of the PHP string indicate a JPEG or PNG photo?
If the string passed both of the above tests, then I simply transferred the AMF 3 String to my newly written WebORB and AMF 3 ByteArray writer class, which serializes it into a data stream and sends it on its merry way to the SQGallery Flex client.
Guess what? My mapping of the AMF 3 Strings to AMF 3 ByteArrays worked the first time I tried it with a server-to-client photo transfers. After nearly a month of on-and-off frustration, I figured out the issues involved and came up with a solution.
The elapsed time to figure out all of the above and get it working was just short of a month. I’m not one who gives up easily when the programming syntax and supporting framework don’t do what I want. Needless to say, it was a good feeling when it all finally worked.
When dealing with server-to-client PHP-based AMF 3 transfers, I hope you will remember the code chicanery I came up with and discussed. And please pass this information along to others who may come upon this barrier of PHP server to AMF 3 client photo data transfers.
It’s perhaps not the cleanest of solutions, but it does the job. I do welcome suggestion of better solutions to handle ByteArray management of photo string data.
The specifics of the changes I made to WebORB for PHP are fully discussed and explained in two documents, “WebORB 3.6 AS 3 ByteArray Writer Design Notes” and “WebORB 3.6 PHP Class Module ByteArray Writer Update Instructions”. Click here to download these two documents along with the WebORB for PHP server PHP class modifications and additions.