Android: Client area of OptionContainer goes under the tab bar

[Juan-de-Salgado]

Hi,
In Android, a flex'ed widget (in my case, a Canvas) inside an OptionContainer expands under the Tab Bar as well, appearing "under" the tabs (at least according to the "width" and "height" keyword parameters passed to the on_resize handler). This does not happen with "briefcase dev" (Linux GTK in my case), where the OptionContainer appears to have a client area that excludes the tabs, as it should.
Of course, it may be just a coordinate issue, where the width/height are passed incorrectly to the resize handler; in which case I'd need the size of the tab bar to compensate.
Any ideas / fixes / workarounds? Thanks in advance.
I'm on Toga 0.5.3.

P.S.: I did a small experiment, and replaced the Canvas with an ImageView(..., flex=1); and the image occupies only the expected client area, so it does not seem to be a layout issue. Just an issue of the coordinates passed to Canvas.on_resize, which are including the tab area.

[freakboy3742]

We may need a little more detail to clarify what you're doing, and how you're responding to it.

The content area of an OptionContainer should be the "viewable" area, as you've described it on Linux. If that's not what you're seeing on Android, then that's possibly a bug; we'd need a reproduction case to be certain. Recent releases of mobile platforms have had some interesting relationships with transparency and controls overlapping content areas, so it's possible we've missed something.

However, to clarify - on_resize is only available on a Window, not the widget - so the size you're getting from on_resize will be the size of the OptionContainer widget, not the size of the content area. I'm not sure if that's what you were reporting, but I wanted to clarify just in case your use case was based on applying the on_resize size to your content.

[Juan-de-Salgado]

Thanks for the reply! I'm a bit confused, though, because toga.Canvas definitely has a writable property on_resize, which can have a handler assigned to it. It does differ from the documentation, in that the docs say the parameters are (width, height, **kwargs); instead, if I define it as (*args, **kwargs), I receive the Canvas in args, and {"width":www, "height":hhh} in kwargs.

I merely wish to know what are the maximum coordinates I can paint on, without exceeding the client area of the container.

P.S.: Give me some moments and, to make your life easier, I'll make a minimum project that replicates the issue.

[freakboy3742]

My apologies - I overlooked the (very relevant) detail that the widget in question was a Canvas.

If you're getting misleading width and height results from a canvas on_resize call, that definitely sounds like to be a bug. A reproduction case will definitely help, though.

[Juan-de-Salgado]

All right; first of all, thanks for your saintly patience.

This may be my fault. The minimal app has two buttons, which replace part of the layout. The first time, the Canvas "looks wrong"; on subsequent times (or when switching Landscape/Portrait orientation) they look OK. I may be missing some step to force a layout recalculation when I replace a widget.

canvastest.zip

P.S.: Runs OK with "briefcase dev" on Linux. Ran on Android with "briefcase build android" followed by "briefcase run android --update".

[freakboy3742]

Thanks for that example. The behavior you're seeing is a manifestation of a known issue with the way we're currently implementing OptionContainer on iOS and Android; the issue is tracked as #4297.

There's extensive background detail in the discussions on #4059 and #4271 - but the core of the problem is that the widget we're currently using for OptionContainer on iOS and Android must be a top level widget - that is, you can use an OptionContainer as main_window.content, but nowhere else.

This isn't the case on desktop platforms - it's only a problem for mobile. The fix proposed in #4297 is to change the widget we're using for OptionContainer; we're then going to introduce a new concept called a "Scaffold" to encompass the idea of navigation elements that need to exist at the top level (see #4299 for the OptionScaffold proposal).

In the meantime, this is something we should probably call out in the docs; the Notes section for OptionContainer should highlight the known issues with using OptionContainer as non-root content.

[mhsmith]

There's extensive background detail in the discussions on #4059 and #4271 - but the core of the problem is that the widget we're currently using for OptionContainer on iOS and Android must be a top level widget

Where in those discussions does it explain this bug? I can see that putting it at the top level was recommended by the platforms' UI guidelines, but I wasn't aware that it was an actual technical requirement.

[freakboy3742]

On reflection, it's probably not immediately apparent based solely on that discussion - but it falls out as a consequence once you play with the pieces.

Consider a layout where the root content is a horizontal box with 2 children - both of which are option containers. This isn't a problem for desktop platforms - you get a 50/50 split of content, with 2 separate sets of tabs. However, the rendering of tabs on both iOS and Android results in the tabs at the bottom of the window, with the tabs filling the whole window (essentially as part of window-level chrome)... so how should multiple sets of tabs be rendered?

I've just added #4369 to document this in the short term; Using the "secondary" rendering form for mobile OptionContainer (see #4297) would relax this requirement.

[mhsmith]

the rendering of tabs on both iOS and Android results in the tabs at the bottom of the window, with the tabs filling the whole window (essentially as part of window-level chrome)... so how should multiple sets of tabs be rendered?

At least on Android, the tabs aren't part of window-level chrome, they're just a BottomNavigationView which you can put anywhere you want. There's nothing that forces it to fill the whole window, it'll take up whatever space is determined by the containing layout.

So if you put two OptionContainers side by side, then their tabs will appear side by side. This is potentially a bad UI design even on desktop platforms, because it might look like a single row of tabs, but that's a problem with the app, not with Toga itself. And I don't see how it would make any difference whether the tabs are at the bottom or the top.

[freakboy3742]

Thanks for clarifying the rendering relationship in Android - I evidently misunderstood how that was constructed. The constraint I described evidently only exists on iOS.

I agree that having 2 tab groups side-by-side is going to be a confusing UI, regardless of platform. However, on most platforms, there's some sort of "grouping" in the tabs that makes it's clear that there's 2 groups of tabs, not one long list of tabs with two items selected and no clear distinction where each "group" ends. For example, on iOS, UISegmentedControl (which is what "secondary" tabs should be rendered as) looks like:

macOS also uses a different background color for the "contained" content:

If you have two of those side by side, it's clear you have 2 independently selectable groups.

Ironically, it looks like this isn't the case for Android secondary tabs, so the case is a little harder to make; but based on my read of the Material style guide, the intention is that the intention is that "bottom tabs" are "whole of window" tabs, whereas secondary tabs can be used anywhere in-content. That matches up with the ultimate goal of OptionContainer vs OptionScaffold described by #4297 and #4299.

[Juan-de-Salgado]

Thanks for the info, and for your work!