应用更新 SDK
集成第三方更新 SDK 可以显著提升用户体验,并简化应用程序更新的管理流程。 然而,与任何第三方库一样,可 能会出现某些问题和挑战。 在本指南中,我们将探讨为什么您可能需要集成此类 SDK,以及在过程中可能会遇到哪些问题。
为什么要集成第三方更新 SDK?
- 提升用户体验
RuStore 应用内更新 SDK 允许用户在无需离开应用程序或进入应用商店的情况下获取更新。 这使得更新过程更加流畅和便捷。 - 提高安全性。 定期更新可能包含安全修复。 集成更新 SDK 有助于确保用户始终使用您应用程序的最安全版本。
- 快速交付新功能
第三方更新 SDK 可以快速地向用户交付新功能和改进。 对于那些处于积极开发阶段且需要频繁更新的应用程序来说,这一点尤为重要。 - 减轻开发人员负担
集成第三方更新 SDK 可以自动化检查和安装更新的过程,从而减轻开发人员的负担,让他们能够专注于改进应用程序的功能。
在应用程序中集成 RuStore 更新 SDK
添加依赖项
添加任何新 SDK 的第一步都是在您的应用程序中添加依赖项。
implementation("ru.rustore.sdk:appupdate:6.0.0")
要使用更新 SDK,我们需要一个更新管理器,请创建更新管理器。
val updateManager = RuStoreAppUpdateManagerFactory.create(context)
更新 SDK 的工作条件
以下是更新 SDK 可用的工作条件。
- 已在 RuStore 控制台 的“推送通知 > 项目”部分上传应用程序数据。
应用程 序已通过审核(无需发布应用程序)。
。
- 应用程序不同类型版本(debug、release 等)的签名和包名(package name)可能互不相同。 在这种情况下,您必须在 RuStore 控制台 的“推送通知 > 项目”部分为每种版本类型创建一个项目。。
- Android 7.0 或更高版本的操作系统。
- 用户设备上的 RuStore 版本为最新版本。
- 用户已在 RuStore 中登录。
- RuStore 应用程序已获准安装其他应用。
检查 SDK 可用性
可以使用 getAppUpdateInfo() 方法来检查 SDK 的可用性。
作为响应,我们将获得一个包含更新信息的 AppUpdateInfo 对象。 AppUpdateInfo 对象包含一组用于确定更新可用性的必要参数。
updateAvailability— 更新可用性。installStatus— 如果用户当前正在安装更新,则为更新的安装状态。
有关状态的详细信息,请参阅文档。
下面是调用 getAppUpdateInfo() 方法的一个示例。
ruStoreAppUpdateManager
.getAppUpdateInfo()
.addOnSuccessListener { appUpdateInfo ->
if (appUpdateInfo.updateAvailability == UpdateAvailability.UPDATE_AVAILABLE) {
// Обновление доступно(здесь можно зарегистрировать listener и начать загрузку)
}
}
.addOnFailureListener { throwable ->
Log.e(TAG, "getAppUpdateInfo error", throwable)
}
在确认可以从应用商店将更新下载到用户设备后,可以请求更新的下载状态。
为此,我们需要一个专门的更新下载状态监听器 registerListener。
监听器的创建与使用。
ruStoreAppUpdateManager.registerListener { state ->
when (state.installStatus) {
InstallStatus.DOWNLOADED -> {
// Обновление готово к установке
}
InstallStatus.DOWNLOADING -> {
val totalBytes = state.totalBytesToDownload
val bytesDownloaded = state.bytesDownloaded
// Здесь можно отобразить прогресс скачивания
}
InstallStatus.FAILED -> {
Log.e(TAG, "Downloading error")
}
}
}
有关下载状态的详细信息,请参阅文档。
应用更新类型
RuStore 更新 SDK 提供了 3 种更新类型:
FLEXIBLE(延迟更新);SILENT(静默更新);IMMEDIATE(强制更新)。
FLEXIBLE(延迟更新)
这是最常见的类型,也是用户习惯的场景:
- 系统将向用户显示 RuStore 的 UI 对话框以确认更新;
- 点击更新按钮后,将显示确认安装更新的对话框;
- 安装完成后,应用将关闭。
下面是调用 FLEXIBLE 更新的一个示例。
startUpdateFlow(appUpdateInfo, AppUpdateOptions.Builder().appUpdateType(FLEXIBLE).build())
SILENT(静默更 新)
无需 RuStore UI(弹窗)提示更新,用户只需确认安装即可:
- 系统将向用户显示确认安装更新的对话框(更新将在后台下载);
- 安装完成后,应用将关闭。
下面是调用 SILENT 更新的一个示例。
startUpdateFlow(appUpdateInfo, AppUpdateOptions.Builder().appUpdateType(SILENT).build())
IMMEDIATE(强制更新)
如果上述更新类型简单易懂,那么强制更新则需要特别关注。
让我们来看看为什么需要第三种更新类型,即使它会破坏用户与应用的交互体验。
在移动应用开发中,有一个概念叫做“旧版本尾巴”。 假设您发布了应用的第一版本,一年后,您已经拥有了一个包含大量针对用户优化、修复和新功能的版本。
但通过查看服务器日志或 Crashlytics 统计数据,您可能会发现部分用户仍在运行产品的第一个版本。
表面上看,既然他们觉得满意,就让他们继续使用吧。 但存在两个主要问题,为了解决这些问题,必须采用强制更新应用:
- Bug、Bug 还是 Bug。
我们每天都能看到使用旧版本应用的用户遇到了在后续版本中已修复的 Bug。 有时这可能是对产品至关重要的关键 Bug,必须尽快为用户消除。 - 引入新功能。
新版本应用中增加了功能,分析数据或该功能带来的收益可能非常重要 —— 但用户并不急于更新,导致您不得不等待。 在这种等待中,您可能会损失时间和金钱。
为了解决这些问题,才有了强制更新机制。 让我们看看如何在应用中使用它。
在获取 AppUpdateInfo 后,您可以检查强制更新是否可用。
if (appUpdateInfo.isUpdateTypeAllowed(IMMEDIATE)) {
// Принудительное обновление доступно
}
建议使用 isUpdateTypeAllowed 函数的结果来决定是否启动强制更新,但该结果并不影响启动该场景的可能性。 启动更新场景的必要性可以根据您的内部逻辑来决定。
startUpdateFlow(appUpdateInfo, AppUpdateOptions.Builder().appUpdateType(IMMEDIATE).build())
更新成功后无需进一步操作。
在集成此阶段,用户设备上已有一个下载好的更新文件。 要完成更新,需要使用该文件执行安装。
为此,请调用 completeUpdate(appUpdateOptions: AppUpdateOptions) 方法。 该方法仅能传递 2 种安装完成类型 —— FLEXIBLE 和 SILENT:分别对应延迟更新和静默更新。
completeUpdate(AppUpdateOptions.Builder().appUpdateType(AppUpdateType.FLEXIBLE).build())
- 如果传递
FLEXIBLE更新类型,应用将重启。 - 如果传递
SILENT更新类型,应用将关闭且不重启。