How best to communicate with UI?
How would people recomend to get a UI to talk to an application? For example, if the user clicks a button labeled "run", what is the best way to then call a function called run?
Some ideas I've come across so far are:
Callback functions
Message (or event) systems
Overloading each button with specific input handling functions (sounds messy to me!)
So what would people recomend, and why? (In case it makes a difference, this would be in C++)
I had the same problem and eventually I went with an elaborate event processing system. One that is polled for during the next time input is read from. It's rather easy to implement one, all you need is a queue (or similar FIFO data structure). The benefit is that you can design a simple event based system that is very extensible using classes and templates. Callbacks are the old C style way of handling events. The down side is that they lock you into using either static functions in a class or free floating functions.
Note that most event systems are implemented via callbacks. When the button is clicked the callback is called. The callback adds an event to the queue or calls each of the functions in the event listener list, or otherwise does event-style handling. You might design a system that automates the callback and event generation, but the underlying mechanism is the same.
One difficulty with queued messages and delayed processing is that it can become very painful to debug. When you see the symptoms of a bug several frames or iterations after the actual event that caused the bug, it can be very time consuming to figure out what generated the offending event and why.
That being said, event systems do offer a lot of flexibility.
My preference is a global message bus (with mandatory debug info indicating their timestamp and original source) along with a single callback on the UI element. The callback is able to call any number of event listeners (even zero of them) and also add messages into the global bus for general consumption.
With a global bus, you can more easily log events that are going on in the game, and combined with a good scheduler, you can identify and fix runtime hotspots and overly-chatty interfaces.
One difficulty with queued messages and delayed processing is that it can become very painful to debug. When you see the symptoms of a bug several frames or iterations after the actual event that caused the bug, it can be very time consuming to figure out what generated the offending event and why.
That being said, event systems do offer a lot of flexibility.
My preference is a global message bus (with mandatory debug info indicating their timestamp and original source) along with a single callback on the UI element. The callback is able to call any number of event listeners (even zero of them) and also add messages into the global bus for general consumption.
With a global bus, you can more easily log events that are going on in the game, and combined with a good scheduler, you can identify and fix runtime hotspots and overly-chatty interfaces.
Quote:Original post by frob
Note that most event systems are implemented via callbacks.
Not necessarily, but it is the most straight forward method. The Win32 API uses callbacks for all types of enumeration and event processing. I would suggest that you look into this, especially if you don't feel you mastered OO design. Also, Callbacks are not thread safe, you would need to write something a bit more complex in order for your event system to work over thread boundaries.
So, coder beware.
Would the terms Model-View-Controller, Model-View-Adaptor, and Model-View-ViewModel be relevant for ideas? These overly contrived concepts may only be relevant when your app starts getting complex or if you want to plan for the time when your app starts getting to complex to manage with comfort. Otherwise, one method would be as good/bad as any other.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement