[iOS] adds support for column-based SplitViews on iOS 14+

[jpdriver]

UISplitViewController was extensively rewritten as part of iOS 14.

It now supports either a two or three multi-column layout in place of the classic master-detail style.

This PR extends SplitView to additionally support the updated implementation.

I have tried to ensure that there will be no breaking changes, however this PR deprecates the master and detail Layout properties.

Apps using these will continue to function in exactly the same way (and continue using the classic interface style) but will see JS warnings about adopting the corresponding new properties primary and secondary

---

Examples

"Classic" Behaviour

• no style set
• still works the same as it does today, only using primary + secondary instead of master + detail

Navigation.setRoot({
  root: {
    splitView: {
      id: 'SPLIT_VIEW',
      primary: {
        component: {
          id: 'PRIMARY_SCREEN',
          name: 'PrimaryScreen',
        },
      },
      secondary: {
        component: {
          id: 'SECONDARY_SCREEN',
          name: 'SecondaryScreen',
        },
      },
    },
  },
})

Three Columns, twoBesideSecondary

• sets tripleColumn style
• uses twoBesideSecondary displayMode to show all columns by default
• primary column can be shown / hidden with toggle (provided automatically by OS)

Navigation.setRoot({
  root: {
    splitView: {
      id: 'SPLIT_VIEW',
      primary: {
        component: {
          id: 'PRIMARY_SCREEN',
          name: 'PrimaryScreen',
          options: {
            topBar: {
              title: {
                text: 'Primary',
              },
            },
          },
        },
      },
      supplementary: {
        component: {
          id: 'SUPPPLEMENTARY_SCREEN',
          name: 'SupplementaryScreen',
          options: {
            topBar: {
              title: {
                text: 'Supplementary',
              },
            },
          },
        },
      },
      secondary: {
        component: {
          id: 'SECONDARY_SCREEN',
          name: 'SecondaryScreen',
          options: {
            topBar: {
              title: {
                text: 'Secondary',
              },
            },
          },
        },
      },
      options: {
        splitView: {
          displayMode: 'twoBesideSecondary',
          style: 'tripleColumn'
        },
      },
    },
  },
}),

Three Columns, secondaryOnly

• primary and supplementary columns are hidden by default

      options: {
        splitView: {
          displayMode: 'secondaryOnly',
          style: 'tripleColumn'
        },
      },

Playground (before update)

• shows Deprecation warning if still using master + detail but continues to work the same

Playground (after update)

• updated to primary + secondary
• sets doubleColumn style

[danilobuerger]

Hi @jpdriver 👋 Thanks for this awesome PR! I didn't do a code review yet, but a couple of points:

• It would be awesome if you could add a new screen to the playground app to showcase all the features of this.

• We don't want to have two ways to define a split view. So either we keep master & detail and add a supplementary, or we deprecate master & detail in js land (see f.x. https://github.com/wix/react-native-navigation/blob/master/lib/src/commands/OptionsProcessor.ts#L142 for the recent search bar deprecations and how to map them to the new names), add primary, secondary and supplementary and use them exclusively on the native side.

• For iOS < 14 we can then just ignore supplementary and for iOS 14 we can either add a options.splitView.style param next to the options.splitView.displayMode config options or just don't support the classic mode (is there any point in keeping it, does it look so different?).

Btw, we are also all available on Discord if there is any in depth discussion to be had.

[jpdriver]

hey @danilobuerger 👋🏻

• there's already a Playground screen for the Master-Detail version (the Cocktail list). Would you like this new screen to replace that, or do it as a separate addition specifically showing 3x columns?

• i think for clarity we shouldn't mix the naming conventions (i.e. we shouldn't have master, supplementary, detail). i can re-work this so that behind the scenes everything is treated as primary, supplementary, and secondary.

• i'm don't know how many RNN apps are actually using the existing Master-Detail SplitView; but in the interest of flexibility it might be nice to keep some mechanism to continue using either one as required.. i love the idea of going with options.splitView.style so I'll update to use that instead

[danilobuerger]

• there's already a Playground screen for the Master-Detail version (the Cocktail list). Would you like this new screen to replace that, or do it as a separate addition specifically showing 3x columns?

Just some additions to showcase the new features (like supplementary, display mode and style)

• i think for clarity we shouldn't mix the naming conventions (i.e. we shouldn't have master, supplementary, detail). i can re-work this so that behind the scenes everything is treated as primary, supplementary, and secondary.

Sure go with the new naming convention and lets deprecate the old one. See the example for the search bar that I mentioned above on how to convert the values in js and throw a deprecation warning.

• i'm don't know how many RNN apps are actually using the existing Master-Detail SplitView; but in the interest of flexibility it might be nice to keep some mechanism to continue using either one as required.. i love the idea of going with options.splitView.style so I'll update to use that instead

Awesome! The following logic would be nice:

• If no style is set in native, default to the new style (either two or three columns depending on which are set)
• In the options processor for the deprecation (js): ** if the user has set master / detail, also add the style prop (if not already set) and default to classic ** if the user has set primary / secondary do nothing

[lprhodes]

I'd love to see this updated and merged, what ended up happening with it @danilobuerger?

[danilobuerger]

@lprhodes I have no idea, I am not a maintainer of this repo :)

[jpdriver]

for what it's worth, i'm happy to dust this PR off and keep it ready to go -- but i completely understand that it likely can't come in until the next major..