Un Player di Eventi per LEAD

Un Player di Eventi per LEAD

Angelo Cafaro

22/04/23 Angelo Cafaro - ISIS Lab. 2

Argomenti

1. Un breve riepilogo.

2. Il Player di eventi.

3. Implementazione del Player.

4. Un esempio di “replay”.


Un breve riepilogo (1)

Nel precedente seminario abbiamo parlato di:• Gestione dei client ritardatari.• Gestione dello Stato in LEAD:

ChatState; TreeChatState; CoreState;

• Salvataggio dello stato con XML.

1


Un breve riepilogo (2)

1


Il concetto di sessione

1 Per tenere traccia di tutte

gli eventi:• Ingresso/uscita client;• Avvio/Chiusura tool;• Contenuti dei tool.

L’ArrayList Content


Cosa conteneva “content”?

content: ArrayListM M M M M M ME E E E E E

Campo content all’interno di ToolSession:1


Cosa contiene ora “content”?

content: ArrayListE1 E E E E E E E E E E E


Il Player di Eventi -Le origini

Per ciascun tool offerto da LEAD abbiamo a disposizione un file XML:• ChatState.xml;• TreeChatState.xml.

All’interno di ciascun file possiamo trovare tutte le informazioni necessarie per poter

“ricostruire” una o più sessioni del tool a cui è legato il file:

• Data/ora di inizio/fine della sessione;• Ingresso/Uscita dei client;• Messaggi scambiati.

2

1


Il Player di Eventi -L’obiettivo

Utilizzare le informazioni contenute nei file XML per poter effettuare il “replay” di una sessione (di Chat o TreeChat).

Il “replay” deve avvenire nello stesso modo in cui è avvenuta la conversazione originale.• Bisogna rispettare la stessa tempistica degli eventi

così come sono stati generati nella conversazione reale. Possibile farlo perché ad ogni evento, nel file xml, è stato

associato il tempo in cui è avvenuto.

Dare la possibiltà di gestire il replay con i pulsanti standard di un comune “player” (Play – Pause – Stop).

2


Il Player di Eventi -Il riutilizzo di LEAD

Il player è stato creato “utilizzando” LEAD. Vantaggi:

• Funzionalità offerte da LEAD (avvio tool, ecc…).• UI già pronta e completamente adattabile

(quasi). Svantaggi:

• Individuare le parti di codice da: Modifiare per adattare al Player; Eliminare.

2


Implementazione – L’idea di base (cont.)

1. L’applicazione può essere avviata solo in modalità server (Moderatore).

• Vengono ignorati i parametri passati da linea di comando.

2. La GUI permette di scegliere il tool del quale vogliamo effettuare il replay mediante un combo-box.

Non compare più la “InstalledToolView”.3. Viene effettuato un login “nascosto” che può

essere definito un “login fittizio” (vedremo di cosa si tratta e a cosa serve).

4. Viene effettuato il parsing del file XML relativo al tool scelto.

3

2


Implementazione – L’idea di base (2)

5. L’utente sceglie una tra le sessioni disponibili (trovate nel file XML).

6. Viene avviato il server del tool ed il client.• Si ha un unico client.

7. Il server “legge” le informazioni da inviare al client quando l’utente avvia il replay (rispettando la tempistica degli eventi).

La UI offre una nuova view chiamata “ActionView” dove sono presenti i comandi: play – pause – stop.

• Il client riceve gli eventi dal server (sostanzialmente i messaggi) e li visualizza nella view del tool.

3


Implementazione – Le parti modificate/eliminate

Modalità di avvio solo server (Moderatore).

Lo stato non deve essere più gestito.• Neanche il salvataggio, ovviamente.

La “InstalledToolView non viene mostrata nella UI.

La view usata per il login (LogView) è stata modificata:• Nascoste le parti relative al login (eseguito

implicitamente quando l’utente sceglie un tool di cui vuole vedere un replay).

• Aggiunti i pulsanti per il replay.

3


Implementazione – Il “login fittizio” (cont.)

Per poter avviare i tool, usando lo schema base di LEAD, è necessario effettuare il login.• Lanciando l’applicazione in modalità server.

Problema: quando si effettua il login, la “PresenceView” mostra il nickname

dell’utente appena entrato. Soluzione: viene effettuato il così detto

“login fittizio”.

3


Implementazione – Il “login fittizio” (2)

Necessario caratterizzare gli utenti in base al ruolo che essi assumono.• Fatta in modo standard mediante l’interfaccia UserRoles:

3


Implementazione – Il “login fittizio” (3)

All’interno della “PresenceView” l’utente PLAYER viene filtrato, ossia non viene visualizzato tra gli utenti online

if(((PersonalData)obj).getRole() == UserRoles.PLAYER)

3


Implementazione – Il parsing del file XML

Operazione opposta al salvataggio. Andiamo a rispolverare vecchi ricordi…

3


Implementazione – L’interazione tra la ActionView ed il Server del tool (cont.)

