Комментарии 29
По композ вы очень поверхностно прошлись. Основная плюшка - функциональный подход к формированию виджетов, использование иммутабельного состояния для обновления всех виджетов экрана. Раньше для этого создавали и парсили ViewState на базе дата-класса, теперь же этого делать не надо. Но заодно завезли довольно медленный и глючный рендеринг превью, так что удовольствия от процесса имхо пока не много. А итоговый код выглядит нагромождением вложений, даже если дробить на функции. Ну и еще есть правила написания таких функций, чтобы не терялся смысл.
В общем, тут все много глубже простого «избавились от xml и id”
Кстати, на месте новичка я бы не торопился учить композ - оно дойдет до хоть какой-то массовости не через год, и может даже не через 2. Как пример - флаттер. Сказки про него рассказывают уже года 4 изо всех блогов, а популярен массово он стал недавно. И в основном в аутсорсе, по понятным причинам.
в целом согласен
но хотелось бы уточнить - и остальные технологии, описанные выше, совсем не то, с чего стоит начинать
о них стоит задумываться как раз в тот момент, когда всё неплохо работает на простых "fragment (xml) + live data + viewmodel + менеджеринг многопоточности" и уже хочется ускорить процесс разработки/попробовать что-то новое
Статья в принципе поверхностная, не совсем понимаю, почему вы выделили именно Compose. Тут про каждую технологию по отдельной статье можно написать
Даже если отбросить мою личную неприязнь к котлину, проблема использования модных гугловских абстракций поверх SDK в том, что они постоянно меняются и никогда не готовы. Одно уже задепрекейтили, а предлагаемая замена всё ещё в бете. Та же навигация — гугл уже, наверное, третье или четвёртое по счёту решение на эту тему представляет, я уже перестал за всем этим следить, просто написал свой простенький стек для системных фрагментов и пользуюсь им. Да, даже appcompat на самом деле не нужен.
Вы, мягко говоря, преувеличиваете. Та же nav library все та же как была, только обновляется регулярно. Не помню когда там были последний раз breaking changes :)
Да, даже appcompat на самом деле не нужен.
?♂️
Вы простите, но когда человек не занимается каким-то направлением разработки, то ему и не судить бы о его (направлении) специфике, верно?
Вы простите, но когда человек не занимается каким-то направлением разработки, то ему и не судить бы и о ее специфике, верно?Вы простите, но я занимаюсь разработкой под андроид 10 лет, 5 из которых писал официальное приложение ВКонтакте, большую часть времени как единственный разработчик. Наверное, я хотя бы чуть-чуть в этом разбираюсь.
Просто ваш комментарий, на мой взгляд, не мэтчится с этим фактом. Но ок, наверное вы чтото другое хотели сказать
ps. Ни на что не намекаю, но можно и за 5 лет не продвинуться особо, я встречал такие примеры. Просто не будем гнуть пальцы ;)
З.Ы. Сам придерживаюсь чего то среднего. С одной стороны современное коммьюнити чрезмерно упоролось абстракциями и «архитектурами», с другой писать на голой java и всюду вставлять проверки на версию SDK по мне тоже как то перебор.
Вдумайтесь - каждое приложение тащит за собой androidx. Хорошо хоть не целую ява-машину. Как пример, приложение без него - 200 кБ, с ним - 2 мб с лишним.
И при этом полная мешанина в стилях, где теперь надо их менять для сходных стилей в разных неймспейсах, а стоит немного ошибться, например вместо цвета поставить ссылку на цвет, и на старых версиях Андроида всё валится без внятных сообщений.
Щас бы в 2022 2 мегабайта экономить, и вместо использования общепринятых стандартов писать костыли и велосипеды
Не у всех мобильников гигабайт памяти на борту. Не радует терять деньги только из-за того, что у потенциального клиента старая версия Андроида или мало памяти на устройстве.
Если вы про устройства с Api < 21, то не представляю какой важности должен быть клиент чтобы мириться со всеми неудобствами minApi < 21. Одна работа с тенями чего стоит :/
Когда приложение это не очередная развлекаловка, клиентов не много и каждый важен. Тени далеко не в каждом приложении важны. Они конечно делают приложение модным, но этот материал дизайн, где элементы управления трудно отличить от обычных надписей, с его огромными отступами, порядком затрудняет разработку интерфейсов и взаимодействие с приложением.
Хорошо хоть не целую ява-машину.Флаттер передаёт привет)))0
думаю, основную выгоду от этих абстракций можно получить на крупных проектах с множеством разработчиков
то есть их основная цель - не дать каждому разработчику писать своё решение на каждый процесс
например, flow - казалось бы, напиши свои коллбеки на корутинах, пропиши сценарии переполнения и готово...
но когда я вижу у кого-то стандартный StateFlow - я сразу уверен, как оно работает и используется в проекте
когда я вижу кастомные SingleValueAnySubscribersDeleteIfNoSubsCallback, мне нужно потратить время, чтобы поверить в логику его работы
MVI или MVVM тут уж кому как больше нравится
Hilt это не замена даггеру. Это упрощённая, урезанная надстройка. Перечислены множество "плюсов", которые сводятся к тому, что надо писать чуточку меньше кода(создание скоупов? серьёзно? в одну строку делается).
А про минусы ни слова. Компонентов(именно классов компонентов) ограниченное количество(можно создавать свои, но тогда весь смысл уменьшения количества кода теряется). Скоупов тоже ограниченное количество(по количеству компонентов). Теперь всё, что есть в скоупе фрагмента, доступно во всех фрагментах. Другими инстансами, да, что тоже может фрустрировать неофита.
Разделение на гредл-модули хромает. По сути хилт будет использоваться только в одном, главном модуле, а в остальных — будьте добры, чистый даггер.
На мой взгляд, хилт — это попытка гугла подсадить всех-всех начинающих разработчиков на хоть какой-нибудь DI. Чтобы было. Для серьёзной разработки оно не подходит. Если модный == делает первые шажки, то конечно да, оно должно быть в подобных списках.
Разделение на гредл-модули хромает. По сути хилт будет использоваться только в одном, главном модуле, а в остальных — будьте добры, чистый даггер.
Звучит будто вы с хилтом никогда не работали, все там отлично с многомодульностью, нужно только плагин в feature-модули подключить. А вот с dynamic features тут да, есть к чему стремиться
Flow (StateFlow, SharedFlow...) — асинхронных способ передачи данных по подписочной модели. По принципу Flow — это LiveData с кучей настроек
Словил фейспалм. По принципу, Flow — это реактивный стрим данных, а никакая не сраная лайфдата. State/SharedFlow это реализация горячих стримов. А то выглядит так, будто PublishSubject изучил, подписался на него, и сидишь довольный.
Как стать модным Android-разработчиком в 2022 году