Posted on July 9, 2017 by sexysoftwareengineer

Protocols as boundaries between the known and the unknown

In the previous post, we discussed how protocols ¹ are the foundation of polymorphism, and how using protocols we can define a contract, an expectation, that can be implemented in many different ways.

Today we are also to explore how we can use protocols as a way to use code that does not exist yet, as a boundary between what we know (our code) and what we don’t know (other people’s code).

In an ideal world (maybe not ideal for everyone, but that would be a different discussion) we don’t develop our software in isolation. We have team mates, or we use modules or frameworks developed by other teams within the same company.

Some time ago, I was with a time developing a set of Video On Demand applications. We had to implement a new feature: add support for recommendations based on user’s content consumption habits. The recommendations engine was not developed yet, in fact there was no team assigned to build it at that time.

We knew were our side of the solution started and ended. We knew we were going to need to tell the recommendations engine that a user had watched a particular item, and we were going to need to get a list of recommended items from the engine.

We started by defining our own interface for that recommendations engine. We looked at the problem from ur side of it, and wrote the interface we wished the recommendations engine had.

Did we know how the actual interface of the actual recommendations engine would look? Not at all. Did we care? We did not.

But we could start working on our side of the solution using fake data.

Having a clear boundary, clear separation between our side and their side, allowed us to build our side completely decoupled from the recommendations engine.

Having a clear boundary also gave us the confidence that we would be able to adapt to whatever the actual interface of the recommendations engine would look. And why I mean by adapt is literally write an adapter between our interface and the actually interface of the engine, if necessary (see the Adapter Pattern)

Also, having a clear boundary allowed us to unit test our solution from day one, giving us the confidence we needed to move forward fast.

It’s not rocket science. But it is worth remembering that protocols are not just those things that you use for table views data sources and delegates, but that they are probably the most powerful tool in our reach.

I have never been a fan of how the Cocoa frameworks use the word protocol instead of interface. ↩︎

Posted on May 25, 2016 by sexysoftwareengineer

TIL: UIViewController.init() might initialize a xib

It is all in the documentation, both in the UIViewController Class Reference, and in the comments in the class header. It also makes sense, but today I spent a couple of hours debugging a weird crash, due to this.

So this is something I think I won’t forget in a long time.

When initializing a view controller passing nil as a nib, the view controller will attempt to load a nib whose name is the as same as the view controller’s class. That’s what the UIViewController header clearly states:

If you
invoke this method with a nil nib name, then this class’ -loadView method will attempt to load a NIB whose
name is the same as your view controller’s class. If no such NIB in fact exists then you must either call
-setView: before -view is invoked, or override the -loadView method to set up your views programatically

But there is more. According to the UIViewController class reference:

If you use a nib file to store your view controller’s view, it is recommended that you specify that nib file explicitly when initializing your view controller. However, if you do not specify a nib name, and do not override the loadView method in your custom subclass, the view controller searches for a nib file using other means. Specifically, it looks for a nib file with an appropriate name (without the .nib extension) and loads that nib file whenever its view is requested. Specifically, it looks (in order) for a nib file with one of the following names:

If the view controller class name ends with the word ‘Controller’, as in MyViewController, it looks for a nib file whose name matches the class name without the word ‘Controller’, as in MyView.nib.

It looks for a nib file whose name matches the name of the view controller class. For example, if the class name is MyViewController, it looks for a MyViewController.nib file.

And that’s exactly what happened to me earlier today. I was initializing a view controller like this:

let vc = AddContactViewController()

1 2	let vc = AddContactViewController()

While also having in the project a completely unrelated xib, named AddContactView. Unrelated, like in “AddContactViewController does not use AddContactView.xib at all. Nothing. Zero.”

So my app was crashing, throwing an assertion that kindly reminded me that AddContactView did not have any owner properly setup.

Well, there is a reason for that.

Remember, read your docs! 💁

Posted on May 24, 2016 by sexysoftwareengineer

Swift extensions can be applied to Objective-C types

The more I think about this, the more obvious it sounds. And the more I think about it, the less I believe it deserves a post. But it was a pleasant surprise anyway, so here it goes.

