kentios

The Right Unit Tests

2020-01-16T00:00:00+00:00

This isn’t a post to teach the basics of unit testing on iOS. It’s designed for people who already write unit tests, but aren’t sure if they’re doing it right.

Unit testing can get messy
(photo by Alice Dietrich)

Just like code, tests should be clear, concise and simple for everyone to understand. It should require no effort to understand a test, even for someone who is not the author, and does not have the full context.

This post is all about getting back to fundamentals and understanding what’s most valuable for unit tests.

Jump to the Summary, or read this article on Medium

Tools

All The Tools!
(photo by Cesar Carlevarino Aragon)

There are some great tools for unit testing iOS in Swift (for example Quick/Nimble, SwiftyMocky, Snapshot-testing). I encourage you to use them! However, even with great tools, developers can still write bad tests. As an example, Quick (or any BDD framework) improves test naming & readability, but it’s important to first understand why better naming is important. To explain these fundamental ideas, let’s just talk about plain vanilla XCTests.

FIRST Things First

If you’re not familiar with it, please take a minute to read about the FIRST principle.

Here’s a short summary for context:

Fast: Speedy tests are run more often
Isolated: One test must never be able to break another test
Repeatable: A test must always return exactly the same result
Self-Validating: A clear name and single assertion identifies point of failure
Thorough: About confidence, not percentages

FIRST is a terrific set of values for tests. However, it’s a general testing principle, not a specific set of tips.

Here are practical tips to improve the quality of your tests, taking FIRST into account. The most important tips are presented first.

1. K.I.S.S. And Short, Stupid

Keep your tests short.

Really short.

A long test is a good indicator of smelly code. That is, testability and code complexity are intertwined. If your code is complicated, it’s likely that it will become a source of bugs. The same goes for tests - a complex test is less likely to catch a bug. Thinking “hmm, this code is difficult to test” should be reason enough to refactor your code. If you, the author, find it difficult to test your own code now, think about someone wanting to refactor this code in 6 months time.

When tests are complex or long, it is almost certain that code can be further improved.

Try to keep your tests to 10 logical statements or fewer

(choose any number that increases your test quality over time)

2. Test Quality ≠ Code Quality

It’s important to remember that good tests have different characteristics to code. A former colleague spent countless PR reviews teaching me that shared test utilities (mocks, convenience factories, comparators) are dangerous. As developers, we learn the DRY principle at birth. But, as FIRST shows, isolation is actually a more important quality for tests.

We don't always need things to be DRY
(photo by Erik Witsoe)

Shared test utilities and test data inevitably become as complex as the code itself when you handle every possible input combination. Recreating a utility for a single purpose in each test means the code is simpler and completely independent from any other test.

Note, there is a difference between a shared utility and a function shared by similar tests within the same test class. Here the scope is localized and the usage specific, not generic.

It’s OK to repeat test utilities & data. Above all, we want to avoid breaking Test A when someone modifies a shared utility so that it works with Test B.

3. Test Your Tests

A common pitfall is to write tests that return false positives. It is necessary to satisfy two things:

Your tests pass when code is correct
Your tests fail when code is incorrect

This sounds so obvious, but so many times I’ve broken code only to find an existing unit test still passes. 😢

TDD is an obvious antidote to this problem. Consider that tests are the specifications of what your code must do. It seems obvious that you would write the specifications before you implement them. In this way you will see the failing test when code is incomplete, and the passing test only when code is complete. If your test passes before you’ve finished implementing the functionality, it will likely return false positives.

You should always run a test twice, once to see it pass, and once to see it fail.

4. Test Naming

Names are important
(photo by chuttersnap)

Ideally, when a test fails, the name of the test should be all a developer needs to pinpoint the problem in code. Compare two different test names for the same test:

testMyMethodResponses()
test_myMethod_withFriday_returnsSmile()

If testMyMethodResponses() fails, we know that some myMethod responses are not correct. We will need to analyse the test and the failing assert before we can start debugging myMethod.

If test_myMethod_withFriday_returnsSmile() fails, the test name alone tells us:

The method being tested: myMethod
The input being tested: Friday
The expected output: Smile

Given a test name, we should be able to determine which method is being tested, in which state, and what is the expected output/behaviour.

5. Test Coverage

Think about the term test coverage literally. Not with percentages, but imagine that your tests are little green ants swarming all over your class.

That's one test...
(photo by Vlad Tchompalov)

As soon as one of the ants finds something wrong with the class, it will turn red. We want to write lots of small, independent tests that act like status lights, quickly identifying precisely which part of our functionality is broken.

If all the ants were to turn red at the same time, they would not help pinpoint which functionality is broken.

