The platform that drives the UI of much of the software we write has been the central focus of much heated debate surrounding performance, standards, hardware, business, money, strategy, openness, and overall web philosophy among other things.

We’re the type of folks who enjoy technology and embrace the whole web enchilada, keeping an open mind and an adventurous attitude towards technology evolution. We’ve always made it a priority to stay on the cutting edge, and to not be afraid to try new things.

That being said, our software has certainly “grown up”. We’re writing software that is used by large organizations in mission-critical implementations. We’re maintaining a large codebase of many complex interoperating parts. The more feature-rich our platform gets, the more committed we are to the technology, and that’s scary. Sure, the thought that has driven this development goes beyond implementation and is intrinsically very valuable. Still, many lines of of code have been written that directly relate to our implementation of those ideas.

I’d like to emphasize that I’m not talking about our website development, or even lighter web application development—those projects are much more nimble and allow us to be expressive and agile in our approach to the choice of technology we implement; this is about Adeptiv, our enterprise application development platform.

What is an enterprise application, and why make a distinction between that and a “non-enterprise” web app? I think the distinction is not black and white, but depends on a few key criteria, including the level of interoperability and integration in the various types of data the application manages, the required complexity of the user interfaces, the development and maintenance strategy, the deployment strategy, and the project life span.

Do I think Adobe Flash is the best platform for all web applications, all the time, forever? Of course not. Is it the “future of the web”? I would doubt that anything could be described as the “one great future of the web”. The web allows for and embraces a variety of useful front-end technologies that apply to equally varied implementation needs. Right now, Flex provides us a wealth of wonderful tools that helps us make and manage beautiful, feature-rich applications. Like any platform, it has it’s challenges and annoyances, but I still feel that it’s the right choice for Adeptiv platform today.

I went on a bit of an exploratory adventure for a few months, making thorough examination of a few strategies for application development using nascent HTML and JavaScript approaches. My goal was to take a fresh approach to the client-side of Adeptiv as if we hadn’t invested years or millions of dollars into it—as if we had to start completely from scratch. Also, very scary, but I was prepared to make an objective call. After taking this long tour, I feel like I have a very balanced and educated perspective on the state of application development, and I can say with confidence that for the types of systems we’re implementing, Flex-based applications on the Flash Platform is a solid framework for Adeptiv and I’m excited to see where we are going to push the technology.

I don’t think we have to apologize that Adeptiv runs on Flash, nor that it doesn’t work natively on iDevices. I feel that there are places in the way we implement it that need to change going forward, and we need to continue our strategy for Flex 4 migration, but overall, I have to say that Adeptiv is simply amazing—a beautiful aggregate of a very talented team.

I think that continuing to prioritize developing non-plugin-based, pure HTML, CSS, and JavaScript applications and websites is extremely important, as is developing both native and web for mobile and touch-based devices. Much of our business revolves around that type of work. However, Adeptiv in the context of our current applications and userbase, is a total win.

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.

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!

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.

Admittedly, my workaround is a total hack. However, that’s why it’s called a workaround. I’ve been using it without issues, and wanted to make it public. Click here to download a Flex project archive with the solution files. This is what it looks like:

Custom Panel / Alert Skin

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.