A First Look at Apple WatchKit

With Apple releasing the latest version of Watch Kit API this morning, more detailed information about this new device has gradually surfaced for developers. It can be said that the functions opened by the latest version of WatchKit are generally satisfactory. Apple continues to move forward in the direction of gradual opening up. Originally, after WWDC, it was expected that Today Widget would be the stage for various novel apps and a great expansion of iOS functions. However, with the successive removal of creative Today Widgets such as Launcher and PCalc, developers have to lower their expectations for WatchKit. But at least from the current information, WatchKit allows complex interactions and the completion of some independent functions. Although it needs to rely on the iPhone app, at least the stage and space for it to be used are much larger than I originally imagined.

Of course, due to the limitations of the device itself, whether it is power or computing power, there are still many constraints when developing Watch apps. Currently, the Watch app only exists as a view display and feedback for user interaction, but considering that this is the latest SDK for this device, and Apple has also promised to allow apps that actually run on the Watch in the future, the future of Apple Watch and WatchKit is still worth looking forward to.

Without further ado, let's take a quick look at some basic information about WatchKit.

What we can do

Watch app architecture

First of all, it should be made clear that on the iOS system, the app itself is the core. All running entities rely on the app itself: this was unquestionable before iOS 8, and the various extensions added in iOS 8 must also be bundled with the app itself as a supplement to the app's functions. Although the Watch app is similar to this, if we want to develop for Apple Watch, we still need to build a traditional iOS app first, and then add the Watch App target to it. After adding, you will find that there are two more targets in the project: one is the WatchKit extension, and the other is the Watch App. Under the corresponding group of the project, you can see that the WatchKit Extension contains code (InterfaceController.h/m, etc.), while the Watch App only contains Interface.storyboard. However, the good news for the time being is that Apple has not explicitly required that apps developed for Watch must still be based on the iOS app as it did for iPhone Extension. In other words, it may be allowed to hollow out the iOS app and focus on providing the UI and experience of the Watch.

When the app is installed, the WatchKit Extension responsible for the logic part will be installed into the iPhone along with the main target of the iOS app, and the WatchKit App responsible for the interface part will be detected by the iPhone after the main program is installed to see if there is a paired Apple Watch, and prompted to install it into the Apple Watch. So in actual use, all operations, logic, and control are actually completed in the iPhone. When the interface needs to be refreshed, the iPhone sends instructions to the Watch to draw and display it on the watch face. Conversely, the information when the user touches the watch to interact is also transmitted back to the iPhone by the watch and processed. This process will be completed for us behind the scenes by WatchKit, and developers do not need to worry about it. What we need to know is that, in principle, we should put the interface-related content in the target of the Watch App, and put all the code logic in the Extension.

When you click the app icon on the watch to run the Watch App, the watch will be responsible for waking up the WatchKit Extension on the phone. The data interaction between the WatchKit Extension and the iOS app is completed by App Groups, which is the same as the Today Widget and some other Extensions. If you haven't learned about it yet, you can refer to a tutorial I wrote about Today Extension before.

Main Class

WKInterfaceController and Lifecycle

WKInterfaceController is like UIViewController in WatchKit, and it will be the class that takes the most time when developing Watch App. Each WKInterfaceController or its subclass should correspond to a full screen of content on the watch. But you need to remember that the entire WatchKit exists independently of UIKit. WKInterfaceController is a class that directly inherits from NSObject, and does not have the response function and complete callback to user interaction like UIResponser in UIKit.

Not only is it much simpler than UIViewController in terms of function, but the life cycle has also been greatly simplified. There are three life cycle methods that must be called for each WKInterfaceController object, namely -initWithContext: when the object is initialized, -willActivate when it is about to be presented, and -didDeactivate after the presentation. Similarly, if we use the UIViewController as an analogy, we can understand them as corresponding to -viewDidLoad, viewWillAppear:, and -viewDidDisappear: respectively. Although you may think that -initWithContext: should correspond to methods such as init or initWithCoder: of UIViewController based on the method name and actual use, in fact, in -initWithContext:, the "view elements" in WKInterfaceController (please note that I added quotation marks here because they are not real views, which will be explained later) have been initialized and are available, which is actually more similar to the behavior in -viewDidLoad.

We usually configure the properties of "view elements" in -initWithContext: and -willActivate, and disable objects that hold self, such as NSTimer, in -didDeactivate. It should be noted that setting the properties of "view elements" in -didDeactivate is invalid because the current WKInterfaceController is already inactive.

WKInterfaceObject and its subclasses

WKInterfaceObject is responsible for the specific interface element settings, including objects such as WKInterfaceButton, WKInterfaceLabel or WKInterfaceImage, which are the "view elements" we mentioned above. You may have the illusion at first that WKInterfaceObject should correspond to UIView, but this is not the case. WKInterfaceObject is just a proxy of WatchKit's actual View on the Watch Extension side, not the View itself. The view actually displayed and rendered on the screen in the Watch App is not directly visible to the code. We can only set the properties through the corresponding proxy object in the Extension target, and then when each run loop needs to refresh the UI, WatchKit will pass the new property values ​​from the phone to the Watch App in the watch and refresh the interface.

Conversely, the actual view in the watch needs to pass user interaction events to the iPhone through the WKInterfaceObject proxy. Each interactive WKInterfaceObject subclass corresponds to an action, such as a button for a click event, a switch for an on or off state, a slider for a floating point value to indicate the selected value, and so on. It is also very simple to associate these events. Simply Ctrl-drag from the StoryBoard file to the implementation to generate the corresponding event. Although the UI resource file and the code implementation are in different targets, the collaboration in Xcode is seamless.

The layout method adopted by the Watch App is completely different from that of the iOS app. You cannot freely specify the specific coordinates of a view, and of course you cannot use flexible interface layout solutions such as AutoLayout or Size Classes. The layout possibilities and flexibility provided by WatchKit are relatively small. You can only use "rows" as the basic unit and use groups to layout "columns" within rows. This brings relatively simple layout implementation, of course, it is also a challenge to the design of interface interaction.

It is also worth mentioning that with the emergence of WatchKit and the change in its development methods, the debate over whether to write UI in code or use StoryBoard, which has been going on for many years, can be temporarily put to rest. Development for Watch cannot be done in code. First of all, all WKInterfaceObject objects must be added via StoryBoard during design, and we can no longer add or remove elements from the interface at runtime (if there is a need to remove them, we can use hiding); secondly, some properties of WKInterfaceObject related to layout, such as row height and number of rows, cannot be changed or set at runtime. Basically, at runtime we can only change the content of the view, and achieve limited layout changes by hiding certain view elements (other view elements will try to fill in the hidden elements).

In short, the tradition of writing UI with code has been officially sentenced to death today with the release of WatchKit, thanks to Apple's continuous efforts.

Table and Context Menu

Most of the WKInterfaceObject subclasses are very straightforward, but there are two that I want to talk about separately, namely WKInterfaceTable and WKInterfaceMenu. Everyone is familiar with UITableView. Although WKInterfaceTable in WatchKit is also used to display a set of data, due to the characteristics of data transmission in the WatchKit API, its use is very different and simplified compared to UITableView. First of all, there is no DataSource and Delegate. The number of data that needs to be presented in WKInterfaceTable is directly set by its instance method -setNumberOfRows:withRowType:. After setting, use -rowControllerAtIndex: to enumerate all rowControllers for setting. The rowController here is the equivalent of UITableViewCell set in StoryBoard, but like other WKInterfaceObjects, it is directly inherited from NSObject. You can complete the display of the table by customizing the rowController and connecting it to the elements of StoryBoard, and setting it after obtaining the rowController. The code is roughly like this:

 // MyRowController.swift  
 import Foundation
 import WatchKit
 class MyRowController: NSObject {
 @IBOutlet weak var label: WKInterfaceLabel!
 }
 // InterfaceController.swift  
 import WatchKit
 import Foundation
 class InterfaceController: WKInterfaceController {
 @IBOutlet weak var table: WKInterfaceTable!
    let data = [ "Index 0" , "Index 1" , "Index 2" ]
    override init(context: AnyObject?) {
 // Initialize variables here.  
 super .init(context: context)
 // Configure interface objects here.  
        NSLog( "%@ init" , self)
 // Note that you need to set myRowControllerType in StoryBoard  
 // Similar to cell reuse id  
        table.setNumberOfRows(data.count, withRowType: "myRowControllerType" )
 for (i, value) in enumerate(data) {
 if let rowController = table.rowControllerAtIndex(i) as? MyRowController {
                rowController.label.setText(value)
 }
 }
 }
 }

For click events, there is no actual delegate. Instead, similar to other WKInterfaceObjects, the clicked row is sent back to the WKInterfaceController as a parameter through action for processing.

Another interesting thing is the Context Menu, which is a unique interaction of WatchKit and does not exist in iOS. In any WKInterfaceController interface, long press the watch screen. If there is a context menu in the current WKInterfaceController, it will try to call out the Context Menu corresponding to this interface. This menu can provide up to four buttons to ask the user for operations based on the current environment. Because the watch screen is limited, it is unrealistic and ugly to put some interactive buttons while displaying information. The context menu solves this problem very well. I believe that the operation of long pressing to call out the interactive menu will become a very standard interactive operation of the Watch App in the future.

Adding a Context Menu is very simple. Just add a Menu to the WKInterfaceController in the StoryBoard and add the corresponding MenuItem to the Menu. In WKInterfaceController, we also have corresponding APIs to add MenuItems according to the context at runtime (this is one of the few methods that allow us to add elements at runtime).

 -addMenuItemWithItemIcon:title:action:
 -addMenuItemWithImageNamed:title:action:
 -addMenuItemWithImage:title:action:
 -clearAllMenuItems

But we have no way to get the classes WKInterfaceMenu and WKInterfaceMenuItem corresponding to Menu and MenuItem. That's right, they don't even exist in the document :(

Basic navigation

The built-in navigation relationships of WKInterfaceController are basically divided into three categories. The first is the stack-like navigation method controlled by UINavigationController. The relevant APIs are -pushControllerWithName:context:, -popController and -popToRootController. I don't think I need to explain too much about the latter two. For the first method, we need to use the Identifier string of the target controller (if you don't have it, you can only set it in the StoryBoard) to create it. The context parameter will also be passed to the -initWithContext: of the target controller, so you can use it to pass data between controllers.

The other is the modal form that we are all familiar with. The corresponding APIs are -presentControllerWithName:context: and -dismissController. For this type of navigation, the difference from UIKit is that a Cancel button is added to the upper left corner of the target controller by default. Clicking it will directly close the presented controller. I just want to say that Apple has finally figured out the fact that every controller that comes out of a modal needs to be closed...

The first navigation method is paging navigation similar to UIPageController. In iOS apps, this navigation method is very common in the tutorial module when the app is first started, and it can be said that it has been carried forward in WatchKit. In fact, I personally think this will be the most commonly used navigation method in WatchKit. Page navigation on WatchKit may correspond to the functions provided by Tab navigation in iOS apps.

In terms of implementation, page navigation needs to connect different pages using segue in StoryBoard. The newly added next page segue does this:

In addition, another API for modal navigation -presentControllerWithNames:contexts: accepts multiple names and contexts. In this way, multiple Controllers called out by the modal will also be presented in page navigation mode.

Of course, as a classic way to use StoryBoard, modal and push navigation can also be implemented in StoryBoard through segue. At the same time, WatchKit also provides the necessary API for segue.

Some interface practices

Because the entire architecture is completely different from UIKit, many previous practices cannot be directly moved to the WatchKit App.

Image Processing

In UIKit, we usually use UIImageView to display images, and then set a created UIImage object for its image property. For WatchKit, the best practice is to store the image in the target of the Watch App (that is, the target of StoryBoard). When setting the image for WKInterfaceImage, try to use its -setImageNamed: method. This method will only pass the image name to the watch through the phone, and then the watch will find the image in its own bundle and load it. It is the fastest way. Note that our code is running on a different device from the Watch App of the watch. Although we can also generate a UIImage object through the relevant methods of UIImage first, and then use -setImage: or -setImageData: to set the picture on the watch, in this case we need to put the picture in the target of the Extension, and the picture data needs to be transmitted to the watch via Bluetooth. Generally speaking, this will cause a non-negligible delay and will greatly affect the experience.

