Build watchOS Apps: Exploring Controls
House Rules
As we take a look through the Object Library and the APIs, almost everything has a similar and direct analog available on the larger iOS devices. But let’s pause for a moment and review some small but important differences in the Watch environment (which we are sure will be no trouble to an intelligent, creative, and insightful developer such as you, dear reader).
- The user interface and the controls it contains are defined during development using the storyboard editor. In contrast to iOS, you can’t create the UI in code. If you are one of those developers who prefer to avoid the visual editor, then you’ll find it’s time to dip your proverbial toe in its waters.
- Even so, some properties of the controls can be set at run time (how else would you update a label to give your user information that you didn’t have at build time?), but only some. Others can be set only in the storyboard editor. We’ll identify which properties on each control can be dynamically updated as we examine each.
- Where values can be set to controls, they cannot be read by your Watch app. For example, you can set a switch to on from your interface controller, but you cannot read from it whether it is on or off. Instead, you must wire up the switch’s change event to an @IBAction method in your controller and keep track of state changes in a property.
This might sound like the Watch presents an even more restrictive environment than we’re used to as developers for iOS platforms, but as you saw when exploring the available navigation options (Chapter 3), you can do a lot with what’s available.