# MVVM MVVM (Model-View-ViewModel) is a UI architectural design pattern that decouples UI and non-UI code using data binding. 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. ## 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 = ## Sharing Android Business Logic with iOS Using Doppl and MVP Architecture DevFeed: [Sharing Android Business Logic with iOS Using Doppl and MVP Architecture]() Original publisher: [Read original article]() Published: 2016-12-12T17:00:07Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [cross-platform](), [Mobile](), [backends](), [MVVM](), [Dagger](), [Dependency injection](), [Testing](), [Objective-C]() Tags: [architecture](), [built-by-touchlab](), [code-sharing](), [dagger](), [dependency-injection](), [ios](), [mvvm](), [native](), [open-source](), [press](), [robolectric](), [thoughts]() ### AI overview The article explains Doppl, a set of tools and libraries built around j2objc for sharing Android business logic with iOS while keeping native user interfaces. It discusses applying MVP architecture, adding Dagger for dependency injection, and using sample test runners, while noting that iOS unit tests must currently be run from an Xcode app rather than the command line. ### Source excerpt Are you building a product and decided to build native? Do you have some no trivial business logic? If so then be sure to read this latest post. ## Rapid Guide on Two-Way Data Binding in Android DevFeed: [Rapid Guide on Two-Way Data Binding in Android]() Original publisher: [Read original article]() Author: hi@meedamian.com (Damian Mee) Published: 2016-01-07T00:00:00Z Content type: tutorial Language: en Sources: [Damian Mee | Blog | Portfolio | About]() Topics: [Android](), [MVVM](), [Code](), [XML]() Tags: [android](), [code](), [guide](), [java](), [mvvm](), [xml]() ### AI overview A concise Android tutorial showing the minimum setup needed to make two-way data binding work in an already configured project, using a simple UI, an Activity, a model, and a ViewModel. ### Source excerpt This post is not a comprehensive introduction to data binding in Android, it's a required minimum to get two-way data binding to work, that assumes your project to be configured for data binding already (if it's not, start here). Complete source code available here or here. Structure: role file Activity: MainActivity.java Model: not relevant here View: activity_main.xml ViewModel: MainState.java Activity This one just glues stuff together: public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super. ## Task Commands revisited DevFeed: [Task Commands revisited]() Original publisher: [Read original article]() Author: Andrew Khmylov Published: 2012-02-23T00:00:00Z Content type: tutorial Language: en Sources: [Despite the odds]() Topics: [MVVM](), [async](), [Code](), [implementation](), [test](), [WPF]() Tags: [async](), [bitbucket](), [code](), [implementation](), [mvvm](), [test](), [zip]() ### AI overview The article revisits an earlier TPL and MVVM command implementation, replacing its event-based asynchronous completion notification with an ExecuteAsync method that returns a Task. It presents an updated generic AsyncRelayCommand and explains its inner command, asynchronous execution, explicit ICommand.Execute implementation, and CanExecute handling. ### Source excerpt Half a year ago I blogged about using TPL with MVVM in a test-friendly way. My solution turned out to be pretty handy, though it was far from being perfect. In this post I will describe what was wrong with the initial implementation and can we slightly improve it. Looking at that solution right now, I wonder why did I decide to use event async pattern (providing the ExecuteCompleted event) in the first place. The intention was to notify the caller about completion of the asynchronous operation. That is what System.Threading.Task is used for this days, isn't it? So the obvious solution is to expose the ExecuteAsync() method returning the Task instance on the command class. Here is the source of the updated AsyncRelayCommand: public class AsyncRelayCommand : ICommand { private readonly RelayCommand _internalCommand; private readonly Func _executeMethod; public event EventHandler CanExecuteChanged { add { _internalCommand.CanExecuteChanged += value; } remove { _internalCommand.CanExecuteChanged -= value; } } public AsyncRelayCommand(Func executeMethod, Predicate canExecuteMethod) { if (executeMethod == null) { throw new ArgumentNullException("executeMethod"); } _executeMethod = executeMethod; _internalCommand = new RelayCommand(_ => { }, canExecuteMethod); } public AsyncRelayCommand(Func executeMethod) : this(executeMethod, _ => true) { } void ICommand.Execute(object parameter) { if (parameter is T) { ExecuteAsync((T)parameter); } else throw new ArgumentException("Parameter should be of type " + typeof(T)); } public Task ExecuteAsync(T parameter) { return _executeMethod(parameter); } public bool CanExecute(object parameter) { return _internalCommand.CanExecute((T)parameter); } public void RaiseCanExecuteChanged() { _internalCommand.RaiseCanExecuteChanged(); } } The code is pretty straightforward, here are the key points: Create an inner command that responds to CanExecute, RaiseCanExecute calls and handles subscriptions to CanExec ## MVVM + TPL + Unit tests DevFeed: [MVVM + TPL + Unit tests]() Original publisher: [Read original article]() Author: Andrew Khmylov Published: 2011-09-27T00:00:00Z Content type: tutorial Language: en Sources: [Despite the odds]() Topics: [MVVM](), [unit tests](), [async](), [Test-driven development](), [Web](), [WPF]() Tags: [async](), [asynchronous](), [callback](), [mvvm](), [tdd](), [testing](), [unit-tests]() ### AI overview The article discusses testing MVVM view-model commands that use the Task Parallel Library for asynchronous operations. It critiques static task creation for making dependencies difficult to mock and presents an ICommand wrapper that signals completion, allowing tests to synchronize with the asynchronous task. ### Source excerpt UPD: This implementation didn't work as well as expected, please read the follow-up article. Recently I've faced an issue with writing unit tests for view model commands that use Task Parallel Library for asynchronous operations. Searching over the web was not really helpful, so I spent some time designing the approach to handle such cases. The most common way to start tasks with TPL is by using one of the static Task.Factory.StartNew(...) methods. If you are mockist TDD guy, this should already raise an alert in your head. Static members are not test-friendly and do not allow you to inject mock dependencies into your module. One may say that using tasks is just an implementation details and should not be concerned when testing the behavior. I would agree if we were speaking about a regular async method that allows you to perform some action when its execution completes (in a form of callback or event, doesn't really matter). That simply doesn't work for me because the asynchrony is used inside the command handler, so there is no way to specify the continuation outside of the view model. My first (and probably the bad one) idea was to create a service for running the tasks. Then it would be easy to mock it and run tasks synchronously. Hopefully, I rejected this solution - creating another dependency just didn't sound right. I decided to create a special ICommand implementation instead that would notify me when the execution completes. This should do the trick because you can always use the thread sync primitives in the test environment to wait on the asynchronous task. For simplicity's sake I just created the wrapper around RelayCommand from MVVM Light Toolkit (you could use your favorite library or implement the command from scratch yourself). public class AsyncDelegateCommand: ICommand { private readonly RelayCommand _innerCommand; public event EventHandler ExecuteCompleted; public event EventHandler CanExecuteChanged { add { _innerCommand.CanExecuteChanged += value ## Building advanced MVVM commands, Part 1 DevFeed: [Building advanced MVVM commands, Part 1]() Original publisher: [Read original article]() Author: Andrew Khmylov Published: 2010-11-24T00:00:00Z Content type: tutorial Language: en Sources: [Despite the odds]() Topics: [MVVM](), [WPF](), [async](), [cancellation](), [Exception](), [Code]() Tags: [applications](), [async](), [asynchronous](), [cancellation](), [exception-handling](), [mvvm](), [thread](), [ui]() ### AI overview This tutorial presents an advanced DelegateCommand implementation for WPF and Silverlight applications using the MVVM pattern. It covers asynchronous execution, command states, cancellation, progress tracking, exception handling, UI updates through Dispatcher, and helper support for property-change notifications. ### Source excerpt If you follow the MVVM pattern while developing your WPF/Silverlight applications, then you are probably familiar with DelegateCommand (or RelayCommand, as it is called sometimes) model. In brief: it is an implementation of WPF/Silverlight ICommand that allows you to specify what the command should do by passing some delegate that performs execution logic (instead of using CommandBindings). Pretty simple, but powerful pattern. Dealing with MVVM a lot, I've build my own implementation of this pattern that lets you simplify its usage. Here are some common features, that you have to handle on your own by using classic DelegateCommand: Support for asynchronous execution (usually solved by generating additional code in ViewModel that handles async calls and free/busy indicator). Different command states (Free/Busy/Failed with exception) + UI reactions for those states. Support for execution cancellation and progress tracking (required for asynchronous commands) Before we start, I offer you to imagine a common command execution timeline. In my opinion it looks like: Initialize some data (generally, UI settings - clear collections, set some indicators,...) Perform main execution logic (can be synchronous or asynchronous) Perform some actions after execution (update UI based on execution result) And don't forget about exception handling and correct cross-thread calls for asynchronous commands (all UI changes have to be performed through Dispatcher). Let's start with a little helper class, that I called PropertyChangedNotifier. It's just a wrapper around IPropertyChangedNotifier that has OnPropertyChanged(string propertyName) method. This method raises underlying IPropertyChangedNotifier.PropertyChanged event. Also this class has VerifyPropertyName method that verifies if specified string corresponds to the actual property (this method is marked with [Conditional("DEBUG")] attribute and is only used while debugging your applications to find out possible bugs with invalid prope ## WPF/Silverlight visual states with DataTemplates DevFeed: [WPF/Silverlight visual states with DataTemplates]() Original publisher: [Read original article]() Author: Andrew Khmylov Published: 2010-11-19T00:00:00Z Content type: tutorial Language: en Sources: [Despite the odds]() Topics: [WPF](), [XAML](), [MVVM](), [ui]() Tags: [mvvm](), [progress](), [screen](), [state](), [threading](), [xaml]() ### AI overview This tutorial presents a WPF technique for switching among page, window, or control states by defining different DataTemplates. It contrasts this approach with VisualStateManager and Silverlight Activity Control, then demonstrates a welcome screen and a busy-progress state backed by a ViewModel. ### Source excerpt Consider a common task - you need to switch between different screens in your application, that represent various states (e.g. Normal/Loading/Error). How are you going to implement this? You can start with VisualStateManager and define appropriate visual states. Well, this will surely do the thing, but you will have to create lots of controls and manage their Visibility or Opacity. And what if you have a complex markup? And I suppose that switching the state will not remove invisible items from the visual tree. And even more, with VisualStateManager you are bound to Expression Blend, because, you know, it's not very convenient to edit VSM settings by hands in XAML (which I prefer, but it is a topic for another article). The second option that may fit well, if you just need something like "I'm busy!" overlay is Silverlight Activity Control. Works like a charm with RIA services, but I find it limited for complex scenarios (and it's not available for WPF). I've found another approach (it becomes especially useful with MVVM and improved DelegateCommand implementations - I will blog about this in a few days). The idea behind this technique is quite simple. You define different templates for different page/window/control states. Yeah, that's it. Let's start with our implementation. Our application will have only one page with 2 different states: A welcome screen, that hosts a button to start 'the heavy' calculation. Busy window" that shows information about the current processing progress. I decided to create a simple ViewModel as a backing storage for our UI properties. It has two properties - IsBusy that says whether some hard work is executing now, and Progress - simple execution progress indicator. Method StartCalculation runs a new thread executes a number of loop steps. On each step the executing thread is suspended for 100ms (to imitate a slow operation). Normally you will create a DelegateCommand that will handle all the execution logic, but I decided to keep thin