SDK应用更新
集成第三方更新SDK可以极大地改善用户体验，简化管理应用更新的过程。但是，与任何第三方库一样，可能会出现一些问题和挑战。在本指南中，我们将探讨为什么要集成这样一个SDK，以及在此过程中可能会遇到哪些问题。
为什么要集成第三方SDK进行更新？
- 优化用户体验
RuStore In-App Updates SDK支持用户无需退出应用或跳转至应用商店即可获取更新。这大幅提升更新流程的流畅性与便捷性。 - 增强安全性。定期更新可能包含安全补丁。集成更新SDK可确保用户始终使用您应用的最安全版本。
- 快速交付新功能
第三方更新SDK允许您快速向用户交付新功能和改进。这对于正在积极开发和需要频繁更新的应用程序尤其重要。 - 减轻开发人员的负担
集成第三方更新SDK可自动完成版本检测与安装流程，有效减轻开发者工作负担，使其能集中精力优化应用功能。
将RuStore Update SDK集成到应用程序中
添加依赖项
添加任何新SDK都是从向应用程序添加依赖项开始的。
implementation("ru.rustore.sdk:appupdate:6.0.0")
为了使用更新SDK，我们需要一个更 新管理器，创建一个更新管理器。
val updateManager = RuStoreAppUpdateManagerFactory.create(context)
SDK更新条款
以下是SDK更新可用性的条件。
- 应用程序数据已经从RuStore控制台的Push Notifications > Projects部分加载。
- 应用程序已通过审核(不必发布该应用程序)。
• 应用程序的不同构建类型（调试、发布等）的签名和包名可能彼此不同。在这种情况下，您应该在RuStore控制台的Push Notifications > Projects部分中为每种构建类型创建一个项目。 • 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 (无界面更新)
没有UI的更新（窗帘）RuStore提供更新-用户只需要确认安装：
- 用户将弹出确认安装更新的对话框（更新将在后台下载）；
- 安装完成后应用将自动关闭。
下面是一个SILENT更新调用的示例。
startUpdateFlow(appUpdateInfo, AppUpdateOptions.Builder().appUpdateType(SILENT).build())
IMMEDIATE (强制更新)
如果说前几种更新类型简单易懂，那么强制更新则需要特别关注。 下面我们分析为何需要这种会"破坏"用户体验的第三种更新机制。 在移动应用开发中，存在所谓的"旧版本长尾现象"。假设您发布了应用的首个版本，一年后已迭代出包含大量修复和改进的新版本，这些更新都是基于用户需求开发的。 但通过服务器日志或Crashlytics分析工具，您可能会发现仍有部分用户在使用最初的版本。 表面看来，既然用户满意似乎无需干预。但存在两大核心问题，必须通过强制更新解决：
- 漏洞，漏洞，还是漏洞。 我们每天都会遇到使用旧版本的用户遭遇已知问题的情况——这些漏洞在新版本中早已修复。有时这可能是严重影响产品使用的关键漏洞，必须立即为用户修复。
- 新功能推广 新版应用新增的功能可能涉及重要的数据分析或收益模块，但用户迟迟不更新导致这些价值无法实现。这种等待意味着时间和金钱的双重损失。 正为解决这些问题，强制更新机制应运而生。接下来我们将详解如何在应用中实施该机制。 在获取 AppUpdateInfo 后，您可以检查强制更新的可用性。
if (appUpdateInfo.isUpdateTypeAllowed(IMMEDIATE)) {
// Принудительное обновление доступно
}
建议使用isUpdateTypeAllowed函数的结果来决定是否启动强制更新，但此结果不影响启动流程的可能性。更新流程的启动需求可以根据您的内部逻辑进行。
startUpdateFlow(appUpdateInfo, AppUpdateOptions.Builder().appUpdateType(IMMEDIATE).build())
如果更新成功，操作结束。
在当前集成阶段，用户设备上已下载更新文件。要完成更新，需使用该文件执行安装操作。 为此调用 completeUpdate(appUpdateOptions: AppUpdateOptions) 方法。该方法仅支持两种安装完成类型参数：FLEXIBLE和SILENT——延迟安装和后台自动安装。
completeUpdate(AppUpdateOptions.Builder().appUpdateType(AppUpdateType.FLEXIBLE).build())
- FLEXIBLE模式：应用将自动重启以完成更新。
- SILENT模式：应用会直接关闭且不重启。