Android: update layout after rotation

[mhsmith]

This is the Toga part of the fix described in beeware/briefcase-android-gradle-template#50. It mostly works, but the viewport height is slightly wrong after rotation because the action bar is narrower in landscape orientation. I'll look into this and add another commit.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

The size of the content area was previously calculated by measuring the whole screen and subtracting the height of the status bar and action bar. This PR replaces that with some simpler code which gets the size of the content area directly, which should be much more reliable.

With this approach, onConfigurationChanged was not required after all, but it might still be useful in the future.

The example from beeware/briefcase-android-gradle-template#50 now looks like this:

[freakboy3742]

Confirmed that this works; nice work. However, I'm wondering if it might be worth making some small structural tweaks - in particular:

1. Making the Viewport the layout listener, rather than the Window
2. Making the self.size property a property of the viewport, rather than the window (and possibly renaming to something like "last observed size")

The reason I'm suggesting this is that with this change, we now have effectively 3 "size" properties - window.size, window.get_size(), and window.viewport.width/height... and while it obviously works, it's going to get confusing if we need to make modifications in future unless it's very clear which size is which, and which to use for which purpose.

This suggestion is in the category of "strong opinions, weakly held"; if you disagree, I'd be more than happy to back down to just renaming self.size to something less ambiguous, plus some in-code docstrings elaborating exactly which extents different sizes refer to.

More broadly, this is an area of weakness that is common on most platforms - the connection between "main window", "main window content", "viewport" - and, on some platforms, "the widget that manages main windows content content" (e.g., the macOS ViewController). There are also some inconsistencies around what sizes refer to (e.g., differentiating between the Window's external size, internal content size, and available internal content size after toolbars/menus etc). That isn't a problem we need to solve right now, but I wanted to flag it as an area where there is a "top level" design issue that we need to resolve, as it intersects with some of the window layout/resize problems we've been seeing, and will impact on the design of some widgets (like stack-based navigation widgets).

[codecov]

Codecov Report

Merging #1507 (9abd3c9) into main (eb8f978) will increase coverage by 0.03%.
The diff coverage is n/a.

Impacted Files	Coverage Δ
src/core/tests/widgets/test_switch.py	97.00% <0.00%> (-1.00%)	⬇️
src/core/toga/widgets/switch.py	100.00% <0.00%> (ø)

[mhsmith]

OK, I've changed size to last_size, but I think it's cleaner to keep it in the Window class, so Viewport can remain a low-level class which only accesses a View, not an Activity.

I've also changed get_size to return the same value. This will return the content area size, which is the only size which is of any use on Android, and I've added a comment to make that clear. I'm not sure how the previous code would have behaved in split-screen mode, but I doubt it would have been correct.

[freakboy3742]

👍 That rationale all makes sense to me.