Как бы вы реализовали UITableView, который обнаруживает горизонтальные пролистывания, чтобы разрешить подкачку?

Question

Я хотел бы реализовать UITableView, который отображает, скажем, 20 строк одновременно. Но, учитывая тот факт, что я мог бы сказать, скажем, 120 предметов, я бы хотел справиться с этим с помощью некоторого подкачки:

Заполните таблицу первыми 20 пунктами. Когда пользователь делает пролистывание справа налево, перезагрузите UITableView со следующими 20 элементами. Слева направо будет отображать предыдущие 20 пунктов.

Я думаю, что подклассификация UITableView и обработка UITouches есть путь, но я не уверен, как правильно обрабатывать касания, чтобы не мешать стандартной обработке событий.

Например. если пользователь просто касается (щелкает) строку, я хочу, чтобы она была выделена (выделена), а затем переключена на подробный вид, представляющий данные, соответствующие выбранной строке. Но если пользователь делает горизонтальное свипирование, я не хочу, чтобы строка под свайпом была подсвечена (и, следовательно, выбрана), вместо этого я хочу вызвать обработку моей страницы, предшествующей загрузке / загрузки, которая перезагрузит таблицу с соответствующей 20 предыдущих или следующих пунктов, в зависимости от направления пролистывания.

Есть предложения?

Answer 1

Горизонтальное пролистывание строки таблицы уже является стандартным поведением пользовательского интерфейса, которое приводит к удалению этой строки. Не изменяйте стандартные парадигмы пользовательского интерфейса - это сбивает с толку пользователей и заставляет их не любить ваше приложение.

Answer 2

Основной вопрос, который нужно задать здесь: «почему»: как вы думаете, почему пользователь захочет перейти к пункту № 527? Как он узнает, что предмет, который он хочет, находится на странице 6? На странице 17?

Вы правильно указываете, что прокрутка 1000 элементов - это странно, но листание 1000 элементов - тоже странно. Возможно, вы хотите улучшить возможности фильтрации или сортировки вашего приложения. Прокрутка тысяч элементов безумна, если только вы не ожидаете, что пользователь прочитает / отсканирует каждый элемент, и в этом случае наличие линейного списка не является проблемой.

UITableView имеет индекс раздела справа, который может решить вашу проблему в зависимости от контекста. Это определенно решает проблему со списком контактов: даже если у вас 2000 контактов, вам нужно прокрутить около 100 из них, как только вы выберете начальную букву. (Производительность не является проблемой, поскольку UITableView никогда не создает и не запрашивает больше строк, чем видно на экране.)

Наконец, я использовал одно приложение с аналогичным представлением страниц + таблиц, и я ненавидел этот опыт. Он чувствует себя совершенно не iPhonish.

Answer 3

Как насчет использования индекса раздела UITableView в качестве альтернативы?

Переопределите следующее:

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

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

Это даст вам указатель в правой части таблицы, который позволит пользователям быстро перейти к нижней части таблицы (если вы не понимаете, что я имею в виду, обратитесь к приложению iPod, если вы не понимаете, о чем я). Также необходимо включить каждый раздел в индекс, чтобы избежать перегрузки сотнями разделов.

Я использую символ степени для моего индекса, так как разделы моей таблицы не алфавитные.

Если вспомогательная структура данных по-прежнему представляет собой один большой список, вам необходимо разбить его на разделы. (Вам не нужно показывать заголовок для разделов, чтобы он мог выглядеть идентично существующей таблице)

Что касается отклонения от стандартного поведения пользовательского интерфейса ... иногда, пытаясь выпустить обновление приложения, вы можете получить странного рецензента, который отклонит ваше обновление для "проблемы" пользовательского интерфейса, которая присутствовала в предыдущей версии приложения. , Просто предупреждение, потому что, когда вы пытаетесь найти важное решение, это самая ужасная вещь в мире. трясет кулаком в Apple

Что касается производительности, у меня была не короткая производительность прокрутки на столах до 900 элементов. На что нужно обратить внимание, если оно станет коротким ... 1) Убедитесь, что вы правильно используете идентификатор повторного использования при удалении из ячеек. 2) Пользовательские ячейки таблицы со сложными элементами управления. (Если вам нужно добавить свои собственные подвиды в ячейки таблицы, UILabels работают быстрее, без прозрачности) 3) Избегайте ячеек таблицы нестандартной высоты (например, не 40). (признанная ошибка производительности Apple, хотя я не проверял это действительно проблема.)

Answer 4

Это довольно нестандартная парадигма пользовательского интерфейса. Конечно, вы бы прокручивали вверх / вниз 120 пунктов, как, скажем, приложение «Контакты». Вы усложняете себе жизнь - и вы серьезно рискуете отклонить это приложение от Apple из-за странного пользовательского интерфейса.

Фактический метод, с помощью которого вы бы это реализовали, описан в http://forums.macrumors.com/showthread.php?t=532573

Я прочитал код там, и он выглядит разумным, хотя мне кажется, что вам также может понадобиться обработать touchUpInside, а не вызывать [super touchUpInside], чтобы избежать выбора ячейки при горизонтальном пролистывании.

Answer 5

Я на самом деле написал код, упомянутый Airsource Ltd на http://forums.macrumors.com/showthread.php?t=532573,, поэтому указание мне на мой собственный код не сильно помогло, во всяком случае, моя вина, но эй, кто не использует разные имена экранов на разных форумы? ; -)

В любом случае, он был одобрен после отправки в магазин приложений, и ИМХО, это очень полезно при работе с длинными списками. Пейджинг - это то, что обычно используется в Интернете, и я не хотел бы заставлять пользователя прокручивать список вверх / вверх с 500+ (я сказал 500+? Что насчет 1000+?) Строк.

Я согласен, что горизонтальное перелистывание в списке должно / позволит пользователю удалять / редактировать строки в качестве поведения по умолчанию. Но разве это не зависит от контекста?

Если я, как пользователь, являюсь «владельцем» данных, я могу ожидать удаления строк. Но ожидаю ли я, что смогу удалять строки в списке приложений в AppStore или в списке книг в приложении Amazon?

Горизонтальное пролистывание списка - это просто жест, в зависимости от контекста, он должен делать то, что ожидает пользователь.

Учитывая сценарий списка с 500+ строками, что бы вы сделали? Показать первые 25 строк с нижним колонтитулом «Покажи мне больше»? -> тогда у тебя будет 50 рядов? и так далее? в итоге у вас будет 527 строк? Если вы не будете хардкорно рисовать свою клетку, стол тоже будет нестабильным. Но даже при плавной прокрутке это не решит проблему прокрутки вверх / вниз на 2000 миль пикселей.

Или поместить верхний / нижний колонтитул с кнопками «Предыдущая страница / Следующая страница» - таким образом отображаются только 25 строк одновременно? Затем вы заставляете пользователя прокручиваться вверх или вниз, чтобы перейти на предыдущую или следующую страницу ....

Я открыт для любых предложений. Для меня это выглядит как естественный жест - провести пальцем влево или вправо по чему-то, у чего есть что-то «предыдущее / следующее».

Answer 6

Если бы я действительно хотел это сделать, я бы создал подкласс UITableView и добавил бы несколько его копий в UIScrollView. Распутывать события было бы ужасно, и я не думаю, что пользовательский интерфейс стоил бы усилий.

Answer 7

Просто вызовите там метод отмены касания, чтобы проверить, происходит ли считывание, но не с точками касания. Затем выполните свою функцию