E-Readers are such different experiences from paper books, but we seem to have already settled on interface paradigms that carry over so much paper baggage. For a while now I’ve noticed that I have adopted a few counter-intuitive e-reading practices that others haven’t.

“Both Margins Advance”

The typical e-reader paradigm is to swipe right-to-left or left-to-right to turn the page forward or back, respectively, and to tap the right or left margins to advance or page back. “Duh, obvious,” right? But is this really needed?

By my (highly scientific, trust me!) estimate, more than 95% of reading is moving forward—why should half of the interface be devoted to moving back? If you are right-handed, have you tried holding the iPad in your left hand and advancing pages while enjoying a fresh cup of coffee? Swiping is possible, but it’s awkward.

iBooks has a “Both Margins Advance” option in its Settings.app bundle. I don’t know if this was a sop to lefties, but for me it has become a defining feature for any good e-reader. By enabling this option, tapping either the left or right margin advances the page. You still have left-to-right swipe capability for the exceptional instances when you need to go back. Tapping either margin allows for comfortable ambidextrous one-hand reading while enjoying a tasty beverage or (as in my original use case when I discovered this) holding a sleeping infant.

On the iPhone, Read Less Not More

If you read on your iPhone but it’s not your primary reading device, go make your e-reader font bigger. No, bigger than that.

No…still bigger. Really.

On my iPhone 5, my font is set so I typically only see 13 lines of body text per screen. That’s not much; you’ve probably actively been going the other direction trying to squeeze in a “page” per screen. While I initially made this adjustment due to getting older and denying that I needed reading glasses, it’s turned out to be more generally useful.

When I’m comfortably settled in for reading, I use my iPad. I really only read on my iPhone when I’m on the go, which turns out to be highly interruptible: I’m frequently glancing up to see if the bus is coming, or if it’s my turn to speak to a clerk. Larger fonts don’t necessarily help so much with the reading of text on iPhone as much as they help you return to reading after an interruption. You have much less positioning on screen to remember and can return to where you were much quicker. If this describes your reading conditions, give this tip a try—trust me, you’ll quickly get used to the more frequent paging required.

Wish List Items

I wish iBooks gave me better control of styles. Most notably, I’d like to be able to reduce the size of chapter and section headings so they don’t overwhelm the iPhone screen at my larger font size.

I’d like the ability for the screen to be less reactive while I’m reading. I’ve only dabbled in speed reading practices, but one of the first techniques they all promote is to guide your eye along the text with your finger. This is pretty impractical when it can so easily be recognized as a page-turning swipe. I’m not really interested in getting into a pros and cons of speed reading discussion, but it is an example case where one would want to be more hands-on with the text than most e-readers allow.

I’m really glad e-reading has advanced from when I first started reading on a tiny Handspring Visor. I admire those experimenting with exploring it as its own expressive medium, but I also want developers to continue to question and improve how we read standard texts.

Fortunately, there is functionality within Xcode to make it easier to manage and maintain a number of scenarios and restore them readily. This functionality will allow you to test your migration code from any past data model version to the current version, debug custom migrations, even profile migrations in Instruments.

Unfortunately, it’s not very well documented and, while you can preload to a device or simulator, the data package must first be created on a device.

Update 2015-04-20: This worked great in Xcode 5. Unfortunately Xcode 6 (through 6.3 as of this writing) does not behave as described for the Simulator (it does load a device just fine). Versions <6.3 will tell you “The application data package will be installed the next time you run your app in the Simulator”—every time. Version 6.3 will just silently fail to load the package. I have reported this as rdar://20622011 / Open Radar

Your Friend the .xcappdata Package

You’ve probably encountered an .xcappdata package before, although you most likely think of it as a one-way data extraction method. Let’s walk through this with as simple a demo application as possible:

1. Create a new project. As much as I despise Apple’s template Core Data stack, it will suffice for this example, so create a new “Master-Detail Application” that uses Core Data.
2. Run the application on a device.

3. Add 5 items.

   

4. You may stop running the application on your device—the following steps aren’t affected by it running or not.

5. Open the Xcode Organizer, select the “Applications” section of your device under the Devices tab.

   

6. Select your test application. You should see a bunch of folders and files populate the “Data files in Sandbox”. (This may not populate right away, so be patient.)
7. Click the “Download” button at the bottom and save the xcappdata package to your Desktop, giving it a descriptive name like v0 - 5 items.xcappdata.
8. Click “Delete” to remove the application from the device—we will try to start with a clean install for the next steps.

Here comes the magic:

1. Create a new Group in your project. I name mine “Test Data”.
2. Add v0 - 5 items.xcappdata to the group.
   1. Select “Copy items into group folder”.
   2. Do not add it to any targets.

   

3. Launch the app while holding the Option key—either Option-clicking the Run button, or Option-Command-R. A scheme configuration sheet will appear.

   

4. In the Options tab, select v0 - 5 items.xcappdata from the Application Data menu and click “Run”.

Voilá, your app has launched a clean install, but with five items in the database—Xcode has pre-configured your application with the data files from your xcappdata package.

Exploring the .xcappdata Package

In the Finder, Control-click the .xcappdata package and select “Show Package Contents” from the contextual menu. Inside you will find an AppDataInfo.plist file and an AppData folder. Inside the AppData folder are the Documents, Library, and tmp folders that were downloaded from the device.

Any changes you make to these folders will be reflected the next time you launch the app with this scheme loading the application data. Let’s make a “clean launch” data set:

1. Duplicate v0 - 5 items.xcappdata in the Finder and rename it to Clean Launch.xcappdata.

   

2. Open Terminal and Command-drag your Clean Launch.xcappdata onto it to make the package’s path your current directory.
3. Execute rm AppData/Documents/*sqlite* to remove the Core Data store and supporting files.
4. Execute rm -rf AppData/Library/Caches/*/.CoreDataCaches. This clears out the invisible directory containing all your NSFetchedResultsController caches. If these are out of sync with the data store, you will encounter crashes and other frustrating behavior.
5. Add Clean Launch.xcappdata to your project, again remembering not to add it to any targets.

Now you have a way to start from scratch whenever you want without having to delete the app first.

Testing Implications

Every public release version of your app should be the time to freeze the version of your Core Data model. When you release the next version of your app, you will need to account for migrating the data your users currently have to the new version’s data model. (There may not actually be any version-to-version changes, but you should assume there will be.)

