My second daughter was born this week. In a change to your usual programming, here’s a little whimsical reflection on the parallels between being a parent (though my experience of the former only goes up to 4 years) and being a programmer. Mostly because it’s hard to write code-based blogs with a sleeping baby on your lap.
Implicitly unwrapped optionals don’t make sense at first glance. It’s optional, but you’re always going to assume it contains a value? What’s optional about that?
What are they for?
In Objective-C, you can safely send a message to
nil, which will return something treated as
0 (this variety is part of the reason Swift has optionals, of which more later). This is a useful and powerful feature, but it only applies to Objective-C objects. There’s no universal way to deal with absent or no-value types such as integers, floats or Booleans. Things like
0 are used to represent “no value” in these cases.
Optionals are Swift’s way of unifying the representation of Nothingness. By using them, we lose some of the ease and flexibility of nil messaging, but gain compile-time checking, safety and a consistent way of dealing with the same problem, regardless of variable type.
It’s quite telling that one of my highest voted Stack Overflow answers relates to nothing more than a simple misunderstanding of language. Apple’s use of the term fault in Core Data seems to cause quite a lot of confusion.
Apple to tend to use a ten-dollar word when a cheaper one will do in their APIs (ubiquity or segue, anyone?), but it’s usually a correct and unambiguous one. Fault, particularly when seen in a log statement, is all too readily interpreted as error.
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.
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?
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.
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.
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.
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.