xcode, nslog 이상한 장애물

Question

아래 코드는 tinyurl 링크를 클릭 할 때 tinyurl 링크의 NSLog 리디렉션 위치를 알려줍니다. 그러나 코드 [[UIApplication sharedApplication] openURL:[request URL]];의 다음 부분을 제거하면 NSLog에서 tinyurl 링크가 아닌 실제 웹 사이트가 제공됩니다. 공유 애플리케이션 코드가 표시되는 동안 NSLog에서 실제 웹 사이트 URL을 가질 수있는 위치를 어떻게 만들 수 있습니까?

- (BOOL)webView:(UIWebView*)webView shouldStartLoadWithRequest:(NSURLRequest*)request navigationType:(UIWebViewNavigationType)navigationType { 
    NSLog(@"Redirect Location: %@",[request.URL absoluteString]); 
    [[UIApplication sharedApplication] openURL:[request URL]]; 
} 

Answer 1

짧은 답변 :

shouldStartLoadWithRequest 당신이 (당신의 코드에서 판단, 당신이 궁극적으로 그것을 여는거야 특히 이후 연결됩니다 어떤 사이트에 파악을위한 훌륭한 메커니즘없는 UIWebViewDelegate 방법을 사용하여 외부 앱이 아니라 UIWebView) 리디렉션이 발생하기 전에 shouldStartLoadWithRequest이 나오기 때문입니다. 하지만 NSURLConnection 및 NSURLConnectionDataDelegate 방법을 사용하면 결국 리디렉션되는 위치를 파악할 수 있습니다.

긴 대답은 : 당신이 YES을 반환 할 경우, shouldStartLoadWithRequest 보면

, 당신은 UIWebView 리디렉션 요청에 따라 드리겠습니다. 고려 shouldStartLoadWithRequest 다음 shouldStartLoadWithRequest에 세 번째 호출은 실제입니다

 
2013-03-12 21:23:31.418 webtest[6959:c07] http://nyti.ms/Yi6EAk 
2013-03-12 21:23:31.511 webtest[6959:c07] http://bit.ly/Yi6EAk?cc=0d7134b272b1004cb954d0400076e9fa 
2013-03-12 21:23:31.560 webtest[6959:c07] http://www.nytimes.com/2013/03/13/us/politics/ryans-plan-aims-to-balance-budget-in-10-years.html?hp&_r=0 

한다 : 당신이 이것을 사용하면 임의의 bit.ly URL은, 말하자면, http://nyti.ms/Yi6EAk, 당신은 다음과 같은 로그를 볼 수 있습니다

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType 
{ 
    NSLog(@"%@", request.URL); 
    return YES; 
} 

bit.ly 리디렉션 URL, 즉 두 번의 연속적인 리디렉션의 최종 대상을 정의한 URL입니다. 그러나 shouldStartLoadWithRequest이 NO을 반환하면 궁극적으로 리디렉션되는 사이트를 결코 알 수 없습니다. (그건 그렇고, 당신의 shouldStartLoadWithRequest 확실히 샘플 중 하나를 반환하지 않습니다 ... YES 또는 NO를 반환해야합니다.)

당신이 볼 수 있듯이, shouldStartLoadWithRequest이 발생하기 때문에 리디렉션이 수행 할 수있는 기회를하기 전에, 당신에게 ' 리다이렉트가 일어날 때마다 볼 수 있습니다. 결과 사이트에 따라 페이지가 추가 콘텐츠를 검색 할 때 이후 shouldStartLoadWithRequest 호출이 표시 될 수 있습니다. 이렇게하면 궁극적으로 리디렉션 된 사이트를 찾는 데 어색한 메커니즘이됩니다.

리디렉션되는 사이트가 실제로 필요한 경우 NSURLConnection을 대신 사용할 수 있습니다. 일반적으로 서버에서 실제로 데이터를 검색하는 데 사용되지만 리디렉션을 캡처하는 데에도 사용할 수 있지만 (UIWebViewDelegate 메서드 shouldStartLoadWithRequest의 문제는 발생하지 않습니다.이 경우 임의의 추가 콘텐츠에서 실제 리디렉션을 구별하기가 어렵습니다. 페이지가 계속 요청 될 수 있음).당신이 추적 NSURLConnection를 사용하고 있기 때문에, 분명히

- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response 
{ 
    self.url = request.URL; 

    return request; 
} 

:

self.url = [NSURL URLWithString:@"http://nyti.ms/Yi6EAk"]; 
NSURLRequest *request = [NSURLRequest requestWithURL:self.url]; 
[NSURLConnection connectionWithRequest:request delegate:self]; 

그런 다음 다양한 리디렉션을 추적합니다 connection:willSendRequest:redirectResponse:하는 NSURLConnectionDataDelegate 방법을 구현할 수 있습니다

그래서 다음 사항을 고려 리디렉션은 있지만 일반적으로 검색 할 을 사용하는 responseData에 대해서는별로 신경 쓰지 않아 좋은 응답을 받으면 바로 연결을 취소 할 수 있습니다 (confide NT를 우리가 이미 알고있는 사이트 것은 마지막으로) 리다이렉트하기 :

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response 
{ 
    [connection cancel]; 

    NSLog(@"Ok, we now know that the resulting URL is %@", self.url); 
} 

당신은, 그런데, 또한 예를 들어, 연결 오류를 캡처 할 수 있습니다 : 끝으로

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error 
{ 
    NSLog(@"Ok, we failed trying to retrieve data from %@", self.url); 
} 

, 그것을 가리키는 가치 이 기술은 HTTP 요청을 NSURLConnection으로 만들고 전체 일련의 리디렉션을 따르는 것이 매우 비효율적 인 과정이므로 가치가 있는지 여부를 결정해야합니다. 그러나 이것은 HTTP 리디렉션이 당신을 이끌 것 인 곳을 파악하는 한 가지 방법입니다.

마지막으로주의해야 할 점은 전통적인 리디렉션을 캡처하지만 페이지에서 클라이언트 쪽 JavaScript 리디렉션을 수행하는 경우이 기술이 작동한다고 생각하지 않습니다. 하지만 대부분의 리디렉션 된 HTTP 요청에서 작동합니다.