If you’ve got some ActionScript and Flex experience and you want to learn to use Robotlegs to build more maintainable apps, or if you’ve wanted to get started with Robotlegs but haven’t been able to get your head around it quite yet, then this session is definitely for you.

Since it’s a training session, I’m going to talk a bit about the concepts and theory of Robotlegs, but mostly we’re going to be walking through building an app using the Robotlegs MVCS implementation — the “standard” Robotlegs implementation. We’ll work through several examples of common app “tasks.” We’ll use several of the common “variations” of MVCS that are used in various sample applications, blogs, and the real world, and talk about the benefits and downsides of them. I’ve got a big list of common new-user misconceptions and problems that I’m working in to the presentation. Finally, time permitting, I’m hoping to spend some time covering how to use Signals in combination with Robotlegs, since I know that’s a combination that many people are interested in.

So, if you haven’t registered for 360|Flex yet, there’s no better time than the present. It’s always a great show, and many of my best experiences with the Flex/ActionScript/AIR developer community are linked to a 360|Flex conference. So, what are you waiting for — go sign up right now!

In case you’re curious about my experience with Robotlegs, here’s a little background on my history with the framework. I started following Robotlegs closely last fall, and started building my first apps with it in February. In March I was very fortunate to be able to collaborate with Joel Hooks as he prepared his Robotlegs training session for the previous 360|Flex — I learned a ton from that experience. Since then, I’ve been working full time developing apps using Robotlegs, so I’ve gotten lots of real-world experience with the framework. In addition, I’ve been following the Robotlegs knowledge base/question forum pretty much since it started, (lately I’ve even been contributing answers =) so I’ve gotten a good view of the common questions and problems that people run into while getting started and working with Robotlegs.

It turns out that my thinking on that topic isn’t going to become anything in the Adobe documentation. So I’ve sort of just been sitting on my ideas with the idea that someday I’ll probably share them.

Which brings me to this post.

Aside: upcoming presentations on multi-screen development

This is really a side note to the main ideas here, but I thought I’d mention it since it’s the reason I actually stopped to write this. In one of my mind-wandering moments this morning, I realized that at the upcoming 360|Flex conference (San Jose, March 7-10) I’ll be involved in two presentations that are directly related to practical aspects of building multi-screen apps:

• As part of the pre-conference free training, Joel Hooks and I are doing a four-hour training on using the Robotlegs micro-architecture. (Joel is the main speaker, fortunately, because he’s one of the core Robotlegs developers and the main “evangelist.” I’ll be helping out, to try and help save his voice and maybe to help find typos. =)

  If you’re wondering what a Robotlegs session has to do with multi-screen apps…keep reading, it’s explained below.

• On Tuesday and Wednesday, Renaun Erickson and I are giving (two separate) presentations about building iPhone apps using Flash Platform tools. My session is more of an intro into the workflow, how it’s similar to other app building, and how it’s different. (Plenty of code to look at — don’t worry!) Renaun is going to get more into specifics of building a game, as well as some more intermediate/advanced topics like performance.

Funny that I never really made that connection until this morning. I guess subconsciously I knew this is a direction I want to move in, and that’s why I’ve been focusing my learning (and hence my presenting) on these topics =)

Background

While I was partially trying to keep my thinking abstract, from a practical perspective I centered my thoughts around developing using the Flash Platform. So conceptually, what I was thinking about was the idea of making a single “app” for multiple screens, which would mean that (in the technology of the next year or so) it could be potentially take several forms:

• a browser/computer app (Flash Player)
• a browser/mobile app (Flash Player)
• a desktop app (AIR)
• a mobile (iPhone) app (Publisher for iPhone, similar to AIR)
• a mobile app for other devices (AIR)
• a TV app or widget (Flash for the digital home)

(Obviously many of these are only out in public beta, some have only been vaguely publicly acknowledged, and others may or may not ever exist as actual Adobe products =)

One app, or many?

