Side view shot of a man's hands using smart phone in interior, rear view of business man hands busy using cell phone at office desk, young male student texting on phone sitting at wooden table
MVI (Model-View-Intent) — це архітектурний патерн для розробки програмного забезпечення, який часто використовується в Android-розробці. Зокрема, в розробці на Jetpack Compose.
Як і дорослі партнерські відносини, все починається з контракту. Саме контракт, як і в усіх дорослих партнерських відносинах, визначає перелік наших дій, компетенцій, відповідальності тощо.
Це контракт між нашим UI та ViewModel в якій буде міститись зберігання стану і обробка подій.
Ось і почалась магія, помітили? Як легко ми опрацювали дані які нам прийшли. Два поля і натискання кнопки «Save». А коду написали буквально кілька рядків.
Вся магія обробки ховається у BaseViewModel. Але якщо глянути на неї ближче, то і там нічого складного немає.
Як бачите, я не збрехав — нічого складного.
Нам лиш треба реалізувати дві функції initState(), яка ініціалізує первісний стан UI. Та handleEvent(), яка всі події і обробляє. Що ми успішно і зробили.
Виглядає так, ніби нічого особливого. Код, який нам не довелось писати у ExampleViewModel ми написали у BaseViewModel, та ще й контракт додали з купою додаткових даних.
Але коли у вас багато екранів, багато в’юмоделей, такий підхід значно скоротить і спростить розробку — для зміни стану якогось елемента на UI не потрібно писати окремий метод бо є setState().
А на UI достатньо викликати setEvent() і він передасть усю інформацію про подію, яка відбулась у в’юмодель.
Це також спрощує додавання в’юмоделі у compose function. Адже всі, хто розробляє на Jetpack Compose прекрасно знають, що як тільки додав в’юмодель — preview успішно зламалось. Так, це все можна обійти, але не всі способи зручні, особливо коли в’юмодель приймає купу аргументів
То ж зараз я покажу досить простий спосіб як це зробити з малими затратами праці (як я і люблю).
Це наш UI. Як бачите, він містить всього два колбеки для обробки події та навігації. Якби наша в’юмодель мала функцію на кожну подію, то колбеків би знадобилось значно більше.
І завершальний шматок коду, де все починається. А може закінчується, це вже з якого боку подивитись.
Ось така ось магія, яка не містить жодної магії.
Раніше я до цього патерну ставився скептично, адже звик користуватись MVVM. Тепер от думаю, що як я жив без цього раніше.
Спробуйте та переконайтесь і самі, якщо не пробували.
А якщо пробували — діліться досвідом. Адже ніщо не досконале, і в цього зручного патерну теж є певні обмеження і застереження.
Цей текст з особистого блогу, опублікований з дозволу автора.
Компанія JetBrains оголосила, що середовище розробки RubyMine, яке використовується багатьма програмістами в екосистемах Ruby та…
Аналіз роботи нової моделі Grok Code Fast 1 від компанії xAI виявив, що вона має…
Платформа для веб-публікацій WordPress представила ранню версію нового інструменту розробки на основі штучного інтелекту під…
Нещодавнє опитування Stack Overflow 2025 виявило цікаві тенденції в розробці ПЗ, на які в своєму…
Компанія Google офіційно спростувала серію повідомлень, в яких стверджувалося, що останніми днями поштовий сервіс Gmail…
У середньому український IT-фахівець щомісячно допомагає Силам оборони на суму $155. Це трохи менше, ніж…