MVP/MVVM

  1. We need architecture because we want to maintain our product for a long time.
  2. We want to expand the product code.
  3. We want to write easily understandable code by other developers.
  4. We want easy to debug code.
  5. We want to unit test our code as much as we can cover.
  6. We want loose coupling between components.
  7. We want segregation of code so that it will have less complexity.
  1. Clear separation of responsibilities between components.
  2. This separation allows for an easier understanding and maintenance of the codebase.
  3. Modularity- Modularity allows you to e.g. switch to a different implementation of view component in order to completely change the application’s UI, while all other components remain intact.
  4. Easier unit testing. Since there are well-defined boundaries between components, it becomes much easier to test each component in isolation.
  5. Developers can work on building components independently.
  1. Need one more class which will have an implementation of each presenter.
  2. I need many interfaces for communication back from presenter to views.
  3. Need to pass the view object to the presenter implementing the class.
  4. If we change the orientation view will be destroyed again same procedure to reload the data.
  5. The view is dumb in MVP.
  6. One to one mapping between view and presenter.
  7. We pas the view object to the presenter.
  1. MVVP, your View is more flexible because it can bind to observable.
  2. VM is responsible to communicate to the repository or model
  3. UI can observe the changes from the view model.
  4. Less number of callbacks due to observing from the view model need not. have so many listeners.
  5. Architecture components(Jetpack libs) of android have better support in MVVM.
  6. Easy to write a unit test for the only View model.
  7. You can test it without awkward UI automation and interaction.
  8. Will retain the same view model on change the orientation so need not worry about orientation change.
  9. The presentation layer and the logic are loosely coupled.
  10. Transparent communication between layers increases performance.
  11. One ViewModel can provide data to many views (One to many relationships).
  1. For complex UI it overkills.
  2. Debugging would be difficult due to complex data binding.
  3. To much code to write many classes.
  4. Most of the time business logic is not so simple so I can't write in the view model.
  5. The inheritance we need but hard to provide for ViewModel.
  6. Cant reuse ViewModel even if we have repeated code in it.
  7. MVVM for beginners is hard to put to use.

--

--

--

Senior Android App Developer | Startup | Product base | Java | Kotlin | MVVM | Architecture components | Android Blogger

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aalishan Ansari

Aalishan Ansari

Senior Android App Developer | Startup | Product base | Java | Kotlin | MVVM | Architecture components | Android Blogger

More from Medium

Make your android smartphone to vibrate

Run App using Wi-Fi (Android Studio Update)

How to perform search using channel for Paging 3

How to create a simple coroutine in Kotlin, Android