iOS FRNAppearanceAdditions: support for multiple trait collections

[lyzhan7]

Platforms Impacted

• iOS
• macOS
• win32 (Office)
• windows
• android

Description of changes

Second attempt to add support for multiple trait collections (first attempt here, was closed after realizing that native modules are not singletons/one instance is created per scene)

Context: Before this change, the FRNAppearanceAdditions native module assumed that there was only one window/root view at a time, i.e. one trait collection at a time. This assumption doesn't hold for iPad multiwindow scenarios where there can be more than one window at a time, each having different trait collections.

Getting the iPad multiwindow scenario to work can be broken down into two parts:

1. Making sure that the right windows have the right traits when traits change during runtime
   • Since each native module instance corresponds to one iOS scene, and we've made the assumption that there is only one unique trait collection per scene (for the traits we care about), we could keep the instance variables (_horizontalSizeClass _userInterfaceLevel _accessibilityContrastOption) as is. The behavior that was happening before this change was every time the RCTUserInterfaceStyleDidChangeNotification was fired from any RCTRootView, it would get sent to every native module instance, and update every scene. So all that was needed was to add a check in the appearanceChanged event in RCTAppearanceAdditions.m that the view that the notification was fired from corresponded to the right native module instance before passing along the message to the JS side
2. Making sure that the right windows have the right traits on boot
   • Ideally, there would be a way to determine which RCTRootView/window/scene corresponds to the current instance of a native module, so we can initialize the traits before the first time we ask for the any traits from the JS side. However, since we didn't find a way to do this, the next option was to allow the user to pass in the viewTag/rootTag from the JS side when getting any of the traits, and if a viewTag is provided we'll look up the right trait collection from the UIManager and return that. The remaining changes in this PR are to support this.
     • Note: the react native rootTag identifier returns the react tag of the root view. More documentation about rootTag here

State of the different traits we support at this point:

1. Accessibility contrast (normal vs. high)
   1. Already worked, since it is a system wide setting/not specific to a window
2. Appearance size class (compact vs. regular)
   1. Requires support for multiple trait collections - now works after this PR. See before & after videos below
3. User interface level (base vs. elevated)
   1. Requires support for multiple trait collections - now works in this PR.
   2. Also requires support for multiple themes (out of scope for this PR)

Verification

This change was tested using multiple windows in compact/regular mode:

Before (can't have one side be compact mode, other side be regular mode - both windows will render the same way, which means that one side is sometimes incorrect)

multitraits_before.mov

After (each window will render in compact more or regular mode correctly - both at boot, and at runtime)

after.mov

Other scenarios tested:

• slideover view
• opening lots of windows in varying states of compact vs. regular width

Pull request checklist

This PR has considered (when applicable):

• Automated Tests
• Documentation and examples
• Keyboard Accessibility
• Voiceover
• Internationalization and Right-to-left Layouts

[lyzhan7]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lyzhan7]

Update: after the recent changes to this PR, trait collection with iPad multiwindow works as expected for most scenarios. I've tried testing with split window, slideover window, and opening a bunch of windows.

I am still trying to understand why the current state of the PR is getting the right behavior - I thought that after we execute the view lookup on the main queue, we would need to return some kind of callback/fire some event to let the JS side know what the trait value is. Somehow this wasn't necessary; just updating the stored trait value in the native module instance seems to already trigger the JS side to re-render with the right value, with no flashing.

There's one specific scenario that doesn't work as expected, and it's when a new window is created in an existing compact window. Sometimes this works as expected (the new FluentTester window is correctly in compact mode), but sometimes it doesn't (gets rendered in regular mode). Video here:

bug.mov

You can see that the first window we open is in compact mode, but subsequent windows are in regular mode.

Despite this bug, I still think the changes in this PR are a big improvement on what we currently have, so going to mark it as ready for review

[lyzhan7]

Update: after the most recent commit (replacing RCTExecuteOnMainQueue with RCTUnsafeExecuteOnMainQueueSync), this PR works for all the multiwindow scenarios I've tested (including the specific scenario I mentioned in the comment above). Tests include split view, slideover view, opening new windows in split/slideover view, and opening and closing and reopening lots of windows in varying states of compact vs. regular width

For reference, here's a video to show both how 1) compact vs. regular width is being properly detected & applied, and 2) what the current state of dark vs. dark elevated is (which we don't expect to fully work yet)

dark.mov

[lyzhan7]

Update: I refactored the code a bit since the root tag really only needs to be sent to the native module once when it gets initialized. I made an initializeTraitCollection method, and was able to keep the previous horizontalSizeClass/userInterfaceLevel getters as they were before.

This actually also seems to work for all the dark elevated scenarios I've tested (note if a FluentTester window is in dark elevated mode, the background is dark grey, if it's in dark mode, the background is black):

• When there's only one window, FluentTester is in dark mode
• In split view mode, any FluentTester windows are dark elevated
• In slideover mode, and the top window is FluentTester, FluentTester is dark elevated
• In slideover mode, and the bottom window is FluentTester, FluentTester is in dark mode

darkelevated.mov

One additional change I had to make (most recent commit) was add null checks in appearanceAdditions.ios.ts when receiving appearanceChanged events. RCTAppearance also fires an event called appearanceChanged, and for some reason that only started causing issues after the recent changes. I might also be able to just change the event name in FRNAppearanceAdditions

[lyzhan7]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).