Adds support for better gesture recognizer mocking #208
Conversation
- Can specify the state of the gesture recognizer when it's recognized - Can specify what the location in the given view being recognized is This requires that the recognizer be enabled for view mocking, due to method swizzling on subclasses
| [[recognizer valueForKey:@"state"] integerValue] should equal(UIGestureRecognizerStatePossible); | ||
| context(@"with location mocking enabled", ^{ | ||
| beforeEach(^{ | ||
| [recognizer enableLocationInViewMocking]; |
There was a problem hiding this comment.
Still not sure I like this interface. Still debating whether to do this, or to dynamically find all subclasses of UIGestureRecognizer and swizzle out their -locationInView: method.
There was a problem hiding this comment.
... still think it might be best to do this dynamically.
| @@ -5,6 +5,11 @@ NS_ASSUME_NONNULL_BEGIN | |||
| @interface UIGestureRecognizer (Spec) | |||
|
|
|||
| - (void)recognize; | |||
| - (void)recognizeWithState:(UIGestureRecognizerState)state NS_SWIFT_NAME(recognize(with:)); | |||
There was a problem hiding this comment.
I'm trying to better understand the language and DSL we're building up here, because I think this could be a really neat addition to the testing DSL that PCK exposes.
It seems like the intent of -recognizeWithState: is to say that we want to trigger -recognize, then to have our intermediate state be the one that is specified, effectively making -recognize an alias for recognizeWithState: sharedRecognitionWithState:UIGestureRecognizerStateEnded.
It sounds like that's particularly helpful with one or more unique UIGestureRecognizer subclasses. Could you share a bit more of the context so I can better understand how we can merge this into PCK ?
Also happy to carry on a conversation privately, since we're often doing that anyway outside github, you and me @younata.
It looks good I'm just trying to understand the implications of UIGestureRecognizer subclasses and this method and wondering if there are any other ways forward that might be more maintainable.
I need some more time to understand what's going on with -setLocationInView: and the enable and disable friends for this, since I've only read through the changes for -recognize so far.
There was a problem hiding this comment.
Yeah. My understanding is that these UIGestureRecognizer stubs were made only with UITapGestureRecognizer in mind.
My current use case is UILongPressGestureRecognizer, which you can move around after it's recognized (hence what's going on with -setLocationInView). I had in mind the workflow of testing on UIGestureRecognizerStateBegan, then UIGestureRecognizerStateChanged, then on UIGestureRecognizerStateEnded, and/or UIGestureRecognizerStateCancelled.
But, similar deal with UISwipeGestureRecognizer, UIPanGestureRecognizer, etc. Though, for swiping, you might want to stub out -velocityInView:.
This requires that the recognizer be enabled for view mocking, due to method swizzling on subclasses