На мой взгляд немного странный совет "Избегайте монотонного использования одного и того же паттерна или подхода во всем приложении, так как это может нанести вред", разве не в этом суть как раз таки стандартизации и шаблонов? Если используем паттерн на весь проект - то только его и используем, иначе например у новых подключившихся к проекту разработчиков могут возникнуть вопросы, наподобии "почему здесь так, а тут не так"?
Подскажите, нет ли у вас опечатки в пункте «Пропуск рекомпозиции при нестабильных типах»? В том плане, что пишете про блок Day. На блок схеме он зеленый, пишете что «он имеет нестабильные типы, но рекомпозировался».
Спасибо за статью, весьма обширное количество примеров с минусами / плюсами / оптимизации.
У нас в приложении решили пойти немного другим путем, по доставке какого то события к какому то компоненту - это создание некого «почтового ящика», который позволяет записать событие условно в строку в БД и передать событие в интересующий модуль. Очень удобно и довольно не проблематично .
То что начали появляться сравнительно быстро новые подходы - это очень не плохо, тот же KMM (теперь KMP) вполне интересный подход с реализацией логики на Kotlin. Удалось поработать с этим подходом - правда на iOS экраны не верстали )
А вот то, что условно сначала кодили под View, а теперь начинайте новые проекты с Compose - это странно, так как по сути предыдущие знания по верстке уже не особо пригодятся, ибо подход поменялся.
Для меня лично из плюсов Compose - это более менее удобные Preview и более простая работа по верстке «кастомных вьюшек».
На самом деле задумка так то интересная, но всегда хромает итоговая реализация. Очень странно привязываться исключительно к "номеру" и "смс" пользователя, учитывая что SIM-карты (именно SIM, а не E-SIM) имеют 2 неприятных момента:
1). SIM-карты со временем имеют свойство "размагничиваться", т.е. тебе для восстановления доступа по SMS нужно как минимум зайти в офис продаж того же мобильного оператора для восстановления доступа, и отсюда, мы плавно перетекаем во второй пункт;
2). Привязка SIM-карты пользователя к РЕГИОНУ открытия! Операторы, прежде чем переходить на такие технологии, разберитесь сначала с тем, что человек не может просто "перевыпустить" симку другого региона! Т.е. если я оформил номер в Самаре, то уже живя в Питере я не могу просто "перевыпустить" симку, т.к. она привязка к другому региону, менеджер офиса продаж скорее всего даже в биллинге не увидит данные по симке )))
P.S. По второму пункту правда отдать должное МТС, в Москве вроде как можно в некоторых офисах перевыпустить с другого региона.
Мне очень понравилась статья, спасибо автору. Несмотря на то, что выше подметили мол "пересказ оф доки" - все равно, понятно и доходчиво объяснили некоторые нюансы, например при вызове метода requestLayout() (что вызывается полный цикл с измерением размеров / закрепление дочерних View / перерисовка).
На мой взгляд немного странный совет "Избегайте монотонного использования одного и того же паттерна или подхода во всем приложении, так как это может нанести вред", разве не в этом суть как раз таки стандартизации и шаблонов? Если используем паттерн на весь проект - то только его и используем, иначе например у новых подключившихся к проекту разработчиков могут возникнуть вопросы, наподобии "почему здесь так, а тут не так"?
Добрый день! Хорошо написанная статья, но у меня вопрос возник (может подскажете): а с KMP проектами работает?
Подскажите, нет ли у вас опечатки в пункте «Пропуск рекомпозиции при нестабильных типах»? В том плане, что пишете про блок Day. На блок схеме он зеленый, пишете что «он имеет нестабильные типы, но рекомпозировался».
Спасибо за статью, весьма обширное количество примеров с минусами / плюсами / оптимизации.
У нас в приложении решили пойти немного другим путем, по доставке какого то события к какому то компоненту - это создание некого «почтового ящика», который позволяет записать событие условно в строку в БД и передать событие в интересующий модуль. Очень удобно и довольно не проблематично .
Спасибо за статью! Жду продолжения и исходников )
То что начали появляться сравнительно быстро новые подходы - это очень не плохо, тот же KMM (теперь KMP) вполне интересный подход с реализацией логики на Kotlin. Удалось поработать с этим подходом - правда на iOS экраны не верстали )
А вот то, что условно сначала кодили под View, а теперь начинайте новые проекты с Compose - это странно, так как по сути предыдущие знания по верстке уже не особо пригодятся, ибо подход поменялся.
Для меня лично из плюсов Compose - это более менее удобные Preview и более простая работа по верстке «кастомных вьюшек».
На самом деле задумка так то интересная, но всегда хромает итоговая реализация. Очень странно привязываться исключительно к "номеру" и "смс" пользователя, учитывая что SIM-карты (именно SIM, а не E-SIM) имеют 2 неприятных момента:
1). SIM-карты со временем имеют свойство "размагничиваться", т.е. тебе для восстановления доступа по SMS нужно как минимум зайти в офис продаж того же мобильного оператора для восстановления доступа, и отсюда, мы плавно перетекаем во второй пункт;
2). Привязка SIM-карты пользователя к РЕГИОНУ открытия! Операторы, прежде чем переходить на такие технологии, разберитесь сначала с тем, что человек не может просто "перевыпустить" симку другого региона! Т.е. если я оформил номер в Самаре, то уже живя в Питере я не могу просто "перевыпустить" симку, т.к. она привязка к другому региону, менеджер офиса продаж скорее всего даже в биллинге не увидит данные по симке )))
P.S. По второму пункту правда отдать должное МТС, в Москве вроде как можно в некоторых офисах перевыпустить с другого региона.
Мне очень понравилась статья, спасибо автору. Несмотря на то, что выше подметили мол "пересказ оф доки" - все равно, понятно и доходчиво объяснили некоторые нюансы, например при вызове метода requestLayout() (что вызывается полный цикл с измерением размеров / закрепление дочерних View / перерисовка).