matrixprojects.net - tips Posts

Live Reset For UI Tests

Wed, 30 May 2018 18:00:00 +0000

Overview

A typical test case involves using our test subject from a clean (or perhaps some pre-determined) state, perform some action(s) and verify some state. UI tests should follow this pattern too. Each test case should re-launch the app and reset it prior to conducting the test to ensure we have deterministic test cases.

Resetting or pre-configuring the app on launch is easily achieved by specifying some launchArguments and launchEnvironment on XCUIApplication from within the test target. John Sundell covered examples of how this can be achieved in his UIKonf talk about the Magic of UI testing which is worth a watch!

Re-launching the app each time however has one small snag! This re-launch business takes up time, ~6 Seconds per re-launch! This figure is for a dummy app, the actual launch time could be worse for larger applications. That’s a whole minute for 10 test cases, ten minutes for 100!

The Short Version

During UI testing, introducing a mechanism to reset our app while it’s running will give us the best of both worlds, a clean slate each time and a faster transition to subsequent tests!

Here’s a demo of how such a technique compares:

The following sections will cover some of ways this reset mechanism can be implemented, ranging from simple to slightly more complex ones.

How much time is wasted?

In the intro I mentioned the 6 seconds figure, that’s what I measured for a sample app. If you’re curious how much time is wasted for your test cases you could inspect the raw logs in Xcode. Those can be found by navigating to the Report Navigator tab (⌘+9) and selecting Log. From there you could either expand the log in Xcode or copy it out to a file.

Note: to avoid copying out duplicate log lines, copy the section that starts with Run test suite...

The log lines look something like this:

t =    14.20s Open net.matrixprojects.trials.LiveReset
t =    14.23s     Launch net.matrixprojects.trials.LiveReset
t =    14.23s         Terminate net.matrixprojects.trials.LiveReset:37874
t =    17.76s         Wait for net.matrixprojects.trials.LiveReset to idle
t =    20.87s Tap "List" Button
t =    20.87s     Wait for net.matrixprojects.trials.LiveReset to idle
t =    20.91s     Find the "List" Button
t =    21.05s     Synthesize event
t =    21.15s     Wait for net.matrixprojects.trials.LiveReset to idle

In this example, the launch of the app takes place between Open net.matrixprojects.trials.LiveReset log line and the first action Tap "List" Button.

Bashing some python and regex together, we could work out the total launch time taken:

import re

log = open("/path/to/raw-ui-test.log", "r").read()
regex = "=\s*([0-9]+\.[0-9][0-9])s Open .*\n" \
        ".*Launch.*\n" \
        ".*Terminate.*\n" \
        ".*Wait.*\n" \
        ".*=\s*([0-9]+\.[0-9][0-9])s"
results = re.findall(regex, log)

total_launch_time = 0
for r in results: 
    launch_time = float(r[1]) - float(r[0])
    total_launch_time = total_launch_time + launch_time

print "%.2f Seconds" % total_launch_time

Live Reset

To pull this off, at a high level here’s what we’ll need:

Gracefully handle a “reset” event while the application is running
Build out a mechanism to get notified about reset events
Trigger a reset from the UI tests instead of re-launching the app for each test case

The UI test runner (where our UI test code is running) is actually it’s own app/process. This means we can’t simply call out to our application classes directly to trigger our reset logic. Sadly there aren’t any options available out of the box when using XCTest to overcome this limitation, so we’ll need to get a bit creative to find some solutions.

Handling a live reset

We’ll need to ensure the view and data states are both reset while the application is running. By view state here I mean the view hierarchies. A simple way to achieve this is to re-create the window from scratch when we need to reset:

extension AppDelegate {
    func reset() {
        tearDown()
        window = createWindow()
    }

    func tearDown() {
        window?.rootViewController = nil
        window?.isHidden = true
        window = nil
    }

    func createWindow() -> UIWindow {
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        
        let window = UIWindow(frame: UIScreen.main.bounds)
        window.rootViewController = storyboard.instantiateInitialViewController()
        window.makeKeyAndVisible()
        
        return window
    }
}

Regarding the data state, it’s just a matter of re-creating your models / dependencies (e.g. Networking, storage, business logic models, etc…). This will of course vary app by app, for the sake of this blog post, I’ll be using a class called AppDependencies to act as the conglomerate of models / dependencies the app needs to function.

extension AppDelegate {
    func reset() {
        tearDown()
        appDependencies = createAppDependencies()
        window = createWindow()
    }
    // ...
}

We can then hook this all up our didFinishLaunchingWithOptions method:

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    
    var window: UIWindow?
    
    var appDependencies: AppDependencies?
    var resetNotifier: ResetNotifier?

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {

        setup()
        
        return true
    }

    // ...
}

extension AppDelegate {
    func setup() {
        reset()
    }

    // ...
}

Note: In the event the main interface setting is specified in the target setting, a UIWindow will automatically be created and it’s rootViewController will be set to the initial view controller of the specified Storyboard file. To avoid creating a redundant window and seeing we’re now manually creating and setting it up, we could opt out of the automatic behavior by simply clearing that setting.

Reset Notifier

As we explore the different techniques of triggering a live reset, it’s helpful to model our “Reset Notifier” as a protocol:

// ResetNotifier.swift

protocol ResetNotifier {
    func add(handler: @escaping () -> Void)
}

extension AppDelegate {
    // ...

    func setupResetNotifier() {
        resetNotifier = createResetNotifier()
        resetNotifier?.add { [weak self] in
            self?.reset()
        }
    }

    // ...
}

This helps keep our AppDelegate clean and isolate our reset mechanism in separate classes. This will also allow us to swap implementations as needed.

Reset Trigger

To trigger the yet to be determined “reset” mechanism from our UI test target we’ll need to tweak our test cases to call out to a custom reset() method instead of the typical launch() method:

extension XCUIApplication {
    func reset() {
        if state != .runningForeground {
            launch()
        } else {
            resetAction()
        }
    }
}

In the event the application isn’t running, we will still need to launch it first, but to hide that concern from the individual test cases we can work it out within our reset() method by checking the current XCUIApplication.State.

1) Floating Button Reset Notifier

The idea here is quite simple, when launching the app under test, we could inject a small floating reset button in our main UIWindow.

class FloatingButtonResetNotifier: ResetNotifier {
    var handlers: [() -> Void] = []
    var buttonTargetAction = TargetAction()
    
    init(window: UIWindow) {
        let button = createButton()
        embed(button: button, within: window)
        setupTapAction(for: button)
    }
    
    func add(handler: @escaping () -> Void) {
        handlers.append(handler)
    }
    
    func handleTap() {
        handlers.forEach { $0() }
    }
    
    func createButton() -> UIButton {
        let button = UIButton(type: .custom)
        button.setTitle("[Reset]", for: .normal)
        button.backgroundColor = UIColor.red.withAlphaComponent(0.4)
        button.accessibilityIdentifier = Reset.Button.accessibilityIdentifier
        return button
    }
    
    func setupTapAction(for button: UIButton) {
        buttonTargetAction.onTap = { [weak self] in
            self?.handleTap()
        }
        
        button.addTarget(buttonTargetAction,
                         action: #selector(TargetAction.didTap(_:)),
                         for: .touchUpInside)
    }
    
