Persistence Issue in Widgets

I'm seeing some weird behavior around whether the ObjectStore truly persists data in the case of widgets.

In cases where the widget times-out, I'm seeing the key persisted, so that on opening next opening of the widget, the value is there.

However, when pressing the back-button, in nearly all cases, the key is not persisted, meaning the on next opening of the widget, the data isn't there.

I looked at the `onBack` handler and noticed that I was doing:

function onBack() {

        Ui.popView(Ui.SLIDE_IMMEDIATE);

        return true;

    }

which looks normal to me.

On a whim, I changed the code to

function onBack() {

        return false;

    }

and suddenly persistence works in nearly all cases.

My question is: is this expected behavior? Why is the `onBack` handler affecting persistence at all? At the very least, shouldn't that be more related to `onStop`?

Thoughts here?

travis.vitek over 8 years ago

Yes, but these 'threads' all execute serially. Provided you properly maintain the state of the application in these 'threads', there should be no problem.

rconradharris over 8 years ago

Yep, the 'provided you maintain state' correctly is the rub.

Atomic testing of variables isn't really the issue I generally see, more like callbacks changing views in response to an action, and that being subject to subtle timing issues (if timer callback1 hits first we end up on ViewA, but if callback2 hits, we end up on ViewB. Race-like, but maybe not a true race...

I've settled on a core signaling system (similar to Python's 'blinker' library), which has helped in this regard. 'Threads' can emit signals to declare that something has occurred, and then other threads can subscribe to them. This has made the state-machine a bit easier to understand, so some of these issues have gone away. A few persist, like the one described in the first post on this thread...

rconradharris over 8 years ago

Okay I figured the issue I was running in to; and as expected it was completely my fault :-)

The core problem was that, switchToView() was being call from a MainMenuInputDelegate, which was replacing the view at the Menu-view level, not the previous HomeView-level.

The confusion for me was thinking that switchToView was clearing view stack and then pushing a new view; what it's really doing (AFAICT) is just replacing the top of the stack (which makes complete sense). So the solution was to popView() before performing the switchToView().