¿Cómo detectar el evento de arrastre de un UITableView?

Necesito recibir una notificación cuando la resistencia de UITableView ha llegado a su fin.

Pero estoy trabajando en la categoría UITableView, así que no puedo usar scrollViewDidEndDragging:willDecelerate: para archivar esto.

Intenté usar KVO para observar al dragging ruta key:

 [self addObserver:self forKeyPath:@"dragging" options:NSKeyValueObservingOptionNew context:nil]; 

Pero observeValueForKeyPath:ofObject:change:context: no se llamó, ya que UITableView.dragging no tiene y setter y esta propiedad no es compatible con KVO.

¿Hay algún otro método para archivar esta expectativa para usar scrollViewDidEndDragging:willDecelerate: 😕

¡Cualquier ayuda es agradecida! ¡Gracias!

Editar: Mi solución a continuación fue la primera cosa a tener en count y resultó ser bastante hacky y puede ser inseguro de usar en caso de que Apple decida cambiar los elementos internos de la class UIScrollView . Vea la respuesta sugerida por Mazyod, que debería ser más segura y más directa.


Esto depende de la implementación y Apple puede cambiarlo en futuras actualizaciones de iOS, pero actualmente la class UIScrollView parece depender de los reconocedores de gestos para gestionar la interacción del usuario y UITableView es una subclass de la class de vista de desplazamiento que hace lo mismo.

Si va a UIScrollView.h del marco UIKit, puede observar un _pan ivar sospechoso que tiene un tipo de id , pero parece ser realmente un UIPanGestureRecognizer .

Entonces probé esto y parece funcionar.

  [_tableView addObserver: self forKeyPath: @"pan.state" options: NSKeyValueObservingOptionNew context: nil]; 

Al arrastrar la vista de tabla, el state del gestor de reconocimiento cambia varias veces, y cuando deja de arrastrar, el state recibe su último cambio en el valor de UIGestureRecognizerStateEnded .

Tenga en count que, aunque esto parece hacer el truco, algún otro problema puede interponerse en su path. Por lo general, no es una buena idea anular los methods de class existentes en una categoría, ya que la implementación original se vuelve inaccesible después de eso. La documentation sobre el protocolo informal NSKeyValueObserving indica que

NSObject proporciona una implementación del protocolo NSKeyValueObserving que proporciona una capacidad de observación automática para todos los objects.

Por lo tanto, si reemplaza observeValueForKeyPath:ofObject:change:context: en una categoría, la implementación pnetworkingeterminada será inaccesible (y no podemos estar seguros de que UITableView o UIScrollView no usen KVO para algo). Eso puede causar algunos errores inesperados.

La respuesta de Egor Chiglintsev me recordó que puedo observar la propiedad panGestureRecognizer ya expuesta en UIScrollView . Debería ser mucho más seguro que la pan . Pero luego … ¡Descubrí que puedo añadirme como objective!

 [_scrollView.panGestureRecognizer addTarget:self action:@selector(gestureRecognizerUpdate:)]; 

¡Esto funciona muy bien para mí!