i have been using RoboGuice dependency injection with a Activity and a Fragment Activity. But i cannot figure out how i can use it using a fragment as we dont call setContentview in the Fargment. Can anyone show me an example of how to use this ?
Kind Regards
Here's a post that describes the solution. Main steps are:
Extend RoboFragment.
Return a root View from onCreateView().
Use #InjectView annotations the same way you do in RoboActivity.
Related
Is it mandatory to add #AndroidEntryPoint annotation on all dependent classes like fragment dependent upon activity. Is there any alternative solution for overcome this exception?
Just add #AndroidEntryPoint to your parent Activity class:
And yes, it's a mandatory process if you want to use Hilt. You could use Dagger to get away with this.
I have a doubt regarding Dagger 2.
I have a BaseFragment class in which i am writing AndroidSupportInjection.inject(this), and all my fragments are extending from this Fragment class. I also have a FragmentBuilder class where i mention all the Fragments using #ContributesAndroidInjector annotation where i need injection to happen.
My doubt is, if in a Fragment i don’t need any dependency still i have to mention it in my FragmentBuilder class because its extending from BaseFragment. Is it a all right to do so or this will lead to any memory leak or is this a wrong design pattern ?
Please help!!
In your situation i'll go with 2 "base" fragments, the first BaseFragment doesn't allow injection then you make a BaseInjectableFragment that inherit from the first one and you make it injectable, this looks more cleaner this way.
I'm using data binding in my android project, also i'm using dagger 2 for DI.
basically for setting content view with data binding i need to do something like this :
LayoutClass layoutClass = DataBindingUtil.setContentView(Activity, Layout);
I'm providing that layoutClass in dagger module and injecting it to my activity. the question is, is this a good practice ?
Technically you're defining a circle-reference with this. You're just not warned, because setting up the graph requires you to be pro-active about this.
The dependencies would look like activity -> layout -> activity while you provide the module with an activity explicitly. Additionally you're modifying the activity with DataBindingUtil.setContentView() and therefore provide a dependency to the activity, which actually is a property of the activity itself.
So, never provide any UI with Dagger. Especially not to an activity.
Note : This is a question that I asked straight on the LightCycle project github. It's a great tool from SongKick to build a clean MVP architecture over your android app .
There is a thing that I miss thought, I have an activity with many fragments and many fragmentsPresenters.
Sometimes I do computation on my activity presenter and I want to send it to one or many of the fragment presenters (for example my table of content is displayes in the activity menu, and in a fragment that is shown full screen at the beginning).
How to I add a keep a reference of fragment presenters in my activity presenters (maybe it's not how I'm supposed to design it).
Second question. I have MyActivityPresenter that has two children : MyOnlineActivityPresenter and MyOfflineActivityPresenter.
MyActivityPresenter.newPresenter(Network.isNetworkAvailable(contexte), few other args) decides whearas an online or offline presenter is instanciated. So I should do something like :
#LightCycle
PlayerPresenter presenter = PlayerPresenter.get(NetworkUtils.isNetworkAvailable(this));
But I've been told that I should never use context that way as It could be null at the class instanciation moment. Is it indeed a problem ?
also should I pass the few others arguments that I have in the onCreate Bundle ?
And I don't use dependency injection at the moment.
I hope that I'm clear,
thanks again for this very useful lib
This is the answer they gave me
How to I add a keep a reference of fragment presenters in my activity presenters (maybe it's not how I'm supposed to design it).
It is not something in the scope of this library. I can see 2 solutions for you :
inject the same instance
provide an accessor to the presenter from the fragment. (which seems to be better for you).
But I've been told that I should never use context that way as It could be null at the class instantiation moment. Is it indeed a problem ?
also should I pass the few others arguments that I have in the onCreate Bundle ?
Same here.
You can use the app context which should be available and enough in your case
You can init this guy in the constructor because binding happens on create
Probably the answer is "you can't", because in Mosby 2.0 you need to use fragment and set it to setRetainInstance(true) to preserve Presenter. And the aim of Conductor is to remove the need of using Fragments, so there is no way to use setRetainInstance(true) anywhere in your app.
But maybe there IS another way..
Here is the official Mosby plugin for Conductor:
https://github.com/sockeqwe/mosby-conductor
Sorry i cannot comment because i don't have enough reputation but Conductor is using Conductor.attachRouter in order to take instance inside an activity and attachRouter is using the LifecycleHandler in order to take a "saved" (aka retained instance) because LifecycleHandler is a headless fragment. So in order for you to have a presenter which is not being destroyed on configuration changes all you have to do it to create your presenter inside the constructor of the controller. If i have understand right, the constructor of the controller has the life time of a headless fragment. So problem solved or i might have made a mistake somewhere...