Perché utilizziamo le librerie di rete invece di semplici NSURLRequests e NSURLConnection?

Question

Perché utilizziamo le librerie di rete invece di semplici NSURLRequests e NSURLConnection?

#1 da (3 voti)
#2 da (2 voti)

0

nello sviluppo iOS, ho visto spesso persone che creano un modulo di rete per interagire con le loro API.

Questo modulo generalmente si trova in cima a un framework di rete come MKNetWorkKit o AFNetWorking.

Nella maggior parte dei casi, si tratta di inviare GET, richiesta POST e analizzare la risposta che nella maggior parte dei casi è JSON.

Quali ulteriori vantaggi pratici che queste librerie offrono che uno sviluppatore iOS debba sfruttare le normali API di Cocoa Networking?

Posso capire RESTKit come un'eccezione in cui si prende cura della conversione di JSON in oggetti nativi e si interfaccia anche con Core Data, ma per quanto riguarda gli altri?

ios objective-c

posta Amogh Talpallikar 02.07.2013 - 08:22

fonte

2 risposte

Leggi altre domande sui tag ios objective-c

L'editor di testi firma i file? [chiuso] Come ridurre al minimo l'utilizzo di variabili e oggetti statici

score 3 · Answer 1

What extra practical benefits that these libraries provide that an iOS developer should be leveraging which the plain Cocoa Networking APIs lack ?

Gestione degli errori, facilità d'uso, codice semplificato, ecc. NSURLConnection è una grande classe e molto flessibile, ma se dai un'occhiata a NSURLConnectionDelegate vedrai che ci sono parecchi diversi stati di rete che devono essere gestiti. Una buona libreria di rete si occupa di gran parte del lavoro di routine.

score 2 · Answer 2

Uno degli obiettivi potrebbe essere quello di astrarre il modo in cui si accede ai dati di rete.

Tale astrazione può essere molto astratta:

public loadProducts(currentCategory) returns list of Product {
    var productsFactory = dataAccess.factory.createProductsFactory();
    var productsOfCategory = productsFactory.loadProducts(currentCategory);
    return productsOfCategory;
}

Qui il chiamante non sa se i prodotti vengono caricati da un database, un file XML, una richiesta REST o qualcosa di completamente diverso. Rende molto facile la sostituzione di un'origine dati con un'altra, ad esempio la migrazione di tutti i dati da un servizio REST a un database.

O l'astrazione può essere più trasparente:

public doPostRequest(parameters) returns Stream {
    ... // Use library A to do the request. if you need to switch to library B later, this
        // is not an issue.
}

Qui, il chiamante sa che la libreria sta usando una risorsa di rete. Pur essendo trasparente, tale libreria può ancora essere utile durante la migrazione da un modo per fare richieste HTTP a un altro.

In .NET Framework, ad esempio, ci sono almeno tre modi per fare richieste HTTP, senza contare tutte le librerie di terze parti che si possono usare. Scegliere una direzione e attenersi ad essa è una soluzione, ma in seguito la migrazione a un'altra implementazione sarebbe dolorosa. Un'altra soluzione è quella di creare il proprio livello, astrarre l'effettiva implementazione: se verrà rilasciata una nuova versione di .NET Framework e si desidera utilizzare un nuovo modo di eseguire le richieste HTTP, si modificherà il codice in un unico punto.