-
Notifications
You must be signed in to change notification settings - Fork 659
Block front view "Push" button action while rear view is active. #7
Comments
I consider this problem to be too specific for me to solve it for you. The rationale behind it is as follows: Not everyone might appreciate this kind of behavior in every situation. Take the iPad as an example. It wouldn't make sense to disable user interaction with the FrontView on a screen that big. I agree with the iPhone though. It doesn't make sense to have the user still be able to hit buttons or similar on the front view (if say in portrait mode) seeing how the area of interaction is about 40 points wide. Give or take. Thus I provide you with a protocol you can conform to. The ZUUIRevealControllerDelegate. The usual approach would be no different from what you do when subclassing UITableViewController.
For example, in order to achieve your desired Path way, a quick and dirty solution would be: - (void)revealController:(ZUUIRevealController *)revealController didRevealRearViewController:(UIViewController *)rearViewController { UIView *touchIntercepterView = [[UIView alloc] initWithFrame:revealController.frontViewController.view.frame]; UITapGestureRecognizer *tapGestureRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:revealController action:@selector(revealToggle:)]; [touchIntercepterView addGestureRecognizer:tapGestureRecognizer]; [tapGestureRecognizer release]; [revealController.frontViewController.view insertSubview:touchIntercepterView atIndex:INT_MAX]; [touchIntercepterView release]; } - (void)revealController:(ZUUIRevealController *)revealController didHideRearViewController:(UIViewController *)rearViewController { NSArray *subviews = [revealController.frontViewController.view subviews]; UIView *touchInterceptionView = [subviews lastObject]; [touchInterceptionView removeFromSuperview]; } Note: I don't recommend using the snippet above in production the way I just provided it. It makes my eyes bleed. That's just to show you how it can be done with the least amount of effort. Nonetheless, everything you need to implement your custom behavior and device differentiation (iPhone <-> iPad) is available to you. You can even achieve a perfect recreation of the Facebook way by say,...swapping the "Back" button (if you popped a few things onto the navigation stack the "reveal" button disappears ,..obviously) with a "Reveal" button whenever didRevealRearViewController: is triggered and swapping it back once didHideRearViewController: occurred. Just some thoughts. In the end it's up to you to make use of the barebones I provide. Did that solve your issue or do you still think there should be something I should implement on my side? Please do elaborate I'm open to ideas :-) |
The facebook/path behavior is so entirely expected for the iphone that being able to manipulate the front view controller (by default) is nearly a bug. Subclassing and delegation should be required for the uncommon behavior, not the (95%? )expect one. I know I know: "patches welcome" :P |
I added this to the touch interceptor view to more closely mimic facebook on the iPad, which allows you to drag the front view back into place in addition to tapping it.
|
One other small issue, this method
|
I am thinking when the rear view is revealed, the "Push!" button in the sample code should not push other view inside the hidden front view. I am expecting the behavior of the front view while the rear view is active is either of these:
The text was updated successfully, but these errors were encountered: