Proposal for Fragment Results API about simple-android HOT 12 CLOSED

The listeners are lifecycle aware, so internally it will observe lifecycle and do necessary operations. So we will only get results when the state is started

I have also updated the code to be a bit more concise and readable.

from simple-android.

Q: With dispatchScreenResult, we'd still have to implement the onScreenResult ToDo the body, right?

Yep, it will pass the request type and result and we can continue using the existing approach. So, only the internal implementation is changed.

from simple-android.

Since we only have handful of screens that require screen results, we can finish the migration process in a single PR. #2896

from simple-android.

This approach looks good to me. Ideally, I'd like to abstract even the receiving of results via the Router in some way (similar to how we are abstracting the sending of results), but I think we can take a look at that after removing the existing mechanism for sending screen results since that will simplify a good bit of the Router code.

from simple-android.

Okay, updated the Router to support that. The dispatchScreenResult function does get a bit complicated, but this would make use not to use the standard result pattern.

Also, one of the consequences I have mentioned (multiple listeners), it's no longer a concern. We can change our extension to support multiple request keys and just iterate over them when setting listeners.

What do you think? I personally prefer the listener approach compared to this. But I am open to either approach.

@vinaysshenoy

from simple-android.

This actually looks good. Correct me if I am wrong though, but wouldn't the listening for results have to be done when the fragment is created though? How would this work with the lifecycle?

from simple-android.

As long as the fragment itself is initialised, we can get the lifecycles. Since we found the fragment from the fragment manager, it should be in the initialised state.

from simple-android.

Found easier to understand the extraction after the listeners implemented in OnViewCreated.
Q: With dispatchScreenResult, we'd still have to implement the onScreenResult ToDo the body, right?

from simple-android.

The abstraction is causing a memory leak, I will see if we can resolve that leak, or else we will go with the listeners approach.

from simple-android.

Was not able to resolve the memory leak, have to take a look at it at some other time. There seems to be some issue with the fragment lifecycle that we are observing for results in the Router. Going with the listener approach in the individual fragments.

cc: @vinaysshenoy @Honey14 @janhavisinghh

from simple-android.

One small change is, I have updated the extensions to support multiple request keys.

from simple-android.

Closing this, since the change is merged in by #2948

from simple-android.