Views
6 months ago

tornadofx-guide

EventBus In many event

EventBus In many event bus implementations, you are left with the task of deregistering the subscribers when your UI components should no longer receive them. TornadoFX takes an opinionated approach to event cleanup so you do not have to think about it much. Subscriptions inside UIComponents like View and Fragment are only active when that component is docked. That means that even if you have a View that has been previously initialized and used,event subscriptions will not reach it unless the View is docked inside a window or some other component. Once the view is docked, the events will reach it. Once it is undocked, the events will no longer be delivered to your component. This takes care of the need for you to manually deregister subscribers when you discard of a view. For Controllers however, subscriptions are always active until you call unsubscribe . You need to keep in mind that controllers are lazily loaded, so if nothing references your controller, the subscriptions will never be registered in the first place. If you have such a controller with no other references, but you want it to subscribe to events right away, a good place to eagerly load it would be the init block of your App subclass: class MyApp : App(MainView::class) { init { // Eagerly load CustomerController so it can receive events find(CustomerController::class) } } Duplicate Subscriptions To avoid registering your subscriptions multiple times, make sure you do not register the event subscriptions in onDock() or any other callback function that might be invoked more than once for the duration of the component lifecycle. The safest place to create event subscriptions is in the init block of the component. Should I use events for UI logic everywhere? Using events for everything might seem like a noble idea, and some people might prefer it because of the loose coupling it facilitates. However, the ItemViewModel with injection is often a more streamlined solution to passing data and keeping UI state. This example was provided to explain how the event system works, not to convince you to write your UIs this way all the time. 222

EventBus Many feel that events might be better suited for passing signals rather than actual data, so you might also consider subscribing to signals and then actively retrieving the data you need instead. Unsubscribe after event is processed In some situations you might want to only want to trigger your listener a certain amount of times. Admittedly, this is not very convenient. You can pass the times = n parameter to subscribe to control how many times the event is triggered before it is unsubscribed: object MyEvent : FXEvent() class MyView : View() { override val root = stackpane { paddingAll = 100 button("Fire!").action { fire(MyEvent) } } init { subscribe(times = 2) { alert(INFORMATION, "Event received!", "This message should only appear twi ce.") } } } You can also manually unsubscribe based on an arbitrary condition, or simply after the first run: 223

Guide
guide
GUIDE
GUIDE
GUIDE
GUIDE
Guide
GUIDE
Guide
guide
GUIDE
GUIDE
GUIDE
Guide
GUIDE TO
Guide
GUIDE