supportedOrientations deprecated... what replaced it?

I have an app that requires Landscape mode, but since the newest update, supportedOrientations(LANDSCAPE_ANY) has been deprecated! What do I use instead?

@mistergrav - if you search the forum there have been several discussions on this. Last I heard I think it hinges on the developer checking for dimensions so that you can, not only check orientation, but also identify the device. I think we could use a communal database in a Tab which would enable us to do that then identify orientation.

Remember there is also CurrentOrientation() which tells you which orientation you are in and orientationChanged() which alerts you to the change - check the references under Display.

Hi! Thanks for the reply!

I did find that information, @Bri_G, and perhaps the answer to my question is obvious from what you said, but I’m missing it, so maybe you can help me a bit more specifically…

I can see what orientation the user is holding their device at. And I can run a function to adapt my app when they change orientations. But how do I prevent an orientation change? I want the app to stay Landscape, even when they switch to Portrait.

@mistergrav - I don’t think you can prevent an orientation change. You can print up a large message to return the iPad to its previous orientation against another background. The problem is by the time you anticipate the change the iPad will have recalculated the images etc for the new orientation so the screen will change.

The iPad does have a screen lock but it is an OS call and I’m not sure we can do that from Codea.

An alternative is to capture the screen and to display it in the new orientation as it was in the old orientation and display a message across it. Problem is you would need to freeze the app.

Anyone else managed to deal with this?

How have you managed to capture the orientation change?

@mistergrav @Bri_G is correct that you can’t stop the iPad from being rotated, but you can force the user to keep it in the orientation you want. Here’s an example. Rotate the iPad. The code doesn’t run until you’re in the orientation I want you in.

displayMode(FULLSCREEN)

function setup()
    x,y=300,300
    vx,vy=5,5
    print(WIDTH,HEIGHT)
end

function draw()
    background(255, 111, 0, 255)
    if CurrentOrientation<=LANDSCAPE_LEFT then
        background(0, 240, 255, 255)
        fill(255,0,0)
        text("Rotate the ipad to Landscape Left mode.",WIDTH/2,HEIGHT/2)
        return
    end
    bounce()
end

function bounce()
    fill(0,255,0)
    ellipse(WIDTH/2,HEIGHT-100,300,100)
    fill(0,0,255)
    ellipse(x,y,100)
    x=x+vx
    y=y+vy
    if x<0 or x>WIDTH then
        vx=-vx        
    end
    if y<0 or y>HEIGHT then
        vy=-vy       
    end
end

@dave1707 - thanks for posting that routine. Had a play around with the command myself but couldn’t gett it to work. I struggled with it as I was using a variable to hold the CurrentOrientation and comparing to numeric values 0 fo 3. It looks like you have to use the global identifier for comparisons.

@Bri_G The numeric values should work just like the global identifiers. Run this to see.

function setup()
    print("PORTRAIT",PORTRAIT)
    print("PORTRAIT_UPSIDE_DOWN",PORTRAIT_UPSIDE_DOWN)
    print("LANDSCAPE_LEFT",LANDSCAPE_LEFT)
    print("LANDSCAPE_RIGHT",LANDSCAPE_RIGHT)
end

@mistergrav orientation locking can no longer be supported in Codea because we now support split-view and slide over on iPad (so you can drag another app side-by-side with Codea). If you think about it, it kind of makes sense, what should Codea do if you are using supportedOrientations but your runtime is only running on half the screen?

You can lock your orientation from the control centre using the orientation lock setting. And if you’ve exported your project to Xcode you can tell Xcode you only support full screen mode and a specific set of orientations.

by the way, nowadays the function orientationChanged() also triggers when the overlay is invoked, so it is more a change of screen size. it seems to be called twice on a physical orientation change and four times at startup.

@piinthesky thanks for pointing this out. I think we should replace that API with something like the following:

-- New variables indicating whether the app is in a compact or regular environment
SIZE_CLASS_VERTICAL
SIZE_CLASS_HORIZONTAL

-- Values for them
REGULAR, COMPACT, UNKNOWN

-- Called when WIDTH and HEIGHT have changed
-- (overlay presented, split view invoked, orientation changed)
sizeChanged()

-- Called when either the horizontal or vertical size class has changed
sizeClassChanged()

Thanks everyone!!!

I think the solution that will work most elegantly for me is from @Simeon.
Just limit the orientation switches within Xcode!

I’ll try that out tonight!
You guys rock! Thanks for being so thorough for my first posted question!

@mistergrav no problem, just note that in order to limit orientation in Xcode you need to tick the “Requires Full Screen” setting as well. Apps that don’t require full screen can’t limit their orientation (the same problem Codea itself now has).