In an ideal world, a single bug will cause one (and only one) test to fail, giving us precise information about where and how the bug occurs.

6. Code Safety

If we continue the ant analogy, the sweetest parts of each class should have the most ants (🍰 ❤️ 🐜🐜🐜). That is, you should focus your testing on methods that are more safety critical.

What does safety critical code mean? Focus on testing the parts of your class that could:

Ireversibly lose user data/progress
Enter an unrecoverable state
Compromise user’s private data/security
Affect a user’s wallet (banking/buying online)

Prioritise writing tests for safety critical code.

7. Fail Clearly

When causing a newly written test to fail, it’s important to think how that failure will look to a new pair of eyes. Consider a decodable struct with three variables that are all optional strings. It’s tempting, and quite simple to write one test:

func test_decodes_fullValidJSON_allFieldsDecoded() {
    let json = """
                {
                  "string1": "This is string1",
                  "string2": "This is string2",
                  "string3": "This is string3"
                }
               """
    let expected = MyStruct(string1: "This is string1",
                            string2: "This is string2",
                            string3: "This is string3")

    guard let jsonData = json.data(using: .utf8) else {
        XCTFail("Invalid JSON test data")
        return
    }
    do {
        let decoded = try JSONDecoder().decode(MyStruct.self, from: jsonData)
        XCTAssertEqual(decoded, expected)
    } catch {
        XCTFail("Could not decode JSON into MyStruct")
    }
}

The test name is clear and the test is well isolated. However, what happens when the test fails?

XCTAssertEqual failed: ("MyStruct(string1: Optional("This is string1."), string2: Optional("This is
string2."), string3: Optional("This is string3."))") is not equal to ("MyStruct(string1: Optional("
This is string1,"), string2: Optional("This is string2."), string3: Optional("This is string3."))")

This is a trivial example but I’ve seen tests where the failure takes up half the screen, and requires opening a diff tool to figure out which property failed the equality test.

The solution is to break this test up into 3 smaller tests, one per field. This would look like:

func test_decodes_string1() {
    let json = """
                {
                  "string1": "This is string1.",
                }
               """
    let expected = MyStruct(string1: "This is string1,")

    guard let jsonData = json.data(using: .utf8) else {
        XCTFail("Invalid JSON test data")
        return
    }
    do {
        let decoded = try JSONDecoder().decode(MyStruct.self, from: jsonData)
        XCTAssertEqual(decoded.string1, expected.string1)
    } catch {
        XCTFail("Could not decode JSON into MyStruct")
    }
}

...

func test_decodes_string3() {
  ...
}

And the corresponding assertion failure:

XCTAssertEqual failed: ("Optional("This is string1.")") is not
equal to ("Optional("This is string1,")") -

Ensure that test failures are trivial to understand. It’s better to write lots of simple tests than one complex test.

Summary

Writing tests is not about quantity, it’s about quality. Essentially we are writing documentation, or specifications, for our future selves;

“Here are some examples of how my class should work. If you refactor, or add features to the class, these examples should still pass. If the class functionality changes, some of these examples should break.”

Quality tests save you time
(photo by Pierre Bamin)

When a developer treats their tests as a second class citizen, their tests will be second class. It’s that simple. You should be as proud of your tests as your production code. Put the time in to make your unit tests great. Just as great code is easy to extend, great tests are easy to augment.

Try to keep your tests to 10 logical statements or fewer!
It’s OK to repeat test utilities & data. Above all, we want to avoid breaking Test A when someone modifies a shared utility for Test B
You should always run a test twice, once to see it pass, and once to see it fail
Given a test name, we should be able to determine which method is being tested, in which state, and what is the expected output/behaviour
In an ideal world, a single bug will cause one (and only one) test to fail, giving us precise information about where and how the bug occurs
Prioritise writing tests for safety critical code
Ensure that test failures are trivial to understand. It’s better to write lots of simple tests than one complex test
After 6 months, is it trivial to understand how your test works?
If the answer is no, you’ve written a low quality test. Try again! 😄

Comments? Contact me on Twitter

A special thanks to my former colleague, friend and testing guru Rich Moult for teaching me so much about unit testing. 🙏

A More Diverse iOS Community

2019-12-13T00:00:00+00:00

I wrote a blog post for InsideN26 magazine: A More Diverse iOS Community.
It’s about our efforts at N26 towards increasing gender diversity within the Berlin iOS community.

Der Berliner Jäger \ The Berlin Hunter

2018-08-19T00:00:00+00:00

This is a 3 part series about my recent job hunting experience in Berlin. I’ve definitely lead more interviews than I’ve taken, so these tips come from both sides of the interview panel.

