ArrayCollections, WebORB deserialization, .NET generics

From the “don’t-beat-your-head-against-the-same-wall” department: Here’s the original situation:

1. .NET class (MyContainerType) with a public List<MyChildType> Data { get; set; }

2. Flex has both IMyContainerType and IMyChildType and their corresponding value object classes.

3. Both deserialize properly when service method calls return either class directly, but NOT the MyChildType objects in the Data property of MyContainerType; they return as simple AS3 Objects.

The problem is that unless you refer to the class “MyChildType” somewhere in your project, the Flash runtime has no idea that the “MyChildType” exists. Typically, you’d refer to this class in a view or something, so this problem is very esoteric and you most likely won’t encounter it, but if you do, keep this in mind.

The safest thing you can do is mention the class you intend for your ArrayCollection to contain in your value object (in lieu of Flex Generics) as follows:

Ensure that the compiler includes the Class that the ArrayCollection will contain.

Immutable Strings, Arrays, Lists, and dataProviders PSA

First, click here to view a quick demo of the problem. (Source here). When the lists load, roll over one of the items labeled “something” and notice the hover behavior.

The problem is, that these Lists are bound to and Array and an ArrayCollection of Strings (which are immutable in AS3). Likewise, if multiple entries in an Array referenced the same object, the same issue would occur.

This is a particularly annoying implementation challenge, where you might commonly want to bind an Array of String to a List. This may or may not actually be a bug–well it might be, in that the requirement for uniqueness in dataProviders isn’t very well documented–but it is consistent with how Arrays work in AS3. If you have two strings in an ArrayCollection, for example, the only way to retrieve a particular value is to do so by index; you cannot call .getItem(“stringvalue”) because the collection has no idea which one you are referring to.

The workaround is either to wrap each item in a new object, such that [{label: "string value"}, {label: "string value"}] so that each object actually exists as a unique object in memory, or to wrap ArrayCollection so that it recognizes primitives and wraps them automatically.

This “bug” is being tracked here: https://bugs.adobe.com/jira/browse/SDK-17182 reported by Albert Chang.

This effect was brought to my attention by Winton De Shong.

Rawr! FlexGrowl Component Available

Want to growl in your Flex apps? Try this junk. FlexGrowl is a component that allows you to create growl-like notifications in your Flex apps. If you don’t know, Growl is an integrated notification system for OSX that listens for notifications from registered applications. It looks like this:

FlexGrowl implements this type of interface for Flex; it looks like this (click here for working demo):

However, you can customize the growl notifications to look however you’d like. The notifications shown above are created with Degrafa (which, by the way, is awesome). Click here to download the source. Let me know what you think!

HydraMVC 0.1.3 Released

…And it seems to be the magic number for now. I’ve been using this version for a while and it seems stable and complete enough to actually use f’real. If you don’t know what it is, click here to read about it and get it.

Besides all the obvious goals for HydraMVC (read about them on the website), I have a few big plans for the framework. Firstly, I’d absolutely love to get an AIR debug console written for it. I just ran across this gem today, which is pretty close to what I would like to develop for Hydra, except that instead of debugging the AS3 code per se, it would debug the application logic of the MVC by trapping the paths of Notifications as they are handled by the various actors in the MVC. Since De MonsterDebugger is open source, there’s nothing preventing me from actually augmenting it with a HydraMVC debug console. Talk about pure hotness. Anyway, with deadlines (seriously) looming, don’t look for this anytime this month. But it will happen. Mark my words.

Secondly, something that would also be wonderful if it was integrated with a debug console would be a unit testing interface. That’s all I’m gonna say. See, the beauty of it is that we could just compile out two HydraMVC SWC’s–a debug version and a production version. The debug version would provide the hooks for the debugger and the production version would bypass them. Then, when you’re ready to deploy a HydraMVC application, just switch SWC’s. I wonder if we could even make this a compiler directive for a single SWC? Hmm… Anyway, I’m super excited. This framework is not only pretty cool as-is, but represents to me a ton of realizable potential that would really provide a very accessible, learnable, structured way to develop medium to large, scalable, debuggable Flex applications. Stay tuned. Download HydraMVC and let me know what you think.

AdeptivMVC

Some really interesting things are happening at andCulture these days. In addition to rocking the CSS/HTML/jQuery/AJAX suite of technologies, we’re building libraries for Flex like never before–using Flex for both back-end application-y RIA software and also as the framework for very rich UIs that look nothing like an app.

We’ve been consuming data from .NET, both SOAP and AMF, and from PHP via AMFPHP. Jason Kichline (@jkichline) has been doing some really interesting things with building abstraction classes in a project codenamed SudzC (SOAP classes for Obj-C / iPhone).

For most (ok, basically all) of our Flex projects we use PureMVC, which is elegant, language agnostic, and quite minimal. However, it’s not without its drawbacks. Being language agnostic is nice when you want to develop for multiple platforms and not have to switch out your paradigm-parser, but not so hot when you actually want to take advantage of a platform’s stuff–like for instance, Flex’s event model. PureMVC rolls their own Observer pattern, which is really nerdy and wot not, but sometimes, you just want to use event bubbling / capture. And not have to implement Pipes.

Another interesting challenge of extracting a framework is finding the balance of modularity in encapsulation, and ease of use, so your team can actually build stuff quickly with it. For instance, we’ve got some solid application logic in our MVC, but you might want to switch out where the data actually comes from and not have to trust the developer to ensure that the Notifications are all where they need to be.

Screengrab showing basic package structure of AdeptivMVC

Our answer was kind of a crazy synthesis of a solution for each of these problems. First, we wrote a Plugin / Provider methodology for our framework, not unlike the Provider metaphor in .NET. So, our Model (Proxies) tell the data where to *go*, and *how* it interacts with the application, but Providers interact with the Proxies to actually *get* the data. Pretty nifty. Oh, and while we were at it, we kinda just rewrote PureMVC.

We’ll see if it works out. Basically, you know those times where if you have to trip over that creaky stair *one more time* you’re going to go totally ape and remodel the entire downstairs? That’s exactly what happened.

My mission was to take out all the annoying things about PureMVC and keep all the cool things. Kinda like Palm did with Pre and the iPhone.

Testing it basically involved taking an existing PMVC application and seeing A. how difficult it was to retrofit the new framework and, B. make sure it still works. So far, retrofitting the “AdeptivMVC”, as I’m calling it, is totally easy to do, and regression testing seems to prove that stuff still works.

Now, we also get the added niceties of being able to use Singleton proxies if you want, and have multiple observers in a many-to-many relationship within the app. I added a “Relay” pattern in the mix verus the Multion thing that is used in PMVC, which basically makes things a hierarchy which allows for some neat event bubbling tricks.

I’ll try to get some demos and things up, maybe work on the Adeptiv framework initiative on adeptiv.com, and maybe even have some time to sleep in between doing billable work! Afterburners, engage.

Aurora Borealis in ActionScript

This weekend I threw together an algo to generate Aurora for a holiday ecard. I was really happy with the outcome. You can see the card here.

Very Important Limitations of Generated Flex Data Classes

You will need to know this at some point if you are interacting with SOAP in Flex, I guarantee it.

ISSUE #1:

Types registered in SchemaTypeRegistry may overlap across different services.

Description:

You have a UserService and a RoleService. Methods for both services return an ArrayOfString. This type is generated by Flex when you import the service into the project. You call methods for each service simultaneously that both return an ArrayOfString. However, you get a type coercion problem. Why?

Explanation: 

When Flex imports a web service, it generates a Base{ServiceName} class. In this class, it registers types (like ArrayOfString) with a singleton called SchemaTypeRegistry when the service is instantiated. The problem is, it doesn’t qualify which ArrayOfString it’s talking about.

Therefore, when you instantiate UserService and call a method that returns ArrayOfString, the BaseUserService will map ArrayOfString to net…userservice.ArrayOfString. This works just great when you aren’t making asynchronous calls.

The problem arises when you make asynchronous calls to both UserService AND RoleService. The last service to register ArrayOfString with its corresponding ActionScript class wins. Then, when the result for the other service returns, it will try to explicitly cast a net…userservice.ArrayOfString to a net…roleservice.ArrayOfString and you will net a null result. It won’t error, because it uses the “as” keyword vs, an explicit cast (i.e. result as ArrayOfString, vs ArrayOfString(result)), which makes debugging even more mysterious.

Workarounds:

In my opinion, this is truly a bug in the framework vs a limitation. If you can make asynchronous calls, you should be able to asynchronously deserialize the results, plain and simple. However, we’ve only really found two plausible workarounds.

