Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SplitViewController in portrait - popover appears behind mainView on detailView #21

Open
DrBeak1 opened this issue Jan 31, 2013 · 14 comments

Comments

@DrBeak1
Copy link

DrBeak1 commented Jan 31, 2013

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!

@ocrickard
Copy link
Contributor

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).

@DrBeak1
Copy link
Author

DrBeak1 commented Jan 31, 2013

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!!
example

@DrBeak1
Copy link
Author

DrBeak1 commented Jan 31, 2013

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.

@DrBeak1
Copy link
Author

DrBeak1 commented Jan 31, 2013

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.

@DrBeak1
Copy link
Author

DrBeak1 commented Feb 20, 2013

Has anyone found any other solution to this issue yet?

@ocrickard
Copy link
Contributor

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

@DrBeak1
Copy link
Author

DrBeak1 commented Feb 20, 2013

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].
example

@ocrickard
Copy link
Contributor

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

@DrBeak1
Copy link
Author

DrBeak1 commented Feb 20, 2013

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

Thanks!

@DrBeak1
Copy link
Author

DrBeak1 commented Feb 20, 2013

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.

@ocrickard
Copy link
Contributor

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

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

@DrBeak1
Copy link
Author

DrBeak1 commented Feb 20, 2013

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.

@DrBeak1
Copy link
Author

DrBeak1 commented Feb 21, 2013

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.

@ocrickard
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants