« Day 2 at MAX | Main | Java on EC2, the Easy Way »

Day 3 at MAX

Here are my notes from the third and final day at MAX. It includes info on searchable SWFs, Google working on external media in SWFs, Cairngorm tips, new Cairngorm directions, the Marshall Plan, and Salesforce services.

Flex Framework Features to Support Large Applications

The Marshall Plan in Flex 3.2 allows an app to utilize sub applications built with different versions of Flex.

Limitations- needs full sub applications, styles aren't marshalled, resource bundless aren't marshalled, drag and drop requires extra work, mouse and key events need to be listened to differently, sub applications must load their own RSLs, need to create a different domain to use AMF, doesn't prevent different sub applications from reach into each other, and can sort of create subdomain security with a lot more limitations.

My take-away from this session was that I won't be using the Marshall Plan for any applications anytime soon. But it was still very interesting to hear more about ApplicationDomain and SecurityDomain. I thought that ApplicationDomains were very similar to Java ClassLoaders, but I now see the distinctions.

The Searchable SWF File

Previous solutions for a searchable SWF were workarounds using swf2html or attaching xml to a page. Adobe and Google have worked together to make SWFs show up in Google results.

A special version of the Flash Search Player (Ichabod) steps through visual states and gets the text. It only finds text fields that would actually be shown in the display list. Ichabod must be fast, so it executes faster than real time and doesn't render. Since it must be deterministic, there's no network access, sockets, or threads (sound). Thinking about providing a version of Icabod that's available to everyone to allow you to search SWFs yourself.

If you use SWFObject or Adobe detection kit to embed, your SWF will be found. Other Javascript embeds may not be found, but they are looking into improving this.

If you load in any external media, this currently won't be used within the SWF. But Adobe has fixed their side of this issue, and it just needs some work from Google to work correctly. It's expected that when Loader.load() is used, Google will fetch or get a cached version of the call. An example of this from the Adobe side was used with the Flex store.

What's next, in no particular order:
1. Dealing with external media, as mentioned above.
2. Deep linking. It doesn't currently deal with unique URLs for different states in a SWF, but they're trying hard to get this done.
3. Partner with Yahoo and other search engines.
4. Getting accessibility text.
5. Thinking about getting metadata from progressive download videos, especially with the work at Adobe for getting text from video.

It's possible to use Ichabod for unit tests if this player gets released. It could be extremely helpful for this, since the tests would run much quicker.

The questions at the end turned into a session on how to try to thwart the system. I'm not going to post the suggestions that came out of it, but it was pretty creative.

Building Business Applications in the Cloud with Force.com and Adobe

He listed about 40 things that you need to have to be a platform as a service- data center, disaster recovery, sharing, integration, authentication, API, workflow, monitoring, updgrades, backup, etc, etc. A good list to show all the things that you may not think about when you do a service yourself. "It's more than just imaging a server and putting it up in the cloud"

Some interesting numbers: 150M+ transactions daily with an average speed of 210ms. ~37% global deployments. Allow people to create any schema they want: 8,700,000+ schema edits. 160,000 SQL statements per second. 1.75 billion API calls per month. 28+ billion total API calls.

Created an ActionScript library for using salesforce services. They have a SWC which can be used to query salesforce.

The web services have 1 noun and 19 core verbs (and 4 verbs constitute 90% of usage). Batch based API. Architected for high volume and high velocity. They create revisions of their API and are now at the 14th generation. He says that people have integrations that have been running for 8-10 years which have barely changed at all.

Unrelated to the above, but which I heard after the Salesforce session, it that the Flex framework RSL is cached by over 50% of users in the US. I'm not sure how this was calculated, if it refers to a specific RSL, etc. But that's surprisingly high to me.

RIA Development with Cairngorm: Tips from the Experts

This started out with a general explanation of Cairngorm, which I didn't take notes on. Lots of great info like this is available on cairngormdocs.org

They showed off a refactored version of the Cairngorm Store. As part of this and in the middle of the talk, a lot of excellent suggestions were given for working with Cairngorm. Here's some of them:

1. The presentation model works well for large applications.
2. Can use the model for functions which are called from the view and dispatch events. This function can send a result handler through the event and handle the result itself (instead of setting the model directly in the command).
3. Models should be passed down to components (instead of calling ModelLocators directly). Call ModelLocator.getInstance() in the view only once! Do everything else with data binding.
4. Responders should be used used to handle service requests. It can be helpful to have a base class to implement a common fault method.
5. Anti-pattern: the fat controller. Group controllers in functions or create sub-controllers.
6. Anti-pattern: model locator landfill. The model locator should not store properties. Group properties into clases, ie presentation models.

They also informally announced the Cairngorm Committee, which will guide the future of Cairngorm. I'm happy to say that I'm on this committee.

It's "all about the timing" for when to use Cairngorm, different project structures, different patterns. It's not about doing everything up front, which can mean that business value can't be shown quickly. But it's also not good to wait too long and cause even more pain, either.

They're thinking about using inversion of control instead of ModelLocator- something for the community to think about.

They demo'd the Cairngorm Plugin which creates commands and events easily.

Comments (5)

oh man, IoC over ModelLocator... i'd love to hear more about that. and also how it could be addressed in the front controller as well.

Thanks for these write-ups, Brian. Sometimes i feel like i was there but closed off in whatever session i was sitting in.


Hey Todd, you're welcome. As for IoC, nothing more was said in the session, but I did have a separate conversation with some of the consulting people where this was mentioned. They said that they were sick of hearing "Inversion of Control" within the office, so apparently it's been talked about quite a bit. :)

Hi, I presented the talk with Peter. Great summary, thanks for attending the session. I look forward to hearing your ideas. I think the Cairngorm committee is a great step to engage the community and give real thought leaders some input.

Hi Eric, thanks for the talk- it was an excellent presentation. I look forward to collaborating with everyone on Cairngorm.


"Models should be passed down to components (instead of calling ModelLocators directly). Call ModelLocator.getInstance() in the view only once! Do everything else with data binding."

While I do like this approach, it does make it easier to accidentally update the model from the view.

i.e. 4-5 layers of ui components deep, that "model" that you passed down could easily look like any other variable.

I'm thinking one approach might be to consistently name the variable "model" or "XYZmodel" to indicate to yourself and another developers that this is the model and your view components should only be reading from it, not updating it?