    func embed(button: UIButton, within window: UIWindow) {
        window.addSubview(button)
        button.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            button.trailingAnchor.constraint(equalTo: window.safeAreaLayoutGuide.trailingAnchor, constant: -10),
            button.bottomAnchor.constraint(equalTo: window.safeAreaLayoutGuide.bottomAnchor, constant: -10),
        ])
    }
    
    class TargetAction: NSObject {
        var onTap: (() -> Void)?
        
        @objc func didTap(_ sender: UIButton) {
            onTap?()
        }
    }
}

Due to this notifier’s dependency on the current UIWindow which we re-create each time, we’ll also need to re-create the reset notifier alongside it:

extension AppDelegate {
    func reset()  {
        tearDown()
        appDependencies = createAppDependencies()
        window = createWindow()
        setupResetNotifier()
    }
}

To trigger a reset from the UI tests, we simply tap that button:

extension XCUIApplication {
    func resetAction() {
        buttons[Reset.Button.accessibilityIdentifier].tap()
    }
}

Pros:

Simple to implement and manually test

Cons:

Quite intrusive, and could obstruct other views which may need to be tested
It isn’t possible to pass in new launchArguments or launchEnvironment when resetting for each test case

2) Gesture Reset Notifier

Instead of having a visible view this time, we could perhaps introduce a special gesture on the main window which triggers our reset.

class GestureBasedResetNotifier: ResetNotifier {
    var gestureHandler = ResetGestureHandler()
    var handlers: [() -> Void] = []
    
    init(window: UIWindow) {
        let gesture = createTapGesture(with: gestureHandler)
        setup(gesture: gesture, within: window)
        setupTriggerAction(for: gestureHandler)
    }
    
    func add(handler: @escaping () -> Void) {
        handlers.append(handler)
    }
    
    func didTrigger() {
        let handlers = self.handlers
        handlers.forEach { $0() }
    }
    
    func setupTriggerAction(for gestureHandler: ResetGestureHandler) {
        gestureHandler.onTrigger = { [weak self] in
            self?.didTrigger()
        }
    }
    
    func setup(gesture: UIGestureRecognizer, within window: UIWindow) {
        window.addGestureRecognizer(gesture)
        window.accessibilityIdentifier = Reset.Gesture.hostWindowAccessibilityIdentifier
    }
    
    func createTapGesture(with gestureHandler: ResetGestureHandler) -> UITapGestureRecognizer {
        let resetGesture = UITapGestureRecognizer(target: gestureHandler, action: #selector(ResetGestureHandler.didTrigger(_:)))
        resetGesture.numberOfTapsRequired = Reset.Gesture.numberOfTaps
        resetGesture.numberOfTouchesRequired = Reset.Gesture.numberOfTouches
        resetGesture.delaysTouchesBegan = false
        resetGesture.delaysTouchesEnded = false
        return resetGesture
    }
    
    class ResetGestureHandler: NSObject {
        var onTrigger: (() -> Void)?
        
        @objc func didTrigger(_ gestureRecognizer: UIGestureRecognizer) {
            guard gestureRecognizer.state == .recognized else {
                return
            }
            onTrigger?()
        }
    }
}

Similarly to the floating button, due to this notifier’s dependency on the current UIWindow, we’ll also need to re-create whenever we re-create the window:

extension AppDelegate {
    func reset()  {
        tearDown()
        appDependencies = createAppDependencies()
        window = createWindow()
        setupResetNotifier()
    }
}

To trigger the reset, we can attempt to perform the gesture, for example if it was a multiple tap based gesture:

extension  XCUIApplication {
    func resetAction() {
        let window = windows[Reset.Gesture.hostWindowAccessibilityIdentifier]
        window.tap(withNumberOfTaps: Reset.Gesture.numberOfTaps,
                   numberOfTouches: Reset.Gesture.numberOfTouches)
    }
}

Pros:

Not as obstructive as a floating button

Cons:

UI tests aren’t able to reliably trigger complex gestures (e.g. with multiple touches)
It’s easy to accidentally trigger the reset gesture during the test
As with the floating button, we aren’t able to pass new launchArguments or launchEnvironment when resetting

3) Darwin Notification Reset Notifier

You might be surprised to learn there’s actually a low-level API available within iOS that actually allows cross app communication! DarwinNotifyCenter. All-be-it a simple trigger without any means to pass data, for the purposes of a reset, it does the trick.

I’ve actually covered this in a previous post if you’re interested in details. Be warned it’s quite an old post and with many of the code snippets written in Swift 2 syntax! The good news is that the associated github project was recently updated to Swift 4.

In this example, I’ll be using the “beeper” class (I know, naming is hard …) from github. This class will need to be part of both the main application and UI test targets.

class DarwinNotifyCenterResetNotifier: ResetNotifier {
    var handlers: [() -> Void] = []
    let beeper = DarwinNotificationCenterBeeper()
    
    init() {
        beeper.registerBeepHandler(identifier: Reset.triggerKey) { [weak self] in
            self?.handlers.forEach { $0() }
        }
    }
    
    func add(handler: @escaping () -> Void) {
        handlers.append(handler)
    }
}

Since there is no dependency on the window here, the reset notifier only needs to be setup once and does not need to be re-created on every reset.

extension AppDelegate {
    func setup() {
        reset()
        setupResetNotifier()
    }
}

On the UI test side, we could trigger a reset via:

extension XCUIApplication {
    func resetAction() {
        DarwinNotificationCenterBeeper().beep(identifier: Reset.triggerKey)
    }
}

Pros:

This offers a real trigger mechanism without requiring us to inject elements into our hierarchy that could content with the elements being tested

Cons:

Like the previous techniques, we still aren’t able to pass new launchArguments or launchEnvironment when resetting
- That said, if there’s only a handful of settings we need (e.g. “launch with mock data” and “launch with real data”), we could extend our reset notifier to have two distinct reset methods which have their own notification identifiers. This of course will not scale with more settings!
This API seems too permissive, given how within the iOS eco-system there is heavy sandboxing to prevent apps from interfering with each other, it wouldn’t come as a surprise if this API were to no longer function or be supported in the future.

4) HTTP Request Reset Notifier

