Ted Patrick > { Events & Community } > Adobe Systems

I am having this inner dilemma about AMF vs XML. For a long time (5 years), I have preferred using AMF over XML. It results in lower over-the-wire bandwidth, faster data serialization/parsing, and you get real class instances in AMF3 when using the full spec (See: Flex Data Services and ColdFusion). Then E4X was added into Flash Player 9 and now I am gradually leaning towards XML for several key use cases:

(New to Flex? Some simple facts first:
1. Flash Player has an XML Parser in it.
2. Flash Player can load XML directly over HTTP/HTTPS.
3. Nothing special is required server side.
4. The XML class implements the E4X (ECMAScript for XML) syntax. Think... readable and writable XPath yet much simpler and tons more fun.
)

Integration with REST
REST API's are blooming everywhere and SOAP seems to be fading rapidly as a client integration format. REST is easy, readable, easy to understand, and best of all it is port 80 friendly.

Queryability
E4X makes client side data easy to query. It is one thing to get an object, it is another to get an object and easily query the data interactively.

Here are a few:

In the loaded XML object named myE4XObj:

Give me elements named 'student' off the root?
myE4XObj.student

Give me 'student' nodes anywhere that have a 'name' attribute?
myE4XObj..student(@name)

Give me 'student' nodes anywhere that a 3.0 or higher grade point average?
myE4XObj..student(@average >= 3)

Now for pure remoting, well that is an AMF thing, for loading models or leaving the result client side queryable, XML with E4X takes the cake. I should note that you can pass XML objects within AMF3 so they remain queryable client side as well, shoot with AMF3 you can pass binary images and SWF files around too.

The problem with AMF is that the secret sauce and recipe are bottled up at Adobe. Although there are many AMF clones out there, they vary wildly in support for the deeper object types in AMF3 binary. They all sort of taste like New Coke or Generic Cola, it tastes similar but something is missing, it is just not the real thing.

What is interesting to me is the fact that AMF is easily 10X faster and lighter than SOAP Web Services for server to server and server to client operations. We have all this server iron out there wasting bandwidth and CPU time parsing XML when they could natively serialize objects with less memory and less bandwidth. AMF3 is a perfect spec for it but we need clients and servers for AMF in many languages first. Currently the AMF format is a transmitter/receiver that can only talk to Flash Player and that needs to change.

I am not sure what 2007 will hold but know that I am lobbying for an open AMF spec in 2007 with server and client implementations for Java/C/CSharp. We need to open up AMF and let it breath. It is really great technology that would enable a wide array of companies leverage efficient data transfer and enjoy native Flash Player data exchange.

2007 is going to be a great year for Flex/Flash/Flash Player/Apollo.

Happy New Year!

Ted :)

Patrick Mineault asked why I was writing IFBIN in Apollo and not as a website. There are many reasons but my employer is NOT one of them. Truth be told the original IFBIN plan was to ship on Central 1.5 but given its "developer release" status, things didn't happen there. Lets dive into the issue:

1. Installed vs URL - There is a lot of value in being installed on the desktop. URLS are hard to remember for regular folks (even advanced folks). Plus with over 200 bookmarks, I struggle to locate a site I found before. Being an icon on the desktop is more valuable than being a website. Many key services will move towards Apollo to enjoy this exclusivity. Plus as Apollo has a browser you can control the experience, yet integrate easily with all things web.

2. Browser is a tiny sandbox - The web browser is a very restrictive sandbox. Why cater to incompatible browser quirks, when your app can become the browser? Apollo lets you control the entire user experience and deliver functionality that websites cannot.

2. FileIO - IFBIN 1.0 made installing secure file systems as easy as 1 click cross platform. If we used a browser, here are the features that would go away:

a. 1-Click - Make installing files easy, do not make me think! I want IFBIN to work for everyone, not a limited market who knows SVN/CVS/ZIP.

b. File Verification - IFBIN can verify if every byte in a file is authentic and genuine. If the file contents have been tampered with, the file will not install. This protects end users and is especially valuable when end users are uploading content into IFBIN.

c. IFBIN Secret Feature #1 - There is a killer feature that can only be delivered leveraging FileIO in Apollo. It makes the web more readable and writable. :)

3. Scalability - With UI and logic moving into Apollo on the client side, the server side gets simpler and more scalable. Having to send the presentation layer over and over and over and over is silly. It is a waste of bandwidth and server resources that are better handled within the client. I am concerned about scalability with IFBIN server-side and leveraging an intelligent client makes things much simpler, more scalable, and more configurable.

