The Joy of Flex

Suppose you’re a small startup with a shipping product based on a substantial ActionScript codebase. Suppose your app is not just a bunch of list views with a few graphical assets, but it’s a really rich interactive tool. For example’s sake we’ll say it’s a sailboat designing app with visual water-simulating features: call it BoatWright. And suppose you’re trying to figure out your mobile strategy, which is a fancy way of asking “how do I get BoatWright on at least iPhone and Android, plus Windows Mobile, Symbian, Blackberry, and WebOS for good measure?”

As a startup with a shipping product, you’ve got a lot of constraints. The biggest is that you are already trying to do too much with not enough people, and forward momentum of the product is critical. You have to keep shipping new features to build the product out, so you can’t afford to go dark while you port your ActionScript to Objective C, Java, C++, and so on in order to make native apps. Wasn’t the Flash Player supposed to be a neutral platform?

At the same time, you’re worried about the new guy on the block who is just starting up in your space. Sure, you’re way ahead of him now, but if he starts from scratch maybe he can leapfrog you on the mobile platforms before you can figure out how to get there. Or, put another way, someone’s going to build a great sailboat designing app that runs on the iPhone, and especially on the iPad where it can take advantage of all that extra screen real estate.

What are your options? Well, you could go out and hire a mobile team. Oh, wait, you can’t do that – you’re trying to do less with more, remember? So porting or reimplementing your app on somewhere between two and six additional native platforms is a non-starter. It seems like an exciting prospect – “hey, we’re a cool mobile company now!” – but you’re not a mobile company, you’re a sailboat design software company, and there will be somewhere between two and six steep learning curves, and momentum on the shipping product will fall, and then at the end of it all you’ll have seven separate codebases to maintain, and you’ll grind to a halt. Don’t do this.

Another, more reasonable choice might be to read the tea leaves about which mobile platform is the best choice for your app, and port to just that one. This is really a big decision about what kind of company you’re going to be. Do you want to enter the wild west of Android where the most popular app is a process killer, but at least you can ship whatever you want? Or the safe warm fuzzy confines of the App Store where shipping a new version can be delayed by months while Apple repeatedly rejects your app for minor violations? And are you going to maintain two codebases, ActionScript for your browser app and Objective C or Java for your mobile app? (I’m taking the conservative route and assuming Apple is never going to permit Adobe to ship a version of Flash Player for MobileSafari.) Even maintaining two codebases is going to double the effort for each new feature, so are you going to bet it all on mobile and leave the ActionScript codebase behind? This line of thought seems scary. You want to postpone big decisions like this if you can.

But maybe porting your codebase just once would be acceptable, if the end result could run in desktop browsers and on all mobile platforms. Not to mention that porting the codebase would give you a good opportunity to refactor and generally clean up the code in the process. Suppose you could convince yourself that your app could run well in WebKit using as much of HTML5 as is generally available on both desktop and mobile browsers in the time frame of your port. Now that’s starting to sound like a strategy. You’d end up with just one codebase to maintain, it would run everywhere, and you’d no longer be constrained by the limitations of Flash. ActionScript and JavaScript are similar enough that maybe the port wouldn’t even be terribly hard. This approach seems attractive. It’s not without risk, though: you still have to go dark while you do that port, and more importantly, you have to convince yourself that you can get to the same level of performance in HTML5 with Canvas that you already have in the Flash Player. For some apps this is going to be more challenging than others. For some apps it’s not going to be feasible this year or next.

Then there’s doubling down on Flash: don’t port your code at all. On the mobile platforms where Flash Player 10.1 is coming out, redesign your app for the small screen but leave it in Flash and ActionScript. And on the iPhone and iPad, use the Packager for iPhone technology that’s coming in CS5, again redesigning your app to take advantage of the platform. This approach is not without risk either: the full Flash Player on mobile platforms is a new beast and it’s going to take a while to shake out. The Packager for iPhone is also unproven. In both scenarios it’s going to take a while before everyone is convinced that apps on those platforms will perform adequately while preserving battery life.

