Which architecture is best suitable to develop mobile app

AppDev how would you decide which architecture pattern is best suitable for which app.

How to decide which one is better.

As we all know there are many architecture patterns to implement a mobile app, and we can use anyone to develop any app. but every pattern has some if and but.

Every architecture pattern has some use case, when and why?

We have to decide very carefully which pattern is best suitable for our app.

first of all, we all have to understand that architecture is not decided on the basis of any single thing, 

Which architecture is best suitable for our app is decided on the basis of, User Interface, test case, business logic, app's user scale, etc.

No architecture pattern-

it's very rare that your app screen has no state and business logic, but it happens that there is no state and business logic in your screen, definitely you have to go with no architecture pattern.

there is no use of architecture patterns.

example- suppose you are going to develop a single screen app, where you are showing some textView or anything else using local string, or a button which will be opening another screen nothing else, in this case, there is no need of any architecture pattern.

1. Utilize no Architecture design if your screen doesn't speak with your Model Layer (like creation a server API call, or recovering something from database or preferences)
2. Utilize no Architecture design if your Screen doesn't require sparing it's state (nothing is refreshed on this screen after it draws it's views.

Multi Architecture Pattern-

Multi-module design versus single module architecture: Both MVVM and MVP can execute multi-module models or single module structures.

 I feel that this decision It's much more significant than picking among MVVM and MVP.

 On the off chance that you realize that your App will have huge and complex business logic, suppose a social community App or something to that effect,

 at that point you should utilize a multi-module architecture, this will permit you to keep the features isolated into modules, the structure time (if the module references and the dependency injection is appropriately done) will be linera_ish and It's going to assist you with working serenely with your group. 

In the event that you pick a single module design, you have to remember that the structure time is going to increment as you include new libraries and new highlights. 

On the off chance that you realize that the task isn't complex enough for a multi-module design, at that point this is your right decision.

 Also, you generally can transform your single module architecture into a multi-module architecture on the off chance that you keep your class efficient under an MVP/MVVM design.

MVC "Model View Controller"-

The MVC architecture is another good approach to develop apps, but the main disadvantage of this architecture pattern is, its test-ability. within MVC pattern it is very hard to test that what action is performed after when it UI is finished.

1. We can utilize MVC when our screen is sufficiently basic (like the no architecture model), yet it have to speak with our Model layer ... also, this is the reason we have to place the man in the center ... our Model class.
2. We can utilize MVC when our screen has a One-Direction-Flow of activities, all connections by the user do influence the Model, yet it's result doesn't influence the UI.

MVP "Model View Presenter"-

This architecture is an advanced version of MVC. In MVP pattern our screen communicate with model, and wait for the response to update the screen UI. the major issue of the MVC pattern is its test-able pattern, MVP have a powerful approach than MVC for the test-ability.

if the screen has BI-Directional-Flow go for the MVP architecture pattern.

1. We can go with MVP if UI or screen updates from Model Layer are very limited.
2. We can utilize MVP when our screen has Bi-Directional-Flow, where user communications need to demand something from our Model layer, and the consequence of this request will influence the UI.
3. It is an impractical notion to utilize MVP when the UI is refreshed without user between activities, such as refreshing UI when an event occurs in the Model Layer, this methodology is nearer to MVVM more than MVP ... more on this moment that we come to MVVM.

MVVM "Model View ViewModel"-

Suppose you have a presenter and you want that your presenter will update too many views?

is it possible?

no with MVP and Yes with MVVM.

1. If you want to update Too many views instantly, now time to go with MVVM.
   We can utilize MVVM when our Screen holds numerous views, now it is simpler to make each view subscribe on its data source in the View-Model and handle it-self when this data source changes. this data source can be Live-Data or RxJava2 Observable.
2. We can utilize MVVM additionally when our screen has a One-Directional-Flow, this time the occasions are originating from the Model Layer and influencing the UI with no user associations. what's more, this is the specific inverse for MVC. you can identify this when you work with MVP and find that your presenter is simply refreshing the UI yet not mentioning anything from the Model. a typical situation about this case is a screen that refreshes your area on Map, so at whatever point the area changes, the map is refreshed, so we can make our Views in the Activity/Fragment see on the variable that holds the area in the View-Model, and this variable is refreshed each time the area is changed.

Have a good day.

#staySafe #stayCode