Come fanno i team di app mobili a testare le scarse connessioni dei cellulari?

Come ha detto Dima, la modalità aereo è un ottimo punto di partenza. Puoi mettere il tuo dispositivo in modalità aereo prima di intraprendere azioni che attivano gli aggiornamenti di rete, e poi intraprendere l'azione, vedere come risponde mentre aspetta, e poi toglierlo dalla modalità aereo, e vedere come risponde dopo la riconnessione. Speriamo che la vostra app abbia la logica per riprovare e sincronizzarsi correttamente.

Per andare più a fondo nel test sul dispositivo, vi consiglio di impostare una rete wifi condizionata. Puoi farlo con il tuo Mac in cinque passi (ma hai bisogno di un cavo di rete):

1. Collega un cavo Ethernet al tuo Mac (potrebbe essere necessario utilizzare un adattatore Thunderbolt)
2. Installa XCode Network Conditioner [1]
3. Condividi il tuo wifi dal tuo Mac [2]
4. Collega il tuo dispositivo al wifi del tuo Mac
5. Mentre usi la tua app, cambia le impostazioni del Network Conditioner (offline, bad, good, etc)


Linux ha più strumenti di condizionamento e cattura/ispezione dei pacchetti rispetto al Mac. È possibile impostare un box wifi Linux dedicato con tc (netem) e tcpdump per portare questa idea al livello successivo.

[macchina wifi]

Un risultato di questi test potrebbe essere quello di ripensare parti della vostra app come più asincrone, attività in background. Un altro potrebbe essere costruire alcune cache locali.

In passato mi sono posto un paio di domande correlate:

- C'è un modo per condizionare facilmente la rete della vostra app per farla corrispondere alle esperienze reali degli utenti? Impostare alcuni argomenti del condizionatore del secchio è bello, ma sarebbe bello sapere che sto provando i giusti casi limite.
- Quindi probabilmente la maggior parte degli sviluppatori sta andando a gestire scenari di rete cattivi in modo simile. C'è un modo comune di farlo che le persone possono aggirare e contribuire?

Questo mi ha fatto pensare a costruire una migliore libreria di rete. Poi ho iniziato a costruirla. Puoi controllare cosa sto costruendo su https://github.com/nextopio/nextop-client.

Le idee centrali di questo progetto open source sono:
- Cambiare i default della consegna dei messaggi in modo che le richieste non vadano perse, mai. Finché un messaggio non viene consegnato, viene riprovato. Usa alcune tecniche intelligenti per evitare l'head-of-line-blocking senza che voi facciate nulla. E puoi sempre cancellare un messaggio.
- Aprire la porta a nuovi protocolli in un framework che può ripiegare senza soluzione di continuità su HTTP/HTTPS. Quindi avere un client che può provare qualcosa di nuovo, se questo sta fallendo, ripiegare su qualcosa di fidato, senza incasinare il vostro backend. Se avete visto i primi risultati di HTTP/2, allora sapete che le cose sono eccitanti. Un formato wire migliore può fare molto per rendere le app più utilizzabili nelle reti cattive.
- Costruire un protocollo migliore per tutte le reti.

Quindi qui sono di profilo nella mia app, usando una vista di debug Nextop, perché tutti i miei protocolli sono basati su una Wire.Factory [4] che mi permette di entrare e modellare il traffico con dati reali.

In sintesi, penso che abbiamo bisogno di strumenti migliori.

Spero che questo aiuti!

1. Condizionatore di rete
2. Preferenze -> Condivisione -> Condivisione Internet -> Condividi la tua connessione da Ethernet -> Ai computer che usano il WiFi
3. https://github.com/nextopio/nextop-client