in iOS development, I have often seen people creating a networking module to interact with their APIs.
This module generally sits on top of a networking framework like MKNetWorkKit or AFNetWorking.
In most of the cases, It’s all about sending GET,POST request and parsing the response which is in most cases JSON.
What extra practical benefits that these libraries provide that an iOS developer should be leveraging which the plain Cocoa Networking APIs lack ?
I can understand RESTKit as one exception where it takes care of the conversion of JSON to native objects and also interfaces with Core Data but what about others ?
What extra practical benefits that these libraries provide that an iOS
developer should be leveraging which the plain Cocoa Networking APIs
lack ?
Error handling, ease of use, simplified code, etc. NSURLConnection is a great class and very flexible, but if you take a look at NSURLConnectionDelegate you’ll see that there are quite a few different network states that have to be handled. A good networking library takes care of much of that routine work.
3
One of the goals may be to abstract the way the network data is accessed.
Such abstraction can be very abstract:
public loadProducts(currentCategory) returns list of Product {
var productsFactory = dataAccess.factory.createProductsFactory();
var productsOfCategory = productsFactory.loadProducts(currentCategory);
return productsOfCategory;
}
Here, the caller don’t know if products are loaded from a database, an XML file, a REST request or something completely different. It makes it very easy to replace one data source by another, for example migrate all data from a REST service to a database.
Or the abstraction may be more transparent:
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.
}
Here, the caller knows that the library is using a network resource. While being transparent, such library can still be useful when migrating from one way to do HTTP requests to another.
In .NET Framework, for example, there are at least three ways to do HTTP requests, not counting all the third party libraries one can use. Picking one way and sticking with it is a solution, but later, migrating to another implementation would be painful. Another solution is to create your own layer, abstracting the actual implementation: if a new version of .NET Framework will be released and you want to use a new way of doing HTTP requests, you change the code in one place.