BJ Miller's Blog

Hopefully, it’s not often (or never) that you have that feeling. Hopefully you know what every line of code is doing. For this reason, I really dislike bringing in dependencies, but when I do, I read them line by line to understand what they do.

Recently I started a new project for a client that needed my same old email address validation (you know the one, probably the same one you yanked from Stack Overflow, too) and I thought to myself, “this regular expression makes me want to ball up in a corner and cry.” I needed a better way, so I started researching NSRegularExpression and how it can be used, but then stumbled upon a neat subclass of it called NSDataDetector.

NSDataDetector utilizes regular expressions under the hood so that you don’t have to, and has different commonly used types such as link, phone number, or address detection. Sadly, there isn’t an email address detection option. But…inspecting the data results landed me a pretty good mechanism for detecting email addresses.

The Code

I’ll start with the code and then explain it shortly (and then fix it later, stick with me).

01: func isValidEmailAddress(text: String) -> Bool { 02: let types: NSTextCheckingType = [.Link] 03: let linkDetector = try? NSDataDetector(types: types.rawValue) 04: let range = NSRange(location: 0, length: text.characters.count) 05: let result = linkDetector?.firstMatchInString(text, options: .ReportCompletion, range: range) 06: let scheme = result?.URL?.scheme ?? "" 07: return scheme == "mailto" && result?.range.length == self.characters.count 08: }

The Breakdown

First, I created a function to validate whether a given string was a valid email address or not, as you can see on line 1. Then on line 2, we need to create an array of types to check. In this case, we only want to check the .Link type, but it still needs to be an array, even though the type is NSTextCheckingType. In Objective-C you would use the | (bit-wise OR) operator to combine several different types at the same time, but in Swift, you use an option set, and feed in an array literal.

Next, on line 3, create the data detector and pass in the types.rawValue argument to the types parameter. This could throw an exception, hence why we use the try? keyword. But notice that I didn’t catch any errors thrown – I really don’t care about any error that’s thrown. This should never fail, but if it does, something else much larger is at fault here which I don’t care about in this method, and so this keeps the code cleaner. Also note: linkDetector is now optional, due to the try? keyword.

Line 4 is pretty self-explanatory, we create a range constant that just contains the start and end of our text range. Line 5 then generates a result by asking the linkDetector for the first match in the given string for the range. firstMatchInString(_:options:range:) is a method from NSDataDetector’s superclass, NSRegularExpression. It returns an instance of NSTextCheckingResult, which has all sorts of properties we can check for validity. One of those properties is URL.

Checking the URL property, we can then inspect the scheme. This is ultimately what we want to validate. Does the scheme property begin with mailto? If so, our data detector has detected that we have a valid email address, and we can return true. If not, false, as seen on lines 7 and 8. (UPDATE: Thanks to @scottrobbinsios, I’ve appended the return line to include some more validation to ensure the entered string is the exact length of the email address, avoiding something like “foo [email protected]” with a space. In this case, [email protected] is valid, and is the first returned match, but the length does not match, so it now returns false for invalid.)

The Extension

If you have any experience with Swift, you’d have immediately recognized that this method would be better used in an extension on String than in a method that isn’t geared for reuse. And, you’d be correct. Also, if this is an extension on String, there really is no need to pass a String parameter, so there’s no need for this to be a function. Instead, we can turn this into a computed property. Correct again.

01: extension String { 02: var isValidEmailAddress: Bool { 03: let types: NSTextCheckingType = [.Link] 04: let linkDetector = try? NSDataDetector(types: types.rawValue) 05: let range = NSRange(location: 0, length: self.characters.count) 06: let result = linkDetector?.firstMatchInString(self, options: .ReportCompletion, range: range) 07: let scheme = result?.URL?.scheme ?? "" 08: return scheme == "mailto" && result?.range.length == self.characters.count 08: } 09: }

Notice that where we used text before, we now use self, since self refers to the current String instance. By creating this extension, we can ask any String instance if it is a valid email address, which makes it super convenient. Like this:

// for a login screen... let text = emailTextField.text ?? "" let valid = text.isValidEmailAddress // to see differences... let goodEmail = “[email protected]”.isValidEmailAddress // true let badEmail = "foo [email protected]".isValidEmailAddress // false

