#afnetworking

とある iOS アプリから Web API と HTTP を喋るのに AFNetworking（2系）を利用しています。

AFNetworking というよりかは NSURLRequest の仕様だと思うのですが、下記のようなコードで、一度 HTTP リクエストを送った URL に対して 2 回目のリクエストを送るとクライアント側のキャッシュからデータ（レスポンス）を読むようです。 （サーバー側のレスポンスヘッダーが悪いような感じではなかった、、、） このような場合、特に Web API などはクライアント依存になってしまう状態だと何かと不便です。

下記コードが問題のところ。 いたって普通の HTTP 通信するためのコードです。

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; [manager GET: URL parameters: PARAMS success: ^(AFHTTPRequestOperation *operation, id responseObject) { // anything } failure: ^(AFHTTPRequestOperation *operation, NSError *error) { // anything } ];

どうにか解消できないかと調べていると、HTTP リクエストを送る際にキャッシュポリシーのオプションを指定できることがわかりました。 （公式ドキュメント - NSURLRequestCachePolicy - Foundation | Apple Developer Documentation）

キャッシュポリシーは列挙型 NSURLRequestCachePolicy で、デフォルトが HTTP に従うようです。

下記コードが改善版。 [manager.requestSerializer setCachePolicy: NSURLRequestReloadIgnoringLocalCacheData] が改善箇所です。

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; [manager.requestSerializer setCachePolicy: NSURLRequestReloadIgnoringLocalCacheData] [manager GET: URL parameters: PARAMS success: ^(AFHTTPRequestOperation *operation, id responseObject) { // anything } failure: ^(AFHTTPRequestOperation *operation, NSError *error) { // anything } ];

なるほどなるほど。

他にどんなキャッシュポリシーがあるか調べました。

NSURLRequestCachePolicy (Objective-C) の種類

値 説明 NSURLRequestUseProtocolCachePolicy 基本的にはプロトコルのキャッシュ方針に従う。でも何故かキャッシュされっ放しのケースがある。プロパティに何も指定がなかった場合にデフォルトで設定される。 NSURLRequestReloadIgnoringLocalCacheData 必ずサーバー側にリクエストを送る。サーバー側のキャッシュコントロールには従う。 NSURLRequestReloadIgnoringLocalAndRemoteCacheData クライアント側、サーバー側ともにキャッシュを無視する。ただしサーバー側でプロキシーキャッシュしている場合はその限りではない。 NSURLRequestReturnCacheDataElseLoad クライアント側にキャッシュがあれば必ずキャッシュデータを返す。ちなみに未実装...。 NSURLRequestReloadRevalidatingCacheData サーバー側にキャッシュデータの妥当性を問い合わせた上でキャッシュを使うくさい。ちなみにこれも未実装...orz

いまさら Objective-C ですが、書き方に癖があるだけで、今のところ自然に入り込めている感じ。

参考 URL

Enumeration - NSURLRequestCachePolicy

ios - AFNetworking - do not cache response - Stack Overflow

Victor y Oscar discuten cuál es la mejor alternativa para poder hacer networking en iOS/OS X, cuándo usar Alamofire/AFNetworking y cómo cada uno trabaja personalmente con datos de la red en sus proyectos.

Descarga este episodio.

Links:

NSURLSession Class Reference

Advanced NSOperations WWDC 2015

Alamofire

UPDATE

Actually, it didn't work unfortunately. It'S becuase of Xcode version. :(

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

I just had a little bit problem with iOS Development Target & Cocoapods. I leave a note here how to fix it.

What happened and How it happened

I built a small demo project with iOS Development Target 9.0 on Xcode 7. This app has AFNetworking v2.6.0 added via Cocoapods. However, I needed to downgrade its iOS Development Target to 8.4. I just went to the project settings and changed it. Then, I got many yellow warnings like the below:

ld: warning: object file (/path/to/DerivedData/something) was built for newer iOS version (9.0) than being linked (8.4)

The demo app was still able to be built. Why did these warnings appear? My guess was Cocoapods Podfile settings caused this problem. I didn't write any platform settings in Podfile. Cocoapods automatically set some pod settings to iOS 9.0. This settings didn't get changed even by changing iOS Development Target.

How I fixed

I updated Podfile to the following:

source 'https://github.com/CocoaPods/Specs.git' platform :ios, '8.4' pod 'AFNetworking', '2.6.0'

Apple made a radical decision with iOS 9, disabling all unsecured HTTP traffic from iOS apps, as a part of App Transport Security.

AFNetworking 은 iOS (뿐만 아니라 모든 Cocoa framework) 개발자들이 인정하는 최고의 오픈소스 라이브러리다. 네트워크 관련되어서는 Apple 보다 잘만들었다.. 게다가 오픈소스!

이런 AFNetworking에는 숨겨진(이라기보다는 사람들이 잘 모르는) 기능들이 몇가지 있다. 그것들 중, 요즘 애용하고있는것은 Reachability 기능이다.

Reachability의 뜻은 네이버 사전에 검색해보자.

현재, iOS 기기가 인터넷에 연결 되어있는지 (네트워크 사용 가능 상태인지), 만약 그렇다면 와이파이인지 3G인지 친절히 알려준다. (애플에서 만든 Reachablity Library도 있다.)

사용법은 아주 간단하다. 가장 먼저, 아래의 코드를 통해 모니터링을 시작한다.

[[AFNetworkReachabilityManager sharedManager] startMonitoring];

* 자매품 stopMonitoring도 잊지 말자!

자, 이제 Reachability가 모니터링을 시작했다.

현재, iOS 단말의 Reachable 여부는 어떻게 알까? 

AFNetworkReachabilityManager 클래스의 reachable property가 네트워크 사용 가능 여부를 알려준다.

[AFNetworkReachabilityManager sharedManager].isReachable;

AFNetworkReachabilityManager.h 를 들어가보면 해당 property의 상세 정보를 볼 수 있다 우왕!! 설명도 자세히 나와있어!!!.

@property (readonly, nonatomic, assign, getter = isReachable) BOOL reachable;

* 자매품 reachableViaWWAN 과 reachableViaWiFi 도 잊지 말자.

Reachablity 상태가 변하는걸 어떻게 캐치하지?

AFNetworking의 큰 장점 중 하나는 Block을 지원한다는 점인데, 개인적으로 위에서 언급한 Apple의 Reachability를 사용하지 않고, AFNetworkReachabilityManager를 사용하는 가장 큰 이유이다.

[[AFNetworkReachabilityManager sharedManager] setReachabilityStatusChangeBlock:^(AFNetworkReachabilityStatus status) {        if (status == AFNetworkReachabilityStatusNotReachable) {            NSLog(@"Not reachable");        } else if (status == AFNetworkReachabilityStatusReachableViaWiFi) {            NSLog(@"Reachable via WiFi");        } else if (status == AFNetworkReachabilityStatusReachableViaWWAN) {            NSLog(@"Reachable via WWAN");        } else {            NSLog(@"Unknown :(");        }    }];

위의 코드와 같은 형식으로 사용된다. 별도의 Notification이나 Delegate를 사용하여 지저분한 코딩을 할 필요가 없다. Reachability가 바뀔 때마다 해당 블럭이 실행되고, status를 준다.

status는 NSInteger value의 enum이고, AFNetworkReachabilityManager.h 파일에 선언되어있다.

typedef NS_ENUM(NSInteger, AFNetworkReachabilityStatus) {    AFNetworkReachabilityStatusUnknown          = -1,    AFNetworkReachabilityStatusNotReachable     = 0,    AFNetworkReachabilityStatusReachableViaWWAN = 1,    AFNetworkReachabilityStatusReachableViaWiFi = 2, };

끝!맺으며

AFNetworking을 사용하지 않는다면, 위에서 언급한 Apple의 Reachability 혹은 tonymillion이라는 개발자의 Reachability를 사용하자. 아쉽게도 후자의 경우에는 아래와 같은 메시지가 붙어있다. 

"WARNING there have been reports of apps being rejected when Reachability is used in a framework. The only solution to this so far is to rename the class."

참고로 며칠 전, AFNetworking의 Reachability를 사용하는 프로젝트가 앱스토어에 잘 등록되었다.

AFNetworking은 항상 업데이트된다. AFNetworking의 공식 문서에서도 Reachability Manager에 대해 잘 설명하고 있으니, 읽어보도록 하자.

이 포스트는 AFNetworking 2.5.4 버전을 기준으로 작성되었다.

참고 웹페이지

Stack overflow: AFNetworking 2.0 Reachability

Git hub: AFNetworking/AFNetworking

Git hub: tonymillion/Reachability

I recently worked on a OS X app which had to keep in sync with a database running on a remote server, to interact with a hardware device via serial port and to allow the user to edit said database with information coming from the hardware device. Since reinventing the wheel is never a good idea, I decided to use various frameworks for those tasks: ORSSerialPort to handle the serial communication, AFNetworking for the networking, Apple’s own Core Data for the local database and XCTest together with OHHTTPStubs for the testing. The networking part was by far the easiest to develop but also the hardest to test, due to its asynchronicity.

This is basically how XCTest works: you create subclasses of XCTestCase, and then define instance methods with their name starting with “test”. Inside these methods you can check for whatever condition you need to test. Here's a very simple example:

- (void)testReverseString{ NSString *originalString = @"test"; NSString *reversedString = [self.controllerToTest reverseString:originalString]; NSString *expectedReversedString = @"tset"; XCTAssertEqualObjects(expectedReversedString, reversedString); }

XCTAssert allows to easily compare variables and to let tests fail/succeed based on the result, but it is not enough when it comes to testing the networking code. For example, I needed to test a GET request that fetched the user database from the remote server and tried to do so this way:

- (void)testSuccessfulUserFetch { // Perform fetch [self.networkManager fetchUsers]; // Test if the number of users created in the local database is equal to the one in the remote database NSArray *localUserDatabase = [User usersInManagedObjectContext:self.moc]; XCTAssertEqual([localUserDatabase count], 10); }

The test failed even if the GET was performed with success, because the local database was tested right after the network request was started and not after its completion.

Luckily Xcode 6 introduced a new feature in XCTest that allows to test asynchronous code as well: XCTestExpectation. It’s as easy as declaring an expectation and setting a timeout for that expectation. The only other thing that’s needed is of course to check for whatever condition has to be met and to fulfill the expectation if that happens.

The obvious place to check and fulfill my network expectations was inside the success/failure blocks that my network manager used, but since that code was written way before I decided to write tests for it, there was no easy way to do so without refactoring. At first I felt like it was not a very good idea to refactor the network manager just to be able to test it, but I’m glad I did: while the existing code was working fine, refactoring it and being able to test it afterwards helped a lot while further developing it.

This is how I changed on of my NetworkManger.m methods to use optional success/failure blocks:

typedef void(^SuccessBlock)(AFHTTPRequestOperation *operation, id responseObject); typedef void(^FailureBlock)(AFHTTPRequestOperation *operation, NSError *error); // Perform network request for user database - (void)fetchUsersWithSuccess:(SuccessBlock)optionalSuccessBlock withFailure:(FailureBlock)optionalFailureBlock { // Create success block SuccessBlock successBlock = ^(AFHTTPRequestOperation *operation, id responseObject){ // Load users into the database NSArray *usersArray = (NSArray *)responseObject; [User loadUsersFromArray:usersArray inManagedObjectContext:self.managedObjectContext]; // Optional success block, if given if (optionalSuccessBlock) optionalSuccessBlock(operation, responseObject); }; // Create failure block FailureBlock failureBlock = ^(AFHTTPRequestOperation *operation, NSError *error){ // Optional failure block, if given if (optionalFailureBlock) optionalFailureBlock(operation, error); }; // Perform request to server [self.manager GET:self.userSyncURL parameters:nil success:successBlock failure:failureBlock]; }

And here’s what the test method looks like:

AFNetworking : How to know if response is using cache or not ? 304 or 200

I can’t find any answer to my question, may be I miss something…

When I ask for a url, I need to know if the response comes from the cache or from the net.

Is the status code 304 or 200 ? (but AFNetworking always responde 200)

With ASIHTTPRequest I used to check “didUseCachedResponse” from ASIHTTPRequest, this was perfect.

Best Answer

I think I found a solution to determine if response was…

1,500 iOS Apps Vulnerable to HTTPS Bug. Critical Vulnerability Discovered

There are approximately 1,500 iOS apps that are exposed to a vulnerability that could let a hacker bypass HTTPS security and steal passwords, as well as other sensitive data, according to experts.

Do you own an iOS device, such as an iPhone or an iPad?

A bug in the way that 1,500 iOS apps establish secure connections to servers leaves them vulnerable to ‘man-in-the-middle’ attacks. This means…