Swift NSManagedObjectContext Extension to Delete All Core Data Objects

I made this NSManagedObjectContext extension so that I could delete all of a users data when they log out of the app I’m writing. The alternative was to delete the sqlite file itself and reinitialize my Core Data stack, but that seemed potentially more problematic and less safe.

The two instance methods on NSManagedObjectContext for deleting objects are:

  • func deleteAllObjects(error: NSErrorPointer)
    • Delete all objects in a context. Bails out and returns an error if there’s any problems.
  • func deleteAllObjectsForEntity(entity: NSEntityDescription, error: NSErrorPointer)
    • Delete all objects of an entity type. Bails out and returns if there’s an error.

I also included a convenience initializer for creating a new context with a parent. The way I use the deletion methods would be to create a private queue child context, block out the UI while this is going on with an activity indicator or something, and then call deleteAllObjects(_:) on the child. If there’s an error, you can just throw away the child context, and otherwise save your main context and commit it back to the store. Like this:

Here’s the code for the extension:

Trying Swift Again

On my most recent project, I decided to try going Swift from the start. I did the same thing when I started working on a rewrite of the Lovely app around the end of last summer, but found the tools too immature then. This time I’ve spent about a week with it, and everything seems is working out fine (so far). I’ve tried to keep up reading about the language itself, so the syntax hasn’t held me back much. One difference between now and the last time I really dove into Swift is that either something in my brain has clicked regarding optionals, or the language changed a bit over the past six months to make optionals align with my brain more. I still can’t what the debugger commands are.

The other day on Twitter, I was part of a discussion comparing Swift to Objective-C. My feeling is that Swift isn’t better, but some parts of it are delightful to me, and I like it. For example, method overloading in Swift is pretty great, and I’m looking forward to doing interesting things with enums. Better though? In some ways, but not in others. Colin Cornaby pointed out that the ease of dropping down to C in Objective-C comes up a lot, and that C++ compatibility is pretty much a requirement for a lot of apps. I think he’s right.

The way I look at it is this: Objective-C didn’t have to be “broken” for Swift to be a great language. I don’t expect Objective-C to go anywhere in the near future, and that’s a good thing.

Alamofire

Alamofire is a new networking library — written in Swift — from the creator of AFNetworking. So far I’ve just read the post on NSHipster about it, but I like what I see. It’s not a value judgment, but something AFNetworking has never quite sat right with me. This looks very lightweight and more like something written to be idiomatic Swift rather than Objective-C in Swift’s clothing.

Objective-C Without the Smalltalk

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.