Qual è il modo giusto per fare richieste HTTP quando cambia il valore di un cursore?

6

Sto progettando un software di base per sistemi di illuminazione wireless intelligenti. Il software è basato su GUI e ho un cursore per l'impostazione della luminosità di una luce nella GUI. Il sistema di illuminazione ha un'API RESTful in modo da poter ascoltare le modifiche sul valore del cursore e fare una richiesta HTTP con il valore del sistema. Il fatto è che sembra assolutamente ingenuo fare nuove richieste HTTP con ogni singolo cambiamento di valore.

Ad esempio, se l'utente cambia il valore del cursore da 70 a 20, il software farebbe 50 richieste HTTP.

In che modo le persone affrontano questo tipo di problema? Attendo dopo ogni richiesta per una durata definita? Qual è la migliore pratica per superare la realizzazione di quasi un centinaio di richieste?

    
posta Eralp Şahin 07.09.2017 - 18:18
fonte

2 risposte

8

Dipende davvero da come si intende fornire feedback e quanto velocemente il controller hardware può rispondere. C'è più di un modo per gestirlo e la correttezza della soluzione dipende molto da ciò che gli utenti si aspettano. In realtà, le soluzioni potenziali non si escludono a vicenda.

  • Invia richiesta dopo n millisecondi di un valore stabile
  • Invia richiesta ogni n millisecondi durante la modifica
  • Invia richiesta dopo una modifica di valore di n

Per il caso nominale, 100ms si sente immediato per la maggior parte degli utenti. Tuttavia, se il tuo controller luce richiede 250 ms per rispondere, questo è davvero il tuo fattore limitante. Quel periodo di tempo non è male e si sente ancora reattivo.

Il problema che stai affrontando è in realtà comune ai cursori in generale. Poiché possono causare molti eventi, l'interfaccia utente può impantanarsi ascoltandoli, in particolare se ci sono altri aggiornamenti sullo schermo.

Dato che stai controllando un sistema di illuminazione, vorrei prendere alcune misure:

  • Quanto velocemente risponde il sistema di illuminazione? (tempo di cambiamento visibile)
  • Qual è la soglia del cambiamento che è effettivamente visibile? (quanti incrementi prima di notare il cambiamento dell'intensità della luce)

Considerate queste informazioni, potete elaborare un piano sufficiente in modo che il sistema di illuminazione si senta reattivo, ma non bombardate il vostro dispositivo con richieste più rapide di quanto possa realmente rispondere.

Il motivo per cui ho detto che dipende da come intendi fornire un feedback è perché le diverse soluzioni hanno un impatto sul modo in cui il tuo software viene percepito:

  • Rimbalzo (dopo n millisecondi di nessun cambiamento): non c'è feedback visibile finché l'utente non smette di giocare con il cursore
  • Limite di tempo (ogni n millisecondi durante il cambio): c'è un feedback continuo a una velocità che il sistema può gestire
  • Limitazione del valore (dopo la modifica del valore di n): il feedback ha una frequenza effettivamente percepibile

Se combini tutte e tre le opzioni, funzionerebbe in questo modo:

  • Mentre il cursore viene controllato:
    • Non inviamo aggiornamenti prima di "n" millisecondi
    • Inviamo una richiesta solo se esiste un delta di "x" tra l'ultima richiesta e ora
  • Quando il cursore è fermo:
    • Inviamo un ultimo aggiornamento dopo "n" millisecondi di riposo

Ancora una volta, è importante sapere ora che le diverse opzioni influiscono sugli utenti e su cosa si aspettano.

    
risposta data 07.09.2017 - 19:11
fonte
1

Il termine a cui stai pensando è "rimbalzo". Si sta eseguendo un'azione solo una volta entro un periodo di tempo o dopo un certo periodo di inattività in cui tale azione viene richiesta più volte.

In Javascript eseguendo l'azione dopo un periodo di inattività sarebbe:

var timer = null;
var action = () =>
{
    clearTimeout(timer);
    timer = setTimeout(() =>
    {
        // Do http request with current value
    }, 500);
};

action();
setTimeout(action, 300);
setTimeout(action, 600);

Quindi vedresti una richiesta http. Nell'esempio di un dispositivo di scorrimento, l'utente potrebbe trascinarlo per un po 'e non visualizzare mai un aggiornamento finché non si fermano per 500 ms. Se invece si avvia un timeout come:

var timer = null;
var action = () =>
{
    if (timer == null)
    {
        timer = setTimeout(() =>
        {
            // Do http request with current value
            timer = null;
        }, 500);
    }
};

action();
setTimeout(action, 300);
setTimeout(action, 600);

Vedresti due richieste http perché il timeout attende 500 ms prima di avviare una richiesta http assumendo che l'utente stia trascinando un po '.

    
risposta data 07.09.2017 - 19:11
fonte

Leggi altre domande sui tag