# MVVM Published articles for MVVM. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Sharing ViewModels Across Android and iOS in Kotlin Multiplatform Projects DevFeed: [Sharing ViewModels Across Android and iOS in Kotlin Multiplatform Projects]() Original publisher: [Read original article]() Published: 2026-03-02T00:00:00Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [MVVM](), [multiplatform](), [Mobile](), [android-development](), [Compose]() Tags: [android](), [architecture](), [compose](), [design-patterns](), [ios](), [kmp](), [kotlin-multiplatform](), [multiplatform](), [mvvm](), [viewmodel]() ### AI overview This article explains the MVVM pattern and examines how sharing ViewModels across Android and iOS affects developer experience in Kotlin Multiplatform projects. It discusses separation of concerns, binders, Compose, SKIE, and Android ViewModel lifecycle behavior, including configuration changes. ### Source excerpt Sharing ViewModels between platforms affects the iOS developer experience. In this post we will discuss this topic and some possible solutions in KMP projects that respect the native feel of iOS and Android. ## 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... ## 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 ## Using annotations to improve iOS APIs on Kotlin Multiplatform DevFeed: [Using annotations to improve iOS APIs on Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2023-09-19T00:00:00Z Content type: article Language: en Sources: [Posts on Marco Gomiero]() Topics: [Kotlin Multiplatform](), [interoperability](), [iOS](), [Objective-C](), [Swift](), [Kotlin](), [multiplatform]() Tags: [architecture](), [coroutine](), [interoperability](), [ios](), [kotlin](), [kotlin-multiplatform](), [mvvm](), [objective-c](), [swift]() ### AI overview This article explains how Kotlin 1.8 annotations can improve iOS APIs in a Kotlin Multiplatform project. It describes using @HiddenFromObjC and @ObjCName to expose iOS-specific implementations with clearer names while keeping shared business logic and reducing misleading duplicate class names. ### Source excerpt Kotlin 1.8 has introduced new annotations to improve the interoperability of Kotlin with Objective-C and Swift: @ObjCName: allows to customize the name that will be used in Swift or Objective-C @HiddenFromObjC: allows hiding a Kotlin declaration from Objective-C (and Swift). @ShouldRefineInSwift: it marks a Kotlin declaration as swift_private in the Objective-C API, allowing to replace it with a wrapper written in Swift. You can see the release announcement for more details about the interoperability improvements introduced with Kotlin 1.8. ## VIPER Architecture for iOS Apps DevFeed: [VIPER Architecture for iOS Apps]() Original publisher: [Read original article]() Author: Surbhi Gupta Published: 2023-05-18T14:59:24Z Content type: tutorial Language: en Sources: [ymedialabs-innovation - Medium]() Topics: [iOS](), [Code](), [business logic](), [ui](), [navigation](), [mvc]() Tags: [apps](), [architecture](), [business-logic](), [code](), [controllers](), [flow](), [ios](), [modular](), [mvc](), [mvvm](), [navigation](), [patterns](), [swift](), [ui](), [viper]() ### AI overview This tutorial explains VIPER, an architectural pattern for iOS apps. It describes how VIPER divides each module into View, Presenter, Interactor, Entity, and Router components, with separate responsibilities and delegation-based communication. ### Source excerpt What is a Good Architecture? Architecture serves as a blueprint for a system. It provides a mechanism to communicate between various components and abstracts the complexity. It is important to separate out code components so that they are identifiable, serve a single purpose/responsibility and also fit logically. Code should be scalable, stable upon expansion, and flexible, which brings in the need for a good architecture. A good architecture not only helps in the success of the product but also allows for easy maintenance and makes people's lives easier. This article will talk about VIPER architecture, which is used to build many large projects. What is VIPER? VIPER is an architectural pattern like MVC and MVVM. One of the major issues with MVC and MVVM is bulky controllers. VIPER solves this problem by following Single Responsibility Principle and making the code more modular. Flow of Control Each module created with VIPER has five classes, each with their own responsibilities. No class does anything other than the specified role. These classes are listed below: View: It is responsible for only maintaining and displaying the view. It picks up any user interactions and passes the information to the presenter to decide the next step. Unlike other architecture patterns like MVC or MVVM, its sole responsibility is to manage and show the UI. Presenter: It is the only class that interacts with all other components except Entity. It is the decision-making engine for routing the flow. Interactor: It interacts with Entity and contains business logic. This class is where all the API calls and database interactions are added. Entity: Data model that is used by the interactor. Router: It does all the wire-framing or navigation from one module to another based on the information passed by the presenter. An ideal folder structure would be like below: Ideal Folder Structure with VIPER The communication between various components follows a delegation pattern. One component calls ## 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. ## Improving shared architecture for a Kotlin Multiplatform, Jetpack Compose and SwiftUI app DevFeed: [Improving shared architecture for a Kotlin Multiplatform, Jetpack Compose and SwiftUI app]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2022-06-26T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [Kotlin Multiplatform](), [Jetpack Compose](), [SwiftUI](), [Kotlin](), [Mobile]() Tags: [android](), [android-jetpack](), [app](), [app-architecture](), [architecture](), [article](), [compose](), [coroutines](), [flow](), [ios](), [jetpack](), [jetpack-compose](), [kotlin](), [kotlin-coroutines](), [kotlin-multiplatform](), [mobile](), [multiplatform](), [mvvm](), [swiftui](), [viewmodel]() ### AI overview This tutorial explains how to improve a shared application architecture for Kotlin Multiplatform, Jetpack Compose, and SwiftUI. It replaces duplicated suspendable and non-suspendable methods plus platform-specific callbacks with Kotlin and Swift wrapper code that allows Swift to consume Kotlin Flow, enabling a single UseCase method that returns a Flow. ### Source excerpt A couple of years ago I started working on a pet project to manage personal finances, named MoneyFlow. This project soon became a personal playground for a Kotlin Multiplatform mobile app and in a previous article, I journaled all the steps that lead me to a satisfying (at least for that time) shared app architecture. Choosing the right architecture for a [new] Kotlin Multiplatform, Jetpack Compose and SwiftUI app ## 🙅♂ Don't let ViewModel know about framework level dependencies DevFeed: [🙅♂ Don't let ViewModel know about framework level dependencies]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2021-09-17T12:18:27Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Android](), [android-app-development](), [Memory Leaks](), [Testing]() Tags: [android](), [android-app-development](), [framework](), [kotlin](), [maintainability](), [memory-leaks](), [mvvm](), [software-architecture](), [testing](), [unit-tests]() ### AI overview This Android development article explains why ViewModels should avoid holding Android framework references such as Activity, Context, View, or Drawable. It connects framework-aware ViewModels with memory leaks and reduced testability, modularity, and maintainability. ### Source excerpt Explore best practices for Android ViewModels. Learn why keeping framework references out of ViewModels is crucial for testing and preventing memory leaks. ## Thoughts about Event Handling on Android DevFeed: [Thoughts about Event Handling on Android]() Original publisher: [Read original article]() Author: Márton Braun Published: 2020-06-09T18:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Android](), [ui](), [navigation]() Tags: [android](), [event](), [kotlin](), [marton-braun](), [mvvm](), [navigation](), [ui](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview This theoretical introduction explains why ViewState alone cannot represent one-time communication from an Android ViewModel to a View. It presents events, also called view effects, for messages and navigation triggers that should be processed only once, and discusses lifecycle awareness and sticky state as related challenges. ### Source excerpt In MVVM-like view architectures, view state isn't enough to communicate from the ViewModel to the View. They have to be supplemented by some kind of events, which come with several challenges you should be aware of. ## 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 ## ## Live discussion of MVVM, coroutines, career progression, work-life balance, and football DevFeed: [Live discussion of MVVM, coroutines, career progression, work-life balance, and football]() Original publisher: [Read original article]() Published: 2019-08-25T00:00:00Z Content type: opinion Language: en Sources: [Antonio Leiva]() Topics: [Android](), [Kotlin](), [Coroutines]() Tags: [career](), [career-progression](), [coroutines](), [football](), [kotlin](), [life](), [mvvm](), [work]() ### AI overview A 50-minute live session answers questions about MVP versus MVVM, Rx versus Coroutines, career progression, work-life balance during parenthood, and other topics including football. ### Source excerpt Everything Android, Kotlin and other random topics ## 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. ## Practical iOS Layout Patterns with MVVM and UIView Subclasses DevFeed: [Practical iOS Layout Patterns with MVVM and UIView Subclasses]() Original publisher: [Read original article]() Author: Remind Published: 2019-05-28T00:00:00Z Content type: tutorial Language: en Sources: [Remind]() Topics: [iOS](), [ui](), [MVVM](), [Code review]() Tags: [code-review](), [ios](), [mvvm](), [patterns](), [ui]() ### AI overview This article describes iOS layout practices developed at Remind, including programmatic layout with SnapKit, code-reviewable layouts, and UIView subclasses that encapsulate reusable UI components. ### Source excerpt For the past couple years we've been implementing new features with an MVVM-driven approach. Over that time, we've settled into a couple of good (I think) patterns for implementing UIView subclasses, composing them in various view hierarchies, and handling the interactions between them. Ultimately, the goal of any iOS application is to get data presented onto the screen, so I thought I'd share what's been working well for us in that department. Layout In Code It's a debate where every team eventually has to pick a side: Do we use storyboards and xibs, or do we write all of our layout in code? To make a long story short, our team started with Interface Builder, but we abandoned xibs a few years ago and have gone to fully programmatic layout code using SnapKit as our DSL of choice. Every team's needs will be different, but we think it's important that we can effectively code-review each other's layout implementations and potentially have multiple people working on the same screen, neither of which are really practical with xibs. I'll leave it at that -- you do you. Use UIView Subclasses Liberally Nothing clutters the actual logic of a UIViewController like big blocks of view construction code. Whenever you have a logical grouping UI primitives (UILabel, UIImageView, UIButton, etc), make a UIView subclass that encapsulates all of the relative layout inside that view container. This allows you to build the view hierarchy for your view controller in simpler, larger, more logical chunks of UI. One of the more complex UI layouts we have in our application is the settings screen for a class the user owns. Let's look at the layout and focus on the CLASS SETTINGS section, which contains two items, each consisting of two labels and a switch. On our first iteration, our view controller maintained property accessors for each of those primitives: class ClassSettingsViewController: UIViewController { ... private let isPublicTitleLabel = UILabel() private let isPublicMessageLabel = ## 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? ## Data Binding on Android to implement the real MVVM DevFeed: [Data Binding on Android to implement the real MVVM]() Original publisher: [Read original article]() Published: 2019-05-15T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [Android](), [Kotlin](), [ui](), [data](), [Code](), [XML]() Tags: [android](), [code](), [how-to](), [kotlin](), [livedata](), [mvvm](), [ui](), [xml]() ### AI overview This tutorial explains how Android Data Binding connects data to UI elements, reduces boilerplate such as findViewById, and can be applied to the MVVM presentation pattern. It also describes integration with LiveData for responding to model changes and matching XML views with binding-object properties. ### Source excerpt Everything Android, Kotlin and other random topics ## Google I/O 2019 - What's new for Android Developers DevFeed: [Google I/O 2019 - What's new for Android Developers]() Original publisher: [Read original article]() Published: 2019-05-09T00:00:00Z Content type: article Language: en Sources: [Antonio Leiva]() Topics: [Android](), [Google](), [Kotlin](), [cameraX](), [Coroutines](), [Jetpack Compose](), [Jetpack]() Tags: [android](), [camerax](), [compose](), [coroutines](), [developers](), [google](), [google-i-o](), [kotlin](), [mvvm](), [viewmodel]() ### AI overview A video covering major announcements from the first Google I/O 2019 keynotes for Android developers, including Kotlin-first updates, Android Studio Beta 3.5, CameraX, ViewModel with SavedState and Coroutines, Jetpack Compose, and ViewPager2. It also demonstrates some of these announcements and links to Kotlin, coroutines, and MVVM learning resources. ### Source excerpt Everything Android, Kotlin and other random topics ## MVVM with architecture components: a step by step guideline for MVP lovers DevFeed: [MVVM with architecture components: a step by step guideline for MVP lovers]() Original publisher: [Read original article]() Published: 2018-12-12T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [Android](), [App]() Tags: [android](), [app-architecture](), [architecture](), [architecture-components](), [guide](), [mvvm](), [opinion]() ### AI overview This Android article explains MVVM to readers familiar with MVP, comparing how presenters and ViewModels communicate with views. It argues that MVP remains valid, MVVM is not necessarily better, immediate refactoring is unnecessary, and Android architecture components can generally still be used with MVP. ### Source excerpt Everything Android, Kotlin and other random topics ## Breaking The Buzzwords Barrier Part 3: ViewModel DevFeed: [Breaking The Buzzwords Barrier Part 3: ViewModel]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2018-06-01T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [mvc](), [Android]() Tags: [android](), [architecture-components](), [lifecycle](), [mvvm](), [rotation](), [viewmodel]() ### AI overview This tutorial explains the difference between the ViewModel concept in MVVM architecture and Android's lifecycle-conscious ViewModel class. It describes how Android Architecture Components retain ViewModel data across configuration changes such as rotation. ### Source excerpt So far we've covered four big buzzwords used in our application: Model-View-ViewModel Room RxJava Repository Pattern Now, we should circle back to the beginning. Following our diagram outlined in the previous parts, the next component we can begin to work on is our AccountViewModel: Naturally, this may bring up some confusion. We already discussed ViewModels in part 1. Well, depending on context, we may not be referring to the same thing. ## Breaking The Buzzwords Barrier Part 1: MVVM DevFeed: [Breaking The Buzzwords Barrier Part 1: MVVM]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2018-05-30T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [android-development](), [Development]() Tags: [android](), [android-development](), [architecture](), [business-logic](), [mvvm](), [patterns](), [state](), [viewmodel]() ### AI overview This tutorial introduces MVVM in Android development and explains how separation of concerns divides an application into the View, ViewModel, and Model. It describes how this structure can make applications easier to refactor and illustrates the approach with an account package from Cash Caretaker. ### Source excerpt When you're starting out with Android development, and even as an expert, you will hear about a lot of different architecture patterns. Anything from: Model-View-Controller Model-View-Presenter Model-View-ViewModel Model-View-Intent It can be extremely hard to know which one to pick, what their differences are, and why they matter. I will tell you that even with my three years of Android experience at the point of writing this, I have trouble answering the first two questions. I can, however, explain why these architecture patterns matter - and it boils down to the idea of separation of concerns. ## 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. [Next page]()