Adam Preble

Design Patterns: Locks and Keys

Sat, 26 Jan 2019 11:04:41 -0500

John Sundell’s Locks and Keys design pattern (also covered in this talk) is worth a look. In short, rather than having a manager class with, say, var currentUser: User?, you create a specialized factory class that represents the state of having a user (var currentUser: User), which is in turn used to create the appropriate view controllers with the user populated/injected.

For the past few years I’ve considered the Coordinator pattern (popularized on iOS by Soroush Khanlou) to be my go-to high level app architectural pattern. For me, Locks and Keys closely resemble how the Coordinator pattern has worked out in practice, particularly after several years of Swift. As an example, a root AppCoordinator might create and defer to LoggedInCoordinator and LoggedOutCoordinator, depending on the state of the app. These coordinators then have private methods to create populated view controllers.

Recently I spent some time experimenting with Flutter, writing an app that shows a “Connect to Server” screen prompting for address and port when not connected, and the rest of the user interface when it is connected. Flutter seems to encourage a similar pattern to the above: if the app is not connected to the server, build() returns a widget for the “Connect to Server” screen. If it is connected, a different widget is built, with the reference to the connection passed to its constructor.

A few observations of differences and similarities between Swift/UIKit and Dart/Flutter here:

Swift’s optionals must be dealt with. Without the above pattern, as Sundell points out, you end up with a lot of guard-assertionFailure clutter – error handling code you never expect to be executed.
In Dart, any reference can be null, but there’s also no need to unwrap them. As a result I imagine most code only rarely checks for null, resulting in the occasional “Oh, I forgot to pass that in…” crash.
If you use UIKit storyboards to load your view controllers, you can’t override the initializer and must instead rely on a convention of populating the injected dependencies, models, etc. One could argue that this is roughly equivalent to pitfalls of Dart’s “everything is optional”. (This issue with UIKit view controller instantiation is well understood by the community.)
Flutter’s design encourages passing dependencies down – stark comparison to UIKit storyboards.

Check out John Sundell and Soroush Khanlou’s posts if you haven’t already.

Thanksgiving Moon

Mon, 26 Nov 2018 20:55:03 -0500

Railroad: Relocated

Mon, 26 Nov 2018 20:31:38 -0500

I’ve moved all of my railroad-related posts to their own blog, railroad.adampreble.net, where they can fully stretch out in all of their nerdy splendor.

The Next Chapter

Wed, 02 Sep 2015 12:00:00 -0400

I’ve just begun work at Ritual Development Group, Inc.. Ritual is a product-oriented software company. I’m serving as the CTO and will share more about what we’re building as time goes on. For now, suffice it to say that this is a huge step for me; It is the realization of a dream I’ve had for quite some time.

As wonderful as this is, it has meant making the very difficult decision to leave Big Nerd Ranch, where I have proudly worked for the past five years. I joined BNR in 2010, just as the original iPad was being released. Since that time, BNR has experienced tremendous growth.

At BNR I worked as an independent engineer, a team lead, an author, a teacher, and as the VP of Engineering. I was able to work with startup companies, government contractors, and billion-dollar multinational conglomerates. I feel fortunate to have learned a tremendous amount in that time, and quickly.

Teaching was one of the best parts of my time at BNR. As much as I love writing software, it’s really hard to beat a week spent teaching a group of nerds about platforms you love, especially when every student is excited to be there. The days for an instructor are long, but it’s a truly rewarding experience, even (or especially) when you’re sitting in the lab at 10:00 PM sketching out an app architecture with a student. BNR’s bootcamps are an exceptional experience. If you are serious about advancing as a software developer, I wholeheartedly recommend taking a class.

Co-authoring the fourth and fifth editions of Cocoa Programming for OS X was a remarkable experience. I couldn’t be more thankful to Aaron for the trust he placed in me. I am especially proud of the fifth edition, which my friend and colleague Nate co-authored with me. While the fourth edition was an important update, but the fifth edition was truly an overhaul, a major version release with substantial refactoring. We focused on demonstrating modern app architecture and style while also transitioning from Objective-C to Swift.

