UI Design patterns for non-screen based project

Question

I'm working on a small project coded in Python that uses a single button for input and a RGB LED as feedback, which responds to button presses and asynchronous events from the network.

As the feedback has become more complex (lot's of ifs, elses and timers), it's become evident that a UI design pattern, such as MVC or MVP would help segregate functionality.

The code is already mostly MVC in style, where the button input is tied to a controller thread and the LED has a View thread where animations are loaded under control of the controller. A model exists for interacting with a remote device.

For example, the button initiates an HTTP request by calling on the controller, which initiates an async request to the model and returns a View that blinks the LED to let the user know the request is inflight.

Where I'm struggling is how to deal with the response from the Model when the HTTP request is completed. The View could poll the Model but that seems wasteful and perhaps slow. Which makes me wonder if the Model should update the View either by raising an event or using a controller supplied callback, but these would technically tie the Model to the View.

I'm also wondering if MVP would be a better approach to this and use the Presenter to arbitrate between View and Model.

Your thoughts on approach for this totally over engineered gadget would be appreciated.

Answer 1

When the HTTP request is completed, it will return some data, and the model gets updated by the responsible part of your system. Then raise an event which tells everyone who subscribed to it "new data has arrived", but do not pass the actual data in this event, only the relevant information for the subscribers which part of the model has changed. The event itself can carry something like an ID or primary key together with a type information, but not more.

The view, or some kind of controller beeing responsible for updating the view, has subscribed to that event. It pulls the data to be displayed out of the Model. That way, the Model does not need to know anything about the View, only the View or the responsible Controller has to know about the Model (but not more as it had already to know before). What is more important, you do not tie the View to the part of the system that deals with the HTTP requests.

MVP is good when you have the requirement to change actual view by a different one, but want to keep the core presentation logic (the part in the Presenter) the same. It is also helpful when you need to mock out the view for testing purposes. If this is useful in your case, or not, will depend on the complexity of your system as a whole, but most probably not on your requirement for processing asynchronous HTTP requests.