My Hunting Tips

Here’s a summary of my iOS job hunting advice:

Update your resume and trim any outdated (less relevant) experience
In your cover letter, write enthusastically about why you want to work at the company
Over prepare for interviews
- Study up on iOS basics - iOS Interview Questions
- Complete simple coding exercises - HackerRank
- Practice long answer* questions out loud
  1. Tell us about your previous work experience
  2. Why should we hire you?
  3. Why do you want to work here?
  4. Tell us about a difficult interaction with a colleage
  5. Describe a challenging engineering problem you resolved
Practice describing your career experience out loud, as a story. Ensure this is a compelling story that concludes with the company
Revise your cover letter and resume before each interview - this will be your interviewer’s primary reference
Reiterate your genuine enthusiasm at each step of the process
Plan questions that you want to ask the interviewers
- If you genuinely have none, explain why, rather than flounder for one

Continue reading: Part 1 - Working in Berlin

Comments? Tweet me.

Embedding a Debug Only Framework

2018-05-01T00:00:00+00:00

When using fastlane/Snapshot & SimulatorStatusMagic (which are both ace!!) to produce screenshots, how should SimulatorStatusMagic be added to a project?

Just Use a Dependency Manager

Alright - that’s the easy way out. Continue reading if your project is not using CocoaPods or Carthage.

Just Throw It In

The SimulatorStatusMagic installation instructions outline how to build the framework and add it to your project without a dependency manager.

Embedding the build works fine for both Debug and Release builds. However, SimulatorStatusMagic cannot be submitted to Apple in an app binary.

The framework does not contain bitcode. I unwisely tried to add bitcode - let’s not talk about that anymore.
The framework contains non-public APIs which are detected by Apple’s automatic code scan.

Alas, there is no built-in Xcode mechanism for linking a framework against Debug builds, while excluding Release builds.

Just Embed It For Debug

Update: I added to the official installation instructions on GitHub to describe this process.

Custom Run Script build phases allow for the embedding of a framework under specified conditions, such as Debug configuration only.

The Framework must be added to the Framework Search Paths so it can be found at linking time. For example, if the framework is inside a folder ThirdPartyFrameworks, then set:

Framework Search Paths->Debug: $(SRCROOT)/ThirdPartyFrameworks/

I created a script that embeds a framework only if the build configuration is set to Debug. Download it here with full usage instructions. Hopefully, It Just Works™.

The script solution was adapted from this SO post which shows how to embed framework for certain architectures.

Just Embed It In the UITest Target

The above solution allows SDStatusBarManager to be called from within the main app target. When using fastlane/Snapshot, the screenshots are captured from a UITest target.

Is it possible to use SimulatorStatusMagic from the UITest target and keep the app target clean from ‘Debug frameworks’?

Yep.

But it’s a little tricky. There are three players involved when running UITests; the UITest bundle, the app itself, and an Apple generated test runner app.

The UITest Bundle

The test bundle doesn’t actually run - it merely contains the tests for the test runner to perform on the app itself.

However, it does need to be compiled against the framework, so update the UITest target build settings: Framework Search Paths: $(SRCROOT)/ThirdPartyFrameworks/

The App Itself

The app itself does not require the framework to compile. It does require the framework to run, because it’s performing a UITest which calls SimulatorStatusMagic.

In the UITest target, add a custom Run Script build phase to embed the framework into the app (do insert the red underlined name):

The Generated Test Runner

The test runner also requires the framework to run.

In the UITest target, add a custom Run Script built phase to embed the framework in the test runner (do insert the red underlined name):

Comments? Tweet me.

Big Fat Initializers

2017-03-01T00:00:00+00:00

A dicsussion about whether you really want to build that big, fat initializer.

Ugh, gross. Big, fat, bloated inits. They’re about as cool as these dorky tab bars. Just give me a fat hamburger menu and a skinny init. With a side of customisable properties please. Let me configure my object in the state I want, and ignore the properties that I don’t care about. It’s 2011, I think I know what I’m doing…

<cough….ahem>

I Like Big Inits, And I Can Not Lie

Turns out that I find big, fat initializers way sexier in 2017 than I did in 2011.

Unthinkingly, I used the term ‘big, fat inits’ in a recent email thread. I was explaining that a detailed init could provide us with a lot of benefits, where the only side effect is having to create a ‘big, fat initializer’. I wish I hadn’t made this sound like a bad thing. I wish I’d used the term ‘deterministic, reliable initializer’ instead.

The more I write in Swift and think about value types and immutability, the more I appreciate injecting state at initialization. Make objects as immutable as possible and create objects that behave in fewer, more deterministic ways. The smaller surface area that your state has, the less likely that two instances of the same class can perform in unexpected ways.

