- Getting the Tools
- Types of Apple Watch Applications
- Populating the User Interface
- Testing the Watch Application
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Types of Apple Watch Applications
In this release of WatchKit, you can develop three types of Apple Watch applications, as shown in the following table.
Application Type |
Description |
Watch app |
Runs on the Apple Watch and interacts with the application logic running on the iPhone. |
Glance |
Supplemental way for the user to view important information from your app. Glances don’t support interactions with users—tapping on a glance simply launches the Watch app. |
Notification |
Displays local or remote notifications received by the iPhone; apps can customize the notification interface. |
For this article, I’ll focus on Watch apps. Subsequent articles will dive into the other two application types.
Once the target is added, Xcode adds two groups to your project(see Figure 5):
){kind=link}
- HelloAppleWatch Watch app. The Watch app runs on the Apple Watch. It contains only a storyboard and resources (no code).
- HelloAppleWatch WatchKit extension. The WatchKit extension resides on the user’s iPhone. It contains the code for managing the Watch app running on the user’s Apple Watch.
The Watch app and the WatchKit extension communicate through the WatchKit APIs, working transparently behind the scene. Figure 6 summarizes the locations of the various components of the projects and how they communicate with each other.
Figure 5 The two groups added to your project after adding a target.
)
Figure 6 How the Watch application communicates with your iPhone.
Let’s take a look at the Interface.storyboard file inside the HelloAppleWatch Watch App group (see Figure 7).
)
Figure 7 The Interface.storyboard file contains the UI for your Watch app.
The storyboard file contains a single Interface Controller, which is similar to a View Controller in your iPhone application. When the user loads the application on his Apple Watch, the initial interface controller from the main storyboard is loaded.
Select the Interface Controller and examine the class in the Identity Inspector window. As Figure 8 shows, the Interface Controller is connected to the InterfaceController class.
)
Figure 8 The class representing the Interface Controller.
The InterfaceController class is represented by the InterfaceController.swift file (see Figure 9), in the HelloAppleWatch WatchKit Extension group.
){kind=link}
Figure 9 The InterfaceController.swift file runs on the iPhone.
The InterfaceController class (an extension of the WKInterfaceController class) contains the various events of the Interface Controller as it’s loaded and unloaded from the Apple Watch. The InterfaceController class contains the following code:
import WatchKit
import Foundation
class InterfaceController: WKInterfaceController {
override init(context: AnyObject?) {
// Initialize variables here.
super.init(context: context)
// Configure interface objects here.
NSLog("%@ init", self)
}
override func willActivate() {
// This method is called when watch view controller is about to
// be visible to user
super.willActivate()
NSLog("%@ will activate", self)
}
override func didDeactivate() {
// This method is called when watch view controller is no longer visible
NSLog("%@ did deactivate", self)
super.didDeactivate()
}
}
The Interface Controller lifecycle consists of the three events shown in the following table. (Remember, this class runs on the iPhone.)
Event |
Description |
init() |
Fired when the Interface Controller is loaded for the first time. This event is useful for object initializations, etc. |
willActivate() |
Fired when the user interface is visible to the user. This event is useful for updating the user interface, setting up timers, etc. |
didDeactivate() |
Fired when the user exits your app explicitly or stops interacting with the Apple Watch. This event is useful for cleaning up resources, saving data, etc. |