Add facilities for creating Observables from JavaFX events and ObservableValues #1182
Conversation
…ableValues. Provides: * a Scheduler implementation ensuring execution in the JavaFX UI thread * a Subscription implementation ensuring that un-subscription happens in JavaFX UI thread * an Observable factory method for observing UI events on JavaFX nodes * an Observable factory method for observing value changes of a JavaFX ObservableValue Also the rxjava-javafx is added to the gradle build.
|
The build is failing on the bot. Looking at the output, it looks like the deployed jdk do not provide the javafx bits.
Should the module gradle definition explicitly state dependency on JDK >= 7u15 ? |
|
RxJava-pull-requests #1093 FAILURE |
|
Answering to headinthebox remark on the previous PR: Do subscribeOn guarantees that the un subscription callback runs using the same scheduler as the OnSubscribe(Func) ? |
Based on previous discussions it has been considered that there may still be cases where unsubscribe could arrive from other threads. See these discussions:
If you need unsubscribe to happen on a particular thread, you can use I'm trying to remember why |
The build is using Java 7. If the version of Java 7 is old that will require more effort to resolve as we'll have to get CloudBees involved. |
|
Hi @benjchristensen,
Do you think this responsibility should be left to the user code or enforced withing the Observable creation method? |
|
In the swing module it is handled by the 'SwingObservable' implementation to ensure thread-safety and doesn't use 'unsubscribeOn'. |
|
|
||
| source.addEventHandler(eventType, handler); | ||
|
|
||
| subscriber.add(JavaFxSubscriptions.unsubscribeInEventDispatchThread(new Action0() { |
There was a problem hiding this comment.
This seems to be safely handling unsubscribe by doing it in the right thread so 'unsubscribeOn' is not needed.
Merge pull request #1182
Heavily inspired by the swing contrib.
Provides:
Also the rxjava-javafx is added to the gradle build.