A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I need some more elaboration regarding the implementation of view updates. Here is the specifics: I have a table of data which three views use to display to the user. Each view could potentially modify the data. When data is modified, all the views need to be updated to reflect the changes.
I know this calls for the observer/subscribe pattern. My problem is with the specifics of the implementation. When a piece of data changes, right now I update everything on all the views which is rather inefficient. However, I am having difficulty coming up with a way to update only what changed. The problem is conveying to the views exactly what changed.
The issue is that the controller does not really know much about the views. And the views do not know much about the specifics of the data. Because of all this abstraction, the easiest thing to do is to just get all the views to refresh everything. The controller does this by calling "refresh" on all the subscribed views when the data changes.
How can I implement a more efficient update algorithm for my views so that I don't have to throw out everything and repopulate them every time something changes?
Tuesday, March 06, 2007
I see only two answers (after, admittedly, very brief consideration):
1) make the views smarter. The views could certainly examine the current data set (which they must know a fair amount about, in order to render the data) and redraw only the parts that have changed. While this doesn't reduce the communication load between the view and the controller or model, it does reduce the amount of drawing done by a view.
2) increase coupling between controller/model and views. Obviously you could add a new method to the view that would trigger a refresh while indicating what data in the model has changed. Again, I can't quite imagine how the views couldn't already be fairly tightly coupled to the model, since they need to know enough to render it, but this would certainly introduce some coupling between the controller-view protocol and the model.
The first method is simlar to what is done by curses where a copy of the current display is kept in a buffer and all changed are mapped to the buffer before being sent to the real display. Curses is able to determine a minimal set of display updates to make in order to reflect the changes made by the client program.
The second method is common in GUI systems, where updates to a window include the region of the window that needs to be updated. This is done purely to reduce the amount of actual drawing that is requested of the GUI system by the client programs.
Tuesday, March 06, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz