The lifecycle of a cell has been well-established since UICollectionView was introduced in iOS6:

prepareForReuse is called first, and is where the cell’s contents should be set back to their default state

cellForItemAtIndexPath: is where the majority of the work involved in setting up the cell takes place

willDisplayCell: is a last-minute opportunity to update the cell before it’s displayed

didEndDisplayingCell: is called as the cell disappears from view

The four lifecycle functions remain in iOS10, but there have been some subtle changes to when they’re called:

• willDisplayCell: is now called later than previously - whereas in iOS9 and earlier the function was called immediately the cell was taken off the recycle queue, in 10 it’s not called until just before the cell is displayed
• previously, didEndDisplayingCell was called as soon as the cell scrolled out of the visible bounds of the collection view. Now there’s a delay, which means that the cell hangs around a bit longer in case it’s scrolled back in again. This removes the need to recreate the cell from scratch, and should improve performance when changing scroll direction.

The other significant change is that cells are now dequeued individually rather than row-by-row. This helps to spread out the load of setting each cell up, rather than causing spikes in load; and also aids with making sure that cells are always ready to be displayed.

The good news is that all these changes take place under the hood, so you don’t need to make changes to pre-existing code in order to take advantage of them.

Although UICollectionView is a highly-performant control, Apple haven’t let it stand still. One of the most interesting new features is designed to improve the performance of collection views with expensive data sources.

Background

The aim for any iOS application is to run the UI at the full 60 frames per second, to deliver a completely smooth scrolling performance. Any frame rate significantly lower than this will manifest itself by dropped frames and stuttery performance.

60fps equates to 16.67ms per frame, which isn’t long if you’re dealing with drawing collection view cells using data from slow sources. The trick to high performance collecion views is to get the cellForItemAtIndexPath to return a cell as fast as possible, but this can be difficult. Techniques like asynchronous fetching of images can help, but these aren’t a miracle cure.

Note: This technique is also available to use with UITableView - just replace references to UICollectionView with UITableView, and the implementation patterns are identical.

Prefetching

In iOS10, Apple have introduced a new UICollectionViewDataSource protocol extension called UICollectionViewDataSourcePrefetching.

This introduces a new property on UICollectionView called prefetchDataSource. This is a class that implements two UICollectionViewDataSourcePrefetching protocol functions:

• collectionView(_ collectionView: UICollectionView, prefetchItemsAt indexPaths: [IndexPath])

• collectionView(_ collectionView: UICollectionView, cancelPrefetchingForItemsAt indexPaths: [IndexPath])

The prefetchItemsAt indexPaths: function is called by the collection view when it looks like the scrolling rate of the collection view will outstrip the ability of cellForItemAtIndexPath to deliver cells in a timely manner.

The collection view passes in an Array of NSIndexPaths for cells that are likely to be needed in the future. This gives you an opportunity to update the data source that underlies the collection view. For example, if your data source was an Array of images, you could call out to the network to download the images and insert them into the data source so that they are ready to be used by the cellForRowAtIndexPath function.

The second method is normally called when the scrolling direction changes. The reasoning for this is that you’re likely to be prefetching data well in advance of the cells being displayed - if those cells won’t now get displayed because the collection view is scrolling away from them, you may as well cancel whatever operation it is that you’re carrying out to update the data source. Again, the index paths of the cells in question are passed in as an Array of NSIndexPaths.

Implementing pre-fetching

To take advantage of the new prefetch feature, you’ll need to do four things:

• Conform a class to the UICollectionViewDataSourcePrefetching protocol
• Implement the collectionView(_ collectionView: UICollectionView, prefetchItemsAt indexPaths: [IndexPath]) function to update the collection view’s dataSource
• Optionally, implement the collectionView(_ collectionView: UICollectionView, cancelPrefetchingForItemsAt indexPaths: [IndexPath]) function to cancel any in-flight prefetching operations
• Set the conforming class as the collectionView’s prefetchDataSource property.

Conforming to UICollectionViewDataSourcePrefetching

This isn’t difficult: just mark your data source as implementing the protocol:

1
2
3

class MyViewController: UIViewController, UICollectionViewDataSource, UICollectionViewDataSourcePrefetching {
  ...
}

Implementing prefetching

Prefetching is implementing with the collectionView(_ collectionView: UICollectionView, prefetchItemsAt indexPaths: [IndexPath]) function. There the collection view passes in an Array of NSIndexPaths, one for each of the cells that are likely to be displayed.

Your job here is to iterate across this array, and update the collection view’s data source accordingly:

1
2
3
4
5
6
7
8
9
10
11

func collectionView(_ collectionView: UICollectionView, prefetchItemsAt indexPaths: [IndexPath]) {

    for indexPath in indexPaths {
      
      ... expensive operation to retrieve some data...
      
        dataArray[indexPath.row] = retrievedData
      
    }
    
}

There are a couple of important points to note here: the first is that you’re only updating the collection view’s underlying data source - not returning any data directly. This could be as simple as updating an Array of strings (as above), or more complex like updating a CoreData or Realm model.

The second point to bear in mind is that after the prefetch has taken place, there’s no guarantee when, or if, that retrieved will be used. The collection view’s scroll rate could slow down; or the direction reverse entirely.

For this reason, there is a chance that time-critical data could be stale by the time it’s displayed. Whether this is a factor that you need to consider will of course depend on the nature of the data being displayed.

Implenting prefetch cancellation

To an extent, requests for prefetches are a bit of a guess - the collection view is attempting to optimise for an uncertain future state that might not actually come to pass. For example, if the scroll rate slows, or reverses altogether, there’s a chance that the cells for which prefetch has been requested may never actually be displayed.

In this situation, any inflight prefetch would be wasted effort. Rather than make redundant requests, the UICollectionViewDataSourcePrefetch protocol defines a function to cancel outstanding requests: collectionView(_ collectionView: UICollectionView, cancelPrefetchingForItemsAt indexPaths: [IndexPath])

This is called if the collection view decides that prefetching would be over-optimisation - it passes an Array of NSIndexPaths as the function’s parameter, and it’s up to you to iterate over those and cancel any requests where it makes sense to do so.

Hooking up the prefetch delegate to the collection view

With the class conforming to the protocol, and with one or both of the functions implemented, you need to add it as a prefetchDataSource to the collection view.

This is as simple as updating the property (here, we’re assuming that the collection view controller is acting as its own prefetchDataSource):

1

collectionView.prefetchDataSource = self

This has to be done before any calls to any of the UICollectionViewDataSource protocol functions, so it probably makes sense to do so at the same time as setting up the collection view’s other properties, such as cell registration.

Conclusion

UICollectionView is a high-performance control to begin with, with a significant amount of ‘under the hood’ optimisation going on that we don’t see. Prefetching is another tool to eke out even more performance, especially in situations where getting the source data for display in collection view cells is expensive or slow.

However, there’s a saying that “premature optimisation is the root of all evil” in code, so it’s not a magic bullet. And don’t overlook the fact that often the most expensive part of the process is compositing the collection view cell itself. But if you’re looking to squeeze out the last drops of performance to make your collection views as smooth as possible, prefetching may be worth a try.

It’s important, because it often handles some of the most critical and yet unreliable parts of an app - in other words, networking.

It’s hard because it’s, well, asynchronous. One of the two jokes in software engineering goes something like “Some people, when faced with a problem, think ‘I know, I’ll use threading’. Now problems have two they.”

