Алексей, спасибо за твой труд! Контент на канале - супер! Это видео автоматом добавляю в список, посмотрю позже. Потому что даже не сомневаюсь в огромной пользе информации. Которой, к тому же, у тебя получается очень качественно делиться. Здорово, что есть такие люди, как ты :)
Все отлично сказано и по делу. В 199% случаях на ютубе и во всех самопальных передают список и контекст прямо в адаптер. Что можно добавить что вся эта радость быстро плодиться и , как было сказано в видео сильно разветвляется. Появляются куча реализаций и вариаций на тему. Хороший есть гайдлайн от гугла на Codelab с футерами, хэдерами, кликами diffUtills и прочим
Первый русский ролик на Ютубе, посвященный RecyclerView на Kotlin, так ещё и очень крутой. Спасибо большое. Будет ли продолжение по recyclerView?(Например, разбор клика на элемент)
Алексей, как всегда годный контент... Спасибо за труды! Я не совсем понял про ДЗ, что именно нужно сделать. Было бы здорово, если бы вы добавили описание! Еще раз СПАСИБО за годный контент.
Спасибо за видос. Со списками хорошо(наверное) знаком, потому смотрел в перемотках, возникло пару вопросов\замечаний: 1. Было ли упоминание про подход с DiffUtil? различные нотифай методы это, конечно, хорошо, но так сейчас почти никто не делает, вышеупомянутый подход через дифутил уже стал де-факто стандартом. 2. будут ли еще видео про списки\ресайклер? Как по мне, тема раскрыта не полностью, как минимум, не затронули "пагинацию", которая является неотъемлемой частью любого современного проекта. Щупали ли гугловскую либу для пагинации? какие впечатления? 3. Были ли в вашей практике кейсы, когда нужно было тянуть архитектуру в адаптер\итемы (презентер/вьюМодель и т.д. под каждий итем), как решали подобное и какие отзывы? 4. По поводу колбека - это нарушение "интерфейс сегрегейшина" из СОЛИДа, лонг тап довольно редкий кейс, а дефолтные методы это скорее глушение последствия, а не лечение причины. Имхо там должно быть два самостоятельных колбека. 5. Так же из интересных кейсов - раскрывающийся(expandable) контент в итемах, сталкивались ли и как решали? В принципе еще можно накинуть про АйтемДекораторы и ЛейаутМенеджеры, но думаю итак уже много настрочил.
Привет ) вот так снимаешь видос на час, а тебе говорят мало контента 😆😆 так теперь по существу: 1. Нет про DiffUtils не было, будет в отдельном видео, я там косвенно это упомянул. Diffutils хорошо юзать все в тех же лентах, для списков попроще переопределять отдельный класс я не вижу смысла там и notifydatasetchanged достаточно. 2. Да будут. Пагинация по сути не имеет отношения к самому recycler это скорее архитектурная проблема как это правильно организовать. Про либу честно скажу я ее сам ещё не юзал, но в планах есть разобраться. На картинке выглядит хорошо, в реальности я уверен не все так прекрасно. 3. Насчёт тянуть презентеры и иже с ними я уже говорил в видео - считаю, что адаптер должен бать чистым, поэтому все обрабатываю снаружи. 4. А обработка кликов внутри адаптера это нарушение принципов единой ответственности. Тут, к сожалению, нет серебряной пули имхо, потому что по нажатию, например если у вас чекбоксы и вас надо подсветить кнопку на форме как вы это отработаете внутри адаптера? Потянете ссылку на фрагмент? Или на специфичный интерфейс? Лучше уж клики вынести наружу, в принципе, это тоже самое что онклик на кнопке. 5. Насчёт списков раскрывающихся да делал, интересная тема сниму отдельное видео. Про декораторы и так далее тоже в принципе интересно, но это на сладкое грубоват говоря, сейчас ждут более интересные темы.
Это инструмент в целом да для серьезных списков решение хорошее, но я объясню, что в этом видео моя задача была дать основу, если бы я начал объяснять сразу про подход с DiffUtils, то человек не понял бы чего там работает под капотом. Про него и про payload будет отдельное видео
В некоторых приложениях, использующих recyclerview, есть баг- если быстро листать, могу заново появиться элементы, которые пролистал какое то время назад)) Не люблю recyclerview и по возможности стараюсь использовать классическую навигацию 1-2-...-9-10-11-...-24-25 с 10 элементами на страницу, потому что она более наглядная и позволяет лучше ориентироваться в большом количестве элементов. Конечно без recyclerview всяким фейсбукам на обойтись. Еще прикольная тема- recyclerview с нумерацией элементов и быстрой навигацией.
Любой софт багованный :) По определению просто )) Да многие баги и недоработки приложений можно скрыть хорошим UX. Но, к сожалению, UX дизайнеры тоже люди :)))
такой вопрос возник: вы реализовывали свой DotsPagerIndicator или CirclePagerIndicator (кругляшки, точки внизу фотографий обычно бывают, количество элементов показывают), по-разному называют? Если делали, то с помощью чего? Есть ViewPager и либа CirclePagerIndicator к нему, последний от Jake Wharton, оба устарели. В феврале появился новый ViewPager2, внутри него есть RecyclerView, в отличие от старого VP для него адаптер можно писать в стиле RecyclerView. Пока никто не написал либы типа CirclePagerIndicator для VP2
мне кажется, один RV может заменить VP, к RV можно применять свякие PagerSnapHelper, LinearSnaphelper и т.д. new PagerSnapHelper().attachToRecyclerView(rv);
Алексей, расскажите ваше мнение по поводу custom view. Пользуетесь ли вы этим, нужно но ли вообще это уметь и может тоже подскажите какие то фишки в этом деле. Очень мало информации/туториалов по этой теме и все на какие то очень базовые вещи.
CustomVIew иногда бывает очень полезным особенно когда вы делаете какие-то компоненты, которые нельзя просто так собрать из стандартного набора android view, поэтому да навык очень нужный и часто востребованный. Насчет фишек. У меня на канале есть раздел сообщество там я где-то выкладывал анонс GDG+Revolut. Так вот первый доклад как раз был про custom view
@@MobileDeveloper Алексей спасибо за ответ, если что вот мой первый custom view - TextView со встроенным шрифтом fontawesome, может пригодится) github.com/bios90/faw_text_view
Добрый день, подскажите? а исходника данного урока нет? только начал учить котлин и различные архитектуры, немного не понимаю, как правильно реализовывать сейчас тот же recyclerview и moxy
Привет, подскажи пожалуйста где искать первую работу, я только на HH смотрю, но выбор ну очень мал, на страну менее 100 объявлений без опыта и на нативных языках, ещё у трети написано необходимость высшего образования, по итогу выбора почти и нет
Пробовать себя в стартапах, писать свои проекты, потому что во многие компании требуется человек который умеет решать задачи. Если вы сделаете пару своих аппов, пусть неумелых, то у вас уже будет какой никакой релевантный опыт.
Еще добавлю, что хороший способ объединяться в мелкие команды для проектов. Возьмите пример с Англии 80х, когда там зародили почти все современные звезды и рок группы. Люди объединялись учились играть и делали великие группы. Дерзайте, на этом канале куча людей вы можете кооперироваться.
Есть вопрос: какие либы в Flutter принято использовать для работы с сетью, бд, DI, RxJava, видел, там тоже есть retrofit/room, стоит ли их там использовать или есть что получше?
Большое спасибо за видео! В последнем рабочем проекте было куча списков различных данных, но отображаемых в одном стиле. И пришла мысль привязывать адаптеры не к самим данным, а стилю отображения. То есть, каждый адаптер хранит список неких интерфейсов, в которых описаны методы для заполнения холдера. И после этого список любых моделей можем отображать через этот адаптер, просто написав имплементацию этого интерфейса для модели. Скажите, пожалуйста, как вам такой подход?
Присоединяюсь к вопросу Alex ) могли бы вы скинуть ссылку на реализацию? Данные редко когда отображаются идентично, а это значит, что придётся кучу условий делать для каждого конкретного случая, интерфейсы будут примерно одинаковые разве нет? Мне нравится подход с AdapterDelegate, но я про него недавно услышал на конференции, поэтому пока не использую
@@MobileDeveloper Посмотрел, классная штука, только возникла проблема, если передавать адаптеру не полностью новый список через setData(), а ,например, обновить какой-то элемент через UpdateRow(), то изменения становится видно только после скрола списка туда и обратно, я слышал это вроде называется проблемой иммутабельности списка
Я бы это выносил в некий интерфейс наружу. Потому что очень часто нажатия сопровождаются серьезной логикой. Имхо обрабатывать их надо во фрагменте, а дальше передавать уже или презентеру или ViewModel или роутеру ну и так далее
Хотел у вас спросить. Есть адаптер, который может делать базовую логику (например, писать TextView в строку). Я хочу преобразовать его в open class и сделать наследника, который выводил бы в строке два TextView. Если первый был бы абстрактным, делается без проблем. Однако пока он open, возникает конфликт с onBindViewHolder, поскольку в нём в классе-наследнике входной параметр - viewHolder базового класса. Как сделать наследование адаптеров?
Боюсь это не совсем правильный подход в целом ) лучше настроить абстрактный адаптер с sealed classes и просто в конкретном onbindviewholder подменять на нужный viewholder
@@MobileDeveloper Ну не знаю. Мне интересно, если адаптеры нельзя наследовать (без abstract), соблюдается ли ООП. Sealed class ограничивает кол-во потомков, здесь, наоборот, удобнее делать множество потомков любых модификаций.
@@MobileDeveloper Не уверен, что это бессмысленно. Предположим, что у меня есть список с картинками. От него мне надо создать ещё несколько адаптеров, в которых будут картинки с текстом. Думаю, что наследование адаптеров здесь помогло бы сократить кол-во кода. Туда можно было бы вписать все общие методы и определить базовый ViewHolder.
Забавно недавно о похожем спорили в офисе. Дело в том что Гугл уже вынес все похожее в базовый класс и оставил только те вещи которые отличаются. Соответственно если у вас была картинка а стала картинка с текстом это разные xml и соответственно разные модели и viewholder. В чем здесь профит именно наследования а не просто написания в одном адаптере двух разных вьюхолдеров а унаследовать можно модели данных ) ну вернее сделать все тот же sealed class
Printerest кстати самое тормозное приложение какое я только видел.с производительностью там полная шляпа.не всегда красивый дизайн способствует привлечению пользователей.через неделю был благополучно удалён как раз из за тормозов
Ну ) как всегда вопрос идеи и реализации ) но я бы поспорил, что не всегда дизайн способствует) привлечению всегда или почти всегда, а дальше включается уже фактор удержания ) а вот здесь дизайн далеко не самую главную роль выполняет. Встречают, как говорится, по одежке, а дальше вы и сами знаете )
Ну камон, про итем апдейтед, ремувед, инсертед рассказывал 15 минут, а про DiffUtil ни слова не сказал. Отмазка что эта штука не нужна для базовой работы со списками не принимается.
А можно я сам буду решать как снимать видео? В другом ответе я уже объяснял, что задача была дать основы работы с компонентом, если вы посмотрите мои другие видео, я везде начинаю с самых самых основ и иду от простого к сложному
Тут разные способы. Во-первых можно в модельку положить типа класс, ну что-то вроде SomeActivity::class.java. И потом переходить к ней по нажатию, можно по айди делать when и делать переходы. А скорее всего вам нужны не разные активити, а одна просто с разными входными параметрами. Это другая история
@@MobileDeveloper получается сделать toast на каждый айтем, но вот активити открыть никак через when пробовал Я бы мог скинуть проект, может сможете подсказать, готов на платной основе Уже 2 недели мучаюсь
![UI/UX - RecyclerView. Часть 2. Clicks, DiffUtils. [RU, Android] / Мобильный разработчик](http://i.ytimg.com/vi/zqTbV79WOSY/mqdefault.jpg)
![UI/UX - RecyclerView. Часть 2. Clicks, DiffUtils. [RU, Android] / Мобильный разработчик](/img/tr.png)
![Многопоточность. Часть 1. Процесс и поток [RU, Android] / Мобильный разработчик](http://i.ytimg.com/vi/pyshhQpCezo/mqdefault.jpg)
![Фишки #3 - Sealed Classes [RU, Android] / Мобильный разработчик](http://i.ytimg.com/vi/d7-YDQfAulg/mqdefault.jpg)
![[Live] : ONE 169 วันนี้!! "อนาโตลี vs อูมาร์"](http://i.ytimg.com/vi/IK3YZVWuFJg/mqdefault.jpg)
![Фишки #0 - Как передавать данные между Activity и Fragment [RU, Android] / Мобильный разработчик](/img/n.gif)
Алексей, спасибо за твой труд! Контент на канале - супер! Это видео автоматом добавляю в список, посмотрю позже. Потому что даже не сомневаюсь в огромной пользе информации. Которой, к тому же, у тебя получается очень качественно делиться. Здорово, что есть такие люди, как ты :)
Спасибо большое вам правда )) Очень приятно)
Все отлично сказано и по делу. В 199% случаях на ютубе и во всех самопальных передают список и контекст прямо в адаптер. Что можно добавить что вся эта радость быстро плодиться и , как было сказано в видео сильно разветвляется. Появляются куча реализаций и вариаций на тему. Хороший есть гайдлайн от гугла на Codelab с футерами, хэдерами, кликами diffUtills и прочим
Спасибо!)
Алексей, спасибо огромное за твой контент! Очень жду новых видосиков по Swift
Пожалуйста ) да есть такое в планах )
Манера изложения, на мой взгляд, идеальна, спасибо автору за труды!
Спасибо большое )))
Первый русский ролик на Ютубе, посвященный RecyclerView на Kotlin, так ещё и очень крутой. Спасибо большое. Будет ли продолжение по recyclerView?(Например, разбор клика на элемент)
Привет ) спасибо ) да будет ещё второе видео - DiffUtil и клики
Алексей, как всегда годный контент... Спасибо за труды! Я не совсем понял про ДЗ, что именно нужно сделать. Было бы здорово, если бы вы добавили описание! Еще раз СПАСИБО за годный контент.
Пожалуйста ) рад, что помогаю ) насчёт дз давайте конкретнее ибо я вроде все в видео объяснил
Спасибо за видос. Со списками хорошо(наверное) знаком, потому смотрел в перемотках, возникло пару вопросов\замечаний: 1. Было ли упоминание про подход с DiffUtil? различные нотифай методы это, конечно, хорошо, но так сейчас почти никто не делает, вышеупомянутый подход через дифутил уже стал де-факто стандартом. 2. будут ли еще видео про списки\ресайклер? Как по мне, тема раскрыта не полностью, как минимум, не затронули "пагинацию", которая является неотъемлемой частью любого современного проекта. Щупали ли гугловскую либу для пагинации? какие впечатления? 3. Были ли в вашей практике кейсы, когда нужно было тянуть архитектуру в адаптер\итемы (презентер/вьюМодель и т.д. под каждий итем), как решали подобное и какие отзывы? 4. По поводу колбека - это нарушение "интерфейс сегрегейшина" из СОЛИДа, лонг тап довольно редкий кейс, а дефолтные методы это скорее глушение последствия, а не лечение причины. Имхо там должно быть два самостоятельных колбека. 5. Так же из интересных кейсов - раскрывающийся(expandable) контент в итемах, сталкивались ли и как решали? В принципе еще можно накинуть про АйтемДекораторы и ЛейаутМенеджеры, но думаю итак уже много настрочил.
Хотел тоже про DiffUtil спросить, так как использую его и до этого видео считал, что это единственное и правильное решение.
тоже хотел узнать, практично ли передавать презентер в адаптер, или все-таки колбек вьюхи передать, а в нем вызвать метод презентера?
Привет ) вот так снимаешь видос на час, а тебе говорят мало контента 😆😆 так теперь по существу:
1. Нет про DiffUtils не было, будет в отдельном видео, я там косвенно это упомянул. Diffutils хорошо юзать все в тех же лентах, для списков попроще переопределять отдельный класс я не вижу смысла там и notifydatasetchanged достаточно.
2. Да будут. Пагинация по сути не имеет отношения к самому recycler это скорее архитектурная проблема как это правильно организовать. Про либу честно скажу я ее сам ещё не юзал, но в планах есть разобраться. На картинке выглядит хорошо, в реальности я уверен не все так прекрасно.
3. Насчёт тянуть презентеры и иже с ними я уже говорил в видео - считаю, что адаптер должен бать чистым, поэтому все обрабатываю снаружи.
4. А обработка кликов внутри адаптера это нарушение принципов единой ответственности. Тут, к сожалению, нет серебряной пули имхо, потому что по нажатию, например если у вас чекбоксы и вас надо подсветить кнопку на форме как вы это отработаете внутри адаптера? Потянете ссылку на фрагмент? Или на специфичный интерфейс? Лучше уж клики вынести наружу, в принципе, это тоже самое что онклик на кнопке.
5. Насчёт списков раскрывающихся да делал, интересная тема сниму отдельное видео. Про декораторы и так далее тоже в принципе интересно, но это на сладкое грубоват говоря, сейчас ждут более интересные темы.
Это инструмент в целом да для серьезных списков решение хорошее, но я объясню, что в этом видео моя задача была дать основу, если бы я начал объяснять сразу про подход с DiffUtils, то человек не понял бы чего там работает под капотом. Про него и про payload будет отдельное видео
Лучше имхо выносить наружу actions и разруливать их во вью
В некоторых приложениях, использующих recyclerview, есть баг- если быстро листать, могу заново появиться элементы, которые пролистал какое то время назад))
Не люблю recyclerview и по возможности стараюсь использовать классическую навигацию 1-2-...-9-10-11-...-24-25 с 10 элементами на страницу, потому что она более наглядная и позволяет лучше ориентироваться в большом количестве элементов.
Конечно без recyclerview всяким фейсбукам на обойтись.
Еще прикольная тема- recyclerview с нумерацией элементов и быстрой навигацией.
Любой софт багованный :) По определению просто )) Да многие баги и недоработки приложений можно скрыть хорошим UX. Но, к сожалению, UX дизайнеры тоже люди :)))
такой вопрос возник: вы реализовывали свой DotsPagerIndicator или CirclePagerIndicator (кругляшки, точки внизу фотографий обычно бывают, количество элементов показывают), по-разному называют? Если делали, то с помощью чего? Есть ViewPager и либа CirclePagerIndicator к нему, последний от Jake Wharton, оба устарели. В феврале появился новый ViewPager2, внутри него есть RecyclerView, в отличие от старого VP для него адаптер можно писать в стиле RecyclerView. Пока никто не написал либы типа CirclePagerIndicator для VP2
мне кажется, один RV может заменить VP, к RV можно применять свякие PagerSnapHelper, LinearSnaphelper и т.д.
new PagerSnapHelper().attachToRecyclerView(rv);
Про VP2 интересная статья habr.com/ru/company/surfstudio/blog/461873/
Интересный вопрос ) я по моему обычно какую-то стороннюю либу юзал ) сам не писал. Да мне тоже кажется, что RV заменит VP
Алексей, расскажите ваше мнение по поводу custom view. Пользуетесь ли вы этим, нужно но ли вообще это уметь и может тоже подскажите какие то фишки в этом деле. Очень мало информации/туториалов по этой теме и все на какие то очень базовые вещи.
есть книга по Custom View www.oreilly.com/library/view/building-android-uis/9781785882869/
Dangerous Thunder спасибо уже скачал)
CustomVIew иногда бывает очень полезным особенно когда вы делаете какие-то компоненты, которые нельзя просто так собрать из стандартного набора android view, поэтому да навык очень нужный и часто востребованный. Насчет фишек. У меня на канале есть раздел сообщество там я где-то выкладывал анонс GDG+Revolut. Так вот первый доклад как раз был про custom view
@@MobileDeveloper Алексей спасибо за ответ, если что вот мой первый custom view - TextView со встроенным шрифтом fontawesome, может пригодится)
github.com/bios90/faw_text_view
Круто ) если сделаете хороший ренжпикер цены вам не будет )
Добрый день, подскажите? а исходника данного урока нет? только начал учить котлин и различные архитектуры, немного не понимаю, как правильно реализовывать сейчас тот же recyclerview и moxy
Хм не знаю. Вроде бы не делал
@@MobileDeveloper жаль, буду искать реализации. Но все равно спасибо за видео и объяснения
Привет, подскажи пожалуйста где искать первую работу, я только на HH смотрю, но выбор ну очень мал, на страну менее 100 объявлений без опыта и на нативных языках, ещё у трети написано необходимость высшего образования, по итогу выбора почти и нет
Пробовать себя в стартапах, писать свои проекты, потому что во многие компании требуется человек который умеет решать задачи. Если вы сделаете пару своих аппов, пусть неумелых, то у вас уже будет какой никакой релевантный опыт.
а какой опыт и знания у тебя?
Еще добавлю, что хороший способ объединяться в мелкие команды для проектов. Возьмите пример с Англии 80х, когда там зародили почти все современные звезды и рок группы. Люди объединялись учились играть и делали великие группы. Дерзайте, на этом канале куча людей вы можете кооперироваться.
Есть вопрос: какие либы в Flutter принято использовать для работы с сетью, бд, DI, RxJava, видел, там тоже есть retrofit/room, стоит ли их там использовать или есть что получше?
Самая распространённая наверное это rxdart и bloc. Для всего остального там неплохие вещи из коробки есть. Сейчас Временно отошёл от флаттера
@@MobileDeveloper спасибо большое
Большое спасибо за видео!
В последнем рабочем проекте было куча списков различных данных, но отображаемых в одном стиле. И пришла мысль привязывать адаптеры не к самим данным, а стилю отображения. То есть, каждый адаптер хранит список неких интерфейсов, в которых описаны методы для заполнения холдера. И после этого список любых моделей можем отображать через этот адаптер, просто написав имплементацию этого интерфейса для модели. Скажите, пожалуйста, как вам такой подход?
А что произойдет, если в дальнейшем все же один из списков потерпит изменения? Вынести в отдельный адаптер или добавлять интерфейсы дальше?
@@alexl5607 У нас ведь адаптер зависит от отображения, и если оно должно поменяться в каком-то списке, то выходит это уже должен быть другой адаптер)
Присоединяюсь к вопросу Alex ) могли бы вы скинуть ссылку на реализацию? Данные редко когда отображаются идентично, а это значит, что придётся кучу условий делать для каждого конкретного случая, интерфейсы будут примерно одинаковые разве нет? Мне нравится подход с AdapterDelegate, но я про него недавно услышал на конференции, поэтому пока не использую
На сегодня это видео ещё актуально? В плане передачи данных в адаптер, обновления и удаления их.
В целом recyclerview не изменился, однако, советую еще глянуть вторую часть про диф утилс)
@@MobileDeveloper Посмотрел, классная штука, только возникла проблема, если передавать адаптеру не полностью новый список через setData(), а ,например, обновить какой-то элемент через UpdateRow(), то изменения становится видно только после скрола списка туда и обратно, я слышал это вроде называется проблемой иммутабельности списка
Привет, хороший видос. Где лучше всего реализовывать листнеры для элементов ресайклера?
Я бы это выносил в некий интерфейс наружу. Потому что очень часто нажатия сопровождаются серьезной логикой. Имхо обрабатывать их надо во фрагменте, а дальше передавать уже или презентеру или ViewModel или роутеру ну и так далее
А как же ListAdapter DiffUtil ?
Уже отвечал, будет в следующем видео
Хотел у вас спросить. Есть адаптер, который может делать базовую логику (например, писать TextView в строку). Я хочу преобразовать его в open class и сделать наследника, который выводил бы в строке два TextView. Если первый был бы абстрактным, делается без проблем. Однако пока он open, возникает конфликт с onBindViewHolder, поскольку в нём в классе-наследнике входной параметр - viewHolder базового класса. Как сделать наследование адаптеров?
Боюсь это не совсем правильный подход в целом ) лучше настроить абстрактный адаптер с sealed classes и просто в конкретном onbindviewholder подменять на нужный viewholder
@@MobileDeveloper Ну не знаю. Мне интересно, если адаптеры нельзя наследовать (без abstract), соблюдается ли ООП. Sealed class ограничивает кол-во потомков, здесь, наоборот, удобнее делать множество потомков любых модификаций.
Не, наследовать то можно ) просто это как удалить гланды через задний проход ))) теоретически можно но есть ли в этом смысл?)
@@MobileDeveloper Не уверен, что это бессмысленно. Предположим, что у меня есть список с картинками. От него мне надо создать ещё несколько адаптеров, в которых будут картинки с текстом. Думаю, что наследование адаптеров здесь помогло бы сократить кол-во кода. Туда можно было бы вписать все общие методы и определить базовый ViewHolder.
Забавно недавно о похожем спорили в офисе. Дело в том что Гугл уже вынес все похожее в базовый класс и оставил только те вещи которые отличаются. Соответственно если у вас была картинка а стала картинка с текстом это разные xml и соответственно разные модели и viewholder. В чем здесь профит именно наследования а не просто написания в одном адаптере двух разных вьюхолдеров а унаследовать можно модели данных ) ну вернее сделать все тот же sealed class
30:44 когда getAdapterPosition() передаете для удаления, тоже возникают сложности?
Там не в этом проблема была )
Printerest кстати самое тормозное приложение какое я только видел.с производительностью там полная шляпа.не всегда красивый дизайн способствует привлечению пользователей.через неделю был благополучно удалён как раз из за тормозов
Ну ) как всегда вопрос идеи и реализации ) но я бы поспорил, что не всегда дизайн способствует) привлечению всегда или почти всегда, а дальше включается уже фактор удержания ) а вот здесь дизайн далеко не самую главную роль выполняет. Встречают, как говорится, по одежке, а дальше вы и сами знаете )
может это кросс-платформенное приложение, а у них такая проблема нередкая
Очень классные видосы, но очень не хватает таймкодов и ссылки на код
эх, запоздал я на задание :)))
Будут ещё причём очень скоро )
Ну камон, про итем апдейтед, ремувед, инсертед рассказывал 15 минут, а про DiffUtil ни слова не сказал. Отмазка что эта штука не нужна для базовой работы со списками не принимается.
А можно я сам буду решать как снимать видео? В другом ответе я уже объяснял, что задача была дать основы работы с компонентом, если вы посмотрите мои другие видео, я везде начинаю с самых самых основ и иду от простого к сложному
Очень надо научиться открывать Активити новую по клику на айтем списка, к каждому свою
Хелп плиз
Тут разные способы. Во-первых можно в модельку положить типа класс, ну что-то вроде SomeActivity::class.java. И потом переходить к ней по нажатию, можно по айди делать when и делать переходы. А скорее всего вам нужны не разные активити, а одна просто с разными входными параметрами. Это другая история
@@MobileDeveloper получается сделать toast на каждый айтем, но вот активити открыть никак
через when пробовал
Я бы мог скинуть проект, может сможете подсказать, готов на платной основе
Уже 2 недели мучаюсь
@@АнтонШаманин напишите мне в вк vk.com/neura