Second Screen When Working From a Cafe

I feel like I’m pretty close to being as productive in coding at a cafe as I’m at my desk. Before, the combination of sometimes spotty wifi and lack of a large monitor definitely made me feel a bit sub optimal. These days, I bring my laptop, iPad, and mouse and I hardly feel the difference between sitting at a cafe vs my desk.

A big part of this has been Duet Display which allows me to use my iPad Pro 12.9″ as a second monitor. I’ve written about other apps I’ve used to incorporate the iPad as a part of my setup, but the speed that Duet provides really pushes it past the point where I notice that it’s an iPad.

For me, having my mouse (Magic Mouse) is crucial. Finally, these days large data plans on the phone is affordable enough where push comes to shove I can use that when the cafe’s wifi is acting up.

  • iPad Pro (and keyboard/stand, cable)
  • MacBook (and charger, usb-c hub/dongle)
  • mouse
  • headphones
  • iPhone

Total weight: 3169 grams ~= 7 lbs

Total weight of travel setup

Fetch Request Template (Part 2)


I was looking into how to optimize queries in Core Data and wrote some code to test the various ways. It turned out that creating Fetch Request Templates was faster but I had no idea why and wrote a blog post about the results I got in various ways to do fetches in Core Data. I ended up asking about this in Stackoverflow and at first didn’t get much of an answer at first. The next day, I ended up realizing the biggest of the difference between a regular fetch and running on via a Fetch Request Template was that programmatically creating a fetch request it’s required that we provide a sort (versus a Fetch Request Template which doesn’t require the results to be sorted). I was going to update the code to test this assumption and just got around to it.

After a few days of that question on SO going unanswered, someone put a bounty on it and the question got enough attention to get it answered by more experienced iOS devs. I never realized how useful a bounty was.

So as you can see in the screen capture to the right, most of the difference between a regular fetch and a template fetch is due to the absence of a sort. Once I put a sort on the template fetch it was almost as slow as a regular sort – still a bit faster. I’m not sure what the insert/update costs of a index on the sort are but indexing both the search field and sort field doesn’t help all that much. There is still a bit of a difference between a regular fetch and a template search but nothing like the difference in putting an index on the search or sort field.

Again, here’s the code if you want to test other things:


Different Ways to Fetch Data with Core Data

For the life of me, I couldn’t find any decent information about optimizing Core Data fetches, specifically whether creating Fetch Request Templates improves performance. How best to use caches and indexes to improve performance. So I started some sample code to test these questions. Pretty simple app, but it gave me an opportunity to play with a data set from OpenDataPhilly. I picked the test scores of Pennsylvania high schools. Maybe, I’ll write something else using this dataset.

The source is up on github.


  • Creating a Fetch Request Template is about 9 times faster writing out a NSFetchRequest.
  • There’s got to be something I don’t understand about setting the cacheName value of NSFetchedResultsController, but it’s exactly the same speed.
  • Creating an index improves performance as expected, approximately about an order of magnitude on this specific test.
  • At first I thought that maybe creating a Fetch Template created an index which is why it improved performance. But it’s definitely more than that because when I created a Fetch Request Template on an indexed field, it improve performance even more.

Testing iOS Apps

At this moment, if you search on Google for “unit testing ios,” the second result points to a page on Apple’s developer site that is outdated and now points to a generic “Tools Workflow Guide.” Most of the first page of results are really brief overviews on the topic or dated. Coming from Rails world, perhaps I was spoiled by the abundance of mature frameworks with tons of examples, tutorials, documentations, and even whole books on the topic. As much as I really enjoyed diving into the world of iOS development, I was very disappointed by the dearth of tools/documentations available on this front. I’m just starting to cover new code I’m writing with tests.

I’m writing this in May of 2012 so using Xcode 4.3. Apparently, until 4, the built in tools kinda sucked so GHUnit was pretty popular. As of Xcode 4, OCUnit is a very reasonable tool to use. Combined with OCMock, pretty easy to setup, easy to use, and good enough for me for now. These tests are compiled and there’s no system environment to load so they run fairly fast. I miss being able to have tests run automatically when I changed tests or code. I also miss being able to run specific tests. I’ve read somewhere that some consider this behavior a feature. Meaning that it’s best to always run all your tests. I’m not sure I buy this, but I don’t really care as long as they run fast.

It looks like there are some other functional/integration testing tools they seem a bit immature to me still. For now I’m just going to be sticking with built-in tools, a.k.a. using Instruments/Automation to record user testing scripts. This basically requires a functioning app to create these tests though. So I think the workflow for me will be to write unit/functional tests in OCUnit, implement the feature, then write integration tests in Instruments/Automation. I’m not religious about TDD but I did appreciate that it really got me write more tests. As with most people, I find it hard to get excited about writing tests for features already implemented. As much as I believe in the ability of these tests in reducing the overall implementation time, for me, the best incentive is to make the process of writing tests more enjoyable for myself.

