#bignerdranch

I recently had the opportunity to give the Apple Watch a test run at the Big Nerd Ranch office. While researching its functions and interface guidelines for a work project, I decided to see how it performs doing my favorite activity — running.

I’ve become set in my running ways after many years. I have a favorite shoe brand, prefer a certain meal the night before a big race, and use my Garmin Watch to record my activity. I’ve been using a Garmin watch with a heart rate monitor for almost 5 years. I approached the Apple Watch with a lot of hope and doubt.

Off to the Races

I decided to hit the ground running with the native Workout App. The interface is beautiful and easy to read and has a ton of options. However, its functionality is a little lacking. When running in a city that features many encounters with traffic, I frequently have to stop and restart my watch at crosswalks. With my Garmin, it is as easy as pushing a physical button on the side of the watch. I don’t have to take my eyes off my surroundings. I can simply do it by feel. With the Apple Watch, I have to force touch on the screen, then choose between ending the run or pausing. That’s too many steps, and too much looking at the screen.

The component missing from the Watch that I truly need as a runner is GPS. When I go out for a run, especially a long one, I try to minimize the items that I take with me. I usually bring my key, water bottle, and my watch. With the Apple Watch, if I want to track where I run, I have to bring my iPhone. I haven’t carried any kind of music player or phone on a run in over 4 years. This sudden change in running habit didn’t sit well with me.

It is possible to use the Workout App on the Apple Watch without your phone. However, the results are wildly inconsistent. During my first test run, it was myself, the Watch, and a water bottle. I ran to a mile marker on the Atlanata Beltline that I have completed many times in the past. After completing the 1.5 miles, I looked at the watch to find it .4 miles off the expected distance. On the way back home, it was .35 miles off.

The following day, I ran the same route without my iPhone and water bottle. The results were definitely better. The distance was only .04 miles off. Without an iPhone, it appears that the Watch measures distance using arm locomotion. Carrying a water bottle definitely seems throw off that measurement and movement. Based on those test runs with the native app, my Garmin was still the best bet.

Third Party Apps

There are several running apps available for the iPhone that currently have Watch apps. I took a couple of them out for some short mileage to see how they compare to the native Apple Workout app.

Not every running app has a watch app. And the apps that have Watch apps don’t always have a Glance. Those apps that make their way to the Watch need the iPhone to work (until WatchOS2 hits).

Strava In the past, I have used the Strava iOS app and website for tracking my runs and bike rides. I could either use their app directly, or I could have my Garmin sync the data to the Strava site. I was happy to see that they had extended their app to the Watch. The biggest drawback is that I had to carry my phone with me for the app to work.

Switching back and forth between running and biking requires a force touch much like the native Workout app. The response time for this interaction to begin is a bit sluggish. Hopefully this will change in newer versions. Starting a run is a simple touch of the screen. So simple that I accidentally started a run before I was ready to go. The layout of the information was very similar to the simple LCD screen I am accustomed to on my Garmin. Pausing the run requires a Force Touch, similar to the Workout app. However, in Strava, it doesn’t have an extra screen that requires me to tap to pause.

Runkeeper As with Strava, the Runkeeper app requires the iPhone for the Watch app to function. The UI is very simple, and I found it an easy experience to use. It’s UI for the actual running was the simplest of the apps I tried. It was also the closest to the visual and functional layout of my Garmin Watch. Unlike the Force Touch method used by other apps, a user could simply tap pause on the screen to stop the app. When you want to restart your run, you simply tap the screen again to resume.

Nike+ Running The Nike+ Running app feels and looks like a blend of the native Workout app and the Strava app. It was the most feature rich app that I tested. It brings a lot of the functionality from the existing iPhone app to the Watch. Running, Leader Boards, Social Activity, and more can be found here. Apple suggests that activity on the watch should only take seconds to browse. On the watch, the main focus should be on the activity of running, while leaving the other features to be viewed on the phone.

Unlike the other apps, the Nike+ Running app has a paginated menu in the app allows me to start run, view leaderboard, or check out my previous activities. Starting a run is a very simple tap of the run button. The interface is big and bold, and easy to see even on the 39mm version. For the moment, the Force Touch is the only way to pause or end a run, just like the Native app. This is certainly not the best user experience while running. I am hoping more apps go the way of Runkeeper or Strava to pause a run.

Staying on Course I ran into a couple issues while using the third party apps. When running with the Workout App, the app view would stay persistent throughout the entire run. However, when using a third party app, after a few minutes, the screen returns to the clock face instead of the app you were using. It was very cumbersome to get back to your app. First, you had to touch the digital crown, then try to find the tiny icon of the app you wanted. All of this while running at the same time.

Walk, Don’t Run

I think there is a lot of promise with the Apple Watch. Hopefully, the next generation Watch will include some of the missing components to make it a fully stacked running necessity. Recently at WWDC 15, Apple previewed WatchOS 2, a new SDK that will allow apps to actually run on the watch. This should make response times faster, and increase functionality within the app.

Strava is already planning to use the heart rate sensor to gather and display data during workouts. I can see other apps taking advantage of the Taptic Engine to create custom alerts for users. Also, developers will have access to the Digital Crown. Using this input method, a user might be able to choose from a set of workout types, or set time limits. I wonder if I will be able to pause a workout or run using the Digital Crown. And hopefully, gaining access to the accelerometer will increase accuracy for those choosing to run without their phone.

Day 7 was very different from the previous days at the Ranch. It is mostly a catch-all day for miscellaneous topics that came up throughout the week as well as a discussion on tools.

I was impressed by some of the built in features of both Xcode, the debugger, and instrumentation. In particular, I was shocked by all the options available for debugging with breakpoints; conditional breakpoints, computer speach of pre-defined text triggered from breakpoints, and many other options.

Next we reviewed memory leak analysis using Instrument templates. We worked through a fairly contrived (but relevant) example where the tools correctly found an ARC leak.

The rest of the day was picking up random topics of interest. Christian demonstrated some of his techniques of debugging Auto Layout constraints with Size Classes by setting the canvas in free form mode and resizing it to see how the layout behaves. I've used this technique for years for correctly developing desktop applications with resizable windows so I'm very glad to see it replicated in the iOS tools. While he was at it, we saw a demonstration for constraint inequalities and how they affect animation, which led perfectly into the next topic...

Animations.

I was impressed with how easy iOS makes animating interface elements. In a lot of cases, it can simply be achieved via a call to:

UIView.animateWithDuration(\_: animations: () -> ())

with a start state before the call and the desired end state within the closure. There we variations on this as well such as Spring animations:

UIView.animateWithDuration(0.6, delay: 0.0, usingSpringWithDampening: 0.2, initialSpringVelocity: 0.0, options: UIViewAnimationOptions.something, animations: { () -> Void in // .. finishing code }, completion: nil)

And keyframe animations:

override func touchesEnded(touches: NSSet, withEvent event: UIEVent) { let touch = touches.anyObject() as UITouch let loc = touch.locationInView(view) // Update contraints outside of animation closure topConstraint.constant = loc.y UIView.animateWithDuration(0.5, animations: { () -> Void in // Re-layout views inside animation closure self.view.layoutIfNeeded() // Update view properties inside animation closure self.view.backgroundColor = UIColor.redColor() }) }

Finally, we picked up a topic covered in older editions of the book, location. I'm pleased we covered this topic, as it is something almost completely unique to the platform and something I hope to become familiar with soon (I like to jog).

Our simple example in Swift:

import CoreLocation import MapKit imoprt UIKit class ViewController: UIViewController, CLLocationManagerDelegate { @IBOutlet weak var mapView: MKMapView! let locationManager = CLLocationManager() override func viewDidLoad() { super.viewDidLoad() locationmanager.requestWhenInUseAuthorization() locationManager.desiredAccuracy = kCLLocationAccuracyBest locationManager.distanceFilter = 10.0 // how far the user needs to move before you get updates locationManager.delegate = self locationManager.startUpdateingLocation() } func locationManager(manager: CLLOcationManager!, didUpdateLocations locations: [AnyObject]!) { println("\(locations)") // CLLocation: coordinate, altitude, horizontal and vertical accuracy if let currentLocation = locations.last as? CLLocation { // We found a location mapView.setCenterCoordinate(currentLocation.coordinate, animated: true) let span = MKCoordinateRegionMake(0.01, 0.01) let region = MKCoordinateRegionMake(currentLocation.coordinate, span) mapView.setRegion(region, animated: true) if currentLocation.horizontalAccuracy < 20.0 { manager.stopUpdatingLocation() } } } func locationManager(manager: CLLocationManager!, didFailWithError error: NSError!) { println("\(error)") } }

And so ended my Big Nerd Ranch course. It was such an incredible experience and I highly recommed anyone interested in one of the course topics taught by Big Nerd Ranch to give them serious consideration; the environment is completely unique and they certainly aren't lying when they say it is "monastic like". The lack of external distractions of the real world certainly went a long way in helping become emersed in the material.

Day 6 has come and gone and the amount of code and hours involved with this training is starting to take its toll on the level of energy. That said, the day starts off with some really interesting topics that help invigorate me personally. Storyboards are something that Apple appears to be pushing more of late and I think are the most efficient future of iOS UI development.

Like the smaller level user interface elements such as views, buttons, and labels -- Storyboards’ interactions feel natural in Interface Builder. Placing constraints isn’t bad but adjusting them or handling different size classes feels is awkward. Hopefully, these workflows can be refined over time.

We also covered connecting to web services, which is incredibly useful in today’s cloud-based world, particularly in the mobile. It was good to learn how iOS and Swift handles web requests and JSON parsing if not exactly fun coding.

One of the unique experiences offered on this trip is zip lining at Banning Mills. A few of us signed up for the one slot set aside for it this week and had a blast. I can admit to having some shaking knees while standing at the top of the launch towers but zipping down the steel cables felt surprisingly relaxing. This is such a great experience, I hope everyone takes this opportunity if given the chance.

Lastly, we covered touch events and ended gesture recognizers. I really like how these features are implemented, very concise and elegant. We built a gesture-based primitive drawing app around these concepts and it was quite satisfying.

The Patriots played a Thursday night game, which many of us gathered around the TV in the main lodge area to chat, have a beverage, and take a night off from coding. The game finished on the final play — a blocked field goal so it was a late night for me. Probably not a great idea given the level of tiredness I was already experiencing.

Day 5 continued, once again, where the previous day left off -- which is to say, more user interface topics.

We dove right in to Auto Layout, using contraints to dynamically control the layout of our user interface elements on the screen. Along the way, Christian showed us some common mistakes and the corresponding errors displayed in Interface Builder or the app console and how to fix them. It is amazing to me how much more polished an app looks when it behaves and looks correct on different devices and orientations.

We then explored how to do Auto Layout programmatically. I didn't even think this was possible. I'm not sure I'll want to attempt it in very many situations but I'm sure there will be times when it is potentially necessary. Time will tell.

Once we moved on from the basics of Auto Layout, we moved into Size Classes which allow you to dynamically change the layout of your app dramatically based upon the size of the platform it is running. It is a mobile developer's version of responsive design. It makes a huge difference in the usability of an app to efficiently use the space available to it on each platform and orientation.

The complexity of both Auto Layout and Size Classes will require lots of post-class experimentation to truly feel comfortable with, but for now, I understand the basics.

In the afternoon, we went for our usual walk but it turned into a mini-adventure. We walked down the river to the old Banning Mill, which happened to be on the other side of the river. Since we were there, a few of us crossed the river via some exposed rocks which quickly turned into the entire class. Christian said he had only had one other student in passed classes cross and yet there were seven of us that did on this trip. There was some rough terrain coming back but it was fun and good exercise. I think a few people got more than they had bargained for.

Finally for Day 5, we moved on to Core Data. For the first time in the class, I was relatively uninterested in a topic. I recognize the power of the technology but for my immediate purposes, I'd rather explore other topics. I decided to take my first break on this chapter. Every chapter prior to this one, not only did I do the core example, I had done all the suggested challenges. Some chapters, I had even added some of my own user interface touches to the app but this chapter was a good time to take a short break.

Coming off yeserday's high, I was very much looking forward to today.

Today started an entirely new project, a home inventory app. This app is designed with a table view, a control used constantly in iOS apps and within iOS itself. Given its widespread use, this is an important day of hands-on training.

I found the control to be interesting but not entirely what I was expecting; I've used a lot of table controls in prior UI implementation, but it is a little different on iOS. Most tables have a variable amount of columns as well as rows on other platforms -- on iOS it appears that tables have a single column and rows themselves are designed around a single control of your design. This design can include "column-like" structures but aren't required to look like columns. This makes UITableView something entirely different to me. It certainly allows for some rich display of items but isn't exactly like a traditional spreadsheet design.

Another interesting aspect of UITableView are the other parts of the control -- headers, footers, and even a notion of sections. Christian (the instructor) pointed out how iOS's Settings app uses sections. This certainly makes for some different takes on the design of an application.

We then learned some CRUD (Create, Read, Update, Delete) operations on tables. iOS does some interesting things when it comes to efficiency of UI display by reusing cells when it can. The rest was pretty typical stuff.

Next, we added a navigation control to our design. This control is fundamental to mobile app design, as it allows a hierarchy of views to be navigated and have a standard "back" button to return from "drill down" views. The drill-down view for our table view of inventory items was a detailed view of an item. This showed name, serial number, value and date created. To this view, we eventually added a toolbar that linked to the camera app using the system's camera button and eventually made it also allow editing of the photo selected. This detailed item view then displayed the selected photo.

Lastly, we tied the app into system events so our inventory could be persisted to disk. At this point, you have a reasonable app's functionality. Tomorrow will involve Auto Layout to clean up some of the visual aspects of the app to add a signifigant amount of polish.