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

ASTableNode swipe-to-delete cell gesture can leave delete action in a partially visible state #38

Closed
rewcraig opened this issue Apr 19, 2017 · 4 comments
Labels

Comments

@rewcraig
Copy link
Contributor

When using UITableView's native swipe to delete table cell gesture, a partial swipe gesture either fully shows or hides the actions below the cell's content view.
uikitswipecell

The same gesture using ASTableNode/ASTableView leaves the cell's content view in a partially open state.

texturecellswipe

It appears that this functionality is implemented in UITableView's own (private)
implementation of:
-(void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset;

ASTableView overrides this method, which breaks the show/hide functionality. Removing ASTableView's implementation restores the functionality; obviously this is not the solution.

As an ugly solution I have tried creating a category on UITableView to expose the private method and calling [super scrollViewWillEndDragging] at the top of ASTableView's implementation.
This resolves the show/hide problem, but it doesn't seem ideal and I'm not sure of it's impact on other code.

Sample project:
ASTableSwipe.zip

@Adlai-Holler
Copy link
Member

Hmm great catch!

I think the thing to do is:

  • At the top of ASTableView.mm, add the @interface UITableView (ScrollViewDelegate) category you described.
  • Inside each of the scroll view delegate methods, add something like:
static BOOL superResponds;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
  superResponds = [UITableView instancesRespondToSelector:_cmd];
});
if (superResponds && scrollView != self) {
  [super scrollViewDid……]; 
  return;
}

To keep the code cleaner, you could make a macro that contains the top portion and returns the BOOL superResponds.

This way we only message UITableView with UIScrollViewDelegate methods that it implements, and we only ever message it for other scroll views – UITableView doesn't listen for self-events on the public protocol, it uses private methods like _scrollViewDid… for that.

Would you be willing to implement it?

@rewcraig
Copy link
Contributor Author

I'll certainly give it a shot! Thanks for the quick response :)

@Labun
Copy link

Labun commented Jun 26, 2017

Hi, I use version 2.3.2 and this bug still appears. Any suggestions?

@rewcraig
Copy link
Contributor Author

This was not integrated into the release until 2.3.3. Here is the commit:
e18d139
Hopefully you are able to upgrade from 2.3.2.

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

No branches or pull requests

3 participants