iOS / Mac on Andrew Bancroft

Every Developer is an API Designer

Tue, 25 Apr 2017 13:35:04 +0000

Every function; every class; every struct and enum and protocol is an API.

YOU — are an API designer

As developers, we move into and out of the role of “API Designer” constantly.

Have you ever thought about that? You are an API designer! You create Application Programming Interfaces all the time.

I believe that everything we create has design built in, whether we’ve thought much about it or not.

I don’t know why that thought changed my mindset so much, but it did. Maybe it’s because I always associated APIs with massive frameworks, standard libraries, and 3rd party code modules. It’s as if I thought there was a special class of developer that did that work, and all my job entailed was putting the jigsaw puzzle together.

But when you and I design and create Types of any kind, be they data structures or functions, we ourselves, as “regular developers”, are in the business of creating APIs. We’re building ways for ourselves and others to “connect” to and interact with our code… to interface with it and use it in order to perform work.

You may be building these things for your team to use, or you may be building them for the future [you] to use. The fact is, we slip in and out of consuming and creating APIs all the time.

Being mindful of shifting roles

It’s been helpful for me to recognize when I shift in and out of each role, because creating an API applies a different aspect of the programming mind than consuming an API does.

When you create an API, you’ve got to be super conscious of your decisions. Types matter. Names matter. Inputs, outputs, dependencies and the like all matter when you’re creating an API. Why?

Because other people (or you!) will have to deal with what you create in a direct way. Sure, everyone might be concerned about the implementation and whether or not it has bugs or not. But they’ll be most concerned about how to use the thing… the API… to get work done.

When we drop out of the mode of designing and creating APIs into API consumer mode, we experience the ramifications of our API designs directly.

“Why is this property named that??”
“Does this function really need all these parameters?”
“This function returns what?”
“I wish this concept was represented as a ___ instead of a ___…”

When you’re cognizant of what you’re doing with respect to creating and consuming APIs, it’s a huge help to your team and to [future you].

APIs and team mates

I was working with a teammate, and we were having a discussion about the Type of a property in a class we were building together.

The original API was a property of Type String, and the name of the property was FieldNames. I thought to myself, “Huh… FieldNames… plural… Why is this Typed as a String? Either the name should be singular, or the Type should be switched out.”

We ended up switching that out to a Type that conveyed the idea of being able to store multiple things in that property.

The point? Something as small as the letter s and the Type of a property made a head-scratching difference in my understanding of the API. I didn’t know how to use it until I asked. And that’s a tiny bit dangerous if the person who built it isn’t there to ask, anymore, right?

#1 Takeaway

The number one takeway I want you to glean is this: Whether you realize it or not, if you’re in the software development business, you’re in the API design business. For me that meant becoming super conscious of the kind of code I’m writing, depending on which role I’m in as the keystrokes flow. Maybe this realization will impact you as well!

Solving React Native’s “No bundle url present” Error

Sat, 22 Apr 2017 17:49:11 +0000

I hit the “No bundle url present.” roadblock today and had to dig a bit to find the solution. I’m going to describe how I encountered the problem, and provide the solution that’s worked more than once for me, ever since I found the suggestion in the React Native GitHub repository.

The Problem

You’ve got a React Native app.
In the terminal, you run react-native run-ios.

In the simulator, you hit a roadblock with the following error in a bright red screen:

No bundle url present. Make sure you’re running a packager server or have included a .jsbundle file in your application bundle.

The Solution

Buried in the comments of one of the React Native repo’s issues on GitHub, I found a solution that worked for me…

Open a terminal window
cd into YOUR_PROJECT/ios
Remove the build folder with rm -r build
Run react-native run-ios again

Alternatively, you could open Finder, navigate to YOUR_PROJECT/ios and delete the build folder. Then run react-native run-ios again.

I’m not sure what causes this (that bothers me), but but at least I’ve found something to get me going again.

Disabling Xcode’s OS-Level Debug Logging

Fri, 28 Oct 2016 05:06:19 +0000

Full credit to Russell Ivanovic for his tweet for figuring out how to disable Xcode 8’s extremely chatty debug console logging. I just wanted this here for my own reference, but perhaps it’s helpful to you as well.

If you’re tired of sifting through operating system-level logging to the debug console while you’re debugging your app, it’s actually fairly easy to silence.

Edit the scheme for your app:

2. In the ‘Run’ section, click on ‘Arguments’ tab, and add a new Environment Variable. Use OS_ACTIVITY_MODE for the name, and disable for the value:

That’s it! Closing the Scheme editor and re-running your app will produce a beautifully silent console window, leaving you free to see what you wanted to see with print(), or other app-specific info (such as runtime exceptions) without having to sift through all that OS-level logging.

Deploying Parse Dashboard

Sun, 17 Apr 2016 21:56:45 +0000

Below are steps that I’ve taken, myself, to deploy the [Parse Dashboard][1] to a cloud host, such as Azure, or Heroku.

Before you worry with a cloud host, you need a copy of the parse-dashboard to prepare for deployment…

1 – Clone parse-dashboard git repository

First, you’ll want to clone (or fork, then clone) the [parse-dashboard git repository from GitHub][1].

I typically make folders in my ~/Developer directory for projects that I’m working on. You can make the directory in Finder, then open Terminal and cd into it. Or you can just run mkdir in Terminal and then cd into it.

Once the directory for your parse dashboard is created, run the following command.
git clone https://github.com/ParsePlatform/parse-dashboard.git

2 – Run npm install

Once the repository has been cloned to your local machine, change directory (cd) into the ‘parse-dashboard’ directory. You can run ls at the Terminal to list out the contents of the directory you just cloned the dashboard repository into and you should see a new directory named ‘parse-dashboard’. That’s the one you need to be inside next.

So, in the ‘parse-dashboard’ folder, run npm install at the Terminal. It could take a minute or three for the installation of all the Node packages to complete.

3 – Edit parse-dashboard-config.json

After the npm package installation in Step 3 is complete, you need to cd into the ‘Parse-Dashboard’ directory to find the parse-dashboard-config.json file. Note the capitalization of ‘Parse-Dashboard’. Earlier you cd‘d into the ‘parse-dashboard’ (lower-case) directory. Well, there’s another directory inside named exactly the same, only the ‘P’ and the ‘D’ are capitalized.

You can run ls inside ‘Parse-Dashboard’ and should see parse-dashboard-config.json in there. If you don’t, you’re probably not in the right directory. At this point, you could actually be in Finder to locate the file if you’re more comfortable there. Just run open ., and you’ll be in a Finder window at the directory you’re in inside the Terminal. Then you can just double-click the configuration file to open it up in a text editor.

Once you have it open, you need to have a few pieces of information about your self-hosted Parse server handy:

Your Parse Server’s URL
Your App ID that’s configured on your Parse Server
Your Master Key that’s configured on your Parse Server
Your App’s Name (can be an arbitrary value)

Adjust your Parse Dashboard’s configuration file as follows with the values you’ve gathered:

{
  "apps": [
    {
        "serverURL": "http://url-to-your-parse-server/parse", // If your Parse Server's endpoint is not at /parse, you need to replace /parse with the correct endpoint
        "appId": "your-app-Id",
        "masterKey": "your-master-key",
        "appName": "your-app-name"
    }
  ],
  "users": [
    {
      "user":"username1", // Used to log in to your Parse Dashboard
      "pass":"password1"
    }
  ]
}
```



# 4 – Modify local .gitignore

Your local .gitignore file ignores some needed directories that, while helpful to ignore in the actual Open Source parse-dashboard repo on GitHub, are _not_ as helpful to ignore when you need to deploy the dashboard to a cloud host.

Edit the .gitignore file using a text editor and remove these three lines:

bundles/
Parse-Dashboard/public/bundles/
Parse-Dashboard/parse-dashboard-config.json
```



# 5 – Stage and commit all changes

Stage all of the changes you've made to the parse-dashboard-config.json and the .gitignore files, and add the files and directories that were previously ignored by git by running `git add -A`

Then commit the staged changes:  
`git commit -m "Prepared app for deployment"`



# 6 – Set up private git repository

Since you're storing values that are intended to be kept secret (such as your app's Master Key), you need to set up a private git repository that can be used for two purposes: 1) To keep your configuration under source control and 2) to be able to use as a deployment source for your cloud host provider.

The idea is that you can wire up your cloud app in Azure/Heroku/AWS/wherever to refresh itself every time you commit code to the master branch of this private repository. It's really handy for making updates.

[Bitbucket][2] offers its members unlimited private repositories, so that's where I've chosen to host mine.



# 7 – Add new remote to your local parse-dashboard git repository

With the new private repository set up, you need to add it as a remote to your local parse-dashboard repo.

In the Terminal, make sure you're in the directory of your local parse-dashboard git repository and run:

git remote add privateorigin https://url-to-your-private-parse-dashboard-repo
```



# 8 – Push to your private git repository

With all the changes to your configuration committed and the new remote repository added, you can push those changes up to that repo:

In the Terminal, make sure you're in the directory of your local parse-dashboard git repository and run:

git push -u privateorigin --all # pushes up the repo and its refs for the first time
git push privateorigin --tags # pushes up any tags
```



# 9 – Create app on the cloud host

Now you need to create a new app in your hosting provider of choice. I typically go with [Azure][3], because I'm most familiar with it. I also like that they offer a completely free option, though if you want to really run this stuff for a larger-scale "production” or "enterprise” app, it's going to cost no matter where you choose to host it.

The cloud host may want to know what flavor of app you want to create. In the case of parse-dashboard, it's a Node.JS app.



# 10 – Configure cloud host for git deployment

Once you've created a new Node app on your cloud host of choice, you need to configure it for git deployment.

This step will be different for each cloud host, but the general idea is that you should be able to configure your private git repository that you set up in Step 5, to be the source from which the cloud host will go out, grab the code, and perform the necessary steps to get the Parse Dashboard bootstrapped for access.

In Azure, you simply click on your app, and configure git deployment in the Deployment Source settings:

[][4]

You might check out [Heroku's startup guide][5] for help on deploying to their service.

Note that instead of doing the git deployment option, you could always FTP your whole parse-dashboard directory (the one that you cloned and ran `npm install` inside), if your cloud host supports this deployment option.



# 11 – Enable SSL (or run as insecure app)

If you access your app after you've deployed it to your chosen cloud host, you'll likely run into an error page stating that "Parse Dashboard can only be remotely accessed via HTTPS”.

Configuring SSL is beyond the scope of this walk-through, but that would be the next step if you chose to do it for your production app. Note that on Azure, your App Service Plan needs to be at "Basic” or above. Heroku charges a monthly fee to set up an SSL endpoint as well.

If you choose not to afford it or if you just want to test things out in the deployed environment to see if it's working or not, you can set up an environment variable in your app's settings on the cloud host.

In Azure, you need to choose your app, then go to "Application Settings” in the Azure Portal. Then add a new key-value pair under App settings: PARSE\_DASHBOARD\_ALLOW\_INSECURE\_HTTP is the key, and 1 (the number 1) is the value:

[][6]

In Heroku, you need to go to your app's Settings, and then add a new Config Var with the same key-value pair:  
[][7]




  
    You might also enjoy…
  
  
  
    
       FIX – Query in Parse Cloud Code Returns Unauthorized Error
    
  




 [1]: https://github.com/ParsePlatform/parse-dashboard
 [2]: http://www.bitbucket.com
 [3]: https://azure.microsoft.com/en-us/
 [4]: https://www.andrewcbancroft.com/wp-content/uploads/2016/04/AzureGitDeployment1.png
 [5]: https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction
 [6]: https://www.andrewcbancroft.com/wp-content/uploads/2016/04/AzureAppSettings1.png
 [7]: https://www.andrewcbancroft.com/wp-content/uploads/2016/04/HerokuConfigVars.png

FIX – Query in Parse Cloud Code Returns Unauthorized Error

Wed, 06 Apr 2016 04:27:49 +0000

The Parse migration process has begun – I’ve got a couple of small apps that used this backend as a service because the backend was simple and Parse was free.

The migration has gone fairly smooth so far, but I hit a wall and have been struggling to figure out the solution for about 3 hours. 3 hours too many, haha!

Problem Overview

Any time I did a query in my Parse Cloud Code, the query would fail. Every time I’d make a request to my Cloud Code function, I’d get “500 Internal Server Error” as my response.

I finally wised up and adjusted my query so that I could see the specific “internal server error” that was occurring:

var query = new Parse.Query("NameOfParseClassImFetching");

query.find({
    success: function(results){
        // Do things with the results
    },
    error: function(error) {
        response.error(error);
    }
});
```

When the details came back as to what was failing, the JSON object in the response looked like this:

{
  "code": 141,
  "error": {
    "message": "unauthorized"
  }
}
```

I got to searching and found an [issue on GitHub][1] that pointed me in the right direction, but to spare you reading through the entire thread, here's the gist:



# Solution

I happened to be using a version of the Parse Server Example that was missing a critical line of configuration in index.js. When you configure your Parse Server by calling `new ParseServer`, you need to make sure that there's a `serverURL` property that's set to the URL of your Parse Server's API endpoint.

My config didn't have this, but the moment I added it, my Cloud Code queries worked perfectly as they did before. Here's a look at my final index.js file with the relevant line highlighted:

// Example express application adding the parse-server module to expose Parse
// compatible API routes.

var express = require('express');
var ParseServer = require('parse-server').ParseServer;

var databaseUri = process.env.DATABASE_URI || process.env.MONGOLAB_URI

if (!databaseUri) {
  console.log('DATABASE_URI not specified, falling back to localhost.');
}

var api = new ParseServer({
  databaseURI: databaseUri || 'mongodb://localhost:27017/dev',
  cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
  appId: process.env.APP_ID || 'myAppId',
  masterKey: process.env.MASTER_KEY || '', //Add your master key here. Keep it secret!
  serverurl: 'http://url-to-your-parse-api-endpoint/parse'
});
// Client-keys like the javascript key or the .NET key are not necessary with parse-server
// If you wish you require them, you can set them as options in the initialization above:
// javascriptKey, restAPIKey, dotNetKey, clientKey

var app = express();

// Serve the Parse API on the /parse URL prefix
var mountPath = process.env.PARSE_MOUNT || '/parse';
app.use(mountPath, api);

// Parse Server plays nicely with the rest of your web routes
app.get('/', function(req, res) {
  res.status(200).send('I dream of being a web site.');
});

var port = process.env.PORT || 1337;
app.listen(port, function() {
    console.log('parse-server-example running on port ' + port + '.');
});
```

I hope this little breadcrumb finds its way to someone before _they_ spend 3 hours on a silly configuration issue.



 [1]: https://github.com/ParsePlatform/parse-server/issues/356

NSNotificationCenter vs Delegation – An Analysis

Thu, 05 Feb 2015 13:00:26 +0000

In Fundamentals of NSNotificationCenter in Swift, a commenter asked me to elaborate on a response I’d given to a dialog going on below the blog post. I had stated:

If you need a more structured environment around your [instance]-to-[instance] communication, delegates … are probably a better choice [than NSNotificationCenter].

I’ve been thinking for some time since I responded with that comment. What do I mean when I say “if you need a more structured environment”… What does that even look like? Why are delegates a better choice when I need such “structure”?

Structured environment? What’s that?

“Structured environment” may be a bit vague. Here’s what I was thinking when I wrote it: At the time of the comment, I was imagining what a solution implemented with NSNotificationCenter, and a solution implemented with a delegate look like….

Questions

First, I tried to step into the role of each instance, and in a role-playing sort of way, ask:

As a notifier / delegator instance: “What do I expect to happen as I send this notification or invoke this method on my delegate? What clues from my execution context inform that expectation?”
As a notifier / delegator instance: “What control do I appear to have over the sequence of events that happen as a result of sending this notification or invoking this method on my delegate?”
As a listener / delegate instance: “What impact does acting on this notification or executing this delegate method have on the system as a whole?”

And then shifting out of the role-playing mentality, stepping back and asking a question of clarity:

“Which strategy seems to provide greater clarity and structure to the entire application environment?”
“Which strategy would most help another developer who might see this code and try to trace the logic and impact of the code?”

The measurement of a more or less “structured environment”, then, would be influenced by the answers to the questions of expectations, perceived control, impact, and clarity.

Let’s explore some of those answers from the perspective of each communication strategy, starting with NSNotificationCenter.

Answers from the NSNotificationCenter Perspective

With NSNotificationCenter as an instance-to-instance communication strategy, we have the following environment:

Note that Listeners 1 to n may or may not exist. The graphic is assuming that 1+ Listener instances have “tuned in” to a particular notification key.

Expectations

What do I expect to happen? Well, the most reasonable thing I (as a “notifier instance”) can expect is for some other “listener instance” somewhere to tune in to the notification key I’m broadcasting. I have no way of knowing what would happen after that. It’s up to the listener to do something intelligent with the notification that [x event] occurred. I, as a notifier, can expect nothing more.

Perceived Control

It appears that I, as a notifier, have no control over the sequence of events that would occur as a result of my broadcast. That’s by design – the interaction between me and any listener is weak at best.

This can be a fantastic thing! There’s freedom in saying “Hey! This happened!” and then being done. But it’s also “less structured”, as I’m terming it.

Impact

The impact on the system as a whole has the potential to be significant. With NSNotificationCenter, it depends on how many listener instances there are and what each of them does in response to the notification. One could design the system to localize the impacts to the context of the listening instance. I’ve heard of and seen ugly situations that trigger cascading effects that make deciphering the impact of a notification much harder.

Clarity

We lose a good deal of clarity when heavy usage of NSNotificationCenter occurs in an application. There may be appropriate times to use NSNotificationCenter in your app. Keep in mind that it becomes much more difficult to sort out various interactions when more and more listener instances are responding a notification. Trying to reason about how the system as a whole arrived at its current state isn’t as easy when NSNotificationCenter enters the picture. Other developers with less knowledge of the app as a whole would suffer from this loss of clarity.

Answers from the Delegate Perspective

With a delegate, we have a significantly different strategy at hand. To put it before us:

Expectations

The delegation strategy deals with protocols. Protocols by nature give us reliable a way to…

Count on the implementation of needed/expected behavior, and
Predict what the behavior of the adopter of that protocol will be. By practicing good naming conventions, I, as a delegator, find it reasonable to expect that invoking a method on my delegate will do whatever the name of that method implies.

Perceived Control

It would appear that as a delegator, I can control the sequence of events that need to take place by choosing when to invoke methods on my delegate. A strategy using NSNotificationCenter can only send out a notification into the ether, and hope that something acts on it. A strategy using delegation has a delegate which adopts a protocol. Every method is at my disposal to call in whatever order makes sense.

Impact

The impact on the system as a whole still has the potential to be significant. Since there’s one-to-one communication going on between a delegator and its delegate, the determining factor on how broad the impact is tends to lean on the design of the system as a whole. Design patterns that minimize or eliminate global state reduce this potentially broad impact.

One advantage that the delegation pattern has is that the delegate conforms to a protocol and a protocol, along with its specified methods, have names. However small that knowledge is, it could give us clues about what impact of executing the delegate’s methods might have on the system.

Clarity

With the advantage of dealing with intelligently named protocols and clearly outlined method names, the delegation strategy would win the battle of clarity in my opinion. I can look at the delegator instance and say, “When execution of this instance’s logic gets to this point, reliance on the delegate kicks in and [x, y, and z] happens. I can jump over to the delegate’s implementation and say, “[x] does this, [y] does that, and [z] does this other thing.” Other developers with less knowledge of the app as a whole would enjoy this added clarity quite readily.

In Summary

Here, I’ve analyzed NSNotificationCenter, side by side with the delegation pattern, by imagining myself in the role of each instance (notifier, listener | delegator, delegate). I assessed each strategy in terms of expectations, perceived control, impact, and clarity, attempting to shed light on what it means for an environment to be “more structured” or “less structured”. My hope was to shed light on my use of the term “structured environment”, and to share my thoughts on some of the implications of using each strategy.

You might also enjoy…

Unit Testing Model Layer with Core Data and Swift

Tue, 13 Jan 2015 13:00:37 +0000

Updated on November 19, 2015 – Swift 2.0

As I approached testing my Core Data model, I have to admit I was apprehensive. How in the world was I going to write unit tests for my model layer that depended on a database. Past experience with trying to write tests with databases was painful. I feared the same would be the case with Core Data.

To my surprise, unit testing my Core Data model layer has been… well… amazing. With little effort, I’ve been able to write the unit tests I’ve wanted. The process went something like this for me:

Create an NSManagedObject subclass of the Core Data entity that I need in my unit test. (This just makes things easier from an Xcode code-completion standpoint)
Write a helper function to set up an in-memory NSManagedObjectContext. Avoiding the need to use an actual sqlite database is pretty handy. It allows for quick-running tests and easy iterations over the data model itself.
Write unit tests using the in-memory NSManagedObjectContext.

I’ve already written about creating an NSManagedObject subclass, so I will unpack steps 2 and 3 in this blog entry.

Set up an in-memory NSManagedObjectContext

A Stack Overflow question+answer sparked some thoughts. The idea and the code both came from there. The answer uses Objective-C, so my contribution is that I’ve written it in Swift. In my project, I created a new Swift file called “CoreDataHelpers.swift” in my tests target. Here’s a look at the helper function:

 1import CoreData
 2
 3func setUpInMemoryManagedObjectContext() -> NSManagedObjectContext {
 4    let managedObjectModel = NSManagedObjectModel.mergedModelFromBundles([NSBundle.mainBundle()])!
 5    
 6    let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)
 7
 8    do {
 9        try persistentStoreCoordinator.addPersistentStoreWithType(NSInMemoryStoreType, configuration: nil, url: nil, options: nil)
10    } catch {
11        print("Adding in-memory persistent store failed")
12    }
13    
14    let managedObjectContext = NSManagedObjectContext()
15    managedObjectContext.persistentStoreCoordinator = persistentStoreCoordinator
16    
17    return managedObjectContext
18}

Observations

I’ll be honest, I’m only starting to put together the pieces involved in setting up the Core Data stack. Working through these unit testing techniques has solidified a lot. Analyzing the helper method from the bottom up has made some sense out of how to configure everything:

I need an NSManagedObjectContext whose NSPersistentStoreCoordinator property uses an in-memory store.
To get such an NSManagedObjectContext, I need to add a persistent store with a type of NSInMemoryStoreType to an NSPersistentStoreCoordinator instance. (note the line that’s highlighted)
Of course, in order to do that, I need an NSPersistentStoreCoordinator instance, and I can’t get one of those unless I initialize it with an NSManagedObjectModel.
To get an NSManagedObjectModel, I use the class method, mergedModelFromBundles() to grab it from my main bundle.
Fast-forwarding now: With a proper NSManagedObjectModel instance, I can create an NSPersistentStoreCoordinator instance with it and add an NSInMemoryStoreType to that persistentStoreCoordinator. Finally, I can initialize an NSManagedObjectContext, assign the configured persistentStoreCoordinator to the context, and return it.

Whew! This whole process felt a lot like reading If You Give a Mouse a Cookie, but that may be because I’ve read it a few hundred times to my 2 year old. :]

Writing the unit test(s)

With the ability to get an NSManagedObjectContext instance that’s using an in-memory store, the unit tests using Entities from my Core Data model are quite easy.

Here’s a sample test:

 1import CoreData
 2
 3class TestsUsingModelFromCoreData: XCTestCase {
 4    func testSomethingUsingCoreData() {
 5        let managedObjectContext = setUpInMemoryManagedObjectContext()
 6        let entity = NSEntityDescription.insertNewObjectForEntityForName("EntityName", inManagedObjectContext: managedObjectContext)
 7        
 8        // model setup
 9        
10        // XCTAssert    
11    }
12}

Conclusion

I was so surprised at how straightforward the test was. The helper function makes a world of difference for me. I hope it does for you, too!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Immutable Types with Changing State in Swift

Tue, 06 Jan 2015 12:00:50 +0000

Dabble in Swift for long and the functional programming paradigm will most certainly appear on your radar. From conferences to books to blog posts, I’ve seen a lot in the functional programming arena as it relates to Swift.

As I seek to improve my functional programming thought processes and to practice what I’m learning, I found myself struggling with a fundamental concept: immutability. Especially when I’m designing something that, at the very least, appears to require the ability to change state at some point in time.

Immutable changes – A contradiction in terms?

Immutability and changing state was a real struggle for me. The two seemed contradictory actually. How am I supposed to handle changes with things that can’t change??!

And then, with the help of Stack Overflow, a lightbulb came on. As I was perusing FP topics, I ran across a question that expressed exactly what I was feeling. “How can you do anything useful without mutable state?”, the questioner asked. The answer is what illuminated things for me. The key quote from the Stack Overflow answer:

In functional languages, rather than mutating the state of objects, we simply return a new object with the changes we want.

So… instead of thinking about state changes as mutations, think of them as reasons to create something new.

Getting practical with Swift

If I’m going to get pragmatic with this, I have some design decisions to make if I’m going to try and avoid mutating the state of my objects. Rather than design my Types with the intent to update stored properties in-place, I should think about designing them so that the state-change process would actually produce a whole new instance with the transformed (updated) value.

See it in action

I’m a visual person, so for those of you who need to see it in action like me, here’s a short example: Suppose that you’re designing a class that stores a counter (or a score or a total… something like that), and provides a function to let you increment that count.

The mutating way

We could design this class in one of two ways: declare a variable stored property to hold the count. The method would then reassign incremented values to it. This is the opposite of immutable changes:

class Scorekeeper {
    var runningScore: Int
    
    init (score: Int = 0) {
        self.runningScore = score
    }
    
    func incrementScoreBy(points: Int) {
        runningScore += points
    }
}

let scoreKeeper = Scorekeeper()
scoreKeeper.incrementScoreBy(5)
println(scoreKeeper.runningScore)
// prints 5

    <p></p>
    
    
    ### The immutable way
    
    
    OR, rather than mutating the existing variable, we could go an alternate route:  The second way to design the class is to declare a constant stored property.  The method would then produce _new_ instance that stored the new state:
    
    
        class Scorekeeper {
            let runningScore: Int
            
            init (score: Int = 0) {
                self.runningScore = score
            }
            
            func incrementScoreBy(points: Int) -> Scorekeeper {
                return Scorekeeper(score: self.runningScore + points)
            }
        }
        
        let scorekeeper = Scorekeeper()
        let scorekeeperWithIncreasedScore = scorekeeper.incrementScoreBy(5)
        println(scorekeeperWithIncreasedScore.runningScore)
        // prints 5

    <p></p>
    
    
    ### Observations
    
    
    As I look at the code I've just presented, I notice a few things as I contrast the two examples:
    
    
    
    
    
      * The first example uses var to declare the stored property of my Scorekeeper class.  It _has_ to be var so that the value of the property can be changed (mutated).
    
    
      * The second example uses let exclusively.  No in-place mutations occur, so constants are perfectly reasonable to use.
    
    
    
    * * *
    
    
    
    
    
      * The first example's design lends itself to produce interesting and unpredictable side-effects.  If multiple clients hold a reference to my scorekeeper instance, there are two ways for the runningScore to change out from underneath any of those clients:  First, I could simply reassign a value to the runningScore directly.  Second, I could call incrementScoreBy().  Either way, unintended consequences may arise because of the mutation.
    
    
      * In the second example, it's _impossible_ to cause those unintended consequences.  runningScore can't be changed directly (it's a constant), and incrementScoreBy() returns a whole _new_ instance, so all clients would be dealing with the instance that they expect to be dealing with.  No values can be changed out from underneath them.
    
    
    
    * * *
    
    
    
    
    
      * The first example's incrementScoreBy method has no return value.  While I can envision writing a unit test for this, it's not obvious at first glance what I should do.  The method produces a side-effect in my existing instance that I need to know about in order to get the XCTAssert right.
    
    
      * The second example's incrementScoreBy method returns a new Scorekeeper instance.  The unit test for this (to me) is a little more clear.  I simply inspect the value of runningScore of the new instance, and assert that it is [x] points higher than the old instance.  I still have both the old scorekeeper instance _and_ the new scorekeeperWithIncreasedScore, so everything I'd need to ensure the correct point increase occurred is at my disposal.
    
    
    
    ### Conclusion
    
    
    I hear so much benefit that comes from avoiding mutable state, so it was satisfying to finally let my mind reconcile how to manage the state of my own Types immutably.  With the iOS frameworks we have to work with, immutability is a challenge, and _total_ immutable state is not possible (think of the user interface layer where state is stored and updated out of necessity because of how _Apple's_ frameworks and tools are designed). Nonetheless, I found this discovery to be really exciting all the same.

Getting Started with Unit Testing in Swift

Mon, 29 Dec 2014 12:00:50 +0000

Getting set up to write unit tests in Swift, while not difficult, isn’t exactly intuitive. I’ve written several posts and gathered a few resources on unit testing in Swift, but I haven’t yet published a “getting started” guide until now.

Where does one get started with unit testing in Swift when they’ve never gotten started before? Here are 5 steps to help you successfully begin unit testing in Swift:

1 – Create your project

The obvious first step. If you don’t already have a project going, create a new one to organize the code for your app idea. Xcode 6 will automatically generate two “targets” for you. One will be your app’s main module and contains all the code which, when compiled, is meant to be run in the iOS simulator / on an iOS device.

The other will be your test target, which, as the name implies, is where you write your unit test code.

It’s important to note that there are two compilation targets that you’ll be working with as you unit test. Source code that’s part of one compilation target isn’t part of the other by default. This is important to at least know as we move forward in this walkthrough.

2 – Framework considerations: toggle “Defines Module” in your build settings

This step becomes especially critical if you’re using or plan to use a unit testing framework like Quick. It’s not required to use something like Quick, but it can enhance your testing experience if you prefer something other than the out-of-the-box XCTestCase setup.

When you’re working with frameworks, Apple recommends that you make sure the “Defines Module” build setting, found under Packaging, is set to Yes.

If you are relying on, or could be relying on “non-standard” .framework files for your app, make sure you toggle this flag in your Xcode build settings:

3 – Import your main project (module) into your test file(s)

In your test target, at the top of each of your .swift files that contain your XCTestCase classes, write an import statement to bring in your main project’s module. In normal scenarios, your app’s module is named the same as your Xcode project file.

4 – Access control: Public == Testable

Any classes/structs/enums/methods that you need to use in your tests must have a public access control modifier. Internal (default) and private Types and functions can’t be “seen” by your unit tests, so you need to go the public route if you want to test those things.

Previously I’d written on Swift access control and its implications for unit testing. There, I proposed simply adding your main project’s .swift source files to your test target, but it turns out that this can lead to some really obscure issues. An enlightening Twitter conversation also shed some light on the subject, and pointed to the solution of testing only publicly accessible behavior that your Types expose, rather than trying to test internal implementation. That probably deserves a blog entry of its own, but for now, I’ll leave it to say that I’d recommend not adding your .swift source files to your test target, but rather to adjust the access control modifiers of the things you want to test to public.

5 – Write tests!

With your main project imported into a test file, and your Types and functions declared with appropriate public accessibility, you’re all set to begin writing tests in Swift!

Summary

We’ve gone from 0 to ready-to-test in this getting started guide to unit testing in Swift. From here, you may be interested in pursuing other topics related to unit testing in Swift. Check out my ever-growing unit testing resource list for more information!

Swift Unit Testing – Verifying Method Calls

Mon, 22 Dec 2014 13:09:28 +0000

In this unit testing screencast for Swift developers, we explore how to use Test Driven Development to verify method calls.

Getting Started Guide

If you’re new to unit testing or are trying to get set up with unit testing in a Swift project, you might check out my getting started guide before jumping into the screencast.

Screencast

Large / Full-Screen Viewing

GitHub Example

GitHub repo of the example developed in the screencast.

Screencast Transcript

[0:01]

Hi, I’m Andrew from andrewcbancroft.com, and I’m bringing you a test driven development example for iOS in Swift.

The goal of this video is to teach you how to write a unit test to verify that a method was called.

[0:21]

I’ll begin in Xcode 6.1.1 with a side-by-side view of my TestCase class, and my primary View Controller class. This is what Xcode generated for me when I chose to create a new Single View Application.

[0:38]

Imagine a scenario with me: Suppose that as part of your application’s requirements, you mush show an Alert View after your primary view loads. How would we go about using Test Driven Development to implement this “feature”?

[0:53]

Well, we’d write a test, of course – I’ll name it something appropriate like “testUIAlertViewShowsAfterViewLoads”

[1:04]

Next, I need to create an instance of my ViewController class so that I can test it.
But immediately, I run into trouble. It seems that my TestCase class can’t “see” my View Controller class.

[1:17]

Thankfully, it’s a simple fix: Simply add the View Controller class to your Test target.

[1:26]

With everything compiling now, we can move to the next line of test code.

[1:32]

First off, in order to test my View Controller’s Alert View functionality, the Alert View has got to be visible to my test. The easiest thing for me to do at this point is to assume that there will be a property on my View Controller that I can set. This allows me to perform a kind of dependency injection known as “setter injection”. All it really means is that the property is dual-purpose. When the app runs on my iPhone, it’ll use a real UIAlertView. But when I run it in my tests, I can plug in a UIAlertView that I control the behavior of, so that I can verify what I need to in my tests.

[2:16]

The ability to swap in a kind of Alert View that I control really is the “magic sauce” to this whole test-driven operation. In order to know whether or not a UI element was “shown” in a unit test without actually showing something on the screen in a simulator or device, I need to invent something known as a test-double. A fake object, if you will.

[2:44]

My Fake Alert View will have some special capabilities that allow me to know whether the “show()” method was called on it. At the same time, it needs to be able to be substituted in my View Controller for a real UIAlertView.

[3:00]

Since Swift supports object-oriented design, we have inheritance at our disposal here.

[3:07]

I’ll create a nested class inside my test function called FakeAlertView. Notice that it’s a subclass of UIAlertView. What’s great about this is that it meets both of my testing requirements: I can control it’s behavior, and it can be substituted anywhere a UIAlertView is needed.

[3:28]

I’ll finish fleshing out this fake object in a minute. Now that Xcode isn’t complaining about not knowing what a FakeAlertView is, I’ll turn my attention to a new compiler complaint: I don’t have an alertView property on my View Controller yet, so I’ll add one.

[3:50]

There’s just a little more setup that’s needed in order to be able to verify that the show method was called. Since show() doesn’t return anything, we need some way to know that its logic was executed. I’ll do two things to expose this:

[4:06]

I’ll have a boolean property called showWasCalled on my FakeAlertView that is initially set to false.
I’ll override the show() method in this fake UIAlertView subclass. Inside the method body, I’ll reassign the value of showWasCalled to true. That will be enough for me to use inside an XCTAssert, which is coming up.

[4:35]

We’re nearing the finish line here. All that’s left is to call my View Controller’s viewDidLoad method, and write my assertion.

[4:44]

The only thing I’d tell you to make note of is that we need to cast the View Controller’s UIAlertView instance to a FakeAlertView so that we can access the showWasCalled property.

[4:57]

Running the test at this point should produce a failing test, which is exactly what we want (because there’s no code that calls the alertView’s show() method in viewDidLoad()).

[5:08]

The last step to this adventure is to write the production code to pass the test. In viewDidLoad, I call my alertView’s show method and re-run the tests.

[5:19]

And we’re green! Which means we’ve managed to successfully verify that a method was called.

[5:27]

Thanks for watching – I have other resources related to Swift and iOS development at andrewcbancroft.com.

Swift Unit Testing Resources

Fri, 19 Dec 2014 12:00:33 +0000

As I’ve researched Test Driven Development practices in general, and for iOS / Mac applications, I’ve been helped by several sources. I’ve also discovered a few things the hard way, so I’m combining and maintaining this list of resources to help point you in some helpful directions as you adventure in unit testing your iOS apps.

Pluralsight Courses

Play by Play: TDD with Brad Wilson – Awesome, awesome course. I learned some really great techniques from this one. The course is geared toward .Net development using Visual Studio, C#, and Moq, but you should still watch it if you’ve got a subscription – the techniques used can be done on other platforms. I’ve been practicing the techniques in Swift (minus the mocking framework).
TDD as a Design Tool – Geared toward web development with JavaScript / AngularJS, but has some useful patterns.

Blogs

How to write unit tests in Swift with XCTest – Josh Brown gives a nice overview of the unit testing capabilities offered in Xcode and how Swift can be used as the testing language of choice.
Swift: Unit Testing Tips and Tricks – @NatashaTheRobot offers some practical advice in a tips and tricks style blog post.
iOS Unit Testing – Some good introductory articles to browse. Offers a few things in Swift, but much of his content is in Objective-C.
Write your first Unit Test in Swift – Learn how to write the most basic, but still useful, Unit Tests in Swift with XCTest.

User Group Talks

Adam Leonard – Test-Driven Development in Swift using Quick (July 2014) – Talk given by @adamjleonard at a Brooklyn Swift Developers Meetup in July.

At andrewcbancroft.com

Don’t Write Legacy Swift – Motivations for testing your code.
TDD for iOS in Swift – What’s the Goal? – Before actually doing Test Driven Development (TDD) for your iOS / Mac app, it’s really important to ask a very fundamental question: What’s the goal? I discuss two goals for testing your iOS / Mac apps.
Improvements to Unit Testing in Swift with Xcode 7 Much of the pain involved in getting set up to write unit tests in Swift has been alleviated by improvements in Xcode 7. This article analyzes these improvements to ease your unit testing workflow.
Getting Started with Unit Testing in Swift – While getting set up to write unit tests in Swift isn’t difficult, it isn’t exactly intuitive. This 5-step guide will get your project set up to write unit tests in Swift.
An (Almost) TDD Workflow in Swift – When I find myself staring at the screen, paralyzed because I’m “not supposed to write actual production code until the test is written”, I often turn to the workflow that describe in this post, to help me break through to being productive.
Unit Testing Model Layer with Core Data and Swift – Exploration of testing when your project uses Core Data. This post provides a walk-through of setting up an in-memory data store to test with NSManagedObjects.
Swift Unit Testing – Verifying Method Calls – Screencast showing how to verify method calls in Swift unit tests.
Swift Access Control – Implications for Unit Testing – Pointer on how to make code from your main project visible in your Test project.
Creating “Mocks” and “Stubs” in Swift – Essentially a discovery I made about how to create fake objects and override those objects’ methods. You’d do this to isolate and control the object’s behavior in order to enable or ease the testing process.

TDD for iOS in Swift – What’s the Goal?

Tue, 16 Dec 2014 12:00:10 +0000

Before actually doing Test Driven Development (TDD) for your iOS / Mac app, it’s really important to ask a very fundamental question: What’s the goal? What am I aiming for when I say I want to drive my iOS development with tests?

2 Goals of TDD in iOS

A recent course I watched on Pluralsight called TDD as a Design Tool gave me some insight on two goals for doing Test Driven Development:

Make sure my code is in the right place
Make sure my logic is correct

Let’s take them one at a time…

A place for everything, and everything in its place

Believe it or not, Test Driven Development is an extremely powerful tool for ensuring that code is written in the right place. But what do I mean by “the right place”?

In the object-oriented world, “places” are data structures, such as classes and structs, and their publicly accessible methods.

When I employ TDD in a project, I will tend to be driven to making sure my code ends up in the right place. I’ll give you an example:

Starting Places

When I create a new iOS project, Xcode sets me up with a Storyboard, a blank Scene, and a View Controller. Xcode also generates a Test target for me… BUT a what am I most aware of right from the onset? The Storyboard and the View Controller.

The natural inclination, then is to start dragging things onto the design surface and wiring them up to the controller as Outlets and Actions, and off I go!

It’s like I’m lead to the ever-common temptation to put all my code for a given screen in the application inside its corresponding View Controller.

TDD Tension

While I may be led there, and while it may seem convenient, it would seem that TDD wants to start me off in a different “place” altogether. Since TDD asserts that I should not write any code unless there’s a test requiring it to be written, I’d be driven away from my main project into my Test project. My canvas at that point is a fresh XCTestCase class.

UI at this point is not on my mind. Here, I care more about the foundations of the app itself. I begin to consider the application’s domain, and its behavior apart from its user interface. This is very important if I want to truly write decoupled, modular, maintainable code.

Rather than weigh down my View Controller with tons of responsibility, TDD drives me to try and build separate classes to steward small bits of my application. Those small classes can be tested much more easily than trying to get an enormous View Controller instantiated and configured in my test suite.

This is just one small example of how TDD can get you off on the right track to putting code in its proper place.

Your logic was impeccable, Captain

The second goal of TDD in iOS is making sure my logic is correct, or, as Spock would say, “impeccable”.

Does my application’s code do what it should do? Can I write my code in such a way that I can easily verify it? TDD, by nature, pushes me in the direction of being able to verify the accuracy of my code’s logical outcomes… that is, how it behaves.

Fascinating is a word I use for the unexpected

Testing has this way of setting expectations. One thing I’ve really enjoyed about TDD’s notorious red-green-refactor cycle is that I know certainly and immediately when I’ve messed up (ie, run across a “fascinating” situation in Spock terms).

When I write the test, it should fail the first time. If it doesn’t, I’ve messed up.
When I write the code to pass the test and the test fails, I also know I’ve messed up.

Next Steps

With the fundamental goals of TDD in place, I feel more prepared from a foundational standpoint to venture into actuall test-driven practices for iOS.

I am learning so much in the area of testing – it’s a technique I’m practicing regularly, both in Swift and in C# (for fun and for work, respectively), so as I grow and discover ways to optimize the TDD experience in Xcode / Swift, I’ll be sharing them. Stay tuned!

Don’t Write Legacy Swift

Wed, 10 Dec 2014 12:00:51 +0000

“Legacy Swift”. Is that an odd phrase to you, too?

“Legacy” has connotations such as “old”, “difficult-to-change”, “outdated”, etc. Juxtaposing “legacy” and “Swift” would never have crossed my mind until I read Michael Feathers’, Working Effectively With Legacy Code, where he asserts,

Legacy code is simply code without tests.

What an impact those words had on me as I’ve transitioned over to Swift from Objective-C. If it’s true that legacy code is code without tests, it’s easy to see how you and I could be writing legacy Swift, even though Swift is a brand new language!

And whether you agree with Feathers’ definition of “legacy code” or not (he readily admits the potential for controversy with the definition), I think we can all concede that unit testing our code has many benefits and leads to the ability to consistently, objectively verify the quality of our code at the end of the day.

Legacy Swift == Bad Swift

Unashamedly, Feathers writes,

Code without tests is bad code…With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

My take-away from that quote is this: The only way to consistently, objectively verify whether my code is getting better or worse is to execute it and see if the results are what I expected. I can do this in the Simulator / on my device, over and over and over, opening myself up to a never-ending, time-consuming, error-prone testing cycle, OR I can write automated unit tests and run them every time as I make incremental changes to my software.

Testing is hard (for me)

I have not always been the most successful at writing unit tests. Test-driven development (TDD) is difficult for me at times. I often find myself sitting, staring at the screen as if looking into an abyss, unsure of what I’m supposed to do next. (Any of you TDD-ers who’ve figured out how to imagine the structure of your production code prior to it being written so that a test can be crafted first, let me know your tricks!)

I’m growing in this area of writing testable code, and the tests that go along with it. Admittedly, I’m still in the stages of “this is hard”, sometimes.

I have noticed, though, that coding and testing patterns are emerging in my toolbox that are making this process more and more fluid for me.

Testing is worth it

However difficult it is for me, I’m on board with believing that the effort put in to writing tests is worth it in the end. I wrestle with my code to tame it with tests from the start.

If I’m unable to figure out test-first development on a particular problem, I strive to write the tests as jointly with my production code as possible. At all costs, I try to avoid writing the code and saying to myself, “I’ll come back to the tests later”, because I don’t trust myself to keep that promise.

With every product I’ve written and tested, I can testify to the fact that I feel good about that code. I know it works how I intended it to work. I rest assured that when I make changes, I haven’t broken anything I programmed in another session. The tests help me remember what I intended for my software to do. I’m confident that the patterns that evolved out of the tested code are better than what I’d have implemented if I did without the tests. It’s worth it.

What kind of Swift will you write?

The main goal of this post was to get you thinking. Feathers got me thinking, so I thought I’d pass along the challenge: Don’t write legacy Swift!

The good news is that, as Feathers writes,

[Legacy code is code without tests] is a good working definition, and it points to a solution.

And that solution is straightforward: Begin writing tests for your code, and you’ll avoid writing legacy Swift.

Send a Type to Obedience School – Using Swift Extensions for Additional Protocol Conformance

Tue, 02 Dec 2014 19:15:33 +0000

Did you know that you can make any Type (here meaning Class, Enumeration, or Struct), even already-existing ones that you don’t have the source code for, adopt a protocol that it doesn’t normally conform to out of the box?

You can – even if you don’t have the original source code for that Type! It’s a powerful and intriguing proposition. Let’s explore how this is possible.

How, you ask?

Well, as the title of this article suggests, Swift extensions are the way to do it. To demonstrate this capability, consider the following scenario:

You’re using a library that lets you create instances of Bird , and you don’t have access to the source code for the library.
Bird has a property called species and a property called commonName .
You’d like Bird to conform to the Printable protocol, defined in the Swift standard library, so that you can call println(_:) on Bird instances, and have it log something useful to the console.
When println(_:) is passed a Bird instance, you’d like it to print out something like “[species] (ie, [commonName]).”, and have [species] and [commonName] be replaced by the Bird‘s real values.

Remember that you don’t have access to the original source code of Bird . Without Swift extensions, there would be no way for you to tell the compiler that you’d like Bird to adopt and conform to the Printable protocol.

Thankfully, extensions do exist, and we can teach a Bird new tricks, enabling its conformance to Printable .

Protocol Conformance Extension

As stated in the Printable protocol documentation, a Type adopting the Printable protocol must implement a single, read-only property named description .

The extension, then would be implemented as follows:

1// Explicitly specify protocol adoption
2extension Bird: Printable {
3
4    // Implement the required property to make Bird conform to the protocol
5    var description: String {
6        return "\(species) (ie, \(commonName))"
7    }
8}

The magic line in the code above is highlighted. This tells the compiler that Bird will be extended to adopt the Printable protocol.

Of course, the remaining requirement then, is to implement the specification of the protocol so that Bird conforms to it, which is what the body of the extension contains.

Note that simply extending Bird to have a read-only description property will *not suffice for making the Type adopt the protocol. There is no “implicit” protocol adoption in Swift, so you must specify in the extension declaration that you intend for the Type to adopt the protocol.

Conclusion

With this little example, you’ve seen how using an extension can enable a Class, Enumeration, or Struct to adopt and conform to a protocol that it normally wouldn’t out of the box. It’s especially neat that you can do this for any such Type, whether you have control over its original source code or not.

Swift UITableViewDataSource Cheat Sheet

Mon, 24 Nov 2014 22:04:28 +0000

iOS developers will quickly recognize that there are a set of methods that always tend to get implemented when dealing with UITableViews . The problem I consistently face is remembering that set of methods that belong to the UITableViewDataSource (and UITableViewDelegate ) protocols. I find myself option-clicking the protocol name to remember the method signatures I need, since Xcode doesn’t have a way to stub out the methods involved with a protocol (C# developers working in Visual Studio like myself are spoiled!).

I’m sure cheat sheets like this already exist, but I thought, “Why not have one that I can reference from my own blog?”… In fact, I’ve gone ahead and turned the code below into a snippet in Xcode, but just in case I ever lose that, I’ve got this post, which stubs out dummy implementations of the three most common UITableViewDataSource protocol methods.

I’d be delighted if it helped my readers as well, so without further ado, here’s my UITableViewDataSource cheat sheet, which should allow you (and me) to copy and paste directly into our UITableViewDataSource class for a quick start:

 1func numberOfSectionsInTableView(tableView: UITableView) -> Int {
 2    return 1 // This was put in mainly for my own unit testing
 3}
 4
 5func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 6    return dataSourceArray.count // Most of the time my data source is an array of something...  will replace with the actual name of the data source
 7}
 8
 9func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
10    // Note:  Be sure to replace the argument to dequeueReusableCellWithIdentifier with the actual identifier string!
11    let cell = tableView.dequeueReusableCellWithIdentifier("ReplaceWithCellIdentifier") as! UITableViewCell
12    
13    // set cell's textLabel.text property
14    // set cell's detailTextLabel.text property
15    return cell
16}

The 5 W’s of Swift Extensions

Mon, 03 Nov 2014 19:04:19 +0000

For newcomers to Swift, the concept of extending a Type may be new, so I thought I’d share a high-level overview of Swift extensions in the style of asking the 5 W’s: Who? What? When? Where? Why?

Who

“Swift developers” is a pretty obvious answer, but here are a scenarios to ask yourself about to see if you could make use of Swift extensions:

“I am relying on Types that are found in 3rd party frameworks or libraries and I wish I could add a little bit of functionality that isn’t there out of the box. Can I do that easily?”
“In utilizing Apple’s frameworks I find that a Type could be more powerful if it could just do [x]. Can I add that power to the Apple framework Type?”
“I have written a framework for myself / my team that is used in multiple apps, but I desire to add behavior to one of the framework’s Types that is only relevant in a specific area of one particular app. Can I add that special functionality without changing the framework source?”

If you related to any or all of those scenarios, you could potentially make use of Swift extensions to speed your workflow and make your more organized and clean. Read on for more!

What

Extensions add new functionality to an existing class, structure, or enumeration type.
– Apple Swift Developer Reference

The key word is existing. Hopefully the scenarios listed under “Who” make a little more sense with this information in mind. In all of those cases, you wish to add functionality to Types that have already been designed and implemented.

What I have found to be amazing about Swift extensions is that the word “existing” also applies to Types for which you don’t have access to the original source code. That is powerful!

So extensions are especially useful if you want to add behavior to a Type found in any of the Cocoa / Cocoa Touch frameworks, or a 3rd party’s framework. Additionally, if you’ve created your own libraries and frameworks and you’d like to add behavior without modifying the original source, extensions are a good choice for adding that behavior, especially if what you’re adding doesn’t apply to every single usage of the Type you’re extending.

When

The most logical time to use Swift extensions is when you have a piece of functionality that you want to be able to reuse, and the most reasonable place to put that code is within an already-existing Type. Ideally, the piece of functionality is so closely related to that Type that it just makes sense to extend that Type’s behavior to include your new functionality… “If only I could peek inside that Type’s implementation to inject my new code”, you think to yourself.

If you’re pondering along those lines, then chances are, Swift extensions will aid you in your effort to create more reusable, clean, and organized code.

Perhaps a good question to ask here is, “When not?”. When I see phrases like, “most reasonable place to put that code”, it begs the question, “What does ‘most reasonable’ mean?”. The answer isn’t black and white. I’ll offer what I’ve done in the past as general advice:

As a general rule of thumb, extensions are great for small, simple additions to a Type, rather than long, complex functionality.

If you’re implementing a set of behavior (more than a handful of methods or computed properties), creating a new Type to encapsulate that behavior is most appropriate. After all, that’s what classes and structs do. When deciding on extension vs new Type, they key word that comes to my mind is relatedness. How related is this behavior to the Type I think I want to extend?

Additionally, extensions are limited in the area of maintaining state. Extensions cannot add new stored properties (only computed ones). Creating a new Type to encapsulate the stored properties and the behavior that utilizes them is your alternative solution in this case.

Where

So you’ve decided that you want to create an extension to some class, struct, or enumeration. Where do you put it? My thought on this has always been to create a new .swift file, give it a name that indicates which Type you’re extending, and create the extension inside that file.

So if I want to extend, say, String to have a new method called “sayHello” which printed “Hello” when invoked, I would create a new .swift file called StringExtensions.swift. I’d then place my extension inside:

1extension String {
2    func sayHello() {
3        println("Hello")
4    }
5}

Hey, awesome – you got a bonus How with that quick example! Creating an extension in Swift is that easy.

Why

Swift extensions are powerful. They empower you to add behavior to any class, struct, or enumeration, even if you don’t have access to the original source code.
They are simple and convenient to create.
They encourage code re-use by encapsulating behavior that will be used more than once in your project in a single location.
Additionally, they promote good code organization, leading to cleaner and more readable code when used to add behavior that’s closely related to the Type they’re extending.

Summary

We’ve just explored Swift extensions by analyzing who should use them, what they are, when they’re appropriate, where to put them, and why they’re useful to your development efforts. As a bonus, how to program an extension was given as a simple example.

If you’ve found Swift extensions to be useful to your development efforts, sound off in the comments below! I’d love to hear how you’re utilizing this feature of Swift.

Send Text Message In-App – Using MFMessageComposeViewController with Swift

Tue, 28 Oct 2014 11:00:37 +0000

In a previous walkthrough on sending e-mails in-app, I explored how to use MFMailComposeViewController to allow a user to compose an e-mail without ever leaving your app. I then followed up with a proposal for better-segregating the responsibilities of composing an e-mail and responding to the delegate callbacks out of the View Controller.

I say all this because today, I’d like to walk you through sending a text message in-app using the same pattern as the second article. This walkthrough should be fairly straight-forward on its own, but if you’d like to reference my previous post on clean view controllers, it could be helpful in understanding why I’m not just shoving everything into the View Controller and calling it good.

The Gist

Here’s the gist of the components we’ll need in order to accomplish the task of using MFMessageComposeViewController to send text messages in-app. Presumably, you’d like to allow your users to send a text message to a pre-defined recipient, or maybe you want to pre-populate a message and allow your users to text it to whomever they desire. Any and all of this can be accomplished by implementing this general outline:

Create a class (I’ll call it MessageComposer) that will handle the responsibility of creating/configuring a text message composer.
MessageComposer will also handle the MFMessageComposeViewControllerDelegate callback method (
messageComposeViewController:didFinishWithResult:).
Finally, I’ll program a View Controller to create an instance of this MessageComposer class and present it based upon some user action, such as tapping a button.
Note that to see the example in action, you’ll have to run it on an actual device, because the Simulator is unable to send text messages…

For those who just like to dive in and explore, feel free to head over to GitHub and grab the example project now!

The Details

With the general idea in mind, let’s jump in to discover how to implement the solution…

MessageComposer

While it’s possible to simply put all of this code inside the View Controller, I’d recommend doing your best to avoid it. While this simple example doesn’t add a ton of complexity if you just write it all into your View Controller, a real-world app will undoubtedly be more complex.

In my experience, it’s best to try and segregate out as many responsibilities of functionality from the View Controller where it’s possible. Thankfully, simple examples like this highlight the ease of segregating these responsibilities so that you can begin to employ the pattern for other components that you use within your app.

So in keeping with this idea of nurturing a clean View Controller, I’ve decided to create a new custom class called MessageComposer. Take a look:

 1import Foundation
 2import MessageUI
 3
 4let textMessageRecipients = ["1-800-867-5309"] // for pre-populating the recipients list (optional, depending on your needs)
 5
 6class MessageComposer: NSObject, MFMessageComposeViewControllerDelegate {
 7    
 8    // A wrapper function to indicate whether or not a text message can be sent from the user's device
 9    func canSendText() -> Bool {
10        return MFMessageComposeViewController.canSendText()
11    }
12    
13    // Configures and returns a MFMessageComposeViewController instance
14    func configuredMessageComposeViewController() -> MFMessageComposeViewController {
15        let messageComposeVC = MFMessageComposeViewController()
16        messageComposeVC.messageComposeDelegate = self  //  Make sure to set this property to self, so that the controller can be dismissed!
17        messageComposeVC.recipients = textMessageRecipients
18        messageComposeVC.body = "Hey friend - Just sending a text message in-app using Swift!"
19        return messageComposeVC
20    }
21    
22    // MFMessageComposeViewControllerDelegate callback - dismisses the view controller when the user is finished with it
23    func messageComposeViewController(controller: MFMessageComposeViewController!, didFinishWithResult result: MessageComposeResult) {
24        controller.dismissViewControllerAnimated(true, completion: nil)
25    }
26}

Taking a close look through the comments, you’ll notice the following:

You need to import the MessageUI module.
Rather than hard-code the recipients list, I’ve declared a constant at a global scope for easy access/changeability in the future. It’s actually optional to even supply a recipients list to your composer… it’s just dependent on how you want to use it. Notice that it’s an array of Strings.
MessageComposer inherits from NSObject. This is a requirement of the MFMessageComposeViewControllerDelegate protocol, which MessageComposer conforms to.
There’s a function in there called canSendText that becomes important later on for testing whether or not sending a text message is even possible at the moment on the user’s device. It wraps MFMessageComposeViewController‘s canSendText method to avoid needing to import the MessageUI module in other places (like the View Controller that uses instances of this class).
configuredMessageComposeViewController does what it says it does – it returns an instance of a MFMessageComposeViewController that’s been configured with a list of recipients and a body.
messageComposeViewController:didFinishWithResult: is what gets called with the user either sends the text, or cancels sending a text from the message composer. I’ve written code in that method’s body to simply dismiss the instance of the view controller that called the method.

We’re now ready to head to the View Controller and wire up the components allowing a user to display a MessageComposer!

View Controller

The View Controller is very simple for this example:

 1import UIKit
 2
 3class ViewController: UIViewController {
 4    // Create a MessageComposer
 5    let messageComposer = MessageComposer()
 6    
 7    @IBAction func sendTextMessageButtonTapped(sender: UIButton) {
 8        // Make sure the device can send text messages
 9        if (messageComposer.canSendText()) {
10            // Obtain a configured MFMessageComposeViewController
11            let messageComposeVC = messageComposer.configuredMessageComposeViewController()
12            
13            // Present the configured MFMessageComposeViewController instance
14            // Note that the dismissal of the VC will be handled by the messageComposer instance,
15            // since it implements the appropriate delegate call-back
16            presentViewController(messageComposeVC, animated: true, completion: nil)
17        } else {
18            // Let the user know if his/her device isn't able to send text messages
19            let errorAlert = UIAlertView(title: "Cannot Send Text Message", message: "Your device is not able to send text messages.", delegate: self, cancelButtonTitle: "OK")
20            errorAlert.show()
21        }
22    }
23}

You’ll notice that I create an instance of MessageComposer (the custom class we just defined in previous steps). It’s declared at a scope that can be seen throughout the lifetime of the View Controller (so that the delegate callback can be invoked when appropriate).
sendTextMessageButtonTapped is wired up to a button on my storyboard, and will be executed when the user taps the button.
Checking to make sure the device can send a text message is critical – Note that running the example in the Simulator will execute the else block, because the Simulator cannot send text messages.
If the device can send texts, a configured MFMessageComposeViewController is obtained from the MessageComposer instance. It’s then displayed.
If the device can’t send texts, it’s probably a good idea to alert the user somehow… I’ve chosen a simple UIAlertView.

Summary

In this walkthrough, I’ve demonstrated the mechanics of configuring, displaying, and dismissing a MFMessageComposeViewController, which enables your users to send a text message in-app. Additionally, I’ve attempted to show how to keep the View Controller from handling more than it really should, by segregating out the MFMessageComposeViewController configuration and delegate protocol conformance to another class.

Happy texting!

Fundamentals of NSNotificationCenter in Swift

Wed, 08 Oct 2014 18:27:47 +0000

Updated on September 19, 2016 – Xcode 8 & Swift 3.0

The goal of this post is to help you grasp the fundamentals of using NSNotificationCenter in your Swift iOS app. The topic isn’t necessarily new, and there’s no difference except syntax between Objective-C and Swift implementations involving NSNotificationCenter. Even still, I’m hoping to add to the understanding of this useful tool by giving a fully-working example on GitHub (Swift 2.3 and Swift 3.0), and by sharing the insight that’s clicked in my own brain as I explain the example.

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

First things first: What is this thing?

When I first heard NSNotificationCenter, I thought “push notifications”. However, NSNotificationCenter has nothing to do with sending or receiving push notifications in iOS. Rather, it is a communication tool internal to your app. It provides a way for one instance of a class/struct to notify one or more other class/struct instances about something. The goal in doing this is to enable those 1+ other class or struct instances to take appropriate action based the communication they receive. An common analogy comes to mind: think “radio tower”. NSNotificationCenter is the central hub that acts as a broadcaster of notifications. If that still seems vague, hang tight – seeing the example below should help it all come together for you.

Should I use it?

Before diving into the basic workflow, it’s worth asking, “Should I use NSNotificationCenter, or is there some other option that’s more appropriate for my app’s internal communication needs?”

It is often the case that there is more than one way to solve a problem in software development, and it’s no different with NSNotificationCenter. There is more than one way to accomplish instance-to-instance communication at run-time. I’ve written about two such forms of communication in my post titled NSNotificationCenter vs Delegation – An Analysis. It may be worth reading up on, just to make sure you’re using the right tool for the right kind of communication.

Basic Workflow

NSNotificationCenter.default is at the center of it all when it comes to this discussion.

The basic workflow of using NSNotificationCenter goes something like this:

Since `NSNotificationCenter` is in the business of broadcasting notifications, the first thing to do is to specify a way to uniquely identify a notification. This is most easily accomplished by defining a constant string value (using `let` syntax in Swift) at a globally-visible scope. The string constant you define here will serve as a “notification key”. If you have several notification keys that you need to define, perhaps creating a new .swift file called “NSNotificationCenterKeys.swift” is a clean way to do this.
Steps 2 and 3 of the workflow go hand-in-hand. Without implementing the one, implementing the other doesn’t make much sense… Step 2 is to post a notification to `NSNotificationCenter.default` identified by the key that was created in step 1. In radio terms, the class or struct instance desiring to post a notification asks the default notification center to broadcast the notification key defined in step 1… this class or struct instance chooses the right situations to request that the notification key be sent out based on business logic specific to the project’s requirements.
Step 3 is to set up 1+ class or struct instances to be listeners, or more properly, observers of a particular notification. Such an observer will be able to tell that it’s “heard” the notification, because it will be “listening for” a notification that uses the same key that was created in step 1, which is the key used in step 2 to post the notification. In radio terms, the listener is tuned in to the default notification center’s station that’s identified by that special key defined in step 1 and posted in step 2. So you see now why steps 2 and 3 go hand-in-hand. With no posts to the notification center on that station, tuning in will do no good. Likewise, posting a notification but having no listeners accomplishes nothing.
Finally, what should the observing instance do once it’s detected the notification? Well, when signing up to be an observer, the instance must also specify the name of a function that will be called upon receipt of the notification it’s listening for. Whatever action or routine is appropriate to perform at that time is what that function’s implementation should contain.

Visualizing NSNotificationCenter by Example

If you’re like me, you need less talk and more example, so I’ve created a simple Xcode project that you can grab over at GitHub (Swift 2.3 and Swift 3.0). Running the project will allow you to click through a series of tabs in a tab view controller, post a notification, and see the results. It looks much like this:

Working back through the basic workflow with this example you can find the following key aspects of implementing a NSNotificationCenter solution (lines of code to pay special attention to will be highlighted).

Steps 1 and 2:

I’ve chosen my FirstViewController class to be the one that defines the global constant with a unique notification key and tells the default notification center to post that notification when the “Notify!” button is tapped:

 1// 1. Globally define a "special notification key" constant that can be broadcast / tuned in to...
 2let mySpecialNotificationKey = "com.andrewcbancroft.specialNotificationKey"
 3
 4class FirstViewController: UIViewController {
 5    @IBOutlet weak var sentNotificationLabel: UILabel!
 6    
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9        NotificationCenter.default.addObserver(self, selector: #selector(FirstViewController.updateNotificationSentLabel), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
10    }
11
12    // 2. Post notification using "special notification key"
13    @IBAction func notify() {
14        NotificationCenter.default.post(name: Notification.Name(rawValue: mySpecialNotificationKey), object: self)
15    }
16    
17    func updateNotificationSentLabel() {
18        self.sentNotificationLabel.text = "Notification sent!"
19    }
20}

Steps 3 and 4:

Both of these steps are implemented in very similar ways in my SecondViewController and ThirdViewController classes. The code should speak for itself:

 1class SecondViewController: UIViewController {
 2    @IBOutlet weak var notificationLabel: UILabel!
 3    
 4    override func viewDidLoad() {
 5        super.viewDidLoad()
 6
 7        // 3.  Observe (listen for) "special notification key"
 8        NotificationCenter.default.addObserver(self, selector: #selector(SecondViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
 9    }
10
11    // 4.  Implement function to act on that notification
12    // The name of this function must match the selector argument you specified when you called addObserver()
13    func actOnSpecialNotification() {
14        self.notificationLabel.text = "I heard the notification!"
15    }
16}
17
18
19class ThirdViewController: UIViewController {
20    @IBOutlet weak var notificationLabel: UILabel!
21    
22    override func viewDidLoad() {
23        super.viewDidLoad()
24        NotificationCenter.default.addObserver(self, selector: #selector(ThirdViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
25    }
26    
27    func actOnSpecialNotification() {
28        self.notificationLabel.text = "I heard the notification, too!"
29    }
30}

Finally, to reiterate the explanation in visual form and for easy reference, I’ve annotated a screen shot taken from the project’s code:

Removing an observer

One final requirement for working with NSNotificationCenter is to remove an observer when it no longer needs to listen for notifications. When might this situation arise?

When the observer is no longer referenced and thus deallocated from memory, it should tell the default notification center that it can be removed
When some condition occurs in your application that renders it no longer relevant for an instance to listen for notifications

The first situation is the most common, and is for sure the scenario that we want to protect against, so that the default notification center doesn’t continue to manage observers that are no longer capable of actively listening. To satisfy the requirement of removing an observer when an instance is deallocated, we could provide something like the following deinit method:

1deinit {
2    NSNotificationCenter.default.removeObserver(self)
3}

For the second bullet point, you can simply write the same line of code that’s highlighted in the above snippet, wherever it makes sense for you to tell the default notification center when it’s appropriate to stop sending messages to the instance in question.

Summary

NSNotificationCenter is particularly useful when there are multiple class or struct instances that need to take action based on something that happens elsewhere in your application. For this type of scenario, NSNotificationCenter can be a great tool to wield as you develop apps in Swift for iOS.

You might also enjoy…

NSNotificationCenter vs Delegation – An Analysis

Swift Alternative to Objective-C Macros

Wed, 01 Oct 2014 17:58:46 +0000

I’ve previously written about using enumerations in Swift to encapsulate special values that could end up falling into the “magic string” category if they were to simply be scattered in-line throughout your code. The primary example I proposed for such a “magic string” replacement was Storyboard Segue Identifiers. These special identifiers have such a specific purpose that felt to me like a natural fit to create a Type in the form of an enumeration (which I called SegueIdentifier) to group them all together in one place so that I could easily find them and modify them, should I ever need to do so.

I still like that solution for groups of things, but it’s a lot of “ceremony” to use enumerations for encapsulating everything that may have been implemented as a macro expression or a static global constant in Objective-C.

I ran across this in the Swift developer documentation that I think will be of help to folks who want to avoid “magic values” throughout their code, but don’t want to employ enumerations where they’re not the best fit. Here’s a snippet:

So there you have it, folks! One easy alternative to your former #define habits when you’re working in Swift is to simply declare a constant (using the let keyword) instead. The word “constant” is key – the last thing you want to do is declare a variable in some global scope (using the var keyword) where the value of the identifier could be changed somehow, if even by accident.

Organizing #define Replacement Constants

The question that naturally comes next is, “Where do I declare a constant that I’m using to replace a #define?”

The answer is not black and white – a few factors play into your decision of where to declare them.

In general, I would probably declare such a constant in the location that’s closest to the context in which it is used. Here are a few examples to consider:

If it's only going to be used in a single function, it's reasonable to declare the constant locally at the top of that function, or anywhere near where it will be used.

If it's only used in a single class/struct, perhaps declaring it at the top of that class/struct is a good idea.

If it's going to be a value that's used in multiple classes/structs, it may be time to create a new .swift file and place it there so that you can find it again.

Start with a very small scope, and as that constant broadens in its usage throughout your project, gradually move it to more and more globally visible locations.

Using a globally-defined constant is exactly what I did for checking the iOS version number of a user’s device. I simply created a new file called “iOSVersions.swift”, placed my global constant definitions in it, and was able to reference those constant names everywhere in my project that I needed to perform conditional logic based on the iOS version number.

Summary

A simple Swift alternative to a #define macro in Objective-C it to define a constant at a scope that’s appropriate for where you plan to use that constant.

Slide In Animation in Swift

Wed, 24 Sep 2014 18:25:52 +0000

In a previous post about fade animations in Swift, I demonstrated how to use a class extension to add the ability for any UIView instance to easily call fadeIn() or fadeOut() on itself. This strategy was nice – the animations, while simple, would have cluttered my code each time I used them, had I not encapsulated them somewhere. Employing class extensions in Swift seemed a natural way to provide this functionality to UIViews.

Well, I liked the idea so much that when it came time for me to implement a slide animation, I kept the same strategy, and I’d like to share my implementation with you today.

Animation demo

To start off with, here’s a sample of what the animation does:

The easiest way to get the gist of what I’ve done is to head over to GitHub and download the example Xcode Project. In real life, I’ve combined the fade animations and the slide animation into the same UIView extension, but for education’s sake, I’ve split them out so you can easily see the moving parts.

Implementation overview

There are three major parts to this example implementation, which I’ll explain in detail shortly. Here’s the overview:

1 – Create the UIView extension

 1import UIKit
 2
 3extension UIView {
 4    // Name this function in a way that makes sense to you... 
 5    // slideFromLeft, slideRight, slideLeftToRight, etc. are great alternative names
 6    func slideInFromLeft(duration: NSTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
 7        // Create a CATransition animation
 8        let slideInFromLeftTransition = CATransition()
 9        
10        // Set its callback delegate to the completionDelegate that was provided (if any)
11        if let delegate: AnyObject = completionDelegate {
12            slideInFromLeftTransition.delegate = delegate
13        }
14        
15        // Customize the animation's properties
16        slideInFromLeftTransition.type = kCATransitionPush
17        slideInFromLeftTransition.subtype = kCATransitionFromLeft
18        slideInFromLeftTransition.duration = duration
19        slideInFromLeftTransition.timingFunction = CAMediaTimingFunction(name: kCAMediaTimingFunctionEaseInEaseOut)
20        slideInFromLeftTransition.fillMode = kCAFillModeRemoved
21        
22        // Add the animation to the View's layer
23        self.layer.addAnimation(slideInFromLeftTransition, forKey: "slideInFromLeftTransition")
24    }
25}

2 – Set up the storyboard

From the Utilities panel, drag over a regular View to act as a wrapper for the sliding text (use a regular View, not a Container View)
From the Utilities panel, drag a Label into the wrapper view and create an IBOutlet to your View Controller for the Label
Set up auto layout constraints for both the wrapper and the Label
Set the wrapper view’s Clip Subviews property to checked in the Attributes Inspector

3 – Code the View Controller – initiate slide animation.

In my example, I wired the trigger up to a button’s touchUpInside action. For you, it may be something different that triggers the animation to begin. Whatever it may be, call slideInFromLeft() on your UIView instance (in my case, the UILabel).

1@IBAction func slideTextButtonTapped(sender: UIButton) {
2        self.slidingTextLabel.slideInFromLeft()
3        self.slidingTextLabel.text = "Sliding Text!"
4    }

Notice that directly after the call to slideInFromLeft(), I change the label’s text property to contain the new text that I want to slide in.

Implementation details

The real work all happens inside the UIViewExtensions.swift file where I add the slideInFromLeft() function to a UIView’s arsenal.`

UIViewExtensions.swift

First to note is that I’ve provided a few default values in the function’s signature so that the animation can be initiated as simply as writing viewInstance.slideInFromLeft(), or as “complicated” as providing argument values to both duration and completionDelegate:

1extension UIView {
2    func slideInFromLeft(duration: NSTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
3    // Implementation...
4}

Next, I create a CATransition instance, and set its delegate property if a completionDelegate is passed when the function is called:

1extension UIView {
2    func slideInFromLeft(duration: NSTimeInterval = 1.0, completionDelegate: AnyObject? = nil) {
3        let slideInFromLeftTransition = CATransition()
4        
5        if let delegate: AnyObject = completionDelegate {
6            slideInFromLeftTransition.delegate = delegate
7        }
8            // Remaining implementation...
9}

I then go about configuring the animation’s properties. To achieve the “slide in from left” animation, I set the type and the subtype properties to kCATransitionPush and kCATransitionFromLeft, respectively. These two combined create the “slide in” effect. Other properties that I set are duration, timingFunction, and fillMode:

 1extension UIView {
 2        // ...
 3        slideInFromLeftTransition.type = kCATransitionPush
 4        slideInFromLeftTransition.subtype = kCATransitionFromLeft
 5        slideInFromLeftTransition.duration = duration
 6        slideInFromLeftTransition.timingFunction = CAMediaTimingFunction(name: kCAMediaTimingFunctionEaseInEaseOut)
 7        slideInFromLeftTransition.fillMode = kCAFillModeRemoved
 8        
 9        // ...
10    }
11}

To keep things simple, I only allow myself to customize the duration property, and optionally provide a completionDelegate when I call the function… the other properties are more fundamental to how the animation should perform, so I encapsulate the implementation here so that it’s an abstraction when I actually call slideInFromLeft() later in my View Controller.

The last thing I do is add the animation that I just created and configured to the view’s layer property. “The view” here would be the instance of UIView that has calls slideInFromLeft():

1extension UIView {
2        // ...
3        self.layer.addAnimation(slideInFromLeftTransition, forKey: "slideInFromLeftTransition")
4    }
5}

Storyboard setup details

This is probably the more challenging piece, just because it takes some tweaking to get the auto layout constraints just right.

My general setup in this example is a Label wrapped inside a containing UIView. I made sure to simply drag over a regular View (not a Container View) from the utilities pane on the right. I then dragged a Label inside the “wrapper” view.
I set wrapper view’s width to a value that was less than the entire screen’s width. This was so that the sliding view didn’t appear to slide in from off-screen and slide out off-screen. Instead it appears to slide in from underneath the wrapper view… You’re welcome to customize this how you want (or avoid the containing view altogether if you find it’s not needed for your specific implementation).
For the wrapper view, I’ve set constraints for
- Center Horizontally in Container
- Top Space to Top Layout Guide
- Width
- Height

Next, I made sure that my label that will be sliding is inside the wrapper view. I set its constraints to

Center Horizontally in Container
Center Vertically in Container
Equal Widths
Equal Heights

The last thing I do in the storyboard before wiring things in the View Controller is to select the wrapper view and make sure it’s Clip Subviews property is checked. As an experiment, toggle this option and watch the effect it has on the animation’s appearance:

View controller implementation

The final piece of the setup is to wire things up to the View Controller and animate the Label.

Since I needed to reference the Label containing the text that I’d like to animate, I created an IBOutlet from my storyboard to my View Controller:

1class ViewController: UIViewController {
2    @IBOutlet weak var slidingTextLabel: UILabel!
3    // ...
4}

Next, I needed a way to initiate the slide in animation – I decided that wiring it to a button’s touchUpInside action would be sufficient for the example, so I created an IBAction from my Storyboard to my View Controller for that purpose.

Within the body of that IBAction, I wrote the call to slideInFromLeft() on my slidingTextLabel instance:

 1import UIKit
 2
 3class ViewController: UIViewController {
 4    // ...
 5    @IBAction func slideTextButtonTapped(sender: UIButton) {
 6        self.slidingTextLabel.slideInFromLeft()
 7//      self.slidingTextLabel.slideInFromLeft(duration: 1.0, completionDelegate: self) // Use this line to specify a duration or completionDelegate
 8        self.slidingTextLabel.text = "Sliding Text!"
 9    }
10    
11    // ...
12}

If you have need to specify a duration or a completionDelegate, there’s a commented out line of code there that shows an example of passing those arguments to the slideInFromLeft() function.

If you specify a completionDelegate to the slideInFromLeft() function, a method called animationDidStop() will be called when the animation finishes. Inside this callback function, you can write code to perform any action you’d like to have happen after the animation has finished. If you don’t set a completionDelegate, there’s no need to have this method override in your code:

1override func animationDidStop(anim: CAAnimation!, finished flag: Bool) {
2        println("Animation stopped")
3    }

That’s a wrap, folks! Hope this strategy is helpful for you as you think about where to place code for your UIView animations.

You might also enjoy…

Swift iOS Version Checking

Thu, 18 Sep 2014 04:44:36 +0000

While iOS 8 is now officially in the wild, it may take a bit of time to reach the level of user adoption that iOS 7 had accumulated over the past year. If you plan to target the widest number of users for your app (at least in these early days of the iOS 8 roll-out), it’d probably be wise to include iOS 7 in your target audience.

When accommodating iOS 7 users, you’ll inevitably run into instances where you need to check which iOS version the device is running, so that you can implement a fall-back plan for older versions of iOS.

In Objective-C, I’ve seen this accomplished by using pre-processor directives, or with introspection. Swift, however, has no pre-processor directives in v1.0, and only objects which conform to the NSObject protocol can utilize the respondsToSelector: method call. What to do?

As it turns out, Apple has guidance that would actually work for both Objective-C and Swift – It involves simply checking the NSFoundationVersionNumber of the device against one of the pre-defined values defined in NSObjCRuntime.h.

To accomplish this in Swift, you can create a new Swift file (I called mine “iOSVersions.swift”) to hold the following code:

1let iOS7 = floor(NSFoundationVersionNumber) <= floor(NSFoundationVersionNumber_iOS_7_1)
2let iOS8 = floor(NSFoundationVersionNumber) > floor(NSFoundationVersionNumber_iOS_7_1)

Whenever you need to check which iOS version the device is running, you can simply use the iOS8 / iOS7 constants that you just defined – they’re accessible in other Swift files throughout your project:

1if iOS8 {
2  //Do some iOS 8-specific things that may not be supported in older versions
3} else {
4  //Implement your fall-back plan for older versions of iOS
5}

With these little snippets, you should be empowered to support iOS 7 while taking advantage of new iOS 8-only features and APIs. You can also begin to move away from deprecated ways of doing things, while not breaking your app for iOS 7 users, so long as iOS 7 retains a significant slice of the iOS version pie.

Create Documentation for your Swift Playground

Wed, 10 Sep 2014 03:44:16 +0000

As I opened Apple’s latest “Patterns Playground” blog post, I was impressed with the look and feel. Rather than create the documentation as comment blocks, they managed to put in sharp-looking notes and explanations before each code example / experiment. It’s like an interactive book, reminiscent of the Swift Programming Language iBook! Here’s a snippet of what their Playground looks like:

[][1]

Of course, my immediate question / thought was, “How’d they do that?! Can I do that? I want to do that!”. I didn’t know it at the time of this publication, but apparently Apple has some pre-release documentation out on developer.apple.com, detailing how all this is done. I (as usual) did it the hard way and hacked my way through it. I figured I’d go ahead and share my discoveries alongside the official documentation from Apple.

I’m already a believer in using Playgrounds for teaching. The read-example-experiment loop is so easy in the Playground environment. I think using this documentation technique has the potential to enhance the Playground experience even more to create professional, sharp-looking educational material_. _

For this post, I wanted to take a simple example (the File -> New Playground playground) and convert the comment-style documentation into “fancy” documentation.

Before:

[][2]

After:

[][3]

Let’s explore.

The Gist

Create yourself a playground (and note where you save it).
Navigate to where the .playground file is saved in Finder.
Right-click the .playground file, and choose “Show Package Contents”.
Add a new folder named “Documentation”.
Create a new HTML file in the Documentation folder. It should contain the HTML markup and the text explanation that you’d like to enhance your playground with. Make sure it is a well-formed HTML document by the time you’re finished creating it. I describe a quick way to jumpstart your documentation process at the end of this article…
Although optional, I’d recommend styling your HTML file with appropriate CSS. Adding a CSS file and referencing it within the HTML file you created is probably a good idea (and this is allowed for Playground documentation).
Open contents.xcplayground with the text editor of your choice by right-clicking and choosing “Open With”.
Modify the XML so that the
element contains a node as shown in the highlighted code lines in the example below. Be sure to replace the relative-path value with the name of the HTML file you created in step 5 (I named mine “doc-fragment-0.html”):



  9.  Save, and open the playground in Xcode 6.  Your Playground should now contain documentation!

As a way to jump-start my own Playground documentation, I simply borrowed one of the HTML files and the CSS file from Apple's Patterns Playground.  Then I modified the markup to contain the educational material I wanted for _my_ playground, customized the styles to what I wanted, added the <span class="lang:default decode:true  crayon-inline "><documentation></span> node to the contents.xcplayground file, saved, and voila:  Fancy documentation!

&nbsp;

 [1]: http://www.andrewcbancroft.com/wp-content/uploads/2014/09/Patterns_playground.png
 [2]: http://www.andrewcbancroft.com/wp-content/uploads/2014/09/MyPlayground_WithDocumentation_playground_before.png
 [3]: http://www.andrewcbancroft.com/wp-content/uploads/2014/09/MyPlayground_WithDocumentation_playground_after.png



Replace Magic Strings with Enumerations in Swift
Wed, 03 Sep 2014 01:55:54 +0000
“What can I do to avoid these ‘magic strings’ in my code?” – This was the question I asked myself recently as I found myself in prepareForSegue comparing segue.segueIdentifier to in-line hard-coded Strings.  This kind of in-line hard-coding of a String for comparison purposes is what I mean by “magic strings” in this article.  I knew this felt like a bad idea, but the solution to a cleaner option wasn’t readily apparent to me.
I used to do things like create static string constants, or #define expressions so that I could easily change these values if I ever needed to update them for some reason.  You know… back in a former Objective-C developer life when these tactics were available to me.  But these options don’t exist in Swift.  What to do??
Enumerations to the rescue!
Specifically, Enumerations with pre-populated default values (called raw values).
By creating an Enumeration that stores raw String values, I was able to encapsulate what would otherwise be “magic strings” in a type-safe construct for easier, cleaner use in my code.
The Gist
Consider this fabricated example:
I have a storyboard with one main View Controller that connects to three other View Controllers through three segues:  “otherScreenSegue1”, “otherScreenSegue2”, and “otherScreenSegue3” as defined in the utilities panel in Xcode.
An Enumeration encapsulating those segue identifiers might look something like this:
1enum SegueIdentifier: String {
2    case OtherScreenSegue1 = "otherScreenSegue1"
3    case OtherScreenSegue2 = "otherScreenSegue2"
4    case OtherScreenSegue3 = "otherScreenSegue3"
5}
With this Enumeration defined (perhaps in its own .swift file – wherever you deem would be strategic and findable again), the prepareForSegue override can become “magic string”-free:
 1override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
 2    switch segue.identifier {
 3    case SegueIdentifier.OtherScreenSegue1.toRaw():
 4        println("Going to other screen 1")
 5    case SegueIdentifier.OtherScreenSegue2.toRaw():
 6        println("Going to other screen 2")
 7    case SegueIdentifier.OtherScreenSegue3.toRaw():
 8        println("Going to other screen 3")
 9    default:
10        println("Going somewhere else")
11    }
12}
Alternatively, if you prefer to compare the enum values themselves, you could do the following (thank you to Brandon Knope for pointing this out – I think it looks even cleaner than my original code above!):
 1override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
 2    if let identifier = SegueIdentifier.fromRaw(segue.identifier) {
 3        switch identifier {
 4        case .OtherScreenSegue1:
 5            println("Going to other screen 1")
 6        case .OtherScreenSegue2:
 7            println("Going to other screen 2")
 8        case .OtherScreenSegue3:
 9            println("Going to other screen 3")
10        default:
11            println("Going somewhere else")
12        }
13    }
14}
This strategy of encapsulating my various segue identifiers in an Enumeration provides me a one-stop-shop for reviewing, and if need-be, updating the String values to match what I’ve set up in my storyboard.
The Details
I’ve chosen an Enumeration with Raw Values, because the other two kinds (Enumerations as Inherent Types, or Enumerations with Associated Values) don’t allow me to do String comparison, or don’t allow me to define a value at declaration-time, respectively.
Notice one critical aspect of the Enumeration:  because default raw values are defined, all of the raw values must be of the same Type, as explicitly specified in the declaration line:  enum SegueIdentifier: String // All of the enum cases must be Strings
The next important thing to understand is that in order to do actual comparisons with the raw value itself (see the switch statement in my code example above), I needed to call toRaw() on the Enumeration value being used (first code example), or call fromRaw() to convert the segue.identifier string to an Enumeration value (second code example):
1SegueIdentifier.OtherScreenSegue1 // Enum value of type SegueIdentifier
2SegueIdentifier.OtherScreenSegue1.toRaw() // String value, "otherScreen1Segue"
3SegueIdentifier.fromRaw("otherScreenSegue1")! // Unwrapped Enum value of type SegueIdentifier
Conclusion
In addition to segue identifiers, I’m considering using raw value Enumerations to wrap NSNotificationCenter keys as well.  Share if you find other nice uses of raw value Enumerations!
So far, this solution has provided me a nice, straight-forward, type-safe way to encapsulate groups of Strings where the urge to fall back to “magic strings” would otherwise be high.
 


Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
Wed, 27 Aug 2014 04:43:29 +0000
The delegation pattern is ubiquitous in iOS development – the pattern is a “core competency” for developing in Cocoa, and if you program with the iOS SDK for any length of time and you’ll end up writing some code that resembles someInstance.delegate = someDelegate.
One of the toughest things that I’ve experienced is choosing what someDelegate is.  All too often, a View Controller ends up being assigned the responsibility of being the delegate for everything in its hierarchy.  My question is:  Is there a cleaner way?
Let’s pick up on the example I proposed in my recent post about sending e-mails in-app.  For “quick and dirty” pragmatism, I just crammed everything into the View Controller with the promise of coming back and (hopefully) showing a cleaner way.  Here is a quick link to example posed before if you’d like to review it before proceeding.
What if…
What if we could make some adjustments so that the View Controller was trimmed down to the example on the right (click for larger view):

