• Swift Generics

    "Don't Repeat Yourself" is a solid bit of programming wisdom. It's so common it has been made into an acronym, DRY, which means that people get to make "jokes" about DRYing out their codebase.

    If you write a bit of code that does something, and elsewhere in your program you need to do the same or a very similar thing, don't copy and paste the bit of code. Make it accessible from both places, and make the minimum set of changes needed to make it reusable.

    "Boilerplate" code refers to code that has to be included regularly and without much alteration to achieve basic functionality. There are plenty of frequent, common operations that require a lot of boilerplate code. The boilerplate code obscures what you actually want to do and makes the program harder to read. A good example is inserting managed objects into a context. For each type of managed object, the code looks almost exactly the same, but different types are involved.

    I'm going to discuss some of the boilerplate code encountered in Core Data, and how you can use Swift generics to DRY out some of these operations. First, a few words about generics.

    Read more...

  • Fun with scrollviews

    iOS devices have small screens. Sometimes we want more content to be included on a screen and adding it to a scroll view is a great way of doing this. I'm going to look at the various numbers and measurements that a scroll view uses to do its job.

    Read more...

  • Nice Web Services, Swift edition

    As I've written before I am very keen on getting web service results out of JSON and into a strongly typed form as soon as possible. It makes the rest of your code much cleaner, insulates you from knowledge of the web service keys and format and aids testing.

    Swift structs are a natural home for your web service results - they are immutable, lightweight and have minimal boilerplate code requirements. Getting the results out of JSON and into a struct, however, can be complicated - verifying the correctness of each key in the JSON can quickly lead to an if let staircase of doom.

    I wanted to use something clever and functional, but this has readability drawbacks (I'm not yet comfortable with scattering custom operators all over the place) and also requires me to write a curried initializer for each struct, which seemed like repeating myself a bit too much.

    My design goals were:

    • Minimise repetition of code and boilerplate
    • Allow for flexibility if the API changes
    • Allow for optional properties
    • Take advantage of compile-time checking
    • Feel at least slightly like I had done something a bit "Swifty"

    Here's what I came up with.

    Read more...

  • Storyboards in Xcode 6

    I've liked the idea of storyboards since their introduction, and even used them a couple of times, but I've always gone back to laying out views in code, mostly using my autolayout category.

    It's clear that Apple would prefer us to be using interface builder and storyboards, so every time a new version of Xcode comes out I give it a try to see if I'm ready to move on. Here are the results for Xcode 6, after I've spent the last few weeks building a universal app for iOS 7 and 8 using storyboards.

    Read more...

  • Functional Functions

    Functional programming for people who know nothing about functional programming by someone who knows next to nothing about functional programming : a series

    The introduction of Swift has brought with it a lot of talk about functional programming. I'd previously only heard the term whilst investigating things like Reactive Cocoa, and had not investigated too deeply because the documentation for that was so full of arcane new terms1, but now it sounds dangerously like becoming mainstream.

    As I've previously mentioned, I learnt to code on the streets, not some fancy computer school. It looks like I'm going to have to go back out there and work out what this new2 menace is.


    1. Futures? Promises? Signals? 

    2. Actually, invented at the same time as OOP, so not new at all 

    Read more...

  • Parenting and Programming

    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.

    Read more...

  • Implicitly Unwrapped Optionals in Swift

    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?

    Read more...

  • Understanding Optionals in Swift

    What are they for?

    In Objective-C, you can safely send a message to nil, which will return something treated as nil, or NO, or 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 NSNotFound, NSIntegerMax,-1 or 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.

    Read more...

  • It's not your fault

    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.

    Read more...

  • 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:

                        }];
                    }];
                }];
            }];
        }];
    

    You don't need to do this.

    Read more...