But the great thing about doubling down on Flash is that it postpones major life-changing decisions like porting an entire codebase, and the investment of redesigning your app for Player 10.1 on mobile and Packager for iPhone is relatively small by comparison. Even if it doesn’t work out, you’re not much worse off than you are now, and you can still try one of the more expensive and riskier strategies.

What are you waiting for?

P.S. I was a little surprised to come to the above conclusion. I don’t work for Adobe any more and even though this blog is called The Joy of Flex, I’d rather make a good strategic decision than stick blindly with Flash Player forever. So I’m happy to convince myself that with FP 10.1 and Packager for iPhone, Adobe is about to start offering a potentially great choice for developers like me.

If you missed the beta version of my talk on Architecting a Shared Codebase for Flex and AIR on Tuesday night, and you’ll be at Adobe MAX 2008 in San Francisco next week, you have another chance to see the 1.0 version of the talk.  It’s on Wednesday at 11 am in Moscone West 2006.  Sign up here.

Adobe MAX North America conference registration is now open. This year it’s going to be in San Francisco, November 16-19.

For four days in November, an amazing collection of developers, designers, and users of Adobe products are going to come together to learn and share. It’s also one of the most fun conferences around. 

Don’t miss it!

Daniel Rinehart took some detailed notes on the talk I gave to the Boston Flex Users Group on Tuesday night.  Thanks, Daniel!

Last week the entire Buzzword team joined the rest of Adobe’s U.S. technical staff at an internal event in San Jose called Tech Summit 2008. Every couple of years Adobe gets this very large group of people together as a way of fostering teamwork, collaboration, technical growth, and general knowledge about what we’re all up to. Adobe has developers in quite a few locations just in the U.S., so as a way of getting to know other people at Adobe, it really has no equal.

In addition, when the Buzzword team joined Adobe, we actually became part of a fairly large distributed team of people working on hosted services: this includes the engineering teams working on BRIO and SHARE, and lots of others besides. This team has got people working in Newton, San Francisco, San Jose, and other locations, so we’re definitely challenged to figure out the best ways to work together over distances. Adobe owns and uses (and makes!) some of the best software and hardware collaboration tools in the business, but still, nothing beats face to face.

Fortunately, the hosted services team got a chance to spend the day together on Monday, we had a fair amount of hang-out-and-work-together-with-laptops time on Friday, and there were a bunch of social/dinner/pool-hall type events in the evenings. I feel like I have really connected with folks on those teams a lot better now, so that was a win for the team as a whole.

There were some great sessions at the Tech Summit. Some of them were very directly applicable to my day to day work, but for some reason the most interesting ones were less directly applicable and more thought-provoking. I’ll try and narrow it down to three.

The most jaw-dropping talk was called “How We Hear,” given by James A. Moorer in the Digital Video Engineering group. James Moorer is, among many other things, the composer of the THX sound, also known as “Deep Note.” The talk focused primarily on the physical mechanisms inside the ear and the interesting ramifications that these mechanisms have for digital audio. He was, as far as I know, the only presenter at the conference to wear and play a banjo during his talk. He used the banjo both to illustrate specific pitches (“hmm, 1000 Hz is about here… twang!“) and to create brief musical interludes between segments of his talk. Every three minutes or so he would explain something about the ear and I would think “holy cow it does that?” After hearing this talk I came away strongly doubting that hearing was actually possible at all, the evidence of my ears to the contrary. A funny story about Deep Note: Moorer wrote Deep Note using a program, and while the overall shape of the sound was predetermined, many of the characteristics were randomly generated. He ran the program until it generated something good, then gave the sound to the THX people, who promptly lost it. When they asked to get another copy of the sound, Moorer didn’t have it any more, and he had to run the program a bunch more times to get it to put out something relatively similar to the original sound.

