Storage is not persistent after closing the app

[bgulotta]

I am able to use the plugin to successfully store and retrieve data on an Android device while the app is running. If i try and close the app out and reopen it the data is no longer found.

[ggozad]

Can you comment if this is the same as #45 If not, could you debug the app and let me know what you see in localStorage?

[drbeermann]

We've seen some reports that our users are getting logged out of our application, which suggests that this could be a problem. I have not been able to replicate it myself, however I do know that it happened on a HTC One running Android 5.0.2. I'll update this issue if we can find any more information.

[GillesC]

LocalStorage isn't always persistend see for instance this thread. That's why I think this plugin should use SharedPreferences to store data, or use this plugin. This is answer is not for getting publicity for my plugin but just for helping out and sharing information.

[ggozad]

@GillesC thanks for this! Would it be possible to make a PR and use native storage instead of localStorage? Obviously in the case of secure storage this would only be necessary for android.

[GillesC]

@ggozad I will try :) I'm also thinking about adding your plugin to mine, I hope that won't give any issues related to circular depencies.

[ggozad]

Instead of depending on each other I would rather have the sharedPreferences implemented. It seems there's a lot of duplication of functionality between the two plugins.

[GillesC]

Are you going to implement a SharedPreference based storage mechanism? If so I could focus on my own plugin, and begin adding your plugin as a dependency. Thanks.

[ggozad]

@GillesC I was hoping you or somebody else would step up and do the work :) I don't have the time to do so immediately, but it has to happen eventually.

In our case, it shouldn't be complex: it's just about replacing locaStorage.get/set with share preferences or whatever other mechanism exists on android.

[GillesC]

Yeah but the NativeStorage plugin does just that. So just replacing localstorage with NativeStorage should be simple and clean.

[demetris-manikas]

Since values for API 19 are created by sjcl I believe that a SharedPreferences plugin should be used instead of implementing a SharedPreferences interface. When the sjcl dependency goes away then we could review the implementation.

cordova-plugin-app-preferences seems like a good choise.

[ggozad]

@demetris-manikas Not sure I understand how sjcl affects SharedPreferences. Both sjcl and native produce strings that we store to localStorage. We might as well store them elsewhere. Can you elaborate if I am missing something?

I am very reluctant to add a dependency: 1) While cordova-plugin-app-preferences seems mature and well maintained, a dependency in something as big might break secure-storage anytime.
2) We do not need the full functionality of the plugin for any other platform than android. 3) People are reluctant to use plugins that bring in other plugins. I know I am and avoid it as much as possible. 4) Performance.

[demetris-manikas]

@ggozad If values were only produced natively then SecureStorage.java would only expose get/set methods only and use the SharedPreferences internally. Usage of sjcl requires the addition of store/fetch methods.

I proposed the usage of a dependency so that we don't have to maintain code related to SharedPreferences.

1) a dependency is defined by plugin+version and this way we can avoid breaking secure-storage if something is broken in the dependency. 2) a dependency will be added only for the android platform 3) You are right about this 4) Since two native calls have to be done to actually store or fetch a value even if we implement the SharedPreferences handling I don't see why it will be less performant to use another plugin.

If you believe that matter 3 is more important than maintaining more code then I 'll be happy to write that code!

[ggozad]

@demetris-manikas Yes please go ahead.

If native AES is used then the plugin should not use the bridge for get/set methods but rather do it internally. Two calls to the bridge should only be made is sjcl is used.

To be honest I don't see sjcl staying in for long, eventually we will deprecate it and move to Android 21.

[ggozad]

Should be resolved.