Back when I started thinking about this, there seemed to be two main camps. One group was a strong advocate for the “single source” idea: you would build one SWF or one AIR app and distribute that same app on any platforms (desktop/mobile/TV). Obviously a key element to that, especially for desktop/mobile apps rather than browser apps, would be having code that detects screen size and device capabilities and adapts the UI to the device.

The second group felt that it was more likely that developers who are creating an app for multiple screens would actually create multiple apps (from the perspective of the IDE). The apps would obviously share some code, visual assets, etc., but would be different enough that they’d be created separately and distributed as separate file types. (In the case of apps created for the iPhone, of necessity this has to be true, at least in terms of the publishing part.)

Since I try to be pragmatic about things unless I have a really good reason, I favored the second viewpoint. However, I acknowledge that in some circumstances the first approach might be used. As always, I think that developers are going to use a mix of approaches.

For example, suppose I’m building an app and I want to create a version for desktop computers, a version for the iPhone, and a version for other mobile devices. Personally I see this not just as an issue of “porting” the app from one platform to another. I think that each device has its strengths, and more importantly, each device is used for different purposes and in different contexts. If I’m building an app for a device, I should definitely be taking that notion of context into account as I’m designing the app. That pretty much rules out the possibility of using the exact same app (UI and everything) for both computers and mobile devices, unless I want it to run as a widget-type app on the desktop.

Also see: Adobe Flash Platform contextual applications developer center

Adaptable code to the rescue

On the other hand, that doesn’t mean that developers will always create completely separate projects. For example, suppose I’m creating an app for iPhone, and another for another mobile device. Or perhaps I’m using the Publisher for iPhone to create an iPhone version of my app and an iPad version. If my app is a game where I can more freely discard the conventions of the platforms, perhaps the only platform difference I need to consider is the difference in screen dimensions and pixel density. In that case, it’s quite possible that I can .

Even for a more line-of-business or productivity app, one of the key ideas in Slider, the future Flex mobile framework, is to (as much as possible) abstract away platform convention differences. For example, if iPhone usually puts the back button on the top, and another platform puts it on the bottom, and another platform puts it in a menu, and another platform has it assigned to a physical button on the device, then Slider might have a “back” event that you can hook into, and you can make your app perform the necessary “back” tasks regardless of platform.

Design patterns to the rescue

And, of course, in some situations you’ll almost surely need to create different versions of apps for different screens. For example, suppose you’re building a desktop Twitter client and a mobile Twitter client. Chances are good you’ll put some functionality into the desktop version that doesn’t go into the mobile one — such as previewing images, or maybe Facebook integration. On the other hand, adding a feature like automatic location tagging would make lots of sense in the mobile version, but not so much in the desktop one.

As I was thinking, many months ago, about the idea of efficiently creating different versions of the same app for different devices, a thought hit me like a ton of bricks. This is exactly the use case that the oft-mentioned “separation of concerns” is designed for:

Over several years, various “micro architectures” and “application frameworks” have emerged and waxed and waned in popularity. Many of these architectures are modeled around the “Model-View-Controller” design pattern (or its many variations).

One of the key benefits that these architectures claim is that it helps you keep the pieces of your application separate, without explicit links and dependencies between them. I’ve looked into and even tried out several of these over the years. One example that is frequently used to describe the notion of separation of concerns, which I always struggled with, goes something like this:

Suppose you’re creating an app, and you build the user interface and the other logic like server communication and data processing. If you use MVC/separation of concerns, then it’s really easy to just rip out your whole user interface layer and replace it with a new one.

They usually lost me with that one. As much as I tried, I couldn’t imagine a situation in which I’d want to build my app and then just rip out the UI and replace it with a different one note 1.

Until now.

Suddenly I had discovered, for myself at least, a real-world use case for the separation-of-concerns-so-you-can-swap-out-the-UI argument. If I’m building an app for the desktop and mobile, I’d like to be able to reuse my code where I can. At the same time, some functionality is only going to apply to one app or the other, so it’d be nice to be able to plug it in cleanly. Oh and by the way, the user interfaces are going to be different, so being able to swap those out is an absolute must.

I’d always liked micro-architectures in general, if only because I like knowing that I’m building my app using some pattern or structure that is based on developers’ real-world experience. It’s much nicer than trying to invent it myself and having to deal with all the pain points they’ve already gotten over. Now that I am imagining a world where I create multiple versions of the same app, with similar functionality but different user interfaces, suddenly micro-architecture patterns have become indispensable in my mind.

Conclusion

These are only just a few of my thoughts about the future world of multi-screen, contextual applications. Like Lee Brimelow, I believe that going forward building multi-screen, multi-context apps is going to be a much more common scenario. From my perspective as someone who thinks a lot about user experience design, and trying to optimize tools for the task and context, I think this is one of the most exciting aspects of the current technology revolution. I’ll definitely continue to share my thoughts and ideas in the future (hopefully more practical ones, too, not just abstract ones like this =)

Notes

Note 1: Just to be clear, I’m not trying to sound negative about MVC or micro-architectures/frameworks. Most of them provide many benefits, many of which are also related to the idea of separation of concerns, such as making code easier to test, making code cleaner, reducing boilerplate code, providing structure so that teams or developers who inherit a project can get going more quickly, etc. Swapping out the view layer is just one little benefit they mention. (back)

• FlexUnit 4. Wow. Big update. Very nice new features. Time to get (back) into it. (presentation by Michael Labriola)
• Renaun Erickson’s Structured Log Testing framework. Another great, unexpected surprise. I didn’t really have plans to go to this session except that Renaun’s such a smart, friendly guy. And frankly, I’ve never really had enough interest to take a look at his work on this project so far. Boy am I glad I changed my mind. This is definitely a testing approach I can get into — much less overhead than other approaches I’ve seen. Getting going with it is only barely more work than adding trace() calls. And the result is certainly infinitely more valuable.

Considering I didn’t come to Indianapolis with any real interest in hearing more about testing…I’m surprised to find myself so excited by what I saw today. Today is a great day for Flex testing, that’s for sure.

I also got to hear some interesting ideas and future plans from Jacob Wright and Tyler Wright. (They made me a bit jealous — I wish I had a Flex programmer brother that I could see at conferences.) If you’re in Indianapolis, I recommend checking out their “write-in” session on the Flight Framework at 10am Tuesday in the Illinois East room.

Other less code-centric, but interesting, tidbits:

• Joe Berkovitz is an avid mountain biker.
• Ben Stucki has a sweet five-year-old daughter who likes deep-fried calamari and pasta, although she wasn’t able to finish her macaroni and cheese at Buca di Beppo, where apparently even the child meals are sized to feed 3-4 people.

As I mentioned briefly before, this week I presented at the 360|Flex San Jose (August 2008) conference. My presentation was titled “Adobe AIR SQLite: An optimization conversation.” As I mentioned in the presentation, the term “optimization” could mean a few different things — for example, optimization meaning improving performance, or optimization meaning improving developer productivity. While my presentation focused mostly on the first type of optimization, I included suggestions for tools, libraries, and strategies that fall in the “developer productivity” type of optimization as well.

Anyway, as always I’m happy to make my presentation materials available. Here are the slides (with some notes) from my presentation:

“Adobe AIR SQLite: An optimization conversation” slides (PDF in .zip - 504kb)

I don’t really have any specific code examples, apart from what’s in the slides, so there’s no “source code” download. However, I did link to a lot of external tools and resources (including a few of my own). To save you the trouble of digging into the PDF, here are the links:

Tools

• Cristophe Coenraets’ “SQLite Admin”
• My tool for testing queries
• “Lita” by David Deraedt (I learned about this one after the presentation, so it’s not discussed in my slides/video, but I thought it’d be worth mentioning anyway.)

Application architecture/patterns/libraries

• SQLite MXML wrapper classes (Peter Elst)
• Data access layer (Brandon Ellis)
• asqlib SQL statement generator (Miran Loncaric)
• “Command” classes (me) as demonstrated by my AddressBook sample application
• AIR ActiveRecord source and blog post explaining its usage (Jacob Wright)
• AIR SQLite Cairngorm services (Eric Feminella)
• Connection and statement pools, mentioned (with source code) in the article User experience considerations with SQLite operations (Daniel Rinehart)

Finally, as you may have heard, Adobe sponsored the recording of every presentation at 360|Flex, and they’re all going to be made available free of charge via a channel in Adobe Media Player. They’re rolling them out in phases, and mine isn’t available yet. When it is, I’ll update this post with the video as well. Update: the video is now available on Ted Patrick’s blog as well as in Adobe Media Player.

In the mean time, 360|Flex was full of awesome presentations. I wasn’t able to get to all the ones I wanted to see, due to conflicts and me trying to finish up preparation for my presentation. So I’m going to be spending some time watching many of those videos as well. If you’d like to see the videos, Ted Patrick has posted instructions on his blog:

How to view 360|Flex San Jose 8/08 session videos in Adobe Media Player

My conclusion (not original by any means) was that unit testing is an important tool for ActionScript developers. I’ve tried a couple of ActionScript unit testing frameworks (ASUnit and FlexUnit). And finally getting to the point of this post, I was interested to learn today that the crew at Digital Primates is releasing an open source unit testing framework for Flex, known as “dpunit”.

(via Jesse Warden via Twitter)

And what nice details they are!

Here are a few highlights that stood out to me:

Flex applications however have gained a reputation for looking too similar to each other, as many developers choose to use the Flex default look and feel (known as Halo)…we have found that it remains too challenging to create a truly custom experience. It is therefore a priority for Gumbo to make easy customization of Flex application experiences the norm instead of the exception.

Major features…component and skinning architecture…make it easier to describe experience-oriented features such as states and transitions

Perhaps the most revealing part for existing Flex devs is the aptly named “Caveats and Reassurances” section:

Gumbo will remain compatible with Flex 3…Over multiple releases post-Gumbo we expect to deprecate the Halo model…Halo and new Gumbo components can co-exist…new MXML features may require some changes to your existing markup. However, you can make these decisions on a file-by-file basis

But my favorite line of all is in the “Related Work” section:

Provide a tool in which design-oriented users can easily customize the look of individual components or entire applications. Yes, this is Thermo. We’re not discussing it here.

Of course, this is all fairly in line with what’s been talked about previously, such as Thermo, MXML-G, Ely’s presentation about a new component structure with separation of model and view, etc. But it’s nice to see more information…and what’s not there but is hinted at is even more tantalizing.

I’ll definitely be watching that page for more information about “Design in Mind” and the other Flex 4 themes.

(via email from Matt Chotin — also see the announcement on the Flex team blog)

I found a couple of posts that were very interesting from a different perspective than just the “hey free web hosting” angle, that I wanted to save/share:

• Alec Saunders discusses Google App Engine as an example of the competition between Microsoft and Google, and why Google “gets it” but Microsoft doesn’t.
• Jacob Brunson thinks this is an example of Google “changing the world” — an innovative idea coming from inside Google rather than being bought by them.

And one more link that is a coding-focused one, but I wanted to save it anyway. =)

• Ronald Schouten has a great list of resources for learning Python and Django (Python being the language you must use with Google Apps Engine, and Django being one of the most popular Python frameworks for web apps).

Here are the direct links:

• Grant Straker on Moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes on Flex application frameworks (A great overview of the strengths and weaknesses of various frameworks like Cairngorm etc., from two really smart developers.)

Enjoy!

(via email from SilvaFUG)

If you’re interested in a summary of the talks, I’m afraid I didn’t do that. (But I highly recommend viewing the presentations:

• Grant Strake on moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes comparing various Flex application frameworks

What I’ve written here is primarily just thoughts that I wanted to save for myself; things that maybe I don’t think about as often as I should, or things I want to remember about the audience of Flex and other Adobe developer products. Because I’m interested in the developer community, much of the focus is on points about the developer community that I sometimes need to remind myself of.

Grant Straker

The first speaker was Grant Straker, talking about his company’s choice to use a homegrown framework, and eventual decision to migrate it to Cairngorm instead. His company (Straker Interactive) has a RAD product (“ZoomFlex,” I believe it’s called) that bundles ColdFusion and Flex to create apps quickly — you use wizards to define data structures, and the product generates database structure, backend ColdFusion, and front-end Flex code for apps using that data. (The idea is that developers then take those Flex files and customize the front-end forms, style the app, etc.)

Here are some interesting thoughts/points I picked up:

• Originally they chose not to use Cairngorm for the underlying framework for their generated code. The reason: while there are some developers who build big, fancy, complex enterprise apps, there’s also a group of developers who “just want to know what they need to know to get their job done” — which often means build basic CRUD apps as quickly and easily as possible (e.g. web-enabling existing databases, spreadsheets, etc.). This latter group was/is more in their target audience.
• Code can be written in different ways — they try to generate code so that it’s clear and obvious what it does, and so that it can be easily extended by developers of varying levels of experience (key: don’t assume a high level of experience).
• In retrospect, he wishes they had just stuck with Cairngorm in the beginning. Now, 1.5 years later, there’s a large community, examples, documentation, etc. making it easier for a less-experienced developer to learn enough Cairngorm that they can understand it and use it.
• I was really amazed by how much code they are able to generate for developers. I’ve read some things about code generation tools, but I’ve never tried them out (due to the organizations I’ve worked for, and perhaps due to my personality as a developer who likes to have “control” of the code). However, I’ve definitely seen the down side of that, which is that I end up writing a lot of redundant or very similar code (especially for data access and manipulation). The “alternative” approach certainly has some attractions…
• Part of what they include is a library of pre-built UI components. The process of migrating these components to Cairngorm has been challenging at times. One of the principles of many frameworks including Cairngorm is that the user interface code is separate from the “model” (the underlying data). However, some components by nature lend themselves to having knowledge of their underlying data (e.g. their video player component) so figuring out how to structure those components is complicated.

Luke Bayes and Ali Mills - Evaluating application frameworks for Flex

Luke and Ali came into this presentation with no background in any of the major frameworks (other than the Flex framework). This is good because they didn’t have any biases, but it means they may have some non-best-practices too.

This was a great talk, but there was a lot of info in a short time so again, I’m not going to bother trying to write detailed notes. I highly recommend watching the recording.

However, once again in this presentation (in particular in the discussion afterwards) some of the same ideas came up. Luke in particular expressed a reluctance to have a prescriptive framework, because he doesn’t want to be “told how to code.” That opinion resonated with most of the audience there — but at the same time, everyone also acknowledged that the audience at a user’s group presentation isn’t really an accurate representation of the broad Flex developer community (especially the even broader community of developers who are considering Flex or who will be Flex developers in the future). If the Flex community is going to continue to grow, and be more accessible to new developers, it would be very helpful to have some prescriptive application frameworks that give people a predefined, standard architecture within which they can build their app (in the same way that Flex’s components provide user interface elements and layout elements that give developers a big head-start in building an app, compared to straight ActionScript or Flash).

What is the “next frontier” of Flex developers? Is it the “VB developer”1 (the “behind-the-firewall” corporate developer). If so, then to support that group of developers we’re going to need prescriptive frameworks that are easy to get into (“accessible” in Luke and Ali’s terms), that do as much work for you as they can, but that still don’t get in the way as an app grows in complexity.

At the same time, more advanced Flex developers may not want such a framework, and they certainly aren’t going to want to have to carry along the “baggage” (meaning both prescriptive architecture imposed on them, and literal baggage in download size) that would come along with such a framework if they’re not using it.

Personally, I think that’s an extremely important point for both Adobe and third-party framework developers to keep in mind going into the future.

“VB Developer” is my name for a developer who works in a medium-large corporation or organization, perhaps coding apps for a group within that organization, who doesn’t really want to learn everything there is to know about Flex (or their language of choice), or become a “guru,” but rather just wants to build their app and make it work nicely, but do so as quickly and painlessly as possible. Yes, the name “VB developer” is rather dated, since at this stage in history most such developers are doing web-based apps, probably using ASP.NET or J2EE in a large, standardized org or perhaps PHP or Ruby in a smaller or more independent group.