Chapter 4. Expanding on C-Quence

Now that we have a strong framework in place, we can begin to turn those empty functions into fully implemented methods, after which C-Quence will be a fully functioning watchOS app.

You will probably be delighted to discover just how easy this is, having reached a point at which we have already decided both how the app is structured at a high level and roughly which methods we need our two classes to provide. The basic app may look only half finished, but it is, in fact, much further than that.

Implementing the methods

Take a deep breath, we don't run the code for a while!

We will start with our InterfaceController class. This is where the user's engagement with the app begins, and this is where we will begin to endow the classes with life.

When the app launches, it automatically loads the view that is designated as the Main Entry Point, identified in Interface Builder by the Main arrow, as shown in the following figure:

In our case, this main entry point is the InterfaceController class.

The InterfaceController class

In addition to performing duties of its own, InterfaceController creates two objects on which it must call. Firstly, an instance of our GameLogic class and secondly, an instance of NSTimer with which we will control the timing of the flashing colors.

In contrast to some languages, in Swift we can both declare these properties and instantiate them at the same time. Add the following code to the InterfaceController class below the IBOutlet declaration:

    @IBOutlet var greenGroup...

Testing and tweaking

One of the hardest things in developing software is testing its functionality to the limit. There is something inherently difficult about trying to provoke your own code into failing your own tests, but it is absolutely imperative that you cover as many as possible of the scenarios that the app could come up against. Users are so unpredictable.

The first test

With a simple app such as this one, this is not such an insuperable task. Play the game over and over, trying to catch not only the usual sequence of actions that you expect your users to go through, but also all those niggly edge cases, such as:

• User fails at the first guess

• User taps incessantly on the screen

• User manages an incredibly long sequence (pen and paper might help—or just a lot of practice)

• User switches to a different app and then returns

• Anything else you can think of

• Anything that anybody else can think of

The first bug

Now, if you have tested your creation on a real Apple Watch, you may have noticed that...

Communicating with the phone

The app that we have coded is in some senses completely autonomous—the iPhone companion app does nothing except install the watchOS app, after which the player never needs to engage with the phone. Which is kind of a shame given that the phone offers us some benefits that most apps are likely to be able to make use of. These include:

• Much greater storage capacity for resources

• Much greater processing power (and the battery life to do it)

• A much larger screen

While we will have little use in C-Quence for the first two of these, we will make use of the ease with which our users can give us information using the larger screen, information that we will only collect once, or at least not often.

As mentioned in Chapter 1, Exploring The New Platform, the Apple Watch is at one and the same time an independent device, and an extension of the iPhone, but we can also turn this relationship around and use the iPhone to augment the capabilities of the Watch.

To get input from the...

Summary

This where we leave C-Quence, at least, as far as this book goes. It would be an excellent idea to go back over the code, right the way from the beginning of Chapter 3, C-Quence – A Memory Game, and experiment with tweaking the code here and there, with a view to better understanding what each line of code does, and how it might be varied.

And if it kills the app? No problem, that's what command-Z is for.

In this chapter, you have learned to:

• Iterate through the Run-test-fix process to catch bugs

• Adapt the originally planned code to real hardware conditions, You have

• Enabled phone-to-watch communication using the WatchConnectivity framework

• Use of constants to make that communication easier to code safely

• You have also learned to create shared manager singletons

• Use NSUserDefaults to persistently store data on both devices

• You have used Interface Builder's Layout Constraints to create a minimalistic interface on the phone that will correctly adapt to all screen sizes and orientations

In the...