How Big Is Too Big?

If your initializer really is getting too big, there are a couple of solutions.

One symption of big initializers is too many responsibilities. If your object is trying to do many things, it will likely require many dependencies to be injected. Think of ways to cut back your objects responsibilities. Could the responsibilities be split amongst multiple objects? Is there a design pattern that could improve your architecture?

If your object’s initializer is large because of many related state variables, consider creating a container class. In Swift this would be a value type - an immutable collection of properties that are simpler to pass around as a group. Do not use a dictionary - I guarantee someone will mistype one of your carefully named keys.

Init Got Back!

In summary, some advantages to using a deterministic, reliable initializer:

Immutability
Move towards immutable objects (the power of value types in swift) so that an object will behave in a well defined way for it’s entire lifetime.
Clear interface
The init shows which parameters (variables or dependencies) are required to make your object function correctly. Ideally, tend towards nonnull parameters.
Resist Multiple Responsibilities
Declaring all dependencies/state in one place makes it easier to identify a class that is taking on too many responsibilities.

And finally, the disadvantages:

Can’t Think Of Any
Stop supporting countless states, with countless properties, with countless bugs.

Want to talk about big, fat initializers? Tweet me.

PS. We have enough real world problems in 2017, please stop using hamburger menus.

Turn Me On Turn Me Off

2017-02-07T00:00:00+00:00

General advice for when and how to hide features behind a toggle.

In an ideal world every feature we write is bite sized and shippable. When development is complete, we get our little featureling a ticket on the next release train and we move on. We are content that our hard work will soon be in the hands of happy users.

Alas, the real world is not ideal. There are epics and rewrites and features with creepin scopes. There are releases that simply must go out and cannot wait for all features to be completed. At this point there are two common options:

a long lived feature (or epic) branch
a toggle that enables the feature

In my experience long lived feature branches tend to get muddy. Someone adds a terrific utility that everyone wants on develop and after a cherry pick or two our branches become entangled.

A toggle makes life simpler. We can merge everything onto develop and share the benefits. The risk is that features are not properly toggled and incomplete work slips into the hands of our users.

Toggle Time

How can we make sure that toggles are safe and effective? Here are some tips.

Aim for one toggle
A toggle that enables/disables all unfinished features reduces possible test states. Wait did you test with feature A on, but feature B off?
Make the toggle OFF by default
Toggling unfinished features on should always be a conscious act.
Disable the toggle in release builds
Use #ifdef DEBUG or your own compiler flag so that the toggle is not even compiled into a release.
Control the toggle from a single point
A well architected toggle should enable/disable a feature as early as possible so that code is not riddled with if (featureEnabled) statements.
Don’t let the toggle become part of the furniture
Make the toggle control stand out!! Make it hurt your eyeballs!!
If the toggle is hidden under four layers of submenus*, or nestled in amongst regular controls, it may sneak onto that release train unnoticed.
Backup the toggle with a remote kill-switch
The above points all relate to development toggles.
Add an extra layer of security by adding a remote toggle that can disable or enable a feature without changing the code.

*If your app has four layers of submenus, you have bigger problems than toggles…

Remote Toggling

