Dead Ink Vinyl

For most of this year, I’ve been taking notes at conferences using Field Notes notebooks. I love their pocket sized dimensions and they have just enough pages to comfortably hold everything from a conference that I’ll want to remember later. However, for QCon last week I decided to try typing everything into Evernote. The fact that I can access my notes on my iPhone makes the notes just as portable ex post facto, and saved my Field Notes for more worthy pursuits.

Evernote worked out very well, and now I can share my notes online just by putting all of them into their own notebook (folder) and making it public.

So without further ado: my notes from QCon.

Overall, I thought QCon was excellent. While the quality of the speakers was somewhat varied in the sessions I attended, I never felt my time might be better spent checking out a different session, which puts it ahead of most conferences. (I’m a big fan of voting with my feet.) QCon is certainly on my short list of conferences to attend next year. Also on my list are (in no particular order): C4, WWDC, RailsConf, eRubyCon, and 360|Flex.

Okay, I’ve walked through all of the code in UIComponent and Container to work this out, so I’m going to share it: the sequence of operations when addChild(child) is invoked on a container and child extends UIComponent.

Since the primary use for this knowledge is managing the initialization portion of the component life cycle, I’ve highlighted the lines where your component may extend the behavior of UIComponent to perform its own operations.

The addChild() code bounces around through a lot of the Container class hierarchy, so I’ve included the class name with the method calls inside the parent’s instance so that you know where in the class hierarchy things get handled.

For simplicity, I skip showing the parameters to method calls and I don’t expand some operations (depicted by italicized text).

1. Container.addChild()
   1. calls Container.addChildAt()
      1. removes child’s previous parent, if present
      2. calls Container.addingChild()
         1. calls UIComponent.addingChild()
            1. calls child.parentChanged()
            2. performs style setup on child
            3. calls child.stylesInitialized()
         2. invalidates size and display list of parent
      3. calls UIComponent.$addChildAt()
         1. calls Sprite.addChild()
      4. calls Container.childAdded()
         1. parent dispatches “childrenChanged”
         2. parent dispatches “childAdd”
         3. calls child.dispatchEvent()
            1. child dispatches “add”
         4. calls UIComponent.childAdded()
            1. calls child.initialize()
               1. dispatches “preinitialize”
               2. calls child.createChildren()
               3. calls child.childrenCreated()
                  1. invalidates properties, size, and display list of child
               4. calls child.initializeAccessibility()
               5. calls child.initializationComplete()
                  1. sets processedDescriptors = true
                     1. dispatches “initialize”

There you have it: the order of operations when you invoke Container.addChild(). I hope this proves useful.

I’ve been thinking a lot about the Ryan Stewart’s Flex SEO contest (also known as the “Fleximagically Searchable” contest). As I posted earlier, I believe the best and correct method for “making Flash indexable” is not to index Flash at all, but rather to index the data. I spent a lot of time thinking about how I could get Google to index my content but link to my Flex application and I finally found a mechanism to do this! However, upon very close reading of Ryan’s rules I see that he specifically does not want this solution—he wants the content to be indexed by Googlebot “interacting” with the application.

That’s just silly.

For data-driven sites—which would be most Web sites with Flex front-ends—this is an completely artificial restriction. The only place where this would make any sense is for applications that do not dynamically load content, but rather dynamically generate content, such as for client-side mash-ups. Additionally, according to Google “if your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.” That implies that dynamically loaded content must be RPC-based (and binary?) to be considered part of your SWF (as Ryan Stewart desires) instead of a separate resource. Yuck!

I will continue with my planned solution because demonstrating the technique and learning how well it works for SEO will provide valuable information for the community.

Finally, I’d like to announce that I’ve purchased the domain fleximagicallysearchable.com for this contest¹. There is nothing there now, but I would like to turn it into a blog or user forum for discussing Flex SEO strategies and make it a resource that lives beyond this contest, continuing to be useful in the future by providing tutorials and covering the emerging best practices for Flash and Flex SEO.

¹ Not to be confused with fleximagically-searchable.com, which is owned by zedia.net.