fix stats orientation change

[MorenoTropical]

Purpose / Description

Describe the problem or feature and motivation

Fixes

• Fixes [BUG]: Changing screen orientation clears stats' search options #16410

Approach

How does this change address the problem?

How Has This Been Tested?

Rotating statistics and it doesnt vanish

Learning (optional, can help others)

Describe the research stage

Links to blog posts, patterns, libraries or addons used to solve this problem

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[criticalAY]

I don't think it is feasible to use it for the SingleFragmentActivity as it is also used for other fragments

[mikehardy]

a reasonable point @criticalAY but doesn't that imply that the other anki backend pages will also have state loss on orientation changes (Previewer, NoteEditor eventually, deck options etc... ?) - may need a more general solution (like an abstract method to save/restore state to enforce they all implement it, or something)

[david-allison]

My (unconfirmed) understanding is that WebViews don't handle state restoration correctly (each rotation counts as a refresh).

I may be mistaken here, and it would be extremely useful to have up-to-date documentation

[lukstbit]

We should avoid using configChanges for activities.

There's even a note in the documentation:

Note: Use this attribute only in special cases to improve application performance and responsiveness.

[BrayanDSO]

We should avoid using configChanges for activities.

I agree that we should, but I don't think that we can.

I haven't found any Android way to restore the webview state after a configuration change. So any elements that can be changed by the user, like Stats's <input> boxes, will be reset after it.

This would only matter if we had a different layout for landscape mode or different screen sizes, but we don't, so IMO that's fine. criticalAY's concern is valid, but we are more in a point that ignoring these config changes is better than not ignoring them.

[mikehardy]

Okay, so this is an important issue already, and will only get more important as we get deeper into exposing anki backend pages through AnkiDroid, and some of the pages have the potential to contain a lot of temporary user data that would feel awful to discard on a screen rotation (think: a carefully crafted card template edit, not saved yet, and you accidentally tilt your phone just enough it gets a rotation signal and poof your edits are gone...)

So, within these constraints:

• overriding config changes is discouraged because then screen rotation is not even possible (for example) and you have to override a list of changes that will grow over time, meaning it's a bit of an "arms race" over time
• webview state restore cannot be trusted to restore completely or correctly
• the data we are saving is unbounded, and card templates (to use my favorite example) are specifically known to be larger than Bundles can handle, requiring a file-backed solution

That means that we are on our own basically. We need a solution where Activity restarts are okay, but we handle save/restore somehow in our own code, and the data goes to a file.

I propose a design where we do override onSaveInstanceState and onRestoreInstanceState, and we do put some information in the passed Bundle signaling whether our AnkiDroid-specific WebView state solution has worked, but we don't store our actual data in the Bundle

I then further propose a design where, unfortunately we have to know the HTML elements (DOM tree access paths perhaps?) we care about preserving, and their type, for each page we care about. Then we somehow (perhaps using JSI to inject javascript that iterates on this list of elements?) grab the values and save them to a file to save, and read the file them set the elements on restore

Or something, anything else that seems reasonable (and perhaps better than that 🤷 )

Until that happens, we need to decide what's worse:

• discarding webview state in our anki backend pages
• disabling configuration changes (temporarily, until a real state save/restore solution appears)

I submit that discarding state is not that bad currently, with our current set of pages, but I'd feel differently if it was card template editor, and I may be missing some page that already has lots of user-created temp data vs just a search string or deck options change...

Thoughts?

[BrayanDSO]

overriding config changes is discouraged because then screen rotation is not even possible

Screen rotations still works and the user will see the screen in landscape. Just the activity isn't recreated after a rotation. Since we don't have a layout-land for any of the affected screens, nor anything on those screens should change with the device rotation, as they are just a toolbar with a webview, the result is the same.

webview state restore cannot be trusted to restore completely or correctly

that only saves WebBackForwardList, so it's useless for our goal

---

If we wanted to use different layouts for that, I think that's easier to just handle the configuration change ourselves than trying to restore the webview.

For now, this PR has the best solution IMO

[criticalAY]

• Feature: Allow changing deck name in statistics screen #15648 Has a separate Activity for Stats screen what if we wait for that so that it can be activity specific?
  or we can create a separate activity for this (might not be the best)

[BrayanDSO]

This happens in screens like CSV import and deck options as well. Creating a separate activity seems like the correct move it was one or two screens, but is basically all of them

[lukstbit]

Looking for alternatives brought nothing so I think we can go with this.