Wrap Up

Failable Casts

You can now use the as! operator to forcibly downcast one object as another type, with the knowledge that at runtime it may fail and crash the application. Sometimes this is ok to use, as it removes the need for if let binding, or a really awkward nil coalescing expression. For example, you may have a segue to another view controller, and it is the one and only view controller that segue will ever go to. In that case, I believe it is ok to downcast segue.destinationViewController as! YourDestinationViewController. In other cases, it may be better to play it safe with as?.

Multiple if let bindings on a single line

This is huge. Rather than a nested series of if let statements to continually unwrap optional values to finally get to a set of unwrapped values, you can now do it all in one line, separating each binding assignment with a comma, and even use unwrapped values inside the expression before getting to the success case’s closure. You can also have trailing where clauses which may or may not include unwrapped values, as well as a leading condition to check if the binding should even happen. For instance: if sky == "blue", let uperson = person, udog = uperson.dog where udog.age > 2 { ... }

Nullability in Objective-C Headers

This is a really cool optimization that was included in Objective-C. These are covered in the video series, but are not included in the book; the book will have these updates in the second edition. Basically, they are compiler annotations to assist in knowing what reference pointers can be nil and which ones can’t. * nonnull - the reference will never be nil, so in Swift the type is non-optional. * nullable - the reference can be nil, so in Swift the type is optional. * null_resettable - the reference can be reset back to nil, but once set to nil, will immediately have a default value assigned. Because it can be assigned to nil at some point in that process, but safely accessed henceforth, it is an implicitly unwrapped optional in Swift. * null_unspecified - Apple suggests using this in the transitionary period where you are opening Objective-C code to Swift inside your project, and is also an implicitly unwrapped optional in Swift.

Constant Assignment

Constants assigned with the let introducer can not be defined with a type but not immediately assigned a value. This is great for when you want a value to be constant, but you don’t yet know what its value is. Constants are now a write-once value.

New Set Struct

Swift 1.2 brings a new data type: Set. A set is an unordered, unique set of values. Think of a set like an array, but without any indexes, and no element can be duplicated. It even conforms to the ArrayLiteralConvertible protocol, so you can assign values from an array directly into a set. If there are duplicates in the array, the set will only save one of them.

flatMap Function

Wrapping up the changes in Swift is the addition of flatMap to the Standard Library. The flatMap function is actually implemented for two things: arrays and optionals. To use on an array, you will see the most benefit of flatMap when you have arrays of arrays, and need to get a single-level array out of it. For instance, [["a", "b"], ["c", d"]] becomes ["a", "b", "c", "d"].

For optionals, flatMap removes one layer of optional, such as Int?? (or Optional<Optional<Int>>). On a single-optional value, it can map a function over the unwrapped value inside

Conclusion

I will post more as more changes come, so stay tuned for more updates. Also any time I write a post like this, I’ll link to it from the ReadMe’s of the book and video repositories on GitHub.

I’ll create an example using UITableViewController, but this should be applicable to any class that uses the protocol paradigm for communicating back to another object for delegate and data source information or requests. The completed code is available on GitHub, if you would like to download it.

The Setup

Create a new Single View Application Xcode project, and name it KeepItSeparated. I will be using Swift as my language, but feel free to use Objective-C; the concepts apply just the same. Save the project to a directory of your choosing and click Create.

Select ViewController.swift in your project navigator and delete it. Next, open Main.storyboard, select the View Controller scene and delete that too. The storyboard should have an empty canvas now. I did this for this example so we could start with a clean UITableViewController versus a UIViewController. Often times, I will use a plain UIViewController with a UITableView inside it because I need other elements to control that I gain better flexibility with by using a UIViewController, but for this demo, a UITableViewController will suffice.

Press ⌘N to create a new file. Choose iOS then Source from the left-hand pane, and then double-click Cocoa Touch Class.

Name the class ItemsTableViewController, and select UITableViewController in the Subclass drop-down menu. 

Click Next.

Ensure the KeepItSeparated group is selected in the Group drop-down, and the KeepItSeparated target is selected in the Targets list of checkboxes.

Click Create.

Clean It Out

Here comes some fun. If you're like me and like deleting code almost as much as writing it, this step is for you.

Select all the code inside the ItemsTableViewController class, except for viewDidLoad, and delete it all. 

...

Doesn't that feel good?

While you're at it, remove all the comments inside viewDidLoad, so it should only call its super class's implementation. Your class should look like the following figure:

Create A Data Source

For this blog I'll only show creating the data source file, but the exact same steps can be followed to make the delegate class as well.

Press ⌘N again to create a new file, and select an iOS Swift file, and then click Next. Name the file ItemsTableDataSource, and then click Create.

By default, your file only contains an import statement. Change Foundation to UIKit.

Our data source needs to do the following things:

Subclass NSObject

Adopt the UITableViewDataSource protocol

Add a variable to store data

Conform to the UITableViewDataSource protocol

We have to subclass NSObject because of how we will have to hook our data source up to our storyboard, which you'll see in a moment. "Couldn't we have just created a Cocoa Touch Class instead of a Swift file?" Yes. 

We can do steps 1 and 2 together in one line, so do that first. Create the class, make it a subclass of NSObject, and adopt the UITableViewDataSource protocol.

class ItemsTableDataSource: NSObject, UITableViewDataSource { }

Next, we need a variable to store our data in our data source class. Create a variable array of String instances, and use its empty initializer.

var items = [String]()

Lastly, we have to conform our class to the protocol. We only need three methods, so add these to your class:

func numberOfSectionsInTableView(tableView: UITableView) -> Int {     return 1 }     func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {     return items.count } func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {     let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as UITableViewCell     cell.textLabel?.text = items[indexPath.row]     return cell }

Prepare The Interface

Select your storyboard file, which should be empty. Drag a Table View Controller onto the canvas. With the new Table View Controller selected, press ⌘⌥3 to open the Identity Inspector. Change the Class to our subclass of UITableViewController, ItemsTableViewController. 

Next, select the Table View Cell (sometimes it's easier from the Document Outline).

With the cell selected, press ⌘⌥4 to show the Attributes Inspector. In the Identifier field, enter "Cell" (without the quotes). This will set the cell's reuse identifier to be used in our table view's queue of reusable cells.

Last thing we need to do to prepare the interface before we get into the meat of changing the data source to our own custom data source is to ensure our table view controller is the initial view controller. When we removed the default view controller from the storyboard, it also removed the "initial view controller" arrow. If you look at your table view controller on the storyboard canvas, there is no right-pointing arrow to the left of your view controller. Select your table view controller and press ⌘⌥4 to show the Attributes Inspector. Under the View Controller section, check the box that says "Is Initial View Controller". This tells Xcode that this view controller is our starting point.

Hook It Up

Now we are finally ready to connect our custom data source class as the table view's data source. There are three things we need to do to make this happen:

Drag an NSObject from the Object Library onto your view controller

Change the NSObject's class to your data source's class

Remove the table view's existing data source pointer and add yours

First, open the Object Library (⌘⌥^3), and search for NSObject.

Drag that Object onto your view controller's top bar (along side the View Controller, First Responder, and Exit icons) and drop it there. You'll see the green icon with a plus sign indicating when it is OK to drop the Object.

With the Object item selected in the table view controller's bar, open the Identity Inspector (⌘⌥3) and change the class from NSObject to ItemsTableDataSource.

With the first two steps done, the last thing we need to do to our interface is to remove the existing data source outlet and wire it up to our own class. Right-click (or two-finger tap on a trackpad) the Table View in the document outline, and click the small 'x' next to the data source.

NOTE: If you are making your own delegate along with this tutorial, feel free to remove the delegate also, and then follow the exact same steps to wire up your custom delegate class.

With the black menu window still open, drag from the data source's now empty circle on the right side over to your ItemsTableDataSource in the document outline to connect the outlet.

Save your storyboard and switch back to the ItemsTableViewController.

Feed Your Data Source

Let's give your data source some data so we can see the fruits of our labor. In ItemsTableViewController, add the following code to your viewDidLoad method. In your actual app, you may need a different method in your view controller lifecycle, such as viewWillAppear(animated:), but for our purpose viewDidLoad will suffice.

override func viewDidLoad() {     super.viewDidLoad()     let dataSource = tableView.dataSource as ItemsTableDataSource     dataSource.items = ["Good morning", "Hello", "Bonjour", "Ciao", "Good morning"] }

Build and Run

Press ⌘R to build and run your app. You should now see your list of items in the table view as expected, and the warm fuzzy feeling inside knowing that your view controller has none of that code in it. Of course, this looks terrible because the cells interfere with the status bar, but that's because I didn't embed it in a Navigation Controller. 

Summary

This article showed you how to separate out your data source (and delegate by the same process) of a table view from your view controller in an effort to reduce the size of your view controller. You learned how to create a separate class for your data source, conform it to the appropriate protocol, and add the relevant methods you need. Then you saw how to adjust the interface to use an NSObject in the storyboard, changing the class to be your data source class, and then wiring that up to be your table view's data source. Lastly, you saw how to feed your data source with data from your controller. 

In short, constants cannot change once initialized to a value, and variables can change at any time during their existence. Constants are declared with the let keyword, and variables with var. As you may know, type is inferred in Swift, so these are assumed to be of type String. Here's a simple example:

let str = "Hello, playground" str = "this will produce an error"

Line 1 declares a constant str and sets it to "Hello, playground". Being a constant, it cannot be altered. Right? Sure, as you can see in Line 2, trying to assign str to another value gives an error. That's because the new String, "this will produce an error" is a different String value, and str cannot be changed to it.

Arrays

But the initial issue was really revolving around Arrays. In Apple's eBook for the Swift Programming Language, the very last page of the "Collection Types" chapter details this behavior. Now, I must state that I'm not necessarily "backing" this behavior, as it seems odd to me too, but only perhaps because I'm thinking about immutability in the context of what other languages define as immutability. They state immutability has a different meaning for Arrays than Dictionaries (or Strings, Ints, any other type, really), and that you are "not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array." (bold emphasis mine). This initially hits me, too, as "not so immutable". But look at how Apple phrases it: you can't change the "size", but you can change the "value" for an existing index. So, if I understand that right, the pointer to the Array (which has already been allocated and sized in memory) cannot change, but the contents of that memory space can. So the pointer is what is immutable, not the contents. Here is another example:

let arrayA = ["dog", "foo"]  // just defining the constant Array var arrayB = arrayA  // making a variable Array set to arrayA arrayB[0] = "cat"  // should be fine, just mutating the variable Array arrayB  // displays: ["cat", "foo"] arrayA  // displays: ["cat", "foo"]  // yikes? arrayA[1] = "bar"  // should we be allowed to do this? arrayA  // displays: ["cat", "bar"]...it appears we can arrayB  // displays: ["cat", "bar"] arrayB.append("baz")  // this should be ok, since it's a var arrayA  // displays: ["cat", "bar"] arrayB  // displays: ["cat", "bar", "baz"]

Certainly this is not what we would have expected from other languages. Saying something is immutable means it cannot mutate. But with Swift, these array values ARE mutating. But, look more closely. I set arrayB as a var that equals arrayA, thus creating a mutable copy. Right? Well, not really. In Apple's WWDC 2014 video 406 "Integrating Swift with Objective-C", they make a tiny mention that the "+" operator can be used to concatenate strings, but it doesn't really mutate anything; it leaves the strings in memory as they are, and makes an optimized concatenation. It appears that this is happening here, too. When I append a value to arrayB, I am changing the size of the array. BUT! If I change a value at an index that is also within the bounds of arrayA (in this case, 0 or 1), arrayA's value changes too! Let's take a look at what this means from a memory diagram perspective:

When you access arrayA's elements, it only knows about two of them. When you access arrayB's elements, it knows about three of them (for now, until you mutate it again), and as you can see if common values are changed between the two arrays, the value is reflected by both arrays. Based on this diagram, arrayB is NOT a "copy" of arrayA, as we may have expected. Because the array treats its objects as independent values (as mentioned in the WWDC video referenced above), arrayB's size changed by appending an object to itself, which is as expected, but arrayA's size did not change, which is as expected also.

I totally understood the Twitter user's reaction, for I had the same one, so I do not blame him at all. If this behavior is going to be foundational to Swift, and not a "whoops" in the first release, then it is something we need to be cognizant of, and respect while we use the language (whether we like it or not -- I'm sure there are plenty of things we do in languages that don't jive with our inner instincts, but we just need to understand the method to Apple's madness). It may be an optimization that we can embrace and use to our advantage.

Hope this article helped clear up some confusion about Swift's handling of mutability/immutability.

(Update: I'm still filing a radar on this behavior -- why have collections behave differently under the context of "immutability"?)

Recently, some of us from our local CocoaHeads meetup have started meeting on weekend afternoons for something called “Paired Programming Fun”. It has been fun and very educational. Yesterday we met and started doing TDD exercises from http://exercism.io, which are great tools to learn by. It gives you a set of unit tests and you must write the code to make them pass. We took it one step further, and began writing them in Swift. We all had a great time and learned so much. But, we got stuck, naturally, because none of us are Swift experts yet. Time came, and we all had to part ways back to our families.

Ok, back to my bed (get your mind out of the gutter, you sicko). I was lying there trying to figure out the problem where we left off from PPF earlier that day. I decided I wasn’t going to bed until I solved the problem, one where you were given a string “1, 2, 3!” and give a certain reply, but another case tripped it (one with non-numerical characters). We all guessed that it should be a regular expression, but how do we implement that in Swift? Apparently, the String class has an instance method (according to the documentation) called “length” that returns the length of the string, but Xcode said no such method exists.

I dug around and found “countElements(string)” which works, inserted that into the range for the regular expression, and then brought all the logic in to finally make the tests pass.

It was 12:45am. And I felt alive.

In a matter of a few days I immersed myself in Swift, TDD, Regular Expressions, and many other things to get this to work, and I felt so alive. It may sound small to some, and whooptie-doo, I made a unit test pass. But this feeling is what keeps me striving to be the best I can be, and may keep some of you going in those midnight hours while solving problems.

I am so thankful that Apple cared enough about their platform to devote so many resources to make a wholly new language for us to develop stronger and better apps for the App Store and customers. I am so thankful for the community of developers who have helped along the way.

I hope this article strikes a chord with you and that maybe some of you feel the same way. We are all in this together, let’s make this adoption to Swift worthwhile to help the language, platform, and the future of electronics by showing what we can do.

Before wrapping up, here’s a quick tip on how to get to the Swift REPL (Read Eval Print Loop - Wikipedia) in your Mac command line.

Open Terminal (or your terminal app of choice), and enter the following:

$> sudo xcode-select -switch /Applications/Xcode6-Beta.app/Contents/Developer

$> xcrun swift

Enjoy!

Let’s begin

Fire up Xcode and create a new Single View project. Call it SnippetyDooDa or something, it doesn’t matter. We aren’t going to actually build anything on the device or simulator, but just get a feel for how to add these to your code.

Built-in Snippets

Click to select your ViewController.m file. Next, it may already be selected, but click the button that looks like two curly braces in the Inspector Pane on the right.

Single-click the first snippet (in my case, C Block typedef) and a popover window will show, displaying details about the snippet. As you’ll see, Xcode has the syntax for declaring a C Block typedef here, with the familiar highlighted areas where you can tab-jump to, and edit to your app’s needs. Click Edit. Here, you see all the information in this snippet, where there is a description, completion shortcut (which is what you type in Xcode to invoke the snippet without needing to drag-and-drop it), completion scopes (telling Xcode where you’re able to insert this snippet), and more.

Click Done.

Go ahead and drag the C Block typedef snippet above your @interface line of code. Xcode adds the snippet to your code where you drop it and now you can enter in the information needed to make your Block typedef. This is very cool!

That’s how simple it is to add an existing snippet to your code. This post isn’t all about Blocks, but try adding the next one, C Inline Block as Variable, to your viewDidLoad method. Inline blocks can be useful for something you need to use locally without the need to create an instance variable.

I think you’ve got the idea now. Take a look at the other snippets in the list, click on them to see the code there, and see if they may be handy for you. Some nice ones are:

Core Data Fetch

Enumerated Type Declaration (both enum and NS_ENUM)

Enumerated Type Declaration (NS_OPTIONS) (which is very cool for combinable options for bitwise OR/AND options)

GCD snippets…all of them

Objective-C KVO: Observe Value For Keypath

Creating Your Own Snippets

Not sure about you, but I dislike typing [NSString stringWithFormat:…]. I’m thankful that Objective-C tends to be wordy because it’s easier to read and know what blocks of code are doing, but snippets can help keep you typing faster than autocomplete.

“OK, so how do I do it?”, you ask. Type whatever code gets you angry, or you type frequently, and highlight it.

Then, drag that highlighted piece of code and drop it into the Snippets pane. It will default to naming it “My Code Snippet”, and notice that “User” is over the icon, meaning that it’s a user-created snippet. Single-click the snippet, and click Edit. You can name the snippet whatever you want, and set a completion shortcut.

With this new snippet, typing cwrgba in Xcode inside a method will expand out to [UIColor colorWithRed:#value blue:#value green:#value alpha:#value].

Here are some completion shortcuts I use:

pns for @property (nonatomic, strong)

pnc for @property (nonatomic, copy)

pwni for @property (weak, nonatomic) IBOutlet

swf for [NSString stringWithFormat:#text#]

Invoking Snippets in Code

You may be doing this already, but try this in Xcode. Place your cursor inside any method, like viewDidLoad, and type dispatch_once. Autocomplete will suggest the snippet for you, and if you hit the Enter key, it will fill in the entire snippet for you, with your tab-complete ready to go to the first place to fill in.

That’s All

Hope this has been helpful for you, I know they are helpful for me.

Git

Git was scary to me. Hadn’t ever used it. I think it started when I heard Dan Benjamin (@danbenjamin, http://5by5.tv) talking about some command line videos he had done on peepcode.com (now part of PluralSight), and I saw he also had some on Git. Best $12 bucks I ever spent (well, on a Git video, that is). Learned enough to commit, roll back, tag, push, etc. 

GitHub offers free public repositories for your code, and charges for private repos. BitBucket, on the other hand, has free repos for up to 5 users per account. Bingo.

Create a BitBucket Repo

Go to BitBucket, create an account, and follow their links on how to set up SSH authentication with your SSH keys. This ensures secure communication to BitBucket via SSH without you needing to enter a username/password. 

Click the Create button at the top of the page. Name it “CITest”, give it a description if you wish, ensure “Git” is selected, choose “Objective-C” for the language, and click “Create Repository”.

Once your repository is created, it will provide steps for getting you up to speed with pushing an existing local repo to BitBucket, or starting from scratch.

Click “I have an existing project to push up”, and leave this page up and available for later. We will connect this to our code next.

Create the Project in Xcode

In Xcode 5, create a new Single View Application Project. Name the Project “CITest”, and fill in the rest of the information according to what you would do. iPhone only is fine for this example. Click “Next”.

Choose the location for your Project to be stored, and ensure “Create git repository on <whatever>” is checked (if not checked, you can create the git repo for your Project later by typing “git init” at the command line in the root folder of your project). Click “Create”.

You are greeted with an empty project. For simplicity, just create something simple, so you have something to test. I’m going to remove the default ViewController.m/.h files (and remove it from the Storyboard file), and add a UITableViewController subclass as my initial view controller. Then for right now, just add an NSMutableArray item to the .h file to contain an array of items that will show up in the table.

Create some simple tests

Xcode 5 kindly gives you a test target for free with any new project. Expand the CITestTests group, and notice there’s a single .m file. Click CITestTests.m, and notice there are three methods; setUp, tearDown, and testExample. In short, Xcode’s testing framework will run tests on methods in this target’s test files that begin with “test”. Mattt Thompson wrote a great article on testing (http://nshipster.com/unit-testing/) using the SenTest framework, but now Xcode 5 uses the XCTest framework, which appears to be relatively similar in nature. Instead of STAssertTrue() or STAssertFalse(), you have XCTAssertTrue() or XCTAssertFalse(), in addition to many others. The premise of testing is to allow you to assert that things are true, false, equal, not equal, nil, not nil, etc. To understand this well, I HIGHLY recommend Jonathan Penn’s (@jonathanpenn) video on YouTube from CocoaSlopes. Also, you’ll want to check out WWDC ‘13 session 409 (Testing in Xcode 5).

Add the below method to your CITestTests.m file:

- (void)testArrayNotNil { NSArray *items  = @[@"apples", @"oranges", @"bananas", @"pears", @"bacon"]; XCTAssertNotNil(items, @"items should not be nil"); }

This test should pass, obviously, as we are instantiating the array in the line before it. The point is to show you that it’s not scary, and we want a test to show for later when we set up Continuous Integration. Also, remove the testExample method, as that shows the default fail assertion.

Run your test by either pressing ⌘+U, or by clicking the diamond to the left of the method implementation.

After testing, you should see a green indicator for our test. Take a second to pat yourself on the back!

Push your code to BitBucket

There are several ways you can add a “remote origin” to your local git repo: via Xcode, or command line. I’ll cover both, because they’re very quick. First, give you code a quick commit. Open Terminal, cd to your project path, and type the following:

$ git add . $ git commit -m "initial commit"

That added all the added/modified files in the working directory to be staged for the commit. The next line committed those changes to your master branch.

Via command-line: Go back to the BitBucket site you left open from earlier (labeled “Push up an existing repository”), which looks like the below image:

Open a Terminal window, and change directory to the path where your .xcodeproj file is (mine is ~/dev/CITest). Type in the commands listed on BitBucket’s site exactly how they are, and watch the magic happen.

What this did is add the remote origin to your <project folder>/.git/config file to let Git know you have a remote repo. Now, when you commit your code, you can also push it to your BitBucket repo, and all sorts of other cool things. You also performed your first push of code, plus any git tags.

The Xcode way: with Xcode 5 open to your project, click the Source Control menu, CITest - Master, Configure CITest.

Click “Remotes” along the top, and if you did the command-line steps above, you’ll see your remote origin there. If not, click the “+” in the lower-left corner, and click “Add Remote”.

Then, a new dialog comes up asking for the name and address of the remote. Enter the SSH URL for the Address, and give it a name.

Now that this is set up, you can commit and push code very easily from within Xcode. Press ⌘+⌥+C, which brings up the commit dialog, and gives you the option to push the code to your origin (or whatever branch you may be on or want to push to). Very, very handy.

OS X Server and Xcode Service

OS X Server now comes as an app that operates within Mavericks, rather than being an entire Server OS itself. I downloaded it from developer.apple.com, but I believe it’s available in the Mac App Store, too. Download and install it, and then open it to begin working with it.

Once open, and past the greeting screen, locate Xcode along the left-hand side, and turn it’s switch to ON. 

You can also take the time to choose the version of Xcode under Builds and choose your Developer Team(s).

Click “Repositories”, and click the “+” to add your repository to OS X Server. 

There may be several ways to set this up, but here I will outline what worked for me. On the “New Repository” dialog, choose:

Choose “Connect to a Git Repository” from the drop-down

Name: “CITest”

URL: paste in your SSH URL from BitBucket (include the ssh://)

Authentication: “SSH Key”. This shows more input fields for you to further configure the repo entry

User Name: enter “git”. This will set a default SSH key, but we want to paste in the SSH keys you created when connecting to BitBucket. 

Click the “Edit” button. The keys that you created earlier, we’ll need to copy and paste their contents here. From a Terminal window, type the following:

pbcopy < ~/.ssh/<name of key>.pub

This copies to the paste board the contents of your .pub file. Paste it into the Public Key text field in OS X Server. Next, pbcopy the private key:

pbcopy < ~/.ssh/<name of key>

The contents of your private key file will be copied into the paste board, and then paste it into the OS X Server’s Private Key text field. This will allow OS X Server to connect to the repo on behalf of you. Click “OK” to complete.

Then click “Create” to create the repo entry. Notice that the entry is now in the list of repos your server manages.

Create a Bot

Xcode 5 now has “bots” that can run automatically or manually to perform actions upon your code, such as static analysis, running unit tests, and archiving. These bots need to have access to your repository as they will check out your code to a local temporary location, build, analyze, test your code, and produce a terrific dashboard of results for you. You can create these bots from Xcode or from your OS X Server’s web interface. As of the time of writing this, Xcode 5 has an issue with using SSH keys for authentication to create bots, so we’ll use the web interface. 

One thing that must be done is to share your scheme. To do what we’re trying to do in previous versions, you had to have a separate scheme in Xcode for testing, but now you can use your primary scheme and share it. But good news! When creating your first bot in an Xcode project, it will ask you if you want to share your scheme for you.

 Ensure your Server is running, and in the Xcode Service, click “View Bots”, which will open your server to your Xcode Service bots page.

Click the “+” icon in the top-right of the page, then click “New Bot”.

On the “Create a new bot (Step 1 of 4)” dialog, enter the following:

Repository: choose the CITest repository we added via the Xcode Service page of OS X Server

Branch: master (this is your master branch. If you have another branch you want to test, put it here — very cool to have bots testing different branches!!)

Project Path: relative path to your .xcodeproj or .xcworkspace file. If this file is at the root of your project folder, just enter your .xcodeproj or .xcworkspace file

Scheme: scheme name from Xcode (CITest)

Bot Name: Be descriptive here, because you may have many bots

Integrate Immediately: deselect this for now

Click “Continue”. 

On Step 2, I am choosing “Poll for new commits”, which effectively runs your tests after committing your code (after a few seconds/minutes delay, so good enough). You can also choose “Manually”, “Periodically”, or “On commit with custom trigger”. Apple recommends having several Bots run, and especially “Periodically” every night so your test users will have a fresh new build every morning when they come to work. Also, I want to analyze, test, and archive my code, and clean it every build so gunk doesn’t get in there.

Click “Continue”.

On Step 3, select “iOS”. Now choose what devices you want this to run on. Select “All devices” for now, unless you need specific devices. I found that using “All simulators” works unless you have checked “Perform test action” in Step 2. If you have figured out how to get that to run on the Simulator, please let me know!

Click “Continue”.

On Step 4, this is purely choice. If you want an email on success/failure, go ahead here. Click “Create”.

Click “View Bot” to view the bot in the web interface.

Plug in your device(s) and click “Integrate” now to run your first integration.

Did it fail for you too?  Good! I left out a step, did you catch it? I wanted to do it this way to show you something. 

Switch back to Xcode, and click the right-most icon in your Navigator pane.

Click the red circle with the white ‘x’. It will show you details of the failure in the main content window of Xcode. We didn’t share our Scheme! Xcode will share your scheme automatically for you when creating Bots through it, but the web interface will not. Click your scheme, and click “Manage schemes”. Place a check next to your scheme, then click “OK”.

The shared scheme now needs to be committed and pushed to your repository. From Xcode, press ⌘+⌥+C, enter a quick comment about sharing the scheme, check the box to push to your master branch, and click “Commit”.

Now, you can re-run your bot manually (yes, even though we chose “On commit”!), right from within Xcode (once the Bot is created, it’s available from both your server’s web page and Xcode). Select the Bots tab of the Navigation pane again, right-click your Bot, and choose “Integrate Now”.

Success!!! You should see something like this below:

I wanted to show you the failure to show you where the information for errors is shown, and plus I hate tutorials that are always so error-free. I learn best when I break stuff. 

Hope that helps you in your journey to write better code, as I know it has helped me. More tidbits about this will be coming out, as I find this fascinating, and it helps me learn the more I do this.

If you have questions, comments, “you did something wrong”, or “an alternative to X is Y”, I’d love to hear it. 

Twitter: http://twitter.com/bjmillerltd. App.net: http://app.net/bjmiller

Resources

Jonathan Penn’s CocoaSlopes talk: http://www.youtube.com/watch?v=8cpEIik-FZM

http://madebymany.com/blog/continuous-integration-for-ios-development

http://ikennd.ac/blog/2013/10/xcode-bots-common-problems-and-workarounds/

WWDC ‘13 Session 409 “Testing in Xcode 5”