Migrating to NSPersistentContainer

Update - 2017/07/12

if let oldUrl = oldUrl {
        let description = NSPersistentStoreDescription(url: oldUrl)
        persistentContainer.persistentStoreDescriptions = [description]
    }
    persistentContainer.loadPersistentStores { (description, error) in
        if let oldUrl = self.oldUrl {
        do {
            let psc = persistentContainer.persistentStoreCoordinator
            let store = psc.persistentStores[0]
            try psc.migratePersistentStore(store, to: url, options: nil, withType: NSSQLiteStoreType)                                                   self.deleteDatabase(url: oldUrl)
            self.cleanDb()
        } catch {
            block(description, error)
            return
        }
    }

Small update - instead of replacing, I use migratePersistentStore instead. This seems to work a little better with the current setup. So I have an oldUrl which is returned if the old store exists. If it's not nil I create the database against this and then migrate it to the correct location under Application Support. The old database still needs to be deleted in a separate step (assuming you no longer need it).


iOS 10 brought some welcome changes to Core Data and I need to migrate an existing database into this. Here’s how I did it.

First off, my existing DB is in the Documents folder. That’s not really good practice and NSPersistentContainer will create one in Application Support. That seems more sensible so I decided to move my Database. The default SQLite backed Core Data store includes SHM and WAL files (Write-Ahead Logging). To ensure you don’t lose data you need to move all three files at the same time. Fortunately, NSPersistentStoreCoordinator has built-in support for moving a database around.

First, I set up the NSPersistentStoreContainer:

persistentContainer = NSPersistentContainer(name: "GameModel")
persistentContainer.loadPersistentStores { (description, error) in
    if let error = error {
        fatalError("Could not create CoreData store: \(error)")
    }
    print(description)
}

This gives me something to work against. NSPersistentStoreContainer will create a NSPersistentStoreCoordinator with an sqlite DB at ApplicationSupport/GameModel.sqlite upon calling loadPersistentStores(completionHandler:). I want to replace that with the old Documents/Core_Data.sqlite. Fortunately, there’s a replace function right there.

let psc = persistentContainer.persistentStoreCoordinator
guard let storeUrl = psc.persistentStores.first?.url else {
    return
}
do {
    try psc.replacePersistentStore(at: storeUrl,
                                   destinationOptions: nil,
                                   withPersistentStoreFrom: oldUrl,
                                   sourceOptions: nil,
                                   ofType: NSSQLiteStoreType)
    persistentContainer.loadPersistentStores(completionHandler: { (description, error) in
        if let error = error {
            fatalError("Could not create CoreData store: \(error)")
        }
        print(description)
    })
} catch {
    print("Could not replace store: \(error)")
}

The newly created GameModel sqlite DB is replaced with the contents of the existing database by the replace call. I then need to call loadPersistentStores again to set up the NSPersistentContainer against the updated DB. Once it’s successful, I can delete the old DB files. There might be a better way, but this worked for me:

private func deleteOld(url: URL) {
        let parent = url.deletingLastPathComponent()
        let name = url.lastPathComponent
        do {
            try FileManager.default.contentsOfDirectory(at: parent, includingPropertiesForKeys: nil, options: [])
                .filter {
                    $0.lastPathComponent.hasPrefix(name)
                }
                .forEach {
                    try FileManager.default.removeItem(at: $0)
                }
        } catch {
            print("Failed to clear old DB: \(error)")
        }
    }

Where the passed URL is the old store URL.

Unit Testing - Mocking In Swift

Mocking is a useful tool when writing unit tests. Due to limitations in the current swift version, there aren’t any real mocking frameworks like the ones you see for Java and Obj-C. That said, there are work arounds. Here’s a quick one when you need a one-off:

Method to test:

func crossDissolve(toIdentifier identifier: StoryboardIdentifier) {
    let nextViewController = viewController(forIdentifier: identifier)
    nextViewController.modalPresentationStyle = .fullScreen
    nextViewController.modalTransitionStyle = .crossDissolve
    show(nextViewController, sender: self)
}

This just performs a simple cross-dissolve between two view controllers (the one it’s on to the new one).There are four things to validate:

  1. The UIViewController passed to show(_:sender:) is the one expect.
  2. The sender is correct
  3. That the presentation style is fullScreen
  4. The transition style is crossDissolve

Since it doesn’t return any values I’m going to have to capture them instead. The method under test is crossDissolve(…) so I don’t want to change that behaviour. Everything else is fair game though. In this case, if I intercept the call to show(…) I can capture the parameters passed and validate them.

Since this is a one-off I can nest a class inside my test and capture the values appropriately. Then I can fill in the test.

func testCrossDissolve() {
    class MockSut: UIViewController {
        var showViewController: UIViewController?
        var showSender: Any?
        override func show(_ vc: UIViewController, sender: Any?) {
            showViewController = vc
            showSender = sender
        }
    }
    let mockSut = MockSut()
    mockSut.crossDissolve(toIdentifier: .gameViewController)
    XCTAssertNotNil(mockSut.showViewController as? GameViewController)
    XCTAssertEqual(mockSut.showSender as? UIViewController, mockSut)
    XCTAssertEqual(mockSut.showViewController?.modalPresentationStyle, .fullScreen)
    XCTAssertEqual(mockSut.showViewController?.modalTransitionStyle, .crossDissolve)
}

So, we’re creating a subclass of UIViewController and overriding a method that is called by the method we are interested in testing. Then we can use assertions to complete our test.

Of course, this could get messy if we had a bunch of test cases which needed to handle overrides. In that case I’d move the MockSut class out of the function and into the parent class. If I needed it outside of this specific set of tests, I’d move it into its own class so it could be used in multiple places.

Swift Generics

After installing SwiftLint I was going through resolving the issues. Fortunately, I hadn’t too many problems, mostly because it’s still a small project.

Some longish lines did catch my attention though.

enum StoryboardIdentifier: String {
    case splashViewController
    case mainMenuViewController
    case levelSelectViewController
    case optionsViewController
    case gameViewController
}

fileprivate extension UIStoryboard {
    func instantiateAppViewController(withIdentifier identifier: StoryboardIdentifier) -> UIViewController {
        return instantiateViewController(withIdentifier: identifier.rawValue)
    }
}

fileprivate class NavigationAssistant {
    private static let mainStoryboard = UIStoryboard(name: "Main", bundle: nil)

    private static var splashViewController: SplashViewController {
        return (mainStoryboard.instantiateAppViewController(withIdentifier: .splashViewController) as? SplashViewController)!
    }

    private static var mainMenuViewController: MainMenuViewController {
        return (mainStoryboard.instantiateAppViewController(withIdentifier: .mainMenuViewController) as? MainMenuViewController)!
    }

    private static var levelSelectViewController: LevelSelectViewController {
        return (mainStoryboard.instantiateAppViewController(withIdentifier: .levelSelectViewController) as? LevelSelectViewController)!
    }

    private static var optionsViewController: OptionsViewController {
        return (mainStoryboard.instantiateAppViewController(withIdentifier: .optionsViewController) as? OptionsViewController)!
    }

    private static var gameViewController: GameViewController {
        return (mainStoryboard.instantiateAppViewController(withIdentifier: .gameViewController) as? GameViewController)!
    }

As often seems to happen, on revisiting I can see a way to improve it. First off, it's a little bit verbose in the naming. Changing instantiateAppViewController to just instantiate shortens everything up to get it well under the limit. AppViewController is superfluous, named only to stop a naming collision between the extension and the actual class, and ViewController for the thing it is returning. instantiate could possibly be improved upon but it's clear enough in context for the moment.

That’s minor stuff though. What really caught my eye is that I’m repeating the same code over and over. That cast is kind of messy since I’m kind of cheating SwiftLint there. Without that I had return mainStoryboard.instantiateAppViewController(withIdentifier: .splashViewController) as! SplashViewController which is marginally shorter but it’s not really the problem. What I don’t like is that it’s the same call each time with the only change being the Type I’m casting to. If, instead of casting back as a UIViewController, I was to cast back as the type I was expecting then that would save a bunch of repeated code.

I’ve used generics a bunch of times but I keep forgetting about them - at least when I’m first writing out the code. That’s not necessarily a bad thing since the current way works and I’ve come back to it eventually to clean things up. That’s partly my reasoning for writing this post though, to remember to use these things (appropriately).

So, modify the call which returns the UIViewController to return a generic. Easy:

fileprivate extension UIStoryboard {
    func instantiate<T>(withIdentifier identifier: StoryboardIdentifier) -> T {
        return (instantiateViewController(withIdentifier: identifier.rawValue) as? T)!
    }
}

Fairly straight forward, still have that ugly ‘cast to optional, force unwrap’ to appease SwiftLint. Wait a second, SwiftLint also has a rule about force unwrapping! Optional, but maybe there’s a better way.

guard let viewController = instantiateViewController(withIdentifier: identifier.rawValue) as? T else {
    fatalError("Could not instantiate viewController")
 }
return viewController

There we go. Now it’s explicit what the behaviour is meant to be. It’s a little more code but no-one scanning the code should be confused by the intent.

So the whole thing looks like this now. Much better. The repeated logic is now in a single place. I'm happier with how it looks and, whilst there might be more lines, it feels more compact. I think there are some other improvements that can be made but that goes outside the scope of this post.

enum StoryboardIdentifier: String {
    case splashViewController
    case mainMenuViewController
    case levelSelectViewController
    case optionsViewController
    case gameViewController
}

fileprivate extension UIStoryboard {
    func instantiate<T>(withIdentifier identifier: StoryboardIdentifier) -> T {
        guard let viewController = instantiateViewController(withIdentifier: identifier.rawValue) as? T else {
            fatalError("Could not instantiate viewController")
        }
        return viewController
    }
}

fileprivate class NavigationAssistant {
    private static let mainStoryboard = UIStoryboard(name: "Main", bundle: nil)

    private static var splashViewController: SplashViewController {
        return mainStoryboard.instantiate(withIdentifier: .splashViewController)
    }

    private static var mainMenuViewController: MainMenuViewController {
        return mainStoryboard.instantiate(withIdentifier: .mainMenuViewController)
    }

    private static var levelSelectViewController: LevelSelectViewController {
        return mainStoryboard.instantiate(withIdentifier: .levelSelectViewController)
    }

    private static var optionsViewController: OptionsViewController {
        return mainStoryboard.instantiate(withIdentifier: .optionsViewController)
    }

    private static var gameViewController: GameViewController {
        return mainStoryboard.instantiatZ(withIdentifier: .gameViewController)
    }

Swift: Image Picker

A quick overview of getting an image from the camera, or the photo library.

First, set up your view in the interface builder. For this example, I'm keeping it really simple with a UIImageView and 3 buttons.

Update the UIViewController for your view to import MobileCoreServices (contains the constants required for defining what we want from the picker). Also, add support for the protocols we will need for our view controller to serve as a delegate on the picker. If you have created a new project, this will be ViewController.swift.

import UIKit
import MobileCoreServices

class ViewController: UIViewController {
 
}

extension ViewController: UIImagePickerControllerDelegate {

}

extension ViewController: UINavigationControllerDelegate {
    
}

Note that I've taken advantage of Swift's protocol extensions to keep my delegate handling code separate from the rest of my application code. This helps keeps things logically grouped and makes it easier to keep it tidy. I'm not interlacing different contexts which will make it easier to read if I come back to it months later.

Add the user interface code. We're going to get a reference to the UIImageView so we can update it. We'll also hook up actions to the buttons so we can trigger the desired behaviour.

class CameraViewController: UIViewController {
    @IBOutlet weak var imageView: UIImageView!
    
    @IBAction func displayCamera(sender: UIButton) {
        displayImagePicker(.Camera)
    }
    
    @IBAction func savedPhotos(sender: UIButton) {
        displayImagePicker(.SavedPhotosAlbum)
    }

    @IBAction func photosLibrary(sender: UIButton) {
        displayImagePicker(.PhotoLibrary)
    }
    
    func displayImagePicker(sourceType: UIImagePickerControllerSourceType) {
        guard UIImagePickerController.isSourceTypeAvailable(sourceType) else {
            return
        }
        
        let imagePicker = UIImagePickerController()
        imagePicker.delegate = self
        imagePicker.sourceType = sourceType
        imagePicker.allowsEditing = false
        imagePicker.mediaTypes = [kUTTypeImage as String]
        presentViewController(imagePicker, animated: true, completion: nil)
    }
    
    func handleImage(image: UIImage) {
        imageView.image = image
    }
}

A quick description of what's here:
@IBOutlet allows us to connect a component from Interface Builder - just display the source code side-by-side with the Interface Builder view and Ctrl+Drag to connect them. If you drag to an empty space in your code, Interface Builder will prompt you to create an @IBOutlet, or @IBAction.
@IBAction allows us to connect an action on a component in Interface Builder. In this case, Touch Up Inside to define a touch event ending (lift up) that occurred inside the relevant component. As with @IBOutlet, Ctrl+Drag to connect the Interface Builder view to the source code.

The UIImageView, imageView, is defined as a weak reference as the reference will be held for us by the view so we don't need a strong reference in our UIViewController under most circumstances. Doing so can, in fact, lead to memory problems. We don't need specific references for the buttons since we don't need to access, or change, their state.

The @IBAction prefixed functions will trigger when the relevant button is pressed. I've included the button as a parameter, though this isn't necessary for this application, as it can be useful in other cases and is included by default if you let Xcode create the method for you. These methods just call a helper with an appropriate parameter for the source we want to get an image from.

displayImagePicker(sourceType) is a method that creates, and displays, the image picker. This just lets us reuse code that we'd otherwise have to include in all 3 of our IBAction methods since the only change, in this example, is the sourceType. Other than the image picker, the only notable addition is the use of a guard-statement to check if the source type is available. For this I'm just returning if it's not, but a more complete application might display an error message here.

handleImage(image) takes a UIImage as a parameter and updates the imageView to display it. This is nice for a test but of minimal use otherwise.

This code will run but will not do much because we don't currently handle the image retrieval. Nothing is calling the handleImage(image) method yet. Update the UIImagePickerControllerDelegate protocol extension like so:

extension ViewController: UIImagePickerControllerDelegate {
    func imagePickerController(picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String : AnyObject]) {
        dismissViewControllerAnimated(true, completion: nil)
        let mediaType = info[UIImagePickerControllerMediaType] as! String
        if mediaType == kUTTypeImage as String {
            let image = info[UIImagePickerControllerOriginalImage] as! UIImage
            handleImage(image)
        }
    }
}

All we're doing here is handling the UIImagePickerController being dismissed and retrieving the image, if the media type is an image. It should be since we've requested that only image types be allowed but I've included the check in case you want to extend this to handle video in the future.

Note that, whilst we do need to declare that we support the UINavigationControllerDelegate protocol to assign our view controller as the delegate of the image picker, we don't need to handle any of the callbacks so we can leave this blank for now.

Run the app. It's better on a real device since the simulator doesn't support the camera, but the photo library should be accessible on both (privacy restrictions permitting). 

Swift: Initialising a 2D Array

I have a struct called Tile, which has (for now) a position defined as a tuple:

struct Tile {
    let pos: (Int, Int)
}

And a class called Board, which has a 2D array of Tile objects:

class Board {
    let tiles: [[Tile]]
    
    init() {
        var tilesArray = [[Tile]]()
        for row in 0..<Board.rows {
            var rowTiles = [Tile]()
            for column in 0..<Board.columns {
                let tile = Tile(pos:(column, row))
                rowTiles.append(tile)
            }
            tilesArray.append(rowTiles)
        }
        
        tiles = tilesArray      
    }
}

This works, though it feels a little messy... I'll have to come back and look at this again.

Xcode 7 and Swift 2: Unit Testing (again)

Some follow up from creating a new project and adding tests.

This turned out to be important...

This turned out to be important...

I hadn't really noticed in the last one but I hadn't added the new classes to the test target, as I would under Obj-C. In Swift 2 there's a new @testable keyword. I found it blogged by Natasha the Robot when I started looking to find out why I wasn't seeing any code coverage showing up for my classes.

Then I started wondering why I was getting Undefined Symbol errors. I could resolve them by including the classes, but then I wouldn't get coverage and everything I saw on @testable assured me I didn't need to include them. Finally, I remembered I'd been getting a bit click happy earlier. I'd disabled Allow testing Host Application APIs.

One checkbox later and I'm a happy camper...

Okay, not a lot done tonight but I feel like a few pieces fell into place.