autosave not persistant

[smellymoo]

When the app is closed properly, game progress is lost. That seems like a serious problem.

[smellymoo]

is this project still alive? I can probably help you debug the problem, I am a developer (got a 50+ million download app).

[ildar]

don't ask to help. Just help ))) I'm just a user. But I see @ligi appearing from time to time and pulling some PRs.

[ligi]

yea - also need to cut a new release soon

[ildar]

awesome! :-)))

[smellymoo]

just had a quick dig, I think it might be that you only have onpause, and android can skip onpause in certain cases?

[ligi]

OnPause should actually never be skipped:

[smellymoo]

Lol. Oh I remember being your level of optimistic about android, that passed about 5 years ago...

Read the android docs and you will quickly discover that it's all bs, they have fat warnings everywhere saying that they may not happen.

The android life cycle is a great idea, but they didn't implement it probably. Now it's garbage. Basically I have seen most parts skipped, or called twice, or called out of order (when there is more than one activity) 🤦

There are different ways to deal with this, mine was to not trust all the life cycle calls, and feed them into my own generic handler of state, then that keeps track of It's own state and calls my own start or stop functions. This then debounces and allows android to forget to call things.

At the very minimum you need to combine onPause and onStop (and maybe onSaveInstanceState() ) to get anything reliable.

[smellymoo]

I call your photo and raise you...

[smellymoo]

The worst of it is:

onPause() may be called unexpectedly if the activity is partially obscured by a system dialog or if the system needs to reclaim resources.

onResume() may be called unexpectedly if the activity was partially obscured by a system dialog or if the system needed to reclaim resources.

onSaveInstanceState() may not be called if the activity is destroyed unexpectedly, such as during a low-memory situation or a process death.

onStop() may be called unexpectedly if the system needs to reclaim resources, or if the activity is partially obscured by a system dialog.

[ligi]

can you point me to where in the docs it states onPause might not be called?

[smellymoo]

I'm on my phone right now. That is one example. But honestly, if you don't want to fix it, that's on you. Done my part.

[smellymoo]

I am sorry. I was having a bad day and you were looking at the finger pointing rather than what it was pointing at.

Maybe just call it a feature not a bug? when you put your phone down it's non-deterministic if you still have your game when you go back, gives you a little gambling kick... also if you are losing the game, then it's like "oh shit, it cleared itself, oh well, shall we start again?"

[ligi]

Thanks - no I want to fix it - guess I just do the saving after each move then - I think this should solve the problem.

[smellymoo]

that is an easy and robust solution.

Other ideas would be:

• running a background service (pain in the bum).
• funnelling all of the possible ones (onPause, onStop, and onSaveInstanceState) into save, with debounce logic.
• timer based pause (this would be an optimization on top of your solution)
• ???