Adobe MAX. Blog #5. Day 2.

MAX, as a big brother hosts a number of small unconferences, which are located in the well equipped half-open spaces in the hallway. They have AV, comfy coaches, and are less formal gatherings of the developers. At 8:30AM I was sitting at 360MAX unconference listening to the presentation of Shashank Tiwary on communication protocols. The next hour I spent at interesting official presentation on testing with Flex by Mike Labriola.

Testing of RIA is a gray area, and pretty often is being ignored. Mike did a good job explaining objectives of different types of testing (unit, integration, functional, stress) and  reviewed  available software that works with Flex.

To attend session of interests, MAX attendees could book the sessions in advance using a hopefully-to-be-better-next-year scheduler.  Rooms  for technical sessions are large and can accommodate anywhere from 100 to 350 people. If a session is sold out but you want  to attend it anyway, you have to wait in line, and when the first class passengers compete boarding, they may let you in.

If a session is not completely booked, you can register at special workstations and re-program your badge so these old ladies armed with scanners will treat you nicely. A number of advanced sessions discussing such boring subjects as communications with the servers, data persistence and the likes were undersold, and I had a chance to easily jump in.

The second day’s keynote was also flashy and energizing.  We’ve learned about this mysterious Flash Player that Google bots use to index the content of other Web pages that include Flash content. It properly extracts  text embedded in SWF, and its virtual user can run remote calls to retrieve the application data for smarter indexing.

Various Adobe groups demoed their product that by the end of the presentation competed the jigsaw puzzle called The life cycle of RIA development – from Photoshop to Catalyst to Flex to the server side and back. Exchange between Flash Catalyst and Flex is done using a special format called FXG. To the best of my understanding, designer-developer workflow can work like this:

1. A designer creates a piece of art in CS4 using Photoshop, Illustrator or Fireworks.
2. A designer starts Flash Catalyst and imports this art. Then, he highlights various areas of this piece of art selecting Flex components to be generated for them. For example, a little birdy can become a button or a thumb on the scrollbar. The generated code is saved in FXG format.
3. A Flex/AIR developer loads into Flex Builder the FXG code that becomes MXML.  If a developer needs to return the updated code to the designer, he saves it back in the FXG format that Catalyst can read.

I hope I got it right.  In general, Flex 4 completely changes Flex skinning mechanism. If now you can  use either pre-created images or do a programmatic skinning, pretty soon you’ll start creating skins in MXML, and the level of granularity here is amazing.  In the new architecture, component needs to know its data and what is selected in case of lists. The skin is none of its business and is a separate entity.

In the evening, Adobe ran a sneak preview event, and we had a chance to peek into the future.  For example, Real Time Media Flow Protocol  (RTMFP) allows peer to peer communication between the users running Flash Players – no server is required. This protocol is built on UDP.
The demo of infinite zoom was awesome. Microsoft has introduced it earlier, but it’s ok.

Engineering departments of all major companies usually release new versions of their software at these events.  Adobe plays by the same rules and Flex developers may download the following fresh from the oven software:

1. Flex 3.2
2. LCDS 2.6.1.
3. AIR 1.5

Every attendee of MAX 2008 was offered a DVD with the pre-release Flex Builder 4 and Flash Catalyst. Interestingly enough, this pre-release is available only for the lucky Mac OS users. Your’s truly purchased his first Macbook Pro two weeks ago. When time permits,  I’ll give it a try and will offer you my unbiased opinion on the designoper-devigner workflow.

Wednesday is a closing  day of the conference. Stay tuned.

One thought on “Adobe MAX. Blog #5. Day 2.

  1. Yakov,
    You are really close with the Catalyst workflow, but Catalyst itself saves an FXP file, not FXG. FXP is a zip file that contains a Flex project that can then be shared between Flex Build and Catalyst. FXG is the XML based markup language that represents Flash Player content (rects, circles, blurs, etc). AI, PS, and FW can export their content as FXG which either Catalyst or Flex Builder can then use directly. In most cases, FXG would be handed directly from one of the supported design tools directly to the Flex developer. I believe the naming follows this pattern: FXG = FleX Graphics, FXP = FleX Project. Its really confusing, I know that during our sessions we stumbled on FXG/FXP word at least once when explaining the proposed workflow process.

    BTW – I really enjoyed your comments on the Architecture panel. Its great to hear a fellow architect who doesn’t like large framework / micro-architecture use in Flex. That is exactly how I feel and it was validating to hear others say the exact same thing I tell my clients and/or fellow developers.

Comments are closed.