Bug: AIR for Android, SharedObject and File

While working on a recent AIR for Android application, I found myself pulling my hair out over a strange bug. To speed up application development, I was persisting some of my application VOs using SharedObject, e.g:

var appSharedObject: SharedObject = SharedObject.getLocal( "appModel" );
appSharedObject.data[ "content" ] = vo;
appSharedObject.flush(  );

This had been working flawlessly for some time, and I had little reason to suspect it. The symptoms were particularly painful: after the application had finished with one View, persisted the data and attempted to move onto the next View, the application would unexpectedly close. There was no error, no crash and no stack trace.

Thankfully, my persistence layer had already been abstracted into a service, and I was able to implement an empty version and plug that in with little effort. With this in place, everything worked fine, so I was confident it had something to do with the SharedObject persistence. I needed to debug things further, but didn't want to spent hours rewriting the application.

Enter the [Transient] metadata. Adobe defines this metadata element as:

Identifies a property that should be omitted from data that is sent to the server when an ActionScript object is mapped to a Java object using [RemoteClass].

However, it can be used to provide hints to the SharedObject serialization system on which fields to ignore: marking any fields with [Transient] will see them ignored by SharedObject. By using this trick, I was able to use a binary search to very quickly identify which field was causing the problem. It turned out that a File instance containing a reference to a captured photo was causing a low-level crash with the AIR runtime, when it was serialized to a SharedObject; the same location stored in a String presents no problem (and, for that matter, files pointing to other locations present no problem).

Hopefully this saves someone else a heap of time!

Printing in Flex, with runtime images

Printing in Flex is a topic that comes up from time to time, and is met by a shudder from most people. Whilst it is nice to have some direct printing capability within the Flash Runtime and API set, it is far from friendly to work with.

FlexPrintJob provides a nice abstraction on top of the core Flash Printing API, allowing Flex visual components to be printed directly. This can make life easier when it comes to complex layouts and content, as it is not necessary to work with low-level drawing APIs. However, do note that Flex components need to be added to the display list, otherwise certain dependent resources will not be available that are required by FlexPrintJob to function correctly.

The general premise is to call FlexPrintJob.start() which begins the print job, and presents the end user with a print dialog. This method is synchronous, and processing will halt until the user has made a selection (do note, however, that the Flash API places a 15 second maximum time between calling FlexPrintJob methods, and I experienced timeout issues when spending too much time working with an Acrobat Distiller browse dialog). After this point, FlexPrintJob.addObject() is called for each page in the print job. At its conclusion, FlexPrintJob.send() is called to pass the job to the native print spooler.

The problem I encountered recently involved the printing of images, which did not make use of embedded content. I'll demonstrate with a brief example. The printable UI may look like:

PrintUI.mxml

<s:Group>
   <s:Image id="image" />
</s:Group>

PrintMediator.as

[Inject]
public var printUI: PrintUI;

private var _imageData: ByteArray;

override protected function onRegister(  ): void
{
   addContextListener( ApplicationEvent.PRINT, onPrint, ApplicationEvent );
}

private function onPrint( event: ApplicationEvent ): void
{
   var flexPrintJob: FlexPrintJob = new FlexPrintJob(  );
   flexPrintJob.start();
   flexPrintJob.printBitmap = false;

   printUI.image.source = _imageData;

   flexPrintJob.addObject( printUI );

   flexPrintJob.send(  );
}

So, what happens? Ideally, the printed output should contain a representation of the image contained in the ByteArray. Unfortunately, we'll get a blank page. Why is this? It comes down to the way that Image handles a ByteArray. Whilst the data is available client-side, it still needs to be validated by the image parser. Consequently, when the .source setter is called, the value is stored in the Image instance, but it is not processed until a later stage - one which is not in the current call-stack. Consequently, by the time processing has reached the FlexPrintJob.addObject() method, the Image data has not been converted into its visual representation.

Fortunately (although not simply), the Image API provides events to track the progress of loading and parsing. Thus, problem is resolved by listening for the FlexEvent.READY event, which is fired when the image has been processed and displayed. The downside to this is that a simple synchronous function (like the one presented above), must become asynchronous, as indicated below:

PrintMediator.as

[Inject]
public var printUI: PrintUI;

private var _imageData: ByteArray;

private var _flexPrintJob: FlexPrintJob;

override protected function onRegister(  ): void
{
   addContextListener( ApplicationEvent.PRINT, onPrint, ApplicationEvent );
   printUI.image.addEventListener( FlexEvent.READY, onImageReady );
}

private function onPrint( event: ApplicationEvent ): void
{
   var flexPrintJob: FlexPrintJob = new FlexPrintJob(  );

   _flexPrintJob.start();
   _flexPrintJob.printBitmap = false;

   printUI.image.source = imageData;
}

private function onImageReady( event: FlexEvent ): void
{
   _flexPrintJob.addObject( printUI );

   _flexPrintJob.send(  );
}

Obviously these examples have been simplified for the purposes of display.

Calling LiveCycle processes via Remoting, involving Documents

One nice aspect of Adobe's LiveCycle is the ability to easily invoke a process using Flex Remoting. For 'primitive' types, such as Number, XML and String, it's a straight-forward case of passing them to the Remoting call. However, in some instances, it is necessary to pass a LiveCycle Document instance to a Remoting call. The recommended means of doing this involves a two-step process, where the Document is uploaded to the LiveCycle server, which returns a DocumentReference. This reference is passed to the Remoting call and LiveCycle marries everything up on its end.

I encountered an issue with this recently in an enterprise environment, due to the way DocumentReference works. After the Document has been stored on the server, LiveCycle constructs a URL pointing to it - based on the application URL of the Flex application that performed the upload. In our client's case, the application URL does not resolve inside their firewall. This meant that when LiveCycle attempted to load the Document based on the DocumentReference, it was unable to locate it.

Manipulating the DocumentReference on the client side was ruled out, due to the maintenance nightmare and security implications of having internal infrastructure details stored within the application itself. Resolving the issue on the server side was not a straightforward solution, as all processes involving Documents would have to be changed.

It turns out there's a simple solution; instead of performing a HTTP-based Document upload (which also has problems in a HTTPS context on non-IE browsers), it is possible to manually construct a DocumentReference instance, and pass in the file data by hand. For example:

var documentReference: DocumentReference = new DocumentReference(  );
documentReference.referenceType = DocumentReference.REF_TYPE_INLINE;
documentReference.bytes = yourByteArray;