clearing String value with null doesn't make contains() return false

[sameerjj]

putting null String in preferences and then checking contains(), contains() will always return true.
it seems that Harmony uses some NULL_VALUE parameter to null key-values which leads to this behaviour which is inconsistent with the default SharedPreferences implementation

prefs.edit().putString(key, null).apply()
prefs.contains(key) // returns true

[pablobaxter]

Does this happen between processes or within a single process?

[sameerjj]

Thanks for your response. Although I use Harmony in a multi-process environment, this occurs within a single process.
If it helps, it's possible that the key/value didn't exist initially, and the first operation on that key was to enter a null value. But I did notice in the code that handling NULL is handled specially, not as a null but NULL_VALUE. My guess is that exists() doesn't account for this.
my init code:

prefs = context.getEncryptedHarmonySharedPreferences(
            PREF_NAME,
            keyAlias,
            EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
            EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
        )

[pablobaxter]

Ah, it's the encryption library. I will take a look at this issue. Thank you for this bug report!

[pablobaxter]

What's interesting here is that Androidx EncryptedSharedPreferences does the exact same thing. Going to dig a bit more before I make this change, but whether it's intended or not, I plan to fix in Harmony.

[pablobaxter]

It looks like EncryptedSharedPreferences will be deprecated soon. Either way, I have a PR to fix this issue (#57).

[pablobaxter]

@sameerjj I have pushed an update to fix this issue. Please update to v1.2.6 for the fix.