I’m having an issue with dependency injection with Dagger, and using the MVP architecture, on a view which has dynamic tabs.
My activity is consisted basically of multiple tabs, which each tab has just a list of items (thus they all will be using the same Fragment class), and they all will use the same presenter class too (different instances). The number of tabs that I’ll be showing is based of a response I get from my server.
The problem is because dagger works on top of classes types, and I need to work on some sort of index to correlate the tab view and it's presenter.
I can't use the same instance of the presenter for all fragments because the presenter also keeps an reference to it's own fragment.
How can I achieve this kind of dynamic injection with dagger?
Related
I've got an app that only uses one ViewModel to handle GroceryItem.kt items from local Room database. I'm planning on adding multiple fragments using bottom navigation with NavGraph and want to include an additional ViewModel class to obtain Recipe.kt items from an API using Retrofit.
I've read from online that I need to create one ViewModel for each Fragment/Activity. How can I do that if I use two different ViewModels with different purposes?
When working with Bottom Sheets and Dialog how to perform operation:
Use a SharedViewModel with fragment that created this bottom sheet?
Don't use a ViewModel at all?
Creating a separate ViewModel for the BottomSheet?
Any other approach that is best practice
If the bottom sheet/dialog is tightly bound to your "host" fragment (it shares some specific live data), and it is never going to be created from some other fragment, then it's OK to use a shared view model.
If the dialog is dead simple (like one input + 2 buttons), then the viewmodel might not be needed
If the dialog really needs a viewmodel (i.e. it fetches and displays some dynamic data), then a separate viewmodel makes sense
I'll go with the first approach by using a ShareViewModel, but if you understand the underlying layer, shared ViewModel is also ViewModel it's just a name convention we gave it to them.
Also sometimes it becomes tedious to write separate ViewModel to deal with fragments and bottom sheet where a MainActivity ViewModel can also do the exact same thing.
What I meant, in order to avoid complexity I use one view model per activity. Now, whenever I want to execute something in fragment or bottom sheet I just pass the view model in the constructor itself. Many people will think this is bad practice but it's not coz as per the concept of view model it will only be created and destroyed in accordance with the activity's lifecycle and only one instance will be created all along. Also by doing this, I can use Dependency injection with the fragment (I don't think that DI works with navigation component but I think you got my point).
I'm refactoring an android component to be adopting MVP architectural pattern. The problem I faced is that I have a fragment nesting other fragments in it.
1- The parent fragment hides/shows one of the nested fragments based on some conditions.
2- The child fragment passes data to the parent fragment which is observing it as here inspired by callback mechanism between fragment and activity.
I've 2 questions:
1- If I consider the fragment as the view of MVP, should I use distinct presenters for the parent fragment & the child fragment (1-to-1 mapping between presenters & views) or only one presenter for both and why?
2- If I'm supposed to use distinct presenters, how should I handle passing data from the child fragment to the parent fragment as I barely know the Cons. and Pros. of:
Using an EventBus framework like Otto
Allow a presenter to have a direct reference on another presenter
Keep the communication in the view layer, away from the presenters as here, by having the nested view delegates calls it receives from its presenter to the parent view.
As with most architectur questions, I honestly think there is no right or wrong way. So please treat this just a suggestion (how I would implement this)
Each MVP unit should contain it's own presenter, which means there is one parent presenter (for the parent fragment) and several child presenters (one for each child fragment).
The child presenters all contain a parentPresenter field, which acts as a way to pass data / messages from the child to the parent. This parentPresenter is NOT the real presenter object, but an interface that includes only the needed calls.
If you need to pass data / messages the other way around (from the parent to the children), this is implemented via interface methodes in the view:
the parentPresenter calls its view
the parentView finds it's childFragment
the childFragment calls the appropriate interface call on the childPresenter
This way the whole communication is hidden behind clean interfaces and is also nicely testable. Hope this helps and let me know if you have any questions...
What I do in my application is using a callback mechanism between parent and child fragments for passing data between.
I also made a different presenters for each child fragment, because if one day I would like to use only one of the child fragments I would only override it's presenter methods.
So I have an a presenter that is already tied to an activity. The book says that one presenter should be tied to one view. But now I am adding a few fragments and lots of custom views. I am considering a fragment to be a view as well. The custom views will contain a little bit of logic in them. Both the fragments and custom views are contained in my activity of course.
My question is, should I re-use the same presenter in the fragment and custom views or should each view get its own presenter? I realize this is all opinion based but I want the best approach for testing and keeping code clean.
If i do have one presenter for all these fews then then interface the presenter uses will have many callback methods in it. Meanwhile if i did the opposite and created one presenter for each view it might be easier to read but how would i test it ?
View (Activity) can have multiple Presenters. In case of having multiple CustomViews for Activity, you can have one giant Presenter or Presenter per each CustomView. It depends on this:
If all CustomViews share same needs, one Presenter for all CustomViews is enough. Still two options for Presenter's scope:
Presenter has ActivityScope. Activity uses Presenter and gets called from Presenter. Then sends commands, data to CustomViews
Presenter has ViewScope. Each CustomView creates and destroys same Presenter
In case of CustomViews not sharing same needs, having one Presenter and ViewInterface, they will contain methods of all CustomViews needs, so each CustomView has to implement all declared methods in ViewInterface, leave some empty.
If CustomViews have different needs and method calls to Presenter, they should have their own Presenter.
If CustomViews have different needs and also some common needs, they share common need in one Presenter, specific needs in their own Presenters. Example for this: ActivityOne has CustomViewOne and CustomViewTwo. Common Presenter for both CustomViews can be FeedPresenter(considering both CustomViews have Feed List). Then CustomViewOne will have CustomPresenter1 and CustomViewTwo will have CustomPresenter2 for their specific needs.
Best practice is to create a basepresenter , then create presenter for each view implementing basepresenter
I want to implement MVP pattern in my android project .
So , for Login-activity I did not have any problem .
But in Activity-Main I get confused a little and now i`m not sure how should I implement its Presenter !!!
In Activity-Main there are 3 sections as Navigation-Drawer , Toolbar and a fragment .
How can I make Presenter(s) now ? I doubt to create one presenter that implements 3 others implements or
directly create 3 presenter that have access to Activity-Main ?
Thanks
You can create refer to google's android-architecture .According to me you should create three different presenter for your each view and then bind them.you should check this part of sample,which has very basic design
What we did for a complex activity (30+ screens) was to divide each screen into View and Presenter components, where View battles with Android Views, and Presenter works out the logic (pulling and preparing data from controllers, network or local storage). But yeah, Google samples contain information about pretty much everything you'll need to start. Either way you should spend more time designing and thinking about the structure rather than actually implementing it. Good luck :)
From my understanding about MVP and its implementation is "P" is logic part which does all the logic/action handling. For this case i have personally created two presenters : Navigation Drawer/Home Presenter & Fragment Presenter.
Navigation/Home P : Only responsible to action related to Navigation and related to Main-Activity.
Fragement P : Having 1-1 relationship ie each fragment will have its own presenter.
For toolbar Presenter : I don't see much of a case where you should create separate presenter for toolbar, as all the action delegated via fragment and each fragment will have different items in toolbar and different handling as well.So collating them in one would just add complexity.