Skip to content
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

Closed
herzbube opened this issue Jan 31, 2021 · 3 comments
Closed

Redesign view/view controller hierarchy for UITypePhone #348

herzbube opened this issue Jan 31, 2021 · 3 comments
Assignees
Milestone

Comments

@herzbube
Copy link
Owner

herzbube commented Jan 31, 2021

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 has MainNavigationController as its single child view controller.
  • MainNavigationController. This is derived from UINavigationController. It pushes PlayRootViewControllerPhone 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.
  • This view controller hierarchy must be able to react to device orientation changes at arbitrary times. It must also be able to show the appropriate view hierarchy when the user launches the app, which for example means launching directly into the Landscape orientation view hierarchy.
  • A feature of the app is that when it launches it makes a best effort to restore the user interface to a similar state that it had when the user sent the app to the background. For UITypePad and UITypePhonePortraitOnly this means activating the same tab in the root UITabBarController that was selected when the app was sent to the background. For UITypePhone this means that MainNavigationController may need to push MainTableViewController onto the navigation stack, possibly even one of the child view controllers of MainTableViewController. If that happens the PlayRootViewControllerPhone 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 and PlayRootViewControllerPhone. 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.

@herzbube herzbube added this to the Soon milestone Jan 31, 2021
@herzbube herzbube self-assigned this Jan 31, 2021
@herzbube
Copy link
Owner Author

Known bug 1: iPhone 12 Pro Max, iOS 14.3

  • Launch into Landscape. The statusbar is not visible by design to get more available vertical space to display the Go board.
  • Rotate the device to Portrait.

Expected: The statusbar becomes visible after the new view hierarchy has been set up.
Actual: The statusbar is not visible.

Notes:

  • No amount of rotation makes it visible. The only way to get a visible statusbar is to launch the app into Portrait.
  • The statusbar is also not visible if one launches into Landscape with the initial view being the main menu.
  • In PlayRootViewControllerPhone::loadView creation of the view hierarchy is initiated asynchronously. If the view hierarchy is created synchronously the statusbar remains invisible only if the initial Landscape view is the main menu, but then the safeAreaLayoutGuide is not honored.

Known bug 2: iPhone 8 Plus, iOS 11.4

  • Launch into Landscape into the main menu. The statusbar is not visible by design to get more available vertical space to display the Go board.
  • Rotate the device to Portrait Upside Down while the main menu is still visible. The statusbar now becomes visible.
  • Go back to the Go board

Expected: The statusbar remains visible.
Actual: The statusbar becomes hidden.

Notes:

  • The statusbar remains hidden even if the main menu is called up again.
  • When the Go board is visible, rotating once to Landscape and then back to Portrait Upside Down makes the statusbar visible.
  • If the initial rotation is into Portrait instead of Portrait Upside Down then the statusbar remains visible when going back to the Go board.
  • When launching in Landscape directly to the Go board, then rotating to Portrait Upside Down the statusbar becomes visible.

@herzbube
Copy link
Owner Author

herzbube commented Feb 1, 2021

A redesign should take #296 into account: In the redesigned view controller hierarchy it should be possible to use UISplitViewController instead of the project's own split view controller implementation.

@herzbube
Copy link
Owner Author

At the moment the most pragmatic solution seems to abandon the current view/view controller hierarchy for UITypePhone and design something entirely new.

This has been achieved with the unification of all UI layouts (#371). Closing this issue.

@herzbube herzbube modified the milestones: Soon, 1.7.0 Sep 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant