matttthompson

And to be clear—these are all existing sample apps for open source Objective-C projects. The creator of this site does not appear to have done anything but gathered these up into zip files. The complete lack of attribution is misleading.

I don't understand why this is getting so much attention. This is nothing more than a couple zip files containing a few Objective-C open source projects that happen to have example projects.

As far as I can tell, the only original contributions here are that the author tested the apps (in an old version of Xcode) and wrote vague descriptions of what those projects did.

As @orta mentions in another comment, http://cocoapods.org already has a canonical database of thousands of projects. And there are plenty of other sites that do a much better job of curating (and properly attributing) interesting projects.

Edit: Link to original HN submission (2012), for anyone curious - https://news.ycombinator.com/item?id=4182483

I have no illusions about the amount of effort and investment necessary to change technology stacks. Carbon was only officially deprecated in OS X 10.8. To speak of the death of technology is only to acknowledge that it is mortal.

My claim isn't that everything will be rewritten in Swift—far from it. Instead, the article is an exploration of what it would mean for Swift to evolve beyond the constraints of Objective-C & Cocoa interoperability, and how that may occur as Swift gains momentum.

I appreciate your feedback, but I think you're reading an entirely different argument than what is presented in the article. It's not that everything is going to be rewritten in Swift (I'm not sure where you got that idea). Rather, the article is an exploration of what Swift without Obj-C & Cocoa could be, and under what circumstances that might become a reality.

If Swift doesn't have to accommodate Objective-C as it currently does, it's reasonable to assume that system frameworks will be designed and built in ways that make the most of Swift's language features, just as Cocoa currently does with Objective-C.

I don't really see much need for it. Others are welcome to create such an integration, but I probably won't do so myself.

You make some good points, and I agree to caution against names that bear no semantic relationship with their purpose. My justification of Alamofire is that it reflects the history of the project, which traces back from AFNetworking to Gowalla (formerly Alamofire, Inc.), the product for which it was originally developed.

> Was there any reason why you chose callbacks over a Promise-like pattern for the async responses?

Deeply-nested networking callbacks are a code smell, and I find that promises often do more harm by hiding those smells—or worse, obscuring the flow itself. In practice, Alamofire is mostly going to be single or at most nested two levels deep anyway.

Yes, that's correct.

The short answer: Use the version of `request` that takes a `URLRequestConvertible`, and specify the header fields in that.

The long answer: Custom headers on a per-request basis are a bit of a red herring, from an API design perspective. In reality, most use cases boil down to one of three, which are taken care of in other ways:

- Default headers, such as `User-Agent`, are specified in `NSURLSessionConfiguration -HTTPAdditionalHeaders`. - `Authorization` headers, which are handled by `NSURLCredential` and `NSURLAuthenticationChallenge`. - `Content-Type` headers, which are handled by `ParameterEncoding`.

This is why Alamofire is designed the way it is.

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Author of the article here. Let me know if you have any questions or feedback.

> ...ending up in an error block because of a malformed server response is a pain in the ass. Is it really an error if you get a 200 OK response but the body isn't valid JSON?

Yes. Oh goodness, yes it is. Having consistent validation on the networking level means not having sporadic logic scattered throughout models and view controllers.

Your server sent invalid JSON (e.g. sending HTML instead)? AFNetworking just saved you from a crash, or some other undefined, dangerous behavior.

AFNetworking is pedantic because networking is such a wildcard, in terms of performance, consistency, and security.

Nothing in AFNetworking forces a success/failure block. For request operations, `completionBlock` can be set directly. For session tasks, the parameter is a `completionHandler`.

There's plenty of room for simplicity and abstraction, but this is not a particularly good one, if I'm going to be honest. I can't think of any situation in which I'd recommend this over either AFNetworking or the built-in Foundation URL Loading system.

> If i want to generate url requests, i have to use a serializer class...

No, you don't. There's nothing stopping you from creating `NSURLRequest` directly.

> ...wouldn't it be better to just expose all the setup functionality through simple wrapper functions?

Request serializers are not unlike any other class in Cocoa, like say NSURLSessionConfiguration, which is not often mutated beyond initial setup, but exposes properties to remain flexible and not overwhelm the user with init parameters.

What you're suggesting sounds much, much worse.

> For multipart requests, why did a protocol with appends and requiring a block with stateful appends end up making more sense than just taking an array of the parts?

Not using a protocol / builder pattern here would be awful.

You'd have to create classes for each kind of part, which gets complicated because AFNetworking handles data, files, and streams alike. So that's, like, 3 extra top-level classes. And even that doesn't really work, since it makes it really difficult to just append data to the multipart body manually, in case there was some missing functionality that AFN didn't provide. Add to that the consideration of how to specify options on the stream itself, like throttling...

You should give all of that another look—it's one of the best parts of AFNetworking.

I'm all about seeing new ideas about how to approach networking architectures, but this one makes me worried for anyone who decides to adopt it.

Networking is an inherently complex problem. Attempting to simplify the problem by ignoring those complexities, rather than actually deal with them, misses the point entirely.

This library in particular demonstrates an unfortunate lack of understanding of why Apple has designed its networking stack the way it has. As a result, it needlessly duplicates interfaces and functionality of built-in classes.

Not exposing NSURLRequest means that there's no support for caching policies, or HTTP pipelining, or setting an HTTP body stream, or control over cellular access. Not using NSURLCredential or exposing authentication challenges means that you lose support for digest auth, NTLM, and kerberos, and leaves the user vulnerable to Man-in-the-Middle attacks for lack of certificate pinning and verification. Not exposing other delegate methods means no backgrounding support, no cache control, and no extensibility beyond what the original author envisioned.

AFNetworking is modular and composable. If you don't want to deal with its complexity, you can ignore a lot of it. If you don't need much, just use the built in NSURLConnection or NSURLSession classes (they're actually quite nice). But seriously, don't settle for a wrapper library that dumbs down a problem; you'll regret it soon enough.

In my opinion, no better case for AFNetworking 2.0 wrt/NSURLSession can be made than AFURLSessionManager, and all of the great stuff it does for you. http://cocoadocs.org/docsets/AFNetworking/2.0.0/Classes/AFUR...

Another essential feature is SSL pinning, which helps prevent against man-in-the-middle attacks and other vulnerabilities. If your app interacts with any sensitive customer information, you would be well-advised to take a look at AFSecurityPolicy: http://cocoadocs.org/docsets/AFNetworking/2.0.0/Classes/AFSe...

If you're using UIKit, there's a good chance that at least one of the many UIKit extensions would be worth your while: https://github.com/AFNetworking/AFNetworking/tree/master/UIK...

I also think serializers will have a dramatic impact on the reusability and composability of business logic across your application in a really elegant way.

I'd be very interested to hear your thoughts as you do networking on iOS 7 with and without AFNetworking. Feel free to reach out over Twitter or email.

Yes, AFNetworking 2.0 (with the exception of `NSURLSession` functionality) is compatible with iOS 6 and Mac OS X 10.8.

(This was changed from the original plan to only target iOS 7, after it was determined that A) only the two classes needed iOS 7, and B) although iOS 7 adoption is crazy good, the same isn't as true of OS X)