So as part of every release you should take a few xcappdata snapshots:

• Empty database. This is not the Clean Launch, this is the default database Core Data would generate, including anything your app automatically constructs. This is the state your app would be in if a user launched it once, didn’t do anything, and (horrors!) forgot about your app until launching an updated version.
• “Typical” user database. Run the app for a while as a typical usage scenario, then download the data package. You may have multiple “typical” users—make snapshots for all you can define.
• “Extreme” user database. This is your chance to stress test; this is your chance to ensure that your migrations can satisfy even the most outrageous user of your application. If you need to, create a command-line tool to create a large data store using the model then copy that into the package.

Add these to your project so they’re available to use. Give them descriptive names that include at least the revision (“v1”, “v2”) and scenario (“base”, “userA”, “extreme”). Adding them to project groups will help organization, but the scheme menu only lists the package name so make it identifiable.

At some point during the development of your next release, any model updates will have settled down. Use these data sets to verify that:

• Migration of old versions happens
• Migration happens correctly
• Migration happens quickly

The first two points can be tested in the simulator. If you need to write custom migration code, you will automatically start from the same point every time you launch the app after making code changes.

The last point of verification, though, needs to be run on real devices so you know that users will successfully migrate without having the launch watchdog kill the app launch and launch again.

Keep in mind that successfully migrating in the allotted launch time isn’t enough. If the app is to all intents and purposes locked during that time, the user may choose to be the Final Watchdog and terminate your app with extreme prejudice. This is your chance to ensure a positive user experience.

Manually Updating the Package

You can manually update the files in an xcappdata package to create a new snapshot, but beware of a few things:

• “Modern” SQLite adds .sqlite-shm and .sqlite-wal files next to the .sqlite file for write-ahead logging. Be sure to keep all these files in sync with a changed .sqlite file by using an editor that understands these files (I recommend Base, I’m sure there are others), or copying/replacing these auxilliary files if you replace one .sqlite file with another.
• NSFetchedResultsController caches need to stay in sync with data store changes, too. Delete the .CoreDataCaches directory from the package, run this package on a device long enough to exercise all the NSFetchedResultsControllers, then download that package as the one to keep.
• Your app is probably more complex than the example shown. Ensure that documents stored external to the SQLite files are where they are expected, and in sync with any other changes.
• If you can get a data file from a user or tester who is experiencing problems, that is golden. Migrate that data file into its own package and name it something like v3-bug16002 to enshrine it in your migration testing history. Not only will this help you debug it, you will have it available going forward to avoid regressions.

Notes and Tips

• The demo app saves the context every time an item is added. If your real code does not do that, be sure -save: is invoked at some point before you try downloading the xcappdata or you will not have the data you thought you had.
• Application Data settings persist with the scheme. I find it useful to create a new scheme named “Migration Testing” and only test migrations with that scheme. This isn’t necessary, but it’s good to know that when you’re using the app’s self-titled scheme, you aren’t accidentally resetting the data every launch.
• Git for one doesn’t track empty directories. In my experience it isn’t worth worrying about because the app’s sandbox gets laid out correctly even without directories like /tmp in the xcappdata package.
• Be sure you don’t add the packages to the app targets. This just copies them into the app bundle as resources and bloats the app.

Radars

• rdar://17495757 – iOS NSFetchedResultsController: Stop hiding caches directory
• rdar://17539241 – Xcode: Allow creation of .xcappdata packages from Simulator

@pgor have you considered using NSStringFromSelector(@selector(property)) when having to hardcode a property string? Seems cleanest to me

— Riley Testut (@rileytestut) March 22, 2014

This does look like it would be cleaner. There’s not a “magic string” involved, and with the “Undeclared Selector” warning (GCC_WARN_UNDECLARED_SELECTOR) you would be warned if a property changed and your @selector wasn’t updated. Upon closer examination, though, there are a few problems.

Problem the First: Declaration

The proposed construct is not a compile-time constant, so I can’t just change my

NSString* const EventKeyTimeStamp = @"timeStamp";

line to

NSString* const EventKeyTimeStamp = NSStringFromSelector(@selector(timeStamp));

There might be a way to pull out some compiler attribute-fu to initialize this properly, but I doubt it would be able to keep the const qualifier that makes me feel safe.

The next step would be to eschew the constant variable declaration and just use a #define in the header:

#define EventKeyTimeStamp NSStringFromSelector(@selector(timeStamp))

I’m not a fan of having actual code in #defines. They always seem to end up causing more trouble and obfuscation than they’re worth, particularly when I write them. I’d much rather just write a boring function or method that I can breakpoint and walk through as a normal part of my applicaton.

But what the heck, let’s go with the precompiler for this one. It works. It substitutes the proper string for KVC and predicates. If you rename the timeStamp property to timestamp it will complain if you don’t change the @selector. All looks well.

Problem the Second: Indiscriminate Selectors

The confidence we gain from this method is based on the undefined selector warning firing if we change the target property name. Simple testing bears that out but unfortunately that’s not the case.

The undefined selector warning will be satisfied if it sees a matching selector anywhere in the current compilation unit. You may think that because our #define is in the NSManagedObject’s header, that compilation unit is just the MO and the (hopefully limited) #imports from that header. Unfortunately, #defines are first substituted into the code in-place then evaluated. So when evaluated, its compilation unit includes every header the client code has imported—if any object in that unit has a matching selector, the warning will be satisfied.

If we rename -timeStamp to -timestamp and any object in the current compilation unit has a -timeStamp method, we will not be warned that we did not update this constant and it will fail in KVC and predicates at runtime.

Any object.

If you can guarantee that you can create some code in your project that will never experience that kind of cross-contamination, it can be the alert system for validating your property constants. If not, the confidence using NSStringFromSelector in this case is sadly most likely false confidence.

At this point, I see no benefit to NSStringFromSelector in this manner. Admittedly, my constant string mechanism is no more reliable in alerting me of these problems, but my aversion to code in #define statements will keep me using constant strings.

Unit Tests!

If you really want safety for this (and you should), I still believe that unit tests are the most reliable way to do it.

- (void) setUp
{
  [super setUp];
  self.managedObjectContext = [MyTestContext createInMemory];
}

