I think this layout would be nice for Mobile devices to quickly browse content by tapping and dragging. I’ve tested it in different devices and from a usability perspective it’s very nice. I can see a big potential on it.

You can check the code here.

As an exercise to better understand the details of the new layout mechanism I played a couple of days creating some layouts that I’ll be posting during the next days.

The first layout I created was a Coverflow layout. There already exist several implementations out there for Flash and even Flex. The biggest difference in this implementation is that it’s using standard 2.5D APIs and the standard Flex4 layout mechanism. This translates in a 200 lines of code and quite good performance.

Bear in mind that:

1. This is not production ready code and might have issues.
2. I haven’t optimised the code at all, it’s almost a first pass code.
3. The layout is not using any virtualization capabilities, which means that won’t perform nicely with big dataproviders. I’ll implement this in the future.
4. I’ve added several configuration parameters and some combinations might not work as good as others.

As an extra, and even though Flex4 is not specifically designed for mobile, see how it works in a Nexus One with FP 10.1 beta. In the video below you can see how the application runs just out of the box, no recompilation, no changes at all. Same content that runs in my laptop runs in Enrique’s phone. The performance is really nice! What the Flash Player team has achieved is amazing!
congratulations guys!!

You can run the application here http://www.rialvalue.com/coverflow
You can get the source code here http://rialvalue.com/coverflow/srcview

Which parameter combination do you like more?

The goal was to be able to consume, from the new application, the exact same Java Services that the Flex application was consuming through RemoteObjects without modifying the Java code or the server gateway at all.

This scenario could be a very common scenario in the near future when porting, adapting or extending existing applications to different devices targetting Flash Player 10.1.

BlazeDS uses some kind of handshake between the client and the server as well as control messages that were not obvious to replicate in a custom implementation using a plain NetConnection object. Also I wanted to make use of the several more complicated features that Flex rpc implementation brings.

Basically the problem became to “How could I use the entire component set from rpc.swc distributed with Flex SDK in a Flash or AS3-only project?”

This excercise is also applicable to WebService, HttpService, Consumer or Producer (messaging) classes.

Step 1.

Add rpc.swc from {FLEX_HOME}/framework/libs to your project or .fla classpath

Step 2

Compile some simple code using RemoteObjects:

Compiling this code throws several different errors due to unsatisfied or missing dependencies:

mx.logging.ILogger
mx.rpc.IResponder

These 2 classes are in framework.swc Copying the swc from the FlexSDK into your classpath will fix the issues.

Step 3

After that you’ll get errors due to missing resource bundles like:
“Unable to resolve resource bundle ‘collections’ for locale ‘en_US’”

Copying to the classpath the required resource bundles from {FLEX_SDK}/frameworks/locale/ will fix the problem. You’ll only need to copy rpc_rb.swc and framework_rb.swc

You will receive this error only if compiling the project using the Flex compiler. You won’t get this error if you compile your application in Flash.

Step 4

When the application finally compiles you’ll always get FaultEvents with not too much information.

faultCode: “Client.Error.MessageSend”
faultDetail: “Channel.Connect.Failed error null url: ‘null’”

Using Charles I realized that the request was not even sent, something was going wrong.

Step 5

All RPC classes use the Flex logging API so enabling it in the Flash project could be helpful. To enable it we only need to add:

Step 6

After a couple of hours of debugging I discovered that RPC library to properly work needs to be initialized in the following way:

Where loaderInfo is the loaderInfo object of the root Sprite of your application.

After adding the initialization code you will see the request going through in Charles.

Step 7

There’s still one last problem to solve:

“TypeError: Error #1034: Type Coercion failed: cannot convert Object@20612a79 to mx.messaging.messages.ErrorMessage.”

The error means that somewhere an ErrorMessage object was expected but instead an object of type Object is received. We need to register several types. This will happen with several different types of ojects. To solve it:

After properly registering these classes everything should work as expected (the list of required registrations might not be complete, if you find a TypeCoercion error consider registering the object).

The entire code you need:

Pros and cons of the solution

• ~100Kb footprint
• You can focus on adding value and not building the infrastructure.
• Faster time to market
• Solid market solution

Improvement points

Using the above solution you’ll have to work with ArrayCollection instead of Arrays which in certain situations might not be necessary, might have a performance impact as well as increase the number of class dependencies and file size.

One possible way to get rid of ArrayCollection and all its dependencies (i.e. ListCollectionView, Cursor, SystemManager, etc.) would be to create your own map. Instead of using:

You could use:

Where your class would implement IExternalizable. This class could be completely light and would mean a considerable improvement in terms of dependencies and lighter implementation.

The stacktrace of these exceptiosn, normally, looks like the lines below:

Today, snooping around the UIComponent class, I’ve found a nice unexpected thing. Basically the invalidation pattern in the SDK is built around the LayoutManager and the UIComponent classes. The callLater method is the responsible to delay the execution of certain functionalities to the next frame. callLater implementation relies on the RENDER and ENTER_FRAME frames. The handler for these events is the method callLaterDispatcher.

Here’s the surprise. If UIComponentGlobals.catchCallLaterExceptions is true, the execution of the validation cycle will be wrapped with a try..catch and a DynamicEvent will be dispatched through the systemManager with information about the error.

This opens the doors for at least catch the error and log it. In some cases, depending on the severity of the error and if the application is not too corrupted, we’ll even be able to display a message to the user notifying him the error. This is not a fix to FP-1499 nor FP-444 but under some circumstances it can be really helpful if combined with great logging practices as explained by Tom.

I’ve created a simple class that hooks into the systemManager, listens for the callLaterError event and logs it using the standard SDK logging mechanism. The AsyncErrorLogger is MXML friendly so that it can be instantiated in the root application. It provides an enable property to switch the behavior on and off. Additionally the property redispatchErrorEvent, which by default is false, redispatches the error causing the traditional flash player error dialog to appear (in debugger player versions) and not fail silently.

Here’s an example on how to use it:

Here’s the code. You can download the class from here as well.

Here’s the source code for the examples.