I’ve created a fully-working example on GitHub if you’d like to download it and play.
So the question at hand:  Is the class labeled “Clean Example” preferable (ie, better)?  First, let’s explore how I accomplished the “clean” View Controller.  Then I’ll tip my hand on and share what I like about this approach…
EmailComposer
In order to accomplish the self-declared Clean View Controller above, I placed all of the configuration processes and the delegate method for the MFMailComposeViewController in a new class called EmailComposer.  It should look familiar if you recall the previous example:
 1import Foundation
 2import MessageUI
 3
 4class EmailComposer: NSObject, MFMailComposeViewControllerDelegate {
 5    // Did this in order to mitigate needing to import MessageUI in my View Controller
 6    func canSendMail() -> Bool {
 7        return MFMailComposeViewController.canSendMail()
 8    }
 9    
10    func configuredMailComposeViewController() -> MFMailComposeViewController {
11        let mailComposerVC = MFMailComposeViewController()
12        mailComposerVC.mailComposeDelegate = self
13        
14        mailComposerVC.setToRecipients(["someone@somewhere.com"])
15        mailComposerVC.setSubject("Sending you an in-app e-mail...")
16        mailComposerVC.setMessageBody("Sending e-mail in-app is not so bad!", isHTML: false)
17        
18        return mailComposerVC
19    }
20    
21    // MARK: MFMailComposeViewControllerDelegate Method
22    func mailComposeController(controller: MFMailComposeViewController!, didFinishWithResult result: MFMailComposeResult, error: NSError!) {
23        controller.dismissViewControllerAnimated(true, completion: nil)
24    }
25}
So literally, the only thing I did is

Cut the function definitions for configuredMailComposeViewController, and the MFMailComposeViewControllerDelegate method.
Paste them into the new EmailComposer  class, which inherits from NSObject  (a requirement for this particular delegate protocol’s conformity), and conforms to the MFMailComposeViewControllerDelegate  protocol.
Adjust my View Controller to create an instance of EmailComposer , obtain a configured MFMailComposeViewController, and present it whenever the user taps on a button in my UI.

Conclusions

The View Controller in its final version is focused.  It’s primary concern is presentation and handling of user interaction with the View itself, rather than needing to worry with configuring an MFMailComposeViewController and its delegate callback.
EmailComposer is less of a hassle to test, in the sense that I no longer need to instantiate a View Controller in my XCTestCase class just to test my MFMailComposeViewController stuff.  It’s a real pain to test an actual View Controller instance, so I like that I can easily create an instance of EmailComposer and test away without the bulk.
No need to import MessageUI in my View Controller.

All in all, this is the cleanest, simplest, most balanced solution (that I could think of) to factoring out some logic to another class, so as to make my View Controller as clean as possible.
The goal was to make sure the appropriate responsibilities are assigned to the right classes.  Presentation logic is all in the View Controller.  Configuration and delegate callback implementation is done in EmailComposer.
I’m thinking through applying this same idea to other more complicated examples (UITableViewDataSource and UITableViewDelegate come to mind), and I think it would do us a lot of good to strategize on how to avoid making the View Controller the “catch-all” delegate / data source class for everything that’s currently on the screen_._
Hopefully these thoughts spark some ideas in the Swift community.  This post has already been revised slightly based on feedback that I’ve received from folks on Twitter.  If you have additional ideas in regards to choosing the right delegate, holler my way!  I’d love to hear from you.
Thanks for reading.

  
    You might also enjoy
  
  
    
      Clean Coding in Swift – Functions
    
    
      Clean Coding in Swift – Type Inference
    
    
      Expanded Thoughts on Swift’s Type Inference
    
    
      Send Email In-App – Using MFMailComposeViewController with Swift
    
    
      Send Text Message In-App – Using MFMessageComposeViewController with Swift
    
  