Take the file upload functionality: The user selects a directory to upload, enters meta-data about the file system, and the IFBIN 2.0 Apollo app prepares a binary file to upload that is highly optimized. The file is uploaded to the server where the file is processed into the backend including source search indexing, category publishing, tag processing, and updating a developer profile. The file is then one approval away from being published. Scalability here also applies to my time, I do not have tons of time to manage IFBIN, so the system needs to be 99.99% automated and distributed.

4. Context - IFBIN 2.0 knows what the user has installed, searched, and viewed. The service can notify the user about new versions, similar content, and search for similar files (same author, same class, etc).

5. Partnership - IFBIN is going to work on a partner model to monetize operations. Partnership on the web today is distractive in nature and content sites typically must hand users to another site. As Apollo contains a browser, IFBIN 2.0 can provide a more controlled partnership model in context. Think sponsored bookstore within IFBIN, category sponsorship, and special offers in context with the service.

6. Offline - IFBIN installation files are cached so a user can re-install without a network connection. Typically with examples developer tinker with code to see what will happen. This type of discovery is at the heart of IFBIN in terms of value. If you want to get things back to the starting state, you are 1 click away even if your are on an airplane.

7. 1000's of HTML pages vs. 1 SWF + API - I think that SWF + API is the right model. It allows me to rapidly change the entire application at once without modifying the server at all. This is 1000 times more scalable than most web production. Also you gain the benefits of having an API for 3rd party integration/syndication without doing anything special. I know many would disagree with me here, but that is my opinion. Leveraging that same model in Apollo is the right call.

8. Persistence - Apollo can persist and cache data on the client side. With client persistence the server-side becomes even simpler. Sessions in Apollo can maintain state far longer than the browser. With IFBIN 2.0, why would you need to login or logout? When client storage becomes rich, many of the key pillars of web technology fall apart. My choice in leveraging TurboGears/CherryPy is the low level control over HTTP, productive development of the XML API, and leveraging ORM mapping in SQLObject. Cookies, Sessions, HTML, Javascript, CSS, AJAX will go unused in IFBIN 2.0 because I am not sending the presentation layer over HTTP and I can persist client data intelligently.

9. Compatibility - Apollo apps run compatibly cross platform. In choosing Apollo, I assure support on Windows, OSX, Linux from the same file! In choosing Apollo I choose the widest possible market for IFBIN. IFBIN 2.0 can provide a dramatically better experience without limiting customer base.

10. Installation - The install process for IFBIN 2.0 and the Apollo Runtime is 1 click. It is so easy, that both my mother and father can do it. I typically rate them a 1 in 10 on a technical scale. Actually installing IFBIN 1.1 today is much harder.

Patrick, I guess in a way I am biased towards this model of development given my experience and job at Adobe. But then again I was biased long before working at Adobe and I know this is the right model to make IFBIN a success. The failure of IFBIN was more personal/business than technical, no need to rehash that uglyness yet again.

Here are some key milestones for IFBIN 1.0:

46,000 installations with a marketing budget of $0.
Average 3,500 unique users in Dec 2006 and rising steadily.
700+ of the best code examples ever assembled for Flash/Flex.
IFBIN royalties paid Darron's rent by majority 3 months in a row.
I worked with some of the best developers I have ever met.
IFBIN was licensed for use at the MIT Media Lab.
IFBIN acquired 150 customers with whom I am forever in debt. IFBIN 2.0 is dedicated to them. Each customer will be listed in the IFBIN credits.
Zero server downtime, thanks FreeBSD!!
Fun, Simple, and Easy to use.

That is success in my book. It wasn't financial success but IFBIN was right on many levels. IFBIN 1.0 remains technologically sound, runs cross-platform, and works 100% today. I have a lot of work to do to best IFBIN 1.0 in terms of stability and performance.

Honestly, if I were to build IFBIN from scratch using any technology at my disposal, I would go this exact route. Cross platform distributed applications are the future of the Internet and choosing Apollo gives me a much deeper technology stack than the browser provides. Delivering a dramatically better application experience cross-platform is the bread and butter of Adobe Apollo.

I am sure there are new lessons to learn in the development of IFBIN 2.0. Software development is a journey and the lessons along the way are the fun part.

Lead with Grenades!

Ted :)

I am working on IFBIN 2.0 all week. It has been 1 year since I worked on IFBIN and it has been far too long. I am going to be blogging my development of IFBIN 2.0 and launching the new version of the service with the Apollo Public Beta in 2007.

IFBIN 2.0 is a client/server application that leverages the internet for data exchange over port 80 HTTP/HTTPS. The desktop IFBIN client allows an end user to find/download/upload software examples from the IFBIN repository. The server side is an API that is accessed by the Apollo client. With the exception of the IFBIN file format, all data is stored and transmitted uses XML. The IFBIN file format contains meta-data about a file system and the data within the file system itself. Having 1:1 files per examples on the server side makes file management much easier, especially given the files named with the SHA1 key of the file data. This allows for some great server automation in dealing with files as file naming can be dynamically applied to the uploaded files.

IFBIN Server Stack:
- THTTPD (static binary data over http)
- TurboGears 1.0 (CherryPy, SQLObject, Kid)
- Python 2.4.4
- MYSQL
- FreeBSD 6.1 Minimal/Optimized

IFBIN Client Stack:
- Flex 2.0.1
- MXML & ActionScript 3
- Apollo Runtime

The server will use THTTPD, TurboGears, Python 2.4.4 running on FreeBSD 6.1. The goal is for the server to be very scalable while supporting rapid development. In this case, Python is ideal on FreeBSD 6.1 within a TurboGears instance. The IFBIN 1.0 client and server used Python and leveraging this on the server is ideal.

The existing IFBIN Server is actually 100% static and is generated onPublish via a Python API. Using URLReWriting on Apache the Flex 1.5 UI loads data remotely to present the UI Data. This model worked very well as a full republish took 2sec writing some 1200 files to the file system. The server will have as few dynamic URLs as possible by by majority most content will be statically cached.

The dynamic APIs will be:

- User.Register()
- User.Login()
- User.Reset()
- User.Profile()
- Example.Search()
- Example.Upload()
- Example.Rate()
- And some surprises... :)

These areas will all be written using TurboGears and Python. I believe that this will allow for very rapid development of the backend for IFBIN 2.0 as the backend is simply an API. Flex will provide the complete UI within the Apollo application.

Building IFBIN last time was a blast and I expect to learn a ton. I have put a lot of thought into IFBIN 2.0 and I look forward to its release in 2007.

More to come!

Ted ;)

So this morning I arrived to find 2 new FlexApps in my inbox. I do not think anyone at Adobe has seen either one of these apps before. Both are medical imaging applications, one shows images of an MRI and one a thermal imaging of an exam. Here are some images:







Special thanks to:

Educase
Wheeler Street Design

for posting images to FlexApps!

FLEXAPP SHOWCASE!

Posting Images to FlexApps

1. Capture images of flex application.

2. Email: flexapps@adobe.com like so:
Subject:

Body:
TagTV searches images and video at Flickr and YouTube. tags: mashup, flickr, youtube

3. Attach Images (NO ZIP FILES!!!)

4. SEND!

WARNING:
- Post images you have permission to post.
- Right to remove images is reserved.
- No notification of publishing will be provided.
- Image publishing will occur in the order they arrive.

Cheers,

Ted :)

I really like the new CS3 icons. Looking at the single color wheel it isn't obvious what is going on, but when you see the icons in the OSX dock and use the apps daily it makes sense. The chips are designed to look like the periodic table of elements.



Here is OSX dock on CS3 (yes I switched last month)!


The CS3 seamless ui makes the icon design and suite very clear. CS3 is going to be a killer release, having used Dw,Fw,Fl,Fx,Ps daily they are a order of magnitude better than prior versions in both design and functionality.

What I think is really cool is that Fx (Flex) is dead center, hmmmmm. Coincidence? Think again!

Look for a Flex release coming very very soon, 2.0.1 simply rocks!

Cheers,

ted :)

Want to showcase a Flex application and get developer/company credit? I have created a Flickr account to showcase images of Flex applications. Many times Flex apps reside hidden behind the firewall and public viewing of the live app is impossible. Follow the directions below to get your application showcased on FlexApps!



FLEXAPP SHOWCASE!

Posting Images to FlexApps

1. Capture images of flex application.

2. Email: flexapps@adobe.com like so:
Subject:

Body:
TagTV searches images and video at Flickr and YouTube. tpatrick@adobe.com http://www.onflex.org/TagTV tags: mashup, flickr, youtube

3. Attach Images (NO ZIP FILES!!!)

4. SEND!

WARNING:
- Post images you have permission to post.
- Right to remove images is reserved.
- No notification of publishing will be provided.
- Image publishing will occur in the order they arrive.



Cheers,

Ted :)

The Flex Cookbook is live and ready for code! If you have some Flex or AS3 code that you would like to share, simply login and complete 1 form. The form also includes an option to be considered for O'Reilly book publishing of your post.

Enjoy the Cookbook!

Ted :)

