Which came first the view or the view model?

An Examination of Strategy: View-First vs ViewModel-First MVVM

In the application development, the architecture pattern “MVVM” (Model-View-ViewModel) frequently emerges as an interview topic, a code base UI philosophy, and/or a point of contention to which is better between MVP, MVC or MVVM. This creates particular confusion when the platforms in question are Android and WPF (Windows Presentation Foundation). At a glance, both platforms champion the MVVM pattern. However, a closer inspection reveals subtle yet distinct differences in their approach. For professionals navigating both terrains, grasping these variances can be indispensable.

To set the stage for a deeper dive, it’s crucial to understand the primary implementations of MVVM across these platforms:

View-First MVVM — A Glimpse into Android

Whether you’re rooted in the classic XML-based UI layouts or venturing into the realms of Jetpack Compose, Android’s inclination is unmistakably towards a View-First MVVM approach. A snapshot of this approach reveals:

• Origin in the View: Android’s journey commences with the view. Whether it’s an Activity or Fragment, it serves as the genesis, eventually binding the ViewModel.
• ViewModel’s Lifecycle Cognizance: Although detached from the view specifics, the ViewModel is typically attuned to the view’s lifecycle, courtesy of lifecycle-aware components.
• Power of Data Binding: A testament to Android’s capabilities is its formidable Data Binding library, enabling seamless observation of ViewModel changes by the view.
• Key Strengths: Novices often find solace in beginning with a tangible, visual component, making the process intuitive. Additionally, the approach provides the leeway for effortless view replacements, a boon when numerous views resonate with a single ViewModel.

ViewModel-First MVVM — WPF’s Philosophy

Transitioning to WPF offers a different narrative. Here, the paradigm subtly shifts.

• The Primacy of ViewModel: WPF’s narrative often starts with the ViewModel. This entity essentially orchestrates the associated view.
• Lifespan Independence: Contrasting Android, here, the ViewModel remains blissfully unaware of the view’s lifecycle, concentrating singularly on data and operations.
• Data Binding Augmented with Commands: While WPF celebrates robust data binding, it elevates the experience by introducing commands and facilitating direct binding of actions to ViewModel methods.
• Key Strengths: This approach is a haven for testing enthusiasts, offering streamlined unit testing due to the ViewModel’s prominence and lifecycle detachment. Furthermore, for applications laden with intricate navigational logic, this approach guarantees a fluid, consistent flow.

As we journey further, we’ll delve deeper into these nuances, ensuring a comprehensive understanding and equipping developers to harness the strengths of both worlds.

Let’s Talk About Android

When discussing Android, it’s crucial to underline that our projects aren’t the usual run-of-the-mill Android applications. Our work’s unique nature often requires multiple views to be up and running concurrently — ranging from as few as 3 to a staggering 20. Navigating such a dynamic and layered UI can undoubtedly be a challenge, especially when ensuring optimal performance and memory management.

In a typical scenario, if all these view models were active and operational all the time as the ViewModel-First approach, it would necessitate a significant restructuring of our design. One possible solution would be to leverage constructs like SharedFlow. SharedFlow's standout feature is its judiciousness: it won't emit unless there's an active listener. This ensures efficient data flow without unnecessary emissions, particularly vital when we consider multiple views.

However, even with solutions like SharedFlow, one pertinent question remains: Why should the ViewModel be operational if its corresponding view isn’t? This question brings us to a pivotal realization: the strength of the View-First approach, especially in our unique context.

View-First: An Asset in Memory Management

The View-First MVVM approach inherently aligns with the philosophy that the view drives the process. Therefore, if a view isn’t present or active, its corresponding ViewModel shouldn’t be in action either. In scenarios like ours, where numerous views co-exist, this approach can be a game-changer for several reasons:

1. Reduced Memory Footprint: By ensuring that only the ViewModels of active views are operational, we significantly reduce the memory footprint. Inactive views don’t burden the system with redundant data or operations.
2. Enhanced Performance: With fewer active processes (thanks to fewer operational ViewModels), the system can allocate resources more efficiently, leading to smoother application performance.
3. Intuitive Lifecycle Management: With the view driving its ViewModel, lifecycle events become more intuitive to handle. If a view is destroyed or paused, it can seamlessly signal its ViewModel to cease operations or release resources.