The standard rhythm of a unit test goes like this:

• set up the preconditions for the test, to get the system into a known state
• make some assertions about what result you’re looking for
• fire the functions under test
• verify that the assertions were met

The problem with asynchronous code is that the third and final steps don’t always come in that order, particularly if you’re attemping to test a long-running operation. It can still be churning away as your verification takes place - and your tests are unlikely to pass in that kind of scenario.

Fortunately, there are ways around this. It’s not especially pretty, but it does work.

waitForExpectations

The key to testing async code in Swift is using the waitForExpectationWithTimeout feature of the XCTest framework. An expectation in this context is just a flag that tells the test code “I’m done, you can check your assertions now”.

The expectation will hang around and wait for the fulfillment message, which gives the async code a chance to complete before the assertions are checked.

There are three stages involved in setting this up:

• Creating an expectation
• Calling the async function, and then flagging that the expection has been fulfilled when your code has comepleted
• Wrapping the assertions inside a waitForExpectationWithTimeout block so that they will wait for the fulfillment to occor.

Creating the expectation

This is quite simple. At the top of your test function, create an expectation with

1

let asyncExpectation = expectationWithDescription("longRunningFunction")

This needs to be done before you call the async code.

Fulfilling the expectation

With the expectation created, you need to signal that it’s fulfilled after your asynchronous code completes. Here’s an example of a function that fires off a network request, and takes a completion handler as a parameter to process the data that’s returned:

1

func networkManager.getDataFromApiForUser(user: User, completionHandler: (userData: NSData?, error: NSError?) -> () )

In normal situations, you’d use this function with something like this:

1
2
3
4
5
6
7

networkManager.getDataFromApiForUser(testUser, completionHandler: { (userData, error) -> () in
  
  ... handle the error if one occurs
  ...
  ... otherwise process the userData object
  
)}

Testing the function in a unit test is very similar:

1
2
3
4
5
6
7
8
9

networkManager.getDataFromApiForUser(testUser, completionHandler: { (userData, error) -> () in

  ... handle the error if one occurs
  ...
  ... otherwise process the userData object

  expectation.fulfill()
  
)}

The key difference is that last line - expectation.fulfill(). What we’re doing here is to signal to the asyncExpectation that everything is completed, and it’s now safe to check the assertions.

Checking the assertions

Assertions in this context are just the usual XCTest assertions that you’ll already be familar with. What’s different is that we wrap them in a waitForExpectationsWithTimeout block:

1
2
3
4
5
6

self.waitForExpectationsWithTimeout(5) { error in
  
  XCTestAssertNil(error, "Something went horribly wrong")
  XCTestAssertEqual(testUser.orders.count, 10)
  
}

This function will do two things - firstly, it will wait for a maximum of five seconds before giving up and failing. This prevents you from locking up the tests in an infinite loop if something goes wrong with the code under test. How long to wait is dependent on the kind of processing that’s taking place - but ideally shouldn’t be so long that it locks up the test suite unncessarily.

Secondly, it will fire the XCTest expectations as soon as the expectation.fulfill() function is called. By triggering that at the end of the chunk of async code, you’re preventing the assertions racing away and being checked before the function under test has had a chance to complete.

Putting it all together

Putting that all together in a example test looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

func testUserOrdersAreRetrievedFromApiAndProcessed() {

  let asyncExpectation = expectationWithDescription("longRunningFunction")
  
  let testUser = User.initWithName("Foo" andAccountNumber: 1234)
  
  networkManager.getDataFromApiForUser(testUser, completionHandler: { (userData, error) -> () in
      
      ... handle the error if one occurs
      ...
      ... otherwise process the userData object
      
      expectation.fulfill()
      
  )}
  
  self.waitForExpectationsWithTimeout(5) { error in
      
      XCTestAssertNil(error, "Something went horribly wrong")
      XCTestAssertEqual(testUser.orders.count, 10)
      
  }

}

It’s not the cleanest looking test code you’ll ever write, especially if you’re not a fan of the Junit-style syntax of the XCTest framework - but it works. And given how important asynchronous code like network requests or long-running processing tends to be to an app, it’s worth sacrificing a little style for the reassurance that high test coverage will provide.

By way of background, mocking is the art of creating “stunt doubles” for your classes that are involved in tests. You’d do this for a couple of reasons - either to manipulate your stunt doubles into a known state for testing purpose; or because it’s expensive or difficult to use the real thing.

An example of this might be testing what happens if a network service doesn’t return the result that you were expecting. If you’re testing the use of a live service, it might be tricky to create a deliberate failure just for testing purposes. Far easier to create a stunt double and use this to return the value that your tests require.

The other situation where you may want a stand-in object is if you want to verify that a method has been called. Say for example you’ve got some kind of callback, and you want to test whether this gets fired. By setting an expectation on the callback method, you can verify that it actually was called - which is especially useful if you’re testing asynchronous operations.

It was perfectly possible to do all of this in Objective-C, but it required the use of external libraries such as OCMock or Kiwi. Swift, on the other hand, is much easier. The structure of the language makes it very straight-forward to implement basic mocking and stubbing operations, without the need for external pods or libraries.

Here’s an example. Say we have a class called SooperClass, and this has a function called someExpensiveFunctionThatReturnsAStringFromTheWeb. We don’t want to really fire this as part of our tests, because (for the sake of this example) we get charged every time we make an API call. Instead, we need to mock it.

The first step is to create a mock of SooperClass inside our test class. At the top of the test class, create a FakeSooperClass which inherits from SooperClass like this:

1
2
3
4
5
6
7
8
9

class MockrTests: XCTestCase {

    class FakeSooperClass: SooperClass {

    }

    ... rest of the test class here ...

}

Next, override the method that you want to test:

1
2
3
4
5
6
7

class FakeSooperClass: SooperClass {

    override func someExpensiveFunctionThatReturnsAStringFromTheWeb() -> String {
  
    }

}

And use this overridden method to return whatever data your test needs:

1
2
3

override func someExpensiveFunctionThatReturnsAStringFromTheWeb() -> String {
    return "Finally! Some content!"
}

Now you can use this in your test:

1
2
3
4
5
6
7
8

func testThatTheExpensiveFunctionReturnsSomethingUseful() {

    let fakeSooperClass = FakeSooperClass()
    let stringFromTheWeb = fakeSooperClass.someExpensiveFunctionThatReturnsAStringFromTheWeb()

  ... use the value in the rest of the test ...
  
}

Here, we’ve created a mock instance of SooperClass, and used this to return data in the format that we need for the rest of the test. But in doing so, we haven’t had to call out to the public API that SooperClass would normally talk to.

We can take the fake class one step further, and test that the method actually gets called. We’ll set an expectation that the function will be called once during the code that we’re testing - if it isn’t, something has gone wrong somewhere.

To do this, we need to extend our fake class slightly, to include a flag:

1
2
3
4
5
6
7
8

class FakeSooperClass: SooperClass {

    var didCallExpensiveFunctionFlag = false

    override func someExpensiveFunctionThatReturnsAStringFromTheWeb() -> String {
        return "Finally! Some content!"
    }
}

This flag is initially false (because the function hasn’t been called yet). When the function is called, we’ll flip the flag inside the fake class. By getting the test to check the state of the flag, it will be possible to see if the function was called as we expected.

This needs a tweak to our fake someExpensiveMethodThatReturnsAStringFromTheWeb() function:

1
2
3
4
5
6
7
8
9

class FakeSooperClass: SooperClass {

    var didCallExpensiveFunctionFlat = false

    override func someExpensiveMethodThatReturnsAStringFromTheWeb() -> String {
        didCallExpensiveFunctionFlag = true
        return "Finally! Some content!"
    }
}

Now we can test all this in our test case:

1
2
3
4
5
6
7
8
9
10
11
12

func testThatTheExpensiveFunctionGetsCalled() {

    let fakeSooperClass = FakeSooperClass()

    // Code that eventually ends up with someExpensiveFunctionThatReturnsAStringFromTheWeb() being called,
    // like this:
    // let result = fakeSooperClass.someExpensiveFunctionThatReturnsAStringFromTheWeb()

    // Set an assertion to check that the flag
    XCTAssert(fakeSooperClass.didCallExpensiveFunction == true, "expected function to be called, but wasn't")

}

If the function WAS called, the flag will be flipped, and the assertion will pass. If for some reason the function didn’t get called, then the flag will be false and will cause the assertion to fail.

You could also extend this to keep track of the number of times the function gets called, by incrementing a counter. It uses exactly the same approach of overriding a function in a fake class, and checking the results with an assertion.

So, not difficult to do. Not only that, but rolling your own mocks and expectations in Swift also has the benefit that you’re not dependent on external 3rd party libraries with all the attendent complexities that these can sometimes bring along.

If you’re using NSUserDefaults, you should be testing NSUserDefaults. Here’s how.

One of the most common testing scenarios is that you want to store some value in the defaults store so that it can be read out later. This is the process for testing that your code actually does so. Assume that we’ve got a class called myClass which has an IBAction method called didTapUpdateSettingsButton which will write out a specific value.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

it(@"should write the configured environment to the user defaults"), ^{

  NSString *apiUrl = @"http://foo.com/bar";
  NSString *theKey = @"defaultApiUrl";

  id mockStandardDefaults = [NSUserDefaults nullMock];
  
  [NSUserDefaults stub:@selector(standardUserDefaults) andReturn:mockStandardDefaults];
  
  [[mockStandardDefaults should] receive:@selector(setObject:forKey:) withArguments:theObject, theKey];
  
  [[mockStandardDefaults should] receive:@selector(sychronize)];
  
  [myClass didTapUpdateSettingsButton:nil];

}

Walking through this, we first create variables for the key and object that we are expecting the didTapUpdateSettings method to attempt to write to the defaults store.

Next, we create a mock object which will stand in for the instance of the NSUserDefaults class that would normally be returned by the [NSUserDefaults standardUserDefaults] method. We’re going to use this mock to catch and test the messages that our code under test sends. It’s created as a null mock here so that it won’t complain if it gets messages other than the ones that we send it.

Then we need to stub the standardUserDefaults method of the real, live NSUserDefaults class, and return our mock instance instead of the real thing.

Once we’ve stubbed out NSUserDefaults, we can now set some expectations about what our mock standardUserDefaults will receive. There are two things we’re interested in - firstly, that it receives the setObject:forKey message with the values that we expect. If that message isn’t received, or the values differ from what we expect, then there’s something wrong with the code that we’re writing.

Secondly, we’re also setting an expectation that the mock receives the synchronize message. This saves the values that we’ve updated - not sending a synchronize message to NSUserDefaults is a common mistake, and hard to diagnost - with a specific test, we’ll catch any situations where we forget that final step.

Finally, we invoke the code under test by “tapping” the button (or in this case, calling the IBAction method that the button is wired up to).

If you’re taking a test-first approach to writing the code, obviously this will initially fail. But by fixing each failing assertion in turn, you’ll end up with a method that both writes and saves the correct values.

If you do need to access those files, the chances are that you can’t find them anymore.

Instead of looking in

~/Library/Application Support/iPhone Simulator/

you’ll find them instead in