- (void) testAttributes
{
  Event* event = [Event insertNewObjectInManagedObjectContext:self.managedObjectContext];
  
  NSDate* testDate = [NSDate date];
  event.timeStamp = testDate;
  XCTAssertEqualObjects(event.timeStamp, testDate, @"timeStamp property failed to store properly");
  XCTAssertNoThrow([event valueForKey:EventKeyTimeStamp], @"KVO property '%@' doesn't exist", EventKeyTimeStamp);
  XCTAssertEqualObjects([event valueForKey:EventKeyTimeStamp], event.timeStamp, @"KVO value differs from property");
}

I don’t remember most of what we discussed; I didn’t even remember much of it immediately afterward, it flowed so smoothly. One thing I do remember is that I said Metrowerks was integral to the Intel transition—instead, they were part of the earlier PowerPC transition. I’m not a historian of any kind and I don’t pretend to be. I misspoke and know it, so I don’t need to be set straight. Thanks.

Now I guess I should listen to the episode to be reminded of what I said, even if it involves the agony of listening to my own recorded voice.

Update: Huh, I did correctly say “PowerPC”. See, I’m not even a good historian of things that happened less than a year ago.

Update: Video is now live. -18mar14

Then Brent Simmons linked to them and I feel like I’ve been fielding questions, comments, and a pleasant number of kudos ever since. I feel like I should post some clarifications here now.

This talk was pretty much a complete last minute change from what I’d prepared and presented internally to Black Pixel coworkers two days earlier because I wasn’t happy with the boring textbook feel of that talk. If you don’t feel it was a polished set of slides, you’re absolutely correct.

Multithreading

Please keep in mind the last few slides on Core Data multithreading are woefully inadequate. I’d intended to cover it more thoroughly as part of the “potpourri” concept but the list of “best practices” grew to pretty much be a list of many things I’ve been ranting about to others for the last year or so, and that I’d been sprinkling throughout client projects. I was tempted to ignore it (like I did the empty slides on performance optimization and multiple persistent stores) but felt I should reward people for sticking it out through the talk.

I warned the audience before discussing it that there would be a lot of handwaving and no code examples were ready—but that surely doesn’t come across in static slides.

Mogenerator

The “Why Not mogenerator” slide has been the lightning rod, as I’d feared—I’ve learned you can expect that whenever you call something out in any negative light. Hopefully when you see the actual talk, it will come across as I intended: A response for when someone asks me why I do this “by hand”, not a screed trying to wipe mogenerator from the face of the Earth.

By the way, there’s one response to “how do you handle when you have to regenerate classes” that I didn’t even manage to get out during the presentation: Git diff. Honestly.

Parent-Child Contexts

This is multifold. First, I consider my “enlightenment” regarding multithreaded Core Data to have come during a project targeting iOS 5.1. The new contexts weren’t an option on the project, and seeing coworkers fight the nightmares of that initial release of contexts convinced me to not bother looking into it for a while. Since then, I’ve become comfortable enough in the “one reader context, multiple serial writer contexts” mechanism that I haven’t found many compelling reasons to make parent-child my default.

Second, I strongly believe that understanding the implications and combinations of the rules “each MO belongs to only one MOC”, “MOCs are not threadsafe”, and—perhaps most importantly—“loaded MOs need to refresh somehow” are key to writing successful multithreaded code. After that, parent-child contexts can make great tools but too many developers treat them as the cure-all that will let them just ignore these aspects. Parent-child and thread containment can work together, it doesn’t have to be either-or.

Miscellaneous

It was pointed out after the talk that my “+newInstance…” method for managed objects returns an autoreleased object and will break MRC conventions. Totally correct. This is mostly due to me having tried to clear out MRC space in my brain for new knowledge, but also because I threw together the talk with code examples from numerous different projects, and my naming conventions have tended to change over time. I’m sure there are other such problems in the slides—you’re free to “Be Better Than Sample Code”. :)

“NSManagedObject Is the Real Top of the Stack” might imply that you don’t have to worry about keeping a strong reference to that parent MOC. Don’t forget that -managedObjectContext is a weak reference and if a MOC is deallocated, any of its MOs are now invalid. In practice, I rarely have an issue with this since I’m keeping one readonly MOC around for all my UI needs, but this is definitely something to be aware of. I still feel it’s not worth the confusion of passing/configuring them separately.

I hope this clarifies some issues people have had. I hope you watch the video when it’s released but be warned that it will probably run about 100 minutes with talk and Q&A. (I’m told Q&A was actually truncated due to SD card storage limits.)

Except I disagree. I’ve been down a number of UITableViewCell paths that bit me in the end, many of which Brent seems to have experienced as well, but I have ended up settling on creating UITableViewCell subclasses which take the model object they’re intended to display and break out the properties to the individual subviews so the controller doesn’t have to.

At its core, I’m taking code Brent would write like this:

- (void) updateCell:(MyTableViewCell*)cell 
     forModelObject:(Model*)object 
{
   cell.nameLabel.text = object.name;
   cell.valueLabel.text = object.value;
}

out of the controller and moving it to the cell as

- (void) updateForModelObject:(Model*)object 
{
   self.nameLabel.text = object.name;
   self.valueLabel.text = object.value;
}

(Yes, he defines it as -updateCell:forIndexPath: but -updateCell:forModelObject: can always be refactored out of that once the object is found for the indexPath.)

There may be some additional smarts in there: The color of valueLabel may get changed at a threshold value, the name text may need some truncation or transformation, an icon may change from sun to moon depending on a timestamp in the object. I’ve left them out of the example for simplicity.

At this simplistic level, they look identical. Yet I still feel putting the logic in the cell is superior. Why?

Polymorphism

Look a bit closer at -updateCell:forModelObject:. You may not even have noticed it, but there’s a distinct absence of the keyword self. This isn’t encapsulation; this method is really just a utility method, which could just as easily be written in C: 

void UpdateCellForModelObject( MyTableViewCell* cell, ModelObject* object );

Why is this bad? It throws away polymorphism, one of my favorite aspects of object-oriented programming. Let’s start with a theming example: We want to allow the user to chose between a set of differently-styled themes in which to display this homogeneous set of data.

This is fairly simple if it’s limited to colors, fonts, and other style-only changes in the themes—change the style in -tableView:cellForRowAtIndexPath: and continue as before. What if one theme “FirstLast” should display my name as “Paul Goracke” and theme “LastFirst” should display as “Goracke, Paul”? The table view controller needs to know this difference. It’s an implementation detail of the theme, but under this design the controller doesn’t just need to know about it—it needs to implement it.

It will need to implement the quirks of every theme supported. Not bad enough for you? How about this: It also needs to determine which set of theme quirks to use each and every invocation of -updateCell:forModelObject:. Why would you want to do this? I don’t.

By putting the logic in the cell, you only check the theme in -tableView:cellForIndexPath:.

1. Dequeue or create a cell of the appropriate type MyFirstLastTableViewCell or MyLastFirstTableViewCell.

2. Call -[cell updateForModelObject:] and the receiver cell will update as appropriate for the single theme it implements.

3. There is no Step 3.

This is the glory of polymorphism: No matter how many crazy themes I make, the table view controller only needs to know which class to make for the specified theme because the subclass knows its specific implementation. If I decide to sunset a theme, I don’t have to worry about code cruft hanging about in the controller to handle that obsolete theme.

Polymorphism with Heterogeneous Model Objects

A heterogeneous data set in and of itself wouldn’t be a problem as long as all objects provide the core set of properties the cell requires to display the items uniformly. (Such would be the case with Brent’s Twitter app example.) Your cell(s) now take -updateForModelObject:(id<ModelObjectProtocol>), they don’t care which particular protocol implementor you pass them as long as they provide the properties needed to display them, and you move on.

But what of a heteregeneous set where each object type needs to display differently?

Once again, the logic of which cell subclass to create lies with -tableView:cellForRowAtindexPath:. After that, updating the cell’s display of model object property changes is handled by the cell. If the model object at that indexPath were to change type, call -reloadRowsAtIndexPaths:withRowAnimation: on the table view to have it ask for a new or dequeued cell of the type appropriate for the model object’s new type. 

What Makes a Controller a Controller?

Unfortunately, Apple seems to have unintentionally muddied the MVC waters by naming their main controller class UIViewController. Many developers now have an extreme view of a controller: If it touches both a view and model object at all it needs to be a UIViewController. Nothing could be further from the truth. Unless you need lazy view loading and view appear/disappear lifecycle management, creating a UIViewController just overcomplicates matters.

Let’s look at Apple’s schematic of MVC, even though it should already be burned into every Cocoa and iOS developer’s brain:

It’s easy to get caught up in defining these objects based on their positions in the diagram, but what really defines them is their role within the system and how updates propagate. Keep in mind that these arrows are not object references, but interactions via updates and notifications—think of them as IBActions more than IBOutlets.

When a UITableViewCell subclass accepts a model object parameter and updates its constituent subviews as I have described, it is behaving as a data transformer, not a controller. It does not care about any future updates to the model unless the controller tells it to transform the updated model object, or to transform a completely different model instance.

Keys to Success

• Avoid the temptation to bypass the controller and start key-value observing (notifications are also verboten) on the received model object. This is the hubris that will lead to your MVC downfall (been there, done that). Leave all of the updating logic to the “true” view controller, and your cell subclass will remain a happy and healthy data transformer.

• Don’t even keep a reference to the received model object. Not only will this help avoid the KVO temptation, but it will encourage you to quickly move the property values into the appropriate subviews and let them take care of drawing, caching and refreshing.

• You’re a UITableViewCell—you’re displaying only one in a possibly innumerable collection of model objects. Leave the handling of the set of model objects to your UIViewController<UITableViewDataSource> which should be invoking tableView updates based on responding to UIFetchedResultsController or KVO, but there may be other update logic involved. That is, after all, the purpose of a controller.

• Keep your cells stupid. Brent’s examples of loading image or web service data asynchronously is still something to be avoided in the cell.

• Keep your cells simple. Many developers try to handle all possible configurations of a cell in one. They have numerous views which are hidden or displayed based on some model object criteria, which leaves a number of unused outlets lying around; this becomes confusing and hard to maintain. Using polymorphic cell subclasses, you can dedicate one cell subclass to each distinct configuration, avoiding unused views and code maintenance overhead.

Conclusion

There is absolutely nothing wrong with Brent’s minimalist guidelines. They will serve you well in many situations. But once your code base gets more complicated, I think you’ll be better served by not fearing better encapsulation of behaviors. Passing a model object to your cell is really only a venial sin.

Everyone has their own definition: Advancing in one’s career; saving enough to retire; finding a significant other with whom to build a happy, healthy family. Complicating matters further, “success” has much finer-grained contexts: Each successive day of kicking a bad habit; completing a project milestone; passing a test in school. Many “personal improvement” programs would even propose that “success” is only measurable as a continuing accumulation of completed milestones, not any one observable point in time.

So why in the world do you think you can capture “success” in a boolean?

BOOL success = [self doSomething];

That method you just called actually did something, and it did something concrete: It deleted (or saved) a file on disk; parsed some JSON; validated an encrypted string.

Don’t try to capture success in a variable. Name your booleans for what the code actually accomplishes and you’ll find the following logic is much more readable with a decreased likelihood of logic bugs.

Last fall, we were in the crunch-time week for a client’s app before the iOS 5.0 submission deadline. I was profiling it in Instruments, trying to find where we could improve its launch-time performance, when I found a noticeable amount of time was spent in Address Book queries by a third-party video tracking library.

Not only was this behavior slowing down our launch, it was unexpected and—since it was a binary library without source code provided—we had no idea what it was doing with that information. A red flag was raised, and to my surprise the client even expressed willingness to cut the functionality until the questions could be answered.

As explained, the usage was almost clever: By adding a defined contact to your address book, you would unlock additional debug logging and reporting options for their SDK. They claimed that there were numerous applications already approved with this SDK, and I don’t feel the need to question their veracity. Most importantly, they offered a build without that functionality, provided it quickly, and that’s what shipped.

So it disappoints me that after my own personal experience of trying to keep code out of the Address Book, there are developers out there who apparently don’t think twice about slurping all of your contacts and sending them to their servers without your express permission.

This has happened before with Aurora Feint. It forever tainted my opinion of Open Feint, which came out of that. I had been under the impression that Apple was much more strict about this type of behavior—“chance of rejection” was one of the main reasons I brought attention to the library’s unexpected access. So I’m disappointed in Apple, too.

There have been calls for Apple to add required guards and notifications to the API’s access, similar to how Location Services is handled. That would probably be good, but at a certain point all the notifications just become “Grant Access?” alerts that users don’t think about. I think there’s a simpler way to do it, at least for a first attempt:

