Who is responsible for GUI timeouts: the GUI or the app?

Question

I have an application written in C#. This app uses a GUI for message display and user input, and the GUI is connected to the app via an interface class:

public interface IEndUserInterface
{
    void Reset();
    void ShowMsg(Tuple<string, string[]> msg);
    void ShowBoolDialog(Tuple<string, string[]> msg);
    [...]

    event DiagAnswerEventHandler DiagAnswerEvent;
    event EventHandler GUIReady;
    event EventHandler StartProcess;
    [...]
}

The methods are used to display stuff on the GUI, the events signal actions or inputs to the app.

When ShowBoolDialog() is called there is a timeout started that sends the Reset() after a while with no user input.

When there is a Message to be displayed there is another timer that cleares the screen (or shows the following message) after it finished.

So there are two questions:
First, I think the timing of the messages should all be done outside the GUI. What do you think: should it be in the app or in the GUI?

And what kind of pattern does this approach of connecting the GUI to the app follow? I can't see the MVC-pattern in it, but felt inspired by it...

Answer 1

With just the interface as information, it is impossible to say if a particular pattern is being followed. It does appear that an attempt is made to separate the user-interface from the business logic, which can indicate that the design is inspired by the MV* patterns.

As for where the timing should be handled for how long messages/dialogs are presented to the user, that should be handled in the GUI side.

Suppose that someone gets the brilliant idea that, besides the existing regular GUI, it must also be possible to interact with the app via email? When the app wants to show a message or dialog, an email would be sent and the user can respond to that email to react. In such a system, a timer for clearing the screen is meaningless and while you might want to implement a response timeout, the timeout values for a standard GUI and an email UI are likely to differ by an order of magnitude or more. Yet, your app should be able to work with both and preferably without knowing which one is hooked up (or if both are).