~/Library/Developer/CoreSimulator/Devices/*

Which at least is easier to embed into scripts thanks to the lack of spaces in the path.

If you were building a universal app that supported both iPhone and iPad, there was a tendency to end up with a lot of if deviceType == kIpad-style code.

AutoLayout was the first part of fixing that problem, and the job’s been completed with iOS 8 and size classes. This is probably the least-sexy feature introduced in 8, but it’s definitely one of the more important.

Some quick background on size classes

There are currently two size classes - horizontal and vertical, and each one comes in two sizes - regular and compact. The current orientation of the device can be described as a combination of the sizes:

• Horizontal regular, vertical regular: iPad in either orientation
• Horizontal compact, vertical regular: iPhone portrait
• Horizontal regular, vertical compact: no current device
• Horizontal compact, vertical compact: iPhone landscape

Storyboards and nib files now support these size classes - so you can think of them as having up to four different layouts contained within the same file. At the bottom of the Interface Builder window, there’s now a control that allows you to switch between each combination:

Every control or AutoLayout constraint can exist in one, several or all of the size classes. This means that you can build interfaces that change depending on device type and/or orientation without any code. Controls can appear or disappear, change size, or change arrangements - all based on the layout that you create in Interface Builder.

Checking size classes

To demonstrate how the size classes change as the device rotates, you can use the a new callback method that’s called as the interface changes:

-(void)willTransitionToTraitCollection:(UITraitCollection *)newCollection
             withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator {
    NSLog(@"Trait collection = %@", newCollection);
}

This will display the trait collection that each orientation triggers:

2014-08-16 19:04:49.785 Adaptr[6522:213857] Trait collection = <UITraitCollection: 0x7fa983c13a10; _UITraitNameUserInterfaceIdiom = Phone, _UITraitNameDisplayScale = 2.000000, _UITraitNameHorizontalSizeClass = Compact, _UITraitNameVerticalSizeClass = Regular, _UITraitNameTouchLevel = 0, _UITraitNameInteractionModel = 1>

How to build adaptive layouts

To demonstrate this, this is a simple universal app that changes layout depending on device and orientation. You can download the full project from here, or follow along. I’m assuming that you’re using Xcode 6 Beta 5 at a minimum.

To start with, create a new universal Single View application. This will create an App Delegate, a view controller and a storyboard. I’m going to ignore the code entirely, and focus on the Storyboard alone (if you’re working with xib files, the process is exactly the same).

Before getting going, it’s worth doing a bit of tweaking to Xcode so that you can see what’s going on. If the Assistant Editor isn’t visible, open it on the right (View -> Assistant Editor -> Assistant Editors on Right) and then switch the Assistant Editor to Preview mode:

This will show a preview of the storyboard in the right hand pane - by default, it’s set up for a 4" iPhone. You can add other devices by clicking on the + icon at the bottom of the preview and selecting the device(s) that you need. They appear side-by-side in the preview pane, so if you haven’t invested in a Thunderbolt Display so far, now would be a good time to do so.

The basic layout

By default, Interface Builder creates a Storyboard with a square ‘Any, Any’ layout - in other words, anything you do with this layout will be common across all devices.

We’re going to start by centering a red block with a constant border. Drag a UIView object into the main view, set the size to 200 x 200, center it in the superview and set the background colour to red. In the Storyboard, it will look like this:

However, if you look at the preview (or run the app in the Simulator) for each device, you’ll see that things look very different:

To fix this, we need to add some AutoLayout constraints. Add constraints to pin the leading, trailing, top and bottom spaces to 50 points:

Run the app again, and this time the red block will be placed correctly regardless of which device you use (you can also change the size of the device in the Resizable Simulator, and the layout will still work.)

Altering constraints in different layouts

So far, we haven’t done anything that previous versions of iOS and Xcode could do. To demonstrate how the layout can change between devices, we’ll alter things so that in landscape, the red block fills the entire screen.

To do this we need to change the layout classes that the constraints are added to. If you select a constraint in the object tree then view the Attributes inspector, you’ll see an Installed checkbox, with a small + to the left:

By default this constraint is installed in all layout classes - what we need to do is to add the appropriate layout classes so that the constraints can be added to the appropriate one. Click the + button, then add a compact width, regular height layout:

When you add the new layout, the constraint will be automatically added to both layouts - deselect the Installed checkbox to remove it from the default layout:

Repeat the same process for the other three constraints. As you remove the constraints from the default layout, you’ll see them disappear from the main Interface Builder pane, and become greyed out in the view tree:

To see the size class where the constraints are active, change it using the selectors at the bottom of the Interface Builder pane:

Once you’ve switched layout, you’ll see them reappear:

If you run the app again in the iPhone Simulator everything will look fine in portrait orientation. Rotate into landscape, though, and things go horribly wrong - the red block disappears, albeit with a nice animation. This is because there are no layout contraints present in this layout class combination, so AutoLayout does its best to figure out what should happen and gets it wrong. To fix this, we need to add constraints for the landscape scenario.

In Interface Builder, switch the layout class to Any width, Compact height:

Now add four new AutoLayout contraints - leading, trailing, top and bottom spaces - and set the constant value for each one to 0. Note that each constraint is added to the Any, Compact layout and not the default:

Run the app again, and as you rotate the Simulator into landscape the red block will be animated to fill the screen:

Adding and removing views in different layouts

As well as adding. removing and changing contraints between different layouts, you can do the same thing with views and controls. This could allow you to build completely different interfaces in portrait and landscape orientations; or as an alternative to separate interfaces for different classes of device.

To illustrate this, we’ll update the current interface to add a white block that appears in landscape:

Start by switching to Any width, Any height and adding a UIView to the interface. Make sure it’s a sibling view of the red block, and set its background colour to white.

Next, change to Any width, Compact height and add constraints to set a 50 point inset on all four edges.

If you run the Simulator now, you’ll see that the white block is the correct size and position in landscape, but the transition between landscape and portrait could be better:

This is because the view animates between the constraints in each size class combination, and at the moment those in portrait are undefined.

To fix this, switch to Compact width, Regular height and add constraints to centre the white block and fix its height and width to zero. You’ll also need to reduce the height and width constraint priorities to 750 to prevent a clash between size and inset constraints.

This fixes the start point of the portrait-to-landscape animation, and the end point of the landscape-to-portrait. Because the start and end points are defined, the transition of the white block is smoothly animated:

Where to go from here

By using size classes and constraints, it’s going to be possible to build up responsive interfaces in a way that wasn’t feasible before iOS8. As well as simplifying the management of device rotation, you can also create universal interfaces - something that should make targeting multiple device types a lot easier.

The other interesting extrapolation here is that we’ve now got all the tools we need to build interfaces for any size of device - whether it’s an iPhone 6 with a large screen; or apps for Apple TV; or even CarPlay. Maybe the long-awaited Apple TV SDK might be on the way…?

Here’s a downloadable PDF version.

This code has been updated for Swift 1.0 and Xcode 6.0.1

The project consists consists of a single storyboard with a table view control, and a view controller written in Swift:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
    
    let cellIdentifier = "cellIdentifier"
    var tableData = [String]()
    
    @IBOutlet var tableView: UITableView?
    
    override func viewDidLoad() {
        super.viewDidLoad()

        // Register the UITableViewCell class with the tableView
        
        
        self.tableView?.registerClass(UITableViewCell.self, forCellReuseIdentifier: self.cellIdentifier)
        
        // Setup table data
        for index in 0...100 {
            self.tableData.append("Item \(index)")
        }
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }

    // UITableViewDataSource methods
    
    func numberOfSectionsInTableView(tableView: UITableView) -> Int {
        return 1
    }
    
    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return tableData.count
    }
    
    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        var cell = tableView.dequeueReusableCellWithIdentifier(self.cellIdentifier) as UITableViewCell
        
        cell.textLabel?.text = self.tableData[indexPath.row]
        
        return cell
    }
    
    // UITableViewDelegate methods
    
    func tableView(tableView: UITableView!, didSelectRowAtIndexPath indexPath: NSIndexPath!) {

        let alert = UIAlertController(title: "Item selected", message: "You selected item \(indexPath.row)", preferredStyle: UIAlertControllerStyle.Alert)
    
        alert.addAction(UIAlertAction(title: "OK",
                                      style: UIAlertActionStyle.Default,
                                    handler: {
                                        (alert: UIAlertAction!) in println("An alert of type \(alert.style.hashValue) was tapped!")
                                    }))
        
        self.presentViewController(alert, animated: true, completion: nil)
        
    }

}

Housekeeping

There are three upfront pieces of housekeeping that we need to do:

• create a String constant as a cell identifier (Swift is clever enough to infer the fact that it’s a String when we define the constant):

  let cellIdentifier = "cellIdentifier"

• define an Array variable to contain the table’s data. This is an Array of Strings, and we initialize this as empty as we declare it:

  var tableData = [String]()

• define a UITableView outlet to connect the table in the Storyboard:

  @IBOutlet var tableView: UITableView?

  The outlet’s defined as an optional, because it won’t exist until the view has been instantiated (that’s a similar approach to declaring outlets as weak with Objective-C).

You’ll also need to setup the Storyboard with a UITableView object that connects with the view controller as dataSource and delegate, and connects the view controller’s tableView outlet with the table view.

Registering a UITableViewCell class with the table

So that the table can use UITableViewCell objects, we’ll need to register the UITableViewCell class for use with the cellIdentifier that we created in the stage above. The most logical place to do this is in the viewDidLoad method:

self.tableView?.registerClass(UITableViewCell.self, forCellReuseIdentifier: self.cellIdentifier)

Swift’s way of returning the class name for use with the registerClass method is subtly different from Objective-C - rather than using something along the lines of [UICollectionViewCell class], in Swift you use UICollectionViewCell.self.

Creating some table data

Next, we need to create some data for the table to work with. This is going to be held in the tableData array:

for index in 0...100 {
    self.tableData.append("Item \(index)")
}

This uses Swift’s for-in loop to create 100 Strings and append them to the tableData array. The \(...) format is a huge improvement on the legacy NSString stringWithFormat: style…

Telling the table about sections and rows

The UITableView datasource methods haven’t changed in iOS8 - you still need to inform the table how many sections and rows it will have.

(Technically, the table view will assume that it has one section unless you tell it otherwise, but I usually implement the numberOfSectionsInTableview method out of sheer habit):

func numberOfSectionsInTableView(tableView: UITableView) -> Int {
    return 1
}

There’s no practical difference between the Swift and Objective-C versions, other than the syntactic differences - the method has am external parameter name of tableView, and returns an Int.

The same is also true of the tableView:numberOfRowsInSection: method:

func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    return tableData.count
}

Creating and returning cells

Now that the table view knows how many sections and rows it has, the final step in a minimal implementation is to create and return cells on demand:

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! {
    var cell = tableView.dequeueReusableCellWithIdentifier(self.cellIdentifier) as UITableViewCell
    cell.textLabel.text = self.tableData[indexPath.row]
    return cell
}

Once again, this is very straight-forward: we dequeue a cell with the appropriate identifier, configure its contents, and return it to the table view. The as operator is force-downcasting whatever is returned from the tableView into a UITableViewCell.

Cell selection

Although that’s all that’s needed to get the table view up and running, here’s how a simple UITableViewDelegate method is implemented:

func tableView(tableView: UITableView!, didSelectRowAtIndexPath indexPath: NSIndexPath!) {
    let alert = UIAlertController(title: "Item selected", message: "You selected item \(indexPath.row)", preferredStyle: UIAlertControllerStyle.Alert)
    alert.addAction(UIAlertAction(title: "OK", style: UIAlertActionStyle.Cancel, handler: nil))
    self.presentViewController(alert, animated: true, completion: nil)
}

This method is fired when a cell is selected - no change there. Here, we’re creating an instance of UIAlertController which is the iOS8 replacement for the venerable UIAlert control:

let alert = UIAlertController(title: "Item selected", message: "You selected item \(indexPath.row)", preferredStyle: UIAlertControllerStyle.Alert)

A vanilla UIAlertController doesn’t have any user controls, so we need to add a UIAlertAction to it:

alert.addAction(UIAlertAction(title: "OK", style: UIAlertActionStyle.Cancel, handler: nil))

And then finally present the controller:

self.presentViewController(alert, animated: true, completion: nil)

You’ll notice that the last handler parameter of the UIAlertAction takes a block: this means that you can implement whatever actions you want to occur once the button has been tapped in-place, rather than having to link the alert controller to the view controller through a delegate.

That makes for much less code, and also keeps the action together with UIAlertController (helping to make the code more readable).

If you wanted to log something to the console, say, you could implement this:

    alert.addAction(UIAlertAction(title: "OK",
                                  style: UIAlertActionStyle.Default,
                                handler: {
                                    (alert: UIAlertAction!) in println("An alert of type \(alert.style.hashValue) was tapped!")
                                }))

It’s compact, certainly, but this is an example of something that does make me wonder why quite so many people rave about Swift as being more readable than Objective-C - I’m really not sure this is actually so much of an improvement.

Summary

One of the killer features of Swift is the backwards-compatibility of it with the existing legacy of Objective-C and the iOS frameworks. This is a good example of how the basic design patterns of the controls haven’t changed at all - moving to Swift is just a case of getting to grips with the new syntax and language features.

The problem is that unless you’re using a completely custom collection view layout, you can’t move the cell itself. The collection view is in charge of where things are displayed, and it’s a major pain to override this - especially if you’re using a flow layout. Reimplementing UICollectionViewFlowLayout from scratch is a decidedly non-trivial undertaking.

The answer lies in a hack. Create a copy of the contents of the cell as an image, then drag this around the screen underneath your finger. Much easier.

Here’s an example - it assumes that you’ve previously created and attached a UIPanGestureRecognizer to the collection view, and tied this to a method called handlePan: in your view controller. There’s also a UIImageView property on the view controller called movingCell.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

(void)handlePan:(UIPanGestureRecognizer *)panRecognizer {

    CGPoint locationPoint = [panRecognizer locationInView:self.collectionView];

    if (panRecognizer.state == UIGestureRecognizerStateBegan) {

        NSIndexPath indexPathOfMovingCell = [self.collectionView indexPathForItemAtPoint:locationPoint];
        UICollectionViewCell *cell = [self.collectionView cellForItemAtIndexPath:indexPathOfMovingCell];

        UIGraphicsBeginImageContext(cell.bounds.size);
        [cell.layer renderInContext:UIGraphicsGetCurrentContext()];
        UIImage *cellImage = UIGraphicsGetImageFromCurrentImageContext();
        UIGraphicsEndImageContext();

        self.movingCell = [[UIImageView alloc] initWithImage:cellImage];
        [self.movingCell setCenter:locationPoint];
        [self.movingCell setAlpha:0.75f];
        [self.collectionView addSubview:self.movingCell];

    }

    if (panRecognizer.state == UIGestureRecognizerStateChanged) {
        [self.movingCell setCenter:locationPoint];
    }

    if (panRecognizer.state == UIGestureRecognizerStateEnded) {
        [self.movingCell removeFromSuperview];
    }
}

When the pan gesture recognizer fires, it calls the handlePan: method with itself as a parameter.

A UIPanGestureRecognizer has three states that we’re interested in - UIGestureRecognizerStateBegan (which is fired as the first touch starts), UIGestureRecognizerStateChanged(which fires as the touch moves) and UIGestureRecognizerStateEnded (which fires as the finger is lifted).

We hook into the UIGestureRecognizerStateBegan event, and get the location where the pan gesture is occurring:

CGPoint locationPoint = [panRecognizer locationInView:self.collectionView];

Then if the touches have just begun, we grab the cell in which the touch started:

NSIndexPath *indexPathOfMovingCell = [self.collectionView indexPathForItemAtPoint:locationPoint];

UICollectionViewCell *cell = [self.collectionView cellForItemAtIndexPath:indexPathOfMovingCell];

and create a UIImage out of the cell’s layer:

UIGraphicsBeginImageContext(cell.bounds.size);

[cell.layer renderInContext:UIGraphicsGetCurrentContext()];

UIImage *cellImage = UIGraphicsGetImageFromCurrentImageContext();

UIGraphicsEndImageContext();

Finally, we use this UIImage to populate a UIImageView property, and update the center of the UIImageView so that it lies underneath the current location of the touch. I’ve also tweaked the image’s opacity to make it slightly translucent:

self.movingCell = [[UIImageView alloc] initWithImage:cellImage];

[self.movingCell setCenter:locationPoint];

[self.movingCell setAlpha:0.75f];

[self.collectionView addSubview:self.movingCell];

Following the touches is just a case of updating the centre of the UIImageView:

if (panRecognizer.state == UIGestureRecognizerStateChanged) {

    [self.movingCell setCenter:locationPoint];

}

And when the touches end, we remove the UIImageView from the collectionView completely:

if (panRecognizer.state == UIGestureRecognizerStateEnded) {

    [self.movingCell removeFromSuperview];

}

This implementation simply removes the pseudo-cell from the screen when the touch finishes, but there’s no reason why you can’t do something like insert it back into the collection view at the point where it was ‘dropped’. I’ll put the code for this up in another post.

Here’s how I’m doing it - using XCTest and OCMock, although there’s no reason why this approach won’t work with other test/mock frameworks like Kiwi etc.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-(void)testCalculateSpokeRadiusReturnsCorrectValueForTwoItems {

    UICollectionView *collectionView = [[UICollectionView alloc] initWithFrame:CGRectMake(0, 0, 500, 500) collectionViewLayout:self.customLayout];

    id collectionViewMock = OCMPartialMock(collectionView);
    [[[collectionViewMock stub] andReturnValue:@(1)] numberOfItemsInSection:0];
  
    [collectionViewMock setCollectionViewLayout:self.customLayout];

    [self.customLayout setItemSize:CGSizeMake(100, 100)];
    [self.customLayout setSidePadding:10.0f];

    XCTAssertEqual([self.customLayout calculateSpokeRadius], 190.0f, @"should be 190.0f");

}

The process isn’t too gnarly. First, create a real, live UICollectionView instance and give it your custom layout (in this test, I’d previously instantiated the custom layout object in the test setup):

UICollectionView *collectionView = [[UICollectionView alloc] initWithFrame:CGRectMake(0, 0, 500, 500) collectionViewLayout:self.customLayout];

Then create a partial mock:

id collectionViewMock = OCMPartialMock(collectionView);

With this you, you can then stub out the numberOfItemsInSection: method and return the number of items you want to run the calculations for - by mocking out this method, you’ve got no dependencies on your datasources.

The advantage of using a partial mock is that you only need to stub out the methods that you want to control - you can use everything else as you would with the real, live object.

[[[collectionViewMock stub] andReturnValue:@(1)] numberOfItemsInSection:0];

Now link the custom layout and the collection view together:

[collectionViewMock setCollectionViewLayout:self.customLayout];

A few custom layout settings (these will obviously depend on how you’ve implemented your layout):

[self.customLayout setItemSize:CGSizeMake(100, 100)];`
[self.customLayout setSidePadding:10.0f];`

Finally, after all this, you can actually fire the test:

XCTAssertEqual([self.customLayout calculateSpokeRadius], 190.0f, @"should be 190.0f");

Here, I’ve created a helper method inside the custom layout to calculate the radius from the centre of the collection view for various sizes of layout. That’s often an easier approach to take - calculating layout attributes like item centre often involves some fiddly maths, so by breaking it up into chunks of helper methods you can test each bit piece-by-piece.

This tends to be easier in the long run than doing everything in one fell swoop, because you can spend a long time down the rabbit hole of figuring out where the layout is going wrong. With this test, I can throw various sizes of collection view at the layout, and check that things will still work out OK.

This means I’m available for hire. I do several things:

• application architecture: figuring out how the user interactions, front-end, back-end and data pieces of a service need to work in order to play nicely together.

• project management: running Agile-style projects with mixed technical and non-technical teams.

• team management: building and running development teams, with all the challenges that are involved in a group of different skills and personalities.

• iOS development: hands-on code-cutting of apps.

All of these I’ve done in a variety of organisation shapes, sizes and cultures - so I’ve got to be quite good at the spinning plates and herding cats that tend to be involved in getting a service up and running in today’s online world. Ideally, I’m looking for something that draws on all four of those areas.

Location-wise, I’m interested in pretty-much anywhere in mainland Europe. Somewhere English/German-speaking would be a bonus.

Any leads will be gratefully received.

The other way of looking at this idea is that as an established iOS developer, your industry might be about to get invaded by millions of newbies who haven’t had to earn their stripes learning the intricacies of ObjectiveC. Your rates are about to go down, and the age of demand exceeding supply is over.

Both those are simplistic, and missing the bigger point. The bar to entry to this industry hasn’t moved at all - if anything, it’s been raised.

And that’s because becoming a competent developer who can earn a professional living writing code isn’t about mastering one area, it’s about mastering FOUR.

It doesn’t matter if you’re writing mobile apps in a language that was announced 24 hours ago; or banking systems in a language that was designed by people who have since died of a ripe old age. If you don’t understand these four areas, you’ll suck as a developer.

You need to know the language, the paradigms, the frameworks and the environment of the platform that you’re building for.

Knowledge of the language

In order to build any kind of software, you need a working knowledge of the language that you’re using. To learn a language can be the work of a few hours; to master it can be the work of a lifetime.

Irrespective of where you lie along the continuum, there’s a certain minimum amount of expertise that you will need to get by. You need a working knowledge of grammar in order to make yourself understood in speech, and coding is no different - understanding the syntax of a language is a prerequisite to being able to work with it.

Knowledge of the paradigms

When you think hard about what programming actually is, it gets philosophical in a way that you might not expect. You’re in the business of taking tangible, real-world problems and reconstructing them in an intangible mental domain.

We talk about objects as if they’re concrete physical entities - but building an app is actually a process of making a whole series of imaginary constructs, and then getting them to interact with each other.

To do that, you need a working knowledge of the underlying paradigms. This is taking the physical form of the language and making use of it. In order to use objects to break down a problem, you need to understand what they are.

Knowing only the details of a specific language isn’t going to much use here - without the ability to comprehend the patterns of mental abstractions that you are expressing using the code of the language that you’ve chosen.

Knowledge of the frameworks

Knowing what an object is, and how you create one with Swift or Objective-C or whatever language you’re working with, still isn’t enough. Next, you need a knowledge of the frameworks.

While it might be possible to build every aspect of an iOS app from scratch, that’s not a practical way to work. So instead we rely on the frameworks that Apple provides. Table views are a standard control - but they behave in a particular way, and you need an understanding of how they fit together and operate in order to exploit them.

There are so many frameworks involved in iOS that it’s probably not a practical proposition to even attempt to understand all of them.

But some are unavoidable - you’re not going to get far without knowing even the basics of UIKit, for example.

To understand this takes not just a knowledge of the language that they’re built in, but also the underlying paradigms that they’re exploiting. Knowing how to set a table view’s delegate is one thing, but you also need to know what a delegate actually is.

Knowledge of the environment

Assuming a working ability with the language, the paradigms and the frameworks, you’re now in a position to start building things. But only knowing those three is missing one vital part - and that’s the understanding of the environment in which you’re operating.

The shorthand way of referring to this is user experience - why your interface is laid out the way it is, and the workflows that your app provides in order to solve the particular problem it is dealing with.

But this is a complex mix of physical contraints and psychology. Force your users to rely on voice input in a noisy environment - or large amounts of text input on a tiny keyboard - and they’ll struggle to interact with your app. Forcing them to think about how they need to interact, and they’re likely to give up and find an easier alternative.

Where does this leave Swift?

Swift doesn’t change the fundementals of what it takes to be a competent developer AT ALL. It’s possible that it might make picking up the basics slightly easier, although I’m sceptical. Go beyond the first few pages of the Swift guide, and this doesn’t feel like a toy language designed specifically for ease of learning.

What Swift doesn’t do is lower the bar to understanding the paradigms, the frameworks, or the environment. In fact I’d argue it actually raises the bar, at least for a while. It will probably be several years before you can fully get to grips with iOS without any knowledge of ObjectiveC, so for the interim you’re going to need to learn the details of two languages if you’re just starting out.

It might make building some chunks of functionality quicker, and you might find the syntax more expressive or the structure clearer to read.

But without knowing the abstract concepts of programming, and the details of Cocoa Touch, and the constraints of tiny screens in a world of continuous partial attention, you’re not going to succeed in this industry. So I’m not going to worry about being priced out of my chosen field just yet.

The presentation slides are available here.

Testing networks

Unless you’re in the business of writing fairly trivial apps, eventually your code is going to need to talk to some external services reachable across a network link. That immediately opens up a whole world of problems that you need to deal with. Availability, latency, and quality of service are the issues that your app is going to have to handle, while you’re also going to need to make decisions about how to inform your user of what is going on.

It’s very easy to fall into the trap of building apps that work beautifully in the Simulator when sat on a Gigabit ethernet segment downstream from a multi-megabit fibre broadband connection. But the real world isn’t like that - your app needs to be able to handle the flakiest of ropey Edge services, not just full-fat wifi. Forgetting to handle those edge cases is a quick way to build something with really sucky user experiences.

It (should) go without saying that this needs to be tested. But that can be tricky - very often the APIs that your app is talking to aren’t under your control. They’re designed to be reliable and return valid data - so how can you test for the edge cases?

There are a couple of solutions, both of which rely on creating “stunt double” APIs that can stand in for the real thing. By tweaking your mock API, you can develop and test both happy paths and edge cases without any dependencies on live services.

Mocking APIs with servers

If you’re dealing with a relatively trivial API, the simplest option may be to whip up a standalone server and point your app at that for testing purposes. If you know Sinatra or Node, creating a mock API that accepts calls from your app and returns the contents of some predefined data files stored locally to the server isn’t that difficult.

But that a) presupposes that you do have those kind of technologies at your disposal, and b) creates another set of dependencies. In order to run the tests, you’ll need to make sure that your server is up and running, and returning the right values for a given endpoint. What would be far more elegant is a situation where all the moving parts needed for testing could somehow be bundled into your Xcode project.

Then you also need to make sure that your tests are calling the test API, while your live app talks to the production version. You don’t need too much imagination to see what could potentially go wrong here…

Mocking APIs

A practical alternative to a standalone server is a network stubbing library. That sits inside your test target and intercepts any calls to the network in order to return data that you define. One of the most widely used is OHHTTPStubs.

OHHTTPStubs works by catching calls from NSURLConnection and NSURLSession, and checking whether the request should either be passed through as normal or intercepted by the library. If the call is to be intercepted, the library handles creating and returning the data - the call doesn’t get out to the actual network.

There’s also the ability to manipulate the way the response is sent back - for example, setting a simulated delay or latency, returning custom HTTP headers or response codes, or just behaving as if all the packets were dropped. By changing responses, it becomes possible to test a variety of situations ranging from perfect network connectivity to complete isolation.

Setting up OHHTTPStubs

OHHTTPStubs is easiest to install using Cocoapods. Add pod 'OHHTTPStubs' to your Podfile, run pod install, and you’re good to go.

However, now is a good point to introduce a caveat. The library makes extensive use of private frameworks to swizzle the functionality into place, so including it in an app that you try to ship to the App Store is a Very Bad Idea Indeed. There are a couple of ways around this: one is to remember to take it out (not recommended); the other is to only include the library in your test target.

Assuming your project is called MyFantasticApp, then your Podfile should look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

platform :ios, "7.1"

...
main pods go here
...

target 'MyFantasticAppTests', :exclusive => true do

    pod 'OHHTTPStubs'

    ...
    other pods as required
    ...

end

As the MyFantasticAppTests target is separate from the main one, OHHTTPStubs won’t get compiled in when you build the project.

How it works

The basic syntax of using OHHTTPStubs looks like this:

1
2
3
4
5
6
7
8
9
10
11

[OHHTTPStubs stubRequestsPassingTest:^BOOL(NSURLRequest *request) {

   < test the request to see if we want to stub it, and
     and return YES if we do >

} withStubResponse:^OHHTTPStubsResponse *(NSURLRequest *request) {

    < Create and return an OHHTTPStubsResponse object with the
      data that we want to return >

}];

Which request to stub?

In the first block, we’re examining the NSURLRequest to see if it’s one we want to stub out - this allows you to pass through some requests, but catch others.

If you want to stub ALL requests, you simple return YES from this block. Otherwise, you can be more subtle:

• catching all requests to a specific host:

// Catch http://adoptioncurve.net return [request.URL.host isEqualToString:@“adoptioncurve.net”];`

• catching all requests to a specific URL:

// catch http://adoptioncurve.net/about return [request.URL.lastPathComponent isEqualToString:@“about”];`

• catching requests with a specific query string

// Catch http://adoptioncurve.net/login?id=1234 return [request.URL.query isEqualToString:@“id=1234”];`

How to return data

Once the stubRequestsPassingTest: block has returned YES, you’ll need to create an OHHTTTPStubsResponse object to return to the method that made the original request. This mimics the data payload that the API would return.

There are several ways of doing this:

• responseWithData:statusCode:headers: allows you to create an NSData object yourself, and return it along with an HTTP status code and HTTP headers

• responseWithFileAtPath:statusCode:headers: allows the contents of a file to be returned, along with status codes and headers. This file can be JSON, HTML, binary data or whatever format your API will return - the only requirement is that it exists in the app bundle where the tests can find it.

Getting sample data

The first thing you’ll need when starting to use OHHTTPStubs is some data to return for your tests.

If you manage to overcome the visceral loathing and need to user Storyboards in tests, you’ll hit the problem that they seem to be used semi-magically. There’s no obvious equivalent of an initWithNibFile method that you can hook into to load the thing as you kick your test case off.

The answer is actually reasonably straight forward. Create your storyboard as normal (or rely on an Xcode template if that’s your thing), then make sure that you’ve given it a Storyboard ID in the Attributes inspector. The ID you use is a text string, and Xcode doesn’t seem to care what that string is.

Then in your test, you load and instantiate your view controller in a two stage process - here’s an example Kiwi test:

1
2
3
4
5

it(@"should instantiate the view controller", ^{
    UIStoryboard *mainStoryboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
    ViewController *vc = [mainStoryboard instantiateViewControllerWithIdentifier:@"ViewController"];
    [[vc shouldNot] beNil]
});

This loads the storyboard itself, then instantiates the view controller from it - the identifier string is whatever you put in the Storyboard ID field in Interface Builder.

The presentation slides are available here.

Why is testing scary?

Unit testing is a topic that gets talked about a lot, but if you’re not a computer scientist it can have a tricksy reputation. It doesn’t help that much of the source material available is Java-based. That’s fine if you like Java - I’m personally not so keen - but there’s a lot less help if your primary weapon of choice is Objective-C.

Testing is also a topic that attracts - how shall we put it? - some of the more tedious personalities in this business. There’s nothing so dull as a self-appointed “thought leader”, and a lot of what passes for debate on testing is so much arcane, “how many angels can dance on the head of a pin”-style nonsense.

That’s got very little to do with the day-to-day grind of shipping software. There is no One Way to do this, and if you look hard enough at the motives of those who would have you believe that, you often find it comes down to selling themselves as a brand.

Why is testing important?

All that said, testing is important. Let’s start from the premise that the fewer bugs in your code, the better. If you subscribe to that school of thoughy, then anything that helps you achieve this has to be a good thing. As the developer who writes 100% bug-free code hasn’t been born yet, we’re also faced with the challenge that the more code we write, the more likely it is that the project will turn out to be infested with them.

Documentation is also held to be a Good Thing, but it’s also something that very few devs are particularly keen on doing - especially once the code’s been written. A comprehensive test suite, especially if it’s been built using one of the more “descriptive” tools such as Kiwi or Specta, can almost replace documentation. It’s also considerably easier to read than code, because it’s documenting intent rather than execution - the “what” rather than the “how”.

Perhaps the most important reason for taking a test-driven approach, though, is the way you’ll knit yourself a “security blanket” around your code. We’ve all been in the situation where making changes to an existing code base is a stressful affair, because you’re never quite sure whether changing something over here will break something over there.

If your test suite is comprehensive enough, you can relax to an extent knowing that the tests will catch those kinds of problem. And that becomes particlarly important if you’re working with others, because tests can help catch things that break your code.

The basics

The basic purpose of testing is to ask the question “does my code do what it’s supposed to do.” Assuming that you can give a positive answer to that, it will then help you to ask other, more probing questions. *“Can my code handle unexpected values?” is one of them. Coding for the “happy path” only is a common problem - how can you ensure that your app will still work if the API doesn’t respond, for example. What will happen if the data received back from the API is beyond the bounds you expected, or is corrupt?

Even if your code is capable of handling strange data, you can still end up creating problems for yourself further down the line. As you add more classes and features, the chances of something new breaking something existing multiplies. Protecting each area with tests means that you have a safety net that should catch problems by code in another part of the app.

Why not test last?

The meaning of the word “test” implies checking after the fact - making sure that the code you’re written functions as you expected it to do. The problem with testing code after you’ve written it is that there’s actually very little motivation to do this in normal circumstances. After all, you’ve written the code, it does what it’s supposed to, and you’re infallible - right? Testing that it works is just spending more time doing over the same ground.

That’s definitely the response you’ll get when the project manager wanders over and asks what you’re doing. If the answer is “writing tests for the feature that we shipped last week”, then they’re going to ask when you’re going to get on with more productive stuff. In a time-constrained project, there’s a perverse incentive not to test.

Why test first?

The rhythm of test-first, or test-driven development follows a predictable pattern. First, you write a test which describes the outcome that you’re after. What that will be obviously depends on the type of code you’re writing - in the case of a calculation, it would be a correct result; in the case of a UI feature it would be some kind of update to the views.

Then, you run the test. This seems counter-intuitive, because it fails. It has to fail, after all - you haven’t written any code to make it pass yet. In the jargon, your test has just “gone red”. But in the process of seeing the test fail, you’re already getting clues about how to go about fixing it. It’s like having a small and benign homunculus perched on your shoulder, whispering hints about what to do as the tests progress.

With that advice in mind, you can then write the code that will make the test pass - or “go green”. If at first the test fails, you know you haven’t got it right yet - but you always have the target in mind, because you started by describing the outcome that you were looking for.

Once you’ve got a passing test, you’re then free to improve things safe in the knowledge that the test will catch anything you do to break the code. That’s the “refactor” step, and you’ve now been once round the red-green-refactor loop that is the basic process of test-driven development.

Challenges of testing iOS

Test-driven development, or indeed testing of any kind, has some special challenges in the iOS world. The tools and techniques of testing were developed in a terminal-driven world, so many of the approaches are predicated on the results being something that has no user interface component.

On iOS, on the other hand, practically everything happens in response to some kind of user input passed down through the Cocoa Touch layer. And the code that responds to the touches can be highly modular - an indidivual class rarely stands and operates on its own, but instead has to collaborate with all manner of other classes and external APIs.

These two factors - responding to touches, and highly-modular code architectures - can make test-driven development on iOS seem like an impossible challenge. That’s even more the case if you’ve inherited an existing project, and you’re now faced with the challenge of wrapping tests around an already-built code base.

Fortunately, there are some available tools and techniques which can get around both these problems. In the next post, I’ll dig down into how these work in practice, and how you can take advantage of the structure of Cocoa Touch itself to build apps in a completely test-driven way.

To avoid pixellation in the callout, your original image will need to be bigger than the main image on the canvas. Place the main image on the canvas and scale it accordingly:

Draw a circle shape onto the canvas, then add another copy of the main image as the shape’s background using the Set Image option in the Image section in the inspector:

A scaled-down version of the main image will appear as the background of the callout shape:

Now click the Manual Sizing button in the Image inspector to revert the shape background to full size:

Then click the Mask button so that the shape is shown as an overlay on the fullsize image:

Now you can use the scaling grab handles at each corner of the shape’s background image to get the callout to the correct size, and move it so that the correct area is show in the callout:

Clicking the Done button in the Image inspector will hide the full background image - at this point you can move the callout into the right place.

To show the zoomed area, drag another Circle shape onto the canvas and set its fill style to none. Now position it to show the area that’s enlarged in the callout. You can also adjust the border of the circles to make them stand out:

Finally, add two tangent lines to join the original area and the callout:

The end result is a neat callout image highlighting a specific area on the main image.

Our guiding principles over the next 12-18 months include the following:

* we will start with user needs: until we understand what users across the Cabinet Office want and need, we won’t start buying things

* we will design with choice and flexibility in mind: there will be many and different needs across the department so we will offer technology solutions that fit individuals and teams

* we will be transparent throughout: we will be open about decisions and actions so our users and stakeholders understand why we’re taking a certain approach

* we will architect loosely coupled services: we are not building a “system”; we are delivering a set of devices and services that can be independently replaced. A key success measure for the programme is that we should never have to do it again

* we will favour short contracts: technology changes rapidly and we believe the age of the long-term contract is over. We need to be able to swap services in and out as the need arises

* we will bring the best of consumer technology to the enterprise: modern devices and cloud applications are built to be intuitive and flexible with minimal need for training. We believe business technology should be the same

* we will make security as invisible as possible: we are working with CESG and GSS to ensure all services are secure to new Official level. However, appropriate levels of security shouldn’t get in the way of the user experience of the services

* we will build a long-term capability: technology delivery doesn’t end with the programme. We will not be handing the services over to a single outsource vendor in 2015, but instead will be bringing digital skills back into the department

Apple are using Bluetooth LE to power iBeacons – a beacon is a low-power device that talks Bluetooth LE and can be detected by the CoreLocation stack. An app can be “woken up” by a beacon, and can use the signals from several beacons to obtain location information. Think indoor GPS with a (potential) accuracy of centimetres.

At the moment, the iBeacon spec is under NDA, which means that beacons themselves are hard to come by. You can pre-order Estimotes which look like they’ll be the simple, pretty but expensive option; or try Kontakt devices (not so pretty, still expensive). Or there’s the Redbear Labs BLE Mini if you prefer bare boards and some soldering.

iOS devices of recent vintage can act as beacons, though – so if you just need some beacons for testing, there’s no reason why you can’t grab a handful of iPod Touches or similar and use these. The other advantage of this approach is that configuring the various beacon parameters is much easier with a iOS device than fiddling around with hardware alternatives.

ActsAsBeacon is a tiny app which turns your iOS7 device into an iBeacon, and has a search function to show details of beacons in the vicinity. It will also allow you to configure the service UUID and broadcast parameters so that it’s possible to experiment with iBeacon-enabled apps.

In the next version that I’m currently tinkering with, the app will also provide a configuration interface for BLE Mini boards – Redbear Labs have an app for this, but it’s a bit broken on iOS7. My version allows the Mini boards to be configured over the air once their firmware has been updated to run the iBeacon version.

The app’s available as a GitHub repo, and I’ll be submitting a version to the App Store in a couple of days so that there’s no dependency on Xcode and a Developer Program license.

This is by way of an outboard brain dump to remind myself of how this is done.

Remove the Main.storyboard file

This can simply be deleted.

Update the ProjectName-Info.plist file

Remove the Main storyboard base file name key.

Create a nib file and link to the project’s view controller

1. Create a nib file (File -> New -> File -> View)
2. Update the File's Owner's class to whatever the project’s view controller is called
3. Link the File's Owner's view outlet to the view object in the nib file

Update the app delegate

1. Import the project’s view controller’s header file
2. Update the application:didFinishLaunchingWithOptions: method:

1
2
3
4
5
6
7
8

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    MyViewController *viewController = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:nil];
    self.window.rootViewController = viewController;
    [self.window makeKeyAndVisible];
    return YES;
}