android应用程序_如何检测Android应用程序更新

android应用程序

Imagine you’re revisiting an existing feature on your application. Sometimes, it’s such a change from the previous version that you will want to communicate about it. You might want to onboard your users with this updated functionality.

假设您正在重新访问应用程序中的现有功能。 有时,它是对以前版本的更改,您需要就此进行交流。 您可能希望使用此更新的功能来吸引用户。

You want to trigger such an event when you’ve shipped this feature. However, notifying users who upgrade your app is all that matters. It brings no value to onboard new users from a revisited experience.

交付此功能后,您想触发此类事件。 但是,通知用户升级您的应用程序很重要。 重新体验不会给新用户带来任何价值。

The Android SDK provides no mechanism to distinguish how your users obtained your application. They may have done so by either:

Android SDK没有提供机制来区分用户如何获取您的应用程序。 他们可能通过以下任何一种方式这样做:

  • Downloading your app from scratch.

    从头开始下载您的应用程序。
  • Updating from an existing version.

    从现有版本更新。

It would help if you had a mechanism to compare two versions. Let’s see how we can achieve this.

如果您有一种比较两个版本的机制,那将有所帮助。 让我们看看如何实现这一目标。

比较两个不同的版本 (Comparing Two Different Versions)

Naming versions can differ from one company to another. I’ll assume you endorse the MAJOR.MINOR.PATCH naming convention. If so, I’d recommend using the following library.

命名版本可能因一家公司而异。 我假设您认可MAJOR.MINOR.PATCH命名约定。 如果是这样,我建议使用以下

Add this dependency in your build.gradle file:

build.gradle文件中添加此依赖build.gradle

dependencies {
implementation 'com.g00fy2:versioncompare:1.3.4'// latest version
}

This library embeds version comparison. They handle the MAJOR.MINOR.PATCH naming convention as well as pre-release suffixes.

该库嵌入了版本比较。 它们处理MAJOR.MINOR.PATCH命名约定以及预发行版后缀。

You’re free to put in place your version comparison mechanism, depending on your version naming convention.

您可以根据您的版本命名约定随意设置版本比较机制。

检测更新 (Detecting Updates)

With your version comparison mechanism, you can create an UpdateDetector class.

使用版本比较机制,可以创建UpdateDetector类。

This class will be responsible for storing the current version. For such data, SharedPreferences seems enough, although the arrival of DataStore could be a better candidate soon.

此类将负责存储当前版本。 对于此类数据, SharedPreferences似乎足够,尽管DataStore的到来可能很快就会成为更好的选择。

You’ll also want to keep the current version in RAM. That way, you can handle the migration throughout the entire user’s session.

您还需要将当前版本保留在RAM中。 这样,您可以处理整个用户会话中的迁移。

Finally, the class should expose a callback to execute the migration.

最后,该类应公开一个回调以执行迁移。

Here is the implementation you could come up with. For convenient reasons, the next classes rely on dependency injections with Hilt.

这是您可以想到的实现。 出于方便的原因,下一个类依赖于Hilt的依赖项注入。

@Singleton
class UpdateDetector @Inject constructor(private val updatePreferences: UpdatePreferences) {


    /**
     * Store in RAM version so that we can directly save new version in preferences while using previous version in same session (Singleton)
     */
    private var version = updatePreferences.version


    /**
     * Save current version into preferences. Must be called at app launch
     */
    fun updateVersion(currentVersion: String) {
        updatePreferences.version = currentVersion
    }


    /**
     * Check if the version in RAM exists and is lower than target version
     */
    fun doOnUpdate(targetVersion: String? = null, call: ((previousVersion: String?, newVersion: String) -> Unit)? = null) {
        val previousVersion = version
        val newVersion = updatePreferences.version
        if (previousVersion != null && newVersion != null &&
            Version(previousVersion).isLowerThan(targetVersion) &&
            Version(newVersion).isAtLeast(targetVersion)) {
            call?.invoke(previousVersion, newVersion)
        }
    }
}

And the class handling the version storing:

和处理版本存储的类:

class UpdatePreferences @Inject constructor(context: Context) {


    companion object {
        private const val UPDATE_DETECTOR_SHARED_PREFERENCES = "updateDetector"


        private const val VERSION = "updateDetector:version"
    }


    private val sharedPreferences: SharedPreferences by lazy { context.getSharedPreferences(UPDATE_DETECTOR_SHARED_PREFERENCES, Activity.MODE_PRIVATE) }


    var version: String?
        get() = sharedPreferences.getString(VERSION, null)
        set(value) {
            value?.let { sharedPreferences.putString(VERSION, it) }
        }
}

处理迁移(Handling Migration)

Now that you’ve implemented an update detector, you have all the tools to run your migration. You can trigger any code you want to all users coming from any version to a dedicated version.

既然您已经实现了更新检测器,便拥有了用于运行迁移的所有工具。 您可以触发所有用户从任何版本到专用版本的任何代码。

Make sure you’re acknowledging the version update in your Application class. You can still access the previous version and compare it with the current one, as the detector stores it in the RAM.

确保在Application类中确认版本更新。 当检测器将其存储在RAM中时,您仍然可以访问以前的版本并将其与当前版本进行比较。

Finally, you can inject the detector anywhere in your code (it’s a singleton). Handle the migration the way you want from one version to another.

最后,您可以将检测器注入代码中的任何位置(单例)。 以所需的方式处理从一个版本到另一个版本的迁移。

@HiltAndroidApp
class UpdateDetectorApplication : Application() {


    @Inject
    lateinit var updateDetector: UpdateDetector


    override fun onCreate() {
        super.onCreate()
		
	// Update app version for next session
        updateDetector.updateVersion(BuildConfig.VERSION_NAME)
		
	// Listen to app updates
	updateDetector.doOnUpdate { previousVersion, newVersion ->
	    // Handle migration for specific versions
        }
    }
}

关于应用程序更新检测的想法(Thoughts About App Update Detection)

This update mechanism remains basic in its concept. A better storing system would prevent the loss of update events. As of now, your users may never hit your migration handling.

此更新机制在其概念上仍然是基本的。 更好的存储系统可以防止丢失更新事件。 截至目前,您的用户可能永远都无法实现您的迁移处理。

Imagine they decide to exit the app before reaching the place where we wanted to onboard them. Next time your users would launch the app, the app would consider your users as updated.

想象一下,他们决定在到达我们想要登机的地方之前退出应用程序。 下次您的用户启动该应用程序时,该应用程序会将您的用户视为已更新。

Moreover, you may have realized this mechanism works well as long as you anticipate it. The sooner you ship it, the more users will have a previous version stored on their device.

此外,您可能已经意识到,只要您期望它,该机制就可以很好地工作。 越早发货,用户越会在其设备上存储以前的版本。

If you haven’t delivered it long before you start using it, you won’t be able to distinguish new users from pre-existing users.

如果您在开始使用它之前不久还没有交付它,则将无法区分新用户和已有用户。

If you’re thinking long-term, I’d strongly suggest including such a mechanism as early as possible.

如果您考虑的是长远考虑,我强烈建议您尽早加入这种机制。

翻译自: https://medium.com/better-programming/how-to-detect-an-android-app-update-7ded8560af31

android应用程序

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值