DEV Community

MVWTF: Demystifying Architecture Patterns

Adam McNeilly on August 16, 2019

Originally published on Android Essence. You can watch this talk from Android Summit on YouTube: As an Android developer, one of the que...
Collapse
 
bbessa profile image
Bernardo Bessa

That soft explanation about Android app architecture was kind of sublime, sir... Really!
Avoiding some might complex architectural concepts as Flux or Redux, for example, allows a easy compreension of our need to think what we should consider when building something.
I'd add just a detail about MVC. A lot of Android apps are just some kind of frontend component in a bigger architectural perspective, so the MVC you suggest makes sense. However, if the app purpose is to be a "single point" connected with some kind of datasource (files, databases, web services, etc.), I suppose the model can follow a Domain Driven Design, where you apply the Business Logic on your models (where you can/cannot use it to handle data, as well, or apply other kind of layer responsible for that business logic.).
Anyway, it was a refreshing way to study some of the complexity around Android app architecture.

Collapse
 
dmytrokarataiev profile image
Dmytro Karataiev • Edited

I really liked the article and the examples. I tried to play with the MVI example a bit more and refactored your example here: github.com/dmytroKarataiev/MVI-Exa...
My main motivation was to understand if we can re-use viewmodels with different Stores and also merge multiple viewmodels in a single reducer. Which I think I was able to achieve. I'll have to experiment how different threads will work with the reducer and if I need to add synchronization.

Collapse
 
shakenbeer profile image
Sviatoslav Melnychenko
  1. MVC diagram is missing the link between a model and a view. The view observes the model in MVC.
  2. MVI is not a pattern. Disagree? Try to draw a diagram, as you have for other patterns. It's hard because MVI really depends on implementation. Though, MVI is a good helper for any other pattern of choice.
Collapse
 
adammc331 profile image
Adam McNeilly

I think MVI is a pattern and a diagram could be drawn easily. I would just replace the View portion of the redux diagram in the post with a ViewModel or Presenter from the other diagrams.

Collapse
 
erdo profile image
Eric Donovan

I like the post! A broad overview of architectures (and with actual code samples) like this is very helpful. I personally ended up with a different conclusion for android architectures though:

For what it's worth, I don't like MVI much at all. In theory it sounds great, but in practice I've found it requires large amounts of boiler plate for even simple UIs. Once we get to non trivial UIs (multiple loading elements, form validation etc), screens seem to take days instead of hours to implement. (To be fair I am also not a massive fan of MVVM as it's typically implemented - but it's ok).

I wrote something quite similar to your article that details my thoughts on it here: erdo.github.io/android-fore/00-arc...

Collapse
 
adammc331 profile image
Adam McNeilly

I agree, MVI is a lot of work that we don't often need for simple pages that just load and display data. If there are a lot of moving parts/components to interact with, or flows based on complex decision trees, having that unidirectional state management can help a lot, though. I just hope this post helps highlight the differences well enough that people are able to decide for themselves. :)

I like your post! Your diagrams were given much more TLC than mine haha

Collapse
 
jnareb profile image
Jakub Narębski

@adammc331 : There is an error in the article, namely all of the Model-View-Controller images are Model-View-Presenter diagrams.

Collapse
 
adammc331 profile image
Adam McNeilly

MVC is often described in different ways unfortunately, there's usually not a consistent answer.

How do you view the flow of data in MVC? And if what we have here is really MVP, what would you change about the MVP diagrams in this post?

Collapse
 
jnareb profile image
Jakub Narębski

Maybe I was not entirely clear. What I menat is that three first figures use the same image, with Model, Presenter, View and User nodes. (One at the beginning of the "MVC Diagram", one in "Why Don't We Use This On Android?" subsection, and one in "Model-View-Presenter").

They use exactly the same IMG tag, with the same image URL, and the same ALT attribute.

Thread Thread
 
adammc331 profile image
Adam McNeilly

Ah! So sorry! Will fix!

Thread Thread
 
adammc331 profile image
Adam McNeilly

I thought I had the right picture but that the diagram itself was wrong. 🙈 Will fix once I'm at a computer.

Collapse
 
adammc331 profile image
Adam McNeilly

Fixed! Thanks for pointing it out for me. :)

Collapse
 
danielgomezrico profile image
Daniel Gomez

Thanks for sharing this, currently I use MVP, Don't get me wrong but it feels to me that mvvm was borned also from "the boilerplate that comes from MVP contracts", I saw some people criticizing that, without realizing that this is a problem from OOP languages itself besides than just an MVP problem. Another thing that worries me about MVVM is that all of the presentation code is moved into the view, and so, only testable via Espresso or Roboelectric, which makes me worry about moving into this patterns. What do you think about this two ideas?

Collapse
 
kidkkr profile image
kidkkr

I like the word Model-View-Intent than Flux or Redux or something.

Collapse
 
davidszabo97 profile image
Dávid Szabó

Hello Flux

Collapse
 
akashbisariya profile image
Akash Bisariya

Nice Article, completely explained in a very easy and understandable manner. Thank you...

Collapse
 
adammc331 profile image
Adam McNeilly

I'm glad you found this helpful!