Is there a way to determine whether the viewport is in a portrait or landscape orientation?
I know there is a common request for viewport dimensions to be exposed, is there a chance that this will happen?
My specific use for this would be to have dashboards optimised for their respective orientations. But I can think of many other cases where this could be useful.
This should really be accomplished by using reactive containers. This allows you to make the View once, but allow it to handle layout according to viewport dimensions on its own.
Creating a View which appears different based on portrait vs landscape sounds like you should use a Flex Container with wrapping enabled, or possibly a Breakpoint Container.
@cmallonee in most circumstances I would agree; however, when it comes to dashboards things get complicated. Although you can get the widgets and the dashboard to be responsive, itās difficult to get the widget position in the dashboard to be responsive.
An example case would be lots of small widgets all in a row on a landscape screen. When this transitions to portrait these become very small. Ideally they would move onto the next row in dashboard (which Iām sure is possible via scripting, but in my head, seems very difficult).
Possible solutions to the example are:
Reduce the grid size of the dashboard so that the effect is less pronounced.
a. In this case I do not want to restrict the end user to this extent.
Instead of having lots of individual widgets, create fewer complex widgets that are more responsive.
a. Again, this restricts the end userās capabilities. If they want lots of widgets laid out exactly where they want them, then I would like to provide that functionality.
Create two dashboards, each optimised for portrait/landscape layout, and use a breakpoint container to decide which to show.
a. This is my preferred solution currently; however, the breakpoint doesnāt have reference to the view height, so it is not a true indication of whether the screen is in portrait/landscape. If dimensions were exposed to allow a decision to be made on the orientation, this solution would be perfect.
In this example it may actually be better to have access to the container dimensions rather than the viewport. This seems like the simplest solution for me, but I understand it could cause a few headaches to expose these in the properties. Another option could be to have an āorientationā property in the session props that we can use, if this is easier to implement.
We have a free perspective component that may help you with this.
https://modules.bijc.co.uk
@jonathan.taylor thank you, I will give it a try.
We do have an open feature request to provide insight into the orientation of the page, with the goal being to provide a way to also ālockā the orientation if necessary on a per-page basis. Iāll make a note that an additional request has been made.
@cmallonee thank you.
Not to uncover an old thread, but I would like to have this feature be implemented as well (if itās not already). Mostly because with iOS, for some reason when I rotate to landscape, it tends to zoom in on the page. I donāt really need/want a user to rotate anyway, so might as well lock it to avoid any confusion/frustration. Thanks!
Hi @Joe_Kelly, viewport dimensions are available from v8.1.7 (I think) if you need to determine orientation. Iām sure I saw a feature request/post for locking screen orientation on the Perspective app, but I canāt seem to find it 
Hey Matthew, I knew about the dimensions. What I really want is to see if thereās a way to force a certain orientation (or lock the current orientation) for the viewport. As I said, itās just because for some reason, iOS likes to zoom in on the viewport when the orientation changes. For now, Iāll just lock the orientation on the device itself. Thanks!
Any updates about this feature?
As @Joe_Kelly mentioned, some apps don't need to let users to rotate the screen, especially cellphone's apps.
No, the feature has not begun development.
I started a feature request post for this just now:
I agree that this would be useful and ive seen a few others say the same.
We already have an open feature request, but okay.
I tried looking for it first but didn't find it
We already have an open internal feature request, but okay.
... And i was supposed to know this how?
We linked the internal ticket in the title of the thread. The [IGN-3367] is an internal ticket reference. Also:
Again, I was supposed to know this how? As i said, i tried looking for it on the feature request and couldn't find it, but okay.