iPad app; I'm trying to resize my view when the keyboard appears. It amounts to calling this code at appropriate times:
CGRect adjustedFrame = self.frame;
adjustedFrame.size.height -= keyboardFrame.size.height;
[self setFrame:adjustedFrame];
Using this technique for a view contained in a uisplitview-based app works in all 4 orientations, but I've since discovered that a vanilla uiview-based app does not work.
What happens is that apparently the uisplitview is smart enough to convert the coordinates of its subviews (their frame) such that the origin is in the "viewer's top left" regardless of the orientation. However, a uiview is not able to correctly report these coordinates. Though the origin is reported as (0,0) in all orientations, the view's effective origin is always as if the ipad were upright.
What is weird about this is that the view correctly rotates and draws, but it always originates in the literal device top left. How can I get the view to correctly make its origin the "top left" to the viewer, not the device's fixed top left? What am I missing? Please, for something so trivial I've spent about 6 hours on this already with every brute force technique and research angle I could think of.
This is the original source which doesn't work in this case:
move up UIToolbar
OK, I don't know what the ACTUAL answer is to the original question, but I can say with certainty that one way to resolve the issue is to always ensure that you don't manipulate a viewController's view directly. Always wrap your view inside a container view inside the main "view", then have that container view adjust its position etc as needed. Works exactly as the splitview does, probably because in both cases now the view in question is a subview of the main "view". What a relief!
Related
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.
I have an image slide-show viewer that uses a UIPageViewController to present the images.
The image-view viewer ViewController is pretty simple -- a top-level view containing a UIScrollView containing a UIImageView. On initial image presentation or when the device is rotated the image is aspect-fitted to the view dimensions and centered. It works fine except for a problem which happens on both iOS 7 and iOS 6.
If I am in the middle of panning to change images and two images are on the screen and I then rotate the device it sometimes (maybe always?) messes up the display of one or more images. The previously-centered image appears in the wrong place on the screen and this persists when rotated and zoomed.
The only thing I can find wrong when this happens is that the center property of the UIImageView is not, in fact, the center of the frame. If I change the center property of the UIImageView in viewDidAppear to be the center of the possibly-scaled UIImageView then the images seem to display correctly in all cases.
Does this sound like the effect of some familiar mistake that I'm making?
Edit to respond to the question:
I don't do anything in the willRotate or didRotate methods.
In viewDidLayoutSubviews I aspect-fit the image into the current UIScrollView bounds (which is the full top-level view which is the full screen) and center it. This takes care of both the initial presentation and rotations. I don't see any problems in "normal" rotation situations. The problem occurs only when I rotate with two of the pageViewController's children views both partly onscreen at once. I can "fix" the problem in all cases but surely I'm doing something wrong.
Edit 2
I've discovered another anomaly that occurs less frequently when rotating the device while panning with 2 images onscreen. Best explained by an example:
The page view controller is being used to display one image in a sequence of images from left to right of A B C. Image B is onscreen. During a pan to the left you see part of both images A and B. If the pan to image A is nearly complete, i.e. B is nearly offscreen, and you rotate the device then image B normally ends up onscreen (it never rotates still showing the partial pan), but sometimes image C ends up being displayed -- as though you had panned in the other direction. Anybody else see this kind of behavior?
What are you doing in your UIViewController to prepare for the rotation?
– willRotateToInterfaceOrientation:duration:
And then how do you recover once the rotation has finished?
- didRotateFromInterfaceOrientation
These calls are provided specifically so you have a chance to get ready for a rotation, and then to put everything back to normal once it completes.
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).
I've added a UIPageViewController to my app to act as a manual for the app. When the user pops it up it shows one page in portrait and two in landscape with the spine in the middle. Since I have about 100 pages, there is a sibling view UICollectionView page selector view above it to allow jumping to a page quickly. Both the UIPageViewController and the UICollectionView sit on a backing view that contains them both.
The problem I am having with the UIPageViewController is that when the views are first rotated they seem to constrain themselves to the short dimension of the original layout. So, if it first appears in portrait, then when rotating to landscape the width of the two pages is the same as the old portrait width. Likewise, if it first appears landscape with two pages, rotating to portrait has the correct width, but the height is the height of the initial landscape height. This is consistent on any device.
When I create my content views they are all the size I desire, but for some reason they seem to be transformed by some component of UIPageViewController and I'm not grasping why it is only doing one of the two dimensions and why it is always the "short side" that is the problem.
This is one of those kinds of problem that makes me feel a bit nutty, any ideas on how I might debug it if it isn't some trivial misconfiguration?
I finally found it after a long period of debugging. The critical hint was seeing that the spine is set to the correct mid for the width of the view BEFORE the rotation for portrait to landscape. The solution was to reset the frame of the view to the new size given the orientation in willAnimateRotationToInterfaceOrientation.
I calculate the new size before I call an animation block that uses the duration passed into the method, then inside the block I have:
pageViewController.view.frame = newFrame;
When the page is rotated the view holding the content pages is shifted to the correct size and the spine is place correctly and the content fills the given area. I suppose that I ran into the problem because the complexity of the views required me to take over so many defaults, but this one was left hanging.
I'm adding a video out function to my iPad app and have run into a problem with my UIScrollView. To get the proper view orientation on the external monitor, I've rotated the UIWindow based on the current interface orientation (e.g. - mirroredScreenWindow.transform = CGAffineTransformMakeRotation(- M_PI * 0.5);).
The problem I've run into is that the ScrollView dragging seems to be affected by the UIWindow transform. If the UIWindow is rotated 90 degrees, horizontal drags scroll the view vertically and vice versa. Is there any way to correct this?
I got a response from Apple Dev Support that said essentially, "Doing a transform on UIWindow will confuse the internal objects and should never be done."
Looks like I'll just have to create a modified ViewController that lays out all of my UI elements specifically for the format of the external screen, rather than just transforming the view controller that already works correctly on the iPad screen.
Scroll views seem to maintain their own hidden transform. You can try examining it, and see if there's any difference between when instantiating and adding the scroll view before or after modifying the window transform.