ChildFragmentManager about fragnav HOT 5 CLOSED

This may be an oversight on my part, but my understand of ChildFragmentManagers is that it nests a fragment inside of another fragment, which isn't exactly the primary use case here. This library is more for the use case where you want to entirely replace another fragment. Feel free to correct me if I'm wrong though.

from fragnav.

If you think of the top level of fragments as navigation controllers. For example if you have five tabs you have five fragments acting as navigation controllers. Each navigation controller has a base(root) fragment. You can push more fragments in that navigation controller. If you want to switch to another tab you can detach the navigation controller and attach the other navigation controller. When you go back and reattach the previously detached navigation controller you will have all of the backstack for the nav controller persisted by the child fragment managers.

from fragnav.

This is pretty far overdue, but I've been considering this more and more. I'm wondering if anyone has any specific pros/cons to using this method.

from fragnav.

@ncapdevi I don't mean to overstep any bound here (and delete my comment if you'd like), but the task that you are looking to perform is exactly the implementation I have completed. Maybe we can work together on updating your implementation to use my NavigationFragment implementation (My next steps were to make a wrapper around my single navigation stack to help implement tabs and help implement a navigation drawer anyways). Let me know if you would like to work together on implementing this.

As a side note, from my experience so far the only con with using the child fragment manager is that when you start an activity, share intent, etc. it causes the fragment to be detached and hence a blank screen shows prior to the transition/when the share intent shows overtop.

Thanks,
DMCApps

from fragnav.

@DMCApps No overstepping at all, but thanks for the consideration. The whole point of this library was to provide a solution to a specific problem. As far as I'm concerned, the more approaches to solving the problem, the better. I'll have to spend some time looking into your implementation to see what my specific thoughts are, but I'm happy to discuss the differences/pros/cons of the different approaches (if they are that different).

I'm still not entirely sold on the idea of using the child fragment manager vs the fragment manager. I may need to spend some more time looking into the intricacies of the implementation, but my hunch is that using a child fragment manager would be slightly less efficient/performant as well as not necessarily providing any benefits (that I can really see). I'm still interested in the idea of it though.

from fragnav.