MVVM Not always better than MVP

MVP OR MVVM ??🥱🥱

Notes here i won’t make blog for the implementation for each of this

1- is my app can success without clean architecture?
2- ideal clean architecture meaning ?
3- mvvm over mvp and The opposite ?
4- can i combine both in one project?
5- when i use mvvm and mvp ?

1- In most cases we can not build an app purely on a single pattern, and that’s fine.

be relax :)
here Telegram Project you can check if and tell me if it use mvp or mvc or mvvm but don’t mean i told you not make no architecture i will say when should i don’t use architecture later

2- The main things is to separation in the view, the model and the logic between them

3- what is the Ideal Architect It should be

So MVVM and MVP Are Ideal

• flexible to changes of logic and design,
• comfortable to test at the same time.
• It should be independent of external frameworks
• it should be simple in structure

4- mvvm over mvp (don’t take about case for using here)

• in MVVM Provides clearer separation of the UI and application logic but in MVP View connects to the Model via data binding directly this is very strong point that make you go to mvvm rather than mvp and will make test easier as there is no dependency on the View and in mvp you can mock data quickly
• Code size is quite excessive in mvp rather than mvvm as it use a lot interfaces for interaction between layers and each iterface could has many method used for path data between layer although mvvm my use the same number of class but less code in it
• has life cycle + support by google + save state (for interview 😂😂😂)

5- mvp over mvvm (MVVM Drawback)

despite the useful side of use DataBinding
- No need for findViewById, setOnClickListener or similar code
- Possibility to write custom xml-attributes with the help of Binding adapters.-

• in mvvm using DataBinding make Some parts of the code in XML, thus complicating either debugging or development
• in mvvm using DataBinding make Writing tests for an application won’t be easy.
• Maintainability
  MVP is easy to learn, amend, add features. Adding new features with MVVM may require some experience with the library.
• It mixes UI and code just like JSP and ASP.NET does.
• There is a hell of a lot more to an app than just typing in some mundane api like findViewById. Reading code, understanding it, testing it and maintaining it are the biggest time consumers of all. Stick with MVP.

6- you do not have to stick strictly with MVP or MVVM.

7- In most cases we can not build an app purely on a single pattern

7- When Use MVVM and Mvp

• In cases where binding with DataContext is not possible, most developers prefer MVP (Windows Forms being a great example). MVVM is of preference in cases where binding with DataContext is possible, as there are less interfaces and less code to maintain.
• but the main point that makes us choose MVP over MVVM is SIMPLICITY … when we have a SIMPLE screen that holds Bi-Directional-Flow between the UI and the Model (where user interactions need to request something from our Model layer) , but it updates very limited views when our Model responds with the result from the domain, MVP is the best choice
• It is bad Idea to use MVP when the UI is updated without user inter-actions, like updating UI when an event happens in the Model Layer, this approach is closer to MVVM more than MVP
• use mvvm when View is not SIMPLE any more, we have too much Views that will be affected by the updates done from our Model Layer, and handling all those views on different requests from Model Layer will be very hard to maintan
• We can use MVVM also when our screen has a One-Directional-Flow,(events are coming from the Model Layer and affecting the UI without any user interactions)