iOS14新特性探索之二:App Widget小组件应用(二)

简介: iOS14新特性探索之二:App Widget小组件应用

     现在,我们对小组件的创建流程已经有了初步的了解,需要注意,小组件只能用来展示静态的信息,并能支持可交互的组件,例如选择器或滚动视图,当用户点击小组件时,会唤起App本身,并传递一个特殊的URL用来给宿主App做逻辑处理。一个App只能创建一个App Widget,但这并不是说我们只能有一种功能类型的组件,可以通过定义组件包,来提供多个小组件供用户进行使用,示例如下:


struct WidgetExt: Widget {

   public var body: some WidgetConfiguration {

       StaticConfiguration(kind: "WidgetExt", provider: Provider(), placeholder: PlaceholderView()) { entry in

           WidgetExtEntryView(entry: entry)

       }

       .configurationDisplayName("My Widget")

       .description("This is an example widget.")

   }

}


struct WidgetExt2: Widget {

   public var body: some WidgetConfiguration {

       StaticConfiguration(kind: "WidgetExt2", provider: Provider(), placeholder: PlaceholderView()) { entry in

           PlaceholderView()

       }

       .configurationDisplayName("My Widget")

       .description("This is an example widget.")

   }

}


@main

struct WidgetsExt: WidgetBundle {

   @WidgetBundleBuilder

   var body: some Widget {

       WidgetExt()

       WidgetExt2()

   }

}

需要注意,不同的小组件定义的kind参数要有差异。


3. App Widget 的更新机制


       通过前面的Widget初体验,我们知道App Widget可以通过定义时间线来实现视图的动态更新。App Widget使用SwiftUI来进行视图的渲染。Widget有单独的系统进程进行维护,因此即便小组件已经显示在屏幕上,其也并不是一直都是活跃的,开发者可以定义一些时机来对小组件的内容进行更新。


       首先,在开发小组件时,我们要清楚所需要的更新时机。例如对于天气类小组件,可能需要每3小时对组件进行一次更新。当我们定义小组件Widget时,需要指定一个TimelineProvider来对其更新进行驱动,TimelineProvider可以理解为定义了一条时间线,配合官方文档中的一张图片来理解时间线的作用会比较容易:

image.png



如上图中所示,其定义时间线为之后每小时进行刷新,由于将时间线的Refresh机制设置为了atEnd,3小时后系统会重新请求新的Timeline策略,上图中将第2次请求Timeline策略是设置为了立即刷新一次,之后由于时间线的Refresh机制设置为了never,之后不会再尝试请求时间线进行组件更新。时间轴的Refresh选项实际上是设置了当已经定义的时间轴执行完成后,系统将采用怎样的策略(是重新请求还是从此结束更新)。例如下图:

image.png



上图描述了这样一种逻辑,首先请求的时间线定义在未来3个小时,每小时更新一次,并在2小时候重新请求时间线,2小时后新请求的时间线定义2小时后刷新Widget并指定了2小时候重新请求时间线,再2小时之后,重新请求的时间线定义立即刷新组件,并指定之后不再请求新的时间线,组件刷新从此结束。


       除了通过设置Timeline的Refresh机制让Widget请求时间线来进行刷新机制的定义外,宿主App也可以对Widget的刷新机制进行定义。宿主App可以使用WidgetCenter来触发指定Widget的刷新机制更新,如下:


WidgetCenter.shared.reloadTimelines(ofKind: "指定的widget的kind")

同样,WidgetCenter目前也只能使用Swift来调用。


       顺便提一下,关于WidgetCenter,其本身非常简单,提供的接口非常精简,如下:


// 获取单例对象

static let shared: WidgetCenter

// 获取当前Widgets的用户自定义配置

/*

struct WidgetInfo {

   public let configuration: INIntent?

   public let family: WidgetFamily

   public let kind: String

}

*/

func getCurrentConfigurations((Result<[WidgetInfo], Error>) -> ())

// 重新刷新某个Widget的时间线

func reloadTimelines(ofKind: String)

// 刷新所有Widget的时间线

func reloadAllTimelines()

4. 可配置的Widget组件


       前面我们所介绍的构建小组件的方式,虽然可以通过时间线做部分更新逻辑,但对用户来说,依然是静态的。用户不能够根据自己的偏好对组件进行配置,还以天气类组件为例,有些用户可能关心的是空气质量,湿度等信息,有些用户可能只关心阴天雨天的信息,由于小组件的显示空间有限,有时候你无法将所有的信息都展示在组件内,因此让用户选择他感兴趣的信息进行小组件的配置非常重要。


       首先,如果要让我们开发的Widget可以支持用户配置,需要在Widget的target工程中添加一个配置属性表文件,使用Xcode新建一个SiriKit Intent Definition File的文件,如下图所示:


image.png


之后,需要创建一个新的Intent配置,


之后,我们可以添加一系列的用户配置项,系统提供了各种类型的配置项,如让用户传入字符串信息的配置项,开关配置项,日期配置项等等,如下图:

image.png



之后,重新运行Widget,我们的小组件就以支持用户配置功能,用户可以编辑小组件进行设置,如下图所示:


image.png


当用户修改了配置项后,组件会重新请求Timeline时间线,在timeline回调方法中,会传入configuration对象,用来存储用户的配置信息,如下:


   public func timeline(for configuration: ConfigurationIntent, with context: Context, completion: @escaping (Timeline<Entry>) -> ()) {

       // configuration中存放用户配置信息

       var entries: [SimpleEntry] = []

       let currentDate = Date()

       for hourOffset in 0 ..< 5 {

           let entryDate = Calendar.current.date(byAdding: .hour, value: hourOffset, to: currentDate)!

           let entry = SimpleEntry(date: entryDate, configuration: configuration)

           entries.append(entry)

       }


       let timeline = Timeline(entries: entries, policy: .atEnd)

       completion(timeline)

   }

上面演示的这种配置方式,适用于当配置项固定的场景,更多时候,可能连配置项都是动态的,比如我们的应用会根据服务端的状态来提供不同的服务,这时可提供给用户开启的服务项目就是动态的。Widget的配置项也支持动态进行配置,这需要使用到Intents Extension的相关功能,本篇博客就不再过多介绍。


结语:


       App Widgets本身并没有什么新意,只是扩大了iOS系统中组件的能力,这从一定程度上可以带给用户更好的服务和更多元的交互体验。脱离App Widgets这个功能的产品意义本身,iOS 14推出这个功能还有一点非常令人惊讶,就是App Widgets只能使用SwiftUI进行开发,这或许从另一个角度暗示了Swift在未来的推广力度,与iOS开发所使用语言的最终方向。

目录
相关文章
|
6天前
|
安全 Android开发 iOS开发
探索安卓与iOS开发的差异:平台特性与用户体验的深度对比
在移动应用开发的广阔天地中,安卓和iOS两大平台各占半壁江山。本文旨在通过数据驱动的分析方法,深入探讨这两大操作系统在开发环境、用户界面设计及市场表现等方面的差异。引用最新的行业报告和科研数据,结合技术专家的观点,本文将提供对开发者和市场分析师均有价值的洞见。
|
16天前
|
安全 IDE Android开发
探索Android与iOS开发的差异:平台特性与编程实践
【6月更文挑战第17天】在移动应用开发的广阔天地中,Android和iOS两大平台各自占据半壁江山。它们在用户群体、系统架构以及开发环境上的差异,为开发者带来了不同的挑战和机遇。本文深入探讨了这两个平台在技术实现、界面设计、性能优化等方面的主要区别,并提供了实用的开发建议,旨在帮助开发者更好地理解各自平台的特性,从而创造出更加优秀的移动应用。
|
19天前
|
安全 Android开发 iOS开发
探索Android与iOS开发的差异:平台特性与用户体验的对比分析
在移动应用开发的广阔天地中,Android和iOS两大阵营各据一方。本文将深入探讨这两个操作系统在开发环境、编程语言、用户界面设计及市场分布等方面的主要区别。通过比较分析,我们将揭示各自平台的特有优势,并讨论如何根据目标受众和业务需求选择适合的开发平台。
|
1天前
|
机器学习/深度学习 人工智能 文字识别
文本,文字扫描01,OCR文本识别技术展示,一个安卓App,一个简单的设计,文字识别可以应用于人工智能,机器学习,车牌识别,身份证识别,银行卡识别,PaddleOCR+SpringBoot+Andr
文本,文字扫描01,OCR文本识别技术展示,一个安卓App,一个简单的设计,文字识别可以应用于人工智能,机器学习,车牌识别,身份证识别,银行卡识别,PaddleOCR+SpringBoot+Andr
|
26天前
|
数据采集 JSON 算法
使用Python爬取华为市场APP应用进行分析
这个网站也是作者最近接触到的一个APP应用市场类网站。讲实话,还是蛮适合新手朋友去动手学习的。毕竟爬虫领域要想进步,还是需要多实战、多分析!该网站中的一些小细节也是能够锻炼分析能力的,也有反爬虫处理。甚至是下载APP的话在Web端是无法拿到APK下载的直链,需要去APP端接口数据获取
|
13天前
|
安全 Android开发 iOS开发
探索安卓与iOS开发的差异:平台特性与用户体验的对比分析
移动应用开发的两大阵营——安卓与iOS,各自拥有独特的开发环境、用户群体和市场定位。本文将深入探讨这两个操作系统在应用开发过程中的主要差异,包括编程语言、开发工具、用户界面设计、性能优化、安全性考量以及发布流程等方面。通过比较分析,旨在为开发者提供跨平台开发的见解和策略,以优化应用性能和提升用户体验。
14 0
|
16天前
|
应用服务中间件 Linux 网络安全
PHP应用部署在App Service for Linux环境中,上传文件大于1MB时,遇见了413 Request Entity Too Large 错误的解决方法
在Azure App Service for Linux上部署的PHP应用遇到上传文件超过1MB时出现413 Request Entity Too Large错误的解决之法
|
2月前
|
安全 定位技术 网络安全
禁止应用在模拟器上运行的方案及app安全问题
禁止应用在模拟器上运行的方案及app安全问题
77 1
|
2月前
|
存储 数据安全/隐私保护 iOS开发
应用在App Store上被拒重新提交审核流程指南
该文本是关于iOS应用发布的步骤说明
36 2
|
2月前
如何解决iOS16系统app首次启动总是弹出允许粘贴提示框问题
如何解决iOS16系统app首次启动总是弹出允许粘贴提示框问题
36 0
如何解决iOS16系统app首次启动总是弹出允许粘贴提示框问题