It has been 6 months since I joined Adobe as a full time employee. I was asked during a recent customer visit what I do for Adobe, honestly, it is somewhere between Ambassador, Arms Dealer, Mercenary, and Reporter for the growing world of Flex.

Ambassador (less diplomatic immunity) - Developers and companies ask me to help them work with Adobe. I set-up meetings, communicate needs, set-up deals, and generally help developers deliver. In this role, I find I am removing barriers and helping developers succeed. I also spend a great deal of time talking with developers and understanding their perspective.

Arms Dealer - I represent Flex towards developers and arm them to win. I work to start/close sales from a technical perspective (I stay out of negotiations) and help customers understand the technology in depth. Many times this means writing code, teaching Flex, or helping projects get past a key issue. This role is more about making sure developers know the features and how to use them successfully.

Mercenary - I am a developer and I write code to solve problems. Occasionally I am asked to solve a key problem holding a customer back. I was consulting in Flex/Flash long before joining Adobe. Having been in the trenches, I understand the development process and project strategies for success with Flash/Flex. I love solving problems and it is easily the most rewarding part of my work.

Reporter - I blog externally about Flex but I also blog internally about Flex. I provide feedback from the customer perspective to management and engineering. When I return from customer visits I send out a report to let others understand the customer perspective. I get to see the amazing things that developers are creating with Flex and report these to influence product direction.

---

Adobe is an amazing place to work because of the people. What is fascinating to me, is that everyone internally is very passionate about their work, and that energy is obvious when you enter the 601 Townsend in San Francisco. Joining Adobe was a big change for me as it was the first time in my career where I was not Founder/CEO/CTO. Learning to work within a very large company (5500+) takes some getting used to. Regardless, I am having a blast working here and it was a very good choice for me personally. Between the friends internally/externally and the new customers I meet daily, it is a great job and I wouldn't trade it.

That is my job at Adobe in a nutshell! It is a bit crazy, the email never ends, I am always coding, but after a long day, the beers with the team at Mars are worth their weight in gold. I look forward to helping more developers in the coming year ahead.

If you are interested in a killer job at Adobe, look no further!

Ted :)

Mike Arrington has posted a podcast interview with Kevin Lynch on Apollo. Check it out here.

Cheers,

Ted :)

JAM is on the move! Starting today the code and content within "Just AS3 and MXML" is moving into the Flex Cookbook sponsored by OReilly and Adobe. The Flex Cookbook is launching very soon and I want to every code example ported into the Cookbook before it launches (SOON). JAM contributors, please email tpatrick@adobe.com!

JAM was created due to development delays in the Flex Cookbook. It was a fantastic experiment in a code-only blog but the Flex Cookbook supports more functionality and is better suited for posting code and articles.

As I think everyone will see soon, the cookbook is going to be the place for finding great articles and code examples for Flex. It is the mother of all Wiki engines and I know that JAM will live on within the Flex Cookbook.

Thanks for JAM-ing!

Plus in the Flex Cookbook you have a chance to be included in an Oreilly book. You really cannot beat that!

Ted :)

I was in Santa Barbara working with a killer development team Monday/Tuesday teaching Flex 2 and met Seth Caldwell. Seth is new to Flex 2 and has been evaluating it for a very important project launching next year. Monday evening after the first day of training, I received Flex 2 Pong via email.

Pong with Flex2

Go Seth!

Enjoy,

Ted :)

I have visited lots of developers and each meeting has a standard question and answer period where I dispel the myths about Flex 2.0. Posting the list here will help clear the FUD (Fear-Uncertainty-Doubt) about getting started with Flex.

So here it goes, drum roll please.

Top 10 Myths about Flex 2.0

---

#1 - Flex requires a Flex Player!

WRONG!(BUZZER NOISE)

The Flex SDK creates SWF files that run in the Adobe Flash Player. A developer compiles MXML and ActionScript 3 into a SWF which can be deployed to any web server. Flex and Flash share the same runtime, Flash Player, to create rich Internet applications.

---

#2 - Flex requires a special server!

WRONG!(BUZZER NOISE)

Flex SDK creates SWF files that can be deployed to any web server. Yes, any web server, period. There is nothing special to install, configure, or manage server-side. The confusion here is that Flex 1.5 used to require a server and this myth is a legacy hangover from nearly 3 years of Macromedia product marketing. Flex 2 is different, no server required!

---

#3 - Flex costs a small fortune!

WRONG!(BUZZER NOISE)

The Flex product line starts with a low costs of FREE!!! Yes you can build RIA's with Flex SDK no strings attached, no fees, no hidden rules, nothing, nada. Flex SDK is free like beer folks (pretty good beer too!).

Flex SDK - 100% FREE LIKE BEER!
MXMLC Compiler - Compiles MXML and AS3 into SWF files.
COMPC Compiler - Compiles MXML and AS3 into SWC Libraries (precompilation/packaging)
Flex Framework - Classes containing all UI components (Less charting)
Debugger - Debug SWF files at runtime via the command line.
Compatibile with ANT - Fun for the whole family!

Flex Builder 2 (Eclipse Based IDE) - $499
Contains the Flex SDK
Coding tools - Syntax Highlighting, Statement Completion
Integrated compiler - inline errors and incremental compilation
Interactive Debugger - Breakpoints, variable inspector, expressions
Visual Layout - Drag and Drop components, Skinning Styling
Standalone or as a plugin to Eclipse

Flex Charting Components - $299
Killer charting components!


Flex Data Services Express (J2EE Server) - FREE like Beer (limit 1 CPU and minors under the age of 21)
If you have 1 web server, honestly, this is all you need.
Web Teir Compiler - Compile MXML and AS3 on the server.
Remoting - Remoting optimized for J2EE integration
Messaging - Distributed events from other users connected to this server.
Data Management - Data synchronization between connected clients and conflict resolution. Data management gets inside of the transactions and adds multi-user data exchange into applications.
No clustering or Failover on the Express Server. :(


Flex Data Services Departmental (J2EE Server) - $6K per CPU( limit 100 concurrent users. 100 concurrent is plenty for many apps)
This server will power a good sized application but is restricted at the user level. If you are doing important tasks that require multi-user data, this is a good fit.
Remoting - Remoting optimized for J2EE integration
Messaging - Distributed events from other users connected to this server.
Data Management - Data synchronization between connected clients and conflict resolution. Data management gets inside of the transactions and adds multi-user data exchange into applications.
Clustering or Failover! :)

Flex Data Services Enterprise (J2EE Server) - $20K per CPU(No limits, Lasers included)
This server can power applications of any size without breaking a sweat.
Remoting - Remoting optimized for J2EE integration
Messaging - Distributed events from other users connected to this server.
Data Management - Data synchronization between connected clients and conflict resolution. Data management gets inside of the transactions and adds multi-user data exchange into applications.
Clustering or Failover! :)

---

#4 - Flex applications can only exchange data with special servers.

WRONG!(BUZZER NOISE)

The Flex application SWF files are capable of communicating with any HTTP/HTTPS or socket based server. Here is what you can do:

- Exchange any format of ASCII text (POST,GET,REST Headers Supported)
- Exchange any format of XML (POST,GET,REST Headers Supported)
- Talk to any server side language (.NET, RUBY, PYTHON, JAVA, PHP, PERL, XML)
- Exchange data using SOAP direct to the server (many soap encodings supported)
- Exchange binary AMF (Optimized data serialization format for remoting, paging). This is supported in ColdFusion and JRun by default and there are many free AMF libraries for .NET, JAVA, Ruby, PHP
- Exchange data in real-time using 2 way push over XMLSocket and BinarySocket. These features are unique to Flash Player (See #1 - Flex runs in Flash Player) and allow communication to socket based servers. I have seen Flash Player used to create clients for POP3,FTP,SVN,XMPP, and all existing socket based media servers. This can be done over low ports too provided that server permissions are used.

---

#5 - Flex doesn't play well with AJAX.

WRONG!(BUZZER NOISE)

A Flex SWF file can talk 2 way over JavaScript. We are seeing explosive growth of AJAX leveraging features in Flash Player to optimize/improve AJAX applications. Flex can leverage the Flex AJAX Bridge to make data exchange between Flex and AJAX seamless. The 2 top investment portals ( Yahoo and Google )use Flash Player for charting and AJAX for the user interface.

---

#6 - Flex apps can only be full screen.

WRONG!(BUZZER NOISE)

A Flex can be used to make widgets and panels within a larger HTML or AJAX application. Flex can be used to invisibly exchange data which is rendered using AJAX. Some are using Flash Player for XML parsing in AJAX or providing real time communication. There are several video companies providing Video player widgets in Flex 2. In some cases, full screen flex is ideal, in some it isn't.

---

#7 - Flex is hard to learn.

WRONG!(BUZZER NOISE)

The hardest part about learning Flex is understanding the component development model and the MXML translation paradigm. It took me a month before I felt comfortable coming from Flash to Flex. If a you have used PowerBuilder, VB, Delphi, Visual Studio, Java expierience, you will take to Flex like a duck to water. In Flex you work at the component and container level to build the user interface with XML markup. Events, functions, and bindings are used to wire the application together. When you compile, MXML is translated into ActionScript 3 classes and then compiled to a SWF for playback in Flash Player.

Just like any programming language, it takes time to master Flex. Rome was not built in a day and neither are great developers.

---

#8 - Few real projects are using Flex!

WRONG!(BUZZER NOISE)

There are many mission critical apps deployed within intranets around the world. Just because you haven't used an executive dashboard in Flex 2 doesn't mean they do not exist. Many of the top companies powering the world economy are using Flex internally for apps that run essential parts of their business. The first market for Flex is intranet applications and already there are many Flex 2 applications already deployed.

There are a few leading companies using Flex 2 for public facing applications. Given the Flash Player 9 adoption cycle, we are due to hit 80% in the first half of 2007. Currently the September statistics show 40% support for Flash Player 9. As with all players before, when the Flash Player adoption hits 80% there is always a flood of new public facing applications that arrive. What is interesting is that the Pikeo photo service launched on Flex 2 last week. I am seeing several companies shipping public facing Flex 2 applications and there are a ton in development.

Think of the Flex marketplace like an iceberg. There are a few public facing applications but the majority of the apps for Flex are below the waterline and out of public view.

---

#9 - Flex and Flash do not work together.

WRONG(BUZZER NOISE)

Flex and Flash both deploy to SWF and both run in the Flash Player. Becasue they share the same runtime, they both have the same DNA and thus are at a low level compatible. There are many ways to reuse Flash SWF content at both runtime and at compile-time within Flex applications. You can today import and reuse any Flash animations or vector graphics within Flex via the [Embed] Meta tag and this includes support for specifying 9-slice scale parameters too. When CS3 ships we will see many tools able to contribute more directly into the Flex development model.

Who knows, we might be working on some things for the next release as well. :)

---

#10 - Flex is slow.

WRONG(BUZZER NOISE)

Flash Player 9 and ActionScript 3 was designed for speed, period. Flash Player 9 contains a JIT compiler that runs code over 20 times faster than prior versions. The performance gains are attributed to the player generating PPC and X86 machine code nativly at runtime. Yes, you read that correctly, when ActionScript 3 is being executed it executes as native machine code. It is not just faster, its blazing fast.

---

Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...
Marty DiBergi: Oh, I see. And most amps go up to ten?
Nigel Tufnel: Exactly.
Marty DiBergi: Does that mean it's louder? Is it any louder?
Nigel Tufnel: Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from there? Where?
Marty DiBergi: I don't know.
Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
Marty DiBergi: Put it up to eleven.
Nigel Tufnel: Eleven. Exactly. One louder.
Marty DiBergi: Why don't you just make ten louder and make ten be the top number and make that a little louder?
Nigel Tufnel: [pause, blank look and snapping chewing gum] These go to eleven.

---

#11 - Adopt Flex and double your salary/rates.

TRUE(DING,DING,DING)

There are many world class companies building applications with Flex 2.0 and they need help. Consulting rates since the launch of Flex 2 had gone up over 50% in 6 months time. When I look around and see that every Flex developer I know is 110% booked with project work at very high rates, something great is happening. I have seen many developers that I know personally switch to Flex and double their income, it happened to me as well.

At every single customer visit the last question asked is either:

"Where can I find expierienced Flex developers?"
or
"Can you refer me a few developers/consultants that would be ideal for my project?"

Everyone is looking for Flex talent and developer salaries and rates are rising. If you want a better salary, learn Flex, join Flexcoders, and get a job developing Flex applications. It is still very very early for Flex as a technology and when Flash Player 9 adoption hits 80% and Apollo arrives, Flex project work is going to be everywhere. Flex has been building steadily since it launched but the next 12 months are going to be a very wild ride.

We should also see great things at the 360Flex Conference at Ebay March 5,6,7 in San Jose. The conference will hit at a very interesting time and there will be a lot to discuss. Make sure to register now this is almost sure to sell out.

Cheers,

Ted :)

We ended part 1, using addChild to add ball class instances into our application. Adding them is really just the beginning as we need to be able to move them around and reorganize the DisplayTree to our advantage. When you move a class from one part of the DisplayTree to another we call this reparenting.

Reparenting is very important as it allows us to restructure an application at runtime to represent different structures. Lets walk through some reparenting examples of manipulating the DisplayTree.

So here is stage 1 of the DisplayTree. There are 6 children and one base class.


To create this tree you would do this:

1. Create child instances:

a = new Ball( 100, 0xFF0000 );
b = new Ball( 100, 0xFF0000 );
c = new Ball( 100, 0xFF0000 );
d = new Ball( 100, 0xFF0000 );
e = new Ball( 100, 0xFF0000 );
f = new Ball( 100, 0xFF0000 );

2. Add them to one another:

//assuming scope is within the base class
this.addChild(b);
this.addChild(a);
b.addChild(d);
b.addChild(c);
c.addChild(f);
c.addChild(e);

When using addChild items are added to the top z order wise at each level. In the diagram, z-order would be left to right. This is why the order in the addChild calls seems backwards but it is correct. (checked it twice.)



So to modify the DisplayTree to this new version we just need to do this:

a.addChild(c);

The above code moves c into "a" as a child. What is interesting here is that all the children in "c" move with it. In this case we have reparented a branch.



Now another reparenting case. "f" needs to move from "c" to "a" and then be moved behind "c". If just addChild were used, "f" would be in front of "c". To correct this we can swap the values using the swapChildren method like so:

a.addChild(f);
a.swapChildren(f,c);

or you can do this in a single call using addChildAt using the zero index. This is handy as it will alwasy add items to the back.

a.addChildAt(f,0);

So there we are reparenting in a nutshell.

Part 3 we will be doing some work with Flex and explaining trees in the context of containers and controls.

Cheers,

Ted :)

Justin loaned me his Wii this weekend and I have been playing it non-stop, well less going on a date and a round of golf today, I know, pathetic. The Nintendo Wii, simply put, is the best game system I have ever played, including Atari and Intellivision back in the day. I walked into this weekend thinking one thing about the Wii but walked away very impressed.

First off the Wii is small ( 3 DVD's stacked ) and the entire system fits easily in a medium size Timbuk2 bag including all cables, console, controllers, and 3 games. When you first hit the power button, the DVD slot lights up like a spark went off with audio, it hints that thing are different. The background audio on the system and menus are impressive. I was playing on a big screen TV and the visuals were stunning. Contrary to what I expected the graphics are impressive and the game play is very fast paced. I guess I expected something slower but the graphics are on par with any modern game system, it does lack some hi-def graphic details but Wii makes it up in fluid game play. If you want to see great 3D, go to the movies, the Wii is 100% focused on playing games.

Wii Controller
This is 80% of Wii, the controller makes this system unique and great. At first it is awkward but you get accurate very quickly. On a larger TV, I found that the system was easy to control accurately. For example on XBox360 using the onscreen keyboard is slow, but on Wii you can type fast with the controller in one hand, just point and click. The remote vibrates when you roll over buttons and it makes you conscious of what is clickable in the ui. Additionally the controller has a speaker so it makes noise in context with the ui and during game play.

Wii Sports
Wii Sports is fun and I especially like golf and boxing. The controller is intuitive and the game play light, fun, fast, and classic Nintendo. Each sport makes you use the controller differently. In golf you can slice or hook the ball depending on the accuracy of your swing. Also you play all sports in a caricature you create.

Zelda
Wow. If you have anything urgent to do in the next 4 days, DO NOT START PLAYING THIS GAME!!! Zelda starts out slow as usual and builds into a very fast paced strategy/action adventure game. The initial portion teaches you to use the controller as a slingshot, fishing rod, sword, and shield. There is no button to draw the sword, you simply move your hand. The intensity of the game also builds and starts to rival a 1st person shooter sans gore. The first time something jumps out at you and you must draw your sword and fight, you will understand what I mean when I say, Zelda gets intense. The combination of motion controller and immersive game play puts Wii in a new category, Zelda is unlike anything I have played. It is like someone merged Myst + Doom + epic + motion controller into a single game.

So here is the bottom line, sorry Microsoft, it is out with the old and in with the new. I am selling my XBOX 360 on Ebay starting tonight and getting a Wii. It was a good system but to be honest the Wii is better, a lot better.

A bit of a disclosure, I bought Nintendo shares after E3 when I saw videos of people playing the Wii. It looked promising then, but it is much better in person. I wanted to evaluate the system as to my investment with Nintendo and it looks like they have hit a home run. I am actually inclined to purchase some more shares as a result. Combined with the DS, it looks like Nintendo is back to full stride again as a company.

Cheers,

Ted

http://tech.groups.yahoo.com/group/flexcomponents/

1. Extended mx.core.UIComponent lately?

2. Dispatching DOM Events before 10AM?

3. You want a new <mx:Form> Class.

4. You are dying to know what these do?

[Style(name="horizontalGap", type="Number", format="Length", inherit="no")]
[Bindable("valueCommit")]
[Inspectable(category="General")]

5. You check Quietly Scheming for new components.

6. How do I use mx_internal?

7. Writing protocols in flash.net.Socket?

8. You skinned something today.

9. Cairngorm is no longer a challenge.

10. I want to write commercial quality components.

http://tech.groups.yahoo.com/group/flexcomponents/

Post message: flexcomponents@yahoogroups.com
Subscribe: flexcomponents-subscribe@yahoogroups.com
Unsubscribe: flexcomponents-unsubscribe@yahoogroups.com

Seriously, if you have thought about writing components and extending the Flex Framework, come join in. We need more great components, join the list and learn a ton.

Cheers,

Ted Patrick
Flex Evangelist
Adobe Systems

If you develop SWF files using Flash or Flex you develop in a tree whether you realize it or not. Trees are the base structure within the Flash Player DisplayList or better named, the DisplayTree. The Tree within the Flash Player 9 using ActionScript 3 starts with the base class of your SWF either inherits from flash.display.Sprite or flash.display.MovieClip classes. These two classes inherit from flash.display.DisplayObjectContainer and thus have methods and logic to adding and removing children.

The inheritance chain looks like so:

flash.display.DisplayObject
^
flash.display.InteractiveObject
^
flash.display.DisplayObjectContainer ( Methods for managing children)
^
flash.display.Sprite ( Sprite has 1 frame )
^
flash.display.MovieClip ( MovieClips has 1+n frames )

With only one root class this is not much of an application but as you will see the basis for building great things is within understanding this simple model. The ability to add and remove children within the DisplayTree is the essence of Flash Player and it is the most important paradigm to understand. Real interactivity comes with the ablity to create a visible tree of objects nested within one another in a tree structure. Flash Player 9 has greatly improved this paradigm by simplifying the API's for adding/removing children and allowing instances to exist both on and off the DisplayTree.

Lets get into some code.

For those using Flex Builder:
1. File > New > ActionScript Project
2. Type "Dounut"
3. Press Enter

package {
   import flash.display.Sprite;
   public class Donut extends Sprite
   {
      public function Donut()
      {}
   }
}

SWF Compiled: 298 bytes ( SWF can be very small! )

Ok so we have a working base class Donut that inherits from Sprite. It is rather boring but it compiles and we are off to the races.

So lets create some children and add them.

So lets make a Ball class. This class will create instances of Balls of various colors and help us create this virtual SWF donut.

package
{
   import flash.display.Sprite;

   public class Ball extends Sprite
   {
      public var color:uint;
      public var radius:Number;

      public function Ball( radius:Number , color:uint ):void
      {
         this.color = color;
         this.radius = radius;
         this.draw();
      }

      public function draw():void
      {
         this.graphics.beginFill( this.color );
         this.graphics.drawCircle( 0 , 0 , this.radius );
         this.graphics.endFill();
      }

   }
}

Ok so we can make balls now or various radius and color. Now lets add the balls into our base class. I typically like to manage a pool of like instances within an Object for simplicity, I think there is a slight hit performance wise when references are looked up this way as the items in an Object are untyped and thus use hash table lookups. But this is for example purposes and as you will see we will be making lots of balls (they are the sprinkles too).

So here are the change to Donut:

package {

   import flash.display.Sprite;
   import Ball;
   public class Donut extends Sprite
   {
      public var balls:Object = new Object()
      public function Donut()
      {
         //create 2 balls
         this.balls.red = new Ball( 100, 0xFF0000 );
         this.balls.blue = new Ball( 50 , 0x0000FF );
         //set ball properties x,y
         this.balls.red.x = 200;
         this.balls.red.y = 200;
         this.balls.x = 25;
         this.balls.y = 25;

         //add the red ball to the base class as a child
         this.addChild( balls.red );

         //add the blue ball as a child of the red ball
         balls.red.addChild( balls.blue );
      }
   }
}

Wow that is one ugly donut but hey this is virtual and its my donut not yours.

The real key here is the last 2 lines of the Donut constructor. The calls to addChild are very important as these are the keys to understanding the DisplayTree. See as everything here inherits from DisplayObjectContainer, addChild, removeChild are methods in every instance of both Dounut and Ball classes. This allows them to be inserted into one another seamlessly as children. It is this behavior that builds up the tree in the Flash Player.

I have got to run to a custom visit but I will be covering reparenting next time. Experiment with creating more Ball instances and creating a tree of them. As you will see this pattern is wildly extensible and is the root of all interactivity in Flash Player.

If you understand this lesson, you can do amazing things in Flex and Flash Blaze.

Part 2 on Monday!

Cheers,

Ted :)