“Doctor, it hurts when I sit this way.”

“Then don’t sit that way.”

One workaround is to simply queue the calls. Wait until the first call returns, then instantiate the next web service and make the second call.

If you are into changing your back end to patronize the front end, you will need to make the return type unique.

Bon apetit.

 

ISSUE #2:

MyMethod can’t return an object of with the type name MyMethodResult.

Description:

If you have a ListUsers class, and you return an object of type ListUsersResult, your code will compile but your application will break.

Explanation:

Again, the problem lies in the Base{Service} generated class. The result wrapper will not generate properly if you name your result object in this manner.

Workarounds:

Again, don’t sit that way. You simply cannot append “Result” to the end of your result object if it is named the same as the method itself.

 

ISSUE #3:

Headers array gets overwritten.

Description:

You try to make a method call, but it sends an empty headers array, even after you’ve set the headers. 

Explanation:

When Flex generates the method functions abstraction classes for your service, instead of “passing along the headers” as the ASDoc would indicate, it simply creates an empty array. Can you guess where this is found. Correct! The Base{Service} class. The first line after the method signature will be “var headerArray:Array = new Array();”.

Workarounds:

We have to remember to do a global search and replace for “var headerArray:Array = new Array();” replaced with “var headerArray:Array = this.headers;” each time we regenerate the web service abstraction classes when we need to preserve headers for method calls.

 

ISSUE #4:

You can’t have a service with a method named .logout()

Description:

If you name your method “logout” (i.e. for an authentication class), your generated class won’t compile.

Explanation:

The inheritance chain for the web service abstraction classes is: MyService HAS BaseCubeReportService EXTENDS AbstractWebService EXTENDS AbstractService HAS AsyncRequest. AbstractService has a public function logout():void that calls the logout() method of it’s asyncRequest object. When Flex Builder attempts to generate the logout abstraction method in your service class, it will error as though you were trying to override this function.

Workarounds:

Again, avoid usage of “logout”.

 

I sincerely hope this saves you the hours of debugging that we invested to gain this knowledge.

In defense of AS3

As someone who has worked with Flash since FutureSplash was acquired by Macromedia, and as someone with both a design / animation and programming background, I agree with Adobe’s decision to go with a more structured implementation of ActionScript in Flash with AS3. I believe it is a strategic move to position Flash as a viable platform for true RIA development.

There’s no reason that a toolkit couldn’t be written that abstracts the API to provide some of the functionality mentioned in the article. It would streamline development for designers / animators, yet maintain the architectural integrity of AS3.

It’s undeniable that the new VM is harder, better, faster, stronger. The level of complexity of the API needed to increase to provide access to the host of new features–not only for the contemporary version of Flash, but also to elegantly scale for the future.

Consider even the nomenclature of the AS2 display object hierarchy. “MovieClip”? Think about how someone from a development background (not Flash) would approach the idea of an interface comprised of “MovieClips.” They’re not interested in frame-based animation. They don’t want to play a movie. They want to draw vector graphics on the screen. So they create a “MovieClip”? I think Adobe has done a fantastic job of maintaining cohesiveness between a logically engineered AS3 API and the legacy AS2 API that anyone who has evolved as a designer / developer with Flash would be familiar with.

I believe that AS3 allows a developer to logically approach Flash as a UI platform with some amazing capabilities. I think AS3 alone may prove to be a challenge to a designer without any programming background, but this is not unmitigable with a well-written toolkit for designers. Maybe that’s the core of what I’m saying–that you can go one way but not the other. You can abstract an API to make it easier for a designer to use, but you can’t go the other way and take an abstracted API and make it more powerful for developers.

Specifically related to Charge #6–that’s definitely biting the hand that feeds you. SOME errors are better than NO errors. I think it was incredibly cumbersome to code to AS2 for the example that was cited in the article. I agree with the verdict NOT GUILTY.

I would also like to say that I concur with the other, arguably non-AS3, issues mentioned in the article, specifically “Failure to Unload,” which has caused me much grief in the past.

My intent is not to come off as a pretentious “real Flash developer” to all you “plebeian designers” or something, nor is it to slam Colin, whom I hold in very high regard, but I hope that this provides some counter-rationale.

