La gestione degli eventi

1
La gestione degli eventi

• Antonio Cisternino

2
Programmazione ad Eventi

• Come abbiamo visto dagli esempi esiste un pattern
  comune ai vari sistemi per la gestione degli
  eventi
• La gestione degli eventi nelle interfacce si
  articola in
• Gestione degli eventi allinterno
  dellapplicazione
• Gestione degli eventi del gestore
  dellinterfaccia grafica

3
Delegate Event Model

• Questo modello, inizialmente introdotto da Java
  1.1, è ormai quello più diffuso nei framework di
  programmazione di GUI
• Il modello prevede
• Una sorgente degli eventi (es. il bottone)
• I consumatori degli eventi
• Delle interfacce (un modo di comunicazione
  concordato tra il produttore e il consumatore)

4
Schema di funzionamento
Consumatori registrati
Sorgente Eventi (es. Button)
Listeners (interfaccia richiesta dalla sorgente)
5
Il pattern in Java

• Il delegate event model può essere implementato
  in vari linguaggi
• In Java è realizzato utilizzando
• Convenzione sui nomi dei metodi per registrare
  consumatori presso la sorgente (addXXXListener(XXX
  Listener l))
• Interfaccia che la sorgente usa per comunicare
  levento (XXXListener)
• Invocazione dellevento la sorgente invoca uno
  dei metodi dellinterfaccia XXXListener

6
Chi fa cosa

• Produttore di eventi
• addXXXListener
• removeXXXListener
• Definisce una classe XXXEvent
• Definisce linterfaccia XXXListener
• Consumatore di eventi
• Implementa linterfaccia XXXListener
• Si registra presso il produttore

7
Il punto di vista dei controlli

• Il delegate event model, ideale per chi usa
  controlli, presenta problemi nella gestione degli
  eventi dei controlli
• Come si fa a rendere trasparenteun controllo ad
  un evento?
• Ad esempio il click su una label potrebbe
  convenire che sia notificato alla finestra che lo
  contiene

8
Propagazione degli eventi

• Il bubbling di un evento si ha quando viene
  passato al contenitore di chi lo ha ricevuto
• In questo modo si possono implementare i
  comportamenti di default
• Si possono anche gestire in modo centralizzato
  eventi di un controllo composto da finestre

9
Tunneling

• Framework come WPF (aka Avalon) supportano anche
  il flusso in direzione inversa al bubbling degli
  eventi il tunneling
• Questo flusso (solitamente seguito dal bubbling)
  offre la possibilità al contenitore di un
  controllo di gestire un evento prima che arrivi
  al figlio
• Il gestore dellinterfaccia decide, per ogni tipo
  evento, se è diretto, se fa uso di bubbling, o
  tunneling e bubbling

10
Implementiamo il bubbling

• Nei linguaggi orientati ad oggetti il bubbling
  viene facilmente scaricato sulla gerarchia
  dellereditarietà
• Nei framework OO normalmente tutti I componenti
  grafici ereditano da una classe base, ad esempio
  Component
• Dalla classe base tutti i componenti ereditano
  (direttamente o meno) un metodo deputato alla
  gestione degli eventi
• Il componente vede passare tutti gli eventi a lui
  diretti, e può gestirli localmente o delegare

11
Un esempio

• Java, nella sua prima versione (fino alla
  versione 1.0.2) aveva un modello di gestione
  degli eventi come OWL (Borland) e MFC (Microsoft)
  basato su bubbling
• La possibilità di invocare il metodo della
  superclasse consente di delegare la gestione di
  un evento non gestito (o solo parzialmente
  gestito)
• Il dispatch e la classificazione degli eventi
  viene tipicamente incapsulato da metodi invocati
  dal metodo che gestisce gli eventi, inclusa la
  delega

12
Java AWT Event Model

• class Component
• int x, y
• bool handleEvent(Event e)
• class Button extends Component
• String text
• bool handleEvent()
• class Window extends Component
• class Frame extends Window

13
Event handling

• class MyButton extends Button
• boolean handleEvent(Event e)
• switch (e.type)
• case Event.MOUSE_UP
• return true // Event handled!
• default
• return super.handleEvent(e)

14
Dal bubbling alla delegation

• I controlli, nella gestione degli eventi, possono
  implementare linterfaccia necessaria per essere
  una sorgente di eventi
• Per fare questo si possono intercettare gli
  eventi, ed invocare il metodo dei consumatori
  registrati
• La delegation migliora le performance la
  gestione degli eventi non necessita
  lintroduzione di nuove classi

15
Levent loop

• Chi invoca gli event handler?
• Un thread dellapplicazione spende una porzione
  significativa del suo tempo nellevent loop
• Levent loop ha la seguente struttura
• while (mPickMessage())
• DispatchMessage(m)
• Un qualche metodo (più o meno nascosto) esegue
  questo ciclo

16
Levent loop

• Normalmente levent-loop viene incapsulato in
  qualche classe (Application.Run per .NET,
  SwingUtilities.invokeLater in Java)
• La funzione di dispatch del messaggio si occupa
  di inoltrare il messaggio al componente
  dellapplicazione interessato
• Questo innesca il meccanismo di chiamate che poi
  va a chiamare gli event handler definiti
  dallapplicazione

17
Thread or threads?

• Quanti thread gestiscono levent loop?
• A dispetto dellapparente concorrenza degli
  eventi il thread della UI è uno
• Se un event handler lo blocca lintera
  interfaccia dellapplicazione smette di
  funzionare
• Se quindi è necessario intraprendere un qualche
  lavoro significativo è bene avviare un thread
  nellevent handler a cui delegare il compito

18
Troviamo il colpevole

• Come fa il gestore dellinterfaccia a individuare
  il destinatario di un evento?
• Input da tastiera il controllo che ha il focus
  riceve il messaggio
• Spesso il focus si ottiene evidenziando il
  controllo
• Usando il tab è possibile spostare il focus su
  altri controlli
• La pick correlation consiste nellassociare un
  evento del puntatore con il controllo a cui è
  diretto

19
Pick Correlation

• Come facciamo a sapere quale controllo deve
  ricevere gli eventi del puntatore?
• Abbiamo a disposizione le coordinate del punto
  (x, y), ma non sono sufficienti!
• Siamo tutti abituati a sovrapporre finestre
  qualè quella visibile?
• Il gestore dellinterfaccia organizza in modo
  appropriato le finestre e per ciascuna ricorda lo
  z-index ovvero un indice che indica lordinamento
  lungo lasse Z

20
Finestre e Z-Ordering

• La struttura dati primitiva delle interfacce
  grafiche (fino ad oggi) è la finestra unarea
  rettangolare dello schermo
• Tutti i controlli non sono altro che finestre
  specializzate
• Per trovare a quale finestra corrisponde un punto
  (x, y) sullo schermo è necessario
• trovare tutte le finestre che lo contengono
• tra queste prendere quella con z-index più alto
• Le finestre sono organizzate in un albero che
  consenta limplementazione della ricerca in modo
  più efficiente (sfruttando il contenimento)

21
Usare Spy

• Spy è un tool Microsoft (ne esistono analoghi
  per X-Windows) che consente di monitorare gli
  eventi diretti a finestre
• È anche possibile analizzare la struttura di
  unapplicazione in termini di finestre

22
Osserviamo gli eventi

• Se abilitiamo il log degli eventi su un bottone
  della calcolatrice notiamo che
• Gli eventi di paint arrivano in momenti inattesi
• Ci sono molti tipi di eventi
• Se invece facciamo il log della finestra vediamo
  in azione il bubbling alcuni eventi sui figli
  sono inviati anche al padre