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.
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.
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.
What about supporting using something like PromiseKit for error handling and interoperability with aggregation methods? Would you be willing to consider that?
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`.
In the README it looks like using the ObjC AFNetworking is suggested if one wishes to do multipart http requests, I assume this is up to date and Alamofire doesn't support this at this time?
> ...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`.
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.
AFNetworking seems to still have too much in the way for my taste, but maybe i'm missing something. Couple of questions:
If i want to generate url requests, i have to use a serializer class. For me, it seems like overkill to have a stateful serializer. Are there a lot of cases where people change the state of the serializer once created? If not, then wouldn't it be better to just expose all the setup functionality through simple wrapper functions instead of wrapper classes, and let people layer these as they see fit (possibly with server-specific categories)?
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? My impression is that it feels like a lot of chatter for multipart setup. It seems like something that could just be encapsulated as one output from a set of inputs (function). In practice, i've found this approach works better for me.
> 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.
> No, you don't. There's nothing stopping you from creating `NSURLRequest` directly.
There is a lot of basic http setup missing from NSMutableURLRequest that needs to live somewhere.
> 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.
Except NSURLSessionConfiguration is more of a data type, right? By that I mean it is just a blob of parameters that can be inspected. The serializer is not just a configuration, it's something with an 'er' on the end. Plus, many of its properties are direct duplications of NSMutableURLRequest that could just be set after the fact in a wrapper function. AFJSONRequestSerializer and others suggest i follow a pattern of subclass inheritance to provide further customization when everything is just permutations on values of a core set of parameters.
> 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...
I don't understand this argument. What's wrong with creating the simple data types for the cases you need to cover? What is the importance of the top level class count metric? Would a fourth top level data type for the raw data case suffice? Can't throttling go in a parameter of the outer configuration data type?
> You should give all of that another look—it's one of the best parts of AFNetworking.
Maybe. When i look at it i see class hierarchies, singletons, and protocols with contractual state manipulation for a case that seems to (maybe it doesn't?) reduce to an output (NSMutableURLRequest) that's a straight function of a bunch of inputs.
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.