This sounds quite extreme but actually unlocks a whole load of possibilities while UI testing. A lightweight http server (e.g. Swifter or Embassy) can be installed within the main application. This server effectively creates another communication channel for us to send custom requests to control the behavior of the app during runtime. Thus enabling us to send a “reset” request from the test target (e.g. http://localhost:8080/reset).

This is not a wildly new concept, see Stubbing Apple’s UI Tests by Tomas Camin and Embedded web server for iOS UI testing by Fang-Pen Lin for examples of what is possible with such a setup beyond a simple “reset”.

For this example, I’ll be using Swifter:

import Swifter

class SwifterResetNotifier: ResetNotifier {
    var handlers: [() -> Void] = []
    let server: HttpServer
    
    init() {
        server = HttpServer()
        registerPathCallbacks(in: server)
        try! server.start(in_port_t(Reset.HttpServer.port))
    }
    
    func add(handler: @escaping () -> Void) {
        handlers.append(handler)
    }
    
    func handleReset() {
        DispatchQueue.main.sync {
            handlers.forEach { $0() }
        }
    }
    
    func registerPathCallbacks(in server: HttpServer) {
        server[Reset.HttpServer.resetPath] = { [weak self] _ in
            self?.handleReset()
            return .ok(.html("Reset triggered!"))
        }
    }
}

Similarly to the previous notifier, as there is no dependency on the window, the reset notifier only needs to be setup once and does not need be re-created on every reset.

extension AppDelegate {
    func setup() {
        reset()
        setupResetNotifier()
    }
}

Within the UI tests, it’s a matter of sending an http request to trigger a reset:

extension XCUIApplication {
    func resetAction() {
        guard let url = URL(string: Reset.HttpServer.resetUrl) else {
            return
        }
        
        let e = XCTestExpectation(description: "Reset request should complete")
        URLSession.shared.dataTask(with: url) { _, _, _  in
            e.fulfill()
        }.resume()
        
        XCTAssertEqual(XCTWaiter.wait(for: [e], timeout: 5.0), .completed)
    }
}

Another option within the same concept is to leverage a dedicated testing framework like SBTUITestTunnel by Tomas Camin. It leverages GCDWebServer under the hood and offers a mechanism to pass data between the UI test target and the main application via Custom Commands.

Pros:

Http requests are capable of also carrying extra data within the request body. Using some simple Codable structures we can easily pass new launchArguments or launchEnvironment equivalents to the application as part of the reset request. This will not only allow us to reset the app, but also re-configure it on demand based on our test requirements
In addition to resetting the application via our UI tests, we can craft a small html which can have buttons to reset and configure our application to the various states we’re interested in. Effectively we craft our own Hot Reload functionality!
- The html can actually be served from the embeded server when visiting a special link such as http://localhost:8080/debug

Cons:

Having an http server for testing purposes baked into the app could be a hard sell, we wouldn’t want to accidentally ship it to the App Store!
For the time being, the UI test runner is capable of initiating URLSession requests, that however may change as there are no guarantees provided by testing framework about the behavior of the test runner app. It’s been working thus far, let’s hope it carries on!

Interesting Side Effects

An interesting side effect of utilizing live reset is how the UI tests suddenly become a memory leak detector! Keeping the app alive between test cases means any leaks will reside and build up throughout the entire test run and eventually may cause some random crashes.

This actually presents a great opportunity to add some basic tooling to check for leaks and report them proactively (e.g. a weak references array of core components that should be empty on reset).

Mitigating Risk

Many of the techniques described come with some level of risk, as we could be polluting our app with test scaffolding code that we wouldn’t want to ship.

To mitigate this, we could ensure we have some compile time protection by wrapping all the reset code with #if DEBUG statements. To keep things manageable, we would need to minimize the surface area of our reset code to avoid littering #if DEBUG statements everywhere.

Another “safer” option is to perhaps create a dedicated “Sample” application target which includes all the additional test scaffolding while keeping our main application untouched. This does require the core logic of our app to reside within independent frameworks so they can be included by both application targets. The nice thing about this option is that we’re not restricted to just the one sample application, we can create as many as we need based on functionality. This can work really well for larger applications that are managed by multiple teams.

Conclusion

With a bit of creativity we’re able to optimize a small aspect of how our UI tests can run, it may not be for all projects but is certainly worth a try.

Happy testing!

UI Testing with NSUserDefaults

Sat, 06 Feb 2016 13:15:00 +0000

Overview

Last year at WWDC’15, Apple introduced UI testing to XCTest. While not a completely new concept, the fact its now a first class citizen in the developer toolchain is a big deal.

Having used it on a few occasions recently, here’s some tidbits I thought I’d share.

UI Tests

When unit testing, the approach is usually spinning up a single class to test and mock all it’s dependancies to control it’s behavior. This allows us to exercise and verify all the class’s functionality.

Unlike unit tests, when using UI tests, there is no direct way to spin up an instance of a single view to be tested and provide it with mocks. The UI test target is actually a completely separate process, as such the main application code can’t be communicated with directly either.

Arguably that is not how a UI Test should be used, but rather it’s meant to ensure the flows and behavior of the application work as a user would expect.

That being said, tests should be made as reliable and reproducible as possible. Especially if your app requires performing any network requests or accessing any external resources. Not only would the UI tests be slower but also the test environment itself needs to have the appropriate access to these resources which may not always be available. As such there is merit in being able to control certain aspects of the applications when doing UI tests.

Launch Arguments

Googling around, you will find many examples that leverage XCUIApplication().launchArguments to pass in arguments to the main target being tested.

e.g.

MyAppUITest.swift

override func setUp() {
  super.setUp()

  let app = XCUIApplication()
  app.launchArguments.append("ui-testing")
  app.launch()
}

MyAppDelegate.swift

func setupModel() -> Model {
    let uiTesting = ProcessInfo.processInfo.arguments.contains("ui-testing")
    
    let model: Model = uiTesting ? StubModel() : NetworkModel()
    
    return model
}

NSUserDefaults

We can achieve a similar result by leveraging NSUserDefaults too.

Reading though the Defaults System Guide, there’s a way to manipulate the NSUserDefaults’s Argument Domain through launch arguments.

This is achieved through specifying launch arguments in the following format:

-<key> <value>

Taking our example above it can be changed to:

MyAppUITest.swift

override func setUp() {
    super.setUp()
    
    let app = XCUIApplication()
    app.launchArguments.append(contentsOf: ["-ui-testing", "YES"])
    app.launch()
}

MyAppDelegate.swift

func setupModel() -> Model {
    let defaults = UserDefaults.standard
    let uiTesting = defaults.bool(forKey: "ui-testing")
    
    let model: Model = uiTesting ? StubModel() : NetworkModel()
    
    return model
}

NSUserDefault Stubs

Taking the concept above we can take it a step further and start creating full fledged stubs that are controlled by user defaults. This can allow us to gain even more control over our application from the UI tests.

Here’s a simple example of an application with a login feature:

LoginUITest.swift

struct Credentials {
  let user: String
  let password: String
}

// ...

let credentials = Credentials(user: "test", password: "1234")

override func setUp() {
    super.setUp()
    
    let app = XCUIApplication()
    app.launchArguments.append(contentsOf: ["-ui-testing", "YES"])
    app.launchArguments.append(contentsOf: ["-model.user", credentials.user])
    app.launchArguments.append(contentsOf: ["-model.password", credentials.password])
    app.launch()
}

func testLoginSuccessful() {
  let app = XCUIApplication()

  let userField = app.textFields["Username"]
  let passwordField = app.secureTextFields["Password"]

  userField.tap()
  userField.typeText(credentials.user)

  passwordField.tap()
  passwordField.typeText(credentials.password)

  app.buttons["Login"].tap()

  let results = app.staticTexts["results"]
  XCTAssertEqual(results.label, "Success")
}

func testLoginUnsuccessful() {
  let app = XCUIApplication()

  let userField = app.textFields["Username"]
  let passwordField = app.secureTextFields["Password"]

  userField.tap()
  userField.typeText(credentials.user)

  passwordField.tap()
  passwordField.typeText("incorrect-password")

  app.buttons["Login"].tap()

  let results = app.staticTexts["results"]
  XCTAssertEqual(results.label, "Login failed")
}

MyAppDelegate.swift

...
func setupModel() -> Model {
  let defaults = UserDefaults.standard
  let uiTesting = defaults.bool(forKey: "ui-testing")
  
  let model: Model = uiTesting ? UserDefaultsModel(defaults: defaults) : NetworkModel()
  
  return model
}
...

Model.swift

protocol Model {
  func login(user: String, password: String) -> Bool
}

UserDefaultsModel.swift

class UserDefaultsModel {
    let defaults: UserDefaults
    init(defaults: UserDefaults) {
        self.defaults = defaults
    }
    
    // MARK: - Model
    func login(user: String, password: String) -> Bool {
        if let validUser = defaults.string(forKey: "model.user"),
            let validPassword = defaults.string(forKey: "model.password"),
            validUser == user,
            validPassword == password {
            return true
        }
        return false
    }
}

What we achieve here is the ability to test our UI without making a single network request! Another win we gain by following this approach is the ability to exercise situations that are hard to reproduce in a live system. For example if our model also reported connectivity failures, we have a simple way to simulate and test that, without actually disconnecting the machine from the network.

Schemes

Sometimes there may still be a desire to use the full application without making using any stubs when conducting UI testing for one reason or another.

In our login example above, if we want to test the login using the network model we have to ensure the credentials provided are valid ones (perhaps for a test account). In some cases, burning the credentials in the code and have it visible in the repository may not be desired.

Once again we can use launch arguments and NSUserDefault, this time via schemes.

A new testing scheme can be created with the credentials added as launch arguments:

-testing.user testAccount -testing.user testPassword

Ensure the testing scheme shared option is not checked and that the scheme itself is not checked into the repository.

In the test, the credentials can then be extracted from user defaults:

var credentials: Credentials!

override func setUp() {
  super.setUp()

  let defaults = UserDefaults.standard
  
  if let user = defaults.string(forKey: "test.user"),
      let password = defaults.string(forKey: "test.password") {
      credentials = Credentials(user: user, password: password)
  } else {
      XCTFail("No credentials provided for testing")
  }
  
  let app = XCUIApplication()
  app.launch()
}

Final Thoughts

UI testing is by no means a replacement to unit testing. Each have their uses and there’s plenty of material online as to which is more suited to different situations.

As with unit testing, good architecture and design can go a long way to making the application testable, even from a UI level.

i.e. No singletons please!, pass your dependencies in!!

Happy testing!

Links

Update (25th-Nov-2018): Code snippets updated for Swift 4.2 syntax

UICollectionViewCells Dynamic Width

Sun, 31 May 2015 20:00:00 +0000

Update (2022): The recommended approach for achieving this these days is via leveraging UICollectionLayoutListConfiguration. A great reference is Apple’s Modern Collection Views sample code.

Overview

UITableViews are a popular choice when it comes to implementing just about any kind of screen for your app. UICollectionViews are even more powerfull and offer a wider range of options. You can find out more about collection views by reading Apple’s documentation, watching any of their WWDC videos on the topic, or reading this great post on NSHipster.

While collection views offer a great deal of flexibility and customisation - they don’t offer the same pre-canned behaviours we all take for granted in table views. One of these items is the built in editing mode which allows user interaction to re-order and delete items from the list.

While it is possible to implement this with collection views - we’d have to do a lot of the heavy lifting ourselves to achieve it. Another item which may seem quite trivial is the automatic width sizing table views apply to their cells so they span across the whole table view.

In this post I wanted to share how to achieve that behaviour with collection views. I will walkthrough some of the options available when using Flow Layout.

Option 1: The simple option

We can simply set the itemSize width on Flow Layout to be the same as the collection view width.

import Foundation
import UIKit

class ItemSizeCollectionViewcontroller : UICollectionViewController
{
    // MARK: Outlets

    @IBOutlet weak var flowLayout: UICollectionViewFlowLayout!

    // MARK: Properties

    var dataSource = CommonDataSource()

    // MARK: UIViewController

    override func viewDidLoad()
    {
        super.viewDidLoad()

        let nib = UINib(nibName: "MyCollectionViewCell", bundle: NSBundle.mainBundle())

        // Manually set the size to be the same as the collection view width
        // flowLayout.itemSize = CGSize(width: collectionView!.bounds.width, height: 60)

        // For completeness the section insets need to be accommodated
        var width = collectionView!.bounds.width - flowLayout.sectionInset.left - flowLayout.sectionInset.right
        flowLayout.itemSize = CGSize(width: width, height: 60)

        collectionView?.registerNib(nib, forCellWithReuseIdentifier: "cell")
        collectionView?.dataSource = dataSource
    }

    // MARK: Actions

    @IBAction func didTapRefresh(sender: UIBarButtonItem)
    {
        collectionView?.reloadData()
    }
}

This does work but has a few caveats. First, section insets need to be accounted for and second this will not work as soon the device is rotated to landscape.

Attempting to reload data won’t cut it unless we also set the item size before reloading … not a great option.

Option 2: Flow Layout’s Delegate

To mitigate the issues stated above we can make use of the delegate method, that way on reloads the item size will automatically get picked up.

// MARK: UICollectionViewDelegateFlowLayout

func collectionView(collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAtIndexPath indexPath: NSIndexPath) -> CGSize
{
    var width = collectionView.bounds.width - flowLayout.sectionInset.left - flowLayout.sectionInset.right
    return CGSize(width: width, height:60)
}

This still won’t solve the issue of re-sizing on rotation without requiring a call to reload data.

Option 3: Reacting to Rotations

In iOS 8, the willRotateToInterfaceOrientation(...) and didRotateFromInterfaceOrientation(...) methods on UIViewController were deprecated in favor of viewWillTransitionToSize(...).

override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator)
{
    super.viewWillTransitionToSize(size, withTransitionCoordinator: coordinator)

    collectionView?.reloadData()
}

