If you're being a stickler about MVC, you are supposed to update the views in a UI in response to changes pushed out from the model. This is usually done by setting up an observation on the model in the controller, then updating the view from the controller.
Imagine you have an iOS app with a UISlider
on screen. The user is aggressively dragging the slider back and fourth. Each of these events is triggering a model change.
For every one of these events, you would need to notify the model of the change, let the model push that change out to the controller, and update the view from the controller.
- In the best case, this whole process is synchronous. That is, a new user touch-event is not processed until the main thread is totally done handling the first event, processing the change and updating the view. I'm not even sure this statement is true (is it all synchronous?). Assuming it's synchronous, the worst thing that can happen is the slider feels laggy if this whole round trip is costly to perform.
- Next case, assume the process is not synchronous; The touch event updates the model, then asynchronously the model notifies the controller of the change. Or perhaps the model rejects the change and does not notify at all. In this case perhaps the slider moves due to the view updating itself but then jumps to a new location due to the model->controller telling it to.
- Worst case: Adjusting the slider actually causes the app to send a message to some other process or maybe to the network. The app then asynchronously gets confirmation of the change from the remote side at some later point and pushes this change to the controller->view.
How should apps keep their UI responsive while at the same time observing model changes to ensure views don't get stale?
Aucun commentaire:
Enregistrer un commentaire