Let’s assume we have an Objective-C project, that contains a class like this:

//Person.h

@interface Person : NSObject
@property (nonatomic, copy, readonly) NSString *name;
@property (nonatomic, assign, readonly) NSInteger age;

- (instancetype) initWithName: (NSString *) name age: (NSInteger) age;
@end

//Person.m
#import "Person.h"

@interface Person()
@property (nonatomic, copy, readwrite) NSString *name;
@property (nonatomic, assign, readwrite) NSInteger age;
@end

@implementation Person
- (instancetype) initWithName: (NSString *) name age: (NSInteger) age
{
  if (self = [super init])
  {
    _name = name;
    _age = age;
  }

  return self;
}
@end

//Person.h

@interface Person : NSObject

@property (nonatomic, copy, readonly) NSString *name;

@property (nonatomic, assign, readonly) NSInteger age;

- (instancetype) initWithName: (NSString *) name age: (NSInteger) age;

@end

//Person.m

#import "Person.h"

@interface Person()

@property (nonatomic, copy, readwrite) NSString *name;

@property (nonatomic, assign, readwrite) NSInteger age;

@end

@implementation Person

- (instancetype) initWithName: (NSString *) name age: (NSInteger) age

{

if (self = [super init])

{

_name = name;

_age = age;

}

return self;

}

@end

And it also contains another class like this:

//Movie.h
@interface Movie : NSObject
@property (nonatomic, copy, readonly) NSString *title;
@property (nonatomic, copy, readonly) NSString *director;

- (instancetype) initWithTitle: (NSString *) title director: (NSString *) director;
@end

//Movie.m

#import "Movie.h"

@interface Movie()
@property (nonatomic, copy, readwrite) NSString *title;
@property (nonatomic, copy, readwrite) NSString *director;
@end

@implementation Movie

- (instancetype) initWithTitle: (NSString *) title director: (NSString *) director
{
  if (self = [super init])
  {
    _title = title;
    _director = director;
  }

  return self;
}
@end

//Movie.h

@interface Movie : NSObject

@property (nonatomic, copy, readonly) NSString *title;

@property (nonatomic, copy, readonly) NSString *director;

- (instancetype) initWithTitle: (NSString *) title director: (NSString *) director;

@end

//Movie.m

#import "Movie.h"

@interface Movie()

@property (nonatomic, copy, readwrite) NSString *title;

@property (nonatomic, copy, readwrite) NSString *director;

@end

@implementation Movie

- (instancetype) initWithTitle: (NSString *) title director: (NSString *) director

{

if (self = [super init])

{

_title = title;

_director = director;

}

return self;

}

@end

Now, let’s say we declare a Swift protocol like this:

@objc protocol Displayable {
  var firstLineContent: String { get }
  var secondLineContent: String { get }
}

@objc protocol Displayable {

var firstLineContent: String { get }

var secondLineContent: String { get }

}

And extensions to the Person and Movie object to enforce compliance with the Displayable protocol:

extension Person: Displayable {
  var firstLineContent: String {
    return "Name \(name)"
  }

  var secondLineContent: String {
    return "Age \(age)"
  }
}

extension Movie: Displayable {
  var firstLineContent: String {
    return "Title \(title)"
  }

  var secondLineContent: String {
    return "Director \(director)"
  }
}

extension Person: Displayable {

var firstLineContent: String {

return "Name \(name)"

}

var secondLineContent: String {

return "Age \(age)"

}

extension Movie: Displayable {

var firstLineContent: String {

return "Title \(title)"

}

var secondLineContent: String {

return "Director \(director)"

}

Now, we can consume the Displayable protocol from Swift:

final class TableBuilder: NSObject {

  override init() {
    super.init()
    printAllTheThings()
  }

  private func printAllTheThings() {
    let items = getItems()
    for displayable in items {
      print("Swift: First line: ", displayable.firstLineContent)
      print("Swift: Second line: ", displayable.secondLineContent)
    }
  }

  private func getItems( ) -&gt; [Displayable] {
    let meFakingMyAge = Person(name: "Cesar", age: 21)
    let movie = Movie(title: "The Quiet Man", director: "John Ford")

    return [meFakingMyAge, movie]
  }

}

final class TableBuilder: NSObject {

override init() {

super.init()

printAllTheThings()

}

private func printAllTheThings() {

let items = getItems()

for displayable in items {

print("Swift: First line: ", displayable.firstLineContent)

print("Swift: Second line: ", displayable.secondLineContent)

}

private func getItems( ) -> [Displayable] {

let meFakingMyAge = Person(name: "Cesar", age: 21)

let movie = Movie(title: "The Quiet Man", director: "John Ford")

return [meFakingMyAge, movie]

}

Or from Objective-C (please, excuse the weakness of my ObjC-generics kung fu):

#import "TableBuilderObjC.h"
#import "ProtocolExtensionsInterop-Swift.h"

@implementation TableBuilderObjC
- (instancetype) init {
  if (self = [super init]) {
    [self printAllTheThings];
  }

  return self;
}

- (void) printAllTheThings {
  NSLog(@"printing from Obj-C ========");
  NSArray&lt;NSObject&lt;Displayable&gt; *&gt; *items = [self buildItems];
  for (NSObject&lt;Displayable&gt; *item in items)
  {
    NSLog(@"ObjC: first Line %@", [item firstLineContent]);
    NSLog(@"ObjC: second line %@", [item secondLineContent]);
  }
}

- (NSArray&lt;NSObject&lt;Displayable&gt; *&gt; *) buildItems {  
  Person *meFakingMyAge = [[Person alloc] initWithName: @"Cesar" age: 21];
  Movie *theQuiteMan = [[Movie alloc] initWithTitle: @"The Quiet Man" director: @"John Ford"];

  NSMutableArray&lt;NSObject&lt;Displayable&gt; *&gt; *returnValue = [[NSMutableArray alloc] initWithCapacity:2];
  [returnValue addObject:meFakingMyAge];
  [returnValue addObject:theQuiteMan];
  return returnValue;
}
@end

#import "TableBuilderObjC.h"

#import "ProtocolExtensionsInterop-Swift.h"

@implementation TableBuilderObjC

- (instancetype) init {

if (self = [super init]) {

[self printAllTheThings];

}

return self;

}

- (void) printAllTheThings {

NSLog(@"printing from Obj-C ========");

NSArray<NSObject<Displayable> *> *items = [self buildItems];

for (NSObject<Displayable> *item in items)

{

NSLog(@"ObjC: first Line %@", [item firstLineContent]);

NSLog(@"ObjC: second line %@", [item secondLineContent]);

}

- (NSArray<NSObject<Displayable> *> *) buildItems {

Person *meFakingMyAge = [[Person alloc] initWithName: @"Cesar" age: 21];

Movie *theQuiteMan = [[Movie alloc] initWithTitle: @"The Quiet Man" director: @"John Ford"];

NSMutableArray<NSObject<Displayable> *> *returnValue = [[NSMutableArray alloc] initWithCapacity:2];

[returnValue addObject:meFakingMyAge];

[returnValue addObject:theQuiteMan];

return returnValue;

}

@end

Which, believe me, is a huge relief when dealing with large legacy projects.

In case you want to play with a complete example, I uploaded a sample project to GitHub.

Posted on May 18, 2016 by sexysoftwareengineer

Clarity is more important than brevity. Sometimes you can have both.

The Swift API Design Guidelines are crystal clear.

Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate.

Writing compact code is a non-goal. But, often times, it just happens.

Posted on February 14, 2016February 14, 2016 by sexysoftwareengineer

The migration to Swift might very well start in the testing bundle

TL;DR;

Unit tests covering Objective-C code can be written in Swift. By following this approach, we can kill two birds with one stone: add testing coverage while starting to introduce Swift into an Objective-C project.

This is hardly news: Swift and Objective-C can coexist in the same project.

If you are having a hard time finding how and where to start adding Swift to a legacy project, or you are not really sure if Swift is for you, or your management thinks Swift is just a fad, or just “syntactic sugar”¹, or not mature enough, it might be the moment to turn to your testing bundle.

Killing two birds with one stone

Every piece of software should be unit tested. If your project is not tested, I strongly recommend adding unit tests to it as soon as possible.

So, if your project does not contain any tests, you can kill two birds with one stone, by starting to add tests, writing them in Swift. And if you project already contains tests, one way of dipping your toes into the Swift world could be using Swift to write your unit tests.

Let’s assume we have an Objective-C only project. To complicate things just a little bit, let’s assume this project does not even contain a testing bundle.

Follow these easy steps

Add a testing bundle. This step would not be necessary if you already have a testing bundle.

Select Swift as the testing bundle language. Not necessary if you already have a testing bundle.

Add a bridging header to the production bundle. The easiest way to do that, in my opinion, is by adding a dummy Cocoa class, to be removed later, selecting Swift as the language, and letting Xcode take care of adding the header for you. After Xcode adds the header, the new class can just be removed from the project.

Import the Objective-C class or classes you want to test in the bridging header.
Update the testing bundle’s build settings, pointing the the Objective-C Bridging Header setting to the header that was created in step 3.

Add a Test Case, selecting Swift as language.

Write the Test Case in Swift.
Enjoy.

The final result would be that a class like this:

@interface Person : NSObject
@property (nonatomic, strong, readonly) NSString *name;
@property (nonatomic, strong, readonly) NSString *surname;

-(instancetype) initWithName:(NSString *) name surname: (NSString *) surname;
@end

@interface Person()
@property (nonatomic, strong, readwrite) NSString *name;
@property (nonatomic, strong, readwrite) NSString *surname;
@end

@implementation Person
-(instancetype) initWithName:(NSString *) name surname: (NSString *) surname
{
    if (self = [super init])
    {
        _name = name;
        _surname = surname;
    }
    
    return self;
}
@end

@interface Person : NSObject

@property (nonatomic, strong, readonly) NSString *name;

@property (nonatomic, strong, readonly) NSString *surname;

-(instancetype) initWithName:(NSString *) name surname: (NSString *) surname;

@end

@interface Person()

@property (nonatomic, strong, readwrite) NSString *name;

@property (nonatomic, strong, readwrite) NSString *surname;

@end

@implementation Person

-(instancetype) initWithName:(NSString *) name surname: (NSString *) surname

{

if (self = [super init])

{

_name = name;

_surname = surname;

}

return self;

}

@end

Can be tested like this:

import XCTest

class PersonTests: XCTestCase {
    private struct Constants {
        static let name = "🌹"
        static let surname = "🐞"
    }
    
    var person: Person?

    override func setUp() {
        super.setUp()
        person = Person(name: Constants.name, surname: Constants.surname)
    }
    
    override func tearDown() {
        person = nil
        super.tearDown()
    }

    func testPersonNameIsSetProperly() {
        XCTAssertEqual(person?.name, Constants.name);
    }
}

import XCTest

class PersonTests: XCTestCase {

private struct Constants {

static let name = "🌹"

static let surname = "🐞"

}

var person: Person?

override func setUp() {

super.setUp()

person = Person(name: Constants.name, surname: Constants.surname)

}

override func tearDown() {

person = nil

super.tearDown()

}

func testPersonNameIsSetProperly() {

XCTAssertEqual(person?.name, Constants.name);

}

Emoji in the unit test! That’s what I call a win-win situation!

You can check out a sample project available in GitHub.

Yep, a CTO told me, less than a moth ago, that “Swift is just syntax” 😳🙄 ↩︎

Posted on February 8, 2016 by sexysoftwareengineer · 2 Comments

MVC or MVVM?

The last couple of years there has been a lot of discussion in the community about one of the most pressing issues when it comes to writing maintainable applications.

And that pressing issue is no other than the size of view controllers. View controllers tend to become a kitchen sink, a mix of responsibilities, that handle networking, deal with navigation or validate user data.

MVC, or at least the flavour of MVC recommended by Apple’s documentation has been partially blamed for it. And MVVM has been suggested as a better practice, designed to avoid finding yourself with a huge view controller that does too many things.

But here is the thing: I don’t think MVVM is intrinsically better than MVC. Nor the other way around. I have the feeling that sometimes MVVM is sold as some kind of silver bullet that, in combination with a more functional style, is going to, magically, make our lives easier.

I love the idea of separating presentation and presentation logic, which is something MVVM advocates for. But, I don’t think that, by itself, is enough. I think it is necessary to do much more than just embracing a different pattern, no matter how good that pattern looks on paper.

I believe this book (highly recommended, non-affiliated link) is the first one where I read about the idea of micro-architectures. Basically, the idea is: when facing a problem, don’t try to think too big, try to build a solution that solves the problem in a clean, extensible and testable way.

I think that micro-architectures pay off at a local scope. But the way micro-architectures really shine is by accumulation. When you start solving small, limited in scope, contained problems by architecting the crap out of them, everything else starts falling into place, and you start noticing how an application-wide architecture starts emerging.

How? A local, isolated, solution usually leads to a better solution at a wider scope, which usually shows the way to a better solution to an even wider scope.

For example, if you remove from a view controller the responsibility of creating and navigating to another view controller by adding a class to the system that takes care of doing that, you might find that if you inject that class into every other view controller you might generalise it to deal with all the navigation logic in your app. So, now, you need to find a way to inject that NavigationManager into all your view controllers, so it might make sense to have another class that takes care only of creating view controllers. It would be great if you could pass your NavigationManager to this new UIManager, so you might need something that creates both and injects one into another. That could be an ApplicationBootstrapper that you create in the App Delegate. See the pattern? Decisions at a local level propagate up, so you can build an application-wide architecture from the bottom up.

The point I am trying to make is: applying the SOLID principles everywhere, all the time, is going, by accumulation, to produce well architected, maintainable and testable applications.

Embracing MVC, MVVM, or whatever goes into fashion next, by itself, is not going to be enough. I think it is better to embrace whatever pattern you understand better, or think is good for you and your application, or you can reason about better, and keep always a vigilant and critical eye on every decision you make. Trust your instincts, and as soon as you notice a bad smell, micro-architect the crap out of whatever you are building.

Posted on November 17, 2015 by sexysoftwareengineer

The Week in Cocoa News

Greetings, fellow Cocoa developers, and welcome to a new edition of The Week in Cocoa News, your weekly mash-up of bad jokes and links to blogposts and articles of interest to the discerning Cocoa developer in your life.

So, let’s get the bad joke out the way first. And trust me, this is a really bad one

Knock, knock.

Race condition.

Who’s there.

Badum-tsh!

Before you shoot yourself, read the following post. It contains plenty of what’s best about Swift -type-safety, the possibility of avoiding all “sting-typed” programming, easy ways to modify behaviour without relying on extension, to name a few-, in this case in the context of the “classic” Objective-C territory: UIKit

Let’s Get Meta: Swift Metatypes and Cell Reuse

Seriously, don’t do strings. Winners don’t do strings.

Anyway, here is a little bit more on types and meta types in Swift:

Types and meta types in swift

Enough with the meta-stuff! We started talking UIKit, so this looks like a good moment to link to this other post:

Unwind Segues as an Alternative to Delegation

Lately I have been reading a lot about DSLs. I believe DSLs are great tools that are greatly underused. Here is a good example of how a little DSL’ing can take you a long way.

Implementing a Small DSL in Swift

Now it’s time for another favourite of mine: unit testing:

Better Unit Testing with Swift

To be honest, most of the suggestions in that article are not about Unit Testing, but just about good engineering (injecting static dependencies, relying on abstractions -protocols- and not concretions -classes-), but again, this just prove the point of TDD: there is usually a correlation between good production and good testing code.

By the way, now that we are discussing testing. it might be a good moment to link to Nimble, the matcher framework for Swift (and Objective-C)

Nimble

And to wrap up this Edition of The Week in Cocoa News, deep linking and iOS 9:

How to Set Up Universal Links to Deep Link on Apple iOS 9

And that’s all, folks! See you next week, in another Edition of The Week in Cocoa News.

Posted on September 11, 2015 by sexysoftwareengineer

About enumerations in Swift

The last project I have been working on is a set of highly customisable applications, that need to render their user interface according to some configuration downloaded from a remote service. Meh.

But, the thing is, a setup like this leaves a lot of opportunities for Swift to shine. One of those opportunities is implementing color schemes.

The context

All the colours used in an application need to be declared as part of a color scheme, that needs to be downloaded from a remote service. For the shake of this example, we are going to leave the “download it from a remote service” part out of the equation.

A good approach

Well, this is Cocoa, so, the first approach that comes to mind would be declaring an extension on UIColor, and declare the different palette items in it. Something like this:

extension UIColor {
    class func foregroundColor() -> UIColor {
        return UIColor(red: 0/255.0, green: 174/255.0, blue: 239/255.0, alpha: 1)
    }

    class func backgroundColor() -> UIColor {
        return UIColor(red: 25/255.0, green: 22/255.0, blue: 22/255.0, alpha: 1)
    }
}

extension UIColor {

class func foregroundColor() -> UIColor {

return UIColor(red: 0/255.0, green: 174/255.0, blue: 239/255.0, alpha: 1)

}

class func backgroundColor() -> UIColor {

return UIColor(red: 25/255.0, green: 22/255.0, blue: 22/255.0, alpha: 1)

}

Which is a perfectly valid approach. But, that is basically a literal translation of what I would do in Objective-C, if I had to figure out a way out of this problem. Which is not bad.

But…

A better approach

The previous approach does not feel very Swift-ish. And, what is worst to me, it does not seem extremely flexible. For example, how would I deal with a requirement such as “yo, bro! can we make the color scheme change at runtime?. Like, you know, light theme during day hours, dark theme during night hours? That’d be sooooo coooooooooool”

Well, let’s try a fresh approach to the problem at hand. What’s a color scheme? To me, it is a set of mutually exclusive values. The active color scheme can be Light, or Dark, not Light and Dark at the same time.

And that, in Swift, is an enumeration. Also, it happens that Swift enumeration can implement methods. So, we could rewrite the previous extension as:

enum ColorScheme {
    case Light
    case Dark
    
    var backgroundColor: UIColor {
        let returnValue: UIColor
        switch (self) {
            case .Light:
                returnValue = .lightGrayColor()
            case .Dark:
                returnValue = .blackColor()
        }
        
        return returnValue
    }
    
    var foregroundColor: UIColor {
        let returnValue: UIColor
        switch (self) {
            case .Light:
                returnValue = .blackColor()
            case .Dark:
                returnValue = .whiteColor()
        }
        return returnValue
    }
}

enum ColorScheme {

case Light

case Dark

var backgroundColor: UIColor {

let returnValue: UIColor

switch (self) {

case .Light:

returnValue = .lightGrayColor()

case .Dark:

returnValue = .blackColor()

}

return returnValue

}

var foregroundColor: UIColor {

let returnValue: UIColor

switch (self) {

case .Light:

returnValue = .blackColor()

case .Dark:

returnValue = .whiteColor()

}

return returnValue

}

Now, we can set the active scheme as:

var scheme: ColorScheme = .Dark

1	var scheme: ColorScheme = .Dark

And consume it, everywhere in the UI as:

square.backgroundColor = scheme.backgroundColor

1	square.backgroundColor = scheme.backgroundColor

All of that, backed up by the compiler, which will make sure that we do not miss any possible value of the color scheme in its methods.

Final words

Switching to Swift is not only a matter of writing code in a different language, it is also a matter of forgetting about most of the old patterns, and embrace new ways.

And that sounds like a lot of fun to me.

Here is the playground: ColorPalette.playground

Posted on August 13, 2015 by sexysoftwareengineer

Sunsetting id

I am the first to be surprised to find a post about good old Objective-C in this blog. This Sexy Software Engineer has not written any Objective-C code in almost a year! This Sexy Software Engineer, though, still enjoys using the Royal We. Some things ain’t changin’

A little bit of ancient history

Those, like me, old enough to be around in the “good old days”, before ARC, when memory had to be manually managed, will remember how a proper constructor (sorry, initializer) in a proper Objective-C class was supposed to return id

@interface SexySoftwareEngineer
- (id) initWithName: (NSString*) name surname: (NSString *) surname;
@end

@interface SexySoftwareEngineer

- (id) initWithName: (NSString*) name surname: (NSString *) surname;

@end

id meant “Yo! Compiler! This is untyped! Have fun with it!” Or something similar. You get the point.

But then ARC came in with all its modern memory management, and all its fancy annotations, and suddenly, the right thing to do was to type return types in initialisers as instancetype

@interface SexySoftwareEngineer
- (instancetype) initWithName: (NSString*) name surname: (NSString *) surname;
@end

@interface SexySoftwareEngineer

- (instancetype) initWithName: (NSString*) name surname: (NSString *) surname;

@end

A little bit of contemporary history

Here we are now, one year into the Swift age. Lots of things have changed, and most of us do not consider the fully dynamic nature of Objective-C a selling point anymore. We might still miss it sometimes, but we like the warm and fuzzy feeling of relying on the compiler, and let it catch potential problems for us.

But, and this is a big but, we still need to rely on Objective-C libraries and frameworks daily. And those are not trivial libraries, those are the actual SDK frameworks (AppKit, UIKit and Foundation), which are still Objective-C

Apple is doing a great job in making the interoperability as smooth as possible. Please, watch the WWDC Session Swift and Objective-C interoperability right now, and you will get a great walkthrough everything that has been done in order to turn Swift code that uses Objective-C code into something safe. Let’s just say that now you can do something like this:

@interface SexySoftwareEngineer
- (Nullable instancetype) initWithName: (nonnull NSString*) name surname: (nonnull NSString *) surname;
@end

@interface SexySoftwareEngineer

- (Nullable instancetype) initWithName: (nonnull NSString*) name surname: (nonnull NSString *) surname;

@end

Back to the point: what’s with id?

By adding some extra metadata to the Objective-C code, like nullability and “kindof” annotations, or by embracing generics, Objective-C code will be more robust, less error prone, and Swift code that uses Objective-C can be safer.

Values marked as Nullable in Objective-C will be considered as Optionals in Swift. Typed Objective-C arrays will not be AnyObject arrays in Swift anymore. And that’s very good.

But still, what happens to id? Well, there are still two use cases for it:

Store different types of values in a Dictionary.
Type something as “any object implementing a protocol”

The second use case is something I have not done in many years (I always used to type pointers to protocols as NSObject <MyProtocol>).

The first one, is something that, although powerful, I always considered as a code smell.

So there you are, that’s the reason behind the post title.

Posted on June 18, 2015 by sexysoftwareengineer

What’s new in Swift 2: throw

Error handling is hard. Error handling is tedious. And what happens when something is hard and tedious? It gets ignored.

How many times have you done something similar to this?

NSData *JSONData = [ NSJSONSerialization dataWithJSONObject: parsedLockStatus options:0 error: NULL ];

1	NSData *JSONData = [ NSJSONSerialization dataWithJSONObject: parsedLockStatus options:0 error: NULL ];

instead of this?

NSError *error = nil;
 
NSData *JSONData = [ NSJSONSerialization dataWithJSONObject: parsedLockStatus options:0 error: &error ];
 
if( !error )
{
// Do your fancy stuff
}

NSError *error = nil;

NSData *JSONData = [ NSJSONSerialization dataWithJSONObject: parsedLockStatus options:0 error: &error ];

if( !error )

{

// Do your fancy stuff

}

Riiiiiiight, you are the only one that never did that.

Error handling sucks

Let’s be honest. Error handling sucks, big time. Even thought the Cocoa frameworks (those on Mac OS X in particular) have always provided great resources for error handling and, in particular, error recovery.

But, you know, exhibit A.

So, here comes Swift 2 to the rescue, introducing something that will make roll the eyes to our Java-oriented friends in the house: throw

throw does not suck that bad

Yes, I know, I know, Java has been throwing exceptions for years, and Java this and Java that. But, first, Swift throws does not have any performance side effects, opposing to Java exceptions, (meaning, your program is not going to slow down to a crawl when you try to throw one) and second, and most important, using throw, and its sidekicks try and do catch, you can make your code intent extremely clear and obvious to anyone reading your code (including yourself in a couple of months time).

So, how does the awesome shinny new thing works? Actually, it is quite simple.

If you want to Do Things Properly(TM), the first thing you would need to do would be declaring your error type, which should conform to, surprise, ErrorType. Why would you ever want to conform to ErrorType? Well, because that’s what NSError conforms to. Wink, wink, nudge, nudge.

So, again, your error:

enum Error: ErrorType {
    case Dummy
}

enum Error: ErrorType {

case Dummy

}

Remember the previous post? We had a function that bailed out as soon as a set of sanity preconditions where not met. Well, let’s rewrite that one to, instead of just bailing out, throwing one of your shinny new errors.

func divide(x: Int?, y: Int?) throws -> Double {
    guard let x = x, y = y where y > 0 else {
        throw Error.Dummy
    }
     
    return Double(x)/Double(y)
}

func divide(x: Int?, y: Int?) throws -> Double {

guard let x = x, y = y where y > 0 else {

throw Error.Dummy

}

return Double(x)/Double(y)

}

Please note that, in theory at least, throwing an error is not supposed to be that different from an early return. Specially in terms of performance. In other words, throwing errors is the cool thing to do now.

Now, clients of this function can do this:

do {
    try divide2(10, y: nil)
} catch Error.Dummy {
    print("What are you doing, you idiot!?")
}

do {

try divide2(10, y: nil)

} catch Error.Dummy {

print("What are you doing, you idiot!?")

}

Note how you must add the try keyword when calling a function that throws something. Explicit much?

Final words

Now, as usual, reader discretion is advised. Use this at your own risk. It is not that hard to end up with code like this:

enum Error: ErrorType {
    case Zero
    case Negative
    case Null
}
 
func divide(x: Int?, y: Int?) throws -> Double {
    guard let x = x, y = y else {
        throw Error.Null
    }
 
    guard y > 0 else {
        throw Error.Negative
    }
     
    guard y != 0 else {
        throw Error.Negative
    }
 
    return Double(x)/Double(y)
}
 
 
do {
    try divide(10, y: nil)
} catch Error.Zero {
    print("Do not do that, man!. Do not pass a zero as second argument!")
} catch Error.Negative {
    print("Do not do that, man!. Do not pass a negative number as second argument!")
} catch Error.Null {
    print("Do not do that, man!. Do not pass any nil argument!")
}

enum Error: ErrorType {

case Zero

case Negative

case Null

}

func divide(x: Int?, y: Int?) throws -> Double {

guard let x = x, y = y else {

throw Error.Null

}

guard y > 0 else {

throw Error.Negative

}

guard y != 0 else {

throw Error.Negative

}

return Double(x)/Double(y)

}

do {

try divide(10, y: nil)

} catch Error.Zero {

print("Do not do that, man!. Do not pass a zero as second argument!")

} catch Error.Negative {

print("Do not do that, man!. Do not pass a negative number as second argument!")

} catch Error.Null {

print("Do not do that, man!. Do not pass any nil argument!")

}

The Amazing Adventures of a Sexy Software Engineer

Category: Objective-C

Protocols as boundaries between the known and the unknown

TIL: UIViewController.init() might initialize a xib

Swift extensions can be applied to Objective-C types

Clarity is more important than brevity. Sometimes you can have both.

The migration to Swift might very well start in the testing bundle

Killing two birds with one stone

Follow these easy steps

MVC or MVVM?

The Week in Cocoa News

About enumerations in Swift

The context

A good approach

A better approach

Final words

Sunsetting id

A little bit of ancient history

A little bit of contemporary history

Back to the point: what’s with id?

What’s new in Swift 2: throw

Error handling sucks

throw does not suck that bad

Final words