If in some cases we can only get the image in the Extension target (such as downloading from the Internet or dynamically generating from code, etc.), and need to reuse it, we can use the -addCachedImage:name: method of WKInterfaceDevice to cache it in the watch. In this way, when we use this image later, we can directly generate and use it quickly from the watch through -setImageNamed:. The size of each app's cache is about 20M. If it exceeds, WatchKit will delete the oldest data first to make room for new data.

Animation

Because we cannot get the actual view elements, only proxy objects like WKInterfaceObject, and the layout system is limited, complex animations, especially UIView series or CALayer series animations, cannot be implemented. Now it seems that the only feasible method is frame animation, which can be achieved by setting an image containing multiple images for WKInterfaceImage, or by replacing the image regularly through a timer. Although Apple's own examples also implement animations in this way, it may be a challenge for the storage space and energy consumption of the device, and it is necessary to actually get the device to conduct experiments and observations.

Use of other Cocoa Touch frameworks

Apple recommends that you do not use features that require prompting for user permission, such as CoreLocation. Because the actual code is running on the phone, this type of permission will also pop up on the phone, but the user may not be looking at the phone, so it is likely to cause a poor experience. In addition, most background running permissions are not recommended.

To obtain this data and permissions, Apple recommends that you do it in the iOS app and share data through App Groups so that you can get this data in the Watch Extension.

Code Sharing

Because a project now has many different targets, it is necessary to use a framework to encapsulate the common code of different targets and only implement the interface-related code in each target. The advantage of doing so is not only to reduce code duplication, but also to improve code testing and quality. If the logic part has not been framed and tested separately, you may encounter a lot of trouble when implementing various Extensions or Watch Apps.

Because if the original app is planned to be expanded and various extensions are launched, extracting the logic code and encapsulating it into a framework should be the top priority. In addition, if there is no special reason for a new project, it is strongly recommended to use a framework to organize common code.

Glance and Notification

In addition to the Watch App itself, Glance and the watch's Notification are also important usage scenarios. Although Notification is simple in concept, it is very different from iOS notifications. WatchKit notifications allow developers to build their own interfaces. We can set up more complex and more informative notifications through payloads, including images, large paragraphs of text, and even interactive buttons, instead of being limited to text and a dialog box like on iOS. First of all, whether the notification is sent through Local or Remote, it will first reach the iPhone, and then the iPhone will determine whether to forward it to the watch based on the content. After receiving the notification, the WatchKit App will first display a short notification to tell the user that the app has a notification. If the user is interested in the content of the notification, he can click or raise his hand to watch it, and the long version of the notification customized by the developer will appear.

Glance is a new concept of WatchKit, which allows the Watch App to display a WKInterfaceController page with a fixed layout. Its relative position to the Watch App is equivalent to the position of the Today Widget on iOS and the iOS app itself, and it appears as the most important information display of the app on the watch. Glance, as the name suggests, is a short-lived reminder and cannot have interactive elements. However, if the user clicks on the Glance page, it can be launched to the Watch App. It is not very clear how Glance itself is launched and presented. It is speculated that it is presented in a similar way to the Today Widget? (For example, pressing the knob on the side of the watch twice)

Questions and directions for improvement

WatchKit is generally satisfactory, and the API and development environment it provides are enough for developers to make some interesting things. However, there are several limitations that seem obvious now and directions that we hope can be strengthened.

First of all, WatchKit does not provide any API to obtain device sensor information. We cannot get information about heart rate, step count, or whether the user is wearing the Watch, which limits the production of many health apps that collect and monitor data. If you want to request data, you still have to turn to HealthKit. However, with the large screens of iPhone 6 and 6s, fewer people carry iPhones when exercising. If the Watch cannot collect records without pairing with an iPhone and then transmit the data back after connecting to the iPhone, then Apple's health card has failed by half. I believe Apple will not miss this opportunity to tie users together... However, if third-party applications can obtain the user's wearing status in real time, I believe there will be many interesting applications.

In addition, the interactive revolution promoted at the press conference, the knob and touch screen, do not seem to have any API open to developers, so we cannot know the important interactive event of the user rotating the watch knob. It seems that the only operation we can obtain is the user clicking the button on the screen or dragging the slider. From this perspective, the current WatchKit is far from being able to subvert mobile applications.

I hope Apple will bring us other good news later.

In short, the stage has been set, and it is up to us to decide what to perform next.