Question

I'm working with the MVC pattern, which also uses the Observer pattern. The concept is like the following:

________                 _________                ______________
| VIEW | -- observes --> | MODEL | <-- changes -- | CONTROLLER | 
--------                 ---------                --------------

So I think my concept is pretty usual and common. Each time an observed object from the Model is changed, the View updates with a recreation. In my case, i have a lot of objects changing very frequently, which has a bad influence on the performance of the user interface. Because of a wide range of possible changes of the objects and the way of presenting them, i always have to newly create the whole View on update instead of updating particular components. To improve the performance I implemented a queue for update view request to make sure, updates are only done e.g. max. every 50 milliseconds. This works perfectly and increased the performance to a good level.

My question is now, is there a better way to deal with many update view requests, that temporally overlap each other. My solution to queue and reduce the request to an acceptable level seems to me like a bad workaround. Any ideas for a better concept?

Was it helpful?

Solution

The pattern you are picturing in you diagram is not exactly MVC, but rather MVVM (Model, View, ViewModel).
Using a queue to throttle the changes is a perfectly valid approach. In many case, it is useless to try to update a view faster than what the user is able to perceive.

On the other hand, rather than creating new View objects each time might be expensive. Another trick you could apply is to have a pool of mutable view parts, based on demand, you re-bind them to some of your model entities and display or hide them on demand. Depending on your specific use case, this could also help you to improve global performances.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top