AFNetworking 2.0
AFNetworking is one of the most widely used open source projects for iOS and OS X development. It powers thousands of popular and critically acclaimed apps, and serves as the foundation for dozens of other great open source libraries and frameworks. With thousands of stars and forks, and hundreds of contributors, the project is also among the most active and influential in the community.
By all accounts, AFNetworking is about as mainstream as it gets.
But have you heard about the sequel? AFNetworking 2.0.
This week on NSHipster: an exclusive look at the future of AFNetworking.
Full Disclosure: NSHipster is written by the author of AFNetworking, so this is anything but an objective account of AFNetworking or its merits. What you’re getting is the personal, honest take of AFNetworking in its current and forthcoming releases.
AFNetworking’s Big Ideas
Started in May 2011 as a humble extension of an Apple code sample from a doomed location-based social network, AFNetworking’s success was a product of timing more than anything. At a time when ASIHTTPRequest was the de facto networking solution, AFNetworking’s core ideas caught on among developers looking for a more modern solution.
NSURLConnection + NSOperation
NSURLConnection is the backbone of the Foundation URL Loading system. An NSURLConnection loads an NSURLRequest object asynchronously, calling methods on its delegates as the NSURLResponse / NSHTTPURLResponse and its associated NSData is sent to and loaded from the server; the delegate may also implement behavior for handling an NSURLAuthentication, a redirect responses, or determine how the associated NSCached is stored to the shared NSURLCache.
NSOperation is an abstract class that models a single unit of computation, with useful constructs like state, priority, dependencies, and cancellation.
The first major breakthrough of AFNetworking was combining the two. AFURLConnection, an NSOperation subclass conforms to NSURLConnection methods, and tracks the state of the request from start to finish, while storing intermediary state, such as request, response, and response data.
Blocks
iOS 4 radically improved the process of developing apps with its introduction of blocks and Grand Central Dispatch. Instead of scattering implementation logic across your application with delegates, developers could localize related functionality in block properties. Rather than struggle with a miasma of threads, invocations, and operation queues, GCD could dispatch work back and forth with ease.
What’s more, NSURLConnection methods could be customized for each request operation by setting a corresponding block property (e.g. set to override the default implementation of connection:will)
Now, an AFURLConnection could be created and scheduled on an NSOperation, with behavior specified on what to do with the response and response data (or any error encountered during the request lifecyle) when finished by setting the new completion property on NSOperation.
Serialization & Validation
Going even further, request operations could have their responsibilities extended to validate HTTP status codes and content type to validate the server response, and, for instance, serialize NSData into JSON objects for responses with an application/json MIME type.
Loading JSON, XML, property lists, or images from the server was abstracted to more closely resemble a latent file loading operation, such that a developer could think in terms of promises rather than asynchronous networking.
Introducing AFNetworking 2.0
In many ways, AFNetworking succeeded in striking a balance between ease-of-use and extensibility. That’s not to say that there wasn’t room for improvement.
With its second major release, AFNetworking aims to reconcile many of the quirks of the original design, while adding powerful new constructs to power the next generation of iOS and OS X apps.
Motivations
-
NSURLSession Compatibility -
NSURLSessionis a replacement forNSURLConnectionintroduced in iOS 7.NSURLConnectionisn’t deprecated, and likely won’t be for some time, butNSURLSessionis the future of networking in Foundation, and it’s a bright future at that, addressing many of the shortcomings of its predecessor. (See WWDC 2013 Session 705 “What’s New in Foundation Networking” for a good overview). Some had initially speculated thatNSURLSessionwould obviate the need for AFNetworking; although there is overlap, there is still much that a higher-level abstraction can provide. AFNetworking 2.0 does just this, embracing and extendingNSURLSessionto pave over some of the rough spots, and maximize its usefulness. -
Modularity - One of the major criticisms of AFNetworking is how bulky it is. Although its architecture lent itself well to modularity on a class level, its packaging didn’t allow for individual features to be selected à la carte. Over time,
AFHTTPClientin particular became overburdened in its responsibilities (creating requests, serializing query string parameters, determining response parsing behavior, creating and managing operations, monitoring network reachability). In AFNetworking 2.0, you can pick and choose only the components you need using CocoaPods subspecs.
Meet the Cast
NSURLConnection Components (iOS 6 & 7)
-
AFURLConnection- A subclass ofOperation NSOperationthat manages anNSURLConnectionand implements its delegate methods. -
AFHTTPRequest- A subclass ofOperation AFURLConnectionspecifically for making HTTP requests, which creates a distinction between acceptable and unacceptable status codes and content types. The main difference in 2.0 is that you’ll actually use this class directly, rather than subclass it, for reasons explained in the “Serialization” section.Operation -
AFHTTPRequest- A class that encapsulates the common patterns of communicating with a web service over HTTP, backed byOperation Manager NSURLConnectionby way ofAFHTTPRequest.Operation
NSURLSession Components (iOS 7)
-
AFURLSession- A class that creates and manages anManager NSURLSessionobject based on a specifiedNSURLSessionobject, as well as data, download, and upload tasks for that session, implementing the delegate methods for both the session and its associated tasks. Because of the odd gaps inConfiguration NSURLSession’s API design, any code working withNSURLSessionwould be improved byAFURLSession.Manager -
AFHTTPSession- A subclass ofManager AFURLSessionthat encapsulates the common patterns of communicating with an web service over HTTP, backed byManager NSURLSessionby way ofAFURLSession.Manager
So to recap: in order to support the new
NSURLSessionAPIs as well as the old-but-not-deprecated-and-still-usefulNSURLConnection, the core components of AFNetworking 2.0 are split between request operation and session tasks.AFHTTPRequestandOperation Manager AFHTTPSessionprovide similar functionality, with nearly interchangeable interfaces that can be swapped out rather easily, should the need arise (such as porting between iOS 6 and 7).Manager
All of the other functionality previous tied up in
AFHTTPClient, such as serialization, security, and reachability, has been split out across several modules that are shared betweenNSURLSessionandNSURLConnection-backed APIs.
Serialization
One of the breakthroughs of AFNetworking 2.0’s new architecture is use of serializers for creating requests and parsing responses. The flexible design of serializers allows for more business logic to be transferred over to the networking layer, and for previously built-in default behavior to be easily customized.
-
<AFURLRequest- Objects conforming to this protocol are used to decorate requests by translating parameters into either a query string or entity body representation, as well as setting any necessary headers. Anyone who had beef about the waySerializer> AFHTTPClientencoded query string parameters should find this new approach to be more to your liking. -
<AFURLResponse- Objects conforming to this protocol are responsible for validating and serializing a response and its associated data into useful representations, such as JSON objects, images, or even Mantle-backed model objects. Rather than endlessly subclassingSerializer> AFHTTPClient,AFHTTPRequestnow has a singleOperation responseproperty, which is set to the appropriate handler. Likewise, theSerializer NSURLProtocol-inspired request operation class registration nonsense is no more—replaced by that single delightfulresponseproperty. Thank goodness.Serializer
Security
Thanks to the contributions of Dustin Barker, Oliver Letterer, and Kevin Harwood and others, AFNetworking comes with built-in support for SSL pinning, which is critical for apps that deal with sensitive information.
-
AFSecurity- A class that evaluates the server trust of secure connections against its specified pinned certificates or public keys. tl;dr Add your server certificate to your app bundle to help prevent against man-in-the-middle attacks.Policy
Reachability
Another piece of functionality now decoupled from AFHTTPClient is network reachability. Now you can use it on its own, or as a property on AFHTTPRequest / AFHTTPSession.
-
AFNetwork- This class monitors current network reachability, providing callback blocks and notifications for when reachability changes.Reachability Manager
Real-time
-
AFEvent- An Objective-C implementation of theSource EventDOM API. A persistent HTTP connection is opened to a host, which streams events to the event source, to be dispatched to listeners. Messages streamed to the event source formatted as JSON Patch documents are translated into arrays ofSource AFJSONPatchobjects. These patch operations can be applied to the persistent data set fetched from the server.Operation
NSURL *URL = [NSURL URLWith String:@"http://example.com"];
AFHTTPSession Manager *manager = [[AFHTTPSession Manager alloc] init With Base URL:URL];
[manager GET:@"/resources" parameters:nil success:^(NSURLSession Data Task *task, id response Object) {
[resources add Objects From Array:response Object[@"resources"]];
[manager SUBSCRIBE:@"/resources" using Block:^(NSArray *operations, NSError *error) {
for (AFJSONPatch Operation *operation in operations) {
switch (operation.type) {
case AFJSONAdd Operation Type:
[resources add Object:operation.value];
break;
default:
break;
}
}
} error:nil];
} failure:nil];
UIKit Extensions
All of the UIKit categories in AFNetworking 2.0 have been extracted and expanded, with several new additions to the list.
-
AFNetwork: Automatically start and stop the network activity indicator in the status bar as request operations and tasks begin and finish loading.Activity Indicator Manager -
UIImage: AddsView+AFNetworking imageproperty, which makes it easy to automatically resize or apply a filter to images loaded remotely to an image view. For example,Response Serializer AFCorecould be used to apply Core Image filters to the response image before being displayed.Image Serializer -
UIButton+AFNetworking(New): Similar toUIImage, loadsView+AFNetworking imageandbackgroundfrom remote source.Image -
UIActivity(New): Automatically start and stop aIndicator View+AFNetworking UIActivityaccording to the state of a specified request operation or session task.Indicator View -
UIProgress(New): Automatically track the upload or download progress of a specified request operation or session task.View+AFNetworking -
UIWeb(New): Provides a more sophisticated API for loading URL requests, with support for progress callbacks and content transformation.View+AFNetworking
Thus concludes our whirlwind tour of AFNetworking 2.0. New features for the next generation of apps, combined with a fresh new architecture for all of the existing functionality. There’s a lot to be excited about.
Hit the Ground Running
You can start playing around with AFNetworking 2.0 by putting the following in your Podfile:
platform :ios, '7.0'
pod "AFNetworking", "2.5.0"
For anyone coming over to AFNetworking from the current 1.x release, you may find the AFNetworking 2.0 Migration Guide especially useful.