When running on a tablet, there is no visual differentiation between the list and detail views. Add some sort of dividing line in this view mode.

On tablet/wide screen ratio, split into two pages

@raymondliu2022 can you please add ebook-reader project to the existent build-text-check workflow? so tests and checks are done also on it?

Thanks!

I am working on an app for the Duo and I just finished implementing the window manager approach as used in the TwoDo app. I noticed that in both the sample TwoDo app and my app this approach doesn't seem to account for the region occluded by the hinge. The ReactiveGuide used for the vertical and horizontal folds has visibility GONE and doesn't have a width. In general it behaves very oddly.

What this means:

If you add a simple view (like a textview) at the hinge adjacent edges of a set of containers, you'll see that one of them is occluded by the hinge.

Below, the pink container's end is constrained to the start of the vertical fold. The green container's start is constrained to the end of the vertical fold.

In the layout inspector, you can see that the pink start container is a little bigger than the green end container from stretching into the hinge area (about 33dp or 82.5 raw pixels at the Surface Duo's dpi).

If you call ScreenInfo.getHinge().width(), it returns 84 pixels. This is close enough to the 82.5 raw pixel difference the layout inspector is reporting to not be a coincidence.

Solution & TLDR

ReactiveGuides don't account for an occluding hinge. I expected that the APIs would handle this (and I suspect many other developers will as well). You can fix it by padding the end of the container with whatever ScreenInfo.getHinge().width() returns.

        if(duoScreenProviderInfo.isSurfaceDuoDevice())
        {
            // ReactiveGuides specified in the layout (vert_fold and horiz_fold) don't provide full
            // support for devices with occluding folds like the Duo. We need to manually draw
            // the region that is occluded, otherwise our fragments will extend into that space.

            // Check that you're in dual screen mode, etc. then the call below should never fail.
            val hingeRegion = duoScreenProviderInfo.getHinge()!!

            // For a vertical orientation updatePadding(left, top, right, bottom)
            // startContainer.updatePadding(0, 0, hingeRegion.width(), 0)

            // For a horizontal orientation updatePadding(left, top, right, bottom)
            // endContainer.updatePadding(0, hingeRegion.height(), 0, 0)
        }

When vertical update the startContainer, when horizontal update the endContainer.

I can confirm this works in the emulator and on a real device. I assume this is how the SurfaceDuoLayout libraries may be handling this, but I was not able to get them working for my use case. Either way, I'd like to use the device agnostic APIs as much as possible.

Would you all be willing to update the samples and/or docs with this?

Investigate why video sometimes remains under the hinge in dual-landscape.

Looks like the dual_portrait_split_ctrls_saved() test is failing on the last assertion, will need to investigate why

On Surface Duo dual-portrait mode, the keyboard forces the chat next to the video so both are visible, but on tablet portrait mode the keyboard covers the chat. Need to handle this case for large screen devices.

Surface Duo ✔️

Tablet ❌

The intent for launching the "Files" app fails

The if statement to check if running on a device or emulator also needs to be updated to check if the model contains "Image" because it looks like the emulator name has changed

I think there might be a timing or other issue with PhotoEditor's migration to WindowInfoRepository... fixes itself after rotation, so the layout code is there. Example:

Travel Planner starts with an internet connectivity check which behaves like a splash screen.

Test how it renders with auto-span, and adapt the UI if required.

Test both empty (new install, no data) as well as populated with data states.