Да, мне самому не нравится _ в именах полей, но я пока не придумал как по-другому их называть, поэтому часто ViewModel состоит из таких конструкций, только из соображений инкапсуляции
private val _data = MutableLiveData<Data>()
val data: LiveData<Data> = _data
Зачем хранить сами фрагменты в адаптере? Они ведь и так хранятся в FragmentManager.
К тому же есть вероятность сломать логику работы FragmentStateAdapter, ведь именно он отвечает за процесс создания и переиспользования фрагментов во ViewPager.
А что будет при смене конфигурации? Адаптер будет пересоздан с пустым mapOfFragment?
Бэкстэка на каждой странице не будет, т.е. возврат с "описания тарелки" в "список тарелок" только вручную?
Зато в Яндекс собесы чуть ли не как в компанию из FAANG — в несколько этапов и с обязательной алгоритмической частью. Только вот знание алгоритмов, видимо, не сильно помогает.
Видимо, прежде чем комментировать статью, стоит как минимум мельком прочесть ее, а не только заголовок. Статья для тех, кто пишет код, а не для тех, кто им пользуется.
Это почему вдруг избыточно?
Чем приложения на девайсах отличаются от приложений на десктопе, бэке, вэбе? В некоторых клиентских приложениях может быть кода в несколько раз больше, чем на сервере, и это не значит, что надо сваливать все в одну кучу и забивать на архитектуру. Сегодня в приложении 2-3 экрана, которые пилит 1 разработчик, а завтра там 30-50 экранов, которые пилит уже целая команда. И чем дальше в лес…
Конкретно в этом случае мы жестко связали два слоя (что потенциально развяжет руки джунам-миддлам в команде, которые войдут во вкус и продолжат напрямую юзать репозиторий), и захардкодили репозиторий (что потенциально сделало его non-testable).
Может и тесты писать не нужно? И вообще все в одну активити, раз приложение такая мелкая сошка — сателлит к серверу.
Не видел код, но подозреваю, что если мы напрямую обращаемся из domain-слоя в data-слой, значит оба слоя находятся в одном gradle-модуле или domain-модуль имеет в зависимостях data-модуль, что означает, что clean architecture уже сломано.
domain (как внутренний слой) не должен знать о реализации репозитория, которая находится в верхнем слое. он всего лишь описывает интерфейс и ждет, что реализацию ему предоставят извне (через DI).
Хм, в заголовке Kotlin, в статье ни строчки кода и даже упоминания о Kotlin. Чем "Hilt с Kotlin" отличается от "Hilt с Java"? Хотя этот вопрос скорее к автору статьи-оригинала
почему не используется ListAdapter и почему вычисление calculateDiff() происходит не в отдельном потоке?
как уже сказали выше inner-класс тут лишний. Все что нужно ViewHolder'у можно передать через его конструктор, или засетать прямо в onCreateViewHolder()
сетать onClickListener (и lifecycleOwner) при каждом onBind() — так себе вариант. при каждом вызове onBind() будет создаваться новый экземпляр View.OnClickListener(). достаточно это сделать в init {} вьюхолдера
А это как вообще "GradientDrawable используется не только для градиентов, но и для обычных shape drawable"?
GradientDrawable с тинтом превращается по сути в обычный ColorDrawable
Если в каждый ViewHolder в bindItem() передается onClick: (() -> Unit)?, значит там где-то будет someView.setOnClickListener { onClick() }, а это значит каждый раз создается новый инстанс View.OnClickListener при каждом onBindViewHolder(). Почему бы не передавать onClick в конструктор ViewHolder?
Что в этом подходе не так — адаптер теперь слишком много знает: о существовании Lifecycle, о том, что есть LiveData-источники данных, и есть какое-то выделение элементов. К тому же у адаптера появляется два источника данных — отдельно список элементов и отдельно события о выделении элементов (по position). При неправильном использовании извне это может привести к рассинхрону, например, когда событие selection change пришло для позиции, на которой уже стоит другой элемент из-за того, что в адаптер за мгновение до этого была добавлена/удалена строчка при событии items change.
У адаптера интерфейс четко прописан — вернуть кол-во элементов, создать и забиндить ViewHolder. Уже готовые к отображению данные (items с selection) ему передают извне, например, через submitList().
Весьма странно, что сделали deprecated, а не оставили как альтернативу. Если пользоваться правильно, то и проблем можно избежать. С таким же успехом можно и findViewById задепрекейтить.
В каком месте гугл это требует?
Да, мне самому не нравится _ в именах полей, но я пока не придумал как по-другому их называть, поэтому часто ViewModel состоит из таких конструкций, только из соображений инкапсуляции
А какие еще бывают варианты именования для backing properties?
Зачем хранить сами фрагменты в адаптере? Они ведь и так хранятся в FragmentManager.
К тому же есть вероятность сломать логику работы FragmentStateAdapter, ведь именно он отвечает за процесс создания и переиспользования фрагментов во ViewPager.
А что будет при смене конфигурации? Адаптер будет пересоздан с пустым mapOfFragment?
Бэкстэка на каждой странице не будет, т.е. возврат с "описания тарелки" в "список тарелок" только вручную?
Лучше чем "Дайджест интересных материалов для мобильного разработчика"
С фрагментами конечно перебор. Но и у RecyclerView нет setEmptyView(). Кто-то еще использует ListView?
Зато в Яндекс собесы чуть ли не как в компанию из FAANG — в несколько этапов и с обязательной алгоритмической частью. Только вот знание алгоритмов, видимо, не сильно помогает.
Видимо, прежде чем комментировать статью, стоит как минимум мельком прочесть ее, а не только заголовок. Статья для тех, кто пишет код, а не для тех, кто им пользуется.
Это почему вдруг избыточно?
Чем приложения на девайсах отличаются от приложений на десктопе, бэке, вэбе? В некоторых клиентских приложениях может быть кода в несколько раз больше, чем на сервере, и это не значит, что надо сваливать все в одну кучу и забивать на архитектуру. Сегодня в приложении 2-3 экрана, которые пилит 1 разработчик, а завтра там 30-50 экранов, которые пилит уже целая команда. И чем дальше в лес…
Конкретно в этом случае мы жестко связали два слоя (что потенциально развяжет руки джунам-миддлам в команде, которые войдут во вкус и продолжат напрямую юзать репозиторий), и захардкодили репозиторий (что потенциально сделало его non-testable).
Может и тесты писать не нужно? И вообще все в одну активити, раз приложение такая мелкая сошка — сателлит к серверу.
Не видел код, но подозреваю, что если мы напрямую обращаемся из domain-слоя в data-слой, значит оба слоя находятся в одном gradle-модуле или domain-модуль имеет в зависимостях data-модуль, что означает, что clean architecture уже сломано.
domain (как внутренний слой) не должен знать о реализации репозитория, которая находится в верхнем слое. он всего лишь описывает интерфейс и ждет, что реализацию ему предоставят извне (через DI).
Хм, в заголовке Kotlin, в статье ни строчки кода и даже упоминания о Kotlin. Чем "Hilt с Kotlin" отличается от "Hilt с Java"? Хотя этот вопрос скорее к автору статьи-оригинала
Эм, а это что за плейсхолдеры:
А это как вообще "GradientDrawable используется не только для градиентов, но и для обычных shape drawable"?
GradientDrawable с тинтом превращается по сути в обычный ColorDrawable
Если в каждый ViewHolder в bindItem() передается onClick: (() -> Unit)?, значит там где-то будет someView.setOnClickListener { onClick() }, а это значит каждый раз создается новый инстанс View.OnClickListener при каждом onBindViewHolder(). Почему бы не передавать onClick в конструктор ViewHolder?
Что в этом подходе не так — адаптер теперь слишком много знает: о существовании Lifecycle, о том, что есть LiveData-источники данных, и есть какое-то выделение элементов. К тому же у адаптера появляется два источника данных — отдельно список элементов и отдельно события о выделении элементов (по position). При неправильном использовании извне это может привести к рассинхрону, например, когда событие selection change пришло для позиции, на которой уже стоит другой элемент из-за того, что в адаптер за мгновение до этого была добавлена/удалена строчка при событии items change.
У адаптера интерфейс четко прописан — вернуть кол-во элементов, создать и забиндить ViewHolder. Уже готовые к отображению данные (items с selection) ему передают извне, например, через submitList().
Тут предлагают на замену ViewBinding, а не DataBinding)
Весьма странно, что сделали deprecated, а не оставили как альтернативу. Если пользоваться правильно, то и проблем можно избежать. С таким же успехом можно и findViewById задепрекейтить.
Тоже надеялся про IPC почитать, глянув заголовок. Оказалось 5 страниц текста в основном про android:exported
Пожалуйста, не пишите больше так
Может лучше не позориться, а?