I'm designing a round-based game where one of the core design goals is to have a highly exchangable UI. For this, I've defined an interface which allows implementers to only focus on drawing the UI and processing user input - Everything else happens behind the interface.
The general idea is to have a controller in a background thread/task which calls methods on the interface (synchronously?) which are supposed to block the background thread, while asynchronously playing an animation or waiting for user input. Once the animation finished, or the user pressed/tapped on a button, the background worker shall continue its work.
The basic idea is similar to this example:
Note: userInterface is a member of
Controller of type
IUserInterface. The image above is the way this is represented in the
Modelio modelling tool.
The intended workflow is like this:
Basically, the UI merely reacts - it does not control anything other than actual drawing.
The UI will be implemented using C#. It would be preferrable to have a solution which is not specific to Windows Forms, WPF, WebGL or similar.
In a classical example, I would start background work in an async UI method and await a
Task. However, since we're having
Inversion of Control here, I don't have that option.
What would be the right, modern, C# way of implementing this?
I have found this arcticle from 2009 which would basically recommend a background
Thread and calling UI methods through a
Synchronization Context. I would have to make sure the background thread does not continue execution while waiting for the UI thread but this should be easily possible.
Is there are safer / more modern way than doing this?