The most exciting talk was called “What’s So Great About Tamarin?” given by Lars Hansen, Edwin Smith, and Jeff Dyer. Tamarin is the open source version of the virtual machine that runs ActionScript in Player 9. It’s very cool in its current form, but what made this talk exciting was the future directions for Tamarin, particularly Tamarin-Tracing. Edwin Smith spent a good chunk of time explaining in some detail what tracing actually is. I have to admit I only understood about 60% of it at best, but here’s the basic idea. AVM1, the virtual machine for Flash 8, was only an interpreter. AVM2 is a JIT compiler like Java and provides a major speedup vs AVM1 at the cost of some flexibility and compatibility with existing JavaScript out on the web. But Tamarin-Tracing will be the best of both worlds: it will interpret existing JavaScript correctly, profile it on the fly, and compile the hotspots as needed. The result will be a virtual machine that is as flexible and compatible as an interpreter but as fast or faster than a JIT compiler. Tamarin will become part of Firefox 4, and going forward we should see that browser start to execute JavaScript much, much faster than it currently does. It’s interesting to ask about how this might actually level out some of the Flash Player’s competitive advantage against AJAX programming in the browser.

And the scariest talk was given by Werner Vogels, CTO of Amazon.com, who explained why Amazon.com went into the web services business with S3, EC2, and SQS. The quick answer: because they needed that level of distributed high-reliability, incrementally scalable architecture in order to build their own products. The reason the talk was scary is that it’s clear that building software that way is going to be a big challenge, but it’s definitely the future. Around here people are starting to use the term “Werner-like” to describe a distributed scalable architecture. I love it when new stuff gets under our skin that way.

Bottom line: the Tech Summit really helped me see how much Adobe values their technical staff, and how committed Adobe is to being a great software company. Plus I’m still reeling from how deep the expertise goes in the people I work with.

Technorati Tags: Adobe, Adobe Tech Summit

Here are my slides from the talk “Optimizing Flex Applications” that I gave at the 2007 Adobe MAX conference in Chicago.

What was great:

• Tom and John. These guys are off the hook. They were at their desk every time I walked by, answering questions and helping people. Their positive attitudes were totally infectious. They amazed me repeatedly with their ambition and ability to get stuff done. One quick example: they videotaped all the talks, and plan to make the videos available for download, DRM-free, in a few weeks. And they already had half of them encoded by the last day of the conference! I don’t know if they have a long term plan for world domination, or are just doing things right by instinct, but they’re doing just what I’d do if I had a five or ten year strategy to totally own the “small high-value technical conference” brand.
• Power strips and WiFi in all the conference rooms. The WiFi was spotty but it worked well enough, and better than at other conferences I’ve been at.
• Small size of conference. This whole idea of 360 attendees is pretty great. The conference feels small enough so you can get to know a lot of people, find someone in particular you’re looking for, and hold the whole thing in one regular sized hotel without having to make people hike around a lot.
• Great opportunity for new speakers. This was my first time speaking at a conference about Flex, and my first time speaking about anything in quite a few years. It was a great warm up opportunity for more talks I’m giving at MAX in Chicago in six weeks.
• Food, bar, etc. It was great to be able to get a drink at the open bar after the conference and keep talking about stuff, and the lunch lines were always short and the food good.

Room for improvement:

• There was a good variety of talks: some focused on technical information or training while others showcased a particular product (and some, like mine, crossed back and forth). Some were fairly advanced while others were for beginners. I would have liked there to be more advanced topics. Also, the 101/201/301 labels were ok, but it was hard to know exactly what that meant. In my experience the 201-labeled sessions were still pretty basic. But I applaud the effort to use the labels and I expect this will get better over time.
• There were quite a few Adobe people at the conference, but I would have liked there to be more, and I would have liked them to give more talks. I guess this is another way of saying I wish there was a lot more under-the-hood technical material. And I’ll take some blame for this myself: I had intended to cover at least three times as much Buzzword code as I actually had time for, but I think I was going just about as fast as possible.
• I’m not sure how many conference speakers knew that they had 80-minute time slots. I didn’t know myself, and many speakers seemed surprised. Some talks seemed to kind of peter out around the 60-minute mark, which gave us longer breaks, but left me wondering if there could have been more material covered.

