| 3750c827 | 10-Dec-2020 |
Stanisław Chmiela <[email protected]> |
[expo-notifications] Remove SharedPreferences entry when migrating installation ID to non-backed-up storage (#11283)
# Why
Citing #11249:
>⚠️ **Not removing `SharedPreferences` entry leaves ap
[expo-notifications] Remove SharedPreferences entry when migrating installation ID to non-backed-up storage (#11283)
# Why
Citing #11249:
>⚠️ **Not removing `SharedPreferences` entry leaves app susceptible to the already existing bug** — if backup already has a `SharedPreferences` ID inside and we do not remove it, devices restored in the future will have the same ID. I see a couple of solutions to this problem:
> - keep using `expo_notifications_installation_uuid.txt ?? expo_installation_uuid.txt` for notifications' ID (as in original PR proposal)
> - remove `SharedPreferences` ID and guard against incompatible versions of dependencies with `peerDependencies` — a halfway solution, peer dependencies warnings are often ignored, in some projects may cause `Constants.installationId` to reset.
This pull request implements the second solution by removing `SharedPreferences` entry upon migration.
# How
`SharedPreferences` ID entry exists if a user has already used `expo-notifications` to fetch an Expo push token in the past.
- **in managed workflow** this entry is used solely by `expo-notifications` as they receive an instance of `ScopedContext` which scopes `SharedPreferences`, `expo-constants` and `expoview` use unscoped preferences. In this situation removing the entry should be safe, we remove a value that is used only by us.
- **in bare workflow** this entry is used by both `expo-notifications` and `expo-constants` (backing `.installationId` value).
Removing this value in this scenario is a bit **dangerous** — if we encounter a non-empty value there it means that `expo-constants` is in older version that does not migrate the value to its own storage (`expo_installation_uuid.txt`, `expo-constants`' migration would remove the value, see [code](https://github.com/expo/expo/blob/3df6eb5bc71e00915aa820b70b3a658b98d5a9ef/packages/expo-constants/android/src/main/java/expo/modules/constants/ExponentInstallationId.java#L78-L81)), so if we remove it, next time `expo-constants` runs it will generate a new installation ID, thinking it's a new installation.
There's no simple future-proof solution to this problem, so a solution proposed is to **recommend** upgrading `expo-constants` to a compatible version that will migrate the ID to `expo_installation_uuid.txt` which we will then read in our own migration.
# Test Plan
- managed workflow project updating from SDK39 to SDK40 — identifiers do not change, get migrated to non-backed-up storage ✅
- bare workflow project updating **only** `expo-notifications` and not `expo-constants` — actually identifiers do not change too, we depend on proper version of `expo-constants` in `package.json`, autolinking takes care of picking the highest version so `expo-constants` migrated the ID for us ✅ ��
- bare workflow project updaating both `expo-notifications` and `expo-constants` — same as above
show more ...
|