Command Shift

iOS development and other nonsense

by Richard Turton

Stop Nesting Animation Blocks

Chaining animations together has always been a little bit awkward. You’d do the first step, then in the completion block, do the second step, then in that completion block, do the third step, and so on, until you close it all off with a staircase of doom:

1
2
3
4
5
                }];
            }];
        }];
    }];
}];

You don’t need to do this.

Using Dispatch Groups to Wait for Multiple Web Services

Imagine your app has to run a series of nice web service calls. These could be for a set-up task, for example – when your app launches it may need to get various bits of configuration information from a server. This could involve hitting several endpoints.

You want to call a single method to kick this process off, and have a completion block run when it has finished. The web services don’t depend on each other. How can this be done?

Autolayout in Interface Builder - Xcode 5.1

Other posts in the autolayout series:

They killed clippy.

Interface builder in Xcode 4 was so bad at managing autolayout, and yet autolayout was so good, that it drove me to abandon it entirely and build my interfaces in code. With Xcode 5.1, it appears that most of these wrongs have been corrected.

My previous post on autolayout in interface builder (IB) was basically a list of workarounds and tips on what not to do to upset the fragile system of constraints that you’d created. This post will be about how to work with the editor to get the layout you want.

Nice Web Services

I don’t like “clever” code. Debugging code is much harder than writing it, so if you write the cleverest code you can, you’ll never be smart enough to debug it.

I do, however, like nice code. Nice is an offensively inoffensive word, and pretty hard to define, but you know it when you see it. I therefore humbly present a nice way of writing web service consumer classes for your app. The niceness is derived from:

  • Limited responsibility
  • Simple interfaces
  • Neat encapsulation
  • Minimising dependencies
  • Easy implementation

I came up with this whilst working on a recent project, and colleagues have since tried the same design and liked it, so it’s probably good enough to post here. I make no claims to its originality, but it doesn’t resemble any other networking code I’ve encountered.

Visual Tool for CATransform3D

Understanding CGAffineTransforms is tricky. Understanding them in three dimensions, as a CATransform3D, is even trickier.

There are some fantastic resources available, but I’m a visual learner and I like to be able to mess with things to see what happens.

Though it is great to understand the maths behind transforms1, that doesn’t necessarily allow you to get the effect you’re after just by making up some matrix values and trying them out. We need a little transform sandbox to play in.

Making a Meta-app

I’ve written a post for the Mubaloo developer blog about writing meta-apps. By meta app, I mean an app to help to support the actual app you’re writing.

For a recent prototype, which had a lot of functionality but no web services, I made one of these to populate and maintain the prototype data instead of cluttering the main app with lots of creation code. It was a revelation, and I’ll be keeping this approach firmly in mind for future projects.

Bug Hunting

The client had raised a bug. They’d marked it as high priority, as clients often do. If you take the following steps:

  • Log in to the app
  • Do some activities
  • Switch to the settings app
  • Set the date manually to yesterday
  • Switch back to the app
  • Log out
  • Log back in again

The app would enter a strange, flickering hinterland for a few moments before crashing. The above steps might seem like a strange use case, but it was interesting and could possibly have real world relevance during daylight saving switchovers.

In any case, once I can reproduce a bug, I find it very hard to resist fixing it.

The Core Data Stack

Recently I attended a Core Data workshop given by Marcus Zarra at iOSDevUK. It was brilliant. He threatened to talk and talk until we all passed out, which would have been great, except I had to catch the train home. If you are at all interested in Core Data (and if you’re reading this, I have to assume you are) then listening to the man who literally wrote the book on it is an opportunity you shouldn’t miss.

One of the things he mentioned was the “Core Data Stack”, the term typically used to refer to the NSManagedObjectModel, NSPersistentStoreCoordinator and NSManagedObjectContext that make up the heart of Core Data.

“You can set this up in five lines of code”

Talking to others in the room during the break, it seemed that a lot of people were sticking (or stuck with) with Apple’s template code, which is considerably more than 5 lines and, to add insult to injury, also lives in the app delegate.

While I’m waiting for Marcus’ book to arrive, let’s try and set up a core data stack in five lines of code and see what happens. Note that none of this is code we were shown in the workshop, and is not endorsed by Marcus Zarra in any way. By the end of the post, I’ll have explained how to add a fully functional Core Data stack to your project.

Understanding NSComparisonResult

Readers of this post will hopefully fall into one of two categories:

  • “Well duh, this is obvious! Why are you writing about this?”
  • “OH! That suddenly makes sense!”

(Hopefully, nobody will fall into the third category, which is “I still don’t understand!”)

If you’re in the first category, congratulations, but you’re not really the target audience.

Lessons From a Hackathon

At the weekend I attended the EE Hackathon which was arranged in partnership with Mubaloo, my employer. I’ve never been to an event like this before, so I had no real idea what to expect or how it would go. Here are a few of the things that I learnt.