1. When submitting an app to iTunes Connect, ask “Do you access and transmit Address Book data?” similar to the existing question about using encryption.

2. Answering “yes” is a flag to the review team to verify that the developers have implemented their own reasonable opt-in mechanism, and maybe even a bit more scrutiny of their network traffic.

3. If an app is found to be violating this, terminate the developer’s account.

Yes, I feel that violating this expectation after making it clear that you are expected to be transparent about using this kind of information is worthy of booting you out of the App Store.

Thank you, Mr. Jobs. Thank you, Jobs family, for sharing him with us.

Most of the complaints about the patent system being “broken” come down to a few points:

1. The patent is not novel; it’s an obvious method to anyone spending any mental effort on the problem space.

2. The patent is too broad; It could cover any number of possible techniques without taking a stand on one (or a handful). This usually seems to be done to get around the requirement of sharing the information, keeping aspects proprietary. One might also consider this related to “not novel.”

3. The inventor (or, usually, reassigned rights holder commonly referred to as “patent troll”) has done nothing with their rights to the patent on their own. On its own, there is nothing wrong with this—it would be perfectly legitimate to have a sole licensee. When combined with items 1 or 2, though, most people agree that it’s is predatory and stifles innovation rather than encouraging it.

My Proposal: Within a defined grace period after patent status is granted (I’m envisioning 5 years, maybe 7), the patent holder must show measurable revenue due to a concrete implementation of the patent, or that it is a recognizable part of another product which generates recognizable revenue. This revenue may be recognized directly by the inventor, or by licensees of the patent. If such evidence is not given within the grace period, the patent is considered fallow and control rights are revoked.

A patent that does not result in a concrete implementation within a reasonable period of time is hard to consider as “benefitting society” and thus unworthy of the rights exclusivity granted by the society in exchange.

I just received word that the 2.0 update to ESPN Passport—the last fruits of my contracting with the fine folks of RogueSheep before joining Black Pixel—went live on the App Store today. What started out as “add Facebook Places functionality” became a much smoother, more efficient and focused application that I was proud to have a part in.

If you’re at all interested in adding a social network aspect to your sports watching, go check it out. It’s free, but you’ll need to sign up for a free ESPN Passport login to get the most out of it (Facebook and Twitter logins add even more).

(By the way, have you tried RogueSheep’s latest app, Easy Alarms? I played no part in it, but it rocks all the same.)

During an entertaining aside in Andy Ihnatko’s keynote at this weekend’s Voices That Matter conference, I was reminded of a thought I’d had a while ago: Why don’t Mac desktop applications store their license info in the Keychain?

Complaining about restoring license keys should be just as trite of a humor topic as little bags of peanuts on flights, but it still holds true. Go to restore a machine, or move to a new one with a clean install, and you can write off at least an afternoon launching and entering at least two text fields per application.

Maybe I’m the only one who feels quite comfortable with syncing to MobileMe—I actually consider it the feature that keeps me coming back. (I do know there are people who have frustrating issues, and I truly feel for them, but I continue to believe they are in the minority.) Given that setup, here’s how I’d see setting up a new laptop:

1. Configure my MobileMe account and sync down the data, setting up my Mail accounts, Address Book and Calendar—and Keychain.

2. Launch a new copy of my licensed application.

3. There is no Step Three. Go on your merry way.

I’m not expert enough to suggest that it would improve security of your key, but it sure would discourage casual tweaking more than the plist or hidden file schemes you’d need to develop on your own. Also, separation of license key from a preferences file (hopefully developers are already doing this) allows a user to delete the preferences and start fresh without having to worry about relicensing.

I understand that Keychain development can be convoluted, but is that reason enough to not make the user’s life a little bit easier and your support burden of finding a lost license a little less frequent?

As I said at the top, I realize I’m talking out of my…hat here. I don’t have experience doing this (yet), so I am interested in hearing reasoned arguments. Until and unless this is proven untenable, simply consider it a feature request for your next release.

There seem to be some quirks (all videos and podcasts are marked as unplayed on the device) and other behaviors I’d like changed (watching/listening to a podcast on the device doesn’t report that to the shared library). These niggles are really just small issues compared to the big advance of having access to my full library.

Thank you, iOS team!

2010 was one heck of a slingshot year for me and Corporation Unknown. I started the year unemployed and thin on contract work, and finished it with Corporation Unknown’s highest revenue in its 3-year history and a job offer I can’t refuse.

Bankruptcy

After starting out looking promising, 2009 was rough. The latter half was my first try at full-time independent contracting. I spent time working on project proposals where the client apparently went with someone willing to work for $25/hour; I did work on a decent project (iPhone client for the web site they were developing) that then went “on hold” once the company I was subcontracting for realized that their client was behind on payments to the tune of six digits. (They paid me in full, I don’t know if they ever got the same.)

At the beginning of 2010, my wife and I filed for personal bankruptcy. This isn’t something I’m proud of, but I refuse to hide it as a personal shame. I debated even mentioning this here, except for two points I hope might be able to help others approaching a similar situation:

1. Start looking into bankruptcy before dipping into retirement savings. Most likely, those funds are protected from the proceedings and you won’t have to start over.

2. The idea of paying a lawyer $3k to file for bankruptcy seems wrong, doesn’t it? It was completely worth it. Under our attorney’s advice, we knew exactly what to expect with no surprises. Sometimes when trying to restart parts of your life, it’s refreshing to just chuck it all and walk away, consequences be damned—this is not one of those times.

Contracting

Independent contracting in 2010 was hot and cold. More accurately, cold then hot, and feast or famine. I’d go without prospects for a while, then have a few come all at once that I actually had to choose from. Managing a client pipeline is not easy as a solo contractor.

In the spring, I had the opportunity to work with local friends Black Pixel on a small part of a fairly large project for iPad—before its release. It’s hard to believe the iPad hasn’t been out a full year yet; recalling having to code for iPad without a test device feels like reminiscing about the punchcard days.

I had a good time working on that project, even though it was all too brief. The team was wonderful, and even though it feels unfair, I have to single out the experience of working with Chris Clark. It was the first time I’d had the opportunity to work on an iOS project with a dedicated designer—one who listens, takes feedback, and respectfully tells you you’re either wrong, or he just prefers his design anyway—and I loved that.

At that time, I was also working on a project with a existing client. They had an iPhone app that I had cleaned up somewhat, and the announcement of iPad seemed an ideal fit for their product. Unfortunately, in the early days of the iPad, I still needed a lot of experimenting to get a feel for what “worked” and what didn’t. In their desire to get in to the field as quick as possible, they felt that the project was taking too long and ended up opting out of the contract.

Then in May, I had the opportunity to do some subcontracting work for fellow locals RogueSheep. The project was for a component of an iPad app that, once I got past the “why would you want to do that?” aspect, provided some interesting challenges in designing custom controls and animations, and I loved that.

RogueSheep is another great team, and another great designer in Brad Ellis (even if he has since moved on to Square). Brad has the same positive qualities as Chris, with the addition of slightly crazier ideas that push you to create something you wouldn’t have imagined on your own.

Thankfully, the Sheep have continued to have a project pipeline for me to work on: I wrote another bit of code that I’m not even sure has made it onto the store yet for the same client; I wrote some UI code for RogueSheep’s own TouchUp for iPad application as they were readying it for release, and I’m in the process of finishing off another pretty major iPhone project for another of their clients. They even let me touch their Apple Design Award.

Thanks in large part to RogueSheep, in its first full year of full-time effort, Corporation Unknown has recorded its highest annual revenue:

Onward

This year already has some promising challenges ahead:

1. Beginning in March, I will be teaching “Developing with the iPhone SDK,” the middle course of the iPhone and Cocoa Development certification from the University of Washington’s Professional and Continuing Education.

2. I have accepted an offer to return to Black Pixel full-time beginning in February. It’s been tough feeling like I’m choosing between two great companies and teams, but I am really excited to be rejoining Black Pixel’s now-expanded team and continuing to kick some iOS butt.

3. On top of all that, our second child is due at the end of July.

2011 is going to be a busy year!

I was going along, minding my own business, implementing a typical -tableView:didSelectRowAtIndexPath: delegate method to create a view controller, push it onto the navigation stack, and then…nothing. The view didn’t appear, and the app interface became unresponsive. Numerous pauses in the debugger showed what would appear to be normal stacks in the running of the app—no infinite recursion going on, thankfully.

The view was actually in a strange nesting of UITableViewControllers, UINavigationControllers and UITabBarControllers, so I reworked that to the bare bones of a UITableViewController pushing a freshly made UITableViewController onto its navigationController. I verified that it was being initialized properly, and that I had a valid navigationController to push onto (and other view controllers did push with the same navigationController). Still no change.

Then I added breakpoints to every UITableViewDelegate and DataSource method I’d implemented, even the trivial hardcoded ones (“return 3;” for -numberOfSectionsInTableView:) at first to ensure they were being called (they were). Thus began the tedium of following the chain of 4 or 5 calls per table row until I found the offending code.

This new table view is composed of a number of sections each composed of only one cell. The cells are designed in Interface Builder as top-level objects, and are IBOutlets of the File’s Owner View Controller. Technically, it’s one big scroll view but I’m using this design to provide some layout flexibility if the client wants to reorganize sections, and I thought it would be cool to have the dynamic scrolling of section headers, too.

Since I want the IB objects to define the layout, I determine the height of each row based on the view’s frame:

height = CGRectGetHeight( self.playerStatsCell.frame );

The value for height of this cell (the last on the list—the others were fine) was a “whopping” 6.30104785e-38. What was going on here?!

Well, self.playerStatsCell wasn’t actually connected yet because I was testing (trying to test) one row/section at a time. Calling the frame method on a nil object seems like a normal thing to do in messaging-nil-happy Objective-C. But it’s not. The call is effectively short-circuited, and the temporary CGRect variable the return value was supposed to fill is left uninitialized, which is the bizarre height value returned by CGRectGetHeight.

This call is equivalent to:

CGRect frame; // uninitialized struct
frame = self.playerStatsCell.frame;
height = CGRectGetHeight( frame );

A simple change to the following would fix it:

CGRect frame = CGRectZero; // initialized struct
frame = self.playerStatsCell.frame;
height = CGRectGetHeight( frame );

(In my case, I resolved it by connecting a temporary cell object in IB.)

What did I learn from this?

1. Messaging to nil is normally fine, but definitely not for struct-returning methods.

2. Returning a cell height that is very, very tiny from -tableView:heightForRowAtIndexPath: results in “strange behavior.”

I still don’t know exactly what the app was doing while it wasn’t displaying the new table view, but now I know what to quickly look for when I can’t push a UITableViewController in the future.

At some point, after I’d explained a few times why you have to write software this way on Android, I started wondering why all software, without exception, isn’t written this way by default.

As of 10.6, Apple added enableSuddenTermination and disableSuddenTermination calls to the NSProcessInfo API to allow you to implement similar behavior on the desktop. At its most simplistic description, you can inform the system your application doesn’t need to have its memory paged back in just to destroy it all—just kill the process and you will be sure it behaves properly on relaunch.

I encourage all fellow iOS developers who have already acquired a “sudden termination” design style to make note of this when developing a desktop Cocoa application; I also encourage desktop Cocoa developers to start thinking about how they would design with this paradigm, as it will be one more portable technique when and if you decide to go mobile.

(NSCache and Purgeable Memory is another new-to-10.6 mechanism I consider similar to iOS’ didReceiveMemoryWarning, only giving the OS permission to purge memory instead of it requesting you clean up.)

Want: iPod on iPad able to browse desktop iTunes à la Home Sharing. Watching WWDC videos on iPad w/o having to sync first—yum.

I received a few recommendations for Air Video and StreamToMe. I’d forgotten that I’d downloaded Air Video but hadn’t set up the server; I’d also forgotten about StreamToMe even though I subscribe to Matt Gallagher’s blog.

I fired up the Air Video Server and started it serving the iTunes U playlist. Connecting and browsing from the iPad client was simple and straightforward. Trying to stream a WWDC video paused to buffer annoyingly often—which I blame less on the software than the 2GHz Mini it was running on, which probably also had the misfortune to have Time Machine kick in at the same time. But it doesn’t seem to have a functionality I implied by the “Home Sharing” reference: Copy the video to the iPad to watch elsewhere later. StreamToMe looks to have similar features (and lack thereof) to Air Video, so I didn’t test it.

I appreciate the recommendations, I really do. But neither of these can get past the one requirement I didn’t specify: I don’t want a third-party solution. My tweet was really a passive-aggressive desire to have Apple implement this.

I have fully committed to iTunes being my central media repository. It serves 157GB of my music, 148GB of movies, 100GB of TV shows, 144GB of iTunes U videos (primarily WWDC videos) and a variable amount of audio and video podcasts. As a result, I don’t have many files in formats foreign to iTunes, which both these applications seem focused on solving and I expect they handle admirably.

Both of my AppleTVs can access any file in the desktop’s iTunes library, even though with 40GB and 160GB drives they obviously can’t hold copies of everything. (True, I can’t instruct an AppleTV to copy files to itself, but I don’t feel the desire to pick it up and take it elsewhere, either.)

My iPad cannot access all the files.

My laptop can browse any file on the desktop’s iTunes library; thanks to Home Sharing it can copy any file just by dragging it to the local library. It can even browse other libraries that are shared on the network.

My iPad cannot copy files to its local library, or browse other shared libraries.

The “digital plumbing” is there in DAAP and Home Sharing to make this happen, but third party developers are left to write their own servers to support their clients. I have no reason to distrust InMethod or Matt Gallagher—and I’m pretty sure that either of them can write a better server than I ever could—but each additional server increases the likelihood of conflicts and security problems, so I don’t want to install and maintain additional, practically redundant servers.

I want a digital hub; one machine serving the same media in different ways is not a hub.

During the iPad announcement, Steve Jobs positioned the iPad as a third type of device “between a laptop and a smartphone.” In my experience, that’s an astute description. In regards to media handling, though, I feel the iPad still behaves much more like my iPhone than my MacBook Pro.

Download the Corporation Unknown configuration for Accessorizer.

At a previous employer, we ran into issues where newcomers were confused by Objective-C’s memory management, especially the differences between using properties (and dot notation) and directly accessing the ivar. As you might expect, this led to many memory-related problems. I’ve long been a proponent of only using accessors to access a member unless you have a darn good reason. (And Cocoa’s ? automatic key-value observing makes it even more difficult to have a good reason not to.) In order to visibly identify accessor-vs-direct access, we instituted a naming convention to make direct access look wrong: ivars are named with an underscore prefix (“_ivar”) and properties are not. To make this even more obvious that ivars are implementation details, we declared them @private.

You may disagree with this methodology; that’s fine. But without this context, you might have a hard time understanding my configuration decisions—and why Accessorizer especially rocks in this setup.

When I first started using Accessorizer, I thought of it as a code generator, and it’s hard not to chafe at your disagreements with how code generators generate code. I’ve found that thinking of it as a code template generator makes it easier: Generate the majority of stuff you use, omit the stuff you don’t normally use, and be comfortable with the knowledge that you will regularly have to tweak its output—it’s still better than writing it from scratch every time.

Accessor Style

• “ObjC 2.0 Properties” is always turned on. Period.

• I always use the Defaults Table (more about that later).

• “Detect IBOutlets” automatically inserts the “IBOutlet” declaration into recognized subclasses. Sometimes it doesn’t identify a class I want to be an IBOutlet, but I find this to be right much more often than it is wrong.

• “Append self.view=nil” is a somewhat strangely worded option. Checking it will generate code to nil those properties identified as IBOutlets. Combined with the “–(void)viewDidUnload” checkbox to its right, it will generate a full viewDidUnload method to release your IBOutlets.

• “Assign delegates” automatically overrides your assign/retain/copy property generation setting to be “assign” for any “id” property (or others identified as a delegate form; again, I find more often right than wrong).

• I uncheck “Omit assign for scalars”. True, the “assign” is not necessary, but I find it easier to scan for “assign” when I’m code reviewing than have to think about each type and whether it is handled appropriately. (According to Apple’s documentation, “assign” is also required for garbage collection but I haven’t written any GC code yet.)

• “Assign IBOutlets” is unchecked. I guess I’m still in the “retain outlets” camp, until I bother to change my mind.

• “BOOL getter=isValue” automatically identifies a “BOOL running” property and defines the getter as “isRunning”, just as Apple recommends.

• Since I’ve primarily been coding for iOS lately, I declare my properties “nonatomic”. If/when you’re working on the desktop, you probably want “omit this”—change it or create a “desktop” configuration.

• I omit readonly/readwrite. Most of the readonly properties I create are not backed by ivars, so I find I don’t need to override this behavior often.

• I haven’t been much concerned about weak or strong, so I omit it. You may decide otherwise.

• “@synthesize” will create appropriate @synthesize statements when generation the Implementation. (Be sure to check “generate getter/setter”, even though it applies to @dynamic—I’ll explain later when talking about Defaults Table.)

Getter/Setter settings

Not much to say about these settings other than “Use Defaults Table”. They don’t come into play very often, since I mainly use @synthesized properties but these settings work for me when I don’t. To see the effects on generated code, temporarily switch your properties generation to @dynamic with “generate getter/setter” checked and Implementation being generated—changes will be reflected as you make them.

Dealloc

• I default to “self.property = nil” behavior; I know others disagree. If you’re one of them, simply change the option to “release” in your configuration. If you do agree, or simply want to give this way a try, make a point of removing any related KVO or NSNotification observers before these generated lines or you will receive notifications of the nil settings and you most likely don’t want that.

• “dealloc full block” is the primary reason I am not just making my configuration available without comment. If you were to just take my configuration and copy the generated code, it would break your build because I leave this deselected so it’s not in a code block. As I develop my classes, I add ivars and use Accessorizer to generate the related code. Most of the code is pretty easy to wholesale copy-n-paste, but I tend to have more logic in dealloc than Accessorizer can know about (KVO and NSNotification removal, setting delegates to nil, etc.) and I find it easier to copy this generated dealloc code into an existing method than to use this as a dealloc method and move existing behaviors into it. If you want a full dealloc method, just check the box.

Init and Undo

I’m not sure why, but I still tend to write my own init methods. Someday I’ll explore using Accessorizer for this and Undo registration more fully; until then, you’re on your own.

Defaults Table

The defaults table is used to override the “one size fits all” property generation based on the ivar’s type. I have configured every superclass of “NSMutable” to default to “copy” instead of the default “retain” in order to avoid holding reference to a mutable object when I’m expecting immutable. (This is explained in Apple’s documentation.) I don’t even use some of these classes, but when I do I don’t want to be surprised. I’m always free to edit the declaration on a case-by-case basis, but this is the behavior I want ninety-some percent of the time.

