Dead Ink Vinyl

My MacBook Pro serves two purposes in my life. First, it is my personal computer — where I email, chat, tweet, and browse online, and where I write documents, edit photos, watch videos, and otherwise stay in touch. I want these functions to just work whenever I open the laptop. Zero hassles.

Second, my MBP is my development computer. Development computers get the snot kicked out of them. They are constantly in flux. Install the new Ruby; install the new Xcode; install the new iPhone SDK beta and the new Drizzle and CouchDB and LLVM. Update the new MacPorts and Homebrew and OpenPKG. Upgrade my git, hg, and svn. Try Erlang, and Haskel, and Hadoop. Then uninstall and reinstall some or all as needed. Eventually, I cross the beams and it’s time for a fresh start¹.

On the one hand, I crave stability. On the other, I’m pushing constant change. On the one hand, I have simple requirements that can be met with a simple, 1.5 pound portable device. On the other, I’m a power user demanding the biggest, the fastest, the most of everything in a 17” form factor.

I’ve tried various schemes to manage the conflicting requirements of these two modes of interaction with my computer. On occasion, I’ve completely lost my mind and try outlandish solutions such as dual booting or running my personal computer as a VM inside my development computer (hey, at least it was easy to backup). These solutions never worked because I often wanted to jump between both worlds quickly and effortlessly.

Then the iPhone came along. It was nearly perfect, allowing me to separate my personal computing from my development — in a package that was eminently more portable than my 17” MBP. However, the iPhone has certain constraints that require me to maintain a personal computing presence on my laptop. I don’t like writing long emails on my iPhone. Certain web sites are so poorly designed they must be viewed on a full computer². I can’t create content (documents, spreadsheets, presentations, diagrams) on my iPhone. Ultimately, the iPhone is a satellite device.

The iPad promises to be my dedicated personal computer. It promises to email, chat, tweet, browse, write, edit, and watch — all while just working. (And, might I add, from anywhere.) That frees-up my laptop to be a dedicated development platform that I can use and abuse without consequence.

I want an iPad to keep my simple personal computing needs separate from my developer computing needs.

¹ I subscribe to the Ripley school of developer workstation maintenance: nuke the entire site from orbit — it’s the only way to be sure.

² I’m not even talking about Flash — I’m talking about sites that screw up HTML that badly.

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.

Oh! How so many of the world’s software problems would be solved by listening to this nugget of wisdom from yesterday’s posting by Jacob Nielsen!

Of course, people don’t want to hear me say that they need to test their UI. And they definitely don’t want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support. The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.

Software exists to solve problems. To understand the problems a proposed software application is supposed to solve, nothing beats walking a mile in the user’s shoes. (37signals calls this What’s Your Problem? in their book Getting Real.)