Skip to content

Min/Max version constraints behaviour #42

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
angelolloqui opened this issue May 19, 2022 · 4 comments
Open

Min/Max version constraints behaviour #42

angelolloqui opened this issue May 19, 2022 · 4 comments
Assignees
Labels
accepted enhancement New feature or request

Comments

@angelolloqui
Copy link

Hi, I am running into something similar to what I expressed in the iOS SDK some months ago regarding the behavior of min/max version constraints. Basically, this:

What I expected

Min/Max to be applied not only on downloading but also in future uses. So, if for example I am in app version 3.1.0, and there is an OTA for [3.0.0 - 3.2.0], then I expect OTA to download and use that file. However, when the user updates the app (without deleting) to 3.3.0, I was expecting the OTA to no longer apply and therefore serve strings from the app bundle rather than the outdated OTA file.

What I see happening

Min/Max is applied on download, so it only gets a new OTA file if the app version matches the range. However, once the OTA is downloaded, it seems to be used every time from now on, even if the app upgraded to a version that is no longer under the OTA range.

What is the problem?

The main issue I see with this behavior is that the translations are no longer consistent. So, if I update strings, users that downloaded some old OTA content are now seeing the old strings even if they have the app updated with newer texts, while new users downloading the app today see something newer (coming from the binary)

Can you confirm if the Android SDK is behaving this way on purpose? could you make an update like the one in iOS to make the versioning more consistent? otherwise, could it be possible to at least have a "clear cache" method or alike to reset the state after each app upgrade?

Thanks!

@angelolloqui
Copy link
Author

angelolloqui commented May 19, 2022

For anyone interested on the same, I am for the time being executing this code just before doing the Phrase.setup:

private fun fixOTACache() {
        val preferences = getSharedPreferences("PREF_UNIQUE_ID", Context.MODE_PRIVATE)
        val currentVersion = BuildConfig.VERSION_NAME
        val lastClearVersion = preferences.getString("ota_cleared_cache_version", null)
        if (lastClearVersion != currentVersion) {
            File(filesDir, ".phrase_cache").deleteRecursively()
            val keys = preferences.all.keys.filter { it != "PREF_UNIQUE_ID" }
            preferences.edit().apply {
                keys.forEach(::remove)
                putString("ota_cleared_cache_version", currentVersion)
            }.commit()
        }
    }

What it does is to delete the previous cached data when there is an app version update, because the downloaded OTA for that new version might be no longer applicable.

@theSoenke
Copy link
Contributor

Hey @angelolloqui, thanks for raising this for the Android SDK. Right now the SDK does not validate the version constraints once the translations have been downloaded. We have this also as an improvement in our backlog and I'll let you know when this has been solved in the SDK

@angelolloqui
Copy link
Author

Hello @theSoenke , what is the status of this? have you implemented some kind of version control in the android sdk as mentioned here? thanks!

@theSoenke
Copy link
Contributor

Hi @angelolloqui, unfortunately some other tasks have been taking priority for Android over this issue. But unless any unforeseen new tasks should take priority this will worked on as one of the next tasks

@forelabs forelabs added enhancement New feature or request accepted labels Apr 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants