1. 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

2. 6/13/20152 Outline 4 Model-view controller *Why do we need it? *Changing the display *Event flow *Dragging at interactive speeds 4 Interactive application programming *Callbacks *Multi-threaded programming

3. 6/13/20153 Model-View-Controller 4 Architecture for interactive apps *introduced by Smalltalk developers at PARC 4 Partitions application in a way that is *scalable *maintainable Model View Controller

4. 6/13/20154 Example Application Blue circles: 4 Cardinal squares: 2

5. 6/13/20155 Model 4 Information the app is trying to manipulate 4 Representation of real world objects *circuit for a CAD program +logic gates and wires connecting them *shapes in a drawing program +geometry and color Model View Controller

6. 6/13/20156 View 4 Implements a visual display of the model 4 May have multiple views *e.g., shape view and numerical view Model View Controller

7. 6/13/20157 Multiple Views Blue circles: 4 Cardinal squares: 2

8. 6/13/20158 View 4 Implements a visual display of the model 4 May have multiple views *e.g., shape view and numerical view 4 Any time the model is changed, each view must be notified so that it can change later *e.g., adding a new shape Model View Controller

9. 6/13/20159 Controller 4 Receives all input events from the user 4 Decides what they mean and what to do *communicates with view to determine which objects are being manipulated (e.g., selection) *calls model methods to make changes on objects +model makes change and notifies views to update Model View Controller

10. 6/13/201510 Controller Blue circles: 4 Cardinal squares: 2

11. 6/13/201511 Controller Blue circles: 4 Cardinal squares: 2

12. 6/13/201512 Relationship of View & Controller “pattern of behavior in response to user events (controller issues) is independent of visual geometry (view issues)” 4 Controller must contact view to interpret what user events mean (e.g., selection)

13. 6/13/201513 Combining View & Controller 4 View and controller are tightly intertwined *lots of communication between the two 4 Almost always occur in pairs *i.e., for each view, need a separate controller 4 Many architectures combine into a single class Model View Controller

14. 6/13/201514 Why MVC? 4 Combining MVC into one class or using global variables will not scale *model may have more than one view +each is different and needs update when model changes 4 Separation eases maintenance *easy to add a new view later *new model info may be needed, but old views still work *can change a view later, e.g., draw shapes in 3-d (recall, view handles selection)

15. 6/13/201515 4 Presentations next Mon-Weds 4 Monday groups 1-5 4 Weds groups 6-10

16. 6/13/201516 Adding Views Later Blue circles: 4 Cardinal squares: 2

17. 6/13/201517 Changing the Display 4 How do we redraw when shape moves?

18. 6/13/201518 Moving Cardinal Square Blue circles: 4 Cardinal squares: 2

19. 6/13/201519 Erase w/ Background Color and Redraw Blue circles: 4 Cardinal squares: 2

20. 6/13/201520 Changing the Display 4 Erase and redraw *using background color to erase fails *drawing shape in new position loses ordering 4 Move in model and then redraw view *change position of shapes in model *model keeps shapes in a desired order *tell all views to redraw themselves in order *slow for large / complex drawings +flashing!

21. 6/13/201521 Damage / Redraw Method 4 View informs windowing system of areas that need to be updated (i.e., damaged) *does not redraw them at this time… 4 Windowing system *batches updates *clips them to visible portions of window 4 Next time waiting for input *windowing system calls Redraw method for win. +passes region that needs to be updated

22. 6/13/201522 Damage old, Change position in model, Damage new Blue circles: 4 Cardinal squares: 2

23. 6/13/201523 Event Flow 4 Creating a new shape

24. 6/13/201524 Event Flow (cont.) 4 Assume blue circle selected Blue circles: 0 Cardinal squares: 0

25. 6/13/201525 Event Flow (cont.) 4 Press mouse over tentative position 4 Windowing system identifies proper window for event 4 Controller for drawing area gets mouse click event 4 Checks mode and sees “circle” 4 Calls models AddCircle method with new position Blue circles: 0 Cardinal squares: 0

26. 6/13/201526 Event Flow (cont.) 4 AddCircle adds new circle to model’s list of objects 4 Model then notifies list of views of change *drawing area view and text summary view 4 Views notifies windowing system of damage *both views notify WS without making changes yet! +model may override Blue circles: 0 Cardinal squares: 0