Moreover, a deep dive into the expansive amount of Android documentation and myriad examples available in the developer community consistently echoes the favorability of the View-First approach (even though distinguishing between these two types is not talked about). This isn’t just a circumstantial preference but appears to be a deliberate design choice, highlighting the platform’s architectural philosophy. When the majority of resources, tutorials, and expert commentaries lean toward a particular methodology, it underscores its relevance and applicability. Newcomers and seasoned developers alike are guided by this treasure trove of knowledge, reinforcing the understanding that, for Android, the View-First paradigm isn’t just an option but the recommended path forward. Adopting this approach ensures not only alignment with the broader Android developer community but also an easier time understanding, implementing, and troubleshooting based on the vast amount of available resources.

Let’s Dive into WPF/Xamarin

Transitioning from Android’s ecosystem, the world of WPF (Windows Presentation Foundation) and Xamarin presents a different narrative, driven by its own set of principles, challenges, and strategies. Our endeavors within these platforms are also distinctive, and understanding their architecture becomes pivotal.

Unlike the typically concurrent multiple views we handle in Android, WPF and Xamarin applications often focus on a different form of complexity. With rich desktop and cross-platform mobile applications, the challenges span across different devices, screen sizes, and operating systems.

ViewModel-First: The Cornerstone of WPF/Xamarin

WPF and Xamarin lean more towards the ViewModel-First MVVM approach. The ViewModel takes the center stage, serving as the linchpin that orchestrates the view and manages data flow.

1. Centralized Logic and Data Handling: By starting with the ViewModel, developers have a centralized location to manage data and logic. This makes the codebase cleaner and more modular, facilitating easier maintenance and scalability.
2. Greater Testability: One of the prime advantages of this approach is the ease of unit testing. With ViewModels devoid of UI logic, testing becomes more streamlined, focusing on business logic and data handling.
3. Dynamic View Binding: ViewModel-First ensures that the ViewModel can dictate which view to bind to based on logic or conditions. This dynamic binding is especially valuable in cross-platform solutions like Xamarin, where device-specific views might be necessary.

An analysis of the extensive documentation and numerous examples for WPF and Xamarin further cements the ViewModel-First strategy’s dominance. Developers venturing into these platforms will find a consistent narrative, promoting this approach as the gold standard. This standardization, evident in tutorials, forums, and expert discourses, isn’t accidental. It signifies the platform’s architectural leanings, ensuring developers adopt strategies that extract the best performance and maintainability from their applications.

When most resources and community discussions for WPF and Xamarin champion the ViewModel-First approach, it underscores its significance. Adhering to this methodology aligns developers with industry best practices, ensuring smoother development cycles and optimal application performance.

In Conclusion: The MVVM Conundrum — The View or the ViewModel?

Navigating the maze of MVVM often feels akin to the age-old question: which came first, the chicken or the egg? Similarly, in our realm, it’s the view or the ViewModel. This fundamental question, while seemingly simple, embodies the breadth and depth of MVVM’s versatility. And like many things in software development, there isn’t a one-size-fits-all answer.

Both View-First and ViewModel-First approaches have their merits. Their applicability is shaped not just by the platform in use but also by the specific challenges and needs of the project at hand. While platforms like Android naturally lean towards the View-First paradigm and WPF is commonly associated with ViewModel-First, it’s crucial to understand that neither platform is rigidly confined to one approach.

The confusion surrounding MVVM often stems from the lack of awareness that both strategies coexist. Newcomers might feel cornered into one approach, not realizing that there’s another way. This article’s essence is to illuminate these twin paths within the MVVM landscape. By acknowledging and understanding both, developers can make more informed decisions, tailored to their project’s needs.

In the selection of many, many software design patterns, MVVM shines as a testament to flexibility and adaptability. Whether you’re team View-First or team ViewModel-First, remember that the end goal remains the same: creating robust, maintainable, and efficient applications. I hope that by shedding light on these two approaches, I’ve cleared some of the mist surrounding MVVM and empowered developers to embrace the approach that resonates most with their vision and objectives.