This will do the trick … but perhaps reloading data may not be desirable - after all the data didn’t change, all we want to do is stretch the cells that are already there. UICollectionViewLayout has an invalidateLayout() method that can be used to achieve that.

override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator)
{
    super.viewWillTransitionToSize(size, withTransitionCoordinator: coordinator)

    flowLayout.invalidateLayout()
}

This sadly won’t work. At the point we call invalidate layout above, the collection view has not yet been resized to its new size. One way around that is to perform the invalidate layout call after the transition completes.

override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator)
{
    super.viewWillTransitionToSize(size, withTransitionCoordinator: coordinator)

    coordinator.animateAlongsideTransition({ (context) -> Void in
    }, completion: { (context) -> Void in
        self.flowLayout.invalidateLayout()
    })
}

This will kinda work … but doesn’t seem very elegant. A better way to do this is to temporarily store the new size and work out the collection view size from it.

var widthToUse : CGFloat?

override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator)
{
    super.viewWillTransitionToSize(size, withTransitionCoordinator: coordinator)

    widthToUse = size.width
    flowLayout.invalidateLayout()
}

func collectionView(collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAtIndexPath indexPath: NSIndexPath) -> CGSize
{
    var collectionViewWidth = collectionView.bounds.width
    if let w = widthToUse
    {
        collectionViewWidth = w
    }
    var width = collectionViewWidth - flowLayout.sectionInset.left - flowLayout.sectionInset.right
    return CGSize(width: width, height:60)
}

This will work as intended. Issues will arise when the collection view is part of a more elaborate screen with other views surrounding it and as such would require duplicating layout logic (or worse writing new layout logic which auto-layout was already taking care of).

Option 4: Flow Layout Subclass - modifying attributes

While the previous solutions do work and can probably be improved or tweaked further. Personally however, I found the following solution to be the best. Creating a subclass of flow layout which works out the width automatically.

class FullWidthCellFlowLayout : UICollectionViewFlowLayout
{
    func fullWidth() -> CGFloat {
        let bounds = collectionView!.bounds
        let contentInsets = collectionView!.contentInset

        return bounds.width - sectionInset.left - sectionInset.right - contentInsets.left - contentInsets.right
    }

    // MARK: Overrides

