https://habr.com/ru/post/709808/?utm_source=habrahabr&utm_medium=rss&utm_campaign=709808

Представьте, что вы начали разработку нового Android-приложения. Поначалу особых проблем не будет. Вы реализовали лишь самые базовые функции. Экранов немного, и все они простые. Вам легко ориентироваться в коде. Вы бодро добавляете одну фичу за другой. Но со временем разработка усложняется: кода становится много, главный экран обрастает большим количеством UI-элементов и логики, экраны образуют сложные цепочки переходов. Приходится ломать голову, чтобы добавить что-то новое, не сломав ничего из старого. Скорость разработки падает. Знакомая ситуация?

Существует эффективный способ борьбы со сложностью — компонентный подход. Мы в MobileUp применили его в трех крупных Android-приложениях и теперь не представляем, как жили без него раньше.

Меня зовут Артур, я тимлид в компании MobileUp. Я помогу вам освоить компонентный подход. Постараюсь сделать это как можно проще и увлекательнее.

Вас ждет серия статей. Это первая из них — теоретическая. В ней мы рассмотрим, какие сложности встречаются в Android-приложениях, и почему MVVM и Clean Architecture не панацея против них. Я расскажу, что такое компонентный подход и в чем его преимущества. А в конце статьи будут ссылки на материалы для углубленного изучения.

https://habr.com/ru/post/708040/?utm_source=habrahabr&utm_medium=rss&utm_campaign=708040

В своей прошлой статье я рассуждал о том, как использование паттерна MVVM позволяет упростить процесс разработки. Паттерн был реализован с применением библиотеки MobX. Эту библиотеку я считаю в разы удобнее Redux, аргументы в пользу чего я также привел в статье. Однако, у нее имеется серьезный недостаток - излишняя свобода действий, в следствие наличия которой разработчики не всегда знают как писать код "хорошо". Паттерн MVVM же диктует несколько простых правил по использованию MobX, благодаря которым разработчики могут реже наступать на грабли. Однако, он не решает всех проблем. И в этой статье я бы хотел показать, как можно дополнить паттерн MVVM и сделать процесс разработки ещё приятнее.

https://habr.com/ru/post/704772/?utm_source=habrahabr&utm_medium=rss&utm_campaign=704772

Ни для кого не секрет, что Unity сейчас активно работают над новой системой создания пользовательского интерфейса UI Toolkit. Это инструмент разработки интерфейсов вдохновлённый стандартными подходами веб-разработки.

И всё бы хорошо, но какого было моё удивление, что, проделав такую работу, они не предоставили механизма связывания данных...

https://habr.com/ru/post/689134/?utm_source=habrahabr&utm_medium=rss&utm_campaign=689134

Привет! Меня зовут Александр Соломатов, я iOS Chapter Lead в СберМаркете. Моя команда занимается внедрением продуктовых фич в мобильное приложение СберМаркета под iOS. С 2020 года мы живём в продакшене со SwiftUI и я хочу поделиться опытом съеденных кактусов при использовании этого фреймворка. Эта статья для тех, кто размышляет над переходом с UIKit на SwiftUI, но не может решить, нужно ему это или нет. Никого убеждать всё переписать под чистую не буду, но подсвечу плюсы и минусы. Поехали!

https://habr.com/ru/post/699734/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699734

В этой статье я бы хотел подискутировать о том, насколько хорошо паттерн MVVM подходит для разработки Web приложений на React. Вместе этим, я собираюсь описать какие преимущества могут быть при разработке с использованием MobX с паттерном MVVM в сравнении с Redux. Запаситесь кофе, это будет долгое чтиво.

https://habr.com/ru/post/692218/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692218

https://habr.com/ru/post/687568/?utm_source=habrahabr&utm_medium=rss&utm_campaign=687568

Предпосылки: понимая, что контейнеры компоновки в WPF не позволяют сделать привязки (Binding) к своим дочерним элементам, решил поэкспериментировать, а как же всё-таки подсунуть данные из View Model для формирования содержимого в эти самые контейнеры компоновки. Позже аналогичное решение было сделано для AvaloniaUI.

Кроме того, я стал регулярно обращать внимание на то, что подобные вопросы появлялись в телеграме в чатах pro.net и AvaloniaUI (RU), поэтому своё решение опубликовал на гитхабе. Но вопросы продолжают появляться регулярно, что и сподвигло меня написать статью на Хабре с пошаговым разбором, что делать.

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

https://habr.com/ru/post/686438/?utm_source=habrahabr&utm_medium=rss&utm_campaign=686438

Продолжаем дополнять серию статей. Сегодня мы разберем как легко обработать ошибку с сервера. То что мы будем сегодня разбирать тесно связано с предыдущими статьями и если вы их ещё не читали то настоятельно рекомендую перейти по ссылкам, прочитать и вернуться.

https://habr.com/ru/post/673180/?utm_source=habrahabr&utm_medium=rss&utm_campaign=673180

Среди множества редакторов для разработки приложений под Android особенно выделяется Android Studio — это очевидный выбор большинства разработчиков не только потому, что это основной нативный редактор для разработки приложений, но и потому, что он предоставляет обширную оффлайн поддержку.

Этот набор фич гарантирует, что код, который мы пишем для нашего Android-приложения, будет эффективным и полнофункциональным. Одним из инструментов, цель которого заключается в оказании такого рода поддержки, является Lint.

Lint нужен для того, чтобы искать нетривиальные ошибки и плохо написанные фрагменты в вашем коде. В этой статье я расскажу вам о линтинге в Kotlin и о том, как его настроить и начать использовать. Давайте приступим.

https://habr.com/ru/post/671594/?utm_source=habrahabr&utm_medium=rss&utm_campaign=671594

7 лет назад на одной ИТ-конференции спикер рассказывал про новую возможность Android платформы. После доклада его спросили про архитектуру, которую они используют в своей команде для разработки Android приложений. Его ответ заключался в том, что архитектура не важна, что каждый разработчик может делать так, как он хочет. Он сказал, что главное - это не где какие файлы лежат и что в них написано, а главное, чтобы были новые фичи. В наших приложениях в то время никакой архитектуры не было и мы только начинали интересоваться этим вопросом, но ответ спикера меня удивил. Уже тогда мне казалось, что такой подход только усложняет работу, а не упрощает. Например, когда программист работает над новой фичой, ему приходится проанализировать несколько вариантов, сделанных разными людьми в рамках одного проекта, и потратить время на принятие решения о том, какой же из этих вариантов использовать сейчас.

Сегодня про архитектуру мобильных приложений гораздо больше информации и больше разработчиков задумываются об этом при старте приложения. Неважно, один человек работает над приложением или команда. Набор принципов и договоренностей об организации кода, о том, какой должна быть архитектура, помогает быстрее находить ответы на вопросы в процессе написания и проектирования кода.

https://habr.com/ru/post/664168/?utm_source=habrahabr&utm_medium=rss&utm_campaign=664168

Мы в IceRock Development уже много лет пользуемся подходом MVVM, а последние 4 года наши ViewModel расположены в общем коде, за счет использования нашей библиотеки moko-mvvm. В последний год мы активно переходим на использование Jetpack Compose и SwiftUI для построения UI в наших проектах. И это потребовало улучшения MOKO MVVM, чтобы разработчикам на обеих платформах было удобно работать с таким подходом.

30 апреля 2022 вышла новая версия MOKO MVVM - 0.13.0. В этой версии появилась полноценная поддержка Jetpack Compose и SwiftUI. Разберем на примере как можно использовать ViewModel из общего кода с данными фреймворками.

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

https://habr.com/ru/post/663824/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663824