# MVI Published articles for MVI. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Simple MVI Architecture Approach Using LiveData DevFeed: [A Simple MVI Architecture Approach Using LiveData]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2026-09-17T04:13:15.404035Z Content type: opinion Language: en Sources: [Dustin Summers]() Topics: [Android](), [Dagger]() Tags: [architecture](), [architecture-pattern](), [error](), [livedata](), [loading](), [mvi]() ### AI overview A talk from Android Summit 2019 discusses a simple implementation of the MVI architecture pattern using LiveData and the Loading, Content, Error pattern. ### Source excerpt This was a talk provided by myself and Dan Lowe at Android Summit, 2019. In this we discuss a simple approach to the MVI (Model, View, Intent) Architecture Pattern using LiveData and the common Loading, Content, Error Pattern. Link to Dan's blog post is here which is what our talk was based around. ## Scalable API Response Handling Across Multi-Layered Architectures with Sandwich DevFeed: [Scalable API Response Handling Across Multi-Layered Architectures with Sandwich]() Original publisher: [Read original article]() Author: Jaewoong Eum Published: 2026-02-08T06:25:14Z Content type: tutorial Language: en Sources: [Stories by Jaewoong Eum on Medium]() Topics: [Android](), [Kotlin](), [API](), [kotlin-coroutines](), [Error Handling](), [Network]() Tags: [android](), [api](), [code](), [communication](), [coroutines](), [error-handling](), [exceptions](), [flow](), [kotlin](), [kotlin-multiplatform](), [mvi](), [mvvm](), [network](), [networking](), [presentation](), [responses](), [retrofit](), [viewmodel]() ### AI overview This tutorial explains how to handle Retrofit API responses, errors, and exceptions across multi-layered Android architectures such as MVVM and MVI. It presents Sandwich as a type-safe, composable approach and covers response handling, composition, merging, global error mapping, and Flow integration. ### Source excerpt Unsplash@picoftasty Modern Android applications commonly adopt multi-layered architectures such as MVVM or MVI, where data flows through distinct layers: a data source, a repository, and a ViewModel (or presentation layer). Each layer has a specific responsibility, and network responses must propagate through all of them before reaching the UI. While this separation produces clean, testable code, it introduces a real challenge: how do you handle API responses, including errors and exceptions, as they cross each layer boundary? Most developers solve this by wrapping API calls in try-catch blocks and returning fallback values. This works for small projects, but as the number of API calls grows, the approach creates ambiguous results, scattered boilerplate, and lost context that downstream layers need. You end up with ViewModels that cannot tell whether an empty list means "no data" or "network failure," repositories that swallow important error details, and data sources that repeat the same error handling pattern dozens of times. In this article, you'll explore the problems that emerge when handling Retrofit API calls across layered architectures, why conventional approaches break down at scale, and how Sandwich provides a type safe, composable solution that simplifies response handling from the network layer all the way to the UI. You'll also walk through the full set of Sandwich APIs, from basic response handling to advanced patterns like sequential composition, response merging, global error mapping, and Flow integration, each with real world use cases that show when and why you would reach for them. Retrofit API calls with coroutines Most Android projects use Retrofit with Kotlin coroutines for network communication. A typical service interface looks like this: https://medium.com/media/ebcba33386d664d1cf69a89234d2e22a/href The service returns a List directly. Retrofit deserializes the JSON response body and gives you the data. This works perfectly when the ## Android ViewModel Data Loading: Best Practices and Flow-Based Architecture DevFeed: [Android ViewModel Data Loading: Best Practices and Flow-Based Architecture]() Original publisher: [Read original article]() Author: FunkyMuse Published: 2025-08-28T23:11:00Z Content type: opinion Language: en Sources: [FunkyMuse]() Topics: [Android](), [Development](), [Mobile](), [Kotlin](), [Compose](), [ui]() Tags: [android](), [android-development](), [architecture](), [compose](), [development](), [kotlin](), [livedata](), [mvi](), [mvvm](), [patterns](), [stateflow](), [ui](), [viewmodel]() ### AI overview An opinionated Android architecture article examines data-loading patterns in ViewModels and discusses problems associated with loading data in initialization blocks, including re-entry behavior, dispatcher timing, data freshness, and testability. It presents Kotlin Flow and StateFlow sharing as the proposed solution. ### Source excerpt Architecture discussions in Android development often spark passionate debates--sometimes garnering both praise and criticism. Writing about these topics isn't easy, but that's what makes it worthwhile. This article presents my opinionated perspective on data loading patterns, refined through experience and recovery from recent surgeries (one recovery is still in progress). Consider this a sna... ## Orbit Multiplatform wins Kotlin Foundation Grant: A Journey and a Look Ahead DevFeed: [Orbit Multiplatform wins Kotlin Foundation Grant: A Journey and a Look Ahead]() Original publisher: [Read original article]() Author: Matthew Dolan Published: 2024-10-02T13:30:16Z Content type: article Language: en Sources: [Stories by Matthew Dolan on Medium]() Topics: [Kotlin](), [multiplatform](), [Coroutines](), [Library](), [kotlin-coroutines](), [Open Source](), [Android](), [RxJava](), [reactive](), [Programming]() Tags: [android](), [android-app-development](), [coroutines](), [development](), [kotlin](), [kotlin-coroutines](), [kotlin-multiplatform](), [multiplatform](), [mvi](), [open-source](), [orbit](), [reactive](), [rxjava]() ### AI overview The article announces that the Kotlin Foundation awarded a grant to Orbit Multiplatform and reviews the open-source library's evolution. It describes Orbit 1's reactive, RxJava-inspired architecture and debugging and maintenance challenges, then explains the redesign leading to Orbit 2, including Kotlin coroutines, structured concurrency, composition, direct function calls, and a simplified DSL. ### Source excerpt We're thrilled to announce that the Kotlin Foundation has awarded Orbit Multiplatform a grant! This recognition is a tremendous honour and a chance to reflect on Orbit's journey and share our vision for the future. Orbit's Origins Orbit began as an open-source project over five years ago, in September 2019. It was one of the first libraries I co-created with Mikołaj Leszczyński, and its development has been a journey of constant learning and evolution. The Early Days: Orbit 1 I first encountered Orbit when I joined the Android team at Babylon Health in July 2018. Mikołaj had already developed the initial version of Orbit, heavily inspired by RxJava and talks such as Jake Wharton's Managing The Reactive World with RxJava. RxJava's influence was evident in Orbit's reactive approach, with chained operations driving the architecture. However, while this design worked well in some cases, it posed significant challenges -- especially with debugging. For instance, one event could trigger multiple others, leading to hard-to-trace bugs. Additionally, we ran into issues with type erasure due to the use of generics, which made it even harder to maintain the library. Here's an example of the syntax from Orbit 1: data class State(val total: Int = 0) data class AddAction(val number: Int) class CalculatorMiddleware: Middleware by middleware(State(), { perform("addition") .on() .withReducer { state, action -> state.copy(state.total + action.number) } }) While the initial approach was a valuable learning experience, it became clear that Orbit needed a shift. The Transition: Kotlin Coroutines and Orbit 2 In October 2018, Kotlin 1.3 introduced coroutines, offering an opportunity to rethink Orbit's architecture. Coroutines brought structured concurrency to Kotlin, making asynchronous programming more straightforward and less error-prone. However, it wasn't until May 2020 that we began redesigning Orbit's syntax to leverage coroutines. By August 2020, we released ## Essential Components of an Android Developer GitHub Showcase Project DevFeed: [Essential Components of an Android Developer GitHub Showcase Project]() Original publisher: [Read original article]() Author: Ban Markovic Published: 2024-02-05T11:00:04Z Content type: tutorial Language: en Sources: [Stories by Ban Markovic on Medium]() Topics: [Android](), [android-development](), [Mobile](), [Kotlin](), [REST API](), [Coroutines](), [Dependency injection]() Tags: [android](), [android-development](), [androiddev](), [coroutines](), [dependency-injection](), [github](), [jetpack-compose](), [kotlin](), [mvi](), [mvvm](), [portfolio](), [rest-api](), [screen](), [unit-tests]() ### AI overview The article recommends building a concise Android showcase project for a GitHub portfolio. The project should use two screens to fetch and display a list from a REST API, support navigation to item details, demonstrate MVI or MVVM architecture, organize files clearly, handle asynchronous work, include unit tests, and use dependency injection. ### Source excerpt In the competitive world of Android development, having a strong GitHub portfolio is crucial for showcasing your skills to potential employers. One effective way to demonstrate your expertise is by creating a concise yet comprehensive project that highlights key aspects of Android development. In this article, we'll explore the essential components that every Android developer should have in their GitHub, focusing on a project that encapsulates fundamental skills. The Project Overview A successful showcase project should include two screens and cover the following key functionalities: Fetching and Displaying Data - Utilize a REST API to fetch a list of items. - Display this list on the first screen of the app. Navigation and Detailed Information - Enable users to navigate to a second screen by clicking on a specific item. - On the second screen, display more detailed information about the selected item. Key Considerations for the Showcase ProjectArchitecture -- MVI or MVVM Clearly implement and showcase your understanding of the chosen architecture (MVI or MVVM). Organize code files in a logical and easily understandable structure. File Organization Demonstrate a well-organized project structure, separating concerns and making codebase easily maintainable (feature-based or type-based folders structure). Asynchronous Communication Showcase your proficiency in handling asynchronous tasks by using an appropriate library (e.g., Kotlin Coroutines, LiveData, RxJava). Unit Tests Impress potential employers by including unit tests to validate the functionality of critical components (cover your ViewModel, UseCase, Repository classes with unit tests). Dependency Injection (DI): Implement and demonstrate your use of dependency injection for managing component dependencies (Hilt, Dagger, Koin). Why This Project Matters This concise project effectively showcases your abilities in: Displaying a list of items Fetching data from the internet Implementing navigation between screens ## ViewModel: for UI business, not UI operations 😮 DevFeed: [ViewModel: for UI business, not UI operations 😮]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2022-12-19T12:30:42Z Content type: opinion Language: en Sources: [Shreyas Patil's Blog]() Topics: [Android](), [ui](), [reactive](), [App]() Tags: [android](), [android-app-development](), [apis](), [applications](), [architecture](), [business-logic](), [kotlin](), [mvi](), [mvvm](), [reactive](), [state-management](), [ui](), [ux]() ### AI overview An opinionated Android development article explains that ViewModels should hold UI state and execute business logic for the UI, while avoiding responsibility for UI operations. It uses toast and bottom-sheet interaction examples to illustrate keeping UI concerns loosely coupled from ViewModels. ### Source excerpt Stop misusing ViewModels! Learn why ViewModels should handle UI business logic, not UI operations like showing toasts or navigation. ## Reclaim the reactivity of your state management, say no to imperative MVI DevFeed: [Reclaim the reactivity of your state management, say no to imperative MVI]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2022-05-02T05:05:46Z Content type: opinion Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [reactive](), [Redux](), [Elm](), [JavaScript](), [Programming]() Tags: [android](), [android-app-development](), [androiddev](), [architecture](), [architecture-pattern](), [clean-code](), [elm](), [javascript](), [model-view-intent](), [mvi](), [reactive](), [redux](), [state](), [state-management]() ### AI overview The article critiques imperative MVI-style state management as overly complex and boilerplate-heavy. It traces MVI's web-oriented history through Cycle.js, The Elm Architecture, and Redux, and questions whether those patterns fit statically typed application development. ### Source excerpt Do you find yourself chasing for "clean code, clean architecture, clean design, clean state management" yet still feel bogged down in a sea of boilerplate for even the simplest of tasks -- such as showing a simple list fetched with a coroutine? Surely this could be done in a single line or maybe about seven, but it certainly shouldn't need gigantic case-whens, three layers of indirection, and so on? Well, normally you could just invoke functions on ViewModel and it would work, but if you're forced to seek the "architectural holy grail", no one around you will trust your code unless you add at least one sealed class called ViewActions, and increase the cyclomatic complexity of your "action handler" function until it feels "just clean enough". (After all, surely the more completely unrelated things a single function does based on its argument, the more it has a "single responsibility" of handling literally everything, which is why you know it's definitely the best possible way to do it. 😏) Anyway, the boilerplate of coupling together all aspects into a single class, whether it is a function call or state property, this all has a history: namely, it came from the web. The brief history of MVI MVI stands for "model-view-intent" and comes from a (not very popular for use in production) Javascript framework called Cycle.js, hand-in-hand with a (not popular anymore) concept called "The Elm Architecture" defined as the best practices and intended use of an experimental (and since 2019, unmaintained) "functional-reactive programming language for the web" called ELM. Then again, these didn't come from a vacuum either -- the originator is Redux, in 2015. The general idea was to implement a state machine using the command processor pattern in Javascript, thereby supporting "undo" functionality (also often referred to as "time-travel debugging"). Of course, most design decisions of Redux only make sense for Javascript -- as it is a language with no static typing. It makes sense to ## Архитектурный шаблон MVI в Kotlin Multiplatform. Часть 3: тестирование DevFeed: [Архитектурный шаблон MVI в Kotlin Multiplatform. Часть 3: тестирование]() Original publisher: [Read original article]() Author: arkivanov (Badoo) Published: 2020-08-27T12:52:18Z Content type: tutorial Language: ru Sources: [Badoo EN](), [Badoo RU]() Topics: [Kotlin Multiplatform](), [Kotlin](), [multiplatform](), [Android](), [iOS]() Tags: [android](), [architecture](), [cross-platform](), [ios](), [kotlin](), [kotlin-multiplatform](), [mpp](), [multiplatform](), [mvi]() ### AI overview This concluding article in a series demonstrates unit and integration testing for a shared Kittens module in Kotlin Multiplatform applications. It discusses testing across supported platforms, including Android and iOS, and describes limitations such as the lack of mocking libraries for Kotlin/Native and Kotlin/JS. ### Source excerpt Эта статья является заключительной в серии о применении архитектурного шаблона MVI в Kotlin Multiplatform. В предыдущих двух частях (часть 1 и часть 2) мы вспомнили, что такое MVI, создали общий модуль Kittens для загрузки изображений котиков и интегрировали его в iOS- и Android-приложения. В этой части мы покроем модуль Kittens модульными и интеграционными тестами. Мы узнаем о текущих ограничениях тестирования в Kotlin Multiplatform, разберёмся, как их преодолеть и даже заставить работать в наших интересах. Обновлённый пример проекта доступен на нашем GitHub. ## Архитектурный шаблон MVI в Kotlin Multiplatform, часть 2 DevFeed: [Архитектурный шаблон MVI в Kotlin Multiplatform, часть 2]() Original publisher: [Read original article]() Author: arkivanov (Badoo) Published: 2020-07-09T13:24:17Z Content type: tutorial Language: ru Sources: [Badoo EN](), [Badoo RU]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Android](), [iOS](), [SwiftUI]() Tags: [android](), [architecture](), [cross-platform](), [ios](), [kotlin](), [kotlin-multiplatform](), [mpp](), [multiplatform](), [mvi](), [swiftui]() ### AI overview The second article in a three-part series explains how to implement platform-specific parts of a Kotlin Multiplatform module and integrate it into iOS and Android applications. It uses expect/actual, SwiftUI for iOS, and Android Views for Android. ### Source excerpt Это вторая из трёх статей о применении архитектурного шаблона MVI в Kotlin Multiplatform. В первой статье мы вспомнили, что такое MVI, и применили его для написания общего для iOS и Android кода. Мы ввели простые абстракции, такие как Store и View, а также некоторые вспомогательные классы и использовали их для создания общего модуля. Задача этого модуля -- загружать ссылки на изображения из Сети и связывать бизнес-логику с пользовательским интерфейсом, представленным в виде Kotlin-интерфейса, который должен быть реализован нативно на каждой платформе. Именно этим мы и займёмся в этой статье. Мы будем реализовывать специфичные для платформы части общего модуля и интегрировать их в iOS- и Android-приложения. Как и прежде, я предполагаю, что читатель уже имеет базовые знания о Kotlin Multiplatform, поэтому не буду рассказывать о конфигурациях проектов и других вещах, не связанных с MVI в Kotlin Multiplatform. Обновлённый пример проекта доступен на нашем GitHub. Читать дальше -> ## Designing and Working with Single View States on Android DevFeed: [Designing and Working with Single View States on Android]() Original publisher: [Read original article]() Author: Márton Braun Published: 2020-05-25T17:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Android](), [App](), [ui](), [Code]() Tags: [android](), [architecture](), [data-class](), [kotlin](), [marton-braun](), [mvi](), [mvvm](), [network](), [sealed-classes](), [state](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview This tutorial explains how to represent Android screen state with a single ViewState object. It compares a single data class with a hierarchy of sealed classes, emphasizing how sealed classes can better model mutually exclusive states such as loading, content, and error. ### Source excerpt Describing the state of a screen is a common practice these days thanks to MVI popularizing the concept. Let's take a look at some examples of how you can design your state objects neatly using data classes and sealed classes, and how you can put them into practice. ## \[Перевод\] Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1 DevFeed: [\[Перевод\] Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1]() Original publisher: [Read original article]() Author: arkivanov (Badoo) Published: 2020-05-14T14:01:02Z Content type: tutorial Language: ru Sources: [Badoo EN](), [Badoo RU]() Topics: [Kotlin Multiplatform](), [multiplatform](), [Kotlin](), [Android](), [iOS]() Tags: [android](), [architecture](), [concurrency](), [cross-platform](), [immutability](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [model-view-intent](), [mpp](), [multiplatform](), [mvi](), [mvvm](), [reactive]() ### AI overview This first article in a three-part series describes using the MVI architectural pattern with Kotlin Multiplatform. It introduces a shared module intended for integration with iOS and Android applications and discusses related testing topics. The author argues that MVI is a better fit for Kotlin Multiplatform than MVVM or an added clean-architecture layer, while noting that the article does not teach Kotlin Multiplatform fundamentals or project setup. ### Source excerpt Около года назад я заинтересовался новой технологией Kotlin Multiplatform. Она позволяет писать общий код и компилировать его под разные платформы, имея при этом доступ к их API. С тех пор я активно экспериментирую в этой области и продвигаю этот инструмент в нашей компании. Одним из результатов, например, является наша библиотека Reaktive -- Reactive Extensions для Kotlin Multiplatform. В приложениях Badoo и Bumble для разработки под Android мы используем архитектурный шаблон MVI (подробнее о нашей архитектуре читайте в статье Zsolt Kocsi: "Современная MVI-архитектура на базе Kotlin"). Работая над различными проектами, я стал большим поклонником этого подхода. Конечно, я не мог упустить возможность попробовать MVI и в Kotlin Multiplatform. Тем более случай был подходящий: нам нужно было написать примеры для библиотеки Reaktive. После этих моих экспериментов я был вдохновлён MVI ещё больше. Я всегда обращаю внимание на то, как разработчики используют Kotlin Multiplatform и как они выстраивают архитектуру подобных проектов. По моим наблюдениям, среднестатистический разработчик Kotlin Multiplatform -- это на самом деле Android-разработчик, который в своей работе использует шаблон MVVM просто потому, что так привык. Некоторые дополнительно применяют "чистую архитектуру". Однако, на мой взгляд, для Kotlin Multiplatform лучше всего подходит именно MVI, а "чистая архитектура" является ненужным усложнением. Поэтому я решил написать эту серию из трёх статей на следующие темы: Краткое описание шаблона MVI, постановка задачи и создание общего модуля с использованием Kotlin Multiplatform. Интеграция общего модуля в iOS- и Android-приложения. Модульное и интеграционное тестирование. Ниже -- первая статья серии. Она будет интересна всем, кто уже использует или только планирует использовать Kotlin Multiplatform. ## Build complex screens faster on Android with Epoxy DevFeed: [Build complex screens faster on Android with Epoxy]() Original publisher: [Read original article]() Author: Akshay Chordiya Published: 2019-12-30T13:31:50Z Content type: tutorial Language: en Sources: [Bleeding Edge - Medium]() Topics: [Android](), [Library](), [ui](), [implementation]() Tags: [android](), [architecture](), [class](), [component](), [components](), [declarative](), [epoxy](), [how-to](), [kotlin](), [layout](), [library](), [mvi](), [mvvm](), [performance](), [recyclerview](), [ui](), [view]() ### AI overview This tutorial explains how Clue adopted Airbnb's Epoxy library with RecyclerView to build complex Android screens. It covers Epoxy models, adapters and controllers, declarative layouts, and a unidirectional data-flow pattern related to MVVM and MVI. ### Source excerpt Rowing the boat -- Illustration by Marta PucciBuild complex screens faster on Android⚡ -- Our journey with Epoxy RecyclerView is such an important UI component on Android. But using it can get complex and error prone--especially when dealing with different view types and pagination. Moreover, it's hard when working on the same screen within the team. In this article, I'm going to share basics of Epoxy and an overview of the problems it helped us solve. Here's our journey of how we adopted Epoxy at Clue to build our UIs faster in parallel within the team.⚡ Backstory It all started with our users, who wanted a more understandable and interactive view of their historical tracking data. ✨(For Clue users, this is generally their menstrual cycles & symptoms.) So our awesome design team came up with this beautiful intuitive design 😍: Enhanced Analysis screen in Clue app I know what you're thinking already: that's a lot of view types. And we were definitely concerned about the performance and responsiveness of the screen. That's when we decided to see if we could use any third-party library to help us with our goal. Epoxy Epoxy is a library from Airbnb which takes a declarative / composable approach to build the UI--typically, a list. It uses RecyclerView under the hood It simplifies creation of static and dynamic layouts Each item in the list is associated to an epoxy model which defines the item's layout and manages binding the data and releasing the view's resources when it's recycled. Item <-> Epoxy Model <-> Layout resource The order of the items shown on the UI is based on how you add the model to the adapter or controller. Philosophy Epoxy encourages a usage pattern similar to the popular MVVM and MVI architecture where the data flows in one direction (UDF - uni-directional data flow). Flow with Epoxy The data forms the state of the UI then goes to EpoxyModel and to the views on the RecyclerView . The Epoxy Model behaves like a ViewModel and provides the interface betwe ## Architecting Android and iOS app features for 2020 DevFeed: [Architecting Android and iOS app features for 2020]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-10-26T00:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [Android](), [iOS](), [Code](), [App]() Tags: [android](), [architecture](), [code](), [developers](), [instacart](), [ios](), [mvi](), [mvvm](), [patterns]() ### AI overview A talk presents architecture principles for building robust, safe, and testable app features across iOS and Android. It draws on MVVM and MVI, discusses the principles' advantages and disadvantages, and includes code examples and lessons from applying them at Instacart. ### Source excerpt Inspired by some well known architecture patterns like MVVM/MVI, I set out to come up with an agnostic set of principles that would help developers build features in their app in a robust, safe and (importantly) "testable" way. At Instacart, we've started to use these principles to build features on both iOS and Android. In this talk, we'll examine these principles, discuss the merits (+ disadvantages!) and see how these can be implemented with precise code examples. Having implemented this pattern for sometime now at Instacart, I'll also share some of our learnings along the way for both platforms. Slides ## ## Choosing an Architecture Pattern for Android Applications DevFeed: [Choosing an Architecture Pattern for Android Applications]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2019-08-16T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Android](), [mvc](), [App](), [Code]() Tags: [android](), [architecture](), [architecture-pattern](), [mvc](), [mvi](), [mvvm](), [patterns]() ### AI overview This tutorial explains why Android applications need architecture patterns and compares approaches including MVC, MVP, MVVM, MVI, and MVU. It emphasizes separating application code into distinct components rather than placing all code in an Activity. ### Source excerpt As an Android developer, one of the questions I constantly see asked within the community is "what architecture pattern should I use?" This discussion usually leads to a handful of buzzwordy acronyms: MVC MVP MVVM MVI MVU?? (We don't talk about this but apparently it's the new kid on the block) This can be really intimidating to new Android devs, as well as seasoned veterans who are constantly questioning if they're using the right one. Whether you're trying to decide which one to learn, or wondering if the one you already use is best for you, this post will help lead you to the right decision. ## MVI - The Good, the Bad, and the Ugly DevFeed: [MVI - The Good, the Bad, and the Ugly]() Original publisher: [Read original article]() Published: 2019-07-24T18:52:57Z Content type: opinion Language: en Sources: [Posts on Adam Bennett]() Topics: [Redux](), [Android](), [Development](), [reactive]() Tags: [algorithms](), [android](), [android-development](), [architecture](), [article](), [blog](), [career](), [compose](), [development](), [engineering](), [finance](), [flow](), [functional](), [growth](), [java](), [jetpack](), [kotlin](), [money](), [mvi](), [opinion](), [opinions](), [patterns](), [reactive](), [reactive-programming](), [software](), [startups](), [testing](), [thoughts](), [training](), [tutorial](), [ui]() ### AI overview An opinionated introduction to MVI, also known as Redux, for Android development. The article explains its unidirectional data flow, event and result modeling, reducers, sealed classes, and integration with functional reactive programming, while considering its benefits and downsides. ### Source excerpt For those keeping track of the latest trends in view architecture patterns, MVI, aka Redux, has seemingly become the latest and greatest for Android Development. There's tonnes of things to love about MVI - but what are the downsides, and what should you know going into it? For the sake of this article, I'm basing my thoughts on an adaptation of MVI which I've used for a while now for both personal projects and at work. You can find the important classes here for a deeper dive, but I'll run through the basics here too. ## Testing By Design DevFeed: [Testing By Design]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2019-05-22T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [Testing](), [Android](), [App]() Tags: [android](), [architecture](), [mvi](), [mvvm](), [presentation](), [testing](), [video]() ### AI overview A presentation about designing Android app architectures for efficient and maintainable testing. It discusses how MVP and MVVM improve testability and presents testing-first architecture, including MVI, as a way to write and maintain resilient tests with less code. ### Source excerpt Together with my friend Kostiantyn Tarasenko we talked about testing android apps. Building an efficient and maintainable test suite for an app is challenging. Design patterns like MVP or MVVM help decouple responsibilities so that it becomes easier to write testable code. What is the next level though? How can we get more out of our tests? ## Advanced Model-View-Intent: The Missing Guide DevFeed: [Advanced Model-View-Intent: The Missing Guide]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-06-26T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [RxJava](), [Library]() Tags: [guide](), [library](), [mvi](), [rxjava]() ### AI overview A presentation about Model-View-Intent (MVI) shares practical tips and introduces RxRedux, a library for building state machines with RxJava. ### Source excerpt Together with my friend Kostiantyn Tarasenko we talked about Model-View-Intent (MVI) and were sharing some tips that worked well for us. We also introduced a library to help us build state machines with RxJava called RxRedux ## Reactive Apps with Model-View-Intent - Part 8: Navigation DevFeed: [Reactive Apps with Model-View-Intent - Part 8: Navigation]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-05-06T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [navigation](), [reactive](), [RxJava](), [Android]() Tags: [android](), [architecture](), [blog-post](), [callback](), [lambda](), [mvi](), [navigation](), [reactive](), [rxjava]() ### AI overview This tutorial explains how to apply the Coordinator pattern to navigation in an Android Model-View-Intent architecture. It describes passing a navigation callback into MviBasePresenter and reusing the state-rendering observable with an RxJava operator to trigger navigation when a particular state is reached. ### Source excerpt In my previous blog post we discussed how the Coordinator pattern can be applied on Android. This time I would like to show how this can be used in Model-View-Intent. If you don't know yet what the Coordinator pattern is I highly recommend to go back and read the introdcution. ## In-App Navigation with Coordinators DevFeed: [In-App Navigation with Coordinators]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-05-05T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [navigation](), [Architecture & Design](), [Development]() Tags: [android](), [android-development](), [architecture](), [mvi](), [mvvm](), [navigation](), [patterns]() ### AI overview This article examines the Coordinator pattern for organizing in-app navigation in Android applications. It discusses how navigation logic can become tightly coupled to activities or fragments and considers how coordinators can separate navigation flow logic from those UI components. ### Source excerpt Over the last years we have established best practices for writing android apps: clean architecture, architectural patterns like MVP, MVVM, MVI, Repository pattern and so on. But what about in-app navigation? In this blog post I would like to talk about the Coordinator pattern and how we could apply this pattern in android development to organize our in-app navigation code. ## Reactive State Management with Model-View-Intent DevFeed: [Reactive State Management with Model-View-Intent]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-10-05T00:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Architecture & Design](), [Android](), [reactive](), [RxJava](), [Redux]() Tags: [android](), [flow](), [mvi](), [patterns](), [rxjava](), [state-management]() ### AI overview A presentation explains Model-View-Intent (MVI) as an architectural pattern for managing application state on Android. It covers synchronous and asynchronous data, component lifecycles, navigation, process death, comparisons with Flux and Redux, and unidirectional data flow with RxJava. ### Source excerpt Managing application state is not a simple topic especially on Android with a synchronous and asynchronous source of data, components having different lifecycles, back stack navigation and process death. Model-View-Intent (MVI) is an architectural design pattern to separate the View from the Model. In this talk, we will discuss the idea behind MVI and how this pattern compares to other architectural patterns like Flux, Redux, Model-View-Presenter or Model-View-ViewModel. ## Reactive Apps with Model-View-Intent - Part 7: Timing (SingleLiveEvent problem) DevFeed: [Reactive Apps with Model-View-Intent - Part 7: Timing (SingleLiveEvent problem)]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-09-13T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [App]() Tags: [architecture](), [display](), [livedata](), [mvi](), [reactive](), [screen](), [state](), [state-management](), [viewmodel]() ### AI overview This article explains how Model-View-Intent and proper state management can address the recurring Snackbar problem associated with SingleLiveEvent when Android views are recreated or revisited. It presents immutable view state and unidirectional data flow as the proposed approach. ### Source excerpt In my previous blog post we discussed the importance of proper state management and why I think introducing a SingleLiveEvent as discussed in Google's Architecture Components GitHub repo is not a good idea because it just hides the real underlying problem: state management. In this blog post I would like to discuss how the problem SingleLiveEvent claims to solve can be solved with Model-View-Intent and proper state management. ## ViewModel and LiveData: State-Management Pitfalls in Google's Architecture Components Samples DevFeed: [ViewModel and LiveData: State-Management Pitfalls in Google's Architecture Components Samples]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-06-25T09:00:00Z Content type: opinion Language: en Sources: [Hannes Dorfmann]() Topics: [Programming](), [reactive](), [Google](), [RxJava](), [GitHub](), [REST API]() Tags: [architecture](), [blog-post](), [google](), [livedata](), [mvi](), [mvvm](), [pitfalls](), [reactive](), [reactive-programming](), [rxjava](), [state-management](), [viewmodel]() ### AI overview An opinionated review of ViewModel and LiveData in Google's Architecture Components samples, focusing on state management, pagination, lifecycle awareness, and differences from RxJava. ### Source excerpt At I/O 2017 Google surprised us with a new initiative: Architecture Components. I really appreciate this initiative. In this blog post I would like to share my thoughts about ViewModel and some pitfalls you might stumble upon when using ViewModel and LiveData by taking a look at the official Google samples. ## Reactive Apps with Model-View-Intent - Part 6: Restoring State DevFeed: [Reactive Apps with Model-View-Intent - Part 6: Restoring State]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-05-02T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [RxJava](), [Android](), [Processes](), [navigation](), [push-notification]() Tags: [android](), [blog-post](), [mvi](), [navigation](), [process](), [push-notification](), [reactive](), [rxjava]() ### AI overview This article explains how Model-View-Intent and unidirectional data flow can support state restoration in Android applications. It covers restoring in-memory state across view lifecycle events such as orientation changes and back-stack navigation, as well as persistent state across process death. The examples discuss Mosby, RxJava streams, presenters, and push-notification updates. ### Source excerpt In the previous blog posts we have discussed Model-View-Intent (MVI) and the importance of unidirectional data flow. That simplifies state restoration a lot. How and why? We will discuss that in this blog post. There are two scenarios we will focus on in this blog post: Restoring state "in memory" (for example during screen orientation change) and restoring a "persistent state" (for example from Bundle previously saved in Activity. ## Reactive Apps with Model-View-Intent - Part 5: Debugging with ease DevFeed: [Reactive Apps with Model-View-Intent - Part 5: Debugging with ease]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-03-17T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [debugging](), [Logging](), [reactive](), [Crashlytics](), [RxJava](), [JSON]() Tags: [crashlytics](), [debugging](), [json](), [logging](), [mvi](), [reactive](), [rxjava]() ### AI overview This tutorial explains how the Model-View-Intent pattern and unidirectional data flow can simplify debugging unreproducible crashes. It shows how to log user intents and rendered view state, serialize the state as JSON, and include these logs in crash reports using Crashlytics or another crash-reporting tool. ### Source excerpt In the previous blog posts we have discussed the Model-View-Intent (MVI) pattern and it's characteristics. In part 1 we have talked about the importance of an unidirectional data flow and application state that is driven by the "business logic". In this blog post we will see how this pays off when it comes to debugging to simplify the life of developers. [Next page]()