In my iPad app, I save the state (visible/not visible) of a popover. So, during the launch of the app I initialize the UIPopoverController and tell it to show itself by using presentPopoverFromBarButtonItem:permittedArrowDirections:animated:. For the first argument (UIBarButtonItem), I use self.navigationItem.rightBarButtonItem. However, the popover keeps showing up on the left side of the screen (and not underneath the targeted button).
After the app is launched, the behavior is as expected. Any suggestions how to solve this?
For your information, I initialize the rightBarButtonItem and assign it to the navigationItem in the viewDidLoad method and before asking the popover to present itself. I have tried to call the popover in viewWillAppear and viewDidLoad, but the effect is the same.
My best alternative is to use presentPopoverFromRect:inView:permittedArrowDirections:animated: instead and "guess" the position depending on the orientation of the device.
Update: when I rotate the iPad, the popover does jump to the correct position. It seems that the barButtonItem's position is only determined at the last minute and after I ask my popover to present itself.
In situations like these where timing appears to be important I found that the trick of postponing an action until the next iteration of the run loop helps. If developing for iOS 4.0+, this can be easily achieved with GDC:
// call from viewDidAppear:
dispatch_async(dispatch_get_main_queue(), ^{
// call presentPopoverFromBarButtonItem:permittedArrowDirections:animated: here
});
Related
I am several levels deep in a storyboard and want to unroll everything all the way back to the first screen. Fortunately, there are APIs designed to do exactly this:
UIViewController *topController = [UIApplication sharedApplication].keyWindow.rootViewController;
[topController dismissViewControllerAnimated:NO completion:nil];
However, this method seems to "unroll" the view stack one by one, causing each view between my current position and the first screen to briefly invoke viewWillAppear, viewDidAppear, viewWillDisappear, and viewDidDisappear. This causes a cacophony of activity in my app, as most of the intermediate screens do interesting things when they appear. I can set breakpoints in Xcode and watch these methods get invoked in reverse order back to the main screen.
I need a way to pop back to the start of the storyboard without causing every screen along the path to light up and do work.
If this means I cannot use viewWillAppear for this purpose any more, I am willing to switch to a replacement method as long as one exists.
This is expected behaviour. I assume you're presenting the layers of views with presentViewController... calls on each previous view.
You should look at using a UINavigationController as your top level view instead. Then you can just call popToRootViewControllerAnimated: when you want to go all the way back.
I am going to tear my hair out because I cannot think of a logical reason why this occurs on 5 but not 6. So basically, I have a view presented in modal fashion with a navigation bar and a Cancel button (UIBarButtonItem - no custom anything on it, just a standard button) in the navigation bar. When this Cancel button is tapped, I want the modal view to disappear. This works just fine in iOS 6. But for iOS 5 it refuses to work for 2 out of 3 places I have it in my code. What's odd to me is that it works on one but not the other two.
Using storyboards, I right click the button, click on "selector" under Sent Actions, and drag over to the appropriate IBAction method in my view controller's .h file. The link is successfully confirmed with the little blinking animation in Xcode. When I run the app on iOS 6 (simulator or device doesn't matter), the method is successfully executed upon button tap and my modal view dismissed. However, on iOS 5, the method is never even called (I set breakpoints inside the method to see if they would be hit). I've even tried switching the argument in my IBAction method from id to UIBarButtonItem *. No cigar, though.
I've also tried programmatically (in viewDidLoad) setting the cancel button's action to a selector. I've even set the target to the VC. No cigar again. Here is a screenshots of my current setup:
Please note the IBAction methods.
Is there some magical clause in the documentation that I missed? Something awfully special I need to do in order to get it to work in iOS 5? It sure seems like a bug to me, but I'm still fairly new to this stuff so what do I know.
I am using Xcode 4.5.2 and storyboards, and targeting iOS 5 and iOS 6 for the release.
Your help is appreciated, thank you.
I think there may be problem of using GestureRecognizer please comment that code and try it...
I added a separate UIView that resides under my textfields and button and below the navigation bar/title. I added the tap gesture to that programmatically, and that seems to recognize both my tap and the cancel button's action. I still would like to know why the tap gesture swallows up the UIBarButtonItem's action if the gesture is on the root view. This question helped me figure this out. Thanks.
you can exclude view/control from gesture recognizer using following delegate method.
// UIGestureRecognizerDelegate
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldReceiveTouch:(UITouch *)touch
{
// exclude your view from gesture recognizer
if(yourView == touch.view)
{
return NO;
}
//
return YES;
}
Let me start off by saying I'm not having a problem when rotating views in iOS6 after the app is open. This issue is only happening for me when the app is launched for the first time while in landscape. The new shouldAutorotate and supportedInterfaceOrientations methods are both called when launched, however none of the rotation methods are called, like willRotateToInterfaceOrientation:duration:. (shouldAutorotate is always returning YES, and supportedInterfaceOrientations is always returning UIInterfaceOrientationMaskAll)
In iOS5, the 'first' orientation to landscape on launch was taken care of automatically. Is there an explanation for why the device wouldn't call this first landscape rotation in iOS6? (The view controller I'm checking is the root controller of the window/app delegate).
Thanks in advance for any help with and insight into this.
I suppose that since the interface is not actually rotating, that the method isn't being called.
If you want to do some setup based on the orientation, have you thought of using the view controller's intefaceOrientation property?
You should now use the viewWillLayoutSubviews method and not willRotateToInterfaceOrientation:duration:. The reason is because willRotateToInterfaceOrientation:duration: is not guaranteed to be called in a number of situations.
This is stated in the iOS6 release notes among other places.
I have a strange problem when using a UIScrollView controller combined with iPhone 4 and iOS 5.1.
I have a UIScrollView which has a content size of 640x480 (double screen effectively) and in addition to the swipe to switch between the two "screens" I also permit the user to tap the screen in response to which I call something like...
[scrollView scrollRectToVisible:(CGRectMake 320,0,320,480) animated:YES];
the first 320 would be 0 if the tap occurred whilst the right hand side of the scroll view was displayed (note the scroll view has paging enabled so it can only come to rest either fully left or fully right).
I also have a situation where I sometimes display an additional view controller modally using presentModalViewController over this view controller containing the scroll view.
Everything works perfectly until the modal view controller is presented and subsequently dismissed after which the scrollRectToVisible method will no longer work if animated is set to YES (if I change animated to NO then it works as expected). Note, the tap is still being registered and the scrollRectToVisible being called, it just doesn't do anything when animated is set to YES).
Here's the kicker, this bug only occurs on an iPhone 4 runnings iOS 5.x.
It works perfectly (even after the modal view controller has been displayed) on my:
iPhone 3G running 4.x,
iPhone 3GS running 3.x,
iPod touch (2nd Gen) running 4.x
and most surprisingly the simulator running 5.x.
I wondered if this was a bug in the animation system so disabled the animation on the modal view controller presentation and dismiss and this had no effect, problem still occurred on the iPhone 4 with iOS 5.1.
Anyone got any ideas as to what might be causing this and how I might work around it?
Finally tracked this down. what a pig...
I'm embedding a view from a view controller as a subview of another view controllers view. So my scroll view contains a view which also has an associated view controller.
Prior to iOS 5.x the methods viewWillAppear, viewWillDisappear, viewDidAppear and viewWillDisappear are never called on the sub views view controllers, only the main view controller. Already knowing this I set up my main view controller to manually call the sub views view controllers methods when these events happen.
However it appears that in iOS 5.x this issue has been "fixed" so where I was manually passing the call to viewWillAppear to my sub view controller I no longer need do this under 5.x as the method automatically gets called under 5.x - as a result it's now being called twice under 5.x but still only once when running on a 4.x or earlier device.
As a result, under 5.x my NSTimer used to call my updateUI method is being created twice, but because in viewDidDisappear I only destroy the timer if it is non nil it only gets destroyed once - therefore I'm leaking NSTimers under 5.x through double allocation where I'm not under 4.x.
As a result of multiple NSTimers hanging around all repeatedly calling my updateUI method is that the constant updating of the UI is killing the animation system and so the animation for the scrollView fails when running on an actual device. I guess it continued working OK on the simulator running 5.x as the CPU in the Mac is more than capable of handling the extra workload and still performing the animations correctly.
A simple check in my viewWillAppear method to ensure the NSTimer hasn't already been created has fixed the problem and has kept compatibility with 4.x and earlier.
I frustratingly run up against these kinds of issues every time Apple update their iOS by major versions... The morale of this story is don't assume that long standing classes still exhibit the same behaviour under different revisions of the OS.
I had the same problem. I realized that after modalViewController is dismissed my UIScrollerView shifts downs by 20px, which is the same height as status bar. So, it means when my UIViewController is loaded and UIScrollView is created, UIScrollView thinks there is no status bar, when actually it is there.
So I tried to put in viewDidLoad:
[[UIApplication sharedApplication] setStatusBarHidden:NO];
Now my UIScrollView always stays under status bar, with Y position 20px. It never shifts down.
I finally managed to get this working on an iPhone4 running 5.1. Ensuring the bounces horizontally property for the scroll view is set fixed the problem, though why having this unchecked should cause the problem in the first place is beyond me - I'm pretty certain this is a bug in iOS.
-I have a UIView.
-This UIView has a UIButton that when clicked makes a UIAlertView appear.
-Within this UIAlertView I have another UIButton that when clicked calls buttonClicked:
-Within this buttonClicked: method, I call presentPopoverFromRect with a custom view inside. (hourKeyboard is the custom view)
-(void)buttonClicked:(id)sender
{
if(self.hourKeyboard==nil)
{
self.hourKeyboard = [[HourKeyboardViewController alloc] init];
self.hourKeyboardPopover = [[UIPopoverController alloc] initWithContentViewController:self.hourKeyboard];
}
[self.hourKeyboardPopover presentPopoverFromRect:[sender bounds] inView:sender permittedArrowDirections:UIPopoverArrowDirectionLeft animated:YES];
}
In normal portrait mode, this works great. The popover spawns just to the right of the button, with the arrow correctly pointing left to the button.
There's 2 problems that arrises:
1) While this popover is visible, when you rotate the screen the popover rotates slightly incorrectly (it doesn't reposition it's own x and y position)
2) If the popover is not being shown. If you rotate the screen, then call "buttonClicked", the popover will appear, however, its being shown sideways above the button with the arrow pointing "down" towards the button (technically left in relation to the sideways popover view). If you dismiss it, rotate the screen, then call "buttonClicked", the popover now appears upside down with the button pointing "right" to the button (again, technically left in relation to the sideways popover view)! Repeat to make it sideways again, then right-side up again.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My thinking:
1) I believe I can just reposition the x and y, however, I've also read that you should dismiss the popover and present it over again on a rotation. I'll see if I can get the first one working, however I'm more concerned about the second problem.
2) I have no idea how to fix this rotation issue. It seems that when you rotate to landscape without the popover being visible. And then you call presentPopoverFromRect, the popover is created with the iPad thinking it's still in portrait view by mistake. That's the behavior it's giving, however, I'm not sure how to make the iPad not make this mistake.
-=-=-=-=-=-=-=-=-=
Thanks again for any help you can provide!
-=-=-
Slight Update:
1) It was easy to just dismiss the popover from the main view on rotation. And this seems to be the general way everyone deals with this issue.
2) Trying out various things such as changing the frame, using CGAffineTransformMakeRotation, and others...but no luck thus far
-=-=-
Another Update:
2) After a lot of testing, it seems to be a direct issue with UIAlertView. If I place the view within UIAlertView (currently doing), the AlertView doesn't tell the popover that the screen is rotated...thus creating the issue
It looks like the only way to fix this is to drop the UIAlertView completely. Instead of showing the UIAlertView, I'll disable the various background views manually (like Alert View was doing) and then show a custom UIView that looks darn similar to the AlertView. From there, I should be able to show the popover without any issues. I'll let yea know how it turns out.
-=-=-=-=-=-=-=-
Final Solution:
I ended up just creating my own view, and having that view imitate a UIAlertView. Then when I spawned the popover, I placed it in the root view controller. Worked much MUCH better, but required more work since I had to manually create my own View instead of the premade UIAlertView. Either way, apparently UIAlertView fails at telling a UIPopoverover subview what rotation it is in.
dismiss the popover in willRotateToInterfaceOrientation and show it again in didRotateFromInterfaceOrientation.
It works with no problems.
EDIT:
Sorry, I misunderstood your second problem.
If some part of your view hierarchy is displayed with bad orientation, one of your controllers is probably missing shouldAutorotateToInterfaceOrientation method.