Doc update: testing tombstoning and why it's important

[kmiterror]

I'm shedding some light on tombstoning and why it is important. I'm also demonstrating how to test it on Android.

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

docs update

⤵️ What is the current behavior?

no details about how to test tombstoning

🆕 What is the new behavior (if this is a feature change)?

added description detailing why implementing tombstoning is important and how to test it

💥 Does this PR introduce a breaking change?

no

🐛 Recommendations for testing

no

📝 Links to relevant issues/docs

nothing

🤔 Checklist before submitting

• All projects build
• Follows style guide lines (code style guide)
• Relevant documentation was updated (docs style guide)
• Rebased onto current develop

[dnfadmin]

All CLA requirements met.

[entdark]

Sounds overengineered for testing. Have you tried enabling "Don't keep activities" in Developer options on Android?

[kmiterror]

Sounds overengineered for testing. Have you tried enabling "Don't keep activities" in Developer options on Android?

Yes I have tried it and it doesn't work, meaning ReloadFromBundle is never called (only SaveStateToBundle is called)
With testing approach that I described both of them are called every time, and you can reliably test your app in the situation of state restoring.
On a side note, this might be a bug in MvvmCross because OnSaveInstanceState/OnCreate(bundle) on Activity level works properly with DKA

Also there is another issue with Don't keep activities setting, you look at your app in a way almost no (if any) users sees it.
How to test it properly if you have a stack of activities and you want to test the whole flow?

Issue #3584 is an example of this functionality being not very well understood.
The point of this change is to spread awareness, and give reliable tools to test it.

[entdark]

I see. I use single Activity with multiple Fragments so it worked well in my case and restored all the Fragments correctly.