All of my prior work has stretched me, but the opportunity to work as the VP of Engineering stretched me in a whole new dimension (or two). Looking back on it, I believe we accomplished a lot. But it’s also challenging to fully take stock of it. I owe many thanks to my team of engineering directors: Brandy, Brian, the Chrises, and Steven. Working with them and all of the Nerds was a truly rewarding experience. It’s hard to part ways with such a fine group of people.

Looking back over my time at BNR, it’s almost unreal how much I grew there, even in some of the simplest ways. I’m a fairly quiet person and the fact that I can happily deliver a talk on a chapter from the Cocoa book feels very incongruous. I also drink coffee now. I owe a great deal to all of the people at BNR who gave me so many chances to grow over the years.

So here we are. This chapter has come to a close. I’m grateful for all that’s past, and I look with great anticipation to what’s next.

Handling Keyboard Input in a View Controller – Alongside SpriteKit

Wed, 15 Apr 2015 21:55:17 -0400

I’m using SpriteKit in the train game I’ve been tinkering with on and off, and recently went to add keyboard event handling to my view controller:

override func keyDown(event: NSEvent) {
    interpretKeyEvents([event])
}

override func deleteBackward(sender: AnyObject?) {
    println("deleteBackward")
}

To my surprise, though, whatever was first responder wasn’t passing keyDown: up the responder chain. (This is 10.10 so view controllers are in the responder chain automatically.)

First, determining what was first responder was easy enough. After showWindow: had been called:

