Pull to refresh что это
Обновление страницы Pull-to-Refresh
В стремлении сделать этот компонент интересным и увлекательным мы начали с того, что сделали привязку вращения иконки со стрелкой к тому, насколько далеко вниз можно оттянуть контент, отображаемый на экране. Это было забавно. Бен и я целых десять минут водили пальцами по экрану. Мы быстро поняли, в чем проблема. Все было здорово, но не практично.
Большинство пользователей не сидят и не забавляются анимацией, сопровождающей pull-to-refresh, уткнувшись в свои смартфоны. Они «пользуются» смартфонами. Для них pull-to-refresh служит способом получения информации, которая им нужна, и нужна прямо сейчас. Это означает, что они делают быстрый свайп вниз и ждут, что pull-to-refresh тут же запустит процесс обновления информации. Свайп бывает таким быстрым, что никакой анимации и не происходит.
Мы вернулись обратно к обычной, фиксированной по времени анимации, обновили дефолтные иконки на более красивые и продолжили работу.
Следующее, что мы заметили, это то, что большинство вызовов API работают быстро, даже слишком быстро. Наш «рефрешер» возвращается в позицию «home» сразу же, как только до него доходит сигнал о том, что запрошенная информация уже получена. Нужно было бы, чтобы рефрешер прекратил свое действие сразу же после свайпа вверх. Однако вместо этого он моментально возвращается «домой». Для тестирования функции обновления данных у нас было приложение Hacker News (мы скоро напишем об этом поподробнее). Первая страница Hacker News не обновляется каждые пять секунд, а с помощью «refresh» мы ничего добиться не смогли. Поэтому остались в недоумении, подумали, что апдейт информации перестал функционировать вообще.
Чтобы убедиться в том, что все работает, нам пришлось проверить протоколы. Конечно, это могут сделать только разработчики, а пользователям такой метод недоступен. Поэтому возможность получать подтверждение о том, что обновление данных происходит должна присутствовать на уровне UI.
Мы решили пересмотреть параметры анимации вращения иконки обновления данных, задав для нее значение длительности 400 мс. Если данные обновлялись и поступали бы на экран быстрее, то иконка все равно бы оставалась видимой и вращалась бы. Так пользователь бы точно знал о том, что процесс обновления идет нормально. Ну, а у разработчика в связи с этим может появиться вопрос. Если обновление данных уже произошло, зачем нужно продолжать показывать анимацию?
Я думаю, вы согласитесь с тем, что в таком виде пользоваться «pull-to-refresh» гораздо приятнее и понятнее. На самом деле мне понравился процесс критической оценки ситуации и корректировки поведения этого одного компонента. Это тот стандарт, которого мы пытаемся придерживаться, чем я очень горд. К каждой новой функции Ionic мы относимся с большим вниманием.
Посмотреть то, что мы сделали, можно на хостинге IT-проектов GitHub.
Выбор Pull To Refresh инструмента
100; подгрузка элементов по требованию; набор списков располагается в самописном компоненте, аля ViewPager) это действительно оказалось проблематично. О всех моих изысканиях в данном направлении читайте под катом.
Pull To Refresh — фишка, насколько мне известно, перекочевавшая на Android из iPhone’а. Удобный способ обновления списка.
Рассмотрим его на примере нашего новостного приложения (в него-то собственно и возникла необходимость внедрить эту фичу): есть список новостей, который обновляется через новостной сервер. Обновление ручное, так что внизу торчит кнопочка «Обновить», которая занимает некоторое место на экране. А зачем тратить драгоценное экранное пространство на кнопочку, которая не так уж и часто используется, если можно вопользоваться приемом Pull To Refresh: находясь вверху списка потяните список вниз, а затем отпустите, чтобы список обновился. Новые новости (каламбурчик) подгрузятся и отобразятся. Выглядит это примерное так:
Идея довольно удачная, поэтому и используется во многих приложения, включая популярные Facebook и Twitter клиенты. Так вот и мы решили внедрить в свой новостной проект такую фишку.
Но зачем писать с нуля то, что уже есть в готовом виде? Быстрый поиск в Google, великий и могучий StackOverFlow — и вот найден самый популярный инструмент android-pulltorefresh от Йохана Нильсона. Взял последнюю версию с GitHub’а и заюзал у себя. Не тут-то было! Проект вроде бы уже почти год развивается, но… вот что Я вижу в случае малых списков:
И такой вопрос сразу возникает: WTF? Проект watch’ат 418 человек, аж 71 человек его форкнул, а тут такое каличное некорректное поведение. А все почему? Потому что вот этот вот «Tap to refresh. » — это header у ListView. И прячется он, в реализации от Йохана, банальным ListView.setSelection(1). А в случае коротких списков этот setSelection(1) вежливо посылает на фек не работает.
Но потом замечаю, что у проекта оказывается есть ещё два branch’а: enhancedpull (который уже был смержен с главным брэнчем) и, отоноче, scrollfix_for_short_list 🙂
Вытягиваю последнюю версию брэнча scrollfix_for_short_list, прикручиваю в проект: короткий список вроде выглядит нормально, только отчего ж у меня начал так тормозить UI? А дело вот в чем: список мой — не простой, а с подгрузкой по требованию (on-demand), т.е. саначала показываются первые 10 элементов, а если промотать до конца, то в список догружается следующая порция. А в чем же состоит fix для коротких списков по версии Йохана?
«А давайте добавим в footer ListView пустую вьюху ровно такой высоты, чтобы setSelection(1) снова смог нормально скрыть header», — сказал Йохан и приступил к вычилениям высоты footer’а. Чтобы вычислить его высоту надо знать суммарную высоту всех элементов в списке (кроме header’а конечно). Тогда мы отнимем эту высоту от высоты ListView и получим высоту для footer’а. А чтобы узнать высоту каждого элемента списка, откуда-то было взято «гениальное» решение перебрать с помощью адаптера все элементы (с помощью getView()) и каждому сделать measure(), т.е. по сути отрисовать их (даже если они невидимы). В результате мой список думал, что его все проматывают и проматывают — и все подгружал и подгружал новые порции до тех пор, пока элементы то и не закончатся. А элементов у меня обычно за 50 в списке, и списков несколько (пролистываются наподобие недавно появившегося ViewPager‘а). В общем вот такая реализация подсчета суммарной высоты элементов списка:
то здесь надо вручную создавать header, и по приходу событий менять текст в нем, ну и список конечно обновлять:
Не знаю, может это и более гибко, но… неудобно. К тому же оказалось, что данная реализация не очень корректно работает в Pager’е: стало возможно пролистывать список по вертикали и Pager по горизонтали одновременно.
В итоге со слезами на глазах Я стал ставить на костыли версию Йохана из брэнча scrollfix_for_short_list, чтобы она не заставляла списки подгружаться до бесконечности. Кое-как было сделано, но работало, мягко говоря, нестабильно. На горизонте замаячила перспектива писать компонент самому, и Я решил ещё раз пересерфить интренет. И, о чудо!, Я наткнулся на ещё одну реализацию — от Криса Бэйнса. Проект базировался на версии Йохана, но был с тех пор существенно улучшен (как пишет автор). Испытание подтвердило: данная реализация дествительно лишена всех багов, присущих версии Йохана, и выглядит более приятно (за счет дополнительной анимации).
Так вот, к чему Я тут так распространился? А все затем чтобы выдать мораль:
Если вы хотите использовать в своем проекте механизм Pull To Refresh — используйте реализацию от Криса Бэйнса. На мой взгляд, на данный момент это самая качественная реализация приема Pull To Refresh.
Функция «Pull To Refresh» в iOS принадлежит Twitter
Функция «потяните, чтобы обновить» знакома пользователям многих iOS-приложений, в том числе Twitter, Facebook, Tweetbot, Sparrow и других. И многим интересно, почему Apple не применила данную функцию в собственных приложениях, типа Safari или Mail, что улучшило бы удобство работы с ними.
Как оказалось, причина отсутствия функции в нативных Apple iOS приложениях может крыться в правах на использование патента под названием «Механика пользовательского интерфейса», автором которого является Лорен Бричтер (Loren Brichter), создатель Tweetie. Что такое Tweetie? Это приложение Twitter, созданное в 2010 году, которое позже стало официальным iOS Twitter клиентом.
Да, компания Twitter пыталась запатентовать технологию «потянуть, чтобы обновить» (pull to refresh). Но патент этим не ограничивается – он касается всего, что связано с командой «вытаскивания меню».
Подробную информацию о патентном приложении (20100199180 A1) разместил Дастин Кертис (Dustin Curtis) после разговора в сети Twitter с дизайнером Tapbots Марком Джардином (Mark Jardine) и разработчиком Полом Хаддадом (Paul Hadddad) – именно эта команда стоит за созданием одного из самых популярных сторонних клиентов Twitter под названием Tweetbot. Однако последние твиты Хаддада дали понять, что он не слишком обеспокоен ситуацией. Вот примерный перевод его слов:
«У каждой крупной софтверной компании есть кучи патентов, большинство из которых представляют сомнительную ценность. Многие из них используются в качестве оборонительных средств. Twitter является удивительно хорошим проектом с открытым исходным кодом, и патентные атаки с их стороны меня мало беспокоят».
Также надо отметить, что патент существует уже относительно давно – еще с 2010 года. Тем не менее, факт его существования для многих стал новостью – в частности, для Джона Грубера (John Gruber), чей блог под названием Daring Fireball очень подробно освещает все, что связано с Apple.
«Я не знал, что у Twitter есть патент на это»
Все отреагировали по-разному – Джереми Стэнли (Jeremy Stanley), в частности, отметил, что Apple использует запатентованную технологию «pull-to-refresh» в некоторых своих внутренних приложениях (в чем многие поспешили убедиться и согласиться).
Исходя из всего вышесказанного, на сегодня очень хорошей новостью то, что Twitter и Apple являются лучшими друзьями.
Новости, статьи и анонсы публикаций
Свободное общение и обсуждение материалов
Лонгриды для вас
iOS 15.1 beta 2 уже вышла. Она включает в себя два нововведения: поддержку QR-кодов вакцинации в Wallet и функцию SharePlay, которая позволяет смотреть через FaceTime фильмы и сериалы на Apple TV+, а также тренировки на Fitness+
Apple против подобных экспериментов, но оказывается, macOS Big Sur можно запустить на чем угодно. Один талантливый ютьюбер сделал это и подробно показал процесс создания своего необычного компьютера.
Если раньше многие пользователи хотели скопировать интерфейс iPhone на свое устройство, то сейчас все в корне наоборот. В статье рассказываем, как максимально приблизить iOS устройство к Android гаджетам.
Реализуем pull to refresh и infinite scrolling на Swift
Возьмём за основу статью Знакомьтесь, Swift!, где показано как сделать простое приложение на Swift, и добавим туда такие известные и полезные штуки как pull to refresh и infinite scrolling используя встроенные возможности языка. Чтобы было еще интереснее, добавим немного асинхронности, иначе приложение будет каждый раз замирать на время обновления.
Подготовка
За основу мы берём вышеозначенный пример, поэтому будем просто дополнять его. Для начала в класс контроллера добавим 2 переменные, которые будут отвечать за количество ячеек и за текст, отображаемый в ячейках
И модифицируем код генерации ячеек, используя эти переменные
Теперь сделаем привязку TableView к контроллеру, чтобы можно было производить над ней нужные нам манипуляции. В interface builder выбираем TableView, нажимаем cmd+alt+enter и правой кнопкой тянем в появившееся окно 
Вбиваем имя по которому будем обращаться 
Так же добавим в TableView компонент View, на котором разместим 2 элемента, чтобы получилось следующее 
Эта View нужна для того, чтобы отображать уведомление о том, что идет обновление, и нам нужно, чтобы она была видна только тогда, когда идет подгрузка новых данных (для этого будем использовать свойство tableFooterView.hidden), поэтому нужно ее скрыть вначале, и показать только потом. Так же нужно будет вручную запускать анимацию UIActivityIndicatorView, для этого, аналогично как и выше, добавим привязку 
Для предварительной подготовки этих действий будет достаточно.
Pull to refresh
Теперь можно перейти непосредственно к реализации pull to refresh. В класс контролера добавим новую переменную специального класса UIRefreshControl
В viewDidLoad добавим код, инициализирующую эту переменную и привязывающую ее к tableView
Теперь нам нужно определить функцию refresh, которая и будет вызываться каждый раз, при выполнении действия pull to refresh. Чтобы обновление происходило в асинхронном режиме, используем следующую схему (не буду вдаваться в описание подробностей, разобраться коде не трудно самостоятельно)
В итоге, получаем 
UPD: Если вы используете UITableViewController (а лучше использовать его в данном и аналогичных случаях), то код будет даже проще. В UITableViewController уже есть свойства tableView и refreshControl, поэтому не нужно делать привязку UITableView вручную и не надо в классе объявлять refreshControl. Достаточно написать в viewDidLoad следующий код и все будет работать
Infinite scrolling
С бесконечной прокруткой немного по сложнее, но не на много. В класс контролера добавим новую переменную loadMoreStatus, которая будет отвечать за защиту от повторного обновления, если оно уже запущено
В viewDidLoad добавим код, который первично скроет View с информацией о подгрузке новых данных
Добавим определение специальной функции scrollViewDidScroll, которая вызывается каждый раз, когда происходит любая прокрутка. Если мы доматываем до конца списка, то вызывается функция loadMore, которая реализует асинхронную подгрузку новых данных
В результате все работает, приложение не замирает, а данные добавляются успешно 
Вот таким нехитрым способом можно реализовать pull to refresh и infinite scrolling, и само собой, из-за асинхронного обновления, можно, например, делать запросы JSON к серверу простым синхронным способом и это не помешает работе приложения.
Работающий Pull to refresh
Это рассказ о том, как получилась работающая реализация Pull to refresh под Android. Совсем не будет примеров кода. Немного картинок и в конце статьи ссылка на архив проекта.
Недавно встала необходимость встроить в текущее приложение Pull to refresh. Это сейчас модно, пользователи привыкли, и для твиттер-клиентов уже стало стандартом. Поиск готовых решений в сети вывел на единственный вариант — open-source проект Johan Nilsson android-pulltorefresh на Github.
В ListView вставляется Header, который прячется при необходимости. Решение работающее, но очень криво. Часто подвисает в каком-либо состоянии. Если в списке мало элементов и они не занимают все пространство, отведенное для ListView, то Header не скрывается, а надпись изменяется на Tap to refresh. Логичное ограничение данной реализации. Еще одна особенность была обнаружена при добавлении этого проекта в рабочее приложение. Так как Pull to refresh — это Header, то часто выполняется метод setSelection(1), чтобы спрятать Header. А так как мы используем сохранение и восстановление позиции, то конечно постоянный вызов setSelection нам все портит.
Поначалу решили доработать эту реализацию, исправить самые неприятные моменты. Даже встроили в один проект. Но сделать так, как хочется, не получилось, сказались ограничения от использования Header’а.
Возникла идея, как сделать по-другому и появилось свободное время. Раз проблема в Header’е, значит, его нужно убрать и поместить сам Pull to refresh View и ListView в один LinearLayout и двигать его. В идеале хотелось получить такой же Pull to refresh как в официальном Twitter-клиенте. Но там используется другая связка. Pull to refresh там плавный и хорошо везде работающий. Вообще много времени провели, наблюдая за работой официального Twitter-клиента.
Вариантов что и как двигать много. Можно двигать и Pull to refresh View, и ListView, и LinearLayout. Можно двигать, изменяя Padding, Margin или ScrollTo. После большого количества экспериментов на эмуляторе и на реальных устройствах, была найдена наиболее оптимальная связка. Первоначальный сдвиг делается изменением Padding на высоту Pull to refresh View, таким образом, мы его прячем с экрана. А дальше двигаем весь Layout изменением ScrollTo.
Получилось красиво и максимально плавно. Но возникла проблема, на тот момент кажущаяся непреодолимой. Почему-то при сдвиге Layout все начинало прыгать. Приходили координаты то ниже, то выше, и никак не получалось исправить. Чуть даже не вернулись к первоначальному плану — доработать Pull to refresh от Johan Nilsson.
Но потом как по волшебству на глаза попал другой проект. Альтернативный Pull To Refresh от guillep на том же Github. Он еще ужаснее работает, чем у Johan Nilsson, но используется совсем другой механизм, похожий на нашу идею. И самое главное там обходится проблема с прыгающим Layout’ом. Берется три последних координаты и вычисляется средняя. Таким образом, обеспечивается плавность.
Мы взяли понемногу из каждого проекта, все объединили, и получился хорошо работающий Pull to refresh, но оставалось незаконченным состояние загрузки. После отпускания Release to refresh превращается в Loading и в таком состоянии оно должно скролиться вместе со списком, поэтому оно должно быть частью ListView. Отдельный Pull to refresh View должен исчезнуть, а в ListView должно добавиться Pull to refresh View в состоянии Loading.
Так как наше View должно постоянно то появляться, то исчезать в ListView, использовать его как Header нельзя. Но и изменять текущие адаптеры тоже не хочется. Необходимо, чтобы при добавлении Pull to refresh в рабочий проект, было как можно меньше изменений. Решили использовать специальный Adapter внутри Pull to refresh как Декоратор. И этот адаптер контролирует наличие специального View в состоянии Loading.
Было много проблем, особенно при добавлении в рабочий проект, но все они успешно решились. В конце концов, получился класс, которым можно заменять обычный ListView и в котором реализован хорошо работающий Pull to refresh. Он прекрасно работает на всех API, начиная с версии 1.5.
Только на некоторых устройствах Samsung с переделанным ListView наблюдаются иногда проблемы. Но уже есть идеи как и что можно переделать.