My recent posts were about SwiftUI quirks and annoyances, so I want to share a short success story for a change: You can @import Swift Packages in Objective-C code just fine. (At least if they are Objective-C compatible.) I updated my WordCounter app to rely less on Carthage and use Swift packages where possible instead.
When I pointed out that Sparkle finds its XPC services on its own, I mentioned you can see how it does this by searching for “SPUXPCServiceExists”. If you take a look at the use of this function, you’ll see something like this in the Objective-C (!) source files:
Integrating new functionality is fun. But revisiting 18-months old code isn’t. Back then I created a protocol InvokesWindows to define methods like -showPreferencesWindow which I imported in the menu bar controller to show the preferences when the user selects a pop-up menu item. But I didn’t actually delegate to any instance of InvokesWindows. I used NSApp. (Insert facepalm here.)
UISplitViewController is the way to go when you want to make your iOS app universal without much hassle and can model the scenes in terms of master/detail. While getting Calendar Paste ready for the upcoming iOS 9 release, I discovered that using UISplitViewController across devices is one thing, while Storyboard segues are another.
Objective-C got generics! No more collection classes just for the sake of guarding against invalid elements!
I used custom collection classes a lot for the Word Counter to let the compiler help me prevent mistakes. Swift generics were a godsend for that kind of safety. Now, Objective-C can achieve similar awesomeness.
It can look like this:
@interface Wheel : NSObject
@property (nonatomic, strong) UIColor *color;
@end
@interface Vehicle : NSObject
@property (nonatomic, copy) NSArray<Wheel *> *wheels;
@end
Now the compiler will warn (!) you if you misuse it:
Vehicle *car = [[Vehicle alloc] init];
[car.wheels addObject:@"NSString is of the wrong type"];
Great news, since if you didn’t spend a lot of time creating custom collection types yourself, now at last can you ensure array element type consistency. Makes your code cleaner and more reliable.
You don’t have to learn anything new if you work with Core Data in Swift. It’s a pain to use NSManagedObject directly, so you better work with custom subclasses all the time. Unboxing optional NSNumbers is just too cumbersome. There are caveats you should be aware of, though: Swift’s static typing makes it a bit harder to write test doubles for managed objects.
I’m refactoring code of Calendar Paste 2 some more. Since I like what I learned using Swift so much, one of today’s changes was about making a view controller method do less by factoring object creation and error handling into its collaborators. The resulting code handles far less of the action involved. Instead, it delegates the action to a new command-like object. And instead of querying an event template for data and assembling an actual event with start and end dates, it delegates event creation to the template itself. Tell, Don’t Ask saved the day.
I got the usual Objective-C method declaration: When you reference this method, its proper name is tableView:cellForRowAtIndexPath:. Removing all the parameter declarations and the return type by hand is really tedious. I wrote a Keyboard Maestro macro to remedy my pain: