Mistakes
A master is one who has made all the mistakes that one can make within a given field.
Niels Bohr.
Are You Rich?
Back when I was a registered nurse I had an opportunity to volunteer at a field hospital in Port-au-Prince, Haiti. It was a year after the terrible earthquake in 2010, which killed hundreds of thousands of people and left hundreds of thousands more homeless. Survivors were still living in conditions more appalling then you can imagine — fields covered with tents as far as my eyes could see, strung up between rivers of mud and filth.
The hospital I volunteered at was operating out of a couple of massive tents, like you might see at a state fair in the US. Despite their humble infrastructure, Project Medishare was running a full-service general hospital, providing care for all kinds of patients and conditions. They even had a small ICU, which is where I was assigned.1
One of the volunteers at the hospital was a Haitian young man named Samuel who had been a medical student at a local university. The earthquake had destroyed his school. The closest he could get to his dream of becoming a doctor was to volunteer at Project Medishare. Samuel and I spent a lot of time together and became fast friends.
One night while our patients were sleeping, Samuel and I were chatting about life in the States versus Haiti. In the course of conversation I thoughtlessly mentioned something about my iPad back home. Samuel got quiet, cocked his head at me.
“Jared…are you rich?”
This was 2011. The iPad was still a novelty in the US, let alone in Haiti. I was an iOS nerd who had to have the latest gadget, and as a nurse I had the means to afford it. If memory serves I earned $2200 a month after income taxes. An iPad wasn’t cheap, but I had enough wiggle room in my budget to buy one. By American standards, an iPad was an expensive toy. But in Haiti, $500 USD was an outrageous sum.
I don’t remember how I answered Samuel’s question. I was dumbstruck. Was I rich? Of course not, right? I punched a time clock at work. I drove a Hyundai with only the basic features. My one-bedroom apartment had sparse thrift store furniture. I paid only the monthly minimums on mountains of college debt.
After a week of working in swaying tents and sleeping under mosquito nets and shitting in a hole in the earth, coming home to my one bedroom apartment, where I lived alone with floor-to-ceiling windows and walls that didn’t buckle in the wind, was overwhelming. Everything was sickeningly nice, nauseatingly pleasant. Even my thrift store furniture seemed opulent by comparison.
In the quiet moment after Samuel’s question, I realized more acutely than ever that the truth about my privileged circumstances isn’t in my perception of myself, but in how others perceive me. Relatively, from my friend Samuel’s perspective, I was rich. However much it contradicted my own ideas about myself, Samuel’s perception was the only perception that mattered.
Please consider donating or volunteering with Project Medishare. They do a lot of good for a lot of hurting people.
-
By the way, in case you harbored any doubts about him, Sean Penn (the actor) is the real deal in his commitment to helping people in Haiti. I heard stories about him appearing in front of the Project Medishare hospital in a pickup truck, ferrying sick children and their mothers from remote villages — “Take care of this baby!” he’d bark — and heading back out to do it again. ↩
New Job
Later in October I’ll be starting a new job as a staff engineer at Black Pixel. I’m looking forward to a new set of challenges and cool new projects.
I’ll be leaving behind good friends and colleagues at Bloglovin’. I’ll also be leaving behind a spot for an engineer on the iOS team. If you live near NYC or Stockholm and are looking for an iOS position, shoot me an email and I’ll put you in touch with the right people.
Wishlist for Swift 3.0
Here’s my shortlist of the features I most want to see added to Swift:
One-to-Many Data Flow
There are only three ways to propagate changes from your data model in off-the-shelf Swift: delegation, NSNotifications, and KVO. Only delegation can be accomplished in pure Swift, but it only works for one-to-one relationships. NSNotifications and KVO are Objective-C hacks that are made available to Swift via bridging, but there are numerous shortcomings with both APIs.
Until there’s a proper first-party alternative, I’ve been using KVO, but that requires making all my essential model classes inherit from NSObject. This feels icky.
I know there are third-party alternatives like ReactiveCocoa, but I don’t trust something that important to a third-party library (e.g. none of the libraries I’ve seen include quality-of-service parameters in their API designs, nor do I trust them to get multi-threading right when tying together changes from a background process to main-thread-only UI code).
Whether or not Apple does a Swift-native “port” of KVO or an Apple-esque rendition of ReactiveCocoa, there’s one thing I’d like them to do regardless: weak collections. Something like NSMapTable, only it would actually work as advertised. Then you could do something like:
var delegates: WeakCollection<MyDelegateProtocol>
i.e. a one-to-many version of the delegation pattern.
Improved Debugger
Maybe I’m missing some key knowledge here, but it seems like the debugger has a lot of room for improvement compared to what it was like with Objective-C. Examples abound. Entering po foo.property.anotherProperty should not choke on optionals as hard as it does currently. po someSwiftDictionary should print something closer to what [NSDictionary description] outputs. Using the expandable-caret view in the debugger for something like a Dictionary is pretty painful, too.
More Flexible Collection Constraints
As long as we’re dependent upon subclassing first-party classes like UIView and UIViewController to build our apps, there’s going to be a need to constrain collections to objects that both inherit from a given class and conform to a given protocol (or protocols). For example, if I have a custom view controller container that queries its children for UI details (the way UINavigationController does), then I want my array of child view controllers to be something like:
public var viewControllers: [MyProtocol<UIViewController>]
Currently, the only alternative is something nasty like:
public var viewControllerItems: [MyProtocol]// ...
protocol MyProtocol { func viewController() -> UIViewController func someOtherMethod() -> UIColor }
In the nasty alternative my view controller subclasses would return self for viewController().
More Flexible Extension Constraints for Collections
It’s currently not possible to extend Dictionary with an arbitrary constraint on the key type. In other words, it’s not possible to do this:
extension Dictionary where Key:String, Value:JSONEncodable {
// blah....
}
This would be helpful when, like the code example suggests, extending Dictionary to aid in JSON encoding/decoding.
Typed Throws
Twitter-friend Benjamin Mayo reminded me of another: we want typed throws. Unless Apple scraps the throws API altogether in favor of something less NSError-bound, it should at least indicate to consumers of a public API what values can be thrown by a function that throws. Currently, if you don’t have access to the source code for such a function, you have to rely on guess-and-check or documentation to discover what might be thrown. I’m sure Apple is aware of this drawback and have plans for it, but hey — this is my wishlist.
Swift – Versus – Storyboards and State Restoration
I don’t use Storyboards or State Restoration in my own projects, but I have looked into them in detail at one time or another. From what I understand about both of these APIs, the life cycle for view controllers looks something like this:
1. Something happens in the app. 2. UIKit triggers the initialization of a view controller. 3. The initialized view controller is prepared just prior to being presented. 4. The view controller is presented.
It’s usually inside of Step 3 that depedencies are passed into the new view controller. In the case of State Restoration and a primary Storyboard, for example, the new view controller is given an opportunity to resume its previous state inside:
func decodeRestorableStateWithCoder(_ coder: NSCoder)
Or in the case of a Storyboard segue, the following method is called:
func prepareForSegue(_ segue: UIStoryboardSegue, sender sender: AnyObject?)
In either case, the new view controller is initialized before it receives its dependencies. But this order of operations is the opposite of what Swift encourages, particularly with regard to optionals.
Swift’s optionals make my code safer. They make it nearly impossible, with good coding practices, to make a mistake when reasoning about whether or not an element will be non-nil at run time. But optionals can be really annoying, too, for the same reason that they’re safer. As if let and guard checks build up like snowdrifts at the edges of my code, I find myself gravitating towards API designs that eliminate unnecessary optionals. I look for opportunities to “convert” an optional property to a non-optional one by providing a guaranteed non-nil value for it in the view controller’s initializer.
Thus, my Swift code tends towards view controller life cycles like this:
1. Something happens in my app. 2. I initialize my view controller programmatically, passing in dependencies. 3. My view controller is presented.
Clearly this pattern in Swift is mismatched with the requirements imposed by Storyboards and State Restoration. Swift pushes dependencies towards the init() method, while Storyboards and State Restoration push them into later stages in the life cycle. I have been able to handle this so far by avoiding Storyboards and State Restoration in favor of custom, programmatic alternatives. But I worry that Apple’s winds are blowing in the other direction and someday I’ll have to change up for a new design pattern.
What do you do in your code? Do you avoid Storyboards and State Restoration like I do? Do you have cleverer ways of dealing with the mismatch?