Send Email In-App – Using MFMailComposeViewController with Swift
Tue, 26 Aug 2014 03:48:30 +0000
Updated on October 11, 2016 – Swift 3.0
In this writing, I want explore how to use MFMailComposeViewController with Swift to send e-mails within your app as a walkthrough. My focus here is “quick and dirty” pragmatism, so that we can easily see what the inter-working components of MFMailComposeViewController are. That being said, here’s an important disclaimer – I’m going to overload the View Controller’s responsibilities in the examples to follow.
An op-ed with my thoughts and experimentation on how to keep the View Controller clean by factoring out some of the configuration and delegate methods to another class is now live as well.

Defining the requirements
As part of your app requirements, you need to be able to send an e-mail within your app without leaving it. Additionally, you need to pre-populate some standard e-mail fields such as “To”, “Subject”, and “Body”.
Not only is this possible, the API for accomplishing it is pretty straight forward.

Implementation overview
In order to implement the solution for this requirement, you need a few things:

A View Controller from which your user will initiate the display of the email composer screen, presumably by tapping on a button or something else that’s wired up to an `@IBAction`.
A configured `MFMailComposeViewController` to present.
An `MFMailCompseViewControllerDelegate` to handle dismissing the email composer screen.

Note that you may have trouble in the iOS 8 Simulator, with symptoms of the composer presenting itself and immediately dismissing. Running the app on an actual device running iOS 8 should work fine, as the problem seems to be isolated to the simulator, only.
An example View Controller class that implements the three steps above is proposed here. All that would be left for you to do is to design a user interface and wire up the @IBAction. Lines of code that are of special importance, such as module imports, protocol conformance and assignment, checking for the ability to send e-mail, and the protocol method implementation are highlighted. Take a look:
 1import Foundation
 2import UIKit
 3import MessageUI
 4
 5class ViewController: UIViewController, MFMailComposeViewControllerDelegate {
 6    
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9    }
10    
11    @IBAction func sendEmailButtonTapped(sender: AnyObject) {
12        let mailComposeViewController = configuredMailComposeViewController()
13        if MFMailComposeViewController.canSendMail() {
14            self.present(mailComposeViewController, animated: true, completion: nil)
15        } else {
16            self.showSendMailErrorAlert()
17        }
18    }
19    
20    func configuredMailComposeViewController() -> MFMailComposeViewController {
21        let mailComposerVC = MFMailComposeViewController()
22        mailComposerVC.mailComposeDelegate = self // Extremely important to set the --mailComposeDelegate-- property, NOT the --delegate-- property
23        
24        mailComposerVC.setToRecipients(["someone@somewhere.com"])
25        mailComposerVC.setSubject("Sending you an in-app e-mail...")
26        mailComposerVC.setMessageBody("Sending e-mail in-app is not so bad!", isHTML: false)
27        
28        return mailComposerVC
29    }
30    
31    func showSendMailErrorAlert() {
32        let sendMailErrorAlert = UIAlertView(title: "Could Not Send Email", message: "Your device could not send e-mail.  Please check e-mail configuration and try again.", delegate: self, cancelButtonTitle: "OK")
33        sendMailErrorAlert.show()
34    }
35    
36    // MARK: MFMailComposeViewControllerDelegate Method
37    func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
38        controller.dismiss(animated: true, completion: nil)
39    }
40}