The app I’m primarily working on now had zero test coverage before I started. It was apparently bit of a rush to implement features until now, the codebase was a rather hacky around the edges, no model layer to speak of (not using Core Data, basically no separate model code, and not syncing information with a backend). Largely due to not using Core Data in the first place, the app tended to use idiosyncratic ways of doing things in favor of idioms/apis/sample code that Apple lays out in its documentation. The scariest part was that the app was interconnected to other parts of the codebase in ways that made the app brittle to change. By far the thing that would have help on-boarding on to this app that much easier would have been to have some tests to run while I was getting familiar with the codebase. It’s hard inheriting then refactoring/adding features to a codebase you haven’t written, but to do it without any sense for how your changes are affecting the rest of the codebase is pretty nerve-wracking. I don’t think this benefit of writing tests for your code is covered enough. Having reasonable coverage helps when you have a team of people working on something, and especially when you add to the team after foundations have been laid out.

I decided to go with for my side iOS project. A few reasons (thanks Jon for highlighting these).

1) It’s a small, well scoped project that is potentially going to have real users.
3) I’m pretty sure I can get my teammates at to help me test and promote it.
4) Thanks to Bel, I’ve already got pretty UI assets to use.
5) It’s an excuse to play with MapKit and CoreLocation.

If you want to help test this as I build it, let me know and I can add you as a tester and you can my latest development builds on your iPhone (iOS 5.0+ and no iPad support).

If by some chance you want to help or see the code:

Don’t have much yet. The UI is wholesale ripoff of the iOS Maps app. And I will probably continue to copy everything down to how they handle directions and settings.

Adding UIActivityIndicatorView aka “waiting” spinning gear

Kinda hard to see, but there is a spinning gear on top of the Sign In button. Why are the examples on the Internet so convoluted.

Next Personal iPhone App Project

It’s been a little over three weeks since I’ve started working for KinderTown and I’ve been living iOS day and night (literally dreaming about it) for about 4 weeks now. Definitely learning a lot working on the KinderTown app every day, but I would like to start a personal learning project for learning iOS 5 specific features that I don’t necessarily get to work with during the day (at least not yet, probably another month or more). So I have 3 options that I’m vacillating on.

  • Redo my first iPhone app, right this time. It really was the bare bare minimum and I was too curious about the app review process to not submit it. It’s embarrassing to have it under my name, I need to either delete it or update it.
  • Rebuild as a native iPhone app. It was a startup weekend (August 2011 in NYC) project that Jon Zepernick and I hack together in PhoneGap. It would be interesting to build it out to the point where the data about where these covered public spaces are and where the entrances/exits are is crowdsourced. Users update the public dataset that gets pushed out to all users.
  • Build a multi-player turn or round based game. Probably 3-5 players, a really simple game. This is the most ambitious even if I’m really good about keeping features down to the bare minimum. Also, this requires more design (both graphical and game mechanics).

Let me know if you have any input.

WWDC 2011: Introducing ARC

Fully understand these keywords, e.g. __weak.

20:45 The 4 rules of using ARC.

30:40 It’s faster.

40:30 all variables initialized to nil.

45:36 Method Families. alloc, copy, init,mutableCopy, new transfer ownership.

50:30 Migrating to ARC

53:46 switch statements need braces if you’re declaring variables.

54:20 Singleton Pattern

57:29 Compatibility Library can’t use weak references. Use __unsafe_unretained instead. So basically learn where to do weak, strong, ? references. And where weak, use __unsafe_unretained instead.

ARC Qualifiers – Declared Properties: strong, weak (if deployed to pre 5.0 then unsafe_unretained)
ARC Qualifiers – Regular Variables: __strong, __weak, __unsafe_unretained, __autoreleasing


Xcode & Debugging


Make sure to your IBOutlet targets still exists:

When a view is about to load, it just simply crashes. No error message. This happens if there are objects in that view that are suppose to be connected to an IBOutlet (at least the xib thinks so) and that IBOutlet is not longer there.

This looks like a promising read:


WWDC 2011: Introducing Interface Builder Storyboarding

command-d: duplicates objects in Storyboard.

So you can have multiple segues to a scene.

To send information back to a parent scene, establish a protocol and have the parent conform to that protocol (see 30:20). Need to review establishing protocols and concept of delegate to get a 100% understanding of this.

We should use popover for share buttons.