UIPickerView as inputView gets messed up on orientation change - iphone

I'm using a standard UIPicker view as an inputView for a textField in an iPhone application. When the view is loaded in either landscape or portrait, the picker is sized the same as the appropriate keyboard. However, when you rotate the device once inside the view the picker doesn't resize it's height properly, like it does with it's width. I have UIViewAutoresizingFlexibleWidth set. When I tried setting UIViewAutoresizingFlexibleHeight as well the picker gets messed up (choppy graphics, component cuts off) on rotation, though the height is correct! Has anyone figured this out?

I found that if you are working with iOS 7 simply add:
pickerView.autoresizingMask = UIViewAutoresizingFlexibleHeight;
This solved the problem for me. The transition isn't very choppy, looks like it "should" look.

I found a band-aid:
In didRotateFromInterfaceOrientation: in your hosting viewController, call setNeedsLayout on that picker view. The weird layout glitches are visible during the rotate but clean up at the end.

Related

UIView autoResizing works sometimes

Currently, here's what's happening. If I'm in portrait mode, and I present a new modalViewController, and then rotate to landscape, autoResizing works perfectly and everything looks great. However, if I'm in landscape, and I present a new modalViewController, autoResizing does not work and everything looks funky. Can anyone think of any possible ideas as to why this could be happening? I'm desperate I've tried everything.
Maybe a way to fix this would be to figure out what code gets called by the system when I'm in portrait and I go landscape. Maybe I can call that exact code if my modalView is presented in landscape. I've tried layoutIfNeeded and setNeedsDisplay but they don't do anything. I've also tried setting the contentMode to redraw-doesn't help.
I have this in my viewDidLoad for the modal view
if(UIInterfaceOrientationIsLandscape(self.interfaceOrientation))
{
NSLog(#"is landscape, width:%f", self.view.frame.size.width);
}
and this outputs 320, even though I'm in landscape, when it should be 480.
UIViewAutoResizingMasks are what we refer to as 'struts' and 'springs'. Consider this: you have a large square with a small square inside. In order for that square to stay perfectly centered, you must set a fixed width from each inside edge of the large square, so as to constrain it. These are struts.
Springs, on the other hand, work more like a UIView does during rotation. Let's say our view must stay on the bottom of the screen, aligned in the center. We want to keep it's Top spring flexible so that when the view rotates from 460 px to 320 px, it keeps it's same position relative to the screen's now changed dimensions.
Keeping this in mind, when a view is loaded in portrait (as all UIViewControllers are), but the actual orientation is landscape, it's possible that the view will get 'confused' and maintain a sort of messy hybrid orientation type view. If you absolutely must (and I cannot stress how last resort-ish this is) force an orientation change beforehand, use iOS 5.x's +attemptRotationToDeviceOrientarion

UIScrollView + UITextView resizing causes textView to scroll one line

I have a UITextView with isScrollEnabled set to FALSE. I then add it as a subview of UIScrollView. I then set the content size UIScrollView based on the size of the textView. You might wonder why I am doing this. But there is a need that it be done in this way alone. There is also a UIWebView that I add below the UITextView. I have to resize everything in textViewDidChange delegate method. Everything works fine as long as I don't rotate the view. When the device orientation changes to landscape. The first line of my UITextView scroll up and goes out of view. It never comes back on rotating over and over. My webView also behaves weirdly after rotation. It enlarges the font and messes it up. How can I avoid both these problems. Both UITextView and UIWebView are class variables that I create programmatically in viewDidLoad method of my viewController.
You should have 2 frames for each of these object and set them according to the rotation of the device.
In the device rotation delegate use an if:
- if landscape: set Landscape frames
- if portrait: set portrait frames
Hope this help

Strange black bars in UITableView

I'm really scratching my head over this one: When I make visible the Toolbar of the navcontroller in my view hierarchy, strange black bars appear at the top and bottom of the table view. http://grab.by/8pgz
The app is universal, and on the iPhone simulator (or device) this does not show up, although they use the same UITableViewController subclass.
I cannot even figure out what the extra bars are, which makes it even harder to come up with a solution.
They are, however, not navbar / toolbar. They are not section or table view header / footer. It does not merely seem to be a resizing of the table view either, since its background is not black.
The custom table view controller sits inside a UINavigationController, which in turn is inside a UISplitViewController. Pretty standard, as far as I understand.
Like said, they do not show up on the phone - nor do they appear in the popover in portrait orientation.
I'm really out of clues here. Any suggestions would be most welcome.
Cheers,
Gregor
Sweden
Update: Problem solved by moving the code for making toolbar visible to -(void)awakeFromNib method instead of -(void)viewDidLoad. Still don't know what went wrong, but now at least it works.
I believe there is a problem with the frame you're trying to use to initialize the tableView.
myTableView = [[UITableView alloc] initWithFrame:CGRectMake(0, 0, height, width);
Try changing the height width variables in code, to reflect your height & width on the iPad.

How do I properly handle rotation of a UIScrollView containing UIImageViews?

I'm developing an image viewer, much like the Photos App.
It's a UIScrollView with paging enabled with images loaded from the internet, so I've adapted portions of the LazyTableImages sample. The Scroll View and each ImageView inside of it have all of their autoresize mask flags set.
When I first observed how resizes were happening during rotation, it looked good, but once I started trying to interact with the scroll view, I realized that I also had to programmatically change the size of the contentView. I did that by implementing didRotateFromInterfaceOrientation: in my view controller.
[self.scrollView setContentSize:CGSizeMake(numberOfImages * portraitWidth, [scrollView bounds].size.height)];
With interaction behaving properly, I then discovered that, if I was viewing the second photo and rotated, portions of both the 1st and 2nd photos would be shown on the screen. I needed to change the contentOffset as well.
I've tried to fix this two ways - both by using the scrollRectToVisible:animated: method of UIScrollView, as well as trying to set the contentOffset property directly. And I've experimented by putting this code in implementations of both the "one-step" and "two-step" responses to changes in Orientation. For example:
-(void)didAnimateFirstHalfOfRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation {
[self.scrollView setContentOffset:CGPointMake(currentlyViewedPhotoIndex * largeImageHeight,0) animated:YES];
In all cases though, it just looks janky as hell. Either I clearly see the scroll happen, or it just jumps. Uuuuuuuuuuugly! Is there a way to do this so that it behaves exactly like the Photos app does?
What I wound up doing instead - just before rotation starts, hide the UIScrollView and create a UIImageView that contains the currently viewed image. Rotate, that image will rotate all nice and pretty, and when rotation completes remove the ImageView and unhide the Scroll View.
Update - if you're reading this today (anytime after iOS 6), use a UIPageViewController and set transitionStyle to UIPageViewControllerTransitionStyleScroll, for crissakes.
I did something slightly different when faced with the same problem. In willRotateToInterfaceOrientation:duration:, I hide all of the UIScrollView's subviews except for the currently displayed subview, and in didRotateFromInterfaceOrientation: I unhide the subviews.

Resizing UITableView on RootController

Is it possible to resize the UITableView on the RootController of a nav based app? When RootViewController.xib is opened in IB, there isn't a view. Just the UITableView. Clicking the inspector and then the little yellow ruler, frame height is grayed out. I'm adding a toolbar programmatically to the RootViewController:
[toolbar setFrame:rectArea];
That works fine but the bottom cell in the tableview is partially hidden because the tableview doesn't know about the toolbar.
The easiest way, is to adjust the contentInset (which is inherited from UIScrollView). Resizing by setting the frame can cause crazy drawing bugs in cells.
For example, if you are trying to resize a tableview for the keyboard, do something like this:
tableView.contentInset = UIEdgeInsetsMake(0.0, 0.0, 216.0, 0.0);
tableView.scrollIndicatorInsets = tableView.contentInset;
Hope that helps someone. This way worked best for me.
Yes, but you need to have a ViewController (not a UITableViewController) as the root controller for the nav, and wrap the actual UITableView in the UIViewControllers view.
You can still have the UIViewController conform to the UITableViewDelgate and Datasource protocols, and use all the same methods you have now in your UITableViewController.
P.S. you'll get more responses if you use the plain "iphone" tag.
You could also just set the Content and Scroller inset of the tableview
I encountered a similar issue when attempting to display the detail controller by itself, see: http://vimeo.com/13054813
The issue is that the SplitView controller applies its own transform to the sub-controllers, taking them out of the orientation detection loop, which blows goats and seems incredibly 'hackish' for built-in classes. (The video illustrates what happens when you make the detail view the root view, then add it back to the split view and make the split view root while in landscape; you get double rotation of the detail view.)
Unfortunately I've again run into these transformation issues while attempting to resize a SplitViewController's detail sub-view in response to the keyboard appearing/disappearing. In portrait, all works fine, in landscape it's fscked.
Yes, adjust the contentInset and scrollIndicatorInsets are the convenient way to resize the UITableView.
As the answer of Sam Soffes posted, I succeed resize UITableView in UITableViewController for the bottom UIToolbar.