BobDickinson
commented
10 years ago As of some recent changes, all platforms now support rotation. They will resize any toolbars/statusbars, etc, and resize the top level container on rotation. Verified that samples work as expected (particularly the "fill" sample).
The way this used to work was based on an assumption about a preference for the "natural" orientation of the device (portrait for phones, landscape for tablets). I think it may be worth preserving the natural/primary orientation as one orientation choice when we let the app/page choose an orientation (supported orientations: natural, horizontal, vertical, both).
I think we have consensus that the app should have the option of being notified when orientation (or possibly, size) changes, with the option that it can take some more sophisticated action, including modifying the view template or providing a new view template.
The cases may be more complex than just horizontal vs. vertical orientation to determine the layout (there maybe be layout consideration given to the physical screen size, aspect ratio, whatever, in addition to orientation). For example, maybe when going to landscape orientation, the developer wants to do a list-detail or side-by-side view, but only if the screen is physically large enough for that to make sense.
Firstly, the current client layout code should try to do something sane when the orientation changes, without requiring the developer to do anything special with respect to orientation. This would include resizing the top level container if necessary, resizing any page-level controls (specifically, the top and/or bottom toolbars on iOS). Not sure who else is being stupid.
Secondly, there should be some mechanism for the developer to specify different layouts for different orientations and have that work if the orientation changes while viewing a page (we have a layout filter for orientation now, but that just will apply the orientation reported by the client when initially loading the page to the page layout).
One approach could be to get the page using the current orientation, applying any orientation filters. On an orientation change, the client could ask for the template again, and assuming there were any orientation filters and those filters produce any change, we could send the new template. We could, alternatively, determine whether there will be two orientation templates at the time the page is requested and send them both to the client at that time. In either case the client will have to re-render the page and populate the new controls from the existing client view model.
There are going to be similar issues with things like a snapped layout on Windows (and presumably similar tricks on Android tabs), where the display size actually changes. Not sure what, if anything, to do about that.