Open Radar

 
Summary:
Instead of just having the preferredFocusedView variable, it would be useful if we had a nextFocusedView method that passed in additional information, the UIFocusUpdateContext object, as well as the current focused view (for cases where a test can be performed with a view that's not actually the currently focused view), and a vector (perhaps velocity) of the direction to test with. This would allow much better control over the current system that can only use four directions, up/down/left and right. For example, see attached screenshot, I have a game that uses hexagons for a game board (pretty common scenario). But it's proving very difficult for the user to focus on the tile they need to select.

If an API like that is too much to ask, perhaps we could supply a 'focusFrame' to be used by the focus engine. The hex board in the supplied screenshot for example, is built with a bunch of overlapping views (each hex is a view). This confuses the focus engine since it uses the uncovered portion of the view. If we could supply the frame to use for focus engine calculations, we could use a smaller rect in the center of each tile and not have overlapping frames. I tried doing this using UIFocusGuides in the center, but because each view needs to return true for canBecomeFocused() when the focus guide points to it or it's ignored, the focus guides never get used because they're smaller than the overlapping view.

A third option, would be to add a Bool 'includeInFocusEngineCalculations' (use a better name of course), that would let us exclude a view from being automatically used by the focus engine, but could still become focused if expressly pointed at by a focus guide for example.

Steps to Reproduce:
N/A

Expected Results:
N/A

Actual Results:
N/A

Version:
tvOS 9.0 beta 3 (13T5379f)

Notes:


Configuration:
Apple TV Dev Kit

Attachments:
http://cl.ly/image/3S3B3l252X0k