Some goals I wanted to achieve were:

1. As little code as possible to wire up and unwire events.
2. Lean more toward convention over configuration.
3. Easy to see which events were being listened for (remotely like the delegate concept in Objective-C)
4. It’s not a goal, but I didn’t care about proper use of accessors (one drawback of Hotwire)

The source for Hotwire is 62 lines long, so you could probably clone it and analyze it quicker than I can describe it, but I’ll outline a few use cases anyway.

Usage 1: As Simple As Possible

This is as basic as it gets. You store a reference to an instance of Hotwire, which sets up at least a Event.REMOVE listener, then you call unwire(), which removes all the event listeners setup by the wire() call.

By default, Hotwire attempts to register the event with a listener with the prefix “handle” then a properly-cased version of the event name. Therefore, since Event.ENTER_FRAME is the string “enterFrame”, the listener that Hotwire will wire up is “handleEnterFrame”.

Usage 2: Listening to Other Dispatchers

In the Hotwire constructor, the first argument is the dispatcher, and is the only required argument. The second argument is the handler, and if it is not specified or null, Hotwire will consider the handler and the dispatcher the same object. In my projects, I used custom bubbled events a-plenty for child display objects, and never specified a different handler from my dispatcher until I needed to handle Stage events, which don’t bubble. (I haven’t run across another instance where I couldn’t simply use bubbled events the way I wanted to, but I’m sure I will.)

Usage 3: If you don’t like “handle”

Personally, I like the word “handle” as my handler prefix. I can type handle+Ctrl+Space and get a list of all my handlers, and it’s descriptive. I know that many people like to use “on” however. If you want to change your prefix for one instance, it’s the third argument in the constructor, as you may have noticed in the example above. If you hate “handle” just change the source code. It’s 62 lines. Don’t hate.

Finally

So that’s it. I think Hotwire might be useful if you wanted to wire / unwire groups of events easily also, just by creating separate instances of Hotwire. (Although, I might argue your class is getting too complicated?)

There are some cons to Hotwire that may make your architecture blood boil (for some reason I’ve been much less OCD about all this, so I’m just letting it roll and enjoying the short time of non-obsession):

1. Public handlers. Yeah, if you make private or protected handlers, the instance of Hotwire can’t wire them up. Well, hey. It’s a mixin-y class. Put some Baileys in your latté and discuss architecture with me when I come back to my senses.
2. Handler names derived from constants. This could be pretty bad if you are wiring up to Event.ENTER_FRAME which is currently “enterFrame” but Adobe decides to change to “zomgAppleSucks”. Yes, this might be a problem. In the remote chance this happens, :%s/handleEnterFrame/handleZomgAppleSucks/g and go back to your latté.

If you find it useful, let me know. If you have improvements, fork it. If you think it’s horrible and want to throw your latté at me, please do, I love constructive criticism and alternative perspectives. I’ll just passively-aggressively unfollow you on Twitter.

If you still aren’t clear on how to get Hotwire, even though I linked to it like a million 3 times, it’s hosted on GitHub, and you can get it here.

The impetus behind my learning is that it is an application development framework for the HTML5/JavaScript platform, versus the Flash Platform that I’m used to developing for. The key here is that it is an application development framework. It is not another DOM access library, widget set, or MVC, and it shouldn’t even be compared to them. It’s not a “Flash-killer“. It’s not even a “Flex-killer” per se, although in my mind it is an alternative in part.

Flash is just a display technology. Flex boils down to just a widget set and bindings library. Intrinsically, Flex lacks a good application development pattern. That’s partially why Seppuku is a viable alternative to maintaining the average Flex app built by someone else. There’s no built-in MVC, or unit testing strategy or IoC methodology.

I realize that Adobe’s building in support for FlexUnit4 in Flash Builder 4 / Flex 4 SDK which is wonderful. Michael Labriola et al are doing a fantastic work there that is critical for the Flex project. These necessessities have been the mother of invention with MVC frameworks like Cairgorm, Mate, FlightFramework, and HydraMVC for MVC. Lack of IoC has also inspired Mate, and Flight, as well as the excellent Swiz framework, and the DI part of HydraFramework. And, don’t even get me started on server interaction complexities.

I say all that to illustrate that the Flex development stack really fundamentally consists of Flash -> Flex (widget set, bindings, themes) -> MVC -> IoC -> Unit Testing -> Development environment (IDE, code tools, code gen) -> Support (documentation, community). I feel like that stack is essential to consistently producing good applications built using the Flex SDK, and I think other companies realize this too.

If you look at what Microsoft is doing with Silverlight, they are positioning themselves to own that stack, and not only that, but they have the advantage of not being the first in that they can fix all the things that Adobe has done wrong. It all looks really promising except for a few things, which I’ll discuss in a moment.

