I needed a way to present non-modal alerts inside an app I’m working on and wanted to use a banner system that’s a bit like what Tweetbot1 does. I ended up writing a UIView subclass called BannerView that I’ve open sourced for anybody to use.
TL;DR: You can’t name a Core Data attribute new* in Objective-C or Swift because of how automatic reference counting interacts with manual reference counting. If you do, you’ll crash unreliably when your Core Data stack is deallocated.
I’ve spent the better part of a day trying to fix this hard to track down bug in my Core Data stack that was causing a crash. The crash was introduced when I added a new entity to my object model. The NSManagedObject subclass looked a little like this:
I ran into an issue while writing property validation methods for a Core Data stack where the methods simply weren’t being called. After a bit of head scratching I realised it was because the methods needed to be annotated with @objc. This wasn’t needed in Swift 3 because @objc was inferred on all methods of subclasses of NSObject; however, the behaviour of @objc inference changed in Swift 4. Now, subclasses of NSObject must explicitly mark methods that need to be accessible from Objective-C. This took longer to realise than it should have since the Core Data documentation’s sample code for property-level validation hasn’t been updated for Swift 4.
While working on rewriting Spotijack in Swift, I started to feel dissatisfied with Foundation’s notification API. It’s a stringly typed API that makes heavy use of Any and as someone who loves their types this makes me sad. To cheer myself up, I set about writing a more strongly typed notification system.
The end result is a small library1—TypedNotification—that provides a set of protocols defining a more descriptive type system for notifications. Check out the GitHub project if you’re interested. There’s a Playground in it demoing the protocols. The rest of this blog post will cover them in a bit more detail.
The other week I had to set up a new installation of MATLAB r2016a on a (somewhat) fresh Fedora installation. After running the installer, I ran into a bunch of library errors when trying to run external C++ programs1 from MATLAB or when trying to plot something. When running an external C++ program, MATLAB would complain about missing versions of CXXABI and GLIBCXX in libstdc++2. When plotting something, MATLAB would complain about libmwosgserver.so.