
With the addition of error handling to Swift 2, we got a way to deal with errors with the nice try/catch exception handling syntax from many languages,
but without the associated cost of stack unwinding.

As with anything new, some questions come to mind. How do we test methods that can throw errors? In Objective-C we had a few `XCTest` assert macros to help with this, like `XCTAssertThrows`. Swift 1 does not support exceptions, so these macros,
which get translated to Swift functions, are absent from the `XCTest` framework in Swift. I was expecting to find them in the Swift 2 version of the framework,
but they're missing.

So the first thing that comes to mind is to just wrap the asserts into do/catch blocks.

```swift
func testSomething() {
    do {
        try XCTAssert(parseSomething() == "result")
    } catch {
        XCTFail("Parsing failed.")
    }
}
```

And Xcode complains: _"Call can throw, but it is executed in a non-throwing autoclosure."_

Assert macros use the `@autoclosure` attribute, so everything you pass to them becomes a closure. A non-throwing closure.
So you need to first try to get the result and pass just that.

```swift
func testSomething() {
    do {
        let result = try parseSomething()
        XCTAssertEqual("result", result)
    } catch {
        XCTFail("Parsing failed.")
    }
}
```

This works. But, we hate repetition, don't we?

```swift
func XCTAssertThrows<T>(@autoclosure expression: () throws -> T, _ message: String = "", file: String = __FILE__, line: UInt = __LINE__) {
    do {
        try expression()
        XCTFail("No error to catch! - \(message)", file: file, line: line)
    } catch {
    }
}

func XCTAssertNoThrow<T>(@autoclosure expression: () throws -> T, _ message: String = "", file: String = __FILE__, line: UInt = __LINE__) {
    do {
        try expression()
    } catch let error {
        XCTFail("Caught error: \(error) - \(message)", file: file, line: line)
    }
}

func testSomething() {
    XCTAssertNoThrow(try parseSomething())
    XCTAssertThrow(try parseOtherThing())
}
```

Good. We can check if a method throws or not. But some methods return things and we would like to compare these things to other things.

```swift
func XCTAssertNoThrowEqual<T : Equatable>(@autoclosure expression1: () -> T, @autoclosure _ expression2: () throws -> T, _ message: String = "", file: String = __FILE__, line: UInt = __LINE__) {
    do {
        let result2 = try expression2()
        XCTAssertEqual(expression1, result2, message, file: file, line: line)
    } catch let error {
        XCTFail("Caught error: \(error) - \(message)", file: file, line: line)
    }
}

func testSomething() {
    XCTAssertNoThrowEqual("result", try parseSomething())
}
```

Ok, that's equality. But what about >, < and membership checks? Let's add a validator closure then.

```swift
func XCTAssertNoThrowValidateValue<T>(@autoclosure expression: () throws -> T, _ message: String = "", file: String = __FILE__, line: UInt = __LINE__, _ validator: (T) -> Bool) {
    do {
        let result = try expression()
        XCTAssert(validator(result), "Value validation failed - \(message)", file: file, line: line)
    } catch let error {
        XCTFail("Caught error: \(error) - \(message)", file: file, line: line)
    }
}

func testSomething() {
    XCTAssertNoThrowValidateValue(try parseSomething()) { $0 > 5 }
}
```

This covers my use cases for now!

Testing Throwable Methods in Swift 2


Like just about any other iOS developer, I was caught completely by surprise when Apple announced Swift.
I was expecting modest improvements to Objective-C, maybe even an Objective-C 3.0 release, but nothing as wild as a new language.
But I got excited, really excited, when I watched the state of the union video (no, I was not one of the lucky WWDC ticket lottery winners).
I started reading the Swift book right away. _“I’m going to read this trough first,”_ I said to myself, _“and hack later.”_
Well, guess what? I started hacking after the introduction chapter. After I alternated between reading and hacking for a while,
I needed a project to work on. And so I chose to port [JSImageLoader](https://github.com/jernejstrasner/JSImageLoader) to Swift and see how it goes.

__Update__: See the updated code for Swift 1.2 at the bottom of this post.

The first thing I did was to outline classes and add properties. This was easy. The second step was to implement initializers.
Trivial, if it’s not a singleton. My first idea was to write it the exact same way I would do it in Objective-C, using dispatch_once.
I came across a major difference right away; static variables can only be declared inside enums and structs.
Luckily structs can be defined inside methods and, like in this case, property getters. So I came up with the code below:

```swift
class MyClass {
    class var sharedInstance: MyClass {
        struct Singleton {
            static var token : dispatch_once_t = 0
            static var instance : MyClass?
        }
        dispatch_once(&Singleton.token) {
            Singleton.instance = MyClass()
        }
        return Singleton.instance!
    }
}
```

Works, great!

Then I read more of the book, watched some more WWDC videos and browsed more of the Apple developer forums.
Then I found this post by Joe Groff (@jckarter) who works on the Swift compiler:

> Global and static properties are already dispatch_once’d, so there’s really no need for this. You can simply define the singleton instance as a global variable or static let property of a struct.

This is getting better and better! He says there are two options, one with a global variable and one with a static let as the property of a struct.
I’m not a fan of polluting the global space too much so I chose the latter:

```swift
class MyClass {
    class var sharedInstance: MyClass {
        struct Singleton {
            static let instance = MyClass()
        }
        return Singleton.instance
    }
}
```

Much nicer!

While I do agree that this could be made even nicer by having a private static class let property,
I think that it’s great that global variables and static let properties are wrapped in dispatch_once.
I’m sticking to this implementation for now.

__Update__: Swift 1.2 added support for static properties on classes so now a singleton can be simply initialized when declaring the property. No more embedded structs!

```swift
class MyClass {
    static let sharedInstance = MyClass()
}
```

That’s it!


Singleton Pattern in Swift


I spent the past few weeks digging into Swift while working on PSPDFKit. Today I was trying to enumerate a directory recursively.
I resorted to `NSFileManager` and its method `enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:`.
It returns an `NSDirectoryEnumerator` object which supports `NSFastEnumeration`. That means you can use the for-in loop in Objective-C.
Without thinking, I wrote a for-in loop in Swift. Not so fast.

> Type `NSDirectoryEnumerator` does not conform to protocol `SequenceType`.

Apple should have supported this. So I spent some time browsing trough the Swift headers and with the help of generics
I wrote a custom substruct (?) that conforms to the `GeneratorType` protocol and can be initialized with an object of type `NSEnumerator`.

```swift
public struct GenericGenerator<T> : GeneratorType, SequenceType {
  let enumerator: NSEnumerator
  
  init(_ enumerator: NSEnumerator) {
    self.enumerator = enumerator
  }
 
  mutating public func next() -> T? {
    return self.enumerator.nextObject() as T?
  }
 
  public func generate() -> GenericGenerator<T> {
    return GenericGenerator<T>(self.enumerator)
  }
}
```

In my case I was dealing with `NSDirectoryEnumerator` which iterates trough `NSURL` objects. So I wrote an extension to extend it with support for `SequenceType`.
The nice thing is that using for-in in Swift now provides you with `NSURL` objects!

```swift
extension NSDirectoryEnumerator : SequenceType {
  public func generate() -> GenericGenerator<NSURL> {
    return GenericGenerator<NSURL>(self)
  }
}
```

This generic can now be used to extend any kind of `NSEnumerator` so you can enjoy clean for-in loops in Swift.


NSFastEnumeration in Swift


__UPDATE__: Updated for Swift, Swift 2 and packaged into a [drop-in replacement for UIView](https://github.com/jernejstrasner/Smooth-Gradient).

I thought drawing gradients on iOS is easy. Well, until our designer gave me this:

![Smooth gradient drawn in Photoshop](/images/2013-10-17/gradient_ps.png)

I went on and implemented the `drawRect:` method on a custom UIView. I used `CGGradient` and wrote the drawing code. I ran the project in the simulator and noticed that the gradient was quite different. Ran on the device, same thing.

![Gradient drawn with CGGradient](/images/2013-10-17/gradient_cg.png)

I played around with different colors and their positions but nothing turned out like the Photoshop gradient. After some head scratching I figured it must be something to do with how the colors are interpolated. `CGGradient` uses a linear interpolation of colors.

![Plot y = x](/images/2013-10-17/linear.png)

What I need is a slope (ease-in ease-out for you familiar with animation timings) function and apply that to each color component. I actually cared only about transparency so I had to only adjust the alpha channel.
I needed this:

![Plot slope function](/images/2013-10-17/slope_func.png)

![Plot slope](/images/2013-10-17/slope.png)

Looking at the documentation, `CGGradient` doesn't support custom color interpolation. There is something called `CGShading` that does. The documentation is not absolutely clear on how to use it, but after some experimenting I came up with a solution, which is presented below. There is also a sample project available on [GitHub](https://github.com/jernejstrasner/Smooth-Gradient) so you can compare CGGradient and CGShading.

Hope somebody finds this useful!

[gist](https://gist.github.com/jernejstrasner/6319645344d17e7df8aa)


Smooth gradients on iOS/OSX


Most programmers are familiar with the ternary operator [?:](http://en.wikipedia.org/wiki/%3F:#C) that is available in C and most other languages.
But what some people may not know is that you can also use this operator with only two arguments.

Instead of writing

```c
int y = 23;
int x = (y ? y : 34);
```

you can do this

```c
int y = 23;
int x = (y ?: 34);
```

The other thing some of you may not know is that when defining a const you can't use an if statement to define it based on a condition, but you can do this:

```c
int y = 23;
const int x = (y ?: 34);
```

That's it for the first post!


Jernej Štrasner

Archive

Testing Throwable Methods in Swift 2

Singleton Pattern in Swift

NSFastEnumeration in Swift

Smooth gradients on iOS/OSX

The ternary operator in C