-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workflows started with setContentWorkflow may drop early output emissions. #430
Comments
More thoughts on this:
|
This issue name is obsolete: As for outputs, we should hook into the lifecycle of whatever is creating/retrieving the workflow runner (activity or fragment) and either buffer or pause (via backpressure) the emission of outputs when the lifecycle owner isn't active. And since that caller will be subscribing to outputs from an activity or component, the subscription will likely close over that object and we should be careful to not invoke it in a bad state. |
I updated the issue name so we can remove from the 0.18 milestone. |
As part of the discussion behind #439, we're realizing that this is a pretty easy (and natural) problem for WorkflowRunner to solve. It's job is to ensure that outputs are buffered until someone is subscribed to receive them. At the same time, we should probably replace its rendering and outputs Rx Observables with LiveData properties. |
@zach-klippenstein I've added this back to the 0.18.0 milestone. Suddenly it seems like we have the complete pictures, seems like we should implement it all at once and be sure that it works. |
…tream. Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Closes #430.
…tream. Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430.
Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430.
Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430.
Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430.
Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430. Fixed result f
Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430.
Android's configuration changes make it very difficult to craft an API that can catch all output values and also avoid double-processing of them, and each such API we've come up with is very confusing. The cognitive cost outweighs the benefit of allowing the Activity or Fragment to consume a stream of outputs — if that's even a benefit! So far we have no use cases for a stream v. a single result code that can't be better handled inside the root workflow. Note that we update the Tic Tac Toe sample to take advantage. We also (nearly) make it's back button work properly on the initial screen, but that is blocked by #466. Closes #430.
I'm not thrilled with this extension method any more, but have no change to suggest for this PR. I'll follow up after you merge.
Originally posted by @rjrjr in #426
The text was updated successfully, but these errors were encountered: