Support multitasking on iPad

[herzbube]

With iOS 9, it is not possible on iPad devices to have three types of multitasking, nicely outlined in the Adopting Multitasking Enhancements on iPad guide in Apple's iOS documentation (the following text is quoted from that guide):

• "Slide Over" provides a user-invoked overlay view on the right side of the screen (or on the left side in a right-to-left language version of iOS) that lets a user pick a secondary app to view and interact with.
• "Split View" displays two side-by-side apps, letting the user view, resize, and interact with both of them.
• "Picture in Picture" (PiP) lets a user play video in a moveable, resizable window that floats over the apps onscreen.

With the release of Little Go that is currently in the App Store, the user cannot select the app for "Slide Over" and "Split View" scenarios (I haven't tested "Picture in Picture"), probably because the released app was not built with the iOS 9 SDK. I have verified this on an iPad Pro. Building the app with the iOS 9.3 SDK (#298) however makes the app eligible for these multitasking scenarios, so the app must properly support these scenarios.

[herzbube]

If the user is floating a PiP window over the Little Go, there's nothing that we can do about it. Also, Little Go is not itself a PiP app. So in the end we don't have to do anything special to support PiP.

The other two scenarios are a different matter, because they result in the app getting a lot less space on the screen than the code currently anticipates. Two quick and simple tests reveal that there is indeed a problem in this regard.

Test 1:

• Launch the app on an iPad that is held in landscape orientation
• Make sure that the "Play" UI area is visible
• Perform a "Slide Over" operation with an arbitrary secondary app
• Drag the handle so that the "Slide Over" becomes a "Split View"
• The board view is now shifted to the left. Its content is drawn over the board position list on the left, and is cut off on the right at the position of the "Split View" drag handle.

Test 2:

• Launch an arbitrary app on an iPad that is held in landscape orientation
• Perform a "Slide Over" operation with Little Go
• A similar effect as in test 1 can be observed, except that the drawing errors are more extreme beause the app gets even less screen space than in test 1

[herzbube]

The changes that iPad multitasking introduces and that Little Go must adapt to are best expressed by the following quotes from the "Getting Oriented" section of the "Adopting Multitasking Enhancements on iPad" guide (see the initial issue text for the URL):

In iOS 9, it’s no longer appropriate to think in terms of device idiom or interface orientation. Your app can find itself in either a compact or regular horizontal size class on iPad, with size changes independent of interface orientation. Instead, employ trait collections and size classes (see UITraitCollection Class Reference), and adopt the UIContentContainer and UITraitEnvironment protocols, as described in Slide Over and Split View Quick Start.

and

Likewise, in iOS 9 it’s no longer appropriate to employ the screen’s bounds to gauge your app’s visible area. Instead, obtain the value of your app’s window’s bounds property (which the UIWindow class inherits from the UIView class.)

[herzbube]

The app must provide layouts for the following scenarios:

• 1/3 of the screen in landscape, when displayed as secondary app. The horizontal size class is compact.
• 1/2 of the screen in landscape, when displayed as primary or secondary app. The horizontal size class is regular on iPad Pro and compact on all other iPads.
• 2/3 of the screen in landscape, when displayed as primary app. The horizontal size class is regular.
• 2/5 of the screen in portrait, when displayed as secondary app. The horizontal size class is compact.
• 3/5 of the screen in landscape, when displayed as primary app. The horizontal size class is compact.

Cf. section "Slide Over and Split View Quick Start" in the "Adopting Multitasking Enhancements on iPad" guide.

[herzbube]

Analysis: Where do we use UIScreen bounds?

• ApplicationDelegate uses the screen bounds to provide an initial frame for the app's main window. This should be OK, the window is resized later on.
• LayoutManager uses the screen bounds to determine whether it is running on an iPhone 6+, but does nothing else with the size. This should be OK.
• TableViewSliderCell
  • Uses the screen bounds to provide an initial frame for its labels and sliders. This should be OK, these UI elements are resized later on by Auto Layout.
  • Uses the screen bounds in the class method rowHeightInTableView to render an off-screen cell. This is problematic because the calculation is based on more screen estate than is actually available. Also, the calculation is done only once.
• The UIColorAdditions class method woodenBackgroundColor uses the screen bounds to calculate the size of the wooden background. This is wasteful, but not a bug per se.