Wie würden Sie eine UITableView implementieren, die horizontale Swipes erkennt, um Paging zu ermöglichen?

Question

Ich möchte ein UITableView implementieren, das sage und schreibe 20 Zeilen gleichzeitig anzeigt. Aber angesichts der Tatsache, dass ich tatsächlich 120 Dinge zu präsentieren hätte, würde ich gerne mit einer Art von Paging umgehen:

Füllen Tabelle mit den ersten 20 Elemente. Wenn der Benutzer einen Streichen von rechts nach links durchführt, laden Sie das UITableView mit den nächsten 20 Elementen neu. Ein Streichen von links nach rechts würde die vorherigen 20 Elemente anzeigen.

Ich denke, Unterklasse UITableView und behandeln UITouches gibt es den Weg zu gehen, aber ich bin mir nicht sicher, wie die Berührungen richtig behandelt, um nicht mit der Standard-Event-Handling zu stören.

Eg. Wenn der Benutzer nur eine Zeile berührt (klickt), möchte ich, dass die Zeile heller wird (ausgewählt) und dann zu einer Detailansicht wechselt, die Daten anzeigt, die der ausgewählten Zeile entsprechen. Aber wenn der Benutzer einen horizontalen Swipe ausführt, möchte ich nicht, dass die Zeile unter dem Swipe hervorgehoben (und daher ausgewählt) wird, stattdessen möchte ich meine loadprevious page/loadnext page handling auslösen, die die Tabelle mit dem entsprechenden neu lädt 20 vorherige oder nächste Elemente, abhängig von der Wischrichtung.

Irgendwelche Vorschläge?

Answer 1

Dies ist ein nicht standardmäßiges UI-Paradigma. Sicherlich würden Sie über die 120 Elemente nach oben/unten scrollen, wie zB die Kontakte-App. Sie machen das Leben komplizierter für Sie selbst - und Sie laufen ein ernsthaftes Risiko, dass diese App von Apple wegen der seltsamen Benutzeroberfläche abgelehnt wird.

Die tatsächliche Methode, mit der Sie diese in http://forums.macrumors.com/showthread.php?t=532573 beschrieben implementieren würde

ich den Code dort gelesen habe, und es sieht sinnvoll, wenn es mir einfällt, dass Sie auch touchUpInside zu handhaben müssen, und Rufen Sie [super touchUpInside] nicht auf, um zu vermeiden, dass eine Zelle auf einem horizontalen Swipe ausgewählt wird.

Answer 2

Ein horizontaler Wischvorgang in einer Tabellenzeile ist bereits ein Standardverhalten der Benutzeroberfläche, das dazu führt, dass diese Zeile gelöscht wird. Wechseln Sie nicht die Standard-UI-Paradigmen - das verwirrt die Nutzer und lässt sie Ihre App nicht mögen.

Answer 3

Rufen Sie einfach einen Hauch abbrechen Methode dort überprüfen die Swipe ir nicht mit Touch points.Then tun aufgetreten ist Ihre Funktionalität

Answer 4

Wenn ich wirklich, dies tun wollte, würde ich UITableView Unterklasse und mehrere Kopien davon zu einem UIScrollView hinzufügen . Die Ereignisse zu entwirren wäre schrecklich und ich denke nicht, dass die UI die Mühe wert wäre.

Answer 5

Ich schrieb tatsächlich den von Airsource Ltd erwähnten Code unter http://forums.macrumors.com/showthread.php?t=532573, also wies mich auf meinen eigenen Code war nicht viel Hilfe thx sowieso, meine Schuld, aber hey, wer nicht verschiedene screennames in verschiedenen Foren verwendet? ;-)

Wie auch immer, es wurde nach der Einreichung an den Appstore genehmigt, und IMHO ist es sehr nützlich, wenn es um lange Listen geht. Paging ist etwas, das häufig im Web verwendet wird, und ich möchte nicht einen Benutzer zwingen, eine Liste mit 500+ (habe ich sagen 500+? Was ist mit 1000+?) Reihen nach unten/nach oben zu scrollen.

Ich stimme zu, dass ein horizontaler Swipe auf einer Liste den Benutzer in die Lage versetzen sollte, eine Zeile als Standardverhalten zu löschen/bearbeiten. Aber ist das nicht kontextspezifisch?

Wenn ich als Benutzer der "Eigentümer" der Daten bin, würde ich erwarten, Zeilen löschen zu können. Aber würde ich erwarten, Zeilen in einer Liste von Apps im AppStore oder eine Liste von Büchern in einer Amazon App löschen zu können?

Ein horizontaler Swipe auf einer Liste ist nur eine Geste, je nach Kontext sollte es tun, was der Benutzer erwarten würde.

Angesichts des Szenarios einer Liste mit mehr als 500 Zeilen, was würden Sie tun? Zeige die ersten 25 Reihen mit einem "Show me more" -Footer? -> dann hätten Sie 50 Zeilen? und so weiter? Am Ende hätten Sie 527 Zeilen? Solange Sie nicht Ihre Zelle hardcore-zeichnen, wird der Tisch auch choppy darüber ziehen. Aber selbst bei einem reibungslosen Scrollen würde dies das Problem des Scrollens von 2000 Meilen Pixel nicht lösen.

Oder setzen Sie eine Kopfzeile/Fußzeile mit "Vorherige Seite/Nächste Seite" - Schaltflächen, so dass nur 25 Zeilen gleichzeitig angezeigt werden? Sie würden dann den Benutzer zwingen, nach oben oder unten zu scrollen, um zur vorherigen oder nächsten Seite zu wechseln ....

Ich bin offen für Vorschläge. Es erscheint mir nur als eine natürliche Geste, nach links oder rechts auf etwas zu streichen, das ein "vorheriges/nächstes" Etwas hat.

Answer 6

Wie wäre es mit UITableView Abschnitt Index als Alternative?

folgende außer Kraft setzen:

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

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

Dies gibt Ihnen die Indexleiste auf der rechten Seite des Tableview, die Benutzer springen schnell auf den unteren Teil der Tabelle (Siehe die iPod App, wenn Sie für einen Verweis lässt Ich weiß nicht, was ich meine.) Sie müssen nicht jeden Abschnitt in den Index aufnehmen, damit Sie ihn nicht mit 100 Abschnitten überladen.

Ich verwende das Gradsymbol für meinen Index, da meine Tabellenabschnitte nicht alphabetisch sind.

Wenn die unterstützende Datenstruktur noch eine große Liste ist, müssen Sie sie in Abschnitte aufteilen. (Sie müssen keine Header-Show für Abschnitte haben, damit sie mit der vorhandenen Tabelle identisch aussehen kann)

Wie Sie vom Standard-UI-Verhalten abweichen ... gelegentlich, wenn Sie versuchen, ein App-Update auszugeben, können Sie erhalten Sie einen streitsüchtigen Prüfer, der Ihr Update für ein ui "Problem" ablehnt, das in einer vorherigen Version der App vorhanden war. Nur eine Warnung, als wenn du versuchst, eine wichtige Lösung zu finden, es ist das Erschreckendste auf der Welt. schüttelt Faust bei Apple

Wie für die Leistung, ich hatte nicht klobige Scroll-Leistung auf Tabellen bis zu 900 Elemente. Dinge, auf die geachtet werden muss, wenn es klobig wird ... 1) Stellen Sie sicher, dass Sie den Wiederverwendungsidentifikator beim Entnehmen der Zellen korrekt verwenden. 2) Benutzerdefinierte Tabellenzellen mit komplexen Steuerelementen. (Wenn Sie Ihren Tabellenzellen eigene Untersichten hinzufügen müssen, sind UILabels am schnellsten, ohne Transparenz). 3) Vermeiden Sie Tabellenzellen mit nicht standardmäßiger Höhe (a.k.a. nicht 40). (ein anerkannter Apple-Performance-Fehler, obwohl ich dies nicht validiert habe, ist wirklich ein Problem.)

Answer 7

Die Hauptfrage, die Sie hier stellen müssen, ist "warum": Warum denken Sie, dass der Benutzer zu Artikel # 527 gehen möchte? Wie soll er auf Seite 6 wissen, was er will? Auf Seite 17?

Sie zeigen richtig, dass das Scrollen durch 1000 Elemente seltsam ist, aber Paging durch 1000 Elemente ist ebenso seltsam. Wahrscheinlich möchten Sie die Filter- oder Sortierfunktionen Ihrer Anwendung verbessern. Wenn Sie durch Tausende von Elementen blättern, ist das verrückt, es sei denn, Sie erwarten, dass der Benutzer sie lesen/scannen kann. In diesem Fall ist das Vorhandensein einer linearen Liste kein Problem.

UITableView hat auf der rechten Seite einen Abschnittsindex, der Ihr Problem je nach Kontext lösen kann.Es löst sicherlich das Problem für die Kontaktliste: selbst wenn Sie 2000 Kontakte haben, müssen Sie nur durch etwa 100 von ihnen scrollen, sobald Sie den Anfangsbuchstaben auswählen. (Die Leistung ist kein Problem, weil UITableView nie mehr Zeilen erstellt oder anfordert als das, was auf dem Bildschirm angezeigt wird.)

Endlich habe ich eine App verwendet, die eine ähnliche Paging + Tabellenansicht erstellt hat und die ich hasste Erfahrung. Es fühlt sich komplett nicht-iPhonish an.