Another fun feature of the Defaults Table is the “generation” setting. If you have a class type whose behavior you tend to override often, define its generation as “dynamic”. Every time you use that class type, Accessorizer will generate an @dynamic declaration—and the accessor methods for you to use as a starting template. (This is why I check the “generate getter/setter” in the Accessor tab even though it normally won’t do anything.)

Custom Table

I don’t really use this tab, and I don’t believe any of it gets saved into a configuration set since it’s primarily for point-and-click tweaking of behavior on an ivar-by-ivar basis.

Coding Style

As I mentioned, I prefix my ivars with an underscore, so here is where I define that. By defining my ivar Prefix as “_” and Suffix as “none”, Accessorizer automatically recognizes that underscore and strips it when declaring the property. It also properly declares the backing ivar in the @synthesize directive.

• The Argument Prefix is used when generating methods like -initWith{…}. I vacillate between “a” and “none”.

• Formatting Properties: new to 2.0 is the ability to tweak whitespace in declarations more than you could in previous versions. I’m happy because now I can use my preferred “NSString* title” form; I know many others still hew to the “asterisk must bind the the variable, not type” but you’re free to change it for yourself.

• Formatting Methods: Configure the display to generate some accessor methods and experiment with these settings to see which layout you prefer. The “Tight” spacing option is actually more compressed than I like, but I find the “Spaced” option way too spread out (and I’m someone who loves whitespace). Therefore, I default to “Tight” because it’s easier to insert the few spaces I prefer than delete all the ones I don’t.

• Formatting Pragma Marks: I love me some pragma marks, but try not to go overboard with them. Feel free to experiment.

• Init Style: Apparently, “self = [super init]” is the current Apple-approved format. I’m ambivalent.

Collection Accessors, Keyed Archiving, KVO, Locking, Singleton, General and Sort

Most of these tabs are more hands-on generation of code. You need to enter a class name, and it will generate code right there—I don’t use these as frequently as accessor generation, and you can tweak the layout more directly when you do need it. At some point, I may have changed my settings from the defaults you would encounter in a new install, but I don’t really have strong suggestions for you here.

1. As its name suggests, it will generate the getters and setters for ivars you point it at. It will do this using Objective-C 2.0 @property syntax if you specify it. (I use the 2.0 syntax and revert when I want to customize a getter or setter so i can start with a “standard” usage style.)

2. Automatically recognize UIKit and AppKit classes and mark the properties as IBOutlets.

3. Recognize non-object ivars and set their properties as “assign” instead of “retain”.

4. You can configure defaults for ivar classes (all my NSString and NSData properties default to “copy” instead of “retain”).

5. Generate all the methods for collections to be nicely Key-Value Observing compliant.

6. Generate Keyed Archiving and Unarchiving methods for your ivars.

7. Generate template code for a Singleton class.

That’s really just scratching the surface, but it’s the main functionality I use. As a Cocoa developer, you truly do owe it to yourself to check it out.

What makes me (rather selfishly) consider 2.0 an awesome update, though, is a feature I requested: Configuration Sets. The request grew partly out of encountering co-workers at contracting gigs who didn’t use Accessorizer. There are so many items to customize in the application, a first use could be daunting. If I can say, “Here’s my configuration to get you started,” and pass along my exported Configuration, they’re more likely to use it. (It also helps that they can now feel confident that they can revert after experimenting with settings.)

If I’m working on multiple projects with multiple clients, I can save their specific formatting requirements and switch between Configuration Sets when I change between projects.

If your company has defined formatting standards for the aspects Accessorizer can generate, standardizing with a Configuration Set allows you to quickly bring a new team member up to speed and into compliance.

There are more aspects to Configuration Sets I’d like to see, but they fall on the “magical” end of the spectrum; Kevin has done a great job of implementing the (more than) 80% part of it.

Seriously: Why aren’t you using Accessorizer?

Digression: C4 is/was known for its excellent sit-down meals between sessions. At first, it seemed horribly inefficient to an engineer brain to get up after a session, move “all the way” to the banquet room next door, have to pick out a seat again, only to return to the session hall and have to find a new seat—why not just leave my stuff camped in the same seat all day?

But I quickly heeded Wolf’s advice-slash-admonition to find a different group of people to sit with at each change—and the world opened up. If you went to C4 just for the tech sessions, it was worth the cost but you only got the tip of the iceberg. I met well-knowns and unknowns and learned about their products, their consulting and business development experience, and got to know them without pressure. I may not even remember their names right now (I’m terrible with names) but every one of those conversations built community.

I’m not going to claim WWDC lunches will ever approach C4’s, but you can incorporate a bit of the C4 experience into WWDC: Instead of getting together with the same group for lunch every day, take at least two lunches in the cafeteria area. Find a seat at a table with other people you don’t know, and strike up a conversation to find out who they are, what they do, where they’re from. I somewhat unintentionally did this last year, and I promise you: It will open your eyes.

If you’re stuck for icebreakers, here are some old reliables:

• “What did you think of the Keynote/‘State of’ addresses?”

• “Did you catch yesterday’s Brown Bag session?”

• “What sessions are you looking forward to?” (earlier in the week)

• “What was the best session you attended?” (I love this one later in the week)

Asking where someone’s from or how many WWDCs they’ve attended tend to be short answers that don’t lead to conversations. Asking about shipping software can be great—people love talking about their products—but make the interest genuine so it doesn’t feel like an interview or “I’m only asking about yours so I can tell you about mine.”

Bring your business cards. After or during an interesting discussion, ask for one of theirs and offer one of yours. Periodically review the cards you’ve received during the week to refresh your memory of names and topics—you’ll be surprised how often you’ll run into those same people later.

Keep your own badge visible as much as possible to make it easy to approach you and ask about your company or just say “your name sounds familiar, did you…?”

For more advice on networking, check out Brent Simmon’s “Advice to new developers on networking”.

For more tips on WWDC, Jeff LaMarche’s “First Time Guide” contains nothing but tips I completely agree with. (Except my serious personal aversion to sleeping in public, including on planes.) Wait, I have one extra note: Plan to stow your gear before attending the Thursday Bash. I had my laptop backpack one year, and was miserable.