It’s not that we’re unhappy with how things are done now, but with the new Flex 4 and everything associated to it, I’ve felt that there’s an opportunity to make some improvements to our workflow.

Summing it up

As presented below, there are a few conclusions to be drawn here, for example:

• Flex 4 seems to be a really nice upgrade and probably something you can’t ignore in the end.
• There’s little information on the web about development of large Flash/RIA applications (like those we do). Pretty much all focus is on Flex development of small-to-medium sized applications. I’m not to speculate on the reasons why no one is spreading the word, but hope that my work can shed some light on the area.
• There’s a lot of fuzz around the Adobe products in general and Flex in particular. Very few seem to have any criticism at all when it comes to Flex, which is a bit disturbing, as nothing that looks too good to be true ever is. But maybe I’ve just been looking at the wrong side of the web? Just a reflection…

Presentation of findings

I held an in-house presentation on my findings yesterday, and I thought I’d better share it with the world (= your favourite search engine). I’ve stripped it down a bit, as there were some company specific things in there, but most of it is free for everyone to read.

A few things to consider before jumping in, though:

• This is a PowerPoint (well, OpenOffice actually) slide with notes. There was lots said when presenting each slide, so I can’t guarantee that you’ll learn everything I said. I understand this is not perfect, but figured that it’s better to upload this than nothing.
• It’s just plain slides with notes, really. I did have some imagery in the original slides, but left it out as it’s probably only needed as “distraction” when viewed on a large screen with me talking next to it. So don’t get mad if it’s boring!
• The plan wasn’t actually to hold an in-house presentation, but I figured it was a good idea. So the format on which it is presented may or may not be optimal, as it’s pretty much been summarized as I’ve went along. It could be a good idea to shape it up and make it a bit better, but at the moment, it’s more important just getting it “out there”.

The presentation itself

With that having been said – and my back having been covered – here it is (also available as a PDF):

[gview file="http://blog.sommestad.net/wp-content/2009/10/Catching_up_with_Flex_public.pdf" width=538]

EDIT: Also added the presentation to SlideShare.

I’ve only read the docs and tried the demo out so far, but it’s a very interesting candidate for future Flex projects. It’s quite easy to separate the views and controllers from the business logic and using both MXML and ActionScript views seems to work fine. Swiz really gets the job done.

Seems better than PureMVC

I’ve tested the PureMVC framework earlier and kind of liked it, but developing with PureMVC gets quite repetitive and you produce quite a lot of boilerplate code. I like it better when the MVC framework easily guides you towards a proper structure, without having to do too much work to get there.

Also, there seem to be pretty good community activity in the Swiz Google Code project.

It seems like the best MVC framework candidate so far!

But MXML is said to improve productivity as be “easier to write” and that is a matterI’ve been delving into quite a lot over the past months. (Unfortunately “easier to write” usually comes with a bunch of unneccesary, over-the-top functionality…).

What do others say?

Recently I’ve been trying to figure out how to use MXML together with AS code. I’ve scanned the web for articles, and have found a few interesting. This one, by Dan Orlando, seemed to be on the same track as myself. Also, I’ve previously come across this one, discussing a few pros and cons of MXML.

I don’t know the answer… yet.

I haven’t really come to any conclusion yet, but I’m hoping to do so shortly. I’m sure there’s benefits from using MXML – i.e. to lay out your views – but it’ll be interesting to see how to best combine it with “regular” AS code…

This was a post in the midst of something, but more is to come on the topic, for sure!

EDIT: I’ve posted a presentation about Flex (and MXML).

No reason not to keep trying, though!

• Dive deep into Flash Player 10 and Pixel Bender, with Tom Krcha.

• New Flash Catalyst and Adobe Flex (Gumbo), with Enrique Duvos.

• Adobe Flex/LC DC Integration, with Tom Krcha.

• Case: Min Boling/My Home, with Peter Molgaard.

My main interest was the (more) in-depth demo of Flash Catalyst and Flex, which I’ve been investigating quite a lot lately (and also given some more or less harsh comments on).

Flash Catalyst strikes back!

After today, I’m more impressed with the capabilities of Flash Catalyst – at least if it’s used properly. It was nice to hear Enrique emphasize that it was intended for the View part of the application (in an MVC app). Previously, I’ve interpreted the fuzz about Flash Catalyst as a replacement for the entire MVC model (basically a replacement of regular coding), but that’s not (necessarily) the case.

If we were to use FC purely as a tool for the View Components in our applications, we could really improve our productivity massively. But to me, it stops there. I would keep away from using the different “states” in FC, i.e. to create the various views in the app. Single-view only, please!

But it’s all on a pretty much theoretical level, really, as FC is still on a very early stage in its development (seems like we’re at least a year away from first real release). But it looks interesting, to say the least!

My notes from the seminar

I put down some notes on my mobile phone during the seminar. Maybe some rambling, but hHere it goes:

• Good to use Flash Catalyst – only for isolated components? Avoid using “states” in FC?
• What are the capabilities of FXG? What’s the syntax like?
• Does FXG “skin classes” (and likes thereof) be in MXML? Can regular AS classes be used instead?
• Can FXG code be imported to Flash Catalyst?
• How can Flex and FXG be combined with regular AS classes?
• Try putting more use to SWC files?
• How are SWC files used with Flex? How are component files (binaries) managed in Flex in general?
• Would Gumbo (new Flex Builder) be interesting to use?
• Take a look at Blaze DS for data services. Using HTTP protocol. RTMF to be used when more instant feedback needed.
• Have a look at Adobe AFCS.

All in all…

• Flash Catalyst seemed a lot more interesting in a live demo and I look forward to seeing the public beta (without expecting too much…) .
• PixelBender was really cool (a lot more cooler than its docs )!
• The presented “case”, My Home,  was very cool, but perhaps a bit Big Brothery. Doesn’t feel too secure…
• A good seminar; better than expected!

What’s the deal, anyway?

I’ve been discussing the issue a lot with Peter, our team’s designer, and we’ve been trying to pin-point the most important parts of the process. Two of the main issues are:

1. being able to have short “design-implement-test” iterations when implementing new features, making changes etc.
2. maintaining a solid code base while still allowing non-developers to make changes to the interface.

Does the technology matter?

It’s hard to say which technology to use in order to meet the demands, as it depends very much on what the product really is. If it’s a game where instant and fluffy feedback is important, then we should probably make it a Flash app. If it on the other hand is more of a site, where larger sets of data are important to display in an easy-to-understand manor, then we should probably make it a HTML/AJAX app.

In our upcoming, and many of our current, projects we’re focusing a lot on the visual experience. We’re developing games. In Flash. So how can we optimize the processes with focus on Flash development?

Supporting short development iterations

In order to support short iterations, we need to make it easier for project members to change things without being hindered by their technical skills; a designer or artist shouldn’t need to have ActionScript expertise to change the colors of a button or the placement of a menu.

One way of solving this can be to use Flex with MXML. In MXML, the layout (View) can be changed using a special markup language, logically similar to HTML. Various components, such as buttons, can be positioned freely with some pretty easy-to-use tags. This is quite commonly used among developers all over the world.
Now I haven’t used MXML to any massive extent, but in my opinion, using MXML isn’t really all I want it to be. The code gets a bit ugly and somewhat hard to control.

We’ve got a great tool for this

A while ago, one of my co-workers developed our own framework where it’s possible to easily define views on an XML format. Some capabilities of the framework:

• a widget (component) class can be mapped to an SWF file, i.e. containing the art assets for a widget
• widgets can be positioned anywhere in its container, either with an absolute position or relative to any other widget
• widgets can listen to events from other widgets, in order to allow for them to communicate with each other
• a widget can consist of another XML definition to allow for better structure in the view document

It pretty much meets the demands one’s got on such a framework! An advantage (which could also be seen as a disadvantage) is that we can develop the framework further when needed, in order to add more nifty functionality.

Is this enough for us?

Anyway. Allowing the designer/artist to create widgets/components and using the widget framework for creating a layout is probably a very good way of meeting the demands of our desired work process. A couple of things that are vital:

• The View (Widgets and Layout) needs to be clearly distanced from the actual functionality in order to maintain a solid and independent code base, i.e. no functionality should reside in the Widgets or the View document.
• The widgets should be kept as small and isolated as possible, to make it as flexible as possible and avoid difficulties/conflicts in version systems.

We should try to identify if we have any further needs that aren’t met by our widget framework of today. As it’s a great system, we should really try to cling on to it and keep developing it (as we have up until today).