Apple Watch: how to make an application under the clock and not screw it up
Today launched the official sale of Apple Watch. 90% of mind-blowing app concepts for them, which can be found on the Web, are unrealizable - for those who are familiar with Apple's guidelines, this is well known. What can be realized on the watch is still possible and how best to do it in terms of development and design - under the screen.
Our team made one of the first applications in Russia © under the watch. When the developer and designer understand the features of each other's work, the likelihood of the appearance of fantastic design concepts tends to zero, and the development time - to several days. We, Grigory Matvievich ( fountainhead , developer) and Ekaterina Sotova ( lost_in_purple , designer), tell us what you should pay attention to if you are making an application for Apple Watch.
It will be about:
“Apple Watch is our most personal device,” they say at Apple. And this is true - the gadget, which is constantly on the hand of its owner, suggests new formats of user interaction, which were impossible or not needed on the smartphone. Watch applications must be adapted to the context in which their owner is located. First of all, this means that the clock should display only the most useful information in a very condensed form, as the person uses them on the go. The main task of watches and good applications for them is to be unobtrusive and useful. Apple focused on tactility (Taptic Engine provides tactile response when notifications come or interaction with the clock occurs) and tried to literally “blur” the boundaries between applications and physical objects: the background of the application imperceptibly flows into the display frame, visually merging into a single unit . The watch does not replace the application on the smartphone, but complements it. Apps on Apple Watch should be as easy as possible to interact. Information should be viewed simply and quickly and depend on the context in which the owner is located, without becoming intrusive. So, for example, the notification is displayed completely if the user has fixed his eyes on it, and Glances show the most relevant and necessary. If user interaction scripts with an application on the iPhone can be measured in minutes, then the duration of interaction with the clock does not exceed, as a rule, several seconds. All this must be kept in mind when designing your applications.
In the first version of the smart watch, Apple allowed third-party developers to create applications that are extensions of the main application (hereinafter, an application running on the iPhone, we will call it the “main application” ). And the application that runs on the watch is “WatchKit-application” , or simply “application” on the iPhone. Development exclusively under the Apple Watch promise to do in the future. Now the watch functionality is available through the WatchKit framework and is very limited compared to what you could see at the presentation of the watch itself. It can be seen that the developers at Apple and at several other “selected” companies have more opportunities than others.
')
We will understand how the application is arranged on the Apple Watch. From the point of view of the interface, applications on Apple Watch consist of the following parts:
From an architectural point of view, everything is different. Application files are divided into two parts: WatchKit App and WatchKit Extension. The WatchKit App is stored directly on the clock and consists of a storyboard (interface description) and resources. WatchKit Extension is stored on the iPhone and contains code and resources. Thus, all the code is executed on the phone, and without the iPhone nearby your application on the clock will not start. The interaction between the phone and the clock is carried out through the WatchKit framework and is hidden from the developer.
Each screen of the application is controlled by a WKInterfaceController class controller object. All controllers, including Glance and notifications, must be executed in the WatchKit App. When the user opens the application on the clock, WatchKit finds the initial controller in the storyboard and tells the iPhone that it is necessary to launch WatchKit Extension and create an object of the desired controller class. Similar actions will occur if the user opens Glance or receives a notification.
The life cycle of a controller is similar to that of its older brother, UIViewController. The init, awakeWithContext:, willActivate methods are used to perform the following tasks:
The initial controller plays a crucial role. Despite the fact that it is essentially a screen controller, it has functions similar to the delegate of the application on the iPhone. It is always created and launched first, it processes transitions from Glance and notifications in the WatchKit application. The initial controller initialization methods are the first entry point into the application. It is there that the application can first look at what data it has and display a suitable interface. If classes, number, order of internal screens can be set from the code, then choose which controller will be initial only in the storyboard during the design of the application.
The WatchKit Extension is launched only when the user interacts directly with the clock, and ends as soon as the user exits the application or simply drops his hand. The concept of working in the background for the WatchKit application does not exist. However, the system can make a “screenshot” of the application. If you lower your hand or exit the application, and then after a short time start it again, you will be taken to the same screen where you’ve finished. Only the corresponding controller willActivate is called.
Differences from the development of the main iOS-application
The essential difference from the development of the main iOS application is that the init controller initialization method is not called by the developer, but by the system. Parameters and data are transferred from the controller to the controller through the context. Any transition from the screen to the screen occurs either automatically by segway or from the code by the controller ID in the storyboard. In both cases, WatchKit finds the desired screen in the storyboard, after which the WatchKit Extension creates an object of the class specified in the storyboard at the screen with the given identifier (for the given segway) and calls its init method. Stack controllers remain “under the hood” of the system. The developer does not see it and works with the code of the controllers, as with abstract and isolated entities.
Another important difference is that all interface elements are proxy objects that are write-only. It is impossible to find out from the label which text it displays, which font and color it uses. Therefore, it is sometimes necessary to store the state of objects in separate variables. In addition, you cannot inherit from the WKInterfaceObject base class, which complicates the design of the application and makes it impossible to create custom interface objects.
There is not even the usual hierarchy of View. You cannot dynamically create and add interface objects. The entire interface must be defined in a storyboard, that is, at the design stage of the application. Linking occurs via IBOutlet. Unnecessary part of the interface is hidden. But we must try to avoid situations where there are two completely alternative interfaces on one screen, one of which is hidden depending on the context. But in some cases, like for example in Glance, this is the only solution.
The didDeactivate method is called by the system to inform the controller that it is no longer on the screen. At the same time, in the body of this method and after its call it is useless to make any changes to the interface - the system will ignore them. It can be very inconvenient when, upon the occurrence of a certain event, it is necessary, for example, to change the displayed text on the screen, which is not currently displayed. It is necessary in some way to postpone event handling until the call willActivate. Because of this, willActivate can turn into a string of conditional checks "but do we need to reconfigure the interface again."
Apple advises "lazy" data loading, where appropriate. In willActivate, you can use dispatch_async and dispatch_after on the main thread.
The main difficulty lies in the fact that the main application on the iPhone and the WatchKit Extension are two different isolated processes with their sandbox. On the other hand, it is logical to assume that if the application on the clock is a supplement to the main one, then it should receive data from its older brother. And here Apple offers several ways:
1. Using App Groups, which allow you to have shared NSUserDefaults and save files in a shared container for a group of applications and their extensions.
This method allows you to get data almost instantly. The main application can write to the group, both in the course of its work, and in background fetch mode. There are some limitations: firstly, the main application cannot simply inform the clock that the data has been updated. Simple KVO to shared NSNotificationCenter does not work. Solution: use in conjunction with the second method or organize data transfer through one well-known pod , which archives data into files and uses the Darwinian notification center; secondly, when recording files, you should pay attention to this warning from Apple.
2. Interact with the main application on the iPhone directly.
The WKInterfaceController class has an openParentApplication: reply: method that, when called, launches the main application on the iPhone. It calls the delegate method application: handleWatchKitExtensionRequest: reply:, which processes the incoming request. From WatchKitExtension, the request completion block is transmitted, which takes the NSDictionary as the response of the main application. In addition to the completion block from WatchKit Extension, you can transfer a dictionary with any information so that the main application on the iPhone can handle different requests depending on the context.
If the main application needs to perform an asynchronous request, for example, request fresh data from the server, it is recommended to register the background task, otherwise iOS can complete it without waiting for the completion. The main limitation of this method : it takes time. Of course, blocking the main thread while waiting for a response is unacceptable, so the question is how to show old data, how to show the user something is happening, how to visually update the data, what to do if an error returns, etc. Another serious limitation : complex objects are not transmitted, it is necessary to serialize them. When designing an application, it is very important to remember that data must be received from somewhere. The creators of some concepts of WatchKit applications clearly did not think about it. Still need to consider security issues. If the displayed data is confidential, then you just can not store them. In this matter, it is better for the main application and the WatchKit application to act in the same way.
3. Handoff as a way to start watching information on the clock, and continue on the phone.
Handoff is implemented very simply. NSUserActivity type names are added to * -Info.plist of the main application. The updateUserActivity method is called on the controller object: userInfo: webpageURL: with a parameter - the name of the required type NSUserActivity. You can pass the necessary additional information to userInfo. At this time, the icon of your application appears on the phone screen in the lower left corner and if you pull it up, the main application will start. The application delegate will invoke the application: willContinueUserActivity and application: continueUserActivity: restorationHandler methods, where you can process userActivity and display the necessary information. At the same time, if the user does not get the phone out of his pocket and tries to unlock it, the system will take care of itself to disable the activity after some time.
Apple Watch itself does not recognize or handle NSUserActivities, with the exception of those generated in Glance. But more about that in the next section.
Glances is an application designed to quickly display important information, which is invoked directly from the watch screen with a swipe from the bottom up. In essence, these are flipped application widgets showing the most up-to-date information, such as weather, stock indexes, calendar information, missed calls, fitness goals and achievements. The order of the application cards is customizable. By the way, the application may not have a display in Glance, if this is not necessary
The configuration of the glance is two parts, the upper one is offset from the center:
The system will provide a universal interface for your notifications, even if you do not implement any interface controller for them in a storyboard. But, of course, I want to make them beautiful and comfortable. Here it is necessary to find the right balance so that notifications do not disturb the user too often, but at the same time provide him with relevant information for the current context. The wording of notifications should be as clear and short as possible, because the clock screen is very tiny. This is especially true for Cyrillic. Russian words are placed on the screen with great difficulty.
Notifications are shown in two stages: Short Look and Long Look . When you receive a notification watch gently vibrates. Raising a hand, the user sees the “short view” of the notification - ShortLook, which is immediately animated in LongLook, if the user has kept his eyes on it:
Long Look contains the full text of the notification, the icon and the name of the application, as well as the button “Skip” the notification. Right here you can shove up to four contextual actions - in the case of our application, for example, “extend speed”. The “Dismiss” button is always provided by the system. Other possible buttons and their corresponding actions must be registered in the code of the main application on the iPhone via UIUserNotificationSettings for certain categories of notifications. That is, they are defined at the design stage of the application, and do not come along with the push. Therefore, it is sometimes useful to create a universal category for notifications, if we want to always show a custom interface.
Button actions can have two types of activation mode: background and foreground. Clicking on the button with the foreground action opens the WatchKit application and calls one of the methods handleActionWithIdentifier: forLocalNotification or handleActionWithIdentifier: forRemoteNotification, to which the identifier of the selected button is transmitted. By clicking on the button with the background action, the main application on the iPhone starts up in the background, and one of the appropriate delegate methods of the application is called.
There are two types of notification interface: static and dynamic . If you implement a custom interface, then you need to create a controller for a static type. The static type of interface is a simplified, generalized type of notification compared to a dynamic one. The system will automatically determine which interface to select, depending on the battery charge and user settings. Dynamic type can not be implemented.
Inside the WatchKit application on the clock, it is possible to change any font except the title and time, as well as the context menu called via ForceTouch. Despite the fact that the San Francisco system font package does not have a Cyrillic style, everything is in order on the clock itself and in Xcode. In Glance and Notifications, however, you cannot use custom fonts.
Inside the main application for all headers is set to Global tint color. It cannot be changed during execution depending on the context or data, it is set at the design stage of the application once and performs the function of the header colors in the application and the application name in the “short view” notifications. Color PageControl, unfortunately, can not be changed either, do not believe the concepts. Do not make users of your application feel as if they are watching an advertisement. For branding it is better to use unobtrusive means : color, fonts, images.
Applications support two types of navigation, which, unfortunately, can not be combined with each other.
Hierarchical navigation is a classic application management method, similar to navigation in iPhone applications using UINavigationController, where the user “goes deeper” into the application. This type of navigation is the most convenient and flexible in technical terms, because it allows you to transfer information to the user in portions and have an unlimited number of nesting levels.
Page navigation (PageControl) allows the user to navigate between the swipe screens. This navigation model is suitable for small applications with a simple data model. When using page-by-page navigation, the content of all pages is loaded at a time, and the dynamic increase in the number of pages is not implemented without a number of tweaks.
Also, in any type of navigation, a modal display of content is possible to attract the user's attention or to resolve issues that require the user to make an unambiguous decision without interacting with the main part of the application. In this case, you can show both one window and several windows connected via Page Control. In the left corner of the modal window, the default header is. Abuse of modal mode is not recommended.
The transition between the screens is entirely processed by the system, and it cannot be customized or animated in any way. In the page navigation, the screens appear to the right and left, in the hierarchical one - the next screen slides from the right edge of the screen, like on an iPhone or iPad, and the modal screen pops up from below.
Gestures
The clock screen is too small for a complete list of gestures used in iOS. Here is what is available to the user:
Custom gestures can not be.
Context menu
The context menu is called up by a Force Touch gesture. It can hide from one to four minor actions. The screen as if is really pressed, and the context menu runs from above. It has a translucent background and from one to four buttons of the system view.
There is a misconception that Apple Watch will have many beautiful animations. Not really, at least in the third-party applications definitely not. If there is a need for animation, forget about the software (or almost forget). You can only animate images. Frame by frame That is, get ready to cut all the frames of the animation separately, just like for old cartoons. Objects cannot be moved. It is impossible to animate transitions between interface states, parallax effect, transitions between screens. Only change image frame. Everything.
You can set an image on the background of the WKInterfaceController controller, the WKInterfaceButton buttons, the WKInterfaceGroup group. And there is a special object for displaying WKinterfaceImage images.
When specifying the image name in the storyboard and in the parameters of the methods ending with imageNamed, the system looks for a picture in the WatchKit App, that is, among those stored on the clock. Methods ending in image and imageData imply that the image is stored in WatchKit Extension, that is, physically on the phone. Therefore, when you use them, the picture is transferred from the iPhone to the clock, which will cause some delay. Animation frames must be named with the same name plus the frame number: for example, “image0@2x.png”, “image1@2x.png”, ..., “image256@2x.png”. In this case, the name of the picture that you specify in the storyboard or transfer in the parameter of the animation start methods will be considered “image”.
Programmatically, you can start and stop the WKInterfaceImage animation and the background of the WKInterfaceGroup group. The best place for this is in willActivate. Moreover, if you want the animation to start already after the user sees the screen, the start call can be wrapped in dispatch_async or dispatch_after. If you want the animation to run periodically, you can use NSTimer to do this.
In the start parameters of the animation, you can specify:
— . , , , . Apple Watch, .
html, . , . . — . , .
, , . . : , . , . origin, . , . . .
. storyboard. , Glance — . , . — .
, , . , , . , — , .
, iOS , . , WWDC , , . , . : , .
, Apple Watch — " ".
See also:
Material Design:
Styling iOS Applications: How We Stretch Fonts, Colors, and Images
:
Our team made one of the first applications in Russia © under the watch. When the developer and designer understand the features of each other's work, the likelihood of the appearance of fantastic design concepts tends to zero, and the development time - to several days. We, Grigory Matvievich ( fountainhead , developer) and Ekaterina Sotova ( lost_in_purple , designer), tell us what you should pay attention to if you are making an application for Apple Watch.
It will be about:
- WatchKit application architecture
- Interacting with the main application on the phone
- Glances
- Notifications
- Identity of the application: fonts, icons, colors
- Navigation
- User interactions via interfaces
- Images and animations
- Layout / Layout
Ideology: personalization, integrity, lightness
“Apple Watch is our most personal device,” they say at Apple. And this is true - the gadget, which is constantly on the hand of its owner, suggests new formats of user interaction, which were impossible or not needed on the smartphone. Watch applications must be adapted to the context in which their owner is located. First of all, this means that the clock should display only the most useful information in a very condensed form, as the person uses them on the go. The main task of watches and good applications for them is to be unobtrusive and useful. Apple focused on tactility (Taptic Engine provides tactile response when notifications come or interaction with the clock occurs) and tried to literally “blur” the boundaries between applications and physical objects: the background of the application imperceptibly flows into the display frame, visually merging into a single unit . The watch does not replace the application on the smartphone, but complements it. Apps on Apple Watch should be as easy as possible to interact. Information should be viewed simply and quickly and depend on the context in which the owner is located, without becoming intrusive. So, for example, the notification is displayed completely if the user has fixed his eyes on it, and Glances show the most relevant and necessary. If user interaction scripts with an application on the iPhone can be measured in minutes, then the duration of interaction with the clock does not exceed, as a rule, several seconds. All this must be kept in mind when designing your applications.
1. Architecture of WatchKit application
In the first version of the smart watch, Apple allowed third-party developers to create applications that are extensions of the main application (hereinafter, an application running on the iPhone, we will call it the “main application” ). And the application that runs on the watch is “WatchKit-application” , or simply “application” on the iPhone. Development exclusively under the Apple Watch promise to do in the future. Now the watch functionality is available through the WatchKit framework and is very limited compared to what you could see at the presentation of the watch itself. It can be seen that the developers at Apple and at several other “selected” companies have more opportunities than others.
')
We will understand how the application is arranged on the Apple Watch. From the point of view of the interface, applications on Apple Watch consist of the following parts:
- An application that has an icon and runs from the watch's main screen
- Glance (preview) - analog widgets on the iPhone
- Notifications
From an architectural point of view, everything is different. Application files are divided into two parts: WatchKit App and WatchKit Extension. The WatchKit App is stored directly on the clock and consists of a storyboard (interface description) and resources. WatchKit Extension is stored on the iPhone and contains code and resources. Thus, all the code is executed on the phone, and without the iPhone nearby your application on the clock will not start. The interaction between the phone and the clock is carried out through the WatchKit framework and is hidden from the developer.
Each screen of the application is controlled by a WKInterfaceController class controller object. All controllers, including Glance and notifications, must be executed in the WatchKit App. When the user opens the application on the clock, WatchKit finds the initial controller in the storyboard and tells the iPhone that it is necessary to launch WatchKit Extension and create an object of the desired controller class. Similar actions will occur if the user opens Glance or receives a notification.
The life cycle of a controller is similar to that of its older brother, UIViewController. The init, awakeWithContext:, willActivate methods are used to perform the following tasks:
- Get the data you want to display.
- Set initial values ​​and configurations for labels, images, buttons and other interface objects.
- Hide unnecessary part of the interface and show the desired one.
The initial controller plays a crucial role. Despite the fact that it is essentially a screen controller, it has functions similar to the delegate of the application on the iPhone. It is always created and launched first, it processes transitions from Glance and notifications in the WatchKit application. The initial controller initialization methods are the first entry point into the application. It is there that the application can first look at what data it has and display a suitable interface. If classes, number, order of internal screens can be set from the code, then choose which controller will be initial only in the storyboard during the design of the application.
The WatchKit Extension is launched only when the user interacts directly with the clock, and ends as soon as the user exits the application or simply drops his hand. The concept of working in the background for the WatchKit application does not exist. However, the system can make a “screenshot” of the application. If you lower your hand or exit the application, and then after a short time start it again, you will be taken to the same screen where you’ve finished. Only the corresponding controller willActivate is called.
Differences from the development of the main iOS-application
The essential difference from the development of the main iOS application is that the init controller initialization method is not called by the developer, but by the system. Parameters and data are transferred from the controller to the controller through the context. Any transition from the screen to the screen occurs either automatically by segway or from the code by the controller ID in the storyboard. In both cases, WatchKit finds the desired screen in the storyboard, after which the WatchKit Extension creates an object of the class specified in the storyboard at the screen with the given identifier (for the given segway) and calls its init method. Stack controllers remain “under the hood” of the system. The developer does not see it and works with the code of the controllers, as with abstract and isolated entities.
Another important difference is that all interface elements are proxy objects that are write-only. It is impossible to find out from the label which text it displays, which font and color it uses. Therefore, it is sometimes necessary to store the state of objects in separate variables. In addition, you cannot inherit from the WKInterfaceObject base class, which complicates the design of the application and makes it impossible to create custom interface objects.
There is not even the usual hierarchy of View. You cannot dynamically create and add interface objects. The entire interface must be defined in a storyboard, that is, at the design stage of the application. Linking occurs via IBOutlet. Unnecessary part of the interface is hidden. But we must try to avoid situations where there are two completely alternative interfaces on one screen, one of which is hidden depending on the context. But in some cases, like for example in Glance, this is the only solution.
The didDeactivate method is called by the system to inform the controller that it is no longer on the screen. At the same time, in the body of this method and after its call it is useless to make any changes to the interface - the system will ignore them. It can be very inconvenient when, upon the occurrence of a certain event, it is necessary, for example, to change the displayed text on the screen, which is not currently displayed. It is necessary in some way to postpone event handling until the call willActivate. Because of this, willActivate can turn into a string of conditional checks "but do we need to reconfigure the interface again."
Apple advises "lazy" data loading, where appropriate. In willActivate, you can use dispatch_async and dispatch_after on the main thread.
2. Interaction with the main application on the phone
The main difficulty lies in the fact that the main application on the iPhone and the WatchKit Extension are two different isolated processes with their sandbox. On the other hand, it is logical to assume that if the application on the clock is a supplement to the main one, then it should receive data from its older brother. And here Apple offers several ways:
1. Using App Groups, which allow you to have shared NSUserDefaults and save files in a shared container for a group of applications and their extensions.
This method allows you to get data almost instantly. The main application can write to the group, both in the course of its work, and in background fetch mode. There are some limitations: firstly, the main application cannot simply inform the clock that the data has been updated. Simple KVO to shared NSNotificationCenter does not work. Solution: use in conjunction with the second method or organize data transfer through one well-known pod , which archives data into files and uses the Darwinian notification center; secondly, when recording files, you should pay attention to this warning from Apple.
2. Interact with the main application on the iPhone directly.
The WKInterfaceController class has an openParentApplication: reply: method that, when called, launches the main application on the iPhone. It calls the delegate method application: handleWatchKitExtensionRequest: reply:, which processes the incoming request. From WatchKitExtension, the request completion block is transmitted, which takes the NSDictionary as the response of the main application. In addition to the completion block from WatchKit Extension, you can transfer a dictionary with any information so that the main application on the iPhone can handle different requests depending on the context.
If the main application needs to perform an asynchronous request, for example, request fresh data from the server, it is recommended to register the background task, otherwise iOS can complete it without waiting for the completion. The main limitation of this method : it takes time. Of course, blocking the main thread while waiting for a response is unacceptable, so the question is how to show old data, how to show the user something is happening, how to visually update the data, what to do if an error returns, etc. Another serious limitation : complex objects are not transmitted, it is necessary to serialize them. When designing an application, it is very important to remember that data must be received from somewhere. The creators of some concepts of WatchKit applications clearly did not think about it. Still need to consider security issues. If the displayed data is confidential, then you just can not store them. In this matter, it is better for the main application and the WatchKit application to act in the same way.
3. Handoff as a way to start watching information on the clock, and continue on the phone.
Handoff is implemented very simply. NSUserActivity type names are added to * -Info.plist of the main application. The updateUserActivity method is called on the controller object: userInfo: webpageURL: with a parameter - the name of the required type NSUserActivity. You can pass the necessary additional information to userInfo. At this time, the icon of your application appears on the phone screen in the lower left corner and if you pull it up, the main application will start. The application delegate will invoke the application: willContinueUserActivity and application: continueUserActivity: restorationHandler methods, where you can process userActivity and display the necessary information. At the same time, if the user does not get the phone out of his pocket and tries to unlock it, the system will take care of itself to disable the activity after some time.
Apple Watch itself does not recognize or handle NSUserActivities, with the exception of those generated in Glance. But more about that in the next section.
To conclude the paragraph, here are some more tips from Apple:
- Make out all the common code in the framework.
- Traffic between the iPhone and Apple Watch needs to be minimized.
- "Hard" work should perform the main application on the iPhone.
3. Glances
Glances is an application designed to quickly display important information, which is invoked directly from the watch screen with a swipe from the bottom up. In essence, these are flipped application widgets showing the most up-to-date information, such as weather, stock indexes, calendar information, missed calls, fitness goals and achievements. The order of the application cards is customizable. By the way, the application may not have a display in Glance, if this is not necessary
Features: Design
- Does not have vertical scrolling.
- Does not support interactive elements: buttons, switches, sliders and menus.
- It allows you to work only with the San Francisco system font, but there are different styles: regular, semibold, medium, light and others.
- Built on a special template consisting of two parts.
- Background Glance - Blurry Clock.
- Apple does not recommend the use of maps and tables, but they are not prohibited.
- Gloss is not always updated before the show, sometimes the system displays a screenshot and the inscription "Last updated on ***"
Features: development
- A tap on the glance opens the corresponding application on the clock and loads the initial controller. Through the user activity, you can process the transition from the glance and show the desired interface from the initial controller.
- The base class of the glance screen controller is the standard WKInterfaceController. Glans has an absolutely identical life cycle, except that a non-trivial amount of time can pass between the init call and the willActivate. Therefore, in willActivate, you should check the relevance of the data.
The configuration of the glance is two parts, the upper one is offset from the center:
4. Notifications
The system will provide a universal interface for your notifications, even if you do not implement any interface controller for them in a storyboard. But, of course, I want to make them beautiful and comfortable. Here it is necessary to find the right balance so that notifications do not disturb the user too often, but at the same time provide him with relevant information for the current context. The wording of notifications should be as clear and short as possible, because the clock screen is very tiny. This is especially true for Cyrillic. Russian words are placed on the screen with great difficulty.
Notifications are shown in two stages: Short Look and Long Look . When you receive a notification watch gently vibrates. Raising a hand, the user sees the “short view” of the notification - ShortLook, which is immediately animated in LongLook, if the user has kept his eyes on it:
Long Look contains the full text of the notification, the icon and the name of the application, as well as the button “Skip” the notification. Right here you can shove up to four contextual actions - in the case of our application, for example, “extend speed”. The “Dismiss” button is always provided by the system. Other possible buttons and their corresponding actions must be registered in the code of the main application on the iPhone via UIUserNotificationSettings for certain categories of notifications. That is, they are defined at the design stage of the application, and do not come along with the push. Therefore, it is sometimes useful to create a universal category for notifications, if we want to always show a custom interface.
Button actions can have two types of activation mode: background and foreground. Clicking on the button with the foreground action opens the WatchKit application and calls one of the methods handleActionWithIdentifier: forLocalNotification or handleActionWithIdentifier: forRemoteNotification, to which the identifier of the selected button is transmitted. By clicking on the button with the background action, the main application on the iPhone starts up in the background, and one of the appropriate delegate methods of the application is called.
Layout notification features: design
- Use different system font styles in LongLook.
- Change the color of the plate with the name of the application in LongLook.
- Set the color of the application name via GlobalTintColor in ShortLook.
But you cannot use interactive elements - buttons, sliders and switches - in notifications.
There are two types of notification interface: static and dynamic . If you implement a custom interface, then you need to create a controller for a static type. The static type of interface is a simplified, generalized type of notification compared to a dynamic one. The system will automatically determine which interface to select, depending on the battery charge and user settings. Dynamic type can not be implemented.
Static Interface Features
- All pictures must be contained in the WatchKit App.
- The interface does not contain tables and maps.
- The entire interface is static, except for one label that will display a notification message.
Features of the dynamic interface
- You can use and change labels, images, groups and separators depending on the content of the notification.
- You can add tables and maps as needed.
5. Application Identity: Fonts, Icons, Colors
Inside the WatchKit application on the clock, it is possible to change any font except the title and time, as well as the context menu called via ForceTouch. Despite the fact that the San Francisco system font package does not have a Cyrillic style, everything is in order on the clock itself and in Xcode. In Glance and Notifications, however, you cannot use custom fonts.
Inside the main application for all headers is set to Global tint color. It cannot be changed during execution depending on the context or data, it is set at the design stage of the application once and performs the function of the header colors in the application and the application name in the “short view” notifications. Color PageControl, unfortunately, can not be changed either, do not believe the concepts. Do not make users of your application feel as if they are watching an advertisement. For branding it is better to use unobtrusive means : color, fonts, images.
Tips: Design
- Do not insert a logo everywhere, it eats the usable space of the screen, while not carrying any functionality.
- Colors should be bright and contrasty for easy reading in extreme conditions like bright sun.
- Do not limit color to display interactivity controls - use standard buttons or animation.
- Texts need to pay special attention. They should be well read in any situations: on the go, on the run, somehow. Do not make the text too small or pale.
- It is recommended to use a black background on the watch - not pictures and not bright colors. The picture on the screen does not have indents, thus continuing the application already in the physical product - in the clock. Due to the fact that a large black frame around the display, it seems that both the application and the physical clock themselves are a single whole.
6. Navigation
Applications support two types of navigation, which, unfortunately, can not be combined with each other.
Hierarchical navigation is a classic application management method, similar to navigation in iPhone applications using UINavigationController, where the user “goes deeper” into the application. This type of navigation is the most convenient and flexible in technical terms, because it allows you to transfer information to the user in portions and have an unlimited number of nesting levels.
Page navigation (PageControl) allows the user to navigate between the swipe screens. This navigation model is suitable for small applications with a simple data model. When using page-by-page navigation, the content of all pages is loaded at a time, and the dynamic increase in the number of pages is not implemented without a number of tweaks.
Tips: Development
- In page navigation, it is better to configure the interface in willActivate, and not in init or awakeWithContext. When loading multiple screens with PageControl, they are all created before the first one is shown. This means that all controllers will call init, awakeWithContext :, and then only the first controller, willActivate. And if you put a lot of action in the initialization, the user will see a long indicator of activity before the first screen appears.
- If the initial controller of the storyboard is connected with page navigation, then the context between the screens cannot be transferred, which forces you to invent your own way of data sharing.
- You can not dynamically change the number of screens that are interconnected through Page Control. To do this, you need to “restart” the application completely (the reloadRootControllersWithNames: contexts: class of the WKInterfaceController method), which in the eyes of the user looks like some kind of error has occurred.
Also, in any type of navigation, a modal display of content is possible to attract the user's attention or to resolve issues that require the user to make an unambiguous decision without interacting with the main part of the application. In this case, you can show both one window and several windows connected via Page Control. In the left corner of the modal window, the default header is. Abuse of modal mode is not recommended.
The transition between the screens is entirely processed by the system, and it cannot be customized or animated in any way. In the page navigation, the screens appear to the right and left, in the hierarchical one - the next screen slides from the right edge of the screen, like on an iPhone or iPad, and the modal screen pops up from below.
7. User interaction through interfaces
Gestures
The clock screen is too small for a complete list of gestures used in iOS. Here is what is available to the user:
- Single tapas.
- Vertical scrolling for long screens.
- Swipe left and right in page navigation.
- Force Touch to call the context menu.
- Wheel Digital Crown. In Apple's applications from Apple, for example, you can zoom. But for developers, only the scroll function is available: in order not to block the screen with your finger, you can simply turn the wheel.
- A gesture from the left edge that returns to the previous screen in hierarchical navigation.
Custom gestures can not be.
Context menu
The context menu is called up by a Force Touch gesture. It can hide from one to four minor actions. The screen as if is really pressed, and the context menu runs from above. It has a translucent background and from one to four buttons of the system view.
Features: Design
- You can customize the context menu only with the icon, while it is impossible to change either the color of the icon or the color of the circle.
- The font is also not customized, the length of the inscription is limited to two lines.
- The user can interact with the following objects: button, switch, slider, table (row selection), context menu.
- Tap on the map opens the map application on the clock.
- While the application is running, objects can change configuration (for example, text with a label), you can change the width and height, as well as the hidden and alpha properties.
- Moving objects (changing origin) is difficult and it is better not to do it.
8. Images and animations
There is a misconception that Apple Watch will have many beautiful animations. Not really, at least in the third-party applications definitely not. If there is a need for animation, forget about the software (or almost forget). You can only animate images. Frame by frame That is, get ready to cut all the frames of the animation separately, just like for old cartoons. Objects cannot be moved. It is impossible to animate transitions between interface states, parallax effect, transitions between screens. Only change image frame. Everything.
You can set an image on the background of the WKInterfaceController controller, the WKInterfaceButton buttons, the WKInterfaceGroup group. And there is a special object for displaying WKinterfaceImage images.
When specifying the image name in the storyboard and in the parameters of the methods ending with imageNamed, the system looks for a picture in the WatchKit App, that is, among those stored on the clock. Methods ending in image and imageData imply that the image is stored in WatchKit Extension, that is, physically on the phone. Therefore, when you use them, the picture is transferred from the iPhone to the clock, which will cause some delay. Animation frames must be named with the same name plus the frame number: for example, “image0@2x.png”, “image1@2x.png”, ..., “image256@2x.png”. In this case, the name of the picture that you specify in the storyboard or transfer in the parameter of the animation start methods will be considered “image”.
Programmatically, you can start and stop the WKInterfaceImage animation and the background of the WKInterfaceGroup group. The best place for this is in willActivate. Moreover, if you want the animation to start already after the user sees the screen, the start call can be wrapped in dispatch_async or dispatch_after. If you want the animation to run periodically, you can use NSTimer to do this.
In the start parameters of the animation, you can specify:
- The initial frame of the animation and the number of frames, that is, for example, specify "scroll 10 frames starting from 23"
- The time over which the animation should go. And if you specify a negative value, the animation will start in the opposite direction (from 32 frames to 23 for the previous example)
- The number of repetitions, where zero means "continue until you stop"
Features: development
- Due to delays in transferring images from the phone to the watch while the application is running, the best scenario now is creating animation for all occasions at the design stage and storing it in resources on the watch.
- There are already projects on github, which allow you to create an iOS animation, convert it into a series of pictures and transmit in real time to the clock. But so far this does not seem to be the optimal work scenario.
- , 5MB. , Apple Watch , WKInterfaceDevice. , , .
- . Devices, — Apple Watch, iOS .
— . , , , . Apple Watch, .
9. /Layout
html, . , . . — . , .
, , . . : , . , . origin, . , . . .
. storyboard. , Glance — . , . — .
:
- Apple Watch , — 38mm, — 42mm. .
- .
- — .
- , , .
, , . , , . , — , .
, iOS , . , WWDC , , . , . : , .
, Apple Watch — " ".
See also:
Material Design:
Styling iOS Applications: How We Stretch Fonts, Colors, and Images
:
Source: https://habr.com/ru/post/256501/
All Articles