There was a lot more to the conference than I’ve mentioned above. I didn’t even talk about the charity code jam or the parties! Overall, I’d say that this conference was well worth attending, that it’ll get steadily better over time, and that I’m definitely going to have to figure out how to convince our CEO to let me go to Milan next year!

Technorati Tags: 360Flex

Wednesday 4 pm. History is they were founded in 2005, funded by Alsop Louie in 2006, and launching in October 2007. RibbitPhone is a fully functional Flex-based phone, make and receive calls, runs on top of Flash Player 9, for the user there is nothing to download and install other than the Flash Player. Most importantly it is a component that you can develop with and insert into your own applications.

Chuck demoed the RibbitPhone component running in a browser. It has visual voicemail and looks like the iPhone in other ways too. There were a few false starts but eventually it actually worked — he called someone in the audience, then someone else called him. Cooooool.

Why a component? enables phone calls, adds calling contacts and voicemail into any Flex app. You could put a phone widget into the sidebar of your blog. You could add it to an ecommerce site like 1-800-Flowers so you could call in to place the order from your browser.

API: makeCall(), answerCall(), getMessage(), playMessage(), lookupUser(), addContact(), findContact(), getAllFolders(). Events: callConnected, callHungup, incomingCall, foldersLoaded, messageLoaded, contactAdded, contactLoaded, userFound. Distributed as a SWC with all the libraries you need. Dropping the SWC into your Flex project will include all classes you need to work with.

Ribbit is SIP-compatible, SIP proxy is at sip://sip.ribbitphone.com, Ribbit handles signal and media conversion, and firewalls and NAT issues. See developer site at developer.ribbitphone.com.

The component will be available on Sept. 3. Submit your request for an appID starting today. There will be a limited pre-release of about two dozen developers. Want to make sure that those participating will get as much attention as possible from them. Public beta release will be October 3.

Demo of RibbitPhone component integrated into TileUI.

Technorati Tags: 360Flex

Wednesday 2:30 pm. Blog is dougmccune.com. I make components.

Where do you start? Look at the Flex Framework! Thousands of lines of code. This is the most important resource for how to do Flex development. Really good code, solid standards, best practices for doing event dispatching, customization for styling, etc. In general you should try to follow that, make the code look like theirs. 243K lines of code, UIComponent alone is 8614 lines of code.

Adobe engineers are good, but they are not God. They are all just programmers like you and me. You can write better code than them. There is nothing magical in the framework. If a control doesn’t work for your UI, don’t use it, change it. Don’t settle for something bad.

Extend UIComponent: updateDisplayList(), createChildren(), measure(), commitProperties().

You can also do Sprite or MovieClip, but those are very different, they don’t go through the whole component creation, measure, etc. lifecycle. If you are doing something in an ActionScript project instead of a Flex project, you have to do it that way.

Why isn’t commitProperties() in the list of methods to override? probably it should be. Some people will do an initial implementation without a commitProperties override and then go back and optimize the component by moving things into commitProperties.

Communicating with events: for input, your components has methods and properties. For output, your component dispatches events and your component has bindable properties.

Good idea to use -keep-generated flag in the compiler and look at what code is generated when you use curly braces to set up bindings. A lot of stuff gets done for you and it’s a good way to understand it.

For styles, you should not rely on them being set. Follow the practice in the framework source and create public static consts for the default values, and use the static consts if the getStyle() call doesn’t return a value. All the classes in the framework have default styles in defaults.css.