27. 6/13/201527 Event Flow (cont.) 4 Views return to model, which returns to controller 4 Controller returns to event handler 4 Event handler notices damage requests pending and responds 4 If one of the views was obscured, it would be ignored Blue circles: 0 Cardinal squares: 0

28. 6/13/201528 Event Flow (cont.) 4 Event handler calls view’s Redraw methods with damaged area 4 Views redraw all objects in model that are in damaged area Blue circles: 1 Cardinal squares: 0

29. 6/13/201529 Dragging at Interactive Speeds 4 Damage old, move, damage new method may be too slow *must take less than 200 ms to be smooth 4 Solutions *don’t draw object, draw an outline (cartoon) +use XOR to erase fast (problems w/ color) +save portion of frame buffer before dragging

30. 6/13/201530 Break 4 Next week presentations: 4 Monday: groups 1-5 4 Wednesday: groups 6-10

31. 6/13/201531 Interactive programming 4 Callbacks 4 Threading

32. 6/13/201532 Callbacks 4 Callbacks: every widget registers itself to receive certain events with the OS. 4 Dangers: UI code using callbacks is usually single-threaded. Control does not return to the event loop until the callback returns. Therefore in a callback routine, never: *Wait for another event. *Sleep. *Perform I/O or other actions that may block.

33. 6/13/201533 4 HE Principles: 4 User control and freedom 4 Visibility of system status 4 Help, 4 diagnosing errors

34. 6/13/201534 Threaded code 4 Multi-threaded code uses distinct threads for distinct widgets. 4 It allows blocking operations (e.g. I/O) to be confined to particular threads that don’t affect interactivity. 4 If your program has any time-intensive parts, they should run in different threads from the UI code.

35. 6/13/201535 Threaded code 4 Use separate threads for any operations that can occur asynchronously: *UI interactions. *File operations – use separate threads if you need to be updating several files at the same time. *Inter-process communication (sockets): use one thread for each connection. *Use a thread for each other I/O device, e.g. one each for reading from or writing to the sound card.

36. 6/13/201536 Inter-thread communication 4 The window system and running process in the OS communicate using message passing: *The event queue and sockets are examples of message-passing primitives. 4 Processes in the same address space (i.e. within your program) can use shared memory (i.e. shared variables) which is much more efficient.

37. 6/13/201537 Inter-thread communication 4 Why can’t thread A call thread B (like a callback?)

38. 6/13/201538 Synchronization 4 Shared-memory communication poses challenges. If you rely on “mailbox” primitives, things can go wrong: 0 Flag to show this thread is writing new data Data

39. 6/13/201539 Synchronization Intuitively, threads that want to write should: …. wait until thread_id = 0; write thread_id; write data; 0 Data Flag to show this thread is writing new data

40. 6/13/201540 Synchronization But thread switching can happen anytime, e.g. …. wait until thread_id = 0; write thread_id; write data; 0 Data Flag to show this thread is writing new data

41. 6/13/201541 Synchronization A switch between checking the flag and setting it allows both threads to (incorrectly) write the flag and their data. To prevent this, we define critical sections of the code that cannot be interrupted. 0 Data Flag to show this thread is writing new data

42. 6/13/201542 Synchronization e.g. the critical section in the example is: …. wait until thread_id = 0; write thread_id; write data; 0 Data Critical section, thread can’t be pre-empted. Flag to show this thread is writing new data

43. 6/13/201543 Semaphores Rather than many critical sections in your code, you can use a single semaphore primitive. A semaphore is initialized to an integer n, and has just two operations: test(); wait until semaphore > 0, then decrement it. increment(); increment the semaphore.

44. 6/13/201544 Semaphore example Then the example code becomes (with sem1 initialized to 1): …. sem1.test(); write thread_id; write data; sem1.increment(); This section cannot be pre-empted by the other process that is using this semaphore.

45. 6/13/201545 Summary 4 Model-view controller *Why do we need it? *Changing the display *Event flow *Dragging at interactive speeds 4 Interactive application programming *Callbacks *Multi-threaded programming