A remote toggle can be a value returned in a server response, eg `supportsFeatureX, or something enabled using an A/B testing tool. These remote toggles allow us to perform a staged roll out, or roll back a feature that is not working as expected out in the wild.

A development toggle and a remote toggle can work well together. Consider the point in the code where the remote toggle is introduced. For a server response, this is likely the parsing code. For an A/B tool this is likely some kind of if statement. Use this point for the development toggle also.

Think of the development toggle as a hack that allows us to force or circumvent the remote toggle:

When the development toggle is disabled (or removed), the remote toggle is solely responsible for enabling the new feature
When the development toggle is enabled, the remote toggle is ignored, and the new feature is enabled

Feeling passionate about toggles? Tweet me.

Protocol Extensions - The Bad, the Good and the Ugly

2016-08-15T00:00:00+00:00

An experiment with protocol extensions that goes frustratingly wrong.

Spoilers

The Ugly solution is the best.
Protocol extensions won’t work for optional methods.

Update

Xcode 8 beta 5 shows that Swift 3 helpfully gives a warning about optional methods in a protocol extension:

The Bad

The Bad in this post is life before protocol extensions. I’m a big fan of the WWDC 2015 session introducing Protocol Oriented Programming (POP). I remember being blown away when I saw it. I watched it again when I got home, and then again when I started doing more Swift development.

The primary feature that enables POP is the extension of protocols. In essence, protocol extensions are powerful because they let us provide a default implementation for a protocol. I’m going to talk about a real world use case I came across.

My Issue

I was trying to create the simplest possible UICollectionViewDelegate that implemented a focus functionality. Briefly, this functionality is intended to focus on a particular cell after rotating the device:

The first cell that was selected and visible prior to the rotation, or, failing that
The first cell that was mostly visible prior to the rotation

The Bad Solution

Let’s take a look at the relevant parts of the code that achieve this (here’s the complete file).

We create a concrete delegate that implements UICollectionViewDelegate and store which indexPath was last ‘focussed on’.

class SimpleDelegate: NSObject, UICollectionViewDelegate {
    var selectedIndexPath = NSIndexPath(forItem: 0, inSection: 0)
    var focussedIndexPath = NSIndexPath(forItem: 0, inSection: 0)
    ...

We need to keep the focussedIndexPath up to date following any scrolling events

func scrollViewDidEndDragging(scrollView: UIScrollView, willDecelerate decelerate: Bool) {
  if !decelerate {
    self.scrollViewDidEndScrolling(scrollView)
  }
}

func scrollViewDidEndDecelerating(scrollView: UIScrollView) {
    self.scrollViewDidEndScrolling(scrollView)
}

func scrollViewDidEndScrolling(scrollView: UIScrollView) {

    guard let collectionView = scrollView as? UICollectionView,
        flowLayout = collectionView.collectionViewLayout as? UICollectionViewFlowLayout else {
        return
    }
    
    let visibleIndexPaths = collectionView.sortedIndexPathsForVisibleItems()
    
    for indexPath in visibleIndexPaths {
        if let center = flowLayout.centerForItemAtIndexPath(indexPath) where center > collectionView.contentOffset {
            focussedIndexPath = indexPath
            break;
        }
    }
}

Then any time there is a rotation, we need to return the correct targetContentOffsetForProposedContentOffset (thanks to this SO post).

func collectionView(collectionView: UICollectionView, targetContentOffsetForProposedContentOffset proposedContentOffset: CGPoint) -> CGPoint {
    
    guard let flowLayout = collectionView.collectionViewLayout as? UICollectionViewFlowLayout else {
        return proposedContentOffset
    }
    
    return self.targetContentOffsetForProposedContentOffset(proposedContentOffset, flowLayout: flowLayout)
}

func targetContentOffsetForProposedContentOffset(proposedContentOffset: CGPoint, flowLayout: UICollectionViewFlowLayout) -> CGPoint {
    var contentOffset = proposedContentOffset
    
    // Determine whether to focus on selectedIndexPath or scrolledIndexPath
    let indexPathToFocusOn: NSIndexPath
    if let visibleIndexPaths = flowLayout.collectionView?.indexPathsForVisibleItems() where visibleIndexPaths.contains(selectedIndexPath) {
        indexPathToFocusOn = selectedIndexPath
    } else {
        indexPathToFocusOn = focussedIndexPath
    }
    
    if let frame = flowLayout.frameForItemAtIndexPath(indexPathToFocusOn) where frame != CGRectZero {
        let originX = max(0, frame.origin.x - flowLayout.minimumInteritemSpacing)
        let originY = max(0, frame.origin.y - flowLayout.minimumInteritemSpacing)
        contentOffset = CGPointMake(originX, originY)
    }
    
    return contentOffset
}

This works as expected - you can download the Bad project (Swift 2.2) by checking out this commit.

The Good

Now although the Bad works, it’s not particularly sexy.

The focusing code is spread throughout a delegate that is doing multiple things
Each delegate that wants this ability to focus will need to implement all of the code shown above

The Good Solution

Protocol Extensions!

With Protocol extensions I can solve both of the above shortcomings.

A single protocol that contains all the code required for focusing
Default implementations that provide the functionality for free to any UICollectionViewDelegate

There are two parts to the UICollectionViewDelegateFlowLayoutFocusing protocol (here’s the complete file).

A note on naming - this protocol only applies to UICollectionViews with flow layouts, hence the UICollectionViewDelegateFlowLayout part, and the Focusing suffix to show what this protocol does.

public protocol UICollectionViewDelegateFlowLayoutFocusing: UIScrollViewDelegate, UICollectionViewDelegate,     UICollectionViewDelegateFlowLayout {
    
    var focusedIndexPath: NSIndexPath { get set }
    
    // Must be called by collectionView
    func collectionViewDidEndScrolling(scrollView: UIScrollView)
    func focussedContentOffset(collectionView collectionView: UICollectionView) -> CGPoint?
    // Customisation point
    func indexPathToFocusOn(collectionView collectionView: UICollectionView, flowLayout: UICollectionViewFlowLayout) -> NSIndexPath?
}

The protocol definition includes:

a required variable for tracking which indexPath was last focused
two required methods that should be called by the UICollectionViewDelegateFlowLayout
a required method that is exposed for customisation (to change the algorithm for choosing which indexPath has focus)

Here’s the code:

extension UICollectionViewDelegateFlowLayoutFocusing {
    
    func collectionViewDidEndScrolling(scrollView: UIScrollView) {
        
        guard let collectionView = scrollView as? UICollectionView,
            let flowLayout = collectionView.collectionViewLayout as? UICollectionViewFlowLayout else {
            return
        }
        
        if let indexPathToFocusOn = self.indexPathToFocusOn(collectionView: collectionView, flowLayout: flowLayout) {
            self.focusedIndexPath = indexPathToFocusOn
        }
    }
    
    func indexPathToFocusOn(collectionView collectionView: UICollectionView, flowLayout: UICollectionViewFlowLayout) -> NSIndexPath? {
        
        var indexPathToFocusOn = self.focusedIndexPath // If a new focus can't be found, default to last focus
        
        let visibleIndexPaths = collectionView.sortedIndexPathsForVisibleItems()
        
        if let selectedIndexPaths = collectionView.indexPathsForSelectedItems(),
            visibleSelectedIndexPath = NSArray(array: visibleIndexPaths).firstObjectCommonWithArray(selectedIndexPaths) as? NSIndexPath {
            // One of the selected cels is visible, so use it for the focus
            indexPathToFocusOn = visibleSelectedIndexPath
        } else {
            // No selected visible cells, find the first cell that's at least half visible
            for indexPath in visibleIndexPaths {
                if let center = flowLayout.centerForItemAtIndexPath(indexPath) where center > collectionView.contentOffset {
                    indexPathToFocusOn = indexPath
                    break;
                }
            }
        }
        
        return indexPathToFocusOn
    }
    
    func focussedContentOffset(collectionView collectionView: UICollectionView) -> CGPoint? {
        
        guard let flowLayout = collectionView.collectionViewLayout as? UICollectionViewFlowLayout,
            let frame = flowLayout.frameForItemAtIndexPath(focusedIndexPath) where frame != CGRectZero else {
            return nil
        }
        
        let originX = max(0, frame.origin.x - flowLayout.minimumInteritemSpacing)
        let originY = max(0, frame.origin.y - flowLayout.minimumInteritemSpacing)
        return CGPointMake(originX, originY)
    }
}

The extension of UICollectionViewDelegateFlowLayoutFocusing protocol allows us to provide default implementations for the required methods. This is really powerful as all the complex logic for focusing on a cell is provided along with the protocol itself.

extension UICollectionViewDelegate where Self: UICollectionViewDelegateFlowLayoutFocusing{
  
  func scrollViewDidEndDragging(scrollView: UIScrollView, willDecelerate decelerate: Bool) {
      
      if !decelerate {
          self.collectionViewDidEndScrolling(scrollView)
      }
  }
  
  func scrollViewDidEndDecelerating(scrollView: UIScrollView) {
      
      self.collectionViewDidEndScrolling(scrollView)
  }
  
  func collectionView(collectionView: UICollectionView, targetContentOffsetForProposedContentOffset proposedContentOffset: CGPoint) -> CGPoint {
      
      guard let focusedPoint = self.focussedContentOffset(collectionView: collectionView) else {
              return proposedContentOffset
      }
      
      return focusedPoint
  }
}

And for an added convenience, we can provide default implementations for some optional methods of UICollectionViewDelegate. Note that the extension only applies where Self: UICollectionViewDelegateFlowLayoutFocusing so these default implementations are scoped to delegates that are also implementing UICollectionViewDelegateFlowLayoutFocusing.

The only obvious downside to this implementation is that if a delegate overrides any of these methods, the default implementations will not be called and focusing will no longer work. For that reason these methods are as simple as possible - in case this code needs to be included in an overridden version.

The reward for all this is a UICollectionViewDelegate that is incredibly simple:

class SimpleDelegate: NSObject, UICollectionViewDelegateFlowLayoutFocusing // Ensure that the CollectionView is Focusing
{
    var focusedIndexPath = NSIndexPath(forItem: 0, inSection: 0)
}

This is the power of protocol extensions. As we have provided default implementations for all the functionality of UICollectionViewDelegateFlowLayoutFocusing, any delegate can add this functionality by implementing the protocol - simply defining a single focusedIndexPath variable.

You can download the Good project (Swift 2.2) by checking out this commit. But first you should read about the Ugly solution.

The Ugly

Now although the Good looks beautiful, and super Swifty, it doesn’t actually work.

The wrinkle is that we’re implementing optional methods on UICollectionViewDelegate. And in order for Swift to work with Objective-C, all optional methods are declared with the @objc keyword. This enforced compatibility with objective-C also causes our extension to be ignored in Swift. Essentially, our protocol extension never receives the delegate callbacks.

The Ugly Solution

Fewer Protocol Extensions! Inheritance!

We can still take advantage of the default implementations for UICollectionViewDelegateFlowLayoutFocusing - these are non-optional methods.

We need to delete the UICollectionViewDelegate extension 😢 and instead add this code directly to a delegate. At least we made it as concise as possible!

class FocusingDelegate: NSObject, UICollectionViewDelegateFlowLayoutFocusing // Ensure that the CollectionView is Focusing
{
    var focusedIndexPath = NSIndexPath(forItem: 0, inSection: 0)
}

// MARK: Call UICollectionViewDelegateFlowLayoutFocusing methods on scrolling or external contentOffset change
extension FocusingDelegate {
    
    func scrollViewDidEndDragging(scrollView: UIScrollView, willDecelerate decelerate: Bool) {
        if !decelerate {
            self.collectionViewDidEndScrolling(scrollView)
        }
    }
    
    func scrollViewDidEndDecelerating(scrollView: UIScrollView) {
        self.collectionViewDidEndScrolling(scrollView)
    }
    
    func collectionView(collectionView: UICollectionView, targetContentOffsetForProposedContentOffset proposedContentOffset: CGPoint) ->     CGPoint {
        return self.focussedContentOffset(collectionView, proposedContentOffset: proposedContentOffset)
    }
}

This solution is not that Ugly.

And we have two options going forward:

Subclass FocusingDelegate
- This is a neat solution, but could cause issues if a delegate needs to inherit from another class
Copy the code of FocusingDelegate into any focusing delegate

You can download the Ugly project (Swift 2.2) by checking out this commit.

Comments? Tweet me.

Swift Baby Steps

2015-11-09T00:00:00+00:00

A few thoughts on our first step towards a Swift codebase.

When developers leave a team, you can lose valuable (and often obscure) knowledge of a mature codebase. When developers join a team, it’s a valuable opportunity for new ideas and fresh perspective.

A recent new recruit brought some much needed vigour to our team, giving us a firm shove in the direction of Swift. We needed a jolt to wake us from our warm, comfortable Objective-C routine.

We were in the fortunate position of rewriting a standalone piece of work, and were able to settle upon a compromise…

We decided to write tests in Swift.

Maintain Velocity
Writing Swift tests, which are simpler than the functionality they’re verifying, allows us to start integrating Swift without a noticeable impact on velocity.
Learn
Swift. Is. Fun. There’s a renewed enthusiasm when discussing the simplest of implementation details. Coding in Swift feels exciting!
Build Confidence
Swift has many new concepts - even optionals can take a bit of unwrapping. Tests focussed around passing parameters and creating variables (or letting them be constants) allow us to focus on the fundamentals.
Make Testing Sexy
97% of developers would rather write tests than new functionality. For the remaining 3%, Swift is a great way to ignite our enthusiasm for test writing.
Forward Looking
Integrating some Swift code provides a compelling, concrete motive for adding Swift keywords to Objective-C code (nullability, generics)

We’re only a few weeks into this Swift experiment, but so far so good!

Comments? Tweet me.

NSDates, NSTimeZones, NSCalendars and NSDateComponents. Oh my.

2015-09-28T00:00:00+00:00

Answers to some simple questions about how to handle dates and times across timezones.

Summary

1) Date AND time? Use NSDate.

2) Time only? Use NSInteger.

3) Timezone? Store name as NSString.

4) Date only? Use NSDateComponents.

5) - 7) Comparing minutes/hours/days/weeks? Use NSCalendar components:fromDate:toDate:options.

8) Read Ole Begemann’s detailed post about dates and times.

9) From WWDC2013, watch Solutions to Common Date and Time Challenges.

1) What’s the best option to store a time on a specific date?

This is the principal case where NSDate should be used. The name of this class can be misleading. It’s not just a date, it’s a universal time, the seconds since the new millennium began. i.e. It’s a date AND a time. It’s an instant in time, and it doesn’t take timezone into account. Timezones are just different ways of representing the same instant in time.

If you want to store a time on a certain day, this is your best bet.

2) What if I only want to store a time?

A simple NSInteger is a good bet. Store it as the seconds since midnight: seconds + (60 * (minutes + (60 * hours)))

3) How do I store a time/NSDate in a certain timezone?

Best to store the timezone separately, then put them together before you do any relevant calculations (NSCalendar), or display to user (NSDateFormatter). You’ll need to create a tuple with your NSInteger/NSDate and the timezone as an NSString. Storing the timezone name (i.e. “Australia/Melbourne”) as an NSString makes it easily human identifiable and easy to initialise into an NSTimeZone.

4) What if I only want to store a date without a timezone?

Do not use NSDate, please. I beg you.

Use NSDateComponents and fill the components that are relevant. If you want a day of the week, fill only the weekday component. If you want a day on a certain year, fill year, month and day!

It might seem a bit unwieldy, but it will prevent confusion on everyone’s (that includes you, future me!!) part. You’re not giving any extra information to the date that can be misused and potentially abused.

5) How do I compare two dates?

[NSDate compare:]

6) Smartass. I meant, how do I figure out the days between two dates??

So you want to know how many days are between the 23rd of June and the 7th of July? Well, thirty days hath September, April, June… Just kidding. But you do need to keep in mind that months have different numbers of days and 1 actually comes after 30, or 31, or 28….or sometimes 29. Just use NSCalendar components:fromDate:toDate:options and let Apple do the maths for you.

7) How do I figure out the days between two dates, taking timezone into account?

If you’re talking timezones, that means you have a time and a timezone. If you’re talking days, that means you have a date. What’s the best option to store a time on a specific date? How do I store a time (or NSDate) in a certain timezone? All that stuff you learnt before is useful! Yes, use an NSDate and an NSString containing the timezone name.

You can create an NSTimeZone using your timezone name, and then an NSCalendar aligned to your timezone. Then use good old NSCalendar components:fromDate:toDate:options.

However, this will assume that ‘day’ means 24 hours apart. What if you mean “how many sleeps between now and my flight to Toulouse?” where your flight is 8am in the morning, and right now it’s 8pm 2 days before? You want to know it’s 2 sleeps, not 36 hours == 1.5 days == 1 ‘full’ day.

Modified from this SO post:

-(NSInteger)daysFromDate:(NSDate *)lhs toDate:(NSDate *)rhs inTimeZone:(NSString *)timeZoneName
{
    NSDate *lhsStart;
    NSDate *rhsStart;

    NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:timeZoneName];
    NSCalendar *cal = [NSCalendar calendarWithIdentifier:NSCalendarIdentifierGregorian];
    cal.timeZone = timeZone;

    // These lines are key and ensure days only are taken into account, not hours of the day
    [cal rangeOfUnit:NSCalendarUnitDay startDate:&lhsStart interval:NULL forDate:lhs];
    [cal rangeOfUnit:NSCalendarUnitDay startDate:&rhsStart interval:NULL forDate:rhs];

    NSDateComponents *difference = [cal components:NSDayCalendarUnit fromDate:lhsStart toDate:rhsStart options:NULL];

    return difference.day;
}

Note: It doesn’t make sense to compare two dates in different timezones, ie how long is it from 8pm in Melbourne to 9pm in London? Choose the timezone the user is most concerned with (likely their device’s current timezone), and compare the dates using that timezone.

Comments? Tweet me.

WhenDo Support

2001-01-01T00:00:00+00:00

Please send any questions to the email address:

kentios

The *Right* Unit Tests

Tools

FIRST Things First

1. K.I.S.S. And Short, Stupid

2. Test Quality ≠ Code Quality

3. Test Your Tests

4. Test Naming

5. Test Coverage

6. Code Safety

7. Fail Clearly

Summary

A More Diverse iOS Community

Der Berliner Jäger \ The Berlin Hunter

My Hunting Tips

Embedding a Debug Only Framework

Just Use a Dependency Manager

Just Throw It In

Just Embed It For Debug

Just Embed It In the UITest Target

The UITest Bundle

The App Itself

The Generated Test Runner

Big Fat Initializers

I Like Big Inits, And I Can Not Lie

How Big Is Too Big?

Init Got Back!

Turn Me On Turn Me Off

Toggle Time

Remote Toggling

Protocol Extensions - The Bad, the Good and the Ugly

Spoilers

Update

The Bad

My Issue

The Bad Solution

The Good

The Good Solution

The Ugly

The Ugly Solution

Swift Baby Steps

We decided to write tests in Swift.

NSDates, NSTimeZones, NSCalendars and NSDateComponents. Oh my.

Summary

1) What’s the best option to store a time on a specific date?

2) What if I only want to store a time?

3) How do I store a time/NSDate in a certain timezone?

4) What if I only want to store a date without a timezone?

5) How do I compare two dates?

6) Smartass. I meant, how do I figure out the days between two dates??

7) How do I figure out the days between two dates, taking timezone into account?

WhenDo Support

The Right Unit Tests