Use the [mixin] metatag to a class and implement a static init() method, and the init() method will get called by the SystemManager when the SWF loads.

90% of Doug’s component development is overriding the framework. Don’t reinvent the wheel, just make it rounder. Take advantage of those 243K lines of code in the framework.

When the framework won’t play nice (private variables or methods), copy and paste the framework source, change private to protected, override the new class. This makes it easier to diff and merge your changes with the changes that come in the next drop of the framework.

“Underriding”. Say I don’t want to make my own component, I just want to implement it at the UIComponent level and have it affect all subclasses. You can do this. You probably shouldn’t because it might cause terrible unexpected problems, but you can do cool things with it if you dare and are willing to accept the consequences. You can implement a class called mx.core.UIComponent and it will bring in that class before the framework. Called “monkey patching” in other languages.

Demoed adding drag resize handles to every UIComponent subclass using this technique. It really works! Yikes.

Technorati Tags: 360Flex

Wednesday 10 am. He is what is commonly known as a “devigner” but he hates the term. He prefers the term “designgineer.” He came to the Flash community about 9 years ago as a tweener. Slowly but surely gravitated to ActionScript, doing some Flex stuff, and so on. Want to concentrate on code and walk through how the hell he did all this stuff.

Sometimes he uses Flex Builder, sometimes he usex TextMate. It can take two or three miutes to build a big monolithic project in Flex Builder, so I package things to separate folders and have separate build systems to do that.

It’s a small core, and everything else is a plugin. The menus are a plugin, the view is a plugin. As dvelopers you can extend the product, create your own perspectives, and so on. I’m going to import the PaperVision3 library. It has parsed all the Papervision classes and created models for all of them.

He tried to keep Saffron to the UML spec as much as he could visually, but the UML spec was created by developers, not designers, so he tried to make it prettier. When trying to figure out how to organize the packages visually, he decided to tile them. Trying to figure out whether to do envelopes or not. Do people want them? He is working on a tree explorer to inspect all your packages. Maybe that is sufficient.

He is only doing an AIR version for now. Thinking about what a browser version might do but not right now. All 360Flex attendees are getting an alpha invite, but after Sept 1 there will be regular builds.

To improve performance he is only putting what’s visible on the display list, and removing objects when they go out of view.

Amazingly, a lot of the objects inside the main view are not Flex components but Flash components built in Flash Professional and brought into Flex. He hates to skin with typing, likes to draw. He is using Elemental, a Flash class library, for a lot of this. Elemental separates visual code from interaction code. You can draw anything you want, pass an instance of that class, Elemental will inspect the class, figure out where to hook into.

Saffron Application Manager. This is the main Saffron class. He’s not using Cairngorm, partly because he doesn’t like to type that much, but partly because he took what he liked from Cairngorm and threw away the rest. He’s using a Command pattern but that’s pretty much it.

As a habit, he always hangs onto objects, never just creates them and leaves them around to be GC’ed, always assigns them to class variables and nulls them out as soon as possible. Makes things more predictable.

Trying to access Flash objects from Flex is incredibly painful. Challenge is that Flash does not have native support for AIR. The Saffron window manager has a property called associatedClass that is a Flex class that gets bound to that CS3 class. This is something the Saffron API does for you. The net result is that it makes it easier to integrate Flash and Flex.

He is using a “signals and slots” pattern from QT, rather than the traditional event model that Flex provides. He is basically translating between the two models so that he can use signals and slots internally.

He’s talking about how he parses ActionScript 3. He had to dust off the dragon book for a quick compiler refresher course. He’s also working on parsing MXML, but not yet. He’s using the built-in regular expression support in AS3. It’s pretty fast for the most part, but look ahead negation is very very slow so he has to use a divide and conquer algorithm to work around that. He tests against the Flex Framework SDK since it has a lot of different coding styles and is a good stress test of memory consumption.

Technorati Tags: 360Flex