Edit | orange
New retail product | alibaba tao technology
On June 22, 2020, Apple held its first online developer conference, WWDC20. It was a historic event, with a series of exciting announcements including the ARM-based Mac chip, the integration of hardware and software, and the overhaul of the iOS 14 interface.
Of course, the widgets that interest me the most are the ones that give the iOS interface a makeover. The iOS desktop interaction experience has been a long story for the past few years, and the addition of widgets is definitely a big break. As I watched the event, the question came to my mind: “Is this the next gateway for competing Internet companies?”
Before jumping to conclusions, let’s take a look at what WWDC20 introduces.
What is a Widget?
Widget is not a small App. It is a new form of desktop content presentation designed to compensate for the inability of the main application to present data that users care about in a timely manner. As shown below:
A good Widget should be Glanceable, Relevant, and Personalized.
Glanceable
It is often said that a Widget is not a small App. The average user visits the home screen more than 90 times a day, but stays there for a total of just a few minutes. Typically, users will only stay on the home screen for a short time before jumping to other places, so there is no need for complex interaction design to enhance the Widget, nor for complex styles to enrich the Widget. Simplicity is the key to widgets.
Unlike Android widgets, Apple’s widgets don’t support any complex interactions and don’t recommend overly complex styles for rendering content, which fits with Apple’s reticence about home-screen improvements.
Appropriate presentation (Relevant)
Apple expects widgets to be closely integrated with what is being done or considered. For example, when you wake up in the morning, the most important thing you care about is the weather. Once you wake up, you must put Reminders into your day. Widgets can display Reminders; At the end of the day, when you’re ready for bed, use the Widget to turn on the music for a little relaxation. To do this, Apple offers a feature called Smart Stacks, which is a collection of Widgets. The system will automatically display the exact Widget at the top, based on each person’s habits, using the ability of the end intelligence.
Of course, Apple also considers some special scenarios, such as Widget Gallery browsing, providing the Snapshot capability for developers to customize display styles, Placeholder UI APIS for loading content instead of monotonous loading boxes to avoid too many white screens. These designs serve only one purpose. Apple expects widgets to behave properly in any given scenario.
Personalized
Widgets require some customization capabilities. For example, when I add a weather Widget, I only need to care about the weather in Hangzhou. To achieve this capability, Apple provides the Configuration capability for widgets. As the name implies, configurable. There are two configuration types:
-
StaticConfiguration: the user does not need to be configured. The content displayed is only related to the user information.
-
IntentConfiguration: supports the function of predicting user configurations and user intentions.
IntentConfiguration is implemented based on the Intents. Framework, and SiriKit and Shortcuts will certainly know that the Intents API is for understanding user intentions. In fact, it is a smart form system. After creating a SiriKit Intent Definition File, Xcode will automatically generate the corresponding code and type for you with simple configuration.
When the developer has written the configuration, the Intents. Framework’s ability to draw a configuration page directly at runtime (as shown below) does not require the developer to care how to write the page.
How widgets refresh
The way widgets refresh is unique and fairly restrained. Before we start talking about refresh, there’s a concept called Timeline. As the name implies, it is a Timeline. The figure below is a Timeline.
When the System WidgetKit calls the Reload Timeline API, the Widget Extension Timeline Provider is required to provide a set of TimelineEntry and ReloadPolicy. Used to refresh the page later.
There are many concepts here, so let’s explain them one by one.
First, the refresh of the Widget is completely controlled by WidgetCenter. There is no API for developers to actively refresh the Widget’s page, only to tell WidgetCenter that the Timeline needs to be refreshed.
The system provides two ways to drive the Reload of the Timeline. System and app-driven Reloads.
System Reloads: This behavior is initiated by the System and invokes the Reload Timeline once to request data from the Widget for the next phase of refresh. In addition to initiating System Reloads on time, the System also dynamically decides the frequency of System Reloads of each different TimeLine with the help of end intelligence. For example, the number of times the System Reloads are viewed largely determines the frequency of System Reloads. System Reloads are also triggered by changes in the device environment, such as device time changes.
App-driven Reloads: Data that the App requests to refresh the Widget in the next phase. There are also two scenarios, application running in the foreground and application running in the background. When running in the foreground, the App can directly request WidgetCenter’s API to trigger the Reload Timeline. When the application is in the Background, the Background Notification can also trigger the Reload Timeline.
Note that the Reload Timeline mentioned earlier does not refresh the Widget directly, but WidgetCenter re-requests the Widget for the next phase of data. The Timeline Provider is the object that provides this data.
The data provided by the Timeline Provider consists of two parts: TimelineEntry and ReloadPolicy.
TimelineEntry is the view information and point in time that the Widget needs to present under a time node.
The ReloadPolicy refers to the refresh policy of the Timeline in the following period. There are three types:
-
AtEnd: refreshes the Timeline when it reaches the last time slice.
-
AtAfter: Means to refresh regularly after a certain time.
-
Never: indicates that there is no need to refresh later. The App needs to tell the Widget when it needs to be refreshed.
The Timeline Provider stops running when it has provided the next phase of data. The system also refreshes the display content of the Widget based on the entry information. It is worth noting that WidgetKit caches the Views structure information corresponding to Timelines’ Entries to disk and then jit-rendering them when refreshed. This enables the system to process Timelines information for many Widgets with very low power overhead.
In short, Apple has been fairly restrained in refreshing widgets. Developers cannot directly decide on Widget refresh, only provide refresh policies. The specific time and pace are all controlled by the system. Apple is most likely doing this to improve the performance of the home screen and reduce battery costs.
Widgets and SwiftUI
Widgets can only be developed using SwiftUI. Specifically, widgets are essentially a SwiftUI view that updates over time.
When I first learned about this restriction, it was quite shocking to be honest. As we all know, SwiftUI is a new technology that was released last year, and at the beginning, SwiftUI was quite unstable, so Much so that Apple itself advised developers not to use it in production environments for the time being. Is it too radical to force the use of such a new technology as a home screen function?
Obviously not. Apple’s requirement that widgets only use SwiftUI is based on several considerations:
1. SwiftUI has improved a lot over the past year. Not only can you use SwiftUI to build entire applications, but it is better than UIKit-based development in some aspects. For details, please check out WWDC 20 SwiftUI’s Major Changes and Core Strengths.
2. Apple is laying out a cross-platform, unified strategy. As a core feature of the system, SwiftUI is the only option. SwiftUI’s elegant DSL design makes it easy for developers to use a single set of code to present different styles on multiple platforms such as iOS, iPadOS, macOS, watchOS and tvOS. (Widgets will only be shown on iOS, iPadOS, and macOS)
3. SwiftUI makes the cost of adapting Dynamic Type and Dark Mode very low.
4. Many of the restrictions on widgets can only be met using SwiftUI. There’s probably a million ways developers can get around Apple’s restrictions if they can use UIKit. For example, developers can’t use UIViewRepresentable to bridge UIKit; using any UIKit element will Crash.
5. Increased the importance of Swift and SwiftUI by a significant amount.
How widgets are presented
One App can have multiple Widget extensions
You can use WidgetBundle to do this. Apple doesn’t have a limit on the number of Widget extensions. Therefore, in order to avoid the inconvenience of developing too many Widget extensions, you can only see one item in the Widget Gallery.
A Widget Extension comes in only three sizes
Consider the simplicity and limited screen space. Apple only offers three styles to choose from: systemSmall (2* 2 icon area), systemMedium (2*4 Icon area), and systemLarge (4 *4 icon area).
The same Widget can be added to the home screen multiple times
Each Widget has its own TimeLine, which is independent and does not interfere with each other.
– Developers can’t make Smart Stacks
Developers cannot develop a collection of widgets. Smart Stacks is a system-specific capability, and the only thing a developer can do is proactively provide relevant information. As mentioned above, the data of Timeline is composed of a set of Timelineentries, and each TimelineEntry can include a TimelineEntryRelevance object in addition to time points and view information. Used to indicate the relevance of this entry.
Not interactive, only clickable
The Widget’s UI is stateless, does not support scrolling, and does not support interactive elements like the Switch. The only open ability is to invoke the main App with a tap and DeepLink.
Apple provides two apis for developers. The first is the SwiftUI widgetURL API, which looks like this:
WidgetURL’s clickable areas are as follows:
For systemSmall, only widgetURL is supported, but systemMedium and systemLarge can also use the SwiftUI Link API, as shown below:
The clickable area of Link is as follows:
At the same time, for performance and power consumption. Widgets cannot display video and motion images. So expect to attract the attention of users through dynamic effects can temporarily stop the fire ~
Summary and Prospect
With the advent of widgets, the iOS desktop has been disrupted, and there will be many products looking to enrich their content expression with widgets.
However, while widgets are designed to be straightforward and present personalized content at the right time, they are technically restrained and limit many, many capabilities in order not to complicate the overall experience on the home screen. So I don’t think widgets are going to be the next traffic entry point for Internet companies to compete with, they’re going to be a way for apps to enhance the user experience.
From a technical perspective, SwiftUI Only’s seemingly “radical” strategy is actually a signal of how serious Apple is about Swift and SwiftUI.
While there’s really not much that can be done with Pure SwiftUI’s design so far, I’m sure Apple will continue to improve its capabilities. Developers can adapt to more platforms with the lowest development costs.
Finally, I hope you can take a good look at widgets and combine them with your own products to give users the best user experience.
reference
IOS 14 Preview www.apple.com.cn/ios/ios-14-…
Widgets code – along developer.apple.com/news/?id=yv…
Meet WidgetKit developer.apple.com/videos/play…
What ‘s new in SwiftUI developer.apple.com/videos/play…
Add the configuration and intelligence to widgets developer.apple.com/videos/play…
Build SwiftUI views for widgets developer.apple.com/videos/play…
Creating a Widget Extension developer.apple.com/documentati…
Building Widgets Using WidgetKit and SwiftUI developer.apple.com/documentati…
Making a Configurable widgets developer.apple.com/documentati…
Keeping a Widget Up To Date developer.apple.com/documentati…
Mobile client team
Responsible for basic PaaS and platform technology of Mobile terminal of Handtao. Involving mobile gateway, network speed, long channel, image experience, such as basic technology, and the mass being pushed, supernatant by hit the whole domain of platform technology, and the mobile client system frontier to explore, to create the total IPv6, iOS user mode network stack, Android minimum nuclear, high-performance technology such as adaptive thread scheduling and architecture.
Here, you will face the ultimate pursuit of super App in performance, experience, security and other aspects; Here, you will fully understand and optimize your goals from a business and data perspective; Here, you will work side by side with the industry leaders in various fields, rapid growth.
We are looking forward to having you join us and share the positive, transparent and open team atmosphere with us. Along with all kinds of training and business and technical challenges, we will continue to break through the old and bring forth the new in the field of technology and sail to the sea of stars together.
Position: iOS development, Android development, C++ development, Java server development, front-end development, data engineer, algorithm engineer
Interested students can send their resume to: [email protected], to get the priority of internal promotion qualification!