CooperRS/RMPickerViewController

Call didSelectRows/didCancel after picker dismissed

pronebird opened this issue · 9 comments

I have a trivial situation when I need to push new controller in navigation stack when user taps "Select" in Picker VC. I am surprised, but it seems that UIKit tries to push new controller in context of picker, in that case the next controller does not have a navigation bar and seems like being pushed outside of navigation stack:

- (void)pickerViewController:(RMPickerViewController *)vc didSelectRows:(NSArray *)selectedRows {
    [self performSegueWithIdentifier:kGoalsControllerSegueID sender:self];
}

A workaround to this problem right now is 0.5s delay before performing segue. I will see if I can help with PR here, but probably tomorrow.

Idea: add completion handler to dismiss method and use it to call delegate methods when dismissed. It would be easy to do without breaking current logic.

This one is a little more tricky!

I think the reason for this behavior has to do with the way a RMPickerViewController is presented (a new view controller is added to the view hierarchy). I would suggest to distinguish between pickerViewController:willSelectRows: and pickerViewController:didSelectRows:. The latter method is called after the RMPickerViewController has been dismissed. It should be safe then to perform the segue directly.

Besides: Nice bug! :)

Thanks :) Good idea regarding did/will separation, similar to UIAlertView. Also would be nice to state that in docs when this bug fixed. I am not sure about block-based implementation of showWithSelectionHandler:andCancelHandler: method, probably there it would make sense just to call selection when picker dismissed, it's kinda safer for people who are not aware of implementation details.

Btw, as part of issue, interactivePopGesture of nav controller works even when picker displayed. It totally breaks the navigation stack if used.

I am thinking, why don't we use custom modal transition instead of hacking navigation controller.

The problem with custom modal transitions is that they are awfully broken in landscape mode :/

@CooperRS I dig this for a while and currently I have a stable implementation of custom transition that supports both orientations.

The only thing left to do is to slide my controller in right direction, Because I have to take into account device orientation, but that's the matter of couple of checks.

Otherwise I have nice animation with destination view moving in perspective (using transform3d). You may want to check it out: https://github.com/pronebird/CustomModalTransition

Well: My UIWindow approach is working pretty well. Also see #9...

@CooperRS yep that's one of the stable approaches used in many HUD libraries. I see you don't want to give a shot to custom transitions, but I have nothing against UIWindow approach anyway and it's probably less error prone in long term. 👍

Should be fixed by f4c8338.

Confirm. Using separate UIWindow resolves this issue.