    override func layoutAttributesForElementsInRect(rect: CGRect) -> [UICollectionViewLayoutAttributes]? {
        var attributes = super.layoutAttributesForElementsInRect(rect)
        if let attrs = attributes {
            attributes = updatedAttributes(attrs)
        }
        return attributes
    }

    override func layoutAttributesForItemAtIndexPath(indexPath: NSIndexPath) -> UICollectionViewLayoutAttributes? {
        var attributes = super.layoutAttributesForItemAtIndexPath(indexPath)
        if let attrs = attributes {
            attributes = updatedAttributes(attrs)
        }
        return attributes
    }

    // MARK: Private

    private func updatedAttributes(attributes: [UICollectionViewLayoutAttributes]) -> [UICollectionViewLayoutAttributes] {
        return attributes.map({ updatedAttributes($0) })
    }

    private func updatedAttributes(originalAttributes: UICollectionViewLayoutAttributes) -> UICollectionViewLayoutAttributes {
        let attributes = originalAttributes.copy() as! UICollectionViewLayoutAttributes
        attributes.frame.size.width = fullWidth()
        attributes.frame.origin.x = 0
        return attributes
    }
}

Update (7th-Feb-2016): for this to work reliably one extra addition is needed

In the UICollectionViewDelegateFlowLayout we need to also specify the width

    func collectionView(collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAtIndexPath indexPath: NSIndexPath) -> CGSize
    {
        return CGSize(width: fullWidthLayout.fullWidth(), height:60)
    }

Option 5: Flow Layout Subclass - modifying item size

Update (7th-Feb-2016): Revisiting this post, I have found a simpler and more reliable solution

Looking back at Option 4 that solution now no longer seems as elegant as it could be. Following the same approach with a flow layout subclass, a simpler solution can be devised. We can update the itemSize’s width property on any bounds change and in prepareLayout to make it work on first load.

class FullWidthCellsFlowLayout : UICollectionViewFlowLayout {

    func fullWidth(forBounds bounds:CGRect) -> CGFloat {

        let contentInsets = self.collectionView!.contentInset

        return bounds.width - sectionInset.left - sectionInset.right - contentInsets.left - contentInsets.right
    }

    // MARK: Overrides

    override func prepareLayout() {
        itemSize.width = fullWidth(forBounds: collectionView!.bounds)
        super.prepareLayout()
    }

    override func shouldInvalidateLayoutForBoundsChange(newBounds: CGRect) -> Bool {
        if !CGSizeEqualToSize(newBounds.size, collectionView!.bounds.size) {
            itemSize.width = fullWidth(forBounds: newBounds)
            return true
        }
        return false
    }
}

I have also added a demo project on github to showcase this solution.

UITableView Moves and Updates

Sun, 26 Apr 2015 10:00:00 +0000

Overview

This week I have come across an interesting limitation of UITableView

Suppose you have a list:

A: 10:00 AM
B: 09:00 AM
C: 08:00 AM

Where this list updates over time and the goal is to have the most recent item at the very top. Let’s say C now updates and as such it needs to be moved to the top and get a new timestamp

The desired final list is:

C: 11:00 AM
A: 10:00 AM
B: 09:00 AM

Two operations are needed :

Move index 2 to 0
Update index 0 (after the move)

Animating Changes

A quick thought would be to

func animateChanges()
{
    tableView.moveRowAtIndexPath(NSIndexPath(forRow: 2, inSection: 0), toIndexPath: NSIndexPath(forRow: 0, inSection: 0))
    tableView.reloadRowsAtIndexPaths([NSIndexPath(forRow: 0, inSection: 0)], withRowAnimation: .Automatic)
}

This will appear to work, however we will hit a road block the second we start working with bulk changes to animate all at once.

Bulk Changes

We can use tableView’s beginUpdates() and endUpdates() to perform batch updates

func animateChanges()
{
    tableView.beginUpdates()
    // ...
    tableView.moveRowAtIndexPath(NSIndexPath(forRow: 2, inSection: 0), toIndexPath: NSIndexPath(forRow: 0, inSection: 0))
    tableView.reloadRowsAtIndexPaths([NSIndexPath(forRow: 0, inSection: 0)], withRowAnimation: .Automatic)
    // ...
    tableView.endUpdates()
    
    // Results in Exception:
    //  Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Attempt to create two animations for cell'
}

This is when we hit the limitation I mentioned earlier, we’ll get an exception raised in this scenario

Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Attempt to create two animations for cell’

As the error states, we can’t set two animation on a single cell within one batch. That is effectively what ends up happening when we ask the tableView to move and reload the same cell.

The Workaround

One workaround would be perform updates after the batch (taking care to update the right cells!)

func animateChanges()
{
    tableView.beginUpdates()
    // ...
    tableView.moveRowAtIndexPath(NSIndexPath(forRow: 2, inSection: 0), toIndexPath: NSIndexPath(forRow: 0, inSection: 0))
    // ...
    tableView.endUpdates()
    
    tableView.reloadRowsAtIndexPaths([NSIndexPath(forRow: 0, inSection: 0)], withRowAnimation: .Automatic)
}

This will do the trick, but if you inspect the resulting animations closely you may notice a glitch. To make the glitch more noticeable, we can add another update, for example to the last cell, such that our operations are now:

Move index 2 to 0
Update index 0 (after the move)
Update index 2 (after the move)

func animateChanges()
{
    tableView.beginUpdates()
    // ...
    tableView.moveRowAtIndexPath(NSIndexPath(forRow: 2, inSection: 0), toIndexPath: NSIndexPath(forRow: 0, inSection: 0))
    // ...
    tableView.endUpdates()
    
    tableView.reloadRowsAtIndexPaths([NSIndexPath(forRow: 0, inSection: 0), NSIndexPath(forRow: 2, inSection: 0)], withRowAnimation: .Automatic)

    // Notice the resulting animation, no longer looks like smooth move
}

The animation no longer looks like the move of one cell, instead everything fades into its final destination. One can argue its no big deal, right? but if you’ve gone to the effort of making your table view animate its updates, surely you want it to look great too?

Defering Updates

One option I tested was to defer the update animations until the moves have completed (adapted from wtmoose/TLIndexPathTools and this stack overflow question). This works for the most part however the final outcome doesn’t look as smooth and infact the previous attempt with the glitch looks better.

func animateChanges()
{
    CATransaction.begin()
    CATransaction.setCompletionBlock {
         self.tableView.reloadRowsAtIndexPaths([NSIndexPath(forRow: 0, inSection: 0), NSIndexPath(forRow: 2, inSection: 0)], withRowAnimation: .Automatic)
    }

    tableView.beginUpdates()
    // ...
    tableView.moveRowAtIndexPath(NSIndexPath(forRow: 2, inSection: 0), toIndexPath: NSIndexPath(forRow: 0, inSection: 0))
    // ...
    tableView.endUpdates()
    
    CATransaction.commit()
}

The Solution

I carried on experimenting with options and variation on this and concluded with this solution which does require some additional legwork but produces the best results.

func animateChanges()
{
    tableView.beginUpdates()
    // ...
    tableView.moveRowAtIndexPath(NSIndexPath(forRow: 2, inSection: 0), toIndexPath: NSIndexPath(forRow: 0, inSection: 0))
    // ...
    tableView.endUpdates()
    
    tableView.beginUpdates()
    updateCellAtIndexPath(NSIndexPath(forRow: 0, inSection: 0))
    updateCellAtIndexPath(NSIndexPath(forRow: 2, inSection: 0))
    tableView.endUpdates()
}

func updateCellAtIndexPath(indexPath: NSIndexPath)
{
   var cell = tableView.cellForRowAtIndexPath(indexPath)
   cell.contentView.fadeTransition(0.3)
   configureCell(cell, atIndexPath:indexPath)
}

func configureCell(cell: UITableViewCell, atIndexPath indexPath: NSIndexPath)
{
   // ...
   cell.textLabel!.text = "Updated Text!"
   // ...
}

// MARK - UITableViewDataSource

override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as! UITableViewCell
    
    // to avoid duplicating code used to update cells
    configureCell(cell, atIndexPath:indexPath)
    return cell
}

// MARK - Extensions

// Taken from http://stackoverflow.com/a/27645516
extension UIView {    
    func fadeTransition(duration:CFTimeInterval) 
    {         
        let animation:CATransition = CATransition()         
        animation.timingFunction = CAMediaTimingFunction(name:kCAMediaTimingFunctionEaseInEaseOut)        
        animation.type = kCATransitionFade         
        animation.duration = duration         
        self.layer.addAnimation(animation, forKey: kCATransitionFade)     
    } 
}

What I’m doing here is avoiding the use of tableView’s reloadRowsAtIndexPaths method, and updating the cell content directly. Note for this to work, the assumption is the data model has already been changed ahead of the animations and the update action is applied to the cells using their new locations and not their original ones.

Here you are free to apply your own custom animations, however for a generic fade, we can leverage the CATransition animation. (Taken from this stack overflow post). Notice how we are applying this on the cell’s content view and not the entire cell, otherwise we end up with similar issues we saw when using reloadRowsAtIndexPaths.

That’s it! Happy Coding!

Command line Watch Kit builds

Tue, 14 Apr 2015 22:00:00 +0000

Update: Please read this newer blog post before following the steps here. While these steps were valid at the time of writing, the new post outlines a better alternative without using any custom steps that are likely to fail in the future.

Overview

The Apple Watch is here! and Apple is now accepting Watch Kit enabled Apps. Now if you happen to do your builds outside the comfort of the Xcode application, chances are you will run into some issues. Namely a binary rejection from iTunes Connect after what you may have thought was a successful upload with the following message:

Invalid WatchKit Support - The bundle contains an invalid implementation of WatchKit.

Here are the steps I followed to get a build successfully submitted (till review stage at least). Depening on your project configuration, some steps may or may not apply, for dealing with the issue above only you can jump straight to step 6

Full disclosure, I did not come up with the solutions myself, I am just collating my findings into a single location in hope it will help as I found most of the information scattered around the interwebs. A fair bit of these steps were adapted from WDUK’s gist.

Steps

Let’s assume we have an app called MyApp, with a Watch Kit Extension called WatchKitExtension and Watch Kit App called WatchKitApp.

1) Update Plists

First, you’ll need to update the Info.plist for the App & the Extension.

I usually use python for this, as it has a built in plistlib which is semantically easier to deal with than the command line alternative.

import plistlib

# Read Plists
myAppInfoPlist = plistlib.readPlist(“MyApp/Info.plist”)
watchKitExtensionInfoPlist =  plistlib.readPlist(“WatchKitExtension/Info.plist”)
watchKitAppInfoPlist = plistlib.readPlist(“WatchKitApp/Info.plist”)

# Update Watch Kit Extension Plist
watchKitExtensionInfoPlist[“NSExtension”][“NSExtensionAttributes”][“WKAppBundleIdentifier”] = watchKitAppInfoPlist[“CFBundleIdentifier”]
watchKitExtensionInfoPlist[“CFBundleVersion”] = myAppInfoPlist[“CFBundleVersion”]
WatchKitExtensionInfoPlist[“CFBundleShortVersionString”] = myAppInfoPlist[“CFBundleShortVersionString”]

# Update Watch Kit App Plist
watchKitAppInfoPlist[“WKCompanionAppBundleIdentifier”] = myAppInfoPlist[“CFBundleIdentifier”]
watchKitAppInfoPlist[“CFBundleVersion”] = myAppInfoPlist[“CFBundleVersion”]
watchKitAppInfoPlist[“CFBundleShortVersionString”] = myAppInfoPlist[“CFBundleShortVersionString”]

# Save the Plists
plistlib.writePlist(myAppInfoPlist, “MyApp/Info.plist”)
plistlib.writePlist(watchKitExtensionInfoPlist, “WatchKitExtension/Info.plist”)
plistlib.writePlist(watchKitAppInfoPlist, “WatchKitApp/Info.plist”)

2) Build

Issue your usual xcodebuild command

for example:

xcrun xcodebuild -sdk iphoneos -config "Release"

This should spit out MyApp.app in build/Release-iphoneos/

3) Embed Provisioning Profiles

You’ll need to get a hold of provisioning profiles for the Watch App & Extension if you are not using a wildcard profile.

cp watchkitapp.mobileprovision MyApp.app/WatchKitExtension.appex/WatchKitApp.app/embedded.mobileprovision
cp watchkitextension.mobileprovision MyApp.app/WatchKitExtension.appex/embedded.mobileprovision
cp myapp.mobileprovision MyApp.app/embedded.mobileprovision

4) Get a hold of the expanded entitlements

The archive expanded entitlements will be needed for the signing step next, to get a copy of them ready you can run:

xcrun codesign -d --entitlements :- MyApp.app/WatchKitExtension.appex/WatchKitApp.app 2>/dev/null > watchkitapp.xcent
xcrun codesign -d --entitlements :- MyApp.app/WatchKitExtension.appex 2>/dev/null > watchkitextension.xcent
xcrun codesign -d --entitlements :- MyApp.app 2>/dev/null > myapp.xcent

Edit:Thanks to Norod for the clarification on this step*.

5) Sign

As we now have modified the contents of the packages by embedding the missing provisioning profiles, we will need to re-sign them all. Note that the order of the following steps matter! This is due to the nature of the hierarchy these packages are in.

MyApp.app
- Plugins
  - WatchKitExtension.appex
    - WatchKitApp.app
    - …

# Order is important!!

# WatchKit App
rm -rf MyApp.app/Plugins/MyWatchKitExtension.appex/MyWatchKitApp.app/_CodeSignature
xcrun codesign -f -s "Certificate Name" -- entitlements watchkitapp.xcent MyApp.app/Plugins/MyWatchKitExtension.appex/MyWatchKitApp.app

# WatchKit Extension
rm -rf MyApp.app/Plugins/MyWatchKitExtension.appex/_CodeSignature
xcrun codesign -f -s "Certificate Name" -- entitlements watchkitextension.xcent MyApp.app/Plugins/MyWatchKitExtension.appex

# Main App
rm -rf MyApp.app/_CodeSignature
xcrun codesign -f -s "Certificate Name" -- entitlements myapp.xcent MyApp.app

6) Package

The usual way involves running

xcrun -sdk iphoneos PackageApplication MyApp.app -o MyApp.ipa

What this does is make an .ipa (which if unzipped) will have the following structure

Payload
- MyApp.app

However upon uploading to iTunes Connect the binary will end up getting rejected due to invalid Watch Kit Support. Turns out the command line tools don’t take care of all the necessary steps required for Watch Kit enabled apps. The missing step in this case is the requirement for a top level folder called WatchKitSupport with a Watch Kit Binary WK. See this devfroums post for details.

Payload
- MyApp.app
WatchKitSupport
- WK

To do this you need to run the following few lines

# Extract the contents of the ipa
unzip MyApp.ipa

# Include WatchKitSupport
mkdir WatchKitSupport
cp "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/Library/Application\ Support/WatchKit/WK" WatchKitSupport/WK

# Repackage
zip -qr MyAppWithWatchKit.ipa Payload WatchKitSupport

That will create your new .ipa with WatchKitSupport

Streamlining the packaging

Now here is my contribution, the last step was a little too messy for my liking and was harder to integrate into our existing scripts and as such I wrote a simple packager class in python.

# https://github.com/mxpr/ios-build-utils
from utils.packager import Packager

def package():

    ipa = Packager("MyAppWithWatchKit.ipa")
    ipa.add("MyApp.app","Payload/MyApp.app")
    ipa.add("/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/Library/Application\ Support/WatchKit/WK", "WatchKitSupport/WK")
    
    ipa.package()

Final Thoughts

I really do hope the command line tools get some more attention in upcoming releases as the tips and tricks only work around the issues and generally get outdated or invalid fairly soon.

In any case, hope this helps and happy building!

Debugging gesture recognizers

Thu, 01 Jan 2015 14:30:00 +0000

Recently I was trying to figure out why pan gestures weren’t being picked up. The case I was dealing with was a collection view that did not respond to swipe gestures near the edges of the screen.

After consulting with a colleague and looking up some documentation based on his advice, I found the conflict was partially due to the interativePopGestureRecognizer that lives within the UINavigationController. For background, this gesture recogniser was introduced in iOS 7 to allow swiping back to previous view controllers in the navigation controller’s stack.

Disabling it helped solve some of the conflicts.

self.navigationController.interactivePopGestureRecognizer.enabled = NO;

But doing a quick google would have told you that, the reason for this post is another trick I picked up along the way. I wanted to see if there was a way to get a list of gesture recognizers that were conflicting.

The way to do that is to register as a delegate to any of the gesture recognizers that are part of the conflict and implement the following method.

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer
shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer
{
    NSLog(@"Gesture Recognizer 1 = %@", gestureRecognizer);
    NSLog(@"Gesture Recognizer 2 = %@", otherGestureRecognizer);
    return YES;
}

This method will let you know exactly which gesture recognizers are being activated. One challenge with this was that the only gesture recognizer I knew about was the pan gesture recognizer on the collection view, but unfortunately attempting re-assign the pan gesture recognizer on a collection view will result with an assertion failure

*** 
Terminating app due to uncaught exception 'NSInvalidArgumentException', 
reason: 'UIScrollView's built-in pan gesture recognizer must have its scroll view as its delegate.'
***

The way I got this to work without too much hackery was to simply add another gesture recognizer to the edges - UIScreenEdgePanGestureRecognizer was perfect for this.

UIScreenEdgePanGestureRecognizer *gr = [[UIScreenEdgePanGestureRecognizer alloc] initWithTarget:self action:@selector(didSwipe:)];
    gr.delegate = self;
    gr.edges = UIRectEdgeLeft | UIRectEdgeRight;
    [self.view addGestureRecognizer:gr];

2014-12-29 17:08:27.707 TestProject[1678:34518] Gesture Recognizer 1 = UIScreenEdgePanGestureRecognizer: 0x7f9789d7fae0; state = Failed; delaysTouchesBegan = YES; view = UIView 0x7f9789cbb5f0; target= (action=didSwipe:, target=TestViewController 0x7f9789d96c50)
2014-12-29 17:08:27.707 TestProject[1678:34518] Gesture Recognizer 2 = UIPanGestureRecognizer: 0x7f9789c8e610; state = Began; view = UILayoutContainerView 0x7f9789c7c0c0; target= (action=_swipe:, target=UIPopoverController 0x7f9789c8b8d0)

And there you have it, a quick way to check out which gesture recognisers are causing you grief!

My WWDC Experience

Sun, 28 Jul 2013 20:00:00 +0000

Overview

This year was the first time I got the chance to go attend WWDC in person as opposed to watching the videos like all the other years … and it was awesome!

A bit late, but wanted to share some of my thoughts on my WWDC experience as it unfolded day to day. I’m afraid I won’t be able to share much of the technical details as I would be breaking the NDA every developer signs.

My Schedule

Saturday

Flying in from London, I planned to get there for the Saturday evening so I get a day to settle in and adjust to the new timezone in preparation for Sunday morning’s registration session. I had two main goals for the day, the first was locating the Moscone Center so I know the best route to get there, and the second arguable more important one was getting a sim card with a data plan (data roaming charges are not pleasant!).

The rest of the day was spent wondering about exploring the areas surrounding the hotel and trying to stay awake to a decent time to get my body clock in sync with the local timezone.

Sunday

I was travelling with a few colleagues, so we met up in the morning for the registration to get our WWDC badges and jackets.

Afterwards it was time to tour San Francisco! One of my colleagues rented a car which made the touring much more convienient as it meant we were able to get to places public transport wouldn’t have easily got us to such as the Golden Gate bridge or the Twin peaks (when it’s foggy that place looks like a typical scene out of a horror film).

No post about San Francisco is complete without a photo of the Golden Gate Bridge…

To be honest, I found the Bay Bridge to be much more impressive!

Having a car did mean we were able to go to the Apple Campus (One Infinite Loop) in Cupertino to buy some souvenirs and goodies from the Campus Store. We even had some time to drop by the Facebook office and the the Google campus on the way back.

Monday (Keynote Day):

After numerous discussions the previous day, we all agreed to queue at 5:30 AM, not crazy early, but not too late either.

And so Monday began bright and early. It was the first time I got acquainted with the queuing culture on such a large scale. Time flew by much quicker than I thought it would. There was a surprising number of free giveaways handed out to everyone queuing which included drinks and snacks (I found the coffee to be the most valuable giveaway).

They started letting people into the centre at around 7, where we queued over and over again a few times before we finally made into Persidio - the main hall where the keynote was taking place. It was such an amazing experience being part of the crowd in the hall watching the keynote and witnessing the announcements first hand as they unfolded.

The rest of the week

The rest of the week was spent attending as many sessions as I could and queuing to get into these sessions (I don’t believe I’ve ever queued as much before in my life).

In addition to the technical sessions, there were lunchtime sessions where guest speakers from industry were invited to talk about their professions and what motivated them to get to where they are now. Some of these sessions were really interesting and the food provided in the lunch boxes was surprisingly good too.

Evenings were kept occupied with a number of parties and social events (This page had a list of the events). These ranged from quizzes, networking sessions, lectures, to full blown parties and concerts. Two highlights would be Wednesday night’s Crittercism party which was awesome! and Thursday’s Bash event that was arranged by Apple which had Vampire Weekend playing live on stage in Yerba Buena Gardens!

Some Tips

For anyone reading this who plans on going next year, here are some tips:

I found the T-Mobile $3 a day deal ideal for this trip as it didn’t require a contract and it provided unlimited texts, minutes and data (the first 200MB on 4G/3G speeds and the rest were on 2G - but even with my heavy usage it was plenty and I never exceeded the higher speed allowances).

During the keynote - just switch your data off, there is just way too many people in one spot, you won’t get a data connection (via your provider or the WiFi), and you’ll battery will drain away in record time.

Speaking of battery, invest in a battery extender - they are a life saver especially if you rely on your mobile to navigate around and it’s your first time in San Francisco.