Step-by-step implementation
With the above example in front of you, let’s explore what’s going on here in detail.

Setting up the View Controller
First of all, we need to import the MessageUI module.
Second, we need to specify that the View Controller will conform to the MFMailComposeViewControllerDelegate protocol. Later, we’ll actually implement the method that this protocol outlines, which will allow us to make the email composer screen go away once the user is finished either sending an e-mail or cancels out of sending one.

sendEmailButtonTapped()
This is the method that responds to the user tapping on a button. Assuming this is wired up to an appropriate element in the UI, it kicks off everything related to creating and showing the email composer screen. The logic is as follows:

Obtain a configured `MFMailComposeViewController` instance
Check to make sure the device can send e-mail at this moment

If it can, present the configured `MFMailComposeViewController`
Otherwise, show an alert with an error message




configuredMailComposeViewController()
I decided to encapsulate the configuration of an MFMailComposeViewController instance inside a function. I found that it made things a little more readable, perhaps more testable, and kept the spirit of decomposing sub-steps of a process into individual, single-responsibility functions.
One vital property to set is the mailComposeDelegate property (otherwise, you can never get rid of the e-mail composer screen after it’s presented). Now, there’s a “gotcha” here – MFMailComposeViewController instances also have a property named delegate . The delegate property is not the one to set (I did this at first and wondered why my implemented delegate “callback” method never got called). Set the mailComposeDelegate property to the instance of whatever you want to handle dismissing the email composer screen once the user is finished sending an e-mail or cancels. In the example, I set it to self, since the View Controller itself will implement the appropriate delegate method (Read my thoughts on cleaning this up a bit).
As you can see, setting up the “To”, “Subject”, and “Body” are simply a matter of setting properties of an MFMailComposeViewController instance. Notice that setToRecipients() accepts an array of e-mail address strings, so don’t forget to wrap that argument in an array, even for a single recipient. The same would work for Cc, and Bcc recipients, had I configured those.

showSendMailErrorAlert()
This method shows a simple UIAlertView if the user’s device cannot send an e-mail at the moment.

MFMailComposeViewController’s delegate method
The implementation of this delegate method simply dismisses the email composer screen.


  
    You might also enjoy…
  
  
    
       Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
    
       Send Text Message In-App – Using MFMessageComposeViewController with Swift
    
  




Expanded Thoughts on Swift’s Type Inference
Thu, 21 Aug 2014 02:19:45 +0000
In my recent op-ed on clean coding in Swift focused on Type Inference, I began by saying,
Quick!  Tell me!  What is the Type of the birdDetails constant in this code example:
let birdDetails = birdDetailsFromStorage()
With no additional context to glean information from, the correct answer to the question is, “I have absolutely no clue…”
But is that concluding assertion true?  Hmm…
I’m learning, and as I’ve weighed a recent Twitter conversation and thought on a comment thread that Rob Napier made on the post quoted above, I’m compelled to expand a little on my first post on Type Inference as it relates to clean code in Swift.
Something struck me as I read Rob’s comment:  Why wouldn’t I know the Type that would be inferred from what is returned by birdDetailsFromStorage() and assigned to birdDetails?  Presumably, I named the function what I named it intentionally.  The part I missed, was that if I had designed well and created a Type called BirdDetails (say, a Struct as Rob proposed), then all of a sudden, an inference can be made by both the compiler and a human that the birdDetails constant is… well… an instance of BirdDetails.  Imagine that!
To quote Rob (emphasis added):

Type inference should only be used when the result is unambiguous, but the best solution is to make the result unambiguous.

Bingo.  The best solution is to make the result unambiguous.  You and I as code authors are in charge of the clarity or ambiguity of our code – it’s up to us to make the results of our function evaluations unambiguous.
When I named the function birdDetailsFromStorage(), I heavily implied something about its return Type in the name.  I even implied it in the name of the constant.  I was expecting the return Type to be something that encapsulated whatever “bird details” are – I just didn’t realize it at the time (although it’s super obvious now)!
The very name of a thing sets expectations for you and the readers of your code.  It’s our job to set ourselves up for that expectation to be fulfilled!  Be predictable with the return Type of your functions for your own sake.  A function signature should be such that when you run across birdDetailsFromStorage()in some piece of code, you are able to legitimately expect it to return a BirdDetails.  
Using this predictable, convention-based approach to give humans the right clues about what the compiler is going to compute a Type to be makes Type Inference a totally legitimate language feature to embrace for the sake of your code’s clarity and simplicity.
I’ll leave you with a final quote from Rob’s comments:

Don’t go implying that you’re returning one thing when you’re returning another. If you must, then yes, explicit types are your punishment. 😀

Thank you Rob for your insight and feedback.  You can read more of Rob’s work at http://robnapier.net.

  
    You might also enjoy
  
  
    
      Clean Coding in Swift – Functions
    
    
      Clean Coding in Swift – Type Inference
    
    
      Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
  



