Pattern per la sincronizzazione dei dati delle app mobili tramite HTTP su reti 3G

Question

Pattern per la sincronizzazione dei dati delle app mobili tramite HTTP su reti 3G

#1 da (3 voti)

3

Ho un'app mobile costruita con jquerymobile, PhoneGap e alcuni CSS e JavaScript personalizzati. Gli oggetti dati vengono ricevuti in JSON e utilizzati per visualizzare diversi moduli all'utente. Ad esempio

{ id: 1, type: personal_details, question_1: "First name", question_2: "Last name" },
{ id: 2, type: work_details, question_1: "Occupation", question_2: "Experience" }

L'utente compila questi moduli e rimanda i dati a un'applicazione .NET. Le cose funzionano alla grande quando c'è una buona connessione 3G, ma non è sempre così.

Man mano che ogni modulo viene inviato, c'è il pericolo che non tutte le forme tornino insieme. Nel nostro esempio, i dettagli personali potrebbero essere inviati per primi, la connessione viene persa e i dettagli del lavoro vengono lasciati sul dispositivo mobile o persi sulla rete di cui uno dei due frustra i miei utenti.

Qual è la migliore strategia per gestire e recuperare elegantemente dagli errori di rete? Affidarsi ai codici di risposta HTTP non sembra funzionare. Per es.

for ( form in forms ) {
    $.ajax({
        url: 'http://ac.me',
        data: form,
        success: function (){
            // delete from localStorage
        },
        error: function (){
            // show error message 'try again later'
        }
    });
}

La richiesta può fallire e la funzione di errore non viene mai chiamata. L'alternativa che vedo è l'invio di tutti i moduli in una stringa JSON, ma sono preoccupato per le implicazioni di prestazioni del server SQL che elabora molte richieste brevi o richieste meno lunghe.

javascript algorithms networks data

posta Peter 09.01.2013 - 18:44

fonte

1 risposta

Leggi altre domande sui tag javascript algorithms networks data

Colpite il limite superiore per le funzionalità API di Cross Platform Algoritmo di etichettatura per i punti

score 3 · Accepted Answer

In realtà probabilmente stai meglio mandandoli tutti in una volta.

Le richieste HTTP sono costose È necessario ricordare che l'atto di fare richieste HTTP è, in genere, costoso. È per questo che dovresti unire il tuo JavaScript in un unico file e creare sprite per i siti web.

Perché sono costosi? E perché importa anche su un'applicazione mobile (anche se, per amor di discussione, lo stai facendo in modo nativo)? Perché è l'atto di rendere la connessione stessa che lo rende costoso. Per aprire una connessione HTTP, il client e il server eseguono una serie di passaggi:

Ricerca DNS. Il server è effettivamente lì? Il client può connettersi ad esso?
SYN Lo è? Grande! Avvia la transazione di handshake (questo è noto come pacchetto "SYN").
SYN-ACK il server risponde con il passaggio successivo della transazione di handshake, noto come pacchetto "SYN-ACK".
ACK il client risponde di nuovo, con il terzo e ultimo passaggio dell'handshake. Se tutti e tre i passaggi hanno esito positivo, viene stabilita la connessione. Ora, possiamo effettivamente ottenere la nostra richiesta.
Invia la richiesta. Qui i dati vengono effettivamente inviati.
Attendi risposta. Il server deve fare qualcosa con la richiesta, il che richiede tempo, soprattutto se sono coinvolti un database o calcoli pesanti.
Ricevi risposta il server restituisce la risposta. Ciò richiede tempo in base alla dimensione della risposta e all'integrità della connessione, proprio come il passaggio della richiesta di invio.
Carica ora il client deve fare qualcosa con le informazioni che ha recuperato dal server. Di solito, lo rende su un dispositivo di output o attiva un altro evento.
FIN Il client invia un pacchetto "FIN" che chiude la connessione HTTP

(Controlla questa ripartizione su l'anatomia di una connessione HTTP per ulteriori informazioni.)

Le richieste HTTP hanno molti punti di errore basati sulla rete Dai un'occhiata nuovamente all'elenco di passaggi sopra riportato che passa attraverso una transazione. Sei dei 9 passaggi causeranno il fallimento della connessione e la perdita dei dati in caso di interruzione della connessione di rete. Questo è un sacco di punti di fallimento. Ripeti i punti di errore ogni volta che fai una richiesta HTTP. Quindi, più volte fai la richiesta, più possibilità hai di una richiesta di non riuscire a causa di problemi di rete.

Gli oggetti JSON non sono così grandi Gli oggetti JSON, essendo solo testo, sono piuttosto piccoli se fatti correttamente. Loro possono diventare piuttosto grandi, ma dovresti inviare un tonnellata di dati (molto probabilmente più dati di quelli effettivamente necessari e probabilmente possono filtrare verso il basso, come la ricerca risultati con un termine di ricerca troppo vago) per farlo. Rispetto al costo di creare la connessione HTTP, devi essere abbastanza grande da compensarlo con troppi dati JSON.

JavaScript non ottiene risposta dalle connessioni eliminate Questo è il motivo per cui la funzione "errore" non viene chiamata su una connessione interrotta (una risposta "errore" è ancora una risposta dal server). JavaScript aspetterà indefinitamente, a meno che non venga detto diversamente, per una risposta. Se la connessione di rete si interrompe, JS non ne è a conoscenza e continuerà ad attendere una risposta che non arriva mai. La soluzione migliore per questo problema è impostare un meccanismo di timeout e riprovare la connessione se il precedente è scaduto.

Richieste HTTP non hanno nulla a che fare con SQL Server Dovresti avere un livello applicazione, che espone un'API al tuo client, tra il tuo client e SQL Server. In quanto tale, puoi formattare le richieste del database in un modo che abbia senso, indipendentemente da ciò che fai sul lato client.