(lldb) ex windowController.window!.firstResponder
(SKView) $R2 = 0x0000000100e1b100 {

The SKView is the first responder. I had forgotten that SKNode is a subclass of NSResponder and that nodes can participate in the responder chain.

So why wasn’t the keyDown: propagating up to the view controller? I checked the nextResponder of the SKView: it was the same as its superview, which is to be expected. The question remains: why wasn’t keyDown: propagating?

For the answer to that I turned to Hopper Disassembler, which revealed that -[SKView keyDown:] essentially sends keyDown: to its scene:

void -[SKView keyDown:](void * self, void * _cmd, void * arg2) {
    rbx = self;
    r14 = [arg2 retain];
    if (rbx->_disableInput == 0x0) {
        rdi = rbx->_scene;
        if (rdi != 0x0) {
            [rdi keyDown:r14];
        }
    }
    rdi = r14;
    rax = [rdi release];
    return;
}

So how can I deal with this? I could subclass SKView and override keyDown: to give it a more traditional implementation (pass it on to nextResponder, for example). However, while I was in Hopper I noticed that SKScene doesn’t implement keyDown:, which means that it is relying on the default implementation of keyDown: in NSResponder. Which means that the simplest solution is to set the scene’s next responder to my view controller:

let gameScene = GameScene(size: ...)
skView.presentScene(gameScene)

assert(gameScene.nextResponder == nil)
gameScene.nextResponder = self

Now my view controller receives keyboard events: problem solved! My guess is that SpriteKit’s designers intended for the keyboard event handling to be done in an SKScene subclass – that’s how it’s done in the Adventure sample code. Unfortunately that doesn’t make sense for my app architecture, where there’s more to the UI than an SKView.

A Quick Fix for Fuzzy SKShapeNode Lines

Mon, 16 Feb 2015 23:57:51 -0500

I’ve been using Apple’s SpriteKit for the train game. It’s gone fairly well, except there have been a few unpleasant surprises with SKShapeNode, which strokes/fills a bezier path. The internet is filled with folks complaining about buggy behavior from it and I’ve definitely had more than a few moments where I daydreamed about dusting off my OpenGL chops.

This is an A/B screenshot of an issue I was running into. At left is before, right is after:

These are SKShapeNodes with paths for the track segments, which are 2pt wide, stroked, and, most importantly scaled up several times (zoomed in on the map). The issue of course is the blurry/fuzzy line rendering.

The ‘fix’ was startlingly simple: setting antialiased = false makes your blurry lines crystal clear when scaled up. This isn’t at all what I was expecting (antialiasing off == stair-stepping, pixelated lines in my mind).

My guess is that this is an optimization. For SKShapeNode, antialiased means it will be drawn on a texture at unscaled resolution and that texture is then scaled as needed. With antialiased off, the curve drawing occurs at the current resolution. This is only reasoning off of the visual results. I don’t notice any significant difference in CPU overhead when antialiased is off.

It’s also curious because SpriteKit seems to perpetually re-render SKShapeNodes whether they have changed or not. At some point I will likely end up writing code to render them to textures, or just moving over to OpenGL and rendering the tracks myself.

At this point in development the visuals are secondary, however. I ran an experiment with SKShapeNode’s strokeTexture and aside from some strange rendering artifacts (texture scaled unevenly), the result was much too busy. For now I rather like this abstract appearance for the tracks.

A Train Game: Prototypical vs Playable

Sun, 15 Feb 2015 12:18:50 -0500

Late last year I was playing Artemis Spaceship Bridge Simulator and, being the sort that likes trains, I thought, wouldn’t it be cool if there were a collaborative game that simulated running a railroad? So late in December I started writing some Swift code, building the game as a Cocoa app. Here’s what it looks like today:

Here’s some video of it from around the first of this year:

The vision is for several players to operate a railroad together. One or two dispatchers, a few engineers cycling between trains. Switching cars in yards, moving trains up and down the mainline, fulfilling orders from industries. A game could run an hour or two, or perhaps a number of sessions over the course of a few weeks.

It’s come a long way over the past two months. There’s a server that clients can connect to and operate the trains, couple and decouple cars. A basic map editor. It’s a lot, or it feels like a lot to me, but at the same time it still feels very primitive. It’s a prototype, or possibly a toy, but not yet a game.

Motivation can be a curious beast, especially with competing priorities. With the basics in place, feature work becomes less satisfying. It’s time to start playing with making it a game.

At its core this game is a simulation of the operating sessions that some model railroaders conduct in their basement, but without the limitation of space. This makes it possible for maps to be very realistic, modeled on real places.

That realism presents some interesting challenges in terms of presenting the information. This is a fairly simple classification yard and already it’s pretty challenging to take in:

Picture those tracks full of cars and weep. I weep for joy and terror: there’s something very pleasing about vast arrays of parallel tracks, as well as extremely daunting if you are expecting me to make sense of it! At the moment my favored approach to this is to add a toggle-able HUD that color codes cars by their destination.

Here’s another area that needs work. Perfectly clear, right?

From here there will of course be more feature work – such as on those switch track signals – but more importantly I plan to work on the model for the industries and yards so that there is something to accomplish in the game, aside from randomly coupling and decoupling cars.

Lennart Green

Tue, 07 Oct 2014 23:55:22 -0400

This video of Swedish close-up/card magician Lennart Green from TED 2005 (YouTube) is simply wonderful. It is a pleasure to watch him expertly fumbling his way through one delightful surprise after another.

Iterating Over a Range of Dates in Swift

Sun, 07 Sep 2014 22:29:04 -0400

Updated 2016/8/25: Made a few style tweaks and fixes for Swift 2.2; fixed start date issue (thanks, gist commenters!).

One thing I’ve been wanting to do with Swift is iterate over a range of NSDate objects in a for loop. Something like this:

let startDate = ...
let endDate = ...
for date in startDate...endDate {
    ...
}

While I think it might be possible to do this by making NSDate conform to ForwardIndexType, it would be fairly inflexible. As I understand date arithmetic, to do it right you need a reference to the NSCalendar being used, and of course you need to know how much to ‘step’ the date each time. You could just make it step by days but what if you later want to step by hours?

So I decided on a different approach: create a struct, DateRange, that conforms to SequenceType. It’s not nearly as succinct, but it is much more flexible. Create an instance of the struct using an extension on NSCalendar, as this seems to be in keeping with calendar-dependent date APIs. It looks like this:

let calendar = NSCalendar.currentCalendar()
let startDate = ...
let endDate = ...
let dateRange = calendar.dateRange(startDate: startDate,
                                     endDate: endDate,
                                   stepUnits: .Day,
                                   stepValue: 1)

for date in dateRange {
    print("It's \(date)!")
}

The complete code is below (also in a gist), but first a bit of a disclaimer: this code works, but I half expect to look back on it in a year, cringe, and contemplate deleting this post. My crystal ball of Swift faux pas is cloudy.

Note also that at the time this was written, NSDate did not have any Swift comparison operators built in, so I implemented >. Presumably that will change.

import Foundation

func > (left: NSDate, right: NSDate) -> Bool {
    return left.compare(right) == .OrderedDescending
}

extension NSCalendar {
    func dateRange(startDate startDate: NSDate, endDate: NSDate, stepUnits: NSCalendarUnit, stepValue: Int) -> DateRange {
        let dateRange = DateRange(calendar: self, startDate: startDate, endDate: endDate,
                                  stepUnits: stepUnits, stepValue: stepValue, multiplier: 0)
        return dateRange
    }
}

struct DateRange :SequenceType {
    
    var calendar: NSCalendar
    var startDate: NSDate
    var endDate: NSDate
    var stepUnits: NSCalendarUnit
    var stepValue: Int
    private var multiplier: Int
    
    func generate() -> Generator {
        return Generator(range: self)
    }
    
    struct Generator: GeneratorType {
        
        var range: DateRange
        
        mutating func next() -> NSDate? {
            guard let nextDate = range.calendar.dateByAddingUnit(range.stepUnits,
                                                          value: range.stepValue * range.multiplier,
                                                         toDate: range.startDate,
                                                        options: []) else {
                return nil
            }
            if nextDate > range.endDate {
                return nil
            }
            else {
                range.multiplier += 1
                return nextDate
            }
        }
    }
}

// Usage:
func testDateRange() {
    let calendar = NSCalendar(calendarIdentifier: NSCalendarIdentifierGregorian)!
    let startDate = NSDate(timeIntervalSinceNow: 0)
    let endDate = NSDate(timeIntervalSinceNow: 24*60*60*7-1)
    let dateRange = calendar.dateRange(startDate: startDate,
                                         endDate: endDate,
                                       stepUnits: .Day,
                                       stepValue: 1)
    let datesInRange = Array(dateRange)
    XCTAssertEqual(datesInRange.count, 7, "Expected 7 days")
    XCTAssertEqual(datesInRange.first, startDate, "First date should have been the start date.")
}

Southern 4501 at TVRM

Sat, 06 Sep 2014 10:21:32 -0400

Norfolk Southern’s Tumblr and Flickr tend to have some pretty great train photography on them. Recently they’ve had some shots of Southern 4501, which has been restored by the Tennessee Valley Railroad Museum up in Chattanooga.

In particular, this shot of 4501 and 630 at TVRM is pretty sharp: Southern 2-8-0 630 and 2-8-2 4501 Simmer Side By Side. I’d embed them but they aren’t on Flickr.

Update 9/6/2014: They shot some video, too: Southern 4501 and 630 Working Together.

Update 9/7/2014: This overhead shot is pretty outstanding.

We went up to TVRM a couple months ago and had a great visit. The Missionary Ridge Local that they run uses 630 as its power. It’s a 45-minute out-and-back excursion with a 15 minute break in the middle where you watch them turn the locomotive on a turntable and run it back to the (new) front of the train to take it back to the station.

Below is a photo I took during that visit of 630 arriving as NS 9686 kindly passes in the background.