If you plan on touring, rent a car! To get to some of the popular destinations, public transport is a bit tricky (I haven’t personally tried, but it didn’t seem like there were any buses or trains going there).

Go to the sessions you want to attend, don’t worry about the ones you miss because you can watch them online. These videos were being posted online much quicker than they have done in the past.

If you’ve got a MacBook Air, Invest in a Thunderbolt or USB ethernet adapter. Once the new iOS and Mac OS previews get announced, you can get them zapped down onto your Mac in no time via the ethernet cables available at the desks on the lower ground floor (near the labs). Don’t bother trying to download it over WiFi - it just won’t work.

Final Thoughts

The sessions at WWDC were very educational, It felt like I was back at university for a week long course on all things Apple! I met a lot of interesting people some of whom worked on some of my favourite apps!

San Francisco is such a nice city and has just the right weather that time of year, sunny and warm (not hot) with a cold breeze. I would highly recommend a visit up Coit tower to get the best panoramic view of the city.

Xcode Tips : Organising your code

Sun, 02 Jun 2013 18:30:00 +0000

Using Pragma Mark

Xcode is by far the best IDE I’ve ever used for development and one of my favourite features is the ability to get the source code within a file organised into categories using #pragma mark - Category.

Why?

It makes it easier to read and navigate through your own source code.
If you and your team agree on a particular convention to follow, it will also make it easier for you to navigate through code written by others.
When organising your code, you will end up grouping related methods together so they fit the category they are listed under. This will allow you to easily isolate these method groups into separate classes if required at a later time.

Grouping

I usually make a category for each of the following items, but it’s really up to your personal preference as to what and how you choose these category groups. The idea here is to just group related methods together to keep the code easy to follow.

Constants
Init / Setup Methods
View Life-cycle (in UIViewController for example)
Overrides (Subclass method overrides)
Public Methods
Private Methods
Protocol Methods
Class Methods

Here’s what it looks like

From the jump bar you can view all the categories and methods within a file.

Code Snippets Shortcut

I found having to type in #p - then wait for autocomple to fill in the rest of pragma, and then typing mark - my title to be a bit mundane (what can I say - I’m a bit lazy). So I’ve made my own code snippet to speed up the process.

Creating a code snippet

1) First expand the utilities sidebar

2) Open the Code Snippet tab at the bottom

3) Now somewhere in your source file type in #pragma mark - <#title#>

4) Select the entire line and drag it to the code snippet area in the sidebar. If that works you should see a popup similar to the one below.

5) Fill in an appropriate title and summary

6) The completion shortcut is what will be used to trigger the snippet from the autocomplete menu so choose something short that does not conflict with any of your other snippets.

7) For the completion scopes you want to add

Top Level
Class implementation

8) Click Done and your Done!

Seeing your shortcut in action

In your source file start typing in your shortcut and you should see your new snippet appear in the auto complete menu.

On selecting it or pressing the return key, #pragma mark - will be filled in and the cursor will be in right position ready to type in the category title.

Additional Notes

So it seems there is a bug with Xcode which prevents the first pragma mark from appearing in the list if your implementation or interface does not make use of the braces (see link). The work around is to simply add the braces.

iOS Tips: Debugging UI

Sat, 30 Mar 2013 16:00:00 +0000

So you’ve been working on some fancy UI for your app and you’ve just ran into a little niggle. Something doesn’t look quite right, not in the right place or you just can’t see it anywhere!

Here are two techniques I regularly use to troubleshoot any view related issues.

1) Setting a Border

This may sound basic, but it is tremendously useful. Having borders around the views helps visualise their boundaries. This is especially useful when dealing with images or icons with paddings, this can help you figure out why an icon has more space that it should have.

Is it the icon itself? or maybe it is the layout logic used for that icon?

I find including the following category to my .pch file really handy as it saves me from including QuartzCore, setting a border width and color on every view I want to outline, only to remember to remove them all once I’m done.

UIView+Debugging.h

@interface UIView (Debugging)

- (void)setBorderColor:(UIColor *)color;
- (void)setBorderColorOnSubviews:(UIColor *)color;
- (void)setRandomBorderColor;
- (void)setRandomBorderColorsOnSubviews;

@end

UIView+Debugging.m

#import "UIView+Debugging.h"
#import QuartzCore/QuartzCore.h

@implementation UIView (Debugging)

- (void)setBorderColor:(UIColor *)color
{
    self.layer.borderWidth = 1.0f;
    self.layer.borderColor = color.CGColor;
}

- (void)setBorderColorOnSubviews:(UIColor *)color
{
    for (UIView *subview in self.subviews)
    {
        [subview setBorderColor:color];
    }
}

- (void)setRandomBorderColor
{
    [self setBorderColor:[self randomColorFromSet]];
}

- (void)setRandomBorderColorsOnSubviews
{
    for (UIView *subview in self.subviews)
    {
        [subview setBorderColor:[self randomColorFromSet]];
    }
}

- (UIColor *)randomColorFromSet
{
    NSArray *colors = @[ [UIColor blackColor],
                         [UIColor darkGrayColor],
                         [UIColor lightGrayColor],
                         [UIColor grayColor],
                         [UIColor redColor],
                         [UIColor greenColor],
                         [UIColor blueColor],
                         [UIColor cyanColor],
                         [UIColor yellowColor],
                         [UIColor magentaColor],
                         [UIColor orangeColor],
                         [UIColor purpleColor],
                         [UIColor brownColor]];
    
    NSUInteger index = ( arc4random() % colors.count );
    
    return colors[index];
}

@end

And to use it simply:

[myView setRandomBorderColor];

2) recursiveDescription

recursiveDescription is a hidden method that can be used from the debugger (as per this link). This will print out the full view hierarchy starting from the view this method is called on.Simply place a breakpoint at the end of viewDidLoad or viewWillAppear of a UIViewController for example, and type in the following command in the debugger.

po [[self view] recursiveDescription]

iOS Tips: Don't use 'description'

Sun, 18 Nov 2012 12:00:00 +0000

What is wrong with the following piece of code ?

@interface MyArticleClass : NSObject

@property (nonatomic, strong) NSString *title;
@property (nonatomic, strong) NSString *description;

@end

The title of this post has already given this away. We can’t use description as a property name and here’s why.

NSObject already has a description method which by default returns a string with the object name and memory address. Subclasses can override this method to return a more descriptive string. This can help print out useful information to aid debugging when using NSLog or the po in the debug console.

Having a description property on the subclass MyArticleClass in the example above is just asking for trouble. The code will have no issues compiling, it will probably work fine until you use it with core data. See this stackoverflow link. The general rule is to avoid using property names of methods or properties declared in parent classes unless its specifically to override them.

That being said, do make use of description to aid your debugging

Interface

@interface MyArticleClass : NSObject

@property (nonatomic, strong) NSString *title;
@property (nonatomic, strong) NSString *articleDescription;

@end

Implementation

@implementation MyArticleClass

- (NSString *)description
{
    return [NSString stringWithFormat:@"MyArticleClass: %p %@ - %@",self, self.title, self.articleDescription];
}

@end

Usage

MyArticleClass *article = [[MyArticleClass alloc] init];
article.title = @"iOS Tips";
article.articleDescription = @"The first iOS tips post!"; 
NSLog(@" %@ ", article);

Result

MyArticleClass: 0x74d5920 iOS Tips - The first iOS tips post!