Schermi multitouch in spazi pubblici: solo pubblicità o anche servizi utili?

La tecnologia utilizzata per implementare il sistema nel nostro caso è MT4J, che prevede la possibilità di usare meccanismi per passare da un’applicazione all’altra senza dover chiudere il sistema.
Nel nostro caso questa l’idea di questa funzione c’è tornata molto utile perché direttamente dal menu di ogni applicazione abbiamo introdotto delle voci di collegamento a tutte le altre applicazioni esistenti. Purtroppo, questa modalità di MT4J ha presentato dei problemi molto seri via via che le applicazioni diventavano più complesse; perciò abbiamo ideato una nuova soluzione tecnica ma con gli stessi effetti di quella prevista nell’MT4J, consentendoci infatti di utilizzare sempre le voci dei menu per spostarsi da un’applicazione all’altra.
Un altro vincolo molto importante da dover rispettare è stato quello della velocità di cambio da un’applicazione all’altra; tutte le applicazioni destinate al multitouch, anche le più semplici hanno una certa complessità interna che si ripercuote in maniera molto evidente all’apertura dei programmi, momento in cui la JVM7 deve interpretare e caricare in memoria tutte le classi necessarie. Ovviamente, se un’applicazione ha interfacce grafiche molto complesse questo fenomeno è ancora più evidente e così sarebbe stato se non avessimo adottato dei modi per aggirare il problema. Non stiamo parlando di minuti ma soltanto di qualche secondo che però dal punto di vista dell’utente potrebbe essere colto come un problema del sistema, come una mancata risposta. Pensiamo al momento in cui un utente decide di cambiare applicazione spostandosi da Interactive Program a taxisharing: quando viene toccato il tasto di taxisharing, il sistema normalmente impiegherebbe qualche secondo prima di caricare e visualizzare la nuova applicazione e questo potrebbe essere percepito da parte dell’utente come una mancata risposta, con il risultato che l’utente toccherà in continuazione quel pulsante fino all’apertura effettiva di taxisharing. Anche volendo prevedere dei meccanismi di feedback con cui si fa capire all’utente che si sta caricando una nuova applicazione, questo non va comunque bene in situazioni particolari come un congresso, dove le persone sono di passaggio, hanno poco tempo da dedicare e vogliono provare in quei pochi secondi o minuti in cui interagiscono quante piú applicazioni possibile, perciò rallentamenti del genere risulterebbero molto fastidiosi.
La soluzione proposta consiste nel caricare in memoria dei livelli visuali su cui vengono "sistemate" le applicazioni: queste sono caricate in memoria ram tutte insieme all’avvio e lì forzatamente restano fino alla terminazione del programma. Il risultato del caricamento in memoria forzato delle applicazioni è che il cambio da un’applicazione all’altra è istantanea, poiché la JVM non ha bisogno di portare in memoria altro. Si potrebbe pensare che il dispendio di ram sia oneroso ma si deve considerare che una macchina destinata a far funzionare questi schermi, durante l’esecuzione di queste applicazioni non farà altro che eseguire le applicazioni e quindi non c’è pericolo di saturare mai la ram andando a eseguire altri programmi al di fuori di quelli per il multitouch. Nel nostro caso, ad esempio, la suite esegue contemporaneamente sul sistema quattro applicazioni, tutte molto complesse, ricche d’immagini e video. Considerando che caricando un’applicazione vuota realizzata in MT4J la ram richiesta è di quasi 400 Mb, aggiungendo il caricamento di tutte e 4 le applicazioni della suite in memoria si raggiunge circa 750 Mb, valore che non aumenta mai perché tutto il contenuto delle applicazioni viene completamente caricato all’avvio.