I have a VC with two imageViews. One takes up the whole screen, the other is actually slightly larger and can be moved around on the screen (Pan Gesture).
When the device changes orientation only the static view changes orientation, or just updates its frame maybe (automatically).
The second Pan UIImageView does not move. Is there a reason for this, or a switch to make this happen somewhere possibly in the storyboard properties of the UIImageView itself? I would like the view to move too.
I understand that an option would be to use the methods that confirm the orientation has completed a change and transform the imageView myself, which is not a problem... but checking I am not missing something that could do this for me automatically first.
Ensure you are using correct AutoResizeMasks on the imageview. Provide your code or storyboard description for a more complete answer.
-Additionally if you are using AutoLayout, you may need to add the appropriate constraints (making it slightly larger than the view may confuse it as to your intention without proper suggestions via constraints).
Related
I came across the project: https://github.com/monoqlo/ExpandingMenu
which adds a button to a view. when the button is added a menu appears. You can find details behind the link.
The problem is that this project doesn't support autolayout and all frames are hard coded. So it doesn't support device orientation changes.
Currently I'm trying to rebuild it with autolayout. How would you do it?
Start with a xib?
Doing everything hard coded?
Do you know some code that could be reused?
Maybe you can try these:
First: check out the code of ExpandingMenu, I know it hard code, that is to say, it use the frame of its superview or [UIScreen mainScreen]'s frame. Make clear when it set its subviews frame.
Second: first may have 2 options
one is setting its subviews frame when it init or added in view: In this case , you have to rewrite it or else, in a word , you can not use it to support device orientation.
one is setting its subviews frame when it calls layoutSubviews: In this case ,it is able to support device orientation.
That is to say: if it does not support device orientation, you can fix it by rewrite it to make it setting in layoutSubviews.
I have a UIViewController that overlays controls on a view presenting what the camera sees. I have a couple of scenarios I would like to allow.
For the iPad, I want to keep the controls on the right most edge of the device, by your right thumb, no matter what the device's rotation. The controls should rotate their content so that their top is always upwards (away from the ground). I don't want the camera view to rotate at all, because that would just be silly – its position & size should stay the same and its contents shouldn't rotate either.
For the iPhones, I want to keep the controls at the bottom of the device's screen, by to the home button, wherever the home button actually is. The controls should rotate their content so that up is always pointing upwards. Again, I don't want the camera view's frame or content to take part in any view rotation animation at all.
I'm using auto-layout.
I'm wondering if there is any way to describe some or all of this in a storyboard. In particular, it'd be great to be able to describe that some view positions need to autorotate (ie, the controls, on iPad), but that other views don't (the camera view).
A question from 2011 indicates this wasn't possible at the time, but perhaps things have moved on since then? If it's not directly supported, can you suggest an approach and are there some sensible places to be hooking in to autorotation to achieve this?
Ok, this isn't quite a complete answer, but I tried a few things which look promising.
First, you can create a separate set of constraints for portrait vs. landscape using the size specifiers: landscape is w Regular, h Any; portrait is w Any, h Regular (I think -- double-check these) This is accessible via the pop-up control in the bottom-center of the storyboard view. By installing different constraints for portrait and landscape, it should be possible to scale the width and height of your controls' container view so it appears to be in a constant position w.r.t. device orientation; in other words, the container doesn't actually counter-rotate -- it scales so it effectively looks like it has counter-rotated.
I got this close to working. It looks like it's doing the correct thing in the storyboard view, but when I actually run it, I get debug messages about conflicting constraints. Not sure how to fix this, but maybe play with the constraint priorities? That sometimes helps.
A second thing I (partially) tried was creating a custom container view class which counter-rotates itself to the correct position based on the device orientation (in the UIDevice class). You implement this by overriding layoutSubviews. For each orientation, you define a transform which puts it in the correct position, and set the view's transform property.
Another possible solution is to override updateConstraints in your view controller and add/remove constraints to position/scale your container to the correct place for each orientation.
For all of these, the idea is that you "force" the container to be in the correct place, but leave the subviews (the actual controls) alone. The controls should do the right thing if their constraints are independent of the specific orientation of the container view.
So, those are some ideas anyway... if they lead you to an actual solution, could you post it? I anticipate having a need for this myself.
Very simple question, but I'm asking as there seems to be a lot of conflicting views and I've been completely unable to find a definitive answer, let alone a modern one.
I use Auto Layout for 99% of my handling of the user changing from portrait to landscape or vice-versa in a UIViewController. Works great. But sometimes, I have to rely on frames still for one reason or another.
How would I best handle this?
You have willAnimateRotationToInterfaceOrientation, willRotateToInterfaceOrientation, the NSNotification methods with checking status bar, and I'm sure there's some others.
If I want to change the position of a view when the user rotates, which method should I be changing the frame in? And is it best to do it with a simple setFrame: or should I be using autoresizing masks?
Since iOS6, you should not be using willRotateToInterfaceOrientation: and didRotateFromInterfaceOrientation:. These are only called on the front-most presented view controller, and will not be called on others. This means if you have a pushed view controller or a presented view controller, all others will not layout correctly.
Instead, you should always use viewWillLayout and viewDidLayout to handle rotation. They are both called inside an animation block, so anything you do which is animatable, will be animated.
For positioning views, you can either set the frames yourself, or use auto-layout constraints and adjust the constraints in viewDidLayout. If you go the auto-layout route, never remove and add constraints. Use the same constraints as much as possible and just adjust their constant values.
When I'm changing the main view frame, I typically adjust the frame in willRotateToInterfaceOrientation if I need to. Then I adjust any subviews by overriding layoutSubviews for my main view.
I don't know that this is a definitive answer, though - I don't think there really is a definitive answer - it depends on how your application is structured.
wilLRotateToInterfaceOrientation and didRotateFromInterfaceOrientation are best used for stuff you need to do before and after rotation, respectively (for example, disabling user interaction before the rotation begins, and reenabling it after). Everything else should be done in layoutSubviews if possible.
Autoresizing masks are useful sometimes, but I usually lay everything out manually to avoid any surprises when things change between iOS releases (as they often do).
So I am new to autolayout in iOS and so I have run into a problem.
My program has 2 imageviews which can be dragged around,pinched, zoomed in and rotated. The user should be able to drag the image views anywhere on the screen. So basically I dont want constraints holding my images in place. I need autolayout to be off for the 2 image views alone (and I know thats not possible).
So whats happening now is when I run the program, the image views can be dragged to anywhere in the screen but when I rotate it or pinch to zoom it, the image moves from its current position and gets placed at the center of the screen, and there it will be zoomed or rotated.( Center contraints are there and they are on lowest priority). I can't seem to delete the constraints either.
Is there anyway I can avoid the constraints just for the image views???If not, what can be the solution to my problem??
override -(void) layoutSubviews in your UIViewController
That should do the trick :)
Take a look at this question. It explains how to disable auto layout for a specific uiview at runtime.
Can I disable autolayout for a specific subview at runtime?
I would appreciate some help before spending any more time on trial and error.
Imagine the following: I'm just starting to create something for the iPad that will look something like a dashboard with a number on dials on it. When rotating the iPad (portrait, landscapeLeft etc) the background should not rotate, the dials position should remain but the inside of the dials should rotate to correct position. So, main view should not rotate, but the subviews (inside of the dials) should. I have done this on the iPhone before by telling the viewController to only be in portrait and then checking UIDeviceOrientation, so I thought this was gonna be easy. But my headache starts when displaying a UIPopoverController. Since I'm not changing the UIInterfaceOrientation, the UIPopoverController will always be in portrait.
Ideal solution would be to have the main view (self.view from the viewController) not observe changes in rotation, but allowing the subviews to do it, but from what I understand that is not possible. Only other solution I could think of is to not animate the change in rotation, and jut move the subviews (dials) into their new position. Animating them (subviews) make the dance all over the place. But I have not found any good solution on how to do that.
Any thoughts anyone?
You are correct in thinking that if the main view does not rotate, having the subviews automatically rotate is not possible.
A workaround that springs to mind is this: What is animated when you rotate the view is a change in the view's transform. I am pretty sure that you could register to receive device orientation changes and when you get the change, animate a transform change to a container view that contains all the subviews you want to rotate.
Edit: just read about you having a popover controller.
As far as the popover is concerned, the way the API manages autorotation is to hide the popover and then show it again at the end of the rotation. It shouldn't be too hard to implement similar behavior.
Another thing that occurs to me is this: Is what you want to not rotate just a background? Would it work to just have two backgrounds, one for portrait and one for landscape that you could switch between? It might not be the most pretty looking, but it would probably be easier than recreating autorotation behavior yourself.