Passing ScreenResult from one fragment to another fragment about alligator HOT 9 CLOSED

You can implement screen result listener like that to handle screen result in fragments:

@Override 
public void onScreenResult(Class<? extends Screen> screenClass, @Nullable ScreenResult result) {
	FragmentManager fragmentManager = activity.getSupportFragmentManager();
	Fragment fragment = fragmentManager.findFragmentById(containerId);
	if (fragment instanceof ScreenResultListener) {
		((ScreenResultListener) fragment).onScreenResult(screenClass, result);
	}
}

The library does not use setTargetFragment.

from alligator.

Yeah, that would work.

Although it would be nice if I could avoid accessing FragmentManager altogether and register listener when fragment is added to backstack.
That would require support of multiple listeners of course.

from alligator.

Activities are responsible for creating and binding of NavigationContext, so it is not quite clear how to configure it from fragments. Anyway you can try to implement some kind of composite listener to have multiple listeners in one.

Also look at my comments to this rejected pull request #4
It has something common with the issue.

from alligator.

With composite listener it's same story - it's error prone. I would have to manage such listeners.
onResume - register listener in CompositeResultListener, on destroy - unregister.

On the other hand if this fragment implements ScreenResultListener

Although I haven't read whole code, there might be some issues with this approach.

from alligator.

Yes, it is possible to check if a previous fragment implements ScreenResultListener and call it in BackCommand. Similar change can be done for activitities.
But in my opinion that api would be less flexible and not consistent. Now there are no requirement that an activity or a fragment have to be a listener. An inner class can be a listener for example. Also the api is consistent now. Screen result listener is set in the same manner as other listeners are done: TransitionListener, NavigationErrorListener and other.

It requires some additional code to establish result handing in fragments. But it can be done once in BaseActivity.

from alligator.

Yes, it is consistent, but not flexible and requires accessing fragment stack to implement behaviours similar to mine or mentioned in #4, which defeats the purpose of the api.

from alligator.

So, what do you suggest?

from alligator.

I understand that implicit result returning to fragment implementing ScreenResultListener isn't the best solution.
To mitigate that there could be option in NavigationContext.Builder to toggle such behaviour - attemptResultDeliveryToFragment or whatever :) Naming is not my strong suite.
If fragment consumed the result - returns true and result propagation stops. If false try to deliver to activity/default listener.
That way it gives control to user, keeps some of the consistency - behaviour is controlled.
What do you think?

from alligator.

More options - more possibilities for bugs :)

And don't forget about other cases:

1. Starting activity for result and handling result on a fragment.
2. Starting activity for result and handling result on a page of a screen switcher.

from alligator.