I understood the concept of optionals right away, but since the debugger doesn’t work with Swift in the third beta of Xcode 6, I’m given no clue what I’m actually doing wrong when my app explodes. This article did a pretty good job clearing things up for me.
Objects that may or may not be nil (and the nil-checking code that accompanies them) are the cause of many common programming errors. Swift’s optionals offer compile-time cues to developers about when it’s necessary to nil-check and when it’s not, and makes it harder to write code that misbehaves in the presence of nil.
I hadn’t mentioned it here, but a couple of months ago I took a full time position running iOS development at Lovely. Lovely is a great service for people looking to rent a new apartment, and it’s been really exciting working with the team. This also means I’m now living in San Francisco, so hopefully I’ll be able to run into some people here.
I haven’t needed to get a unique device ID since before we stopped being able to use
-[UIDevice uniqueIdentifier] until today. Apple added the method
-[UIDevice identifierForVendor] in iOS 6 which totally replaces the old method for any of my needs.
What the method does is give a unique ID for any apps from the same vendor on a given device. The part which might be a little confusing at first is that “vendor” does not mean the same developer account, but instead means any apps where the first part of the bundle identifier (
CFBundleIdentifier) is the same. So
com.collindonnell.myotherapp would get the same identifier, but
com.albinadevelopment.anyapp would not.
Just learned from the Accidental Test Podcast that if you option click on the fast forward button in QuickTime X you can increase the playback speed.
I never feel like I have a great answer on how to organize anything, so this response on Quora by Phil Libin is really interesting to me.
The main points are that he:
- Changes it up pretty often.
- Has about forty-five total notebooks.
- Has one primary notebook that most things go into.
- Most of his other (at least thirty) notebooks are shared.
- Doesn’t use very many tags.
- Uses one notebook for each “major” conference he goes to.
I’ve also found most of my stuff going into one notebook (I call it “Filing Cabinet”). The most effective way for me to find anything is to search, so it would probably be useful for me to pare down some of the other notebooks I have and use a few strategic tags in their place.
This is a really good post lamenting some of the direction Swift has chosen to take:
Gone is the dynamic nature of ObjC; it has instead been replaced by a rigid, generic based type system. I know the world of C++, Java, and C# programmers have rejoiced. Myself, having worked in Visual Studio building tools for .NET and Windows developers for many years and leaving that for the world of Cocoa and ObjC, I am greatly saddened by this turn of events.
Objective-C without the C is a worthwhile goal, but I don’t think anyone was asking for Objective-C without the Smalltalk. I’m still learning and planning to use Swift, but I think dividing into pro-Swift and anti-Swift crowds is probably too narrow of a view. Both languages are better and worse in different ways. It’s going to be up to us to learn those differences.
I hadn’t been using DuckDuckGo as my main search engine recently, but the big revision they just did has made it amazingly slick and fast. If you install their extension you can use it as your main search engine in Safari.
I’ve been hearing about Harry’s cartridge razor subscription service for a while on different podcasts, but since I’ve been using a safety razor for about four years now, it didn’t really interest me too much. The other day when I heard an ad though, I thought of how I’d been thinking of getting my dad a fancy-pants safety razor set with brush and everything, but hadn’t because I knew it’d be too fussy for him to use, and so I went to the website, read some reviews online to make sure they were actually good razors, and ordered my dad the “Truman” set in blue with a subscription that will sent him more razors and cream every four months.
For the cost of $93 a year (plus $15 for the initial pack) my dad will never have to think about getting fresh razors or shaving cream again. It’s a small thing, but something I can’t imagine anyone being upset that you did for them.
I’m considering how to handle a pretty big refactoring of how networking code is handled in this app, and after talking to my friend about how he’s handling networking/model object creation in an app he’s working on if the way I’m thinking is a good idea or not.
What my friend described is that he’s using the active record pattern, which roughly translates here to sticking everything into the model, and creating new
NSURLSession objects as needed. I don’t like the idea of needing to create a session object for every request, since the nice thing about
NSURLSession is that all of your requests get to share a delegate, which minimizes repeated code in a lot of cases. I also had an assumption that
NSURLSession has some smarts about managing its own queue of tasks and that creating separate session objects would mess that up. The other thing is that if you had some shared code specific to the service you were talking to, having all of your model objects manage all of their own networking seemed like a good way you might end up with some repeated code later on.
All of that aside, I do kind of like talking directly to the model objects when I need to get things done with them. It feels pretty natural that if you need to do something with SomeObject that you’d talk directly to it. The solution I’m thinking of is to borrow from Core Data and create a class that’s sort of like an
NSManagedObjectContext which manages an
NSURLSession and which I dependency inject as needed. It also gives me a nice place to stick things which are common to the service, so that code doesn’t get repeated across model classes.
For a service called
Foo whose API I need to interact with to create
Bar model objects by ID, I might have a class called
ALBFooAPIContext and do something like this:
[Bar objectWithID:barID usingContext:fooContext completionHandler:completionHandler];
That method could then talk to the context object however it needs to in order to get stuff done. Is this a terrible idea? I’d probably go for calling the context class something else, except I think it’d be a good place to store stuff that is actual contextual to how I’m talking to the service (maybe a
I will be at WWDC this year. I’ll also be in SF before and after. If you’re going to be in town and want to get together, get in touch.