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?

Seems like the issue was that we were deciding whether to inflate the single vs dual screen layout (in ActivityFragment) based on information from window manager, but the window manager info wasn't always updated before inflating the views!

@conceptdev @CesarValiente

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:

📃 Description

Updates the drag and drop test in PhotoEditor so it works on both device and emulator

🤔 Motivation and Context

Fixes #34 by using targetContext instead of context, making sure the app has permission to query the Files app, and using test kit device coordinates instead of hardcoded values

🧪 How Has This Been Tested?

Tested on Surface Duo, Surface Duo 2, and Surface Duo 2 emulator

Note: test will not pass on Surface Duo 1 emulator due to known smallestWidthDp issue (emulator dimensions are incorrect, so the device model will not be recognized)

⚒️ Does the PR contain new tests or refactored old ones?

Refactors the old drag & drop test

📷 Screenshots (if appropriate)

📦 Types of changes

• [ ] New feature (non-breaking change which adds functionality)
• [ ] Enhancement to a current functionality
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] Bug fix (non-breaking change which fixes #34).

✅ Checklist

• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] This PR contains new tests that cover the new code.
• [ ] This PR refactor previous tests to cover the new code.
• [ ] This PR is part of a set of PRs that build a bigger feature. If so, please, add here links to previously merged or open PRs.

Update samples with UI tests to use test kit spanning methods instead of local helper methods

Note: some of the UI tests in FoldingVideo and PhotoEditor fail but for reasons other than this update - I can create issues for these so we can fix them in the future

Update samples to Jetpack Window Manager rc01:

• [x] eBookReader ^
• [x] FoldingVideo
• [x] FoldingVideoPlusChat
• [x] PhotoEditor
• [x] SourceEditor
• [x] TravelPlanner ^
• [x] TwoDo ^
• [x] TwoNote

^ these samples were also updated with SlidingPaneLayout rc01

Update samples to Jetpack Window Manager beta04:

• [ ] eBookReader ^
• [x] FoldingVideo
• [x] FoldingVideoPlusChat
• [x] PhotoEditor
• [x] SourceEditor
• [ ] TravelPlanner ^
• [ ] TwoDo ^
• [x] TwoNote

^ three samples use slidingpanelayout:1.2.0-beta01 which is still dependent on an earlier version of JWM (1.0.0-beta02) and cannot be updated until a new SlidingPaneLayout is available that's based on JWM beta04.

@raymondliu2022 can you please add ebook-reader project to the existent build-text-check workflow? so tests and checks are done also on it? https://github.com/microsoft/surface-duo-window-manager-samples/blob/c9d47df61282384420ee33716e34139fcae20356/.github/workflows/build_test_check.yml#L24

Thanks!

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

and slidingpanelayout-1.2.0 stable release

Update samples to Jetpack Window Manager 1.0.0:

• [x] eBookReader ^
• [x] FoldingVideo
• [ ] FoldingVideoPlusChat
• [ ] PhotoEditor
• [x] SourceEditor
• [ ] TravelPlanner ^
• [x] TwoDo ^
• [ ] TwoNote

^ these samples were also updated with SlidingPaneLayout to 1.2.0

Adds auto-span compatible splash screens to the following samples:

• [x] PhotoEditor
• [x] SourceEditor
• [x] TwoNote
• [x] eBook
• [x] FoldingVideo
• [x] FoldingVideoPlusChat

Two samples do NOT use the default splash screen set-up:

• TwoDo
• TravelPlanner

These samples already have their own splash-like behavior (yet to be tested with auto-span).

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.

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 ❌