어라... iAd 배너 View가 붙어야 할 자리에.. 그냥 덩그러니 빈 화면만 생기네?? 그래서 부랴부랴 'iPhone Developer News' RSS를 확인 해 봤더니 이런 피드가 있더라..
'For developers outside of North America, iAd will be rolled out in a few months.'
퓨 먼쓰란다.... 북미시장을 제외하고 나머지 시장은 아직 iAd가 서비스 되지 않는댄다.. 아마 광고타겟이 다르기 때문이 아닐까.. 생각이든다
그래서 우리 아시아권 개발자들은.. iAd를 request했지만 거절됐을 때 이벤트를 만들어 줘야되는데 (iAd 영역의 공간을 원래의 컨텐츠가 가져가게 하던가.. 말이지)
http://developer.apple.com/videos/wwdc/2010/ 올해 개최되었던 WWDC 페이지를 가면 iAd라던가 멀티태스킹에 관련된 키노트들이 있으니 참고를 하면된다.
그 키노트를 바탕으로 만들어 뒀던 예제는 요렇게 생겼는데요.. 한번 보시죠
- (void)moveBannerViewOffScreen { // iAD영역을 없애고 컨텐츠 크기를 늘리는 메소드 CGRect originalWebViewFrame = _webView.frame; CGFloat newWebViewHeight = 416; // self.view.frame.size.height 와 같이 self.view가 되었던, tableview가 되었던 원하는 높이 CGRect newWebViewFrame = originalWebViewFrame; newWebViewFrame.size.height = newWebViewHeight;
- (void)bannerViewDidLoadAd:(ADBannerView *)banner { [self moveBannerViewOnScreen]; } // 정상적으로 iAd가 요청되었을때 ADBannerViewDelegate 에서 콜백되는 함수
- (void)bannerView:(ADBannerView *)banner
didFailToReceiveAdWithError:(NSError *)error {
NSLog(@"didFailToReceiveAdWithError : %@",[error description]);
[self moveBannerViewOffScreen]; } // iAd요청을 했으나, 거절되었거나 인터넷 상태가 좋지않아 광고를 받아오지 못 할 경우
대충 보시면 저 같은경우엔 UIWebView를 이용해서 iAd를 달았기 때문에 self.view가 아니라 _webView의 크기를 구하는 걸 알 수가 있을거에요~
다음 과정을 거치면 PEM 형식의 인증서와, 개인키가 발급이 됩니다. 써드파티 서버에서 푸쉬를 보낼 때 푸쉬 인증서를 개인키와 비교해서 올바른 사용자인지 구분하는 과정을 거쳐줘야 되는데요, 매번 개인키를 통해서 인증하는 과정이 번거롭기 때문에, 인증서와 개인키를 합치는 과정을 진행 해 보 겠습니다.
Tracked from Britney spears underwear.2010/07/30 23:13delete
Britney spears no underwear. Male underwear. Lindsey lohan no underwear. Britney without underwear. Brittney spears underwear. Britney spears without underwear.
어플리케이션에서 사용자에게 어떠한 알림메시지나, 이벤트를 주기위해서 푸쉬~라는 서비스가 필요로 합니다. 예를들면, 메신저를 통해 친구가 로그인 했다던가 하면 오른쪽 구석에서 네모난 상자가 올라갔다가 내려가면서 사용자들에게 어떤 상황을 전해 주는걸 푸쉬 서비스라고 생각을 하시면 됩니다.
모바일 디바이스에서도 예외가 아니에요. 디바이스에 설치한 어플리케이션에서 사용자에게 도움이 되는 정보나, 어떠한 상황이 발생했을 때 알려주는 기능이 있어야 되는건 당연하겟죠.
기본적으로 푸쉬알람을 받기위해선, 어플리케이션이 있어야겠죠. 그리고 물론 어플리케이션이 실행중이어야 됩니다. 그래서 윈도우 기반의 휴대폰들을 보면 푸쉬서비스를 받기 위해서 상당량의 프로그램들이 계속 백그라운드로 실행되고 있습니다.
( 왼쪽에 있는게 윈도우 모바일의 작업관리자 화면 인데요 지속적으로 푸쉬알림을 받고, OS를 관리하는 프로세스들이 실행되고 있습니다. )
하지만,
단순히 어플리케이션이 백그라운드로 많이 떠있으면 그만큼 퍼포먼스도 떨어지고, OS도 불안불안해집니다. 특히 개인개발자들이 만든 백그라운드 어플리케이션들은 그 안정성도 보장할 수 없고, 걔네들이 무슨짓을 하는지도 알 방법이 없죠..
그래서 애플이 아이폰을 발표하고, 기존에 모바일 OS와 차별을 두기 위해 꺼내든 카드는 OS의 안정성과 신뢰성입니다.
iTunes AppStore를 통해서 애플의 검수를 모두 마친 어플리케이션들만 판매 / 제공함으로서 사용자들은 믿고 어플리케이션을 받을 수 있게되고, 어플리케이션들의 안정성은 전화기를 껐다,켰다 반복하지 않게 되었습니다. 사용자들은 디바이스가 제멋대로 꺼지진 않을까? 바이러스가 걸려서 내 개인정보가 빠져나가진 않을까? 에 대한 걱정은 깨끗하게 잊을 수 있게 만들었습니다.
그러면, 아이폰은 백그라운드 프로그램을 지원하지 않는데 어떤방식을 통해서 어플리케이션 푸쉬서비스를 받을 수 있을까요? 정답은 바로 APNs에 있습니다.
어플리케이션이 사용자에게 알려줘야 되는 내용을 애플 서버를 경유해서 전달해줌으로 인해서, 그 푸쉬되는 내용에 대해서 신뢰할 수 있게 됩니다.
일반적인 푸쉬 서비스의 흐름은 간단합니다. ( 클라이언트 서비스 서버 ) -> ( 모바일 디바이스 ) 반면에, APNs는 ( 클라이언트 서비스 서버) -> ( APNS : Apple Push Notification Server ) -> ( 아이폰 ) 의 방법을 통해서 사용자에게 푸쉬를 해주는 겁니다.
그리고 APNs는 일반적인 푸쉬서비스와 개념이 약간 다른데요.. 일반적으론 백그라운드에 있던 어플리케이션이 푸쉬를 받는 순간 특정한 모듈이 작동하고, 액션이 발생하지만
APNs의 개념은 "어플리케이션에 다음 과 같은 상황이 일어났으니.. 어플리케이션을 실행해서 서버와 통신을 하도록 해라." 라고 할 수 있을 것 같습니다. 푸쉬 메시지가 어플리케이션의 어떤 행동을 해주는게 아니란 얘기죠.. ^^
APNs를 이용함에 있어서 단점도 있습니다. 전세계 아이폰 어플리케이션에서 원하는 푸쉬의 내용이 각 나라의 통신사 서비스를 통해서 애플서버를 경유해 가기 때문에, 반응이 느릴 수 밖에 없습니다. 그리고 푸쉬가 폭주하는 날이면 종종 알람을 받지 못하는 경우도 일어납니다. ( 경우에 따라 다르지만, 푸쉬를 제공하는 클라이언트 서비스 서버가 트래픽을 감당못하고 뻗어버리는 경우가 더 많죠... ) 그리고, 푸쉬로 제공할 수 있는 데이터의 제한이 있습니다. 다음 파트에서 또 언급을 할 거지만.. 256byte의 제한이 있습니다. 텍스트의 크기가 아니고, 모든 푸쉬서비스에 관련된 패킷 사이즈가 256byte 미만이어야 합니다.
푸쉬 서비스 치곤 할 수 있는게 너무 없다고 생각하실 수도 있을거에요, 하지만 애플이 원하는건 안정성을 담보로 아이폰의 안녕을 바라고 있으니까요 ^^
(0) 
(0)
MRImageViewer.zip
iPhoneOS4.pdf
댓글을 달아 주세요