I've been searching through lots of posts trying to find a way to change the orientation of the view manually. However I can't seem to find a definitive answer that's not outdated. Please can someone suggest the best way to switch the orientation based on when a user presses a button?
I.e. I need some help filling in the gap...
- (IBAction)buttonPressed:(id)sender
{
// Switch the orientation to ...
}
The Apple guideline doesn't allow that. There's some hack to do that but it's not a good idea to use it.
Your app will run in a real device and there isn't any piece of code that can physically turn the phone. Device orientation is constraint by real world constraint, you can't force your user to turn his phone.
[UIApplication sharedApplication].statusBarOrientation = UIInterfaceOrientationLandscapeLeft
Change the orientation to Landscape or Portrait.
You might have to also apply a transformation to complete the change:
self.view.transform = CGAffineTransformRotate(self.view.transform, -(M_PI / 2.0));
Related
I used MPMoviePlayerViewController to play a video and when back to app, I need app force return portrait
I think the best way to solve this is by using
https://stackoverflow.com/a/13800907/620197
These are callbacks who only gets called when the user autorotates - you can tell the user to rotate the device and then the autorotate callback will be called and will show only the supported orientation.
If you still want force rotation i believe you need to dismiss the controller - try this and please do tell me if it worked out for you:
IOS 6 force device orientation to landscape
I have searched the web for a long time for a force rotation solution that will please me with no success, it almost looks like apple
Doesnt want us to be able to so this.
How to find out if the UIDeviceOrientationFaceUp is landscape FaceUp or Portrait FaceUp?
Can any one tell me?
UIDeviceOrientation will only tell you the orientation of the physical device. You need to use methods that use UIInterfaceOrientation (from UIApplication) to make decisions depending on whether the screen is in portrait and landscape mode.
You can use UIInterfaceOrientationIsLandscape() and UIInterfaceOrientationIsPortrait() with a UIInterfaceOrientation too.
I realise this is an old question now, but looking at the answers everyone is being overly pedantic. In case anyone else stumbles across this:
The answer to your problem is for you to keep a secondary variable which is any of your accepted orientations.
When the device orientation notification comes in, simply look at the incoming orientation and see if its an acceptable one, (portrait/landscape NOT faceup/facedown) then update your secondary variable, and finally trigger a ui/app refresh from there using your secondary variable as the orientation source.
This will have the effect of locking the orientation to the "last known good" orientation.
It's not possible, because the accelerometer can't detect rotation around the z axis. On an iPhone 4, you could perhaps use the gyroscope for this (using CoreMotion), but UIDevice doesn't have an API for this. You would then also have to define what the starting position is, because you can't detect in which direction the user is from the device's point of view.
UIDeviceOrientationFaceUp and UIDeviceOrientationFaceDown are orientations for when the device is laying flat (like on a table). Portrait and Landscape don't make sense in this cases.
There is no way you can find out from orientation . I have found a workaround.
CGRect screenBounds = [[UIScreen mainScreen]bounds];
if(screenBounds.size.width > screenBounds.size.height)
{
// This means FaceUP/Down is in Landscape
}
else
{
// This means FaceUp/Down is in Portrait
}
Hi I have an app and I have two *.pngs for default splash screen:
Default-Landscape.png
Default-Portrait.png
What I want is to animate this default splash screen away when my app is loaded and ready to go.
To achieve this I would normally present an UIImageView with either default-landscape or default-portrait (depending on the device orientation), keep it on screen for a certain time and then animate it away.
My problem is that if I call [[UIDevice currentDevice] orientation] in
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
The answer is always that the device is in portrait orientation even if I clearly have it in landscape. I tried this in simulator and on the device as well and the behaviour is the same.
Does anyone know a fix for this or maybe some other approach?
Thanks!
I had troubles with this and I solved it by making one image 1024x1024 and setting the contentMode of the UIImageView to UIViewContentModeTop, then using left and right margin autoresizing. So long as your portrait and landscape default images are the same layout then this will work fine.
Just to clarify here's what I used:
bgView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:SplashImage]];
bgView.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin;
bgView.contentMode = UIViewContentModeTop;
To get around this problem I installed the splash image view inside of a view controller that allowed both orientations. Even though the device reported the wrong orientation at startup, the view controller seems to get the right one.
You can use UIApplication statusBarOrientation as follows:
if ( UIDeviceOrientationIsLandscape( [[UIApplication sharedApplication] statusBarOrientation] ))
{
// landscape code
}
else
{
// portrait code
}
Maybe you could show a blank view with black background at start time and place [[UIDevice currentDevice] orientation] into this view's viewDidAppear and start your splash screen from there?
Another solution would be to read the accelerometer data and determine the orientation yourself.
To know at start what is the orientation (UIDevice orientation don't work until user have rotate the device) intercept shouldAutorotateToInterfaceOrientation of your View Controller, it is called at start, and you know your device orientation.
There are certainly times when you want to transition from the loading image to something else before the user gets control of your app. Unless your app is really simple, going from loading image to landing page probably won't be sufficient without making the app experience really suck. If you ever develop a large app, you'll definitely want to do that to show progress during setup, loading xibs, etc. If an app takes several seconds to prepare with no feedback, users will hate it. IMO, there's nothing wrong with a nice transition effect either. Almost nobody uses loading screens the way Apple suggests to. I don't know which apps you looked at that showed the "empty UI" type loading screens they suggest. Heck, even Apple doesn't do that except in their sample code and none of my clients would find that acceptable. It's a lame design.
Only the first view added to the window is rotated by the OS. So if you want your splash screen to automatically rotate AND your main view is rotatable then just add it as a child of that view.
Here is my code for fading out the appropriate splash screen image:
// Determine which launch image file
NSString * launchImageName = #"Default.png";
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
if (UIDeviceOrientationIsPortrait([[UIDevice currentDevice] orientation])) {
launchImageName = #"Default-Portrait.png";
} else {
launchImageName = #"Default-Landscape.png";
}
}
// Create a fade out effect
UIImageView* whiteoutView = [[[UIImageView alloc] initWithFrame:self.window.frame] autorelease];
whiteoutView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
whiteoutView.autoresizesSubviews = YES;
whiteoutView.image = [UIImage imageNamed:launchImageName];
[[[self.window subviews] objectAtIndex:0] addSubview:whiteoutView];
[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:0.5];
whiteoutView.alpha = 0.0;
[UIView commitAnimations];
Note: You'll have to update it to support hi-res screens.
It sounds like you're not using the launch image the way Apple recommends in the iOS HIG. It specifically calls out that you should not use it as a splash screen, but rather as a skeleton version of your actual UI. The net effect is that your app appears to be ready just that much faster.
The suggestions that you could draw a splash screen yourself after the app has launching in viewDidAppear or similar also are missing the basic purpose of a launch image. It's not a splash screen. If your app is ready, let the user interact with it, don't waste their time drawing a splash screen.
From my five minute survey of Apple apps and third-party apps, everyone showed a portrait launch image, loaded the portrait version of the UI, and then rotated to landscape. It's been a while since programming on iOS, but I think this mirrors the order of the method calls -- first your app gets launched, then it is told to rotate to a particular orientation.
It might be a nice enhancement request to file with Apple though :)
Is there a way to receive a notification when the iPad gets orientation locked? When the orientation lock is set on or off, it does send a receivedRotate: notification, but I need a way to be able to distinguish normal rotations from lock "rotations".
The problem is I am rotating things in my view when the rotation changes. When the lock is activated, the iPad sends a receivedRotate: with UIInterfaceOrientationPortrait.
I've looked in UIDevice for something like isOrientationLocked, but with no success.
Thanks for any clues on this.
EDIT: When the iPad orientation lock is switched ON, it does send a notification that the rotation changed to portrait for some reason. This causes the elements to rotate since they rotate with any orientation change. This is what I want to prevent.
EDIT2: Yes, the iPad shouldn't send a portrait notification but it does. After this portrait notification the iPad stops sending notifications, which is the way it should be. It's just the initial notification that is in the way.
I cannot use the accelerometer because I still want to be able to use the orientation lock's locking feature. Maybe I would use the accelerometer if I had some way of knowing when the iPad was locked.
EDIT3: receivedRotate: is called with UIInterfaceOrientationPortrait for all orientations.
Apparently it's working now.
I recently jumped back into my old project after installing the latest XCode & iPhone SDK and I no longer receive UIInterfaceOrientationPortrait when the lock is switched on. Haven't changed my code at all so it must be Apple.
Just to be clear, are you only using the rotation notifications to determine your rotations? You are not pulling data from the accelerometer or the like to get your orientation?
One other thing is that the lock is just that, a lock, it should not force you into portrait mode if you are in landscape. It should just keep you in landscape.
So, guessing from what you are doing I might suggest that you really do not want to be using the notifications as the basis of your interface but rather the accelerometer data directly.
As a newly minted iPad owner I might wonder what you are doing since I see the lock as a way to keep the orientation the way I want when my physical orientation is not "normal" like laying on the couch.
I don't need to specify the orientation in this case, I just need to detect it, but I'm having trouble. I have conditional code that should only work in portrait, and if the device is in landscape I need to do something else. Since the deviceOrientation is not necessarily the same as the interfaceOrientation, I can't come up with a way to test for portrait mode.
Most tutorials I find on Google are ways to force landscape or do some sort of rotation. The only thing I want to do is just determine what the orientation is. Here is my code, which is not working:
-(void)viewDidLoad {
[super viewDidLoad];
//currentOrientation is declared as UIInterfaceOrientation currentOrientation
currentOrientation = [[UIApplication sharedApplication] statusBarOrientation];
NSLog(#"%#",currentOrientation); // == NULL
}
I need to determine the value of the interfaceOrientation and program conditionally. Thanks for your help!
Are you aware of the interfaceOrientation property of the UIViewController class?
- (void) viewDidLoad {
[super viewDidLoad];
BOOL isPortrait = UIDeviceOrientationIsPortrait(self.interfaceOrientation);
// now do whatever you need
}
Or are you after [[UIDevice currentDevice] orientation]?
Especially at launch I have found the following to be always accurate for the UI, regardless of what the UIDevice says the orientation is.
[UIApplication sharedApplication].statusBarOrientation
self.interfaceOrientation is unreliable in certain situations. For example, re-arranging tabs in a tabbar application returns incorrect value.
However [UIApplication sharedApplication].statusBarOrientation is always reliable. You saved me a lot of time slycrel. Thank you.
UIInterfaceOrientation orientation = [UIApplication sharedApplication].statusBarOrientation;
if ((orientation == UIInterfaceOrientationLandscapeLeft)
|| (orientation == UIInterfaceOrientationLandscapeRight) )
{
//Landscape
}
else
{
//Portrait
}
I know it is a very old post. How ever I would like to add a point to say it is better to check status bar orientation is better. When ever you call self.interfaceorientation it is calling shouldRotateToOrientation every time. If you have written some code in that method it will be executed. So be cautious!.
UIDeviceOrientation deviceOrientation = [UIDevice currentDevice].orientation;
UIInterfaceOrientation statusBarOrientation = [UIApplication sharedApplication].statusBarOrientation;
if(deviceOrientation == UIDeviceOrientationFaceUp || deviceOrientation == UIDeviceOrientationFaceDown){
if(debug){
NSLog(#"Nothing to change because it is gone to Flat");
}
return;
}
if(deviceOrientation !=statusBarOrientation){
if(debug){
NSLog(#"\nApple has a bug?:\n UIDeviceOrientation : %d, UIInterfaceOrientation: %d",deviceOrientation, statusBarOrientation );
}
}
You won't believe me until you will see at the console the second output!
Some situations - and they exists! - is displayed the last NSLog content!
Than you have to do some workarounds to go on that way, where iOS has no bug, good luck for everyone!
Ah that ... forum moderator maybe will delete this post too, because this doesn't meant to be and answer in his opinion!
I hope it helps for somebody once, it happens on iphone too...(there I got)
Mix it up a little:
BOOL isLandscape = self.view.frame.size.width > self.view.frame.size.height;
(edit) Obviously the previous answers are the correct way to do this and this solution would fail in a situation where view controllers are not full-screen.
-(void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration{</br>
if (UIDeviceOrientationIsLandscape(toInterfaceOrientation)) {</br>
some instructions;
} else {
some instructions;
}
}
This is a snippet from one of my programs.
You could of course use the if statement in your ViewDidLoad notification as well.
I already voted up the answer by #slycrel, but I would like to take the time to write this, and point some things out that seems to be lost in this old question, and lots of other questions on the subject.
It's true that Apple does not really want us to update most of our UI based on orientation changes, but it is still totally possible and sometimes necessary on a case by case scenario, and it will be that way until Apple improves their new(ish) APIs (e.g. viewWillTransitionToFrame: would be way more useful than viewWillTransitionToSize:. Just sayin')
Why I voted up the answer by #slycrel is related to what you need to keep in mind as the logical difference between UIDeviceOrientation and UIInterfaceOrientation.
Tthe status bar is what denotes an application's currently known UIInterfaceOrientation. All this stuff about FaceUp, FaceDown is only related to a device's orientation, not necessarily your application's. An application does not support device orientations anyway. Really, UIDeviceOrientation can be ignored completely if all you have to do is make sure you layout and animate things appropriately in your interface, which is 99% of an application developer's use cases. This is currently achieved with the status bar's UIInterfaceOrientation from #slycrel's answer:
[UIApplication sharedApplication].statusBarOrientation
It should be noted, the readwrite version of this property is deprecated, the readonly version is not.
Take this example:
I have an application that supports ALL interfaces orientations, and a root view controller that supports them as well.
Now, I am presenting a UIViewController that will result in the status bar orientation to become landscape.
Which landscape orientation (left or right) it goes to is based on what is returned by preferredInterfaceOrientationForPresentation for that view controller, what the current device orientation is, and what interface orientations the view controller supports (see next point).
The status bar will go to landscape, regardless of what the current device orientation is, because this view controller only supports landscape based on what is returned by supportedInterfaceOrientations. Lets say we support both landscape left and right with UIInterfaceOrientationMaskLandscape.
I also want to conditionally animate this view controller into position with a rotation transform. This will only be necessary when going from portrait or portrait upside down, to landscape left or landscape right. Otherwise it will be a more simple presentation animation without rotation.
Then, after some time and device use, I dismiss that view controller.
Now I want to conditionally animate this view controller off the screen with another rotation transform. This will only be necessary when going from landscape left or landscape right, to portrait or portrait upside down. Otherwise it will be a more simple dismissal animation without rotation.
At this point, the status bar's orientation will become whatever the system decides is appropriate for the combination of your root view controller's preferred interface orientation and supported interface orientations, as well as the device's current UIDeviceOrientation.
Since the view controller we are going to supports ALL interface orientations, if your device's orientation is FaceUp or FaceDown, you can not reliably guess the next UIInterfaceOrientation based on UIDeviceOrientation, and you do not have to anyway.
So... status bar orientation to the rescue!
The previous example is possible, because the status bar orientation is not updated when a view controller transition is about to start (the system asks a transition delegate for an animator, etc.). Then it is updated when the transition starts animating (e.g. by the time animationTransition: is called). This way you should have a good comparison just using the initial and current values of the status bar's UIInterfaceOrientation.
Even without using view controller transitions, it should still be safe to update views based on the status bar orientation.
Keep in mind, if you are manually updating the status bar, and if you are not using "View controller-based status bar appearance" in your Info.plist, then your application's logic must be aware when the status bar will and did change orientation. You will probably be looking for a couple NSNotification names for these cases, which are:
UIApplicationWillChangeStatusBarOrientationNotification
UIApplicationDidChangeStatusBarOrientationNotification
As well as these UIApplicationDelegate methods:
- (void)application:(UIApplication *)application willChangeStatusBarOrientation:(UIInterfaceOrientation)newStatusBarOrientation duration:(NSTimeInterval)duration;
- (void)application:(UIApplication *)application didChangeStatusBarOrientation:(UIInterfaceOrientation)oldStatusBarOrientation;
- (UIInterfaceOrientationMask)supportedInterfaceOrientationsForWindow:(nullable UIWindow *)window
And this other helpful UIApplication property:
#property(nonatomic,readonly) NSTimeInterval statusBarOrientationAnimationDuration;
As of iOS8, APIs have been deprecated or return unhelpful results such as .FaceUp .FaceDown
This is because Apple does NOT want you to update your UI using orientation, but rather by using size classes, constraints, and proportion (using n% of superview).
Indeed, orientation dependent code might fail to provide good results across the whole range of device and use case (especially multitasking)