Today has been a really frustrating day. I am writing a new game, and I’ve been making great progress so far. It’s highly optimized for memory performance (so far) and probably as OOP as I’ve ever done. Needless to say I’m rather proud of it so far. It’s been pretty smooth sailing all along, until today. When I found that there is some undocumented behavior. I am using a methodology called Object Pooling. Which basically means I am re-using instances rather than re-creating them. However, as I was going along I hit a nasty little problem. As items came up for re-use all of the visuals were missing. Everything else was there in memory, but the screen was blank. You can imagine my frustration. An to prevent others from experiencing the same frustration, I’ve decided to write what I found here.

What I found:

The items in question eventually inherit from flash.display.Sprite. I was also implementing a custom interface which defined a single method.
function reset():void;

I had this so that when I put the object back into the pool I could call this method which would restore the instance back to it’s default state. However it seems that there is an undocumented “feature” that won’t let me name my function “reset”. Maybe I’m blind, but I couldn’t find it here:   http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Sprite.html#methodSummary When I would call that function all of the visual elements of that class would be erased when I tried to add it back to the display list. As soon as I renamed the function to “resetItem” everything worked perfectly again.

A Word of caution:

Unless you too want to experience countless hours of frustration, *DO NOT* name your functions “reset” when extending from Sprite**.

** I don’t know it it also occurs when extending other things. I didn’t want to take the time to check because I was pretty peeved.

At first, I was one of those people. As part of my duties at work, I have to be mindful of UX (user experience). One of the most difficult tasks of UX has always been how to present data in intuitive and meaningful ways. Previous to this data revolution, many UX engineers would satisfy themselves with a variable cornucopia of buttons, myriads of menus, and tons of raw power exposed to the most simplistic user. Creating some of the most complex applications and logical mazes known to man.

For an example of this, we can look at the UX engineering disaster known as Office XP. Well, anything before Office 2007 / 2010. When Microsoft decided to re-engineer the interface for Office, they started with some basic research to see what people wanted / needed. They discovered something interesting. 80% (as I remember from a release conference I attended) of the abilities requested were already in the software. There was just the simple problem of no-one understanding how to access the capabilities, or they were too terrified to try. (Some people I know really were terrified they would break something, so they stuck to only the basic tasks they knew.)

To be fair, when Office XP came out, people were ecstatic about its capabilities. It was excellent for its time. But it no longer fits the bill of what is expected as far as terms of usability go. How many people can you find that have gotten used  to the changes of the new office workflow (and it is a drastic change for the better) that will voluntarily go back to the profusion of menus?

So what exactly has changed, and what incited it? I believe it was led in large part by a two-part revolution.

Part 1- The desktop RIA.

Ask any C/C++ developer. Creating desktop applications that are beautiful and easy to use is a nightmare, to put it bluntly. Prior to the introduction of things such as Adobe AIR, or Flex applications, people were left to the same nightmarish user experience with most software platforms. For example, most custom business applications looked like a dos terminal threw-up on the screen. Many user applications were the same blah. Especially if the application was data intensive.

Enter the RIA. RIA’s brought a fundamental perspective change to the concept of a data-intensive application. Especially at the Enterprise level. No longer do complex business needs require applications that take three weeks training to use. The RIA allows for a rich interface on a budget. An interface that is both beautiful (which entices users to actually USE the application) and innovative to use. An excellent example of this is the FedEx Custom Critical tracking demo presented at Adobe Max 2009. All of the information that a FedEx employee would need is directly at their fingertips. Easy access such as this system provides, enhances employee productivity and has an inherent coolness factor.

Examples such as the FedEx demo are everywhere. Look through the Adobe Air Marketplace. You would be really surprised at how many applications these days are written using technologies such as Adobe Air and Adobe Flex. Go ahead – look through your hard-drive.

Part 2 – The Mobile Revolution

I know all of this probably sounds like it has nothing to do with mobile paradigms. But it has the world to do with it. Can you imagine trying to navigate through a menu that is more than say one or two levels deep? Mobile, due to its limited screen real-estate, memory capacity, and small processing powers have forced developers on making applications significantly more intuitive and automated.

In application development, there is a concept known as N-Tier architectures. The most popular of which is the three-tier architecture. Prior to the mobile revolution this was mainly used only for web applications. An application that utilizes three tiers is an application that is separates three distinct parts of any application from each other using interfaces to link them together. The UI (User Interface) is separated from the Business Logic (the heavy processing), which is separated from the Data, such as a Database Server. This allows all of the heavy processing to be done in a known environment. Somewhere that we know is going to have the processing power to do what is needed by the application. This includes retrieving / storing data. Processing it, etc. The results are then sent back to the application which shows the data to the user. This frees the user from the desktop. It frees businesses from expensive hardware purchases for all of their employees. It enhances hardware planning so that purchases can be controlled while reducing the overall design. It also allows users to have access to everything they need regardless of their location, provided they have an internet connection.

This concept is also frequently referred to as moving “to the cloud.”

To be fair, not all applications that have taken advantage of the new paradigm are better, or even as good as their desktop counter-parts. Nor will they ever be. As with all paradigms, not everything will fit into it. Honestly we’d be stupid to try. Try putting every feature of Photoshop or any other highly complex application into an RIA, or mobile app, and you have a recipe for revolt from your engineers and customers. But subsets of commonly used features are highly appropriate for the paradigm. i.e. look at photoshop.com, or the Photoshop app on the iPhone. Can I go create amazing art from scratch? No. Can I do some pretty neat stuff to the picture I just took on my cell phone? Yes.

So why should you care?

If you write applications, you need to ask yourself how you can make your interfaces more elegant to use. Are they cluttered un-necessarily? Does it require fifteen steps to do a simple task? Your software will appreciate it. Your customers will appreciate you. Your developers may hate you at first, but once they use an application that simplifies things they will revolt when you try to go back.

If you are a customer, you should demand simplicity. Should the average application take three months to learn? Wouldn’t it be better if you could interact directly with your data? The days of complex forms and boring pages of raw data are numbered for many of us. In this enlightened age of technology we should settle for nothing short of excellence. Nothing short of usability. Nothing short of intuitiveness, and ingenuity in design.

It can be done, it is possible, but it takes work, foresight, and effort. And if we don’t do something to change along with these paradigms and concepts we will be left behind. The future is inexorably moving forward. It may not be exactly what we see before us, but it should be better. It must be better, because we must make it better.

Logical System:

Lets say I had a remote method call getDetails($params) that called a remote data service on my server, which would then do some calculations, maybe a database lookup or two, and send information back to the client. Let’s also say that I didn’t want anyone to be able to call this method, so it internally utilizes Zend_Acl to manage access control.

Symptoms:

When getDetails is called once at a time, with a gap in between calls everything works fine. You can even call it twice simultaneously, as internally Flash Player can handle two open HTTP protocols. The issue comes when you call it, say three or more times simultaneously. When this happens, the third and above call will fail due to Flash Player using what is known as a persistent HTTP connection. Now let me clarify. It will not always fail, but if you are using ACL, the initAcl function will be called with each function call, NOT each connection. That is when it fails. ACL cannot add a duplicate permission (same user, same permission group, etc.) I believe this is caused by the persistent connection, as your Zend session will remain in memory on the server since the connection was never terminated.

Solutions:

There are two feasible solutions that I see at this point. First, set an internal flag to check if the ACL has already been configured for that connection. The second option is that you can accomplish the same result, (albeit incredibly slower and more processor intensive) by wrapping every call to add to the ACL (in your initAcl function) in a try catch block. There is a third option. However, I don’t consider it highly feasible (as I don’t have a clue how to do it, but to be honest I haven’t taken the time to try to figure it out.) Change the HTTP header that Flash Player sends to be a version of HTTP that does not support persistent connections.