Sort It Out – Sorting an Array in Swift
Sat, 16 Aug 2014 18:06:26 +0000
I had a question come to me today regarding sorting an array of integers that are actually encoded as strings in the array.  Data comes to is in a variety of encodings/types, so it’s quite common to need to adjust things to the right state for working with.  Let’s take a look at how to solve this one.
The Dilemma
Given an array like this…
1let arrayOfIntsAsStrings = ["103", "2", "1", "50", "55", "98"]
… the question arises:  “How do I sort this in numerical order so that my output array is still an array of strings, but sorted like this ["1&#8221;, "2&#8221;, "50&#8221;, "55&#8221;, "98&#8221;, "103&#8221;, "1000&#8221;] (integer comparison), not this ["1&#8221;, "1000&#8221;, "103&#8221;, "2&#8221;, "50&#8221;, "55&#8221;, "98&#8221;]  (string comparison)?” Enter Swift’s sorted function:

“Swift’s standard library provides a function called sorted, which sorts an array of values of a known type, based on the output of a sorting closure that you provide. Once it completes the sorting process, the sorted function returns a new array of the same type and size as the old one, with its elements in the correct sorted order. The original array is not modified by the sorted function.” Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l

This is exactly what we need to do the job here.
The Gist
Given the original array outlined above, we can create a new_ sorted_ array like this:
1let sortedArray = sorted(arrayOfIntsAsStrings, {
2    (str1: String, str2: String) -> Bool in
3    return str1.toInt() < str2.toInt()
4})
This code produces our desired output:  ["1&#8221;, "2&#8221;, "50&#8221;, "55&#8221;, "98&#8221;, "103&#8221;, "1000&#8221;]
The Details
Swift’s sorted function takes two arguments:  an Array, and a Closure.  The part that may be confusing is the closure argument.  Isolated it looks like this:
1{
2    (str1: String, str2: String) -> Bool in
3    return str1.toInt() < str2.toInt()
4}
Swift provides several shorthand forms of the closure syntax, but I’ve chosen the longest-form here just for full exposure and clarity.  The closure I’ve written simply needs to compute a Bool value representing the result of a comparison between two values – in this case, I’m wanting to do integer comparison, so I write this:  str1.toInt() and str2.toInt().
You can choose whatever parameter names you’d like, and you can actually rely on Type Inference in the parameter section — the compiler can work out what Types your parameters are.  But if it helps clue you in to what the code is doing, you can specify the Types in the closure’s parameter section, as I wrote about recently, and as I did in my example when I wrote str1: String, str2: String (I could have left off the : String).
Within the closure’s body, you can put in as many lines of logic as are necessary in order to produce an appropriate comparison result to get your Array in the right order.  If it gets too complicated to do it in-line, think about encapsulating that logic inside one or more functions in the spirit of writing clean code.
To produce an appropriate comparison result, you’ll have to consider the Types of the data you’re working with within the closure and consider any casting or manipulation you’ll need to do to produce the correct result like we did in our example. Other than that, it’s pretty straightforward to sort it out!


Clean Coding in Swift – Type Inference
Wed, 13 Aug 2014 04:22:25 +0000
Quick!  Tell me!  What is the Type of the birdDetailsconstant in this code example:
1let birdDetails = birdDetailsFromStorage()
With no additional context to glean information from, the correct answer to the question is, “I have absolutely no clue…”  Or is it?
“Not fair!”, you say.  “In the real world, I’d have the ability to option-click and learn the type from a pop-up tooltip, or learn this information by inspection from Xcode’s utilities panel.”
Truth.  We would.  But… should we have to for an example like the one above?  Could we have helped ourselves out a bit by being explicit about the type of birdDetails?
This was the question I asked myself as I set out to determine how and when I prefer to explicitly specify the Types of my variables and constants at declaration-time, rather than letting the compiler infer the Type for me.
Type Inference is powerful and convenient.  It enables us to leave off explicit type specifications when we declare a variable or constant, leaving us with nice, terse, clean-looking code.  But in reality, for examples like the one posed above, is clean-looking truly “clean code”?
From Apple’s documentation:

Type inference enables a compiler to deduce the type of a particular expression automatically when it compiles your code, simply by examining the values you provide.

The key phrase that stuck out to me was this:  “Type inference enables a compiler to deduce the type of a particular expression…”.  Humans are not compilers!
I don’t know about you, but I could use all the help I can get when it comes to figuring out simple things like the Type resulting from an expression.  Sure, I could rely on the IDE, but in debugging, or in trying to simply read and understand what the intention of my code is when I come back to it sometime later, I want to focus on the code, not on pop-up tool tips or inspector panels.
For instances where deducing the type is not simple for a human to do (and I mean really simple), I’m getting to where I prefer to specify the Type up-front.  We’re used to doing this in Objective-C, and I even do it in C# when using var would obscure things.  When a language gives me the option to be clear about Types, I try to take advantage of that valuable language feature for all but the simplest of situations.
The Simplest of Situations
Let’s think for a moment about this so-called “simplest of situations”.  I would define such a situation to be when the Type resulting from an expression can easily, at a glance, be inferred by a human being without assistance from an IDE.  It’s all about context here, and for these simplest of situations, I love Type Inference.
Compare the following two lines of code:
1let birdDetails = "Swift"
and
1let birdDetails: String = "Swift"
In the example just presented, typing “: String ” to explicitly specify birdDetails‘ type is superfluous in my opinion (and I prefer not to be repetitively redundant when I can).  It’s crystal clear that birdDetails in this example is a String.
However, in situations like the one at the beginning of the article where, by simply looking, I would have to answer, “I have no clue what the Type of this is”, my preference / proposal for your consideration would be to go ahead and specify the Type at declaration time.  Consider:
1let birdDetails: (genusSpecies: String, commonName: String) = birdDetailsFromStorage()
2
3
4//... somewhere else in a Swift file far, far away ...
5
6
7func birdDetailsFromStorage() -> (genusSpecies: String, commonName: String) {
8    return ("Apus apus", "Swift")
9}
When I’m writing this the first time, I can spend the time looking up the function’s return Type and specify it when I declare my constant.  It will make my life so much easier down the road.
Don’t stumble over the fact that birdDetails is a tuple type (String, String).  The point is that the function could have returned anything, and it would still have been impossible for me to tell you what the Type of the constant was just by looking, had I not specified it upon its declaration.
Being explicit about the type in the declaration has great potential to immediately help us get our bearings around a particular set of code when we return to it after any length of time.  And it seems to me that one of the principal goals of writing clean code is to help ourselves and our teams make sense of code quicker so that everyone’s happier and more productive.
Whew.  That was a long-winded exploration of some things to think about when relying on (or avoiding) Type Inference in your own code.  Thanks for reading!

Since publishing this op-ed, I’ve expanded my thoughts on Type Inference as it relates to clean coding practices in Swift.  I highly recommend that this post be read and considered alongside my latest musings,which were heavily influenced by Rob Napier’s comments below.

  
    You might also enjoy
  
  
    
      Clean Coding in Swift – Functions
    
    
      Expanded Thoughts on Swift's Type Inference
    
    
      Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
  



Clean Coding in Swift – Functions
Thu, 07 Aug 2014 18:16:23 +0000
I’ve been thinking a lot about how the principles of clean coding (Bob Martin’s “Clean Code”) apply in Swift. How do I express clean code in this language? Conversely, how do I avoid writing cryptic code in Swift? What language features help me write clear and self-explanatory code and what language features present the potential for tempting me to write obscure code in Swift?
I am beginning a commentary series that I hope will encourage clean coding practice in myself and in the Swift developer community. Dialog on these topics is welcomed – I have not “arrived”, so please – help me help the Swift community for the better!
The first in the series is on writing clean functions in Swift. As it turns out, Swift provides some really great mechanisms for defining self-explanatory, clear-purposed functions. We’ll start by analyzing the features around naming functions and their parameters, and will conclude on thinking through function decomposition.
Function Names
Something that I really enjoyed about Objective-C was that while method names were often long and verbose, they were extremely descriptive. My code often read like a narrative, and I enjoyed that. Some may have hated it, but I found it extremely helpful in facilitating my recollection of a method’s intended purpose and the expectations around its argument requirements.
I do my best to think hard about the names that I give my functions, ascribing to them a name that is specific, targeted, and focused on the single “thing” that each one does. Nothing in Swift mandates that we leave the verbosity of Objective-C naming conventions behind. In fact, the exact opposite is true!  One example is that swift intentionally provides us with the ability to add external parameter names so that we can be as descriptive as we need to be about the names of our functions.
Parameter Names
Swift’s external parameter names, in my opinion, are wonderful for helping write self-documenting code. They simply help guide my mind back to what a given function does and needs in order to do its job. Anything to help me get back in the zone is worth spending a few extra keystrokes on, especially since Xcode’s auto-completion assists me so well when calling functions with long signatures.
Apple recommends the following:

Consider using external parameter names whenever the purpose of a function’s arguments would be unclear to someone reading your code for the first time.

I would only add that sometimes, that someone “reading your code for the first time” is you. Not technically, of course, but think about this: Write some code, leave it, and come back to it some time later. Will it make sense? Will you immediately go, “Ah, I know what I meant there”, or will you do like I’ve often done and say, “WHAT in the WORLD was I THINKING??!?”.
Spending a few seconds on typing a few more words to save brain power and potentially more seconds/minutes some time later is a worthy investment. And if you work on a team, your teammates will appreciate the extra care you put in to providing as many hints as possible through inventing good names. Good naming includes parameter names. Why not take advantage of the fact that Swift provides you this opportunity to write self-documenting code?
Function Decomposition

In order to make sure our functions are doing “one thing”, we need to make sure that the statements within our function are all at the same level of abstraction. -Bob Martin, Clean Code pg. 36

This is just general advice without respect to a specific language. A couple of things to think about:

 Watch out for key words like “and” / “or” in your function names. These red-flag words often indicate that your function is doing more than one thing and can be further decomposed. Consider:

1func washAndDryCar() {
2    // Logic to wash and dry a car
3}
A preferred decomposition could look something like this:
1func washCar() {
2    // Logic to wash a car
3}
4
5func dryCar() {
6    // Logic to dry a car
7}

 Doing one thing can still involve multiple steps. But if each step takes a few steps of its own, that group of steps can be extracted out into another function. Consider:

1func washCar() {
2    // Pre-rinse code (example implementation - 4 lines)
3    // Soap code (example implementation - 5 lines)
4    // Rinse code (exmple implementation - 4 lines)
5}
A preferred decomposition might look something like this:
1func washCar() {
2    rinse(durationInSeconds: 25.0)
3    soapCar()
4    rinse(durationInSeconds: 60.0)
5}
What’s neat about the final result of the decomposition is that not only is my washCar function shorter and more readable (from 13 lines to 3 lines), but I got code re-use by making the rinse< function take a duration argument.
Hopefully these thoughts spark a few ideas in you.  Constructive feedback is welcome!  How are you thinking about writing clean code in Swift?

  
    You might also enjoy
  
  
    
      Clean Coding in Swift Type Inference
    
    
      Expanded Thoughts on Swift's Type Inference
    
    
      Pick a Delegate… Any Delegate… On Clean View Controllers in Swift
    
  



Fade In / Out Animations as Class Extensions in Swift
Sun, 27 Jul 2014 20:13:53 +0000
Updated on December 6, 2016 – Xcode 8 & Swift 3.0
The question has been asked (and solved) on StackOverflow in Objective-C, but my aim in this post is to take the Objective-C implementation and leverage Swift extensions to make this job even easier to achieve and reuse.
Fade animations basically involve adjusting a UIView‘s alpha value from 1.0 to 0.0 (fade out) or 0.0 to 1.0 (fade in) over a specified duration using some kind of easing option (like starting fast, then slowing down at the end of the animation, or starting slow and speeding up at the end of the animation).
I’ve published an example Xcode project to GitHub with the final working version of the code below if you’d like to just see it. Read on for the full explanation.
Edit: 2/23/2016 – A new idea flowing out of my Pluralsight Course involves a similar implementation, but using protocol extensions instead. This article’s implementation still works though, so feel free to check out either the contents of this blog entry, or the new one!

  
    New article using protocol extensions
  
  
    
       Fade Views In/Out with Fadeable – A Swift Protocol Extension
    
  


Fade without an extension
Below is an example of how my view controller may look if I want to click a button and have it fade out a label, set the text, and fade it back in again:
 1class ViewController: UIViewController {
 2    @IBOutlet weak var birdTypeLabel: UILabel!
 3    
 4    override func viewDidLoad() {
 5        super.viewDidLoad()
 6        // Do any additional setup that your app requires
 7    }
 8    
 9    @IBAction func updateBirdTypeLabel(_ sender: UIButton) {
10        // Fade out to set the text
11        UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseOut, animations: {
12            self.birdTypeLabel.alpha = 0.0
13            }, completion: {
14                (finished: Bool) -> Void in
15                
16                //Once the label is completely invisible, set the text and fade it back in
17                self.birdTypeLabel.text = "Bird Type: Swift"
18                
19                // Fade in
20                UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseIn, animations: {
21                    self.birdTypeLabel.alpha = 1.0
22                    }, completion: nil)
23        })
24    }
25}
What I don’t like about this implementation is that if I want to perform this same kind of animation again elsewhere in my app, I’ve got to write the bulk of that algorithm again each time I want to fade something in or out. I’d like it to be in one place for easier maintainability. I’d also like to be able to fade in / out simply by doing something like self.birdTypeLabel.fadeIn() or self.birdTypeLabel.fadeOut() optionally setting parameters for duration, delay, and completion. With these goals in mind, let’s see what Swift extensions provide us in terms of simplifying the process.

Refactoring using Swift extensions

Step 1 – Create UIViewExtensions.swift
Create a new Swift file and name it something like UIViewExtensions.swift

Step 2 – Move fadeOut and fadeIn to UIViewExtensions.swift
Use the previously-written fadeOut() and `fadeIn() algorithms in the new UIViewExtensions.swift file.
We can leverage what we wrote before with a few modifications. Take a look (I’ve written some comments to help identify some of the tweaks for the extension version):
 1import Foundation
 2import UIKit
 3
 4extension UIView {
 5    func fadeIn() {
 6        // Move our fade out code from earlier
 7        UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseIn, animations: {
 8            self.alpha = 1.0 // Instead of a specific instance of, say, birdTypeLabel, we simply set [thisInstance] (ie, self)'s alpha
 9            }, completion: nil)
10    }
11    
12    func fadeOut() {
13        UIView.animate(withDuration: 1.0, delay: 0.0, options: UIViewAnimationOptions.curveEaseOut, animations: {
14            self.alpha = 0.0
15            }, completion: nil)
16    }
17}
With this extension in place, we can now call self.birdTypeLabel.fadeIn() or self.birdTypeLabel.fadeOut() . To gain a little more control (if I so choose), I can outfit the fadeIn and fadeOut extension functions with parameters with default values defined so that I can call them with or without parameters as I need.

Step 3 – Provide parameters with default values
In Step 2, we simply hard-coded values for duration, delay, and completion. Below is the final version of the extension that provides parameters for you to (optionally) pass arguments to.
 1import Foundation
 2import UIKit
 3
 4extension UIView {
 5    func fadeIn(_ duration: TimeInterval = 1.0, delay: TimeInterval = 0.0, completion: @escaping ((Bool) -> Void) = {(finished: Bool) -> Void in}) {
 6        UIView.animate(withDuration: duration, delay: delay, options: UIViewAnimationOptions.curveEaseIn, animations: {
 7            self.alpha = 1.0
 8            }, completion: completion)  }
 9    
10    func fadeOut(_ duration: TimeInterval = 1.0, delay: TimeInterval = 0.0, completion: @escaping (Bool) -> Void = {(finished: Bool) -> Void in}) {
11        UIView.animate(withDuration: duration, delay: delay, options: UIViewAnimationOptions.curveEaseIn, animations: {
12            self.alpha = 0.0
13            }, completion: completion)
14    }
15}
With this now in place, the final version of my view controller becomes much simpler and clean:
 1import UIKit
 2
 3class ViewController: UIViewController {
 4    @IBOutlet weak var birdTypeLabel: UILabel!
 5                        
 6    override func viewDidLoad() {
 7        super.viewDidLoad()
 8        // Do any additional setup that your app requires
 9    }
10    
11    @IBAction func updateBirdTypeLabel(_ sender: UIButton) {
12        self.birdTypeLabel.fadeOut(completion: {
13            (finished: Bool) -> Void in
14            self.birdTypeLabel.text = "Bird Type: Swift"
15            self.birdTypeLabel.fadeIn()
16            })
17    }
18}
By employing Swift extensions to encapsulate the fade in / out animation logic, I was able to

Define the animation logic in one place for easy maintainability
Make my view controller’s code simpler and clean
Provide a more natural way to perform the animation on any UIView instance by simply calling fadeIn() or fadeOut()
Give myself the option to specify a different duration, delay, or completion closure if I need extra control



  
    You might also enjoy…
  
  
    
       Fade Views In/Out with Fadeable – A Swift Protocol Extension
    
    
       The 5 W’s of Swift Extensions
    
    
       Slide In Animation in Swift
    
    
       Rotate Animation in Swift
    
  




Swift Optionals?  Don’t Forget to Unwrap!
Sat, 26 Jul 2014 02:23:53 +0000
There is a compiler error that throws me off every time I see it.  It takes the form,

‘ClassName?’ does not have a member named ‘memberName'

This can happen when you’ve declared a variable as an optional, but forget to unwrap that optional when you attempt to call a method on it.
For example, given this class definition:
 1class Bird {
 2	var family: String
 3	var color: String
 4 
 5	init(family: String, color: String) {
 6		self.family = family
 7		self.color = color
 8	}
 9 
10	func isSwift() -> Bool {
11		return self.family == "Apodidae" ? true : false
12	}
13}
If, say in a ViewController, I declare a variable that I intend to reference an optional Bird instance like this:
1var birdInstance: Bird?
And then I later initialize this variable with a Bird instance, perhaps in viewDidLoad() :
1birdInstance = Bird(family: "Apodidae", color: "Black")
If I attempt to invoke the isSwift method on the birdInstance later  on, I’ll get a compiler error:
1println(birdInstance.isSwift())

error: ‘Bird?’ does not have a member named ‘isSwift'

This may seem pretty basic — after all, I declared the birdInstance as an optional and I know optionals need special treatment.  How could I make this mistake??  Perhaps this is just a consequence of my current stage in life, trying to code in 15-30 minute spurts with my 1 1/2 year old running around, haha.
We all deal with this though:  it’s fairly easy to write some code and come back to it later and not remember how you declared your variable in an earlier coding session.  Then when you’re presented a message saying that your class doesn’t have a member named “___”, you immediately go to the class definition and see the function there, plain as day.  It’s easy to spend 3-5 minutes scratching your head thinking, “What in the world??!” … And then you realize – it’s that optional declaration that you forgot to handle.
To fix this, of course, you can do any number of things, depending on your situation.
Force unwrap the optional and invoke the method:
1birdInstance!.isSwift() // Force unwrapped -- **CAUTION** make sure that birdInstance gets instantiated before you do this,&nbsp;or you'll get a runtime error
Employ optional chaining and invoke the method:
1birdInstance?.isSwift()
Declare the variable as implicitly unwrapped optional, then invoke the method later without extra exclamation or question marks:
1var birdInstance: Bird! // Implicitly unwrapped -- **CAUTION** make sure that birdInstance gets instantiated before you use it, or you'll get a runtime error
2birdInstance = Bird(family: "Apodidae", color: "Black")
3
4// Some time later, invoke isSwift
5
6println(birdInstance.isSwift())
A blog post by Peter Witham over at CompileSwift was the article that caused me to think, “OH!  I haven’t done anything with my optional…that’s the problem”.  Credit to you, sir, for your post!


Swift Access Control – Implications for Unit Testing
Wed, 23 Jul 2014 04:04:43 +0000
If you find yourself with broken unit tests, failing to build with the error, “Use of unresolved identifier…”, you’re not alone!
Unit Tests and Swift Access Control
When Swift access control came into the picture, we suddenly had a little more to consider. From the Apple docs:
Swift access control has three access levels:

private entities can only be accessed from within the source file where they are defined.
internal entities can be accessed anywhere within the target where they are defined.
public entities can be accessed from anywhere within the target and from any other context

that imports the current target’s module.

By default, most entities in a source file have internal access.

So given the following…

Out of the box, your unit tests are part of a separate test target
The default access control for a class is internal, (meaning that if you do not explicitly specify an access control on the class / properties / functions, they’re marked internal behind the scenes)

… we now know why the unit tests break, unless we make a few tweaks:  classes marked internal are only seen within a set of specified targets and our unit tests are in a separate target that our class is not a part of by default.
Options
It seems to me that we have two options:

Change the access control on our class to public.  Additionally, mark any methods we intend to test with public also.
Add the class(es) you want to be able to write unit tests for to the tests target.

Solution
I found option #2 to be the easiest to implement at first. However, it turns out that this can lead to some really obscure issues. An enlightening Twitter conversation also shed some light on the subject, and pointed to the solution of testing only publicly accessible behavior that your Types expose, rather than trying to test internal implementation. That probably deserves a blog entry of its own, but for now, I’ll leave it to say that I’d recommend not adding your .swift source files to your test target, but rather to adjust the access control modifiers of the things you want to test to public (ie, Option # 1).

  You might also enjoy 
  
    
      Don't Write Legacy Swift
    
    
      Getting Started with Unit Testing in Swift
    
    
      Swift Unit Testing Resources
    
    
      TDD for iOS in Swift – What’s the Goal?
    
  



Implement NSManagedObject Subclass in Swift
Fri, 18 Jul 2014 04:08:12 +0000
Updated on July 8, 2016 – Xcode 7
My goal with this blog entry is to help get you set up to create NSManagedObject subclasses in Swift for the Entities in your Core Data model.

Example
Let’s look at a fabricated example: Say that you’ve got a Core Data project and you’re creating Entities.  For my simple project, I’ll create an Entity called “MyEntity” with an attribute called “myAttribute”.
After you create an NSManagedObject subclass for the Entity and come back to the data model screen to specify the “Class” in the inspector area, you must prefix the name of the class with “YourProjectName.” (don’t forget the dot).  Forgetting to do this will lead to run-time errors when you start interacting with instances of your NSManagedObject subclass.
Apple specifies this in their documentation page, but it was a subtle mention at the end of the document and I just happened upon it as I was troubleshooting this:

Swift classes are namespaced—they’re scoped to the module (typically, the project) they are compiled in. To use a Swift subclass of the NSManagedObject class with your Core Data model, prefix the class name in the Class field in the model entity inspector with the name of your module.


Walk-through

Create an Entity
In your .xcdatamodeld file, create an Entity to your liking.  In my example, I named the Entity “MyEntity” and I gave it an attribute called “myAttribute” with a data type of String.



Create an NSManagedObject Subclass for that Entity
On the Menu, click Editor, then “Create NSManagedObject Subclass…”


Make sure you choose “Swift” as your language of choice as you click Next through the wizard and Xcode will generate you a file that is appropriate for your Entity.  The files it created for me (Xcode 7.1.1) look like this:



Verify NSManagedObject class in the “Data Model Inspector”
Make sure that you have your .xcdatamodeld file selected in the Navigator panel.  Then make sure your Utilities panel is visible.
Click the “Data Model Inspector” icon.  This will be the last icon in the inspector of Xcode.  You should see a section for “Entity” and within this section, two textboxes:  one for Name and one for Class. You should also see a drop-down for the Module that the NSManagedObject subclass is found in.
You’ll be verifying the Class and the Module values:

According to the Swift documentation, Swift class namespaces are scoped to the module they’re compiled in (usually the project you’re working in).  
To use the NSManagedObject subclass in your project, you just need to verify that the Module setting is set to “Current Product Module”, assuming that the NSManagedObject subclass you’re wiring this Entity to is found in that module. If it’s in another module, you’ll need to adjust the Module value in the inspector appropriately.
Once the Class and Module values are verified (or set), you’ll be able to use this NSManagedObject subclass anywhere in your project.


  
    You might also enjoy…
  
  
    
       Core Data Cheat Sheet for Swift iOS Developers
    

    
       Using Swift to Seed a Core Data Database
    

    
       Displaying Data With NSFetchedResultsController and Swift
    

    
       Sync Table View Data: NSFetchedResultsController and Swift
    

  




  
    Resources
  
  
    
       Core Data Fundamentals with Swift
 
    
  




How to Create Mocks and Stubs in Swift
Tue, 15 Jul 2014 05:12:16 +0000
Without 100% support for a mocking framework like OCMock, I found myself needing to get creative when building mock objects and method stubs in Swift unit tests.  The great thing about testing is that you’re…well… testing things out to see if they’ll work, and I found a solution that I’m pretty happy with for now.  I’m open to better ways, so leave a comment if you’ve had good results using a different design!
The process is essentially this (example to follow):

Ensure that the class that you would like to test is designed so that you can substitute your mock for the real one that’s used in your class’ implementation
Create an XCTestCase  class with a test function in your unit test project
Within the function body create a nested class
Make the nested class inherit from the real object you’re trying to mock / create a method stub for
You can give the nested class a name such as Mock[ObjectName]
Configure the mock object however you need by setting its properties or overriding its function implementations with stubbed implementations – no need to override every function… only the one(s) that your class calls during the test at hand
Instantiate the class you’re testing and pass in an instance of the mock object you just nested in the test function to your class somehow (either through its initializer, by setting a property on the class, or by passing it into the method under test via parameter — however you intended to ‘inject’ the mock from step 1 is what you should do)
XCTAssert…

Let’s see those 8 steps in action for those of us who are more visually inclined.
EDIT:  July 22, 2014 – I’ve added a simple Xcode Project to GitHub for those interested in seeing the setup directly in Xcode at  https://github.com/andrewcbancroft/MocksAndStubs
The scenario that I’d like to use a mock class in is this:  I have a CoreData application and I’d like to be able to mock the NSManagedObjectContext  so that instead of making actual database fetch requests, I can just provide stubs of various sorts with the kinds of responses I’d expect from the real database calls to ensure my class will do the right thing based on predictable results.  To do this I begin at step 1…
1.  Ensure that the class that you would like to test is designed so that you can substitute your mock for the real one that’s used in your class’ implementation
In the example class below, I intend to provide the NSManagedObjectContext  dependency through the class’ initializer which will set a property that is used by my class’ methods later on, but you could easily use some other way of performing “dependency injection”.  The initializer strategy just makes it super clear in my mind what the class’ dependencies are, so that’s what I’m going to do here.  Have a look:
 1import Foundation
 2import CoreData
 3
 4class MyClass {
 5    let context: NSManagedObjectContext
 6    
 7    init(managedObjectContext: NSManagedObjectContext) {
 8        self.context = managedObjectContext
 9    }
10}
Now, let’s say that my example class has a member function called databaseHasRecordsForSomeEntity  that returns a Bool  value of true if the resulting array of a fetch request contains objects, and a Bool  value of false if the result array of a fetch request is empty.  The completed class looks like this:
 1import Foundation
 2import CoreData
 3
 4class MyClass {
 5    let context: NSManagedObjectContext
 6    
 7    init(managedObjectContext: NSManagedObjectContext) {
 8        self.context = managedObjectContext
 9    }
10    
11    // If the array returned from executing a fetch request contains objects, return true; if empty, return false
12    func databaseHasRecordsForSomeEntity() -> Bool {
13        let fetchRequest = NSFetchRequest(entityName: "SomeEntity")
14        let fetchRequestResults = self.context.executeFetchRequest(fetchRequest, error: nil) // May want to do something with the error in real life...
15        return (fetchRequestResults?.count > 0)
16    }
17}
I want to test if databaseHasRecordsForSomeEntity  does what I intend it to do. So…
2.  Create an XCTestCase  class with a test function in your unit test project
Just listing this for completeness
Next comes the way to make the mock.  Read steps 3-5 and then look below for a code example of what the skeleton will look like.
3.  Within the function body create a nested class
4.  Make the nested class inherit from the real object you’re trying to mock / create a method stub for
5.  You can give the nested class a name such as Mock[ObjectName]
 1import UIKit
 2import XCTest
 3import CoreData // <-- Make sure to import CoreData or you will get errors when you try to use NSManagedObjectContext
 4
 5class MyClassTests: XCTestCase {
 6
 7    override func setUp() {
 8        super.setUp()
 9        // Put setup code here. This method is called before the invocation of each test method in the class.
10    }
11    
12    override func tearDown() {
13        // Put teardown code here. This method is called after the invocation of each test method in the class.
14        super.tearDown()
15    }
16
17    // Yay for verbose test names!  :]
18    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
19        class MockNSManagedObjectContext: NSManagedObjectContext {
20            
21        }
22    }
23}
 6.  Configure the mock object however you need by setting its properties or overriding its function implementations with stubbed implementations – no need to override every function… only the one(s) that your class calls during the test at hand
For my example, I’m going to stub out the executeFetchRequest  method so that it returns an array with one object in it.  This is really the part where you have to determine what you’re testing and what you expect the stubbed results to be.  Whatever you decide, the way to stub a method is simply to override it in the mock you’re implementing.  Here’s how I implemented the executeFetchRequest  stub for my example:
1// Yay for verbose test names!  :]
2    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
3        class MockNSManagedObjectContext: NSManagedObjectContext {
4            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
5                return ["object 1"]
6            }
7        }
8    }
We’re ready to perform the test and assert the results.  Read steps 7-8 and take a look at the code example below step 8:
7.  Instantiate the class you’re testing and pass in an instance of the mock object you just nested in the test function to your class somehow (either through its initializer, by setting a property on the class, or by passing it into the method under test via parameter — however you intended to ‘inject’ the mock from step 1 is what you should do)
8.  XCTAssert…
From step 1, I intended to pass an NSManagedObjectContext instance to the initializer of MyClass, so that’s what I’ll do in my test.  I’ll then perform the XCTAssert on the return value of my method under test:
 
 1// Yay for verbose test names!  :]
 2    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
 3        class MockNSManagedObjectContext: NSManagedObjectContext {
 4            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
 5                return ["object 1"]
 6            }
 7        }
 8        
 9        // Instantiate mock
10        let mockContext = MockNSManagedObjectContext()
11        
12        // Instantiate class under test and pass it the mockContext object
13        let myClassInstance = MyClass(managedObjectContext: mockContext)
14        
15        // Call the method under test and store its return value for XCTAssert
16        let returnValue = myClassInstance.databaseHasRecordsForSomeEntity()
17        
18        XCTAssertTrue(returnValue == true, "The return value should be been true")
19    }
Running the tests at this point should produce a passing test using the mock object in place of a real NSManagedObjectContext that calls a database!
Now, if I wanted to test the “false” branch of my class’ method, I could simply create another test method following the same steps, only this time, I’d provide a new implementation for the overridden executeFetchRequest  method that’s appropriate:
 1func testDatabaseHasRecordsForSomeEntityReturnsFalseWhenFetchRequestReturnsEMPTYArray() {
 2        class MockNSManagedObjectContext: NSManagedObjectContext {
 3            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
 4                return [] // Provided a different stub implementation to test the "false" branch of my method under test
 5            }
 6        }
 7        
 8        // Instantiate mock
 9        let mockContext = MockNSManagedObjectContext()
10        
11        // Instantiate class under test
12        let myClassInstance = MyClass(managedObjectContext: mockContext)
13        
14        // Call the method under test and store its return value for XCTAssert
15        let returnValue = myClassInstance.databaseHasRecordsForSomeEntity()
16        
17        XCTAssertTrue(returnValue == false, "The return value should be been false")
18    }
And that’s a wrap – happy mocking and stubbing in Swift!
EDIT:  July 22, 2014 – I’ve added a simple Xcode Project to GitHub for those interested in seeing the setup directly in Xcode at  https://github.com/andrewcbancroft/MocksAndStubs

  You might also enjoy 
  
    
      Don't Write Legacy Swift
    
    
      Swift Access Control – Implications for Unit Testing
    
  



iOS KeychainItemWrapper – Obstacles Overcome, Inconsistencies Resolved
Wed, 21 May 2014 18:20:56 +0000
I had a major case of “struggleface” when trying to work with the KeychainItemWrapper  for iOS.  I wanted it to be simple – just take a username and password and put it in the iOS Keychain for secure retrieval later.  Turns out that I had to spend an entire work day and do a lot of Googling to get it working so I’m posting this to try and bring all the pieces together.
Obstacle #1:  Automatic Reference Counting (ARC)
My project uses ARC for its memory management.  As it turns out, the KeychainItemWrapper  class from Apple does not support ARC out of the box.  Step one for me should have been to find an ARC-friendly version of the class, but I had no idea until I got in there.  I attempted to retrofit the one provided by Apple, but there are a few nuances with toll-free bridging that I don’t fully understand, so I went in search of someone who’s already invented the wheel.  There’s a GitHub Gist repository that provided exactly what I needed:  KeychainItemWrapper ARCified
Obstacle #2:  Error Message Obscurity
Somehow in my novice experimentation with storing credentials in the keychain I ended up getting a keychainItem  on the keychain for a particular test user that couldn’t be updated or removed.  I kept getting a cryptic error code (–25299) as I debugged the app when attempting to sign in with that user’s credentials.  I spent…well…too long trying to find what the keychain error codes meant.
While I started off reviewing the Keychain Services developer documentation page, I didn’t see the section describing the result codes.  This is the section that was most helpful in determining what “-25299” meant:  errSecDuplicateItem  – The item already exists.  In my case, the item was in there but the keychain search method didn’t find it, so it tried to add it again, causing a “duplicate keychain item” error message.
Inconsistent Behavior
Eventually I got things to store to the keychain fine for some test user accounts but my primary test account (the one I started with at the beginning of the day) still ran into the “duplicate keychain item” error no matter what I tried.  Signing out of my app didn’t work.  Sending a resetKeychainItem  message to my KeychainItemWrapper  instance didn’t work.  Even deleting the app from the simulator didn’t work.  I ended up just needing to reset my simulator completely.  This was simple to do:
iOS Simulator -> Reset Content and Settings…

Things began to work perfectly after the reset.  Unfortunately, I spent the majority of the day spinning over the error message trying to find ways to programmatically either remove the keychainItem  or reset it so that it would no longer be a duplicate.  I’d have been finished hours earlier if I would have just reset the simulator.  In fact, since I reset the simulator, I’ve been unable to reproduce the scenario I’d gotten myself into.  Otherwise I would list the obstacles I was trying to work through for the rest of the day as well.
As far as I can tell, it was all stemming from whatever I did at the beginning of the day to get the malformed keychainItem  in the keychain.  The simulator reset did the trick.
Commit.

Breathe.

Go home happy.


How Old is Silas Allen?
Sun, 31 Mar 2013 14:36:07 +0000
“Ooooohh, now… how old is he??”  I love this question.  Really!  I do!  Every time I’m asked I get to talk about my kid, and that’s always fun.  But today, things just got even more fun.  Now, instead of just telling people his approximate age, I can show them his precise age down to the second!
As some of you know, I’ve been nerding out on learning to build iOS apps for iPhone and iPad.  Well, to celebrate Silas turning another month old, I built a little app that tells me how many years, months, weeks, days, hours, minutes, and seconds he is old.  I also built in functionality so that I can see how much longer it will be until his birthday (actually, I think I just thought of a bug with that part, but it won’t show itself until 2014 so I have time…it shouldn’t be nearly as bad as the Y2K panic – but date math is non-trivial, just so you know). _

_
And yes, for those of you who are just as OCD as I am, I did consider the fact that he was born at 12:06 AM (sorry…they didn’t give us the exact millisecond of his debut or I’d have that in there too).
Check out this video of the app showing his age as he turned 3 months old this morning!
Silas Allen Turns 3 Months Old! from Andrew Bancroft on Vimeo.


Journey in iOS Development Series – In the Beginning…
Sat, 16 Mar 2013 19:51:59 +0000
Today I’m starting a series related to my journey in learning to develop iOS apps. As lightbulbs come on for me, I plan to write up what I’m learning, if nothing else for my own reference. But I do hope my readers enjoy the discoveries I make along the way.
These first few blogs will be somewhat autobiographical, so hopefully I don’t bore you to death. I’ll try and make them quick. More technical stuff will appear very soon. I thought to write a short article about how I got started. If I had an “In the beginning…” moment, what would that be?
The Early Days
It seems like just yesterday I was a little boy visiting my Grandpa’s house in Lawton, OK, eager to play on Grandpa’s computer. Computers in the early 90’s were still not quite the commodity they are in 2013. We didn’t own one yet, but Grandpa did.
If I had to point to an “In the beginning…” stage, it’d be the times when Grandpa sat down with me and taught me about computers. Not just games (although I did enjoy Submarine and Wheel of Fortune for DOS a lot) – he taught me the basics of how to instruct a computer.  He taught me to program. He was a Master of DOS and a QBasic Guru. If I had to guess, he still prefers elements of both today. :]
He is, quite simply, an amazing man. He is now a retired entrepreneur, but when he was running his music store there were always those “things that needed to be done”.  He viewed the “gotta do it’s” as an opportunity to automate by programming a computer to do it for __him, rather than do it by hand. He’s showed me how he programmed apps to produce his financial statements, track his budget, print invoices, and all kinds of other “by hand” stuff that he was able to make “automagically” with a computer. It was (and still is) fascinating to me.
In addition to those early years of influence, I’ve learned from Grandpa that even though “there’s an app for that” already, it doesn’t mean it’ll work for you how you want it to work. Grandpa could be happy with 99% of an app’s functionality, but there’d always be that one thing that bugged him. What did he do? He wrote his own. He made it work how he wanted it to work. He may not have been inventing a new wheel every time, but because he could program, he could improve the existing wheel to his liking.
All of this has served to motivate me in my pursuit of programming in general.  I love my Grandpa.  My Grandpa loves computers.  The little kid inside of me is yelling, “Me too!  Me too!” to this day.
My Grandpa just turned 81 and he still loves the computing world.  It’s been great fun to watch him use his latest computer: his iPhone.  It’s been even more fun to show him the little apps I’m making as I learn to program for iOS.
Next up will be a post on how I’ve approached learning to program for iOS.  What’s my strategy and how is it going so far?  See you again soon with all that and more.