cosa significa esattamente NSUrlConnection ASynchronous?

Question

mi confondo Qual è la differenza tra Synurronous NSUrlConnection e ASynchronous NSUrlConnection? C'è Synchronous o ASynchronous? se usiamo detachNewThreadSelector nel metodo connectionDidFinishLoading, è ASRchronous NSUrlConnection? qual è il modo migliore? qualsiasi tutorial ...

Answer 1

Synchronous significa che si attiva la richiesta NSURLConnection e si attende che venga eseguita.

Asincrono significa che è possibile attivare la richiesta e fare altre cose mentre NSURLConnection scarica i dati.

Qual è il "migliore"?

Synchronous è molto semplice: lo si imposta, lo si attiva e si attende il ritorno dei dati. Ma l'applicazione si trova lì e non fa nulla finché tutti i dati non vengono scaricati, si verifica qualche errore o la richiesta scade. Se hai a che fare con qualcosa di più di una piccola quantità di dati, il tuo utente siederà lì in attesa, cosa che non renderà una buona esperienza utente.

Asincrono richiede solo un po 'di lavoro in più, ma il tuo utente può fare altre cose mentre la richiesta fa la sua cosa, che di solito è preferibile. Puoi impostare alcuni metodi di delega che ti consentono di tenere traccia dei dati così come sono disponibili, il che è utile per monitorare i progressi del download. Questo approccio è probabilmente migliore per la maggior parte dei casi di utilizzo.

È possibile eseguire entrambe le richieste sincrone e asincrone con NSURLConnection. Il numero documentation di Apple fornisce una chiara spiegazione dei due approcci e dei metodi delegati richiesti per quest'ultimo approccio.

Answer 2

Sembra che tu stia confondendo connessioni sincrone/asincrone e threading. Nella mia app ho usato connessioni asincrone come alternativa al threading.

Diciamo che si desidera scaricare un file di grandi dimensioni senza causare il blocco dell'interfaccia utente. Hai due opzioni di base:

1. Connessione asincrona. Si inizia con + connectionWithRequest:delegate: (o con una delle altre opzioni non autorelease) e si scarica il bit del file, chiamando il proprio delegato quando accade qualcosa di interessante. Il runloop continua, quindi l'interfaccia utente rimane reattiva. Ovviamente devi stare attento che i tuoi delegati non vadano fuori portata.

2. Sincrona. Si avvia la connessione con + sendSynchronousRequest:returningResponse:error: ma il codice attende fino al completamento del download. Avrai davvero bisogno di generare un nuovo thread (o una delle operazioni di threading di livello superiore supportate da Cocoa) o l'interfaccia utente bloccherà.

Quale opzione è "migliore" o meno dolorosa dipende dall'architettura dell'applicazione e da ciò che si sta tentando di ottenere. Se è necessario creare un thread per un processo di lunga durata, si potrebbe andare con la seconda opzione. In generale, direi che la prima opzione è la più semplice.

È tutto piuttosto bello documented on Apple's Developer site.

Answer 3

Qualcosa che non è stato menzionato nelle altre risposte è la dimensione della richiesta. Se stai scaricando un file di grandi dimensioni, ad esempio, è preferibile utilizzare una connessione asincrona. Il delegato riceverà blocchi di dati all'arrivo. In confronto, il metodo sincrono attenderà tutti i dati prima di renderli disponibili.Il delegato può iniziare a elaborare la risposta prima (migliore esperienza utente) o salvarlo in un file anziché in memoria (utilizzo di risorse migliori). Hai anche la possibilità di interrompere la risposta senza attendere tutti i dati.

Fondamentalmente, il metodo asincrono offre un maggiore controllo sulla connessione ma al costo della complessità. Il metodo sincrono è molto più semplice, ma non dovrebbe essere utilizzato sul thread principale dell'interfaccia utente perché si blocca.

Answer 4

In risposta alle altre risposte relative alla dimensione del file: Penso che le dimensioni del file non contengano. Se il server risponde molto lentamente e stai caricando i dati in modo sincrono, l'interfaccia utente si blocca ancora, anche se carichi una piccola quantità di dati, come 3k.

Quindi opterei per l'opzione asincrona in ogni situazione, perché non si sa mai cosa si otterrà in termini di dimensioni del file, reattività del server o velocità della rete.