SplitViewController in portrait - popover appears behind mainView on detailView about popoverview HOT 14 OPEN

Hello,

OK, so I'm not 100% sure I understand what's going on. It sounds like the SplitViewController is in a window above the key window, or possibly has its layer's zPosition set above all other views.

I'm going to try and work on a solution to this problem this weekend by just adding another UIWindow onto the stack to get around all these problems. This is now the biggest problem with the component.

Oliver

Oliver C. Rickard
iOS Engineer
Runway 20

On Thursday, 31 January 2013 at 10:58, DrBeak1 wrote:

So I'm not sure if any others have experienced this, but reading through other posts I didn't find anything that was exact.
Currently I have a project that uses a splitViewController. When in landscape I can tap a button in the mainView (leftside view) and the popupView shows up just as expected. However, if I rotate to portrait, swipe right to display the mainView on top of the detailView, then tap the same button the popupView appears behind the mainView on the detailView. If I slide the mainView out of the way the popupView remains there on the detailView.
Any help with this would be great. I'll mess around with things a bit to see if I can fix on my own, just thought I'd mention here.
Thanks!

—
Reply to this email directly or view it on GitHub (#21).

from popoverview.

Wow, quick response! Thanks, Oliver. Yes you have it right. It's just the basic, built-in functionality of the UISplitViewController. In portrait if you swipe to the right it shows the mainView (some call it the masterView, or leftView, etc) on top of the left side of the detailView. Then if you tap on a button to show popover it is hidden behind the mainView, on the detailView. See attached image for visual example. Thanks again!!

from popoverview.

This is where the issue seems to be occurring in:

• (void)showAtPoint:(CGPoint)point inView:(UIView *)view withContentView:(UIView *)cView {
  // ... other code ...

  //Locate the view at the top fo the view stack.
  UIWindow *window = [UIApplication sharedApplication].keyWindow;
  if(!window) {
  window = [[UIApplication sharedApplication].windows objectAtIndex:0];
  }
  NSLog(@"window sub = %@", window.rootViewController);
  topView = [[window subviews] objectAtIndex:0];

  // ... other code
  }

It seems the key window remains the detailView even though the masterView is clearly on top.

from popoverview.

This is an ugly, ugly fix - but it works:

- (void)showAtPoint:(CGPoint)point inView:(UIView *)view withContentView:(UIView *)cView {

    // ... other code ...

    //Locate the view at the top fo the view stack.
    UIWindow *window = [UIApplication sharedApplication].keyWindow;
    if(!window) {
        window = [[UIApplication sharedApplication].windows objectAtIndex:0];
    }

    topView = [[window subviews] objectAtIndex:0];
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {

        for (UIView *v in window.subviews) {
            for (UIView *sv in v.subviews) {
                // Here we check to see if there is a UIPopoverView in the stack
                // which we have to do using a string comparison of the class because
                // the UIPopoverView is not recognized by the compiler as a valid class
                NSString *string = [NSString stringWithFormat:@"%@", [sv class]];
                if ([string isEqualToString:@"_UIPopoverView"]) {
                    topView = nil;
                    topView = sv;
                }

            }
        }

    }

    // ... other code ...
}

Also, at this point I'm not sure of the ramifications this will have in other scenarios where you'd be using a SplitViewController's PopoverViewController and this component.

from popoverview.

Has anyone found any other solution to this issue yet?

from popoverview.

So I've updated the project on a new branch, and added a tiny bit of code that may help out here. I really don't know. So I'm throwing it out there in the hopes that it helps you:

https://github.com/runway20/PopoverView/tree/New-Window

from popoverview.

Hi Oliver, thanks for responding. I tried the update and it does work, however it does not respond to orientation changes. For example, if I'm in portrait and use the popover everything works and looks fine. Then if I switch to landscape, tap the button to show popover, the popover is sideways [see image].

from popoverview.

OK, I've added a couple of majorly hacky changes to the branch. Mind checking if this works for you?

from popoverview.

Sure thing. Give me about an hour - just stepped away from my desk.

Thanks!

from popoverview.

Yep - this solves the orientation problem but adds a new issue: The popups will not dismiss.

Also in PopoverView.m, I think your UIViewAnimationCurveEaseInOut need to be changed to UIViewAnimationOptionCurveEaseInOut. Not having the "Option" there causes warnings because this is two different enumeration sets.

from popoverview.

Hmmm... What happens if you set topWindow.userInteractionEnabled = YES?

And yep, you caught me! I'll try to fix the warning tonight...

from popoverview.

Doesn't seem to do anything. Perhaps I'm not setting it in the correct place. I've set this here:

- (void)showAtPoint:(CGPoint)point inView:(UIView *)view withContentView:(UIView *)cView {

    //NSLog(@"point:%f,%f", point.x, point.y);

    self.contentView = cView;
    parentView = view;

    // get the top view
    // http://stackoverflow.com/questions/3843411/getting-reference-to-the-top-most-view-window-in-ios-application/8045804#8045804

    UIWindow *newWindow = [[UIWindow alloc] initWithFrame:[[UIApplication sharedApplication] keyWindow].frame];
    newWindow.backgroundColor = [UIColor clearColor];
    [newWindow makeKeyAndVisible];
    [newWindow setRootViewController:[[PopoverViewRotationController alloc] init]];
    newWindow.rootViewController.view.backgroundColor = [UIColor clearColor];
    newWindow.rootViewController.view.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;
    [newWindow setWindowLevel:UIWindowLevelAlert];
//    [newWindow setHidden:NO];
    oldWindow = [[UIApplication sharedApplication] keyWindow];
    topWindow = newWindow;
    topView = newWindow.rootViewController.view;

#warning added suggested interaction enabler here ...
    topWindow.userInteractionEnabled = YES;

... other code ...


}

I should also note that the first dismissal DOES work. But if you tap a button to show the popover again, it's any following times that the dismiss doesn't work. So -- first time, works great - any time after - not so much.

from popoverview.

OK, I've added a couple of majorly hacky changes to the branch. Mind checking if this works for you?

If it's going to take hacks to make this work, wouldn't it be simpler just to use the hack I posted above?

Post from 2/1/2013:

- (void)showAtPoint:(CGPoint)point inView:(UIView *)view withContentView:(UIView *)cView {

    // ... other code ...

    //Locate the view at the top fo the view stack.
    UIWindow *window = [UIApplication sharedApplication].keyWindow;
    if(!window) {
        window = [[UIApplication sharedApplication].windows objectAtIndex:0];
    }

    topView = [[window subviews] objectAtIndex:0];
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {

        for (UIView *v in window.subviews) {
            for (UIView *sv in v.subviews) {
                // Here we check to see if there is a UIPopoverView in the stack
                // which we have to do using a string comparison of the class because
                // the UIPopoverView is not recognized by the compiler as a valid class
                NSString *string = [NSString stringWithFormat:@"%@", [sv class]];
                if ([string isEqualToString:@"_UIPopoverView"]) {
                    topView = nil;
                    topView = sv;
                }

            }
        }

    }

    // ... other code ...
}

But I guess this would only work when trying to display the PopoverView on a UIPopoverView on an iPad in portrait orientation. It makes sense to find a more universal solution.

from popoverview.

Yes, that's a good point. To be clear, what I meant by hackish is that it's not that clean, but it IS super general. What I've done is created a UIWindow with a custom subclass of UIViewController to accept the standard autorotation selectors to allow the component to rotate.

I believe introduction of a new UIWindow is the only way that we can achieve the display level required by many of the users of the component. If you look at the issues, I think a majority relate to this problem. We could do a case-by-case approach and deal with them individually, but I tried this already, and it just introduces more problems for other users. If it works for you, then awesome, go for it.

Now, the problem you're describing with the window approach appears to have two possible causes:

1. The new topWindow is not being removed.
2. The old window does not become key window.

I'll try to play with this soon if I can.

from popoverview.