Android MVP Dependency Rules
I've read and tested the MVP patterns in Android a lot, but I'm here to ask your opinion on what might be the best practice if I want to respect both the "dependency rule" and the MVP pattern.
As it is explained in many articles (see link http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ ) our application must be layered and only the outer layer can instantiate and use an inner layer. The inner layer gets all parameters (variables, contexts, views, etc.) and returns a response or uses callbacks, etc.
It is also a good idea to isolate layers that you can use using interfaces and directly calling interfaces instead of classes. (see link: http://www.tinmegali.com/en/model-view-presenter-mvp-in-android-part-2/ ). In the link above, the author points out that he does not use callback methods, but interfaces to go from inner layer to outer layer (not following the dependency rule).
My questions about this are two:
1) is it better to use the interface for the calling class (outer layer refers to the interface of the class) and the called class (inner layer refers to the calling interface of the class), or is it only needed in one direction, for example, only the outer class refers to the interface of the inner ?
2) because the outer layer (UI) creates all the inner layers and through a simple rotation of the screen is destroyed and recreated, is it better (for memory leaks) to save the state (when needed), destroy the inner classes and processes and recreate them, or istantiate static in a way (via a Singleton or as an instance of a class that extends the Application class) all the classes that need to "survive" "on the rotation screen? Thanks everyone!
source to share
I believe MVP is somehow Tuxedo development, which means you have to decouple everything and use interfaces to declare different methods before implementing them. So my answer to your first question is YES!
Usually in this type of situation, I believe that I am defining the layers and another junior developer is going to use the kernel that I developed, so it is best to limit its effect and reduce its drawbacks and error.
About recreating, I would suggest using Dagger appropriately, which actually stops you from recreating objects that were previously created just because of the screen rotation! You can keep the low-level declarations in memory and attach them to the new view after rotation.
I would suggest taking a look at this sample repo that I developed with MVP, Dagger, RxJava and Retrofit to get a better understanding of the best practices and new techniques for Android development:
Hope this helps :)
source to share