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.)

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.