Due ruoli fondamentali: ActionView:

• Riceve i comandi dall’utente. Avvio del replay. Pausa del replay. Interruzione.

Il server del tool:• Attraverso l’oggetto <tool>State ricava le

sessioni del tool salvate in memoria secondaria. L’oggetto <tool>State mette a disposizione il

proprio StateSerializer. • Invia al client del tool le informazioni da

visualizzare per il replay.

3


Implementazione – L’interazione tra la ActionView ed il Server del tool (2)

ActionView e <tool>Server comunicano mediante due interfacce:

3


Implementazione – Il ruolo di ActionManager

ActionManager mantiene i riferimenti di:• ActionView.

Il server lo usa per inviare notifiche alla view, ad esempio la fine del replay.

• Server del tool di cui si deve effettuare il replay. La ActionView lo usa per interagire con il “server

di turno” ed avviare (terminare o mettere in pausa) il replay.

Ovviamente i server e la view implementano le rispettive interfacce…

3


Implementazione – ActionManager…perché?

3


Implementazione – Interfaccia ActionControllerViewer

3


Implementazione – Interfaccia ActionServerPlayer

3


Implementazione – L’uso del timer (cont.)

3

Il player ricostruisce fedelmente le conversazioni di Chat (TreeChat).

I tempi che intercorrono tra un evento e l’altro, nel replay, sono gli stessi della conversazione originale.

Necessario l’ausilio della temporizzazione mediante il Timer.


Implementazione – L’uso del timer (2)

3

All’interno del server abbiamo a disposizione la lista degli eventi da visualizzare.• Ad ogni evento è associato il tempo

in cui è avvenuto. Il server, in fase di inizializzazione

del replay, costruisce un “array di differenze”…


Implementazione – Iniz. per il timer

3

Evento 117:17:10

Evento 217:17:13

Evento 317:17:40

Evento 417:18:02

Evento 517:18:06

Lista degli eventi da visualizzare (ArrayList)

Array di differenze, in ms, dei tempi

0 msEvento 1 Evento 2 Evento 3 Evento 4 Evento 5

3000

27000 22000 4000


Implementazione – Come vengono usate le differenze?

3

Array di differenze, in ms, dei tempi

0 msEvento 1 Evento 2 Evento 3 Evento 4 Evento 5

27000 22000 40003000

ToolServerTimer

0Evento 1

View

Evento 23000


Un esempio di “replay”di una conversazione di Chat

4

3

<chatSession id="4"><info><startDate>2006-10-03</startDate><startTime>21:41:31</startTime><endDate>2006-10-03</endDate><endTime>21:41:50</endTime></info><content><chatEvent action="enter" seqNum="0" time="21:41:31"><nickname>Lupin</nickname></chatEvent><chatEvent action="enter" seqNum="1" time="21:41:34"><nickname>Margot</nickname></chatEvent><chatMessage seqNum="2" time="21:41:36"><nickname>Lupin</nickname><text>Ciao tesoro!!!</text></chatMessage>


Un esempio di “replay”di una conversazione di Chat (2)

…<chatMessage seqNum="3" time="21:41:39"><nickname>Margot</nickname><text>Ciao!!!</text></chatMessage><chatMessage seqNum="4" time="21:41:45"><nickname>Lupin</nickname><text>allora hai pensato alle prossime vacanze?</text></chatMessage><chatMessage seqNum="5" time="21:41:50"><nickname>Margot</nickname><text>certo che si!!!</text></chatMessage>…</content>

</chatSession>

4


Un esempio di “replay”di una conversazione di TreeChat

<treeChatSession id="1"><info><startDate>2006-09-12</startDate><startTime>19:26:40</startTime><endDate>2006-09-12</endDate><endTime>19:27:46</endTime></info><content><treeChatEvent action="enter" seqNum="0" time="19:26:41"><nickname>Lupin</nickname></treeChatEvent><treeChatEvent action="enter" seqNum="1" time="19:27:03"><nickname>Margot</nickname></treeChatEvent><treeChatMessage id="1" parentID="0" seqNum="2" time="19:27:16"><nickname>Lupin</nickname><text>Prossimo colpo</text></treeChatMessage>

…

4


Un esempio di “replay”di una conversazione di TreeChat (2)

…<treeChatMessage id="1.1" parentID="1" seqNum="3" time="19:27:25"><nickname>Margot</nickname><text>Dobbiamo aspettare jigen</text></treeChatMessage><treeChatMessage id="2" parentID="0" seqNum="4" time="19:27:37"><nickname>Lupin</nickname><text>Parliamo di altro...</text></treeChatMessage><treeChatMessage id="2.1" parentID="2" seqNum="5" time="19:27:46"><nickname>Margot</nickname><text>Allora mi ragali un diamante???</text></treeChatMessage>…

</content></treeChatSession>

4

Un Player di Eventi per LEAD

Documents

Transcript of Un Player di Eventi per LEAD