Widget Extension, a new addition to iOS 14, provides a new way to display desktop data on the home screen in a timely manner.

What’s new in the Widget

  • Can be displayed on the home screen
  • A variety of sizes
  • Not interactive, only clickable
  • Intelligent stacked

Widget Extension provides three sizes, small, medium, and large. Different sizes can display different data and different interfaces. Developers can also limit their widgets to a certain size and add the same widgets repeatedly. As a control added to the home screen, Apple uses “At a glance” to describe the widget. Therefore, the Widget Extension cannot interact with each other. All it can do is display some information and click, and the click will lead to the APP. Widget Extension also doesn’t display videos and moving images.

In addition, users can put several widgets in the same place, so that the widgets are stacked on top of each other. The Widget Gallery is called Widget Gallery, and users can freely switch between the widgets displayed at the top. At the same time, users can enable smart stacking, and Apple will display different widgets in different situations according to the user’s habits. For example, the weather Widget will be displayed in the morning, and the traffic information will be displayed during the commute. There is no way for developers to specify the location of their widgets in a smart stack.

What’s new in Widget Development

As developers, we are more concerned about how the new Widget Extension will be developed:

  • Swift UI Only
  • Timeline Update
  • IntentConfiguration
  • Link

First, Widget Extension can only be developed through the Swift UI, there is no way to call any UIKit elements. Using only Swift UI is a bold but logical move, as it easily ADAPTS to dark mode, dynamic fonts, etc., ensures that widgets can be developed in accordance with Apple’s design philosophy, and that widgets on iOS, iPadOS, and macOS use the same code.

In addition, the refresh of widget extension is based on the Timeline, instead of the various refresh timing of the original widget based on UIViewController. For example, a stock widget can be updated frequently during trading. However, updates are not allowed at all during non-trading hours, so developers can set the widget’s update timeline in advance, and the system will automatically update the widget at the corresponding time points.

The display content of the Widget can also be customized by the user. For example, the weather Widget allows the user to select the city to display. This customization is based on the Intents framework, which was originally used on SiriKit, and developers do not need to write code. Simply add the relevant configuration items to automatically generate the interface and options.

Finally, the jump clicked by the Widget is handled by a class called Link, similar to NSURL.

Timeline Reload

In the new Widget, the refresh is based on the Timeline, which is a collection of Timeline entries that contain the information to be displayed by the time node and the corresponding time node Widget. The refresh of widgets 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 refresh of the Timeline. System Reloads and app-driven Reloads

System Reloads

  • Predictable event
  • Launched on time
  • Dynamic decision making

System Reloads are usually used to refresh predictable events, such as a stock Widget, which can predict the start and end times of each trading day, so developers can tell WidgetCenter in advance when it needs to refresh the Widget’s timeline. When you can stop refreshing.

Initiated by the system, this action refreshes the Widget Timeline and requests the Widget for the data to be refreshed in the next phase. System Reloads are initiated at regular intervals, such as when the weather Widget is set to refresh once a day, so it refreshes at the corresponding time node. In addition, the system dynamically determines how often the system refreshes the TimeLine for each Widget. If a Widget is viewed frequently, it will be refreshed more often than a less frequently viewed Widget.

App-Driven Reloads

  • Take the initiative to refresh
  • The main APP must survive

This is when the App actively requests data from the Widget for the next phase of refresh. 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.

Timeline Provider

Since “Reload” doesn’t mean refreshing the Widget’s interface, but requesting new Timeline data, the TimelineProvider is the object that provides that data. The data provided by the TimelineProvider consists of two parts: TimelineEntry and ReloadPolicy.

  • TimelineEntry: Contains the information to be displayed in the Widget at the time point and corresponding time node.
  • ReloadPolicy: indicates the refresh policies of the Timeline in the following period. There are three types:
  • AtEnd: indicates that the Timeline is executed to the last oneTimelineEntry“And then refresh.
  • AtAfter: Means to refresh regularly after a certain time.
  • Never: indicates that the Widget does not need to be refreshed in the future, and the App needs to inform the Widget when it needs to be refreshed again.

When the TimelineProvider has provided the next phase of data, it stops running. Based on the TimelineEntry information, the system refreshes the display content of the Widget at the corresponding time node. Developers only provide TimeLineEntry and ReloadPolicy, so the system controls the actual refresh time and refresh frequency of the Widget interface. In this way, the system can better control the power consumption and refresh frequency of the Widget. Avoid a Widget that consumes too much power due to too many refreshes.

Intent Configuration

  • No NEED to write UI code
  • User Settings refresh the Widget screen

In the process of user use, widgets need to be customized. For example, when I add a weather Widget, I can choose where the weather is displayed in my Widget. To achieve this capability, Apple provides the Configuration capability for widgets. As the name implies, configurable. There are two configuration types:

  • StaticConfiguration: indicates a StaticConfiguration related only to user information
  • IntentConfiguration: Dynamic configuration that supports user customization

IntentConfiguration is implemented based on the Intents. Framework, and those of you who have developed SiriKit and Shortcuts will know that the Intents API is for understanding user intentions. In short, it is a smart form system. After creating a SiriKit Intent Definition File, Xcode automatically generates the corresponding code and UI for you.

Link

Widgets’ UI does not support interaction elements such as scrolling. The only open ability is to invoke the main App with a tap or DeepLink.

Apple provides two apis for developers. The first is the WidgetURL API for SwiftUI, whose clickable area is throughout the widget page.

For systemSmall types, only widgetURL is supported, but for systemMedium and systemLarge you can also use the SwiftUI Link API, and Link’s clickable region looks like this:

conclusion

New widgets bring more information to the screen. Apps can display data better on the home screen through widgets, and the new features are interesting and interesting. It is also important to note that the new Widget is currently in Beta, the interface is not yet stable (e.g. the old PlaceHolder has been deprecated), and there are some holes in this area to be aware of during development.

Follow my blog for more content

reference

  • Apple Widget: The next top Traffic entry point?
  • Widgets – System Capabilities
  • Widgets code-along
  • Creating a Widget Extension