Let me begin by saying that contrary to popular belief, I don’t necessarily enjoy being married to Adobe and the Flash Platform. I really do embrace the ideology of an open, standards-driven web. The market has helped drive Flex because you really could deliver a richer “desktop-like experience” on the web, spawning the RIA buzzword. HTML5 and browser implementations are undeniably slower to progress than a company-owned platform like Adobe has. It was the evolution of Flash as a vector graphics rendering plugin for graphically fun and interesting content that facilitated it’s insane propagation, not it’s ability to draw text inputs and combo boxes.

Ok, back to Silverlight. First bad thing: you are locked into Microsoft. That’s a bad thing, just like being locked into Adobe is a bad thing. However, I would argue that specifically for web development, being locked into Microsoft is better than being locked into Adobe. They own the whole stack, and if you drink the MS Kool-Aid you never have to really leave Visual Studio. Also, Silverlight plays much nicer than Flash with the HTML DOM, which means you as the developer have a greater level of flexibility in how you implement Silverlight as part of your solution.

Second bad thing: you have to work in Windows. It’s not just that I really dislike working in Windows; it’s more that I dislike that I’m forced to. At least Adobe provides Windows, Mac, and (kinda) Linux support for their IDE and Player. I sincerely believe that a web development platform should be OS agnostic.

Ok, wasn’t I writing about Sproutcore? Oh yeah. I’m already way past the tl;dr threshold for most people, but there’s a lot to blab about discuss. All that background was to make the point that an application development platform is more than the display layer and widgets, and even goes beyond the language you’re using. I beleive the fundamentals of an application development platform are:

1. A prescriptive methodology: You or other developers need to be able to look at your source and not have to figure out how you’ve interpreted solutions to basic problems.
2. Consistent development workflow: You or other developers should be able to intrinsically understand how your application can be scaled or altered as it evolves.
3. MVC methodology: You or other developers should be able to intrinsically understand how your application separates concerns.
4. Data access consistency: You or other developers should strive to unify data access methodology so that applications are easier to debug regardless of server technology.
5. Unit tests: The application platform should provide a way of structuring unit tests for all aspects of the platform, including establishing Fixtures for data access logic.
6. Build tools: Scaffolding, configuration, etc. tools should minimize “monkey work” and give the developer the ability to go from thought to implementation as quickly as possible.
7. Good documentation: it goes without saying that docs should ideally help the new learner ramp up, and serve as a reference to experienced devs.
8. Helpful community: I could write an entire post about this one based on my experiences in the Ruby community, but it is critical to have mentors and people who are willing to accept that fact that you are an annoying little n00b and require hand holding like a little child as you ask questions and sound like an idiot for a few days. Also, when you are off the teet and developing like a madman, you need intelligent people to bounce ideas off of. If you go from n00b to the smartest one in the community in a week, you’ve got problems with the community.

Granted, I’ve only been evaluating Sproutcore as I’ve been finding time around regular work, holidays, and spending time with my family, but I’m definitely over the 0 – 1 level of proficiency and actually starting to build things and ask real questions, and I can say that so far, when I need to do something, it feels like Sproutcore has provided for it in a very logical way. All my personal requirements for a good framework are accounted for. I’m not going to port HydraFramework to Sproutcore, because it’s unnecessary in Sproutcore; it already has a wonderful MVC and bindings methodology. I’m not scrounging for a unit testing methodology; it also has been provided for. Skinning / theming couldn’t be easier. Build tools are great. I can develop on my 486 running Ubuntu if I wanted to. There’s always someone idling in #sproutcore who is helpful. The docs are great. It may not have achieved feature parity with the Flex development stack yet but it shows tremendous promise.

So again, the question isn’t Sproutcore vs. jQuery. In fact, you can (and probably will) use jQuery if you develop Sproutcore apps. The question really isn’t even Sproutcore vs. Flash vs. Silverlight, but it’s so easy to frame it up like that. The point of Sproutcore is that it provides the beginnings of an end-to-end application development strategy in HTML5 that competes with Adobe’s Flash Platform (Flash + Flex + Cairngorm + FlexUnit) and Silverlight’s presentation layer and tools.

There are a few additional things I want to point out. I’m not saying it’s the only way by any means. You can write an open standards desktop experience using any recipe you’d like. Maybe my point is that I feel that choosing an application development platform is more than the sum of its parts.

I have also been evaluating Cappuccino by 280 North. For all intents and purposes, it competes directly with Sproutcore, and I’m not blatantly ignoring it. However, my #1 hangup with it is the Objective-J abstraction. I understand using Objective-C for Cocoa development. I understand JavaScript for web development. But to me, I see not much more than a syntactical advantage for Cocoa developers as the point of Objective-J. For me, it makes more sense to stick with JavaScript as JavaScript. I’m going to try to keep my eye on it, especially the Atlas project.

I’d definitely be interested in hearing your experiences with Sproutcore or your own recipe for RIA *choke* or Desktop Experience type applications. I’ll also try to post more details as I continue evaluating.

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.

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.

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.

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.

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.

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.

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.

new Array();
var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

This doesn’t (outputs nulls):

var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

Any questions?

Update: Kudos to Larry (developmentastic.com) for beating his head against this brick wall on the Winestore project.