Conclusion:

This may be a bug, maybe its my own programming incompetence. I’m not sure. Let me know what you think in the comments.

When using the validator, there are two options that you need to consider. First, the required minimum age and secondly if that age should be computed from a specific date (say by the end of a competition or sweepstakes) or from the current date. If you do not provide a date, the current date will be used to provide verification. The date, if provided, should be in the format MM/DD/YYYY. This format requirement also applies to the date being validated. The code formatting below sucks, so download the actual file.

/**
*
* This code is provided AS-IS with no warranty of any kind, it was originally written by the
* U.S. Institute of languages for use within Visual Link Languages. They have kindly allowed
* me to post this code here. You may do whatever you want with this code, including use it in
* commercial applications, or change it provided this notice remains in the source code.
* Retrived from captaincode.wordpress.com
**/
package com.captaincode.utils
{
import mx.validators.Validator;
import mx.validators.ValidationResult;

/**
* Provide basic validation to ensure that a date given (specifically a birthdate generally) meets
* the minumum age requirements.
*
**/
public class MinimumAgeValidator extends Validator
{
/**
* Hold the results of the validation attempts.
* @var Array results
* @private
*/
private var results:Array;

return results;
}
}
}


The UIMovieClip class implements the interfaces necessary for a Flash component to be used like a normal Flex component. Therefore, a subclass of UIMovieClip can be used as a child of a Flex container or as a skin, and it can respond to events, define view states and transitions, and work with effects in the same way as can any Flex component.

I think you can see the use for that. You can develop rudimentary UI elements in flash (which it was designed for), and use them in a flex (MXML) application. In concept this is awesome, and it usually works. However, we were plagued by a seeming randomly occuring bug for quite a period of time. As with all such bugs, it’s not really random, we just hadn’t found the cause. We broke down and finally started rooting around for the cause. We eventually found it, and want to help prevent everyone else from experiencing it, or at least solve it once you do experience it.

First, the error:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.flash::UIMovieClip/removeFocusEventListeners()[E:\dev\trunk\frameworks\proje cts\flash-integration\src\mx\flash\UIMovieClip.as:2466]
at mx.flash::UIMovieClip/focusOutHandler()[E:\dev\trunk\frameworks\projects\flash- integration\src\mx\flash\UIMovieClip.as:2509]
at flash.display::Stage/set focus()
at fl.core::UIComponent/setFocus()
at fl.managers::FocusManager/setFocus()
at fl.managers::FocusManager/mouseDownHandler()

Next, the symptoms:

This error is a common one, the null object reference. Combine this with the referenced FocusManager and it is the kind of thing out of nightmares for any experienced ActionScript Developer.
We are creating basic visual assets in Flash, and some of them are using Flash components. At first we assumed this was the cause, but it turns out that it wasn’t. Frequently we would click somewhere outside the app (to loose focus) or click on another component (transfer focus) and that error would come up so often our app was useless. Even just going to the debugger would cause it.

Next, the cause:

In the end we discoverd the error. We would remove an asset that we had created in flash from the stage. This *does not* trigger the focus to be transferred. (it probably should, but it is what it is at the moment.) There in lies our problem. A component would be off stage, but the focus manager wouldn’t know that. As soon as we would interact with something else and it would attempt to transfer focus *BOOM* the error would occur. This would happen because the asset no longer had a stage from which to remove the even listeners that UIMovieClip is automatically trying to do in it’s focusOutHandler function.

Last, the workaround:

To workaround his issue isn’t incredibly complex thankfully. You just have to remember to transfer the focus to something else, such as the mxml stage, or something else before removing any flash components from the stage. Simple right? Yes, but highly frustrating when you forget to do it. Danwize, one of my co-workers filed a bug on bugs.adobe.com. You can vote, follow or, whatever, here: bug# SDK-24015.