Open chweez opened 7 years ago
Yes, having it kill or stop itself is a great idea, ping me if you need any help, but I can see you are doing great already!
Haha...thanks. Though I'll create another pull for the documentation...
Great
I've been considering this... @jumadeveloper help me with this... I'd like to hear your take on the matter. Any other perspective.
@chweez I think we should make it handle the lifecycle automatically, by somehow receiving the lifecycle event of the parent, as you had stated earlier when creating the issue to reduce code setup needed by the user
@chweez I have an idea, we can use livedata
own lifecylcle manager, to manage our lifecylce here easily. Have a look at it and probably get back with ideas or suggestions
I've been looking at this. I have a concern for including the LiveData
and LifecycleOwner
from arch components because of the external dependencies. However, it may prove worth it. What I'm thinking is another module that depends on livedata
and another that depends on rxjava. Adding the module dependency will pull in the transitive dependency to :networkmanager
. The module names will be; :networkmanager-livedata
and :networkmanager-rxjava
@chweez I completely agree with you
For now, the user must call
Tovuti.from(context).stop()
but i want to make it automatic when theActivity
/Fragment
stops. So, the way Glide implements this feature is by having a view-lessFragment
. The view-less fragment is attached to the activity/fragment where theMonitor
is attached and theseFragment
receives the lifecycle events of the parent/host thus allowing theMonitor
to respond accordingly without user intervention (i.e. calling stop method). I'll try see if this way will suit us. The only problem is increasing the complexity of the library unnecessarily. What do you think @jumadeveloper?