Sensing settings reset when switching to a new channel

[shankari]

I ran into this issue while testing #9.
Both android4 and iphone4 eventually went to continuous (non-duty cycled) data collection with no further user interaction.

Note from #9 (comment)
that the other settings are put into the database on plugin initialize.

The problem is that when we switch to a different channel while clearing out the usercache, the other settings are cleared too. So if we don't force-kill the app, which we typically don't, there is no entry in the database. And then when we sync, if there is an overridden entry on the server, then we end up with an overridden entry on the phone.

[shankari]

One potential solution is to turn off the rw document code that pulls settings from the usercache. We are not using the option of pushing new settings from the server anyway.

The problem with that is that it is completely untested, and I want to release this today.

[shankari]

This may not be an issue with clients that, unlike the test phones, don't have any overridden settings. Eventually the app will restart and then save the entries in the database again.

The problem is that I am not sure how best to test this. The values are in the usercache and are doing to be pulled down. Unless I manually remove them just for the test phones.

[shankari]

One workaround for now, since cci client users can't actually change their data collection settings, we can add code for that channel alone to store default settings into the database on startup (just like the connection settings). This will ensure that after switching to the other channel, we will have current settings in the database again.

[shankari]

Another option is to just set clear_usercache to False. The problem with that is that if somebody does go through the entire onboarding process before they click on the second link, it won't remove any IntroDone object, which will lead to inconsistencies.

[shankari]

ok so going with #12 (comment)

[shankari]

To ensure that the hardcoded defaults in javascript are the same as the ones in native code, we compare them on startup and alert if they are different. Then, when we run the app from the cci branch, the two of them are expected to match.

We can't use this on the real channel because the whole point is that we plan to replace the deleted config with this one. So we will comment it out before checking in.

If we want to change this code before we have a more principled fix, we need to switch to the cci branch, re-enabled the alerts and test.