what is the advantage of using Alamofire over NSUR

Question

Can anyone help me in understanding these question : What is the advantage of using Alamofire over NSURLSession/ NSURLConnection?

What are the differences between NSURLSession and NSURLConnection?

Answer 1

For Swift 3.0 and above, Alamofire is best because it is well Optimized and also reusable and it has also many Build in features.Alamofire calls for a similar approach in that one creates a router by conforming to a protocol, URLRequestConvertible. Under the hood, Alamofire calls for a singleton pattern that’s built on top of an NSURLSessionConfiguration.

Answer 2

The advantage is that there is a higher level of abstraction, so you can write less lines of code. However, there is still no official support for Codable. Updating Swift version can come with its downsides, but I think this should improve with ABI stability in Swift 5. Also, you have got to be mindful of security vulnerabilities.

Back in the Objective C and NSURLConnection days then libraries like AFNetworking made a lot of sense, but with Swift, Codable, and URLSession, then I think there is less of a case to be made for using Alamofire.

Answer 3

NSURLConnection is Apple's old API for doing networking (e.g. making HTTP requests and receiving responces), while NSURLSession is their new one. The latter one is higher level and is generally much easier and involves less boilerplate code to use for most application developers - there's basically no reason to use the former except in legacy code that you don't want to update.

A bit of history: Before NSURLSession came out, a third party library, AFNetworking, became the de facto standard for doing networking in Objective C, as it provided an easier and more convenient API than NSURLConnection (which it was a wrapper around - I think these days it wraps NSURLSession instead). The same developer later made a similar library for Swift, called AlamoFire in order to fully take advantage of "the Swift way of doing things" (instead of just adding Swift bindings to AFNetworking). Around the same time NSURLSession came out and it seemed pretty obvious that Apple had been inspired by AFNetworking and wanted to make their new networking API just as convenient to work with - by and large I think they succeded. What this means is that while previously, using AFNetworking instead of NSURLConnection was the only sane choice for most developers, today the advantages of using AFNetworking or AlamoFire over NSURLSession are much smaller, and for most developers starting up new projects I'd recommend to just start by using NSURLSession and only look into AlamoFire if they feel that they run into some limitation or inconvenience that is big enough to justify adding another dependency.

Answer 4

Alamofire is built on top of NSURLSession, and is less lines of code to do REST interactions with (POST/GET/PUT/etc). It will get you "90%" of the way, but if you need to do super specialized network calls, you will need to use NSURLSession.

Ex: Simple Alamofire call that gets JSON

Alamofire.request(.GET, "https://www.google.com/",encoding: .JSON).responseJSON {response in
        if(response.result.error == nil){
            print(response.data)
        }else{
            print("Network Error")
        }
}

NSURLConnection is now deprecated, and NSURLSession is the new standard. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/UsingNSURLSession.html

Answer 5

First let me answer the difference between NSURLSession and NSURLConnection

1. NSURLConnection : if we have an open connection with NSURLConnection and let's say you close your app, then everything we received or sent is lost

2. NSURLSession: Here this case is handled with the help of a app delegate method

   application:handleEventsForBackgroundURLSession:completionHandler

Here's a link i found which might be useful in explaining the difference better between the two

let's go to your initial question of advantage of Alamofire over the default framework class, and am just sharing my experience on what I did so far so get ready as it's a long read.

For me the thumb rule is never bypass the framework unless you have a strong reason for doing so irrespective of what technology you are using.

Reason behind that is I have used third party library in the past and that did not end well with the latest updates of iOS and let's say if you have a paid app and your third party library stops working then your client's app will loose it's value and will end up having negative comments on the app store.

I advice before using any third party library please make sure you make a check of the given questions

1. what's the frequency of updates?
2. how many open bugs are open?
3. Is it really worth using it or you can leverage the framework classes?
4. What's the license of this library?

Coming back to the question, I used Alamofire in one project which was just making get, post and put calls had some offline sync features.

Now thinking about it i could have made my own class with URLSessions and handled response accordingly there was no need to use Alamofire as i was not doing anything special here.

I believe this was all achievable by the default framework than using a third party but i used it anyway. Why did i use it don't know maybe i was curious but a lesson learned here was i could have achieved the same thing by using framework classes, if let's say the library stops working I would have no clue as to why it did and would have to rely on a fix from the care-taker/author of that library which may take a month, week, day who knows

Once i used a library for a feature i wanted but that same feature had an open defect for it and it was never updated so i ended up making my own custom one and till today it's working fine so do go through all the open defects section to avoid unplanned surprises.

Also as mentioned in the above answer use third party components only and only when you run into limitations with the default framework and even before you do please do check when was the last time this library was updated, what license it has and how many open defects are there.