Ok, I re-read the article, and I have to concede that perhaps my previous comment was slightly a knee-jerk reaction. As a Flash platform evangelist, I really appreciated the architectural changes in AS3 vs AS2. By the time I got to the bottom and read the previous comments, I forgot that Colin’s “What Should ___ Do?” commentary was really well thought through and addressed both the concerns of the designer and developer.

“But despite all the talk of GPU blitting, pixel shading, and ligatures, a non-negligible percentage of the Flash community is rightfully asking: is Adobe still committed to the simple, agile authoring practices on which Flash was founded? It’s a rational enough concern. After all, Flash built its success on ‘ease of use.’”

I think it is a valid concern, but “ease of use” is relative versus the audience, purpose, and power of what is being evaluated. I agree that Flash should be easy to use, but that does not mean what it did 10 years ago.

“Or maybe the time has come for someone to make an entirely new application for building simple Flash websites and animations. Such a tool could even be written in ActionScript, and deployed as an AIR app.”

I wonder when the convergence between Desktop, AIR (runtimes), Browser, Flash Player will happen. I feel like the industry is so confused with levels of abstraction, we’re writing browsers for various OS’s, that render HTML documents, which contain Flash players, that render RIA’s, or animations or whatever, which can also be deployed in an AIR runtime, which can contain a browser, etc… Forgive my rant, but I just don’t see things working like this sustainably for very long. Ultimately, it will come down to a contiguous platform that will allow left-to-right-brained people to interact and produce content in a continuum of connected devices. The moment we have immediate high-bandwidth connectivity everywhere is the moment the game entirely changes, and it’s almost here. But I digress…

Mediator strategy in PureMVC

If you aren’t using an MVC framework like Cairngorm, Model-Glue, Guasax, or PureMVC for your Flex development, you really should think about starting. Our adoption of PureMVC at andCulture has allowed us to structure our ideas around a concrete paradigm and move on to arguing about more important things.

I’ve implemented PureMVC in both Flash and Flex projects and I’ve noticed that #3 of this post really applies. I mean really applies. As a general philosophy, I believe it’s better to start out with as few Mediators as possible, and structure them (or it) around the logical parts of the application or module—not the View Components or even their hierarchy as much. And, when the Mediator starts to become cumbersome, think about refactoring. 

For instance, for a Flash kiosk I just finished, I more-or-less had a Mediator for each VC—not entirely, but I definitely ended up with a disorganized mess of Mediators, which I affectionately refer to now as Mediator Soup. 

One of the biggest issues is state. Often elements that have their own Mediators should actually be a complex VC with a single, intelligent Mediator. Or, if that doesn’t flow architecturally, approach the VC as a separate Module or component, with it’s own MVC, and interface to it via it’s own API.

I’ve noticed that this approach allows me to think of the application in a more logical way, and seems to keep the code cleaner. I’d appreciate any thoughts or feedback on this.

Policy file changes for Flash Player 9.0.124.0 strict security

Adobe has enhanced the security policy in Flash Player 9.0.115 and 9.0.124 that may cause some issues if you’re interacting with Web Services. Typically when I start a Flex project, I just throw a simple, open crossdomain.xml file on the root of the service site (or elsewhere) and go to town (which is poor practice to leave when you deploy). 

The “come and get it” policy file typically 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>
    <allow-access-from domain="*" />
</cross-domain-policy>

 

However, we noticed that an intranet project we’ve deployed stopped working on certain computers, throwing the following error:

[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" 
faultDetail="Unable to load WSDL. If currently online, please verify the URI and/or format
of the WSDL (***YOUR WSDL ENDPOINT HERE***)"]
      at mx.rpc.wsdl::WSDLLoader/mx.rpc.wsdl:WSDLLoader::faultHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::dispatchRpcEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::faultHandler()
      at mx.rpc::Responder/fault()
      at mx.rpc::AsyncRequest/fault()
      at ::DirectHTTPMessageResponder/securityErrorHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at flash.net::URLLoader/flash.net:URLLoader::redirectEvent()

 

When you check out the XSD for policy files, you’ll notice that (among other things) they’ve added a “allow-http-request-headers-from” element. So the new “come and get it” policy file 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>
    <allow-access-from domain="*" to-ports="*" />
    <allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

 

This should allow you to consume your services from basically anywhere. Remember to lock your stuff down when you deploy.