Post news RSS {Devtips} Event-driven programming!

I discovered event-driven programming thanks to Qt (in C++) and its beautiful signal system and later thanks to javascript and its lambda...

Posted by on

I discovered event-driven programming thanks to Qt (in C++) and its beautiful signal system and later thanks to javascript and its lambda.

The principle is to imagine its code not only in components or sequentially but as being organized around events: The click of a player, the press of a key, the addition of an element in a list, the modification of a variable.

Everything is potentially a handler that can trigger an independent code block in its own thread.

Fortunately, Java followed soon enough and proposes in the Jdk8 an advanced system of lambda!

The principle is simple. Any interface having only one method can be created with the following syntax: (var) -> {code block}

Java offers a basic set of interfaces that do most of the work, but you can also create your own for the most exceptional cases.

The most classical one is Runnable: One run method, no parameters, no return!

To use it, nothing could be easier:

More complex, when we want to transmit a variable to the lambda, for example in the case of a mouse movement or pressing a key: Java offers Consumer<>

To use it, same story as for the classic lambda but passing the variable :

Sometimes we don't need to pass a variable but instead get an answer, for this Java offers us Supplier<> (sorry, I don't have any example for this =p)

Finally, if you have a parameter to pass and a response to get. The best solution will be Function<>. Why search when Java prepares the ground and the right classes for you ;).

It is important to know that this notion of event-driven programming is still very recent for Java and it does not (yet) offer all the necessary tools to exploit it to its full potential. This is where the React library comes into play.

React provides us with 2-3 very practical classes allowing us to highlight the event-driven programming in Java: RList, RMap, Slot and Signal.

Concerning RList and RMap, they are neither more nor less than classic List and Map, offering handlers on additions, deletions, etc...

Here, no lambda because it does not concern only one operation (one method).

The Signal and Slot classes allow us more freedom because we can "connect" to each of our components a series of behaviors to perform in certain cases that we have defined.

Thus, it will only remain to "emit" the signal when the event will occur.

So, it's the end! I hope you enjoyed this article! If you liked it and would like us to make more, please let us know! Subscribe, comment it, share it, show us that you are there, it will encourage us a lot!

You can also make a donation, to support us and finance the development of our next game: 'Les Nains du Nord"!

Thank you! ♥

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.