suggest better ways to handle presenting/dismissing

[jjhesk]

Thank you for your dedication and talent to tackle those issues for the library. I am proud of you! Here is another question. Do you have any planning for bringing input or data bundle into presenting/dismissing? I think this is a very important feature for the real world cases. The most common fashion to implement that would be using Bundle to parcel the needed data into the bundle object and past along with the fragment to be initiated for presenting.
Maybe start thinking about this with a list of possible calls for your INavigationFragment where i have found in your library section

void presenting(fragment, bundle, animation in, animation out)
void presenting(fragment, bundle)
void presenting(fragment)
void presenting(fragment, animation in, animation out)

void dismissFragment();
void dismissFragment(bundle);
void dismissFragment(bundle, int animationIn, int animationOut);
void dismissFragment(int animationIn, int animationOut);

When inside the INavigationFragment we can call getNavigationFragmentBundle from presenting or dismissing. thus we can trigger this call at onResume when the dismissed fragment bring back to the previous fragment. I think we need to plan it out more precisely for the naming to handle nested fragment routing handling. I dont mean to using another library to bring assistance for cross instance even handling but it would definitely help. I dont recommend calling another library because there is always a catch from the versioning issue or cause big confusion for unfriendly coding experience. But here we can take check that out for getting some ideas of how to handle the similar issue popular page or I have done this with other projects otto. It is a plus with the object passing support.

This feature maybe not be the most important thing to add but I would like to vote on this for later update! Thank you~

[DMCApps]

Thanks a lot for the suggestions and continued interest.

For this particular suggestion, I am wondering the benefits of adding this? If possible can you give me a use case for this addition?

My current assumption is that people will be following the newInstance() (http://www.androiddesignpatterns.com/2012/05/using-newinstance-to-instantiate.html) pattern for defining fragments and hence they will already be passing in the needed information to the fragment that they are presenting.

I can however see this being beneficial on dismiss to be able to pass data back to the previous fragment on the stack instead of having to pass through a class as a listener. I will leave this open and we can discuss further.

[jjhesk]

it is a better way to include .setArguments(args); implicitly instead of defining f.setArguments(args); before having the instance.

[DMCApps]

I can see the benefit to adding this to reduce the steps when creating a fragment. My only concern is that when the user calls getArguments() in their fragment if we have replaced the previous bundle (when dismissing) then there can be use cases where their data is gone. I can get around this by getting the current Bundle (of the fragment being dismissed or presented) and adding all the keys to it. There will be no need for the getNavigationFragmentBundle() method as the bundle will then we attached to the Fragment itself and the user can then grab keys from there.

On the flip side, if we save the Bundle in the manager as a global Bundle. Then there is a global bundle that all NavigationFragment classes will have access to based on the getNavigationFragmentBundle() suggested method. I feel that this could get abused by users and cause a lot of items to be in memory at a given time. Either that or this Bundle needs to be replaced on every fragment such that only when explicitly given the bundle is used.

Which would you vote on for implementation? I'm leaning heavily towards the first idea. I can make the bundle replace existing keys or add new ones to the fragment being presented/dismissed. Only concern is that the replace may wipe data that the user is expecting. That means you will have access to the Bundle in the Fragment in the default getArguments() method. Let me know your thoughts.

[jjhesk]

I would like to learn more about the mechanism that you have utilized this stackfragmentmanager. When Fragment A is presenting the fragment B, does fragment A has the lifecycle mechanism as an acitivity which contains pause, onsavestate, onrestorestate, and will also call onresume as the fragment B is dismissing from its own? if i need to have communication between B and A, what do i need to do from calling B? If it is much similar to a Fragment and I assume there is a way to pass data or configurations from B to A or vice versa. What is the solution for this idea?

[DMCApps]

For communication between fragments, you can do it in many ways. If you had a situation like this without the navigation manager how would you have done it? Whatever method that is should work.

For example. When communicating from A to B you should be using the newInstance() pattern which passes in parameters and are then put into a bundle for the fragment about to be presented. For communication from B to A, you could use a callback that is defined in B, and A can be assigned as a listener on this callback.

I am planning on adding in the ability to pass bundles to and from fragments using the manager (present/dismiss), but I have not implemented it at this time and likely won't get to it for another week or two as I have other needs of the manager to implement. It has been added to the ReadMe for future release will keep this ticket open until implemented.

[jjhesk]

is this part "adding bundle into calls for present/dismiss" is called ready yet?

[DMCApps]

It's not complete. It is currently being worked on in the develop branch and will be part of the next release. Keep an eye out for it likely late next week as I won't have any time this weekend to work on it.

Thanks for the continued support and any other feature requests please ask and I'll see what I can do!