2008-12-05 7 views
6

Me gustaría implementar un UITableView que muestre, por ejemplo, 20 filas a la vez. Pero dado el hecho de que en realidad podría tener decir 120 artículos para presentar, me gustaría manejar esto usando algún tipo de paginación:¿Cómo implementaría una UITableView que detecta deslizamientos horizontales para permitir la paginación?

Rellene la tabla con los primeros 20 elementos. Cuando el usuario haga un deslizamiento de derecha a izquierda, vuelva a cargar el UITableView con los siguientes 20 elementos. Un deslizamiento de izquierda a derecha mostraría los 20 elementos anteriores.

Creo que subclonando UITableView y manejando las delegaciones de UIT hay un camino por recorrer, pero no estoy seguro de cómo manejar los toques correctamente para no interferir con el manejo de eventos estándar.

Por ejemplo. si el usuario simplemente toca (hace clic) una fila, quiero que la fila se encienda (seleccione) y luego cambie a una vista de detalle que presente los datos correspondientes a la fila seleccionada. Pero si el usuario hace un deslizamiento horizontal, no quiero que la fila debajo del deslizamiento se resalte (y, por lo tanto, se seleccione); en su lugar, quiero activar mi carga previa página/cargando el manejo de la página al siguiente, que volverá a cargar la tabla con el 20 elementos anteriores o siguientes, dependiendo de la dirección del deslizamiento.

¿Alguna sugerencia?

Respuesta

2

Este es un paradigma de IU bastante no estándar. Seguramente se desplazará hacia arriba/abajo sobre los 120 elementos, al igual que (por ejemplo) la aplicación Contactos. Estás haciendo la vida más complicada para ti, y corres un grave riesgo de que esta aplicación sea rechazada por Apple debido a la extraña interfaz de usuario.

El método actual por el que desea implementar esto se describe en http://forums.macrumors.com/showthread.php?t=532573

He leído el código de allí, y parece sensato, aunque se me ocurre que también puede ser necesario para manejar touchUpInside, y no llame a [super touchUpInside] para evitar seleccionar una celda en un deslizamiento horizontal.

9

Un deslizamiento horizontal en una fila de la tabla ya es un comportamiento de IU estándar que hace que esa fila sea eliminada. No cambie los paradigmas de UI estándar: confunde a los usuarios y hace que no les guste su aplicación.

+0

En la aplicación "Byline" puede deslizar los elementos para marcarlos como leídos o no leídos, y eso me gusta. –

+0

echa un vistazo a tweetie – shreyasva

1

Sólo tiene que llamar un toque cancelar método no comprobar el golpe IR se produjo sin contacto con points.Then hacer su funcionalidad

1

Si yo realmente quería hacer esto yo subclase UITableView y añadir múltiples copias de la misma a un UIScrollView . Desenredar los eventos sería espantoso y no creo que la UI valga la pena.

1

De hecho, escribí el código mencionado por Airsource Ltd al http://forums.macrumors.com/showthread.php?t=532573, por lo que apuntarme a mi propio código no fue de mucha ayuda, de todos modos, mi culpa, pero bueno, ¿quién no usa diferentes nombres de pantalla en diferentes foros? ;-)

De todos modos, fue aprobado después de la presentación a la tienda de aplicaciones, y en mi humilde opinión es muy útil cuando se trata de largas listas. La paginación es algo que se usa comúnmente en la web, y no me gustaría obligar a un usuario a desplazarse hacia abajo o hacia arriba en una lista con más de 500 (¿dije más de 500? ¿Qué pasa con más de 1000?) Filas.

Acepto que un deslizamiento horizontal en una lista debe/permitirá al usuario eliminar/editar una fila como un comportamiento predeterminado. Pero, ¿no es ese contexto específico?

Si como usuario soy el "propietario" de los datos, esperaría poder eliminar filas. Pero, ¿esperaría poder eliminar filas en una lista de aplicaciones en la AppStore o una lista de libros en una aplicación de Amazon?

Un deslizamiento horizontal en una lista es solo un gesto, según el contexto, debe hacer lo que el usuario esperaría.

Dado el escenario de una lista con más de 500 filas, ¿qué harías? Muestre las primeras 25 filas con un "Show me more" -Footer? -> entonces tendrías 50 Filas? ¿y así? al final, ¿tendrías 527 filas? A menos que vayas duro-dibujando tu celda, la mesa también dibujará picado encima de ella. Pero incluso si se desplaza suavemente, esto no resolvería el problema de desplazarse hacia arriba o hacia abajo 2000 millas de píxeles.

¿O poner un encabezado/pie de página con "Página anterior/Página siguiente" - Botones, por lo tanto, solo se muestran 25 filas a la vez? Luego obligaría al usuario a desplazarse hacia la parte superior o inferior para cambiar a la página anterior o siguiente ...

Estoy abierto para cualquier sugerencia. Parece un gesto natural para mí deslizar hacia la izquierda o hacia la derecha en algo que tiene algo "anterior/siguiente".

3

¿Qué le parece usar el índice de sección de UITableView como alternativa?

anular el siguiente:

- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView; 

- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index; 

esto le dará la barra de índice en el lado derecho de la tableview que permite saltar rápidamente a la parte inferior de la tabla (Véase la aplicación iPod para una referencia si no sé a qué me refiero). No tiene que incluir todas las secciones del índice para evitar sobrecargarlo con cientos de secciones.

Uso el símbolo de grado para mi índice, ya que las secciones de mi tabla no son alfabéticas.

Si la estructura de respaldo sigue siendo una gran lista, deberá dividirla en secciones. (No es necesario que muestre un encabezado para las secciones, por lo que puede parecer idéntico a la tabla existente)

En cuanto a apartarse del comportamiento de la IU estándar ... ocasionalmente, al intentar emitir una actualización de la aplicación, puede consigue un crítico irritable que rechazará tu actualización por un "problema" de la interfaz de usuario que estaba presente en una versión anterior de la aplicación. Solo una advertencia, como cuando estás tratando de obtener una solución importante, es la cosa más agravante del mundo. sacude el puño en Apple

En cuanto al rendimiento, he tenido un rendimiento de desplazamiento no grueso en tablas de hasta 900 elementos. Cosas a tener en cuenta si se vuelve grumoso ... 1) Asegúrese de utilizar correctamente el Identificador de reutilización al eliminar las células. 2) Celdas de tabla personalizadas con controles complejos. (Si tiene que agregar sus propias subvistas a las celdas de la tabla, las UILabels son más rápidas, sin transparencia) 3) Evite las celdas de la tabla con una altura no estándar (por ejemplo, no 40). (un error reconocido de Apple, aunque no he validado esto es realmente un problema.)

3

La pregunta principal es "por qué": ¿por qué crees que el usuario querría ir al artículo # 527? ¿Cómo se espera que sepa que el artículo que quiere está en la página 6? En la página 17?

Señala correctamente que desplazarse por 1000 elementos es extraño, pero buscar 1000 elementos es igualmente extraño. Probablemente desee mejorar las capacidades de filtrado o clasificación de su aplicación. Desplazarse por miles de elementos es una locura, a menos que espere que el usuario lea/escanee cada uno, en cuyo caso tener una lista lineal no es un problema.

UITableView tiene un índice de sección a la derecha, que podría resolver su problema según el contexto.Ciertamente resuelve el problema para la lista de contactos: incluso si tiene 2000 contactos, solo necesita desplazarse a través de unos 100 de ellos una vez que selecciona la letra de inicio. (El rendimiento no es un problema, porque UITableView nunca crea o solicita más filas que las visibles en la pantalla.)

Finalmente, he usado una aplicación que hacía una vista similar de paginación + tabla y odiaba la experiencia. Se siente completamente distinto de iPhonish.

Cuestiones relacionadas