Pull to refresh

Comments 12

Чего то я не понимаю, зачем в RV использовать адаптер, от которого бежали в привычном ListView?
Кстати, а почему никто не пишет? У нас проект достаточно крупный и много где используется именно ListView, а переходить на RV — довольно долго и пока первого вполне хватает

Мне тоже кажется, что RV всего лишь ListView, вывернутый на изнанку.
Те же адаптеры, те же вьюхолдеры и т.п.
Видимо, его решили сделать, чтобы спрятать вьюхолдеры подальше, и сделать их принудительными. Чтобы не отвечать всегда на вопрос «Зачем он нужен?» фразой типа «Иначе всё тормозит». Чтобы глаза не мозолило.
Да вот как-то честно не замечал особых тормозов при отрисовке ListView без ViewHolder'а. Конечно, данные я заранее готовлю и из массива беру объект со всеми подготовленными полями
Ну там самое медленное место это findViewById(). Но, мне кажется, если вью айтема простое, то и поиск будет быстрым :)
ну если там 200 TextView в каждом item'е, то конечно долго будет :)

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

Спасибо за статью! Последовательно и разумно-подробно.


Я как раз Kotlin изучаю, и планирую в частности что-нибудь для Android сделать.


Методики решения задач всегда полезны — для формирования навыка самостоятельного решения.

Спасибо за статью, довольно интересный подход, но вот создавать список для настроек…
Я такое встречал (до сих пор вздрагиваю, если честно), т.е. мы имеем статический лэйаут, который никогда не будет меняться (а только наполняться при создании), но пишем на него динамический компонент, с его анимацией(если потянуть список вниз, находясь в начале списка, например), обработкой каждого айтема как части списка (хотя там по сути просто вьюха для текста, вьюха для переключателя или текста и все) и вот этим вот всем?
Хорошо, даже если его иногда надо менять, скажем обновить одно значение, для этого перерисовывать весь список или одну ячейку, а если асинхронно мы точно помним какую ячейку, а не повернет ли пользователь экран?
В чем преимущество перед, скажем обычным вертикальным «LinearLayout» и addView() для каждого компонента, раз уж вы хотите динамическое его создание?
На каждый экран нужен еще и адаптер с обработчиком по типу элемента, а не создаете ли вы этим проблему решая свою проблему?
Скажем появится элемент «О пользователе» сверху, «Обратиться в поддержку» снизу, группировка по категориям, пара кастомных вьюх? А еще 5-8 экранов настроек (и это не прям чтобы редкость на самом деле) и для каждого будет сам экаран и класс адаптера…
Спасибо за отзыв.
PreferenceFragment, стандартное решение от гуглов, точно также анимирован по свайпу — что в этом такого? Экран использован как пример, потому что часто встречаются элементы не просто с заголовками, а какие то из них интерактивны, требуют разных обработок — свитч, всплывающие окна, переходы на новые экраны. Все это обрабатывается в Rv, на мой взгляд, быстро и без проблем. Плюс, дает вам возможность быстро переиспользовать тот элемент, который вы реализовали. Датабайдинг упрощает эту возможность.
Не волнуйтесь особо за перерисовку экрана. Устройства на нашем веку уже вполне могут быстро перерисовать список. По крайней мере для фрагмента с найстройками. =) А преждевременная оптимизация — это зло (с).
Да собственно можно и LinearLayout использовать, но что если у вас количество элементов зайдет за рамки экрана? Будете ставить ScrollView? Rv обеспечит вам прокрутку, поэтому даже в стандартном PreferenceFragment она сразу же заложена. Насчет обработчиков по типу элементов — при инициализации Item вы можете указать разные callbacks, пример в этой статье на элементе со свитчем.
Ответом на последний абзац будет — можно использовать DataBinding, чтобы уйти от разных адаптеров. Да это возможно и без него! В разделе ссылок есть доклад от Lisa Wray, там есть об этом. Посмотрите обязательно!
Не волнуйтесь особо за перерисовку экрана. Устройства на нашем веку уже вполне могут быстро перерисовать список. По крайней мере для фрагмента с найстройками. =) А преждевременная оптимизация — это зло (с).

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

Да собственно можно и LinearLayout использовать, но что если у вас количество элементов зайдет за рамки экрана? Будете ставить ScrollView?

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

Насчет обработчиков по типу элементов — при инициализации Item вы можете указать разные callbacks, пример в этой статье на элементе со свитчем.

По поводу обработчиков по типу элемента — вам понадобится обработчик для каждого типа, и я это реализовывал именно LinearLayout-ом и именно «addView(view, clicklistener), addSwitch(switch, onCheckListener) и т.д.» при этом сделав такой относительно маленький абстрактный класс в 200 строк, я очень легко распространил его на остальные 23 экрана настроек… с Вашим подходом классов было бы в 2 раза больше, ну и я в каждом экране сразу вижу колбеки и вьюхи по мере добавления, а не иду в адаптер, но тут может у меня особый случай приложения.
За датабайдинг спасибо, посмотрю…

Дело не в том чтобы отказываться от свистелок в виде прокрутки и этой анимации в пользу «топорного» варианта, а в том чтобы использовать инструмент по назначению, RV очень красиво умеет прокручивать ленту с 4-5 типами элементов, добавлять с анимацией, удалять, сдвигать, при этом в горизонтальной и вертикальной ориентации списка, реализовать с его помощью настройки — именно микроскопом гвозди забивать (мое имхо конечно же)…

А решение от гугла как раз заточено под то чтобы привязать сразу настройки к файлу по типу SharedPreferences, плюс реально добавить минимальный необходимый функционал ака категории и компоненты…
«The fragment implementation itself simply populates the preferences when created. Note that the preferences framework takes care of loading the current values out of the app preferences and writing them when changed»

protected val items: ArrayList = ArrayList()
protected val items: List = mutableListOf<>()
Это же Kotlin

override fun addAtPosition(pos: Int, newItem: IBaseListItem) {
items.add(pos, newItem)
notifyItemChanged(pos)
}
По мне data binding адское зло…
Можно всегда поправить мою реализацию в темплейте. ) Согласен, местами можно сделать более продумано. Если честно, у меня в разных проектах везде что-то меняется, то я открываю items, то делаю их приватными и доступными только по геттеру и сеттеру. protected тоже раньше ставил, тут в примере забил.
Дело не в реализациях, а в общем подходе. Единая реализация важна, если у вас команда и есть какие то общие рекомендации и гайдстайлы.
А почему data binding адское зло? Хотелось бы послушать развернутый ответ. Она много кому не нравится, но объяснить не могут позицию. Часто люди пробовали ее сырой, в то время как гуглы потихоньку делают ее лучше.
Sign up to leave a comment.

Articles