Forum Xamarin.Forms

Add Orientation Options to ContentPages

Summary

Add a setting to ContentPages that allows one to specify the allowable orientations for a given page. While it is a simple matter to specify orientations for an entire app, I am seeing more requests for some pages to be fixed to portrait or landscape only display.

API Changes

To facilitate this request, there are two approaches.

Each orientation is a settable bool with the default being true. You could not allow an orientation to be true though, if it is not allowable in the info.plist when using iOS as the example.

var page = new MyContentPage();
page.Orientations.Portrait = true;
page.Orientations.Landscape = false;

Another option would be to just have one settable array. I find the above to be easier to understand but in the case that others, wiser than myself prefer:

var page = new MyContentPage();
page.Orientations = new Orientations { Orientation.Landscape, Orientation.Portrait };

Intended Use Case

I believe the usage is quite obvious but in my experience, it has been an unfulfilled requirement to have a chart only displayed in landscape, a login the same. I've had a request to do a CarouselView in portrait only mode. Remaining pages in the apps have been to allow user rotation.

There have been numerous posts about this and work-arounds that once worked, are now broken.

Tagged:

Open · Last Updated

Posts

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    shouldn't this be a PlatformSpecifics ?

  • I don't believe so, no. In platform specific coding, there is a method to achieve this result. For iOS as an example, in the AppDelegate, you can place orientation logic in the GetSupportedInterfaceOrientations override. Using Xamarin.Forms, the request to this UI call is never made or it is made at a level that isn't exposed in your code. Basically, Xamarin.Forms cripples the functionality.

    This has been discussed on these forums and SO for at least two years. It is a problem in serious need of a solution.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    I agree this would be an extremely useful addition to XF. The current XF architecture makes it all but impossible to achieve, even with custom renderers.

  • rmarinhormarinho PTMember, Insider, Beta Xamurai

    how do you go about the new platforms like MacOS ? there's no device orientation.

    I think we need a solution like this but more generic

  • @rmarinho said:
    how do you go about the new platforms like MacOS ? there's no device orientation.

    I think we need a solution like this but more generic

    I would think it would be the same as if your config file, like the info.plist in iOS, prohibited it. You are applying a restriction, not granting permission.

    In MacOS, the concept of portrait, landscape and more importantly rotation, don't exist but they are a very real part of iOS.

  • NMackayNMackay GBInsider, University mod
    edited February 2017

    @SteveAndrews said:

    @rmarinho said:
    how do you go about the new platforms like MacOS ? there's no device orientation.

    I think we need a solution like this but more generic

    I would think it would be the same as if your config file, like the info.plist in iOS, prohibited it. You are applying a restriction, not granting permission.

    In MacOS, the concept of portrait, landscape and more importantly rotation, don't exist but they are a very real part of iOS.

    Don't think MacOS is a concern of the majority of us using Forms (I might be wrong), could the support just not be ignored on that Platform?

  • PierceBogganPierceBoggan USForum Administrator, Xamarin Team, Developer Group Leader Xamurai
    edited February 2017

    I agree with @StephaneDelcroix on this; I think this should be a platform-specific. It's the same number of lines to set the orientation with a platform-specific as it would be to just set an Orientation property on the view.

    Applying this as a platform-specific definitely creates a discoverability hit, but I think Xamarin.Forms should try not to introduce areas where behavior is ignored/not enforced on certain platforms and not others.

  • NMackayNMackay GBInsider, University mod

    I'm happy for it to be added as a platform specific feature as we can set that in XAML, would be nice if contentpage also had an OrientationChanged event you could hook into and the event args had the screen layout (e.Layout = Landscape etc), that way you could change you data template on your listview etc, I'm writing a customcontentpage at the moment to do something similar.

  • Perhaps I don't understand the option @PierceBoggan. With platform-specific, would it still work even though it's the Xamarin.Forms layer suppressing the events from being raised? I really don't know how this works under the hood.

  • PaulDiPietroPaulDiPietro USXamarin Team Xamurai

    With a platform specific implementation you could do something like this:

    var page = new ContentPage();
    page.On<Android>().SetSupportedOrientations(SupportedOrientations.PortraitOnly);
    page.On<iOS>().SetSupportedOrientations(SupportedOrientations.LandscapeOnly);
    

    In any scenario where this isn't explicitly set, it defaults to SupportedOrientations.All (this is merely an example naming).

  • Ahh. That's pretty neat.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    I like the idea of finer control over orientation on a page-by-page basis.
    My two cents worth would be that it should follow better/standard naming conventions and be XAML bindable in a straight-forward way like most other properties.
    page.Orientation.Portrait is along the lines of an enum definition not a bool property name.
    page.EnabledOrientations is more of a collection property whose name also implies the state purpose: Enabled.

    var page = new MyContentPage();
    page.Orientations.Portrait = true;
    page.Orientations.Landscape = false;

    When you extend this out to all the orientations: Portrait, PortraitFlipped, Landscape, LandscapeFlipped, SensorLandscape, SensorPortrait... Plus you have to double that because you're going to want control over orientation on a Device.Tablet seperately from Device.Phone... Y'all see where this is going: A bunch of individual properties is unmanageable.

    Another option would be to just have one settable array. I find the above to be easier to understand but in the case that others, wiser than myself prefer:
    var page = new MyContentPage();
    page.Orientations = new Orientations { Orientation.Landscape, Orientation.Portrait };

    Totally agree. But not as a list. The standard for something like this a boolean flag additive approach.

    <ContentPage EnabledOrientations = "{Binding MyAcceptableOrientations}">
    ...
    public DeviceOrientations MyAcceptableOrientations
    {
       get return (DeviceOrientation.Landscape | DeviceOrientation.PortraitFlipped);
    }
    

    I agree with @StephaneDelcroix on this; I think this should be a platform-specific.

    When it comes to orientation do we really care if it is Droid or iOS?
    Don't we really care more about Device.Idiom? If we are on a phone whether it be an iPhone or Galaxy s7 we might allow landscape for a video. But if we are on a Tablet with its larger screen we keep it in portrait because a video still looks good with that larger available screen width, but use a different layout with more information below the video. I don't care if its an Android tablet or a iPad when it comes to orientation: Just the amount of real estate.

    As @NMackay kinda said, an event for Orientation.Changed would be awesome.

  • NMackayNMackay GBInsider, University mod

    @ClintStLaurent

    I've got a working sample of the event concept, I'll post it on the forms forum.

Sign In or Register to comment.