-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesign view/view controller hierarchy for UITypePhone #348
Comments
Known bug 1: iPhone 12 Pro Max, iOS 14.3
Expected: The statusbar becomes visible after the new view hierarchy has been set up. Notes:
Known bug 2: iPhone 8 Plus, iOS 11.4
Expected: The statusbar remains visible. Notes:
|
A redesign should take #296 into account: In the redesigned view controller hierarchy it should be possible to use |
This has been achieved with the unification of all UI layouts (#371). Closing this issue. |
The status quo for
UITypePhone
is this:WindowRootViewController
is at the top of the hierarchy. This is the root view controller of the app's window. It is a container view controller that hasMainNavigationController
as its single child view controller.MainNavigationController
. This is derived fromUINavigationController
. It pushesPlayRootViewControllerPhone
onto the navigation stack where it remains for the entire duration of the app's runtime. When the user taps certain buttons other view controllers are pushed onto the navigation stack (MainTableViewController
when the main menu button is tapped,GameInfoViewController
when the game info button is tapped).PlayRootViewControllerPhone
. This displays the play area with the Go board. This view controller completely tears down its view hierarchy whenever the device orientation changes from Portrait to Landscape, or vice versa, and then builds the view hierarchy up again to match the new device orientation.UITypePad
andUITypePhonePortraitOnly
this means activating the same tab in the rootUITabBarController
that was selected when the app was sent to the background. ForUITypePhone
this means thatMainNavigationController
may need to pushMainTableViewController
onto the navigation stack, possibly even one of the child view controllers ofMainTableViewController
. If that happens thePlayRootViewControllerPhone
view is not loaded at application launch, loading is instead deferred until the user navigates back to the Go board.PlayRootViewControllerPhone
must be able to handle device orientation changes while its view is not yet loaded.The consequence of this design are non-trivial view controller implementations for
MainNavigationController
andPlayRootViewControllerPhone
. The logical requirements are not that difficult to implement, the main issue is that the view controllers must also be able to fulfill these requirements under different iOS versions. At some point in the past a working solution was achieved with great effort (for iOS 9.3 SDK?), but the upgrade to iOS 14.3 SDK again broke some things (see next comment on this issue) which I have been unable to fix with a sensible amount of effort.At the moment the most pragmatic solution seems to abandon the current view/view controller hierarchy for
UITypePhone
and design something entirely new. The assumption is that the current view/view controller hierarchy is somehow unusual enough to break certain expectations built into the iOS layout engine.The text was updated successfully, but these errors were encountered: