AFNetworking còn thiếu những tính năng chính nào của ASIHTTPRequest?

Với việc công việc gần đây đã dừng lại trên ASIHTTPRequest , có vẻ như sự chú ý đang chuyển sang AFNetworking .

Tuy nhiên, tôi vẫn chưa tìm thấy so sánh tốt về các tính năng của hai thư viện, vì vậy tôi không biết mình có thể mất gì nếu / khi chuyển sang.

Sự khác biệt chính mà tôi đã phát hiện cho đến nay là:

1. AFNetworking có kích thước mã nhỏ hơn nhiều (tốt)
2. AFNetworking đang được cải thiện nhanh chóng (vì vậy nó có thể chưa hoàn thiện, có thể chưa có API ổn định?)
3. Cả hai dường như đều có bộ nhớ đệm, mặc dù tôi đã thấy gợi ý rằng vì AFNetworking sử dụng NSURLConnection nên nó sẽ không lưu vào bộ nhớ cache các đối tượng trên 50K
4. ASIHTTPRequest hỗ trợ rất tốt cho proxy http thủ công & tự động (PAC); Tôi không thể tìm thấy bất kỳ thông tin nào về mức độ hỗ trợ AFNetworking dành cho proxy
5. AFNetworking yêu cầu iOS 4+, trong khi ASIHTTPRequest hoạt động ngay trở lại iOS 2 (không thực sự là một vấn đề đối với tôi, nhưng nó là một vấn đề đối với một số người)
6. AFNetworking chưa (chưa) có bộ nhớ cache liên tục được tích hợp sẵn, nhưng có một bộ nhớ cache liên tục có yêu cầu kéo đang chờ xử lý: https://github.com/gowalla/AFNetworking/pull/25

Có ai đã thấy bất kỳ so sánh tốt nào về hai thư viện hoặc bất kỳ kinh nghiệm được ghi lại nào về việc chuyển đổi từ thư viện này sang thư viện khác không?

Tôi yêu ASIHTTPRequest và tôi rất buồn khi thấy nó biến mất. Tuy nhiên, nhà phát triển của ASI đã đúng, ASIHTTPRequest đã trở nên quá lớn và cồng kềnh đến mức anh ta không thể dành thời gian để đưa nó ngang hàng với các tính năng mới nhất của iOS và các khung công tác khác. Tôi đã tiếp tục và bây giờ sử dụng AFNetworking.

Điều đó nói rằng, tôi phải nói rằng AFNetworking không ổn định hơn nhiều so với ASIHTTP, và đối với những thứ tôi sử dụng nó, nó cần được cải tiến.

Tôi thường cần thực hiện các yêu cầu HTTP đến 100 nguồn HTTP trước khi hiển thị kết quả của mình trên màn hình và tôi đã đặt AFHTTPNetworkOperation vào hàng đợi hoạt động. Trước khi tất cả kết quả được tải xuống, tôi muốn có thể hủy tất cả các thao tác bên trong hàng đợi thao tác và sau đó loại bỏ bộ điều khiển chế độ xem lưu giữ kết quả.

Điều đó không phải lúc nào cũng hiệu quả.

Tôi gặp sự cố vào những thời điểm ngẫu nhiên với AFNetworking, trong khi với ASIHTTPRequest, các hoạt động này hoạt động hoàn hảo. Tôi ước mình có thể nói phần cụ thể nào của AFNetworking đang gặp sự cố, vì nó liên tục gặp sự cố ở các điểm khác nhau (tuy nhiên, hầu hết những lần này trình gỡ lỗi đều trỏ đến NSRunLoop tạo đối tượng NSURLConnection). Vì vậy, AFNetworking cần phải trưởng thành để được coi là hoàn chỉnh như ASIHTTPRequest.

Ngoài ra, ASIHTTPRequests hỗ trợ xác thực máy khách, điều mà AFNetworking thiếu tại thời điểm này. Cách duy nhất để triển khai nó là phân lớp AFHTTPRequestOperation và ghi đè các phương thức xác thực của NSURLConnection. Tuy nhiên, nếu bạn bắt đầu tham gia với NSURLConnection, bạn sẽ nhận thấy rằng việc đặt NSURLConnection bên trong trình bao bọc NSOperation và viết các khối hoàn thành không quá khó và bạn sẽ bắt đầu nghĩ rằng điều gì ngăn bạn đổ các thư viện của bên thứ ba.

ASI sử dụng một cách tiếp cận hoàn toàn khác, vì nó sử dụng CFNetworking (các khung nền tảng cấp thấp hơn dựa trên C) để có thể tải xuống và tải tệp lên, bỏ qua hoàn toàn NSURLConnection và chạm đến các khái niệm mà hầu hết các nhà phát triển OS X và iOS của chúng ta đều quá sợ hãi. Do đó, bạn tải lên và tải xuống tệp tốt hơn, thậm chí cả bộ đệm của trang web.

Tôi thích cái nào hơn? Khó mà nói ra được. Nếu AFNetworking đủ trưởng thành, tôi sẽ thích nó hơn ASI. Cho đến lúc đó, tôi không thể không ngưỡng mộ ASI, và cách nó trở thành một trong những framework được sử dụng nhiều nhất mọi thời đại cho OS X và iOS.

CHỈNH SỬA: Tôi nghĩ đã đến lúc cập nhật câu trả lời này, vì mọi thứ đã thay đổi một chút sau bài đăng này.

Bài đăng này đã được viết một thời gian trước, và AFNetworking đã đủ trưởng thành. Cách đây 1-2 tháng AF đã đăng một bản cập nhật nhỏ cho các hoạt động POST, đó là khiếu nại cuối cùng của tôi về khung này (một lỗi nhỏ ở cuối dòng là lý do khiến tải lên không thành công với AF nhưng hoàn toàn tốt với ASI). Xác thực không phải là vấn đề với AFnetworking, vì đối với các phương pháp xác thực phức tạp, bạn có thể phân lớp hoạt động và thực hiện các cuộc gọi của riêng mình và AFHTTPClient biến xác thực cơ bản trở thành một miếng bánh. Bằng cách phân loại phụ AFHTTPClient, bạn có thể làm cho toàn bộ người tiêu dùng dịch vụ trong thời gian ngắn.

Chưa kể đến các bổ sung UIImage hoàn toàn cần thiết mà AFNetworking cung cấp. Với các khối và khối hoàn thành tùy chỉnh và một số thuật toán thông minh, bạn có thể tạo chế độ xem bảng với tải xuống hình ảnh không đồng bộ và điền vào ô khá dễ dàng, trong khi trong ASI, bạn phải thực hiện các hàng đợi hoạt động để điều chỉnh băng thông và hãy tự hủy và tiếp tục hàng đợi hoạt động theo khả năng hiển thị xem bảng và những thứ tương tự. Thời gian phát triển của các hoạt động như vậy đã được giảm một nửa.

Tôi cũng yêu thích các khối thành công và thất bại. ASI chỉ có một khối hoàn thành (thực chất là khối hoàn thành của NSOperation). Bạn phải kiểm tra xem bạn có gặp lỗi khi hoàn thành hay không và hành động theo đó. Đối với các dịch vụ web phức tạp, bạn có thể bị lạc trong tất cả các "ifs" và "elses"; Trong AFNetworking, mọi thứ đơn giản và trực quan hơn nhiều.

ASI đã rất tuyệt vời vào thời điểm đó, nhưng với AF, bạn có thể thay đổi cách xử lý các dịch vụ web hoàn toàn theo hướng tốt và làm cho các ứng dụng có thể mở rộng dễ dàng hơn. Tôi thực sự tin rằng không có lý do gì để gắn bó với ASI nữa, trừ khi bạn muốn nhắm mục tiêu iOS 3 trở xuống.

Vừa hoàn thành một dự án mà tôi đang sử dụng AFNetworking thay vì ASI. Đã sử dụng ASI trên các dự án trước đây; nó đã được giúp đỡ rất nhiều trong quá khứ.

Dưới đây là những gì AFNetworking còn thiếu (tính đến ngày hôm nay) mà bạn nên biết:

• Không có gì

ASI sắp biến mất . Sử dụng AF ngay bây giờ. Nó nhỏ, nó hoạt động và nó sẽ tiếp tục được hỗ trợ. Nó cũng được tổ chức hợp lý hơn, đặc biệt là cho các ứng dụng khách API. Nó có một số lớp tuyệt vời cho các trường hợp đặc biệt thường được sử dụng như tải hình ảnh không đồng bộ trong chế độ xem bảng.

AFNetworking không hỗ trợ clientCertificateIdentity và clientCertificates để xác thực ứng dụng TLS.

Chúng ta có thể làm điều đó với - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengephương thức trong lớp con của AFURLConnectionOperation nhưng nó không dễ dàng như vậy.

Tôi đã sử dụng ASI * được một thời gian và tôi thực sự thích cách tiếp cận tải tệp lên của ASI và mặc dù tôi rất vui khi chuyển sang AFNetworking, hỗ trợ tải tệp trong AfNetworking không dễ sử dụng so với ASI *.

Cho đến bây giờ, tôi không thể tìm ra cách đặt thời gian chờ với AFNetworking khi thực hiện một yêu cầu POST đồng bộ . CẬP NHẬT: Cuối cùng tôi đã tìm ra: https://stackoverflow.com/a/8774125/601466
Bây giờ chuyển sang AFNetworking:]

==================

Apple ghi đè thời gian chờ cho một BÀI ĐĂNG, đặt nó thành 240 giây (trong trường hợp nó được đặt ngắn hơn 240 giây) và bạn không thể thay đổi nó. Với ASIHTTP, bạn chỉ cần đặt thời gian chờ và nó hoạt động.

Một ví dụ mã với yêu cầu ĐĂNG đồng bộ:

NSDictionary *params = [NSDictionary dictionaryWithObjectsAndKeys:
                                @"doSomething", @"task",
                                @"foo", @"bar",
                                nil];

AFHTTPClient *httpClient = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:baseURL]];

NSMutableURLRequest *request = [httpClient requestWithMethod:@"POST" path:requestURL parameters:params];
[httpClient release];

AFHTTPRequestOperation *operation = [[[AFHTTPRequestOperation alloc] initWithRequest:request] autorelease];
[operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {}
failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    NDLog(@"fail! %@", [error localizedDescription]);
}];

NSOperationQueue *queue = [[[NSOperationQueue alloc] init] autorelease];
[[AFNetworkActivityIndicatorManager sharedManager] incrementActivityCount];

[queue addOperation:operation];
[queue waitUntilAllOperationsAreFinished]; // Stuck here for at least 240 seconds!

[[AFNetworkActivityIndicatorManager sharedManager] decrementActivityCount];
if (![[operation responseString] isEqualToString:@""]) {
    return [operation responseString];
}

return nil;

Tôi đã cố gắng đặt thời gian chờ ở đây, nhưng không có kết quả. Sự cố này khiến tôi không thể di chuyển sang AFNetworking.

Xem thêm tại đây: Cách đặt thời gian chờ với AFNetworking

AFNetwork thiếu khả năng tải lên các tệp lớn. Nó giả định nội dung tệp nằm trong RAM. ASI đủ thông minh để đơn giản truyền nội dung tệp từ đĩa.

Trong ASIHTTP, tôi thích rằng tôi có thể đính kèm từ điển userinfo vào các yêu cầu riêng lẻ. Theo như tôi thấy không có hỗ trợ trực tiếp cho điều này trong AFHTTPRequestOperation. Có ai nghĩ ra một cách giải quyết thanh lịch chưa? Tất nhiên là ngoại trừ phân lớp tầm thường.

AFNetworking hoạt động với "khối" đối với tôi tự nhiên hơn là làm việc với các đại biểu như ASIHTTPRequest.

Làm việc với các khối giống như làm việc với Hàm ẩn danh trong javascript.