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

Add long press gesture support #299

Closed

Conversation

jamztang
Copy link
Contributor

@jamztang jamztang commented Jan 2, 2014

Particular useful for use case that needed to perform different actions based on user actions.

Say normal tap goes to in-app browser, long pressing shows a dialog for copy link and open in Safari.

pod ‘TTTAttributedLabel’, :git => ‘https://github.com/jamztang/TTTAttributedLabel.git’, :branch => ‘longpresssupport’

@getaaron
Copy link
Contributor

getaaron commented Jan 4, 2014

@jamztang I just submitted a similar pull request here: #302 - I'm curious if you have any feedback on it. I think I like your performSelector: approach over my NSTimer approach. I took the approach of adding separate delegate methods instead of a state variable. I'm not sure which of those I like better yet.

Two differences I noticed:

  • One thing I ran into in my implementation is that a user might press on one link, then slide onto a different link, but the first link would still be registered. (See my handling in touchesMoved:withEvent:.)
  • I'm exposing a CGPoint when a user long-presses on a link. This is helpful for iPad apps, in which a UIActionSheet must be presented from a specific rect.

@jamztang
Copy link
Contributor Author

jamztang commented Jan 4, 2014

I have looked into your implementation at #270 before. I wanted to do minimal changes to both the library (minimal additional lines) and developers (just one condition to adopt the long press, instead of needing to implement a new method), yet customisable to disable the long press gesture easily, and also extensible to add more info like the CGPoint info to just another property when needed.

I think the performSelector is a bit more easier to control and simpler to just cancel right away when touch ended or cancelled.

@mattt
Copy link
Contributor

mattt commented Nov 20, 2014

Thanks for your PR, @jamztang. Of the two current proposals for this feature, I prefer #302, though I'm not entirely sold on that particular implementation either. Defining an enum for tap interactions and exposing a long press interval are not patterns I'd be interested in pulling in.

@mattt mattt closed this Nov 20, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants