Sarah’s posted some succinct observations on getting into the flow, accompanied by a very cool glimpse into mind of Jonathan Gay when they were first creating the Flash and Director plugins.
http://www.ultrasaurus.com/sarahblog/2009/02/preparing-to-get-in-the-flow/
Judah’s posted a detailed walk through of how to test multiple sites and operating systems on one computer:
http://www.judahfrangipane.com/blog/?p=241
Interesting way to point multiple VMs to one web server on the host computer.
This post is not about the raw quantities of documentation I’ve been reading or how cool the technology is… it’s about a long-held interest of mine in how learning happens.
The iPhone Application Programming Guide does not explain the language, the framework, the device, or tools. However, it assumes knowledge of the aforementioned topics and stitches them together into high level concepts. I spent the past week cramming on all the other tedious details leading up to this point, and now I’m flying through the rest of the iPhone documentation.
Cocoa belongs to a family of object-oriented GUI frameworks that trace their lineage back to Smalltalk. This family includes older frameworks like Swing, Morphic, WinForms, and more recent frameworks such as Flex and Silverlight/WPF. Henry Sowizral taught me this; and, for several years, I’ve paid attention to the common inflection point in these frameworks where “play time”, or “getting into the flow” begins. Preconditions for a playful experience seem to require…
My brain wants to barf up all the information crammed into it over the past few days, but the memorization bottleneck has receded. We’re entering “play time” now.
There’s a particular movie scene from The Matrix that I associate with the feeling of getting over the tedious hump of *memorizing* and finally reaching that inflection point of *doing*. It’s quite a rush when you can slot a new model into your reality and start using it.
More to come…
Check out this prescient 2003 presentation by Jeff Bezos on the internet as a utility, and then forward to this 2007 presentation on cloud computing by Kevin Kelly.
In the past month, I’ve had to reinstall Windows on my laptop twice, I discovered my parents’ Windows laptops were riddled with viruses, and I had to rebuild Hoi Yin’s desktop due to similar operating system problems. We almost lost her email, and I spent countless hours restoring our backup data. However, I’d migrated almost all my work to GAFYD, and none of my business files or email required any recovery effort when I bought a macbook. Hoi Yin saw the benefits of my setup but wanted to stick with Windows, so she asked me to migrate her Outlook accounts to GAFYD too. She’s really happy with it.
I’ve come around to the perspective that we’re switching to using DNS as a sort of root directory for personal data and computing in an inverted model of reliance, using the internet for persistent regular computing and our own machines as merely transient machines that we expect to break eventually.
The top-down approach is how I’ve chosen to start learning iPhone development because I’m mapping it to concepts I know, but such an approach takes more time to see results and doesn’t work for everyone.
Here’s a more suitable iPhone guide for those who prefer to learn by doing but need a guide to starting from scratch. It won’t teach you Objective-C or help you understand the Cocoa framework, but it’ll walk you through the steps of building and publishing an app. You’ll feel more comfortable after going through the motions once. It’s enough to get into a write-test-rewrite cycle and start learning as you go, like the way some folks started with Javascript or Flash.
My regular phone number still belongs to a Nokia 6610 purchased back in 2003, so this is obviously not the blog of a mobile trend chaser. However, I’m surprised at how quickly the iPhone replaced my laptop. It was just supposed to replace the iTouch, but after 3 days, I began using the iPhone for most computing activities except coding, extended writing, and deep web immersion. I also discovered an annoyance towards businesses that don’t optimize for mobile, and discovered gratitude to brands that do, like ZipCar and GAFYD.
I canceled my laptop wireless data plan. When a carrier offers an iPhone-quality device with tethering and faster speeds, I will cancel the cable modem too (we stopped using cable “television” years ago).
This doesn’t feel like a hype bubble. It feels like a sea change. Ad Mobs recently released statistics about iPhone’s growing market share of mobile web browsing.
XCode has a feature called Research Assistant, a little window that gives you helpful details about the code under your text cursor. As your text cursor moves, Research Assistant provides a sort of running commentary about whatever the text cursor is pointing at. It tells you where a keyword or message was defined, and a short blurb about what it does. Not all pieces of code have associated documentation, so sometimes the window is blank. Blue underlined keywords act as clickable hyperlinks to full documentation. It’s a great tool for exploring code with the text cursor, or as you type with code sense enabled.
Research Assistant for text cursor pointing at "initWithFrame:"
You can turn on Research Assistant by choosing Help > Show Research Assistant from the menu, or by pressing the Control+Shift+/ key combination. Research Assistant works even better in combination with Code Sense and other XCode features that help you learn on the fly.
Use the built-in Doc Sets and quick reference shortcuts in XCode to help you explore code samples. Once you start XCode, download the iPhone OS Doc Set. Open the documentation window through the Help > Documentation menu, and then press “Get” on the doc sets you want to download. Now you can hold down the Option key and double-click on words in the source code to jump directly to the full documentation! You can also hold down the Command key and double-click on classes and methods to jump directly to their definitions in the original header file.
Make sure the Documentation Window has filters optimized for source code referencing. I have my filters set to API / iPhone OS 2.2 Library / All Languages / Exact. You need to include “all languages” in the filter because some essential frameworks like Core Graphics are written in pure C, not Objective-C.
Check out this page of XCode tips for more useful tricks. XCode also supports many emacs key combos. Here are a few useful XCode shortcuts I use when exploring sample code:
Option+Command-LeftArrow = go to previous source file.
Option+Command-UpArrow = toggle between header and implementation file.
Shift+Command+/ = search available commands and display the associated menu item
Today, I started digging into documentation on Cocoa’s interpretation of MVC patterns in the Cocoa Fundamentals Guide. The design patterns chapter focused too much on jargon to be useful for me, but the MVC chapter cleared up a lot of things. I like how Cocoa’s use of MVC terminology tries to be useful rather than falling into the recursive trap of obsessing about logical consistency, as I’ve seen happen elsewhere.
I used to buy into jargon like “View Models”, “Control Models”, “View Control Models”, etc., but you’re modeling whenever you abstract. We perceive the world through many layers of abstractions, and three layers aren’t enough to model reality, or even just the slice of reality you’re working with. I used to get confused trying to model human-machine interactions into a three-layer ontology because that’s I thought we were supposed to do. Then, a wise man helped me see the limitations of MVC by shattering it against our concurrent, physical (metaphysical?) reality. It’s really just turtles all the way down, man, so, like, stick to the problem at hand. 
The iPhone SDK has started to make more sense. You just have to flow with how Apple wants you to code. The Cocoa Fundamentals Guide offers this pithy advice: “Instead of incorporating library code into your program, you incorporate your program code into the framework.”
So far, I get along ok with Objective-C thanks to a previous interest in Smalltalk (not that I’m fluent). Years ago, I stumbled onto the Smalltalk definitions for “Object” and “Class” while exploring in Squeak’s class hierarchy browser. I was struck by how the dynamic language defined Classes as class descriptions, classes as Class objects, Object for creating/counting all instances, and everything else as instantiable classes. Wow. I barely understood these old-school gems, but they hinted at a much simpler and more powerful way to add object orientation to a language. Anyways, I’m still no rocket scientist about this stuff, but NSObject hints at the same mechanisms from Smalltalk layered on top of C, which makes Objective-C easier to appreciate.
Many thanks to fellow Flashers for more tips and resources too!
After you register for an iPhone developer account, Apple presents you with lots of beautiful documentation. In fact, it’s almost TOO much documentation for someone who doesn’t know where to start. After much wandering around, I pieced together a better roadmap for building up my iPhone knowledge. This might not be the best approach, so let me know if you have any feedback or suggestions.
1) If you’re a visual thinker like me, you might want to spend a few seconds looking at the Application Life Cycle and Event-Handling diagrams in the iPhone Application Programming Guide. These diagrams illustrate the sequence of events as an application starts, responds to user input, and then shuts down. Seeing this diagram was a relief to me after trying to piece together concepts from other sources. This took around 15 minutes.
2) Read the Cocoa Fundamentals Guide first, especially “The Cocoa Environment“, “The Cocoa Frameworks“, and “The Model-View-Controller Design Pattern” chapters, to prepare some mental categories of code you’re going to see later. It’ll give you a frame of reference when you see classes with different prefixes like “NS”, “CG”, and “UI”. Skip any Mac-specific parts unsupported by the iPhone, such as Core Data. This guide took me around 2 days to study carefully, but you might skim it quickly in an afternoon.
3) By the way, I made the mistake of reading the entire “Objective-C 2.0 Programming Language” reference manual from beginning to end, which is why this blog post is titled “day 2″. The summary in the Cocoa Fundamentals Guide is much shorter and more relevant to getting started.
4) Skim the iPhone Development Guide to get some hands-on familiarity building basic apps in XCode, even if you’re not sure how everything works yet. Explore sample source code with tips in Step 3.
5) Learn how to turn XCode into a learning environment with code sense, Research Assistant, and instant shortcuts to documentation. I’ll blog more about this approach later.
My strategy is to build a mental model of the language and frameworks as a whole first. It gives me a way to piece things together in my head so that I know where to look for information later, but this does require more patience in the beginning.