Tips & Tricks: multi threading per operazioni lunghe

by Giuseppe Lanzi on 9 marzo 2016

Capita spesso di dover gestire operazioni lunghe nelle proprie applicazioni, specialmente in ambito gestionale. Questo può portare a un dilemma dell’utente finale che non sa bene come comportarsi.

Infatti quando viene avviata un’operazione lunga l’interfaccia delle applicazioni si deve fermare per aspettare la risposta del server, facendo comparire la classica videata attendere prego che conoscete in molti. Capita anche con le applicazioni fatte con Instant Developer Foundation, ma c’è una soluzione decisamente interessante: usare le Server Session.

Immaginiamo di avere una procedura applicativa che impiega dai 5 ai 60 secondi, nel progetto di esempio potete lanciare il metodo con il comando Long Method, vedrete comparire la barra di attesa per qualche decina di secondi. Noi non vogliamo che l’utente abbia questo tipo di esperienza, vediamo come possiamo fare.

Per prima cosa utilizziamo i metodi di startPhase e trackPhase nel metodo lungo, così da informare l’applicazione dello stato di avanzamento dell’operazione. Nel codice del progetto di esempio viene calcolato un numero casuale di step da 5 a 60, ognuno dei quali dura 1 secondo.

Dopodiché decidiamo di assegnare ad ogni utente, riconosciuto con il proprio username, un numero prefissato di processi indipendenti. Nell’esempio ne ho concesse 3 per ogni utente. Al momento dell’avvio dell’operazione invece di lanciarla immediatamente vediamo se l’utente ha a disposizione una sessione. Ogni sessione è identificata da un nome, nell’esempio UsernameN, dove N rappresenta il numero del processo.

Per avviare un nuovo processo, cioè un’altra sessione applicativa, utilizziamo il metodo startSession, al quale passiamo una query string che identifica l’operazione da lanciare nell’evento di onCommand. Se non ci sono processi disponibili viene mostrato un messaggio in cui si chiede all’utente di riprovare più tardi.

A questo punto dobbiamo informare l’utente di quanti processi ha e qual è il loro stato di avanzamento. Per farlo utilizziamo i metodi existsSession e sessionProgress, mettendo i risultati in una tabella IMDB da mettere a video. E il gioco e fatto.

Che ne pensate? D’ora in poi mai più “attendere prego” .

Quale prossimo trucco ti interesserebbe vedere?

  •    Web API: pubblicare i dati di un'app direttamente su un sito web
  •    Mobile: sincronizzazione dati utente multi dominio
  •    Intregazione di un componente grafico javascript

{ 5 comments… read them below or add one }

1 luca colombo 9 marzo 2016 alle 17:34

troppi dati obbligatori :-) e niente * per dire che il commento è obbligatorio

2 simone 9 marzo 2016 alle 17:44

Per le server session non ho niente da dire. Tuttavia non sempre è possibile utilizzarle e quindi si ricorre alla combo startPhase/trackPhase. Sarebbe ottimale se nella videatina di attesa si potesse cambiare il messaggio a nostro piacimento (ad esempio scrivere la percentuale rimanente)

3 Giuseppe Lanzi 9 marzo 2016 alle 18:37

si può cambiare il messaggio nella startPhase. Per cambiare il messaggio in corsa potresti rilanciare sempre la startPhase con lo stesso numero di passi, specificando subito dopo una trackPhase con il numero del passo corrente

4 Luca Murzio 14 marzo 2016 alle 16:06

Io le utilizzo ma c’è ad oggi un grosso handicap legato al debug che non funziona quasi mai ….

5 Giuseppe Lanzi 22 marzo 2016 alle 23:01

@luca il debug di una server session solitamante io lo leggo come debug su file, mi piacerebbe capire quali sono i casi che non vanno per vedere come possiamo migliorare. Potresti inserire una segnalazione così ci guardiamo insieme?

Leave a Comment

Previous post:

Next post: