스타플(http://starpl.com) 에서 제작된 아이폰/아이팟터치용 무료 어플입니다. 

★★★★★ 아이돌배틀 ★★★★★
팬심으로 대동단결! 매일매일 우리아이돌에게 ♥를 조공하세요~


■ 아이돌랭킹 ■

팬들이 조공한 ♥로 실시간/일간/주간 아이돌 랭킹을 제공합니다.
무조건 팬수가 많다고 랭킹이 높아지지 않아요!
꾸준한 팬심으로 매일매일 ♥를 조공해주세요~


■ ♥캘린더 ■ 

내가 ♥를 조공한 날을 캘린더로 보여드립니다.
♥캘린더로 아이돌을 향한 나의마음을 체크해보세요!


■ 아이돌 커뮤니티 ■

다양한 아이돌의 커뮤니티를 제공합니다.
아이돌 커뮤니티에서 팬들의 정보와 대화를 나눠보세요!


■ 친구에게 알리기 ■

다양한 SNS 서비스와 카카오톡으로 "아이돌배틀"에 초대할 수 있습니다.
우리 아이돌 랭킹 유지할 수 있도록 친구들에게 소문내 주세요!


■ 다운로드 ■ 

 
http://goo.gl/aEw8r




■ 스크린샷 ■ 




 

 ■ 참고사항 ■ 


*** [아이돌배틀]으로 작성한 글/댓글은 스타플(starpl.com) 웹서비스에도 자동 업로드됩니다. 
PC에서 www.Starpl.com으로 접속하시면 더욱 다양한 기능의 스타플 서비스를 이용하실 수 있습니다.


*** 다양한 스타플 연동 어플리스트

(안드로이드)바른생활
(안드로이드)책을읽자!

(아이폰)책을읽자!
(아이폰)바른생활
(아이폰)신조어능력시험
(아이폰)어플지름신
(아이폰)타임라인 
(아이폰)오픈배경화면

 

글쓴이 : 지돌스타(http://blog.jidolstar.com


이 글은 iOS에서 Local Notification에 대한 전반적인 이해를 돕기위한 글이다. 그래서 유사형태인 APNS와 비교해보기도 했다. 검색해보면 Local Notification에 대한 문의는 있어도 이에 대해서 설명된 한글문서가 없는 것 같아 정리해보았다.

Local Notification에 대해
iOS 4.0 이상부터 Local Notification(지역알림, 내부통지, http://goo.gl/jFFsT)을 지원한다.  그러므로  iOS 4.0 미만 버전을 지원하는 어플의 경우 호환성을 유지할 수 있도록 개발해야할 것이다.

Local Notification은 어플이 실행중이 아니거나 Background, Foreground 상태에 관계없이 지정된 날짜와 시간에 필요한 최소한의 데이터를 전송하여 어플에게 전달해 실행하거나 다른 행동을 취할 수 있도록 구현할 수 있다. 심지어 Local Notification을 예약하고 iOS를 재부팅해도 정상적으로 동작한다.  이러한 형태가 가능한 것은 Local Notification 관리는 iOS 자체에서 하기 때문이다. 

Local Notification과 APNS(Apple Push Notification Service, http://goo.gl/fWknl)의 큰 차이점은 Notification을 위한 서버가 필요한가 아닌가의 차이에 있다. APNS는 서버가 준비가 되어 있어야 하고 Push를 위한 인증서도 발급해야한다. 처음 테스트 환경을 만들고 운용하는게 복잡한 편이다. 반면 Local Notification은 이런 절차가 전혀 필요없이 간단하게 코드상에서 처리할 수 있다. 이처럼 Local Notification을 사용하는 방법은 꽤 간단한 편이다. 하지만 APNS에 비해서 테스트하기가 좀 까다로운 면이 있다. 왜냐하면 Local Notification은 시간기반으로 하는 통지가 되는 형태이기 때문에 통지에 대한 제어권이 iOS에 있으며 개발자에게 있다고 볼 수 없기 때문이다. 반면에 APNS는 서버측에서 어떤 시간에 상관없이 개발자가 원하는데로 바로 통지를 할 수 있다. 

Local Notification와 APNS가 이처럼 차이점이 있지만 넘겨주는 데이터나 동작하는 방식은 거의 유사한 편이다.  그래서 어플내에서 동작하는 형태를 하나의 인터페이스로 만들어 운영할 수 있다. 이것이 가능한 이유는 둘다 PayLoad(http://goo.gl/mulVQ)가 유사한 형태를 가지며 통지되었을때 같은 동작을 하기 때문이다. (PayLoad는 일종의 메시지 데이터를 보유하는 패킷이나 프레임의 부분을 말한다.) PayLoad에는 Notification Type과 Custom Data를 담는다. Notification Type은 메시지 ,버튼 제목, 아이콘뱃지숫자, 사운드등으로 구성되어 있고 Custom Data에는 이외에 데이터가 필요한 경우  Dictionary형태로 구성된다. 하지만 APNS와 Location Notification간에 PayLoad데이터 관리의 차이는 있다. APNS는 Dictionary로 관리되며, Location Notification은 UILocalNotification 클래스(http://goo.gl/3TyTg)로 관리 된다. 

Local Notification은 APNS와 다르게 시간기반으로 운용된다. 이것은 iOS에서 스케쥴링을 해준다는 말과 같다. 그래서 통지가 일어나야하는 날짜와 시간을 정해줘야한다. 

Local Notification 사용법 
지금까지  Local Notification을 설명하면서 APNS와의 차이점도 알아보았다. 이러한 내용을 미리 언급하는 것은 처음 이를 접근할 때 Local Notification에 대한 전반적인 이해가 필요하기 때문이다. 여러가지로 복잡하고 잘 이해가 안되겠지만 실제로 해보면 이보다 쉬울 순 없다. 

Local Notification을 학습하기 위해서  Apple문서를 먼저 참고하는 것이 좋겠다.
 - About Local Notifications and Push Notifications : http://goo.gl/jFFsT

그럼 간단하게 Local Notification을 사용하는 방법을 알아보자. 크게 등록과 처리하는 방법을 구분해서 정리했다.

1. Local Notification 등록하기

Xcode상에서 Window Based 어플 프로젝트를 생성한뒤 AppDeleage 소스코드내에 application:didFinishLaunchingwithOptions: 메시지에 다음 코드를 넣는다.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    

    

    // Override point for customization after application launch.

    

    [self.window makeKeyAndVisible];


    //통지시간 정하기 

NSCalendar *calendar = [NSCalendar autoupdatingCurrentCalendar];

NSDateComponents *dateComps = [[NSDateComponents alloc] init];

[dateComps setYear:2011];

[dateComps setMonth:3];

[dateComps setDay:22];

[dateComps setHour:15];

[dateComps setMinute:30];

[dateComps setSecond:0];

NSDate *date = [calendar dateFromComponents:dateComps];

[dateComps release];

UILocalNotification *localNotif = [[UILocalNotification alloc]init];

if (localNotif != nil

{

//통지시간 

localNotif.fireDate = date;

localNotif.timeZone = [NSTimeZone defaultTimeZone];

//Payload

localNotif.alertBody = [NSString stringWithFormat:@"내부통지 %@",date];

localNotif.alertAction = @"상세보기";

localNotif.soundName = UILocalNotificationDefaultSoundName;

localNotif.applicationIconBadgeNumber = 1;

//Custom Data

NSDictionary *infoDict = [NSDictionary dictionaryWithObject:@"mypage" forKey:@"page"];

localNotif.userInfo = infoDict;

//Local Notification 등록

[[UIApplication sharedApplication] scheduleLocalNotification:localNotif];

}

[localNotif release];

    return YES;

}


이게 끝이다. Local Notification을 등록하는 시점은 어디라도 상관없다. 필요할 때 등록하면 된다. UILocalNotification 객체를 생성하고 통지시간, Payload, Custom Data를 설정한뒤 등록하면 지정된 시간에 통지가 발생할 것이다. APNS럼 APNS 서버에 DeviceToken을 받는 과정이 모두 생략되기 때문에 등록절차는 매우 쉬운 것을 알 수 있다. 

이 코드에서 Local Notification 등록을 scheduleLocalNotification을 사용했다. 필요한 경우에 스케쥴링 필요없이 즉각적으로 Local Notification을 줄 필요가 있는 경우에는 다음 메시지를 사용하면 되겠다. 

[[UIApplication sharedApplication] presentLocalNotificationNow:localNotif];


만약 fireDate를 현재시간보다 이전시간으로 등록하면 iOS는 바로 통지해버린다. 이 말이 그냥 쉽게 넘어갈 수 있는 문제인데 경험상 현재시간보다 이전시간으로 가는 경우는 없기 때문에 왠만하면 이전시간으로 등록하는 경우가 없도록 코딩을 해야 버그를 유발시키지 않을 것이다.

만약 이전에 등록된 Local Notification을 삭제하고 싶은 경우가 발생할 수 있다. 그런 경우에는 다음 메시지 중에 하나를 사용하면 되겠다.

[[UIApplication sharedApplication] cancelAllLocalNotifications];

[[UIApplication sharedApplication] cancelLocalNotification:localNotif];




2. Local Notification 처리하기 
앞서 Local Notification을 등록하는 방법을 알았다. 등록된 통지는 iOS에서 스케쥴링해준다.  어플의 실행여부, 및 iOS재부팅에 전혀 상관없이 동작하기 때문에 개발자는 이런부분에 대해 별다른 노력없이 통지 처리에 대한 로직만 만들면 된다.

내부 통지는 다음 3가지 형태로 처리가 가능하다. 이는 APNS와 유사하다.

[경우 1] 어플이 실행중이지 않은 경우 
이 경우에 iOS에 등록된 통지를 정해진 시간에 발생하면 자동으로 Alert창을 띄워준다. 거기에는 UILocalNotification에 Payload로 등록한 alertBody, alertAction이 반영되어 있으며 주어진 사운드를 들려준다. 어플의 아이콘에도 정해진 badge숫자가 표시된다. 


위의 경우 특별히 AppDelegate에서 application:didFinishLaunchingWithOptions: 메세지 내에서 통지된 UILocalNotification객체를 참고할 수 있다. Local Notification을 통해 어플이 실행되는 경우 별다른 작업이 필요하다면 이를 이용하면 유용할 것이다. 접근방법은 간단한다. 아래처럼 접근해서 사용하면 되겠다.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    

    

    // Override point for customization after application launch.

    

    [self.window makeKeyAndVisible];

UILocalNotification *notif = [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];

if (notif != nil

{

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"알림" 

message:[NSString stringWithFormat:@"didFinishLaunchingWithOptions %@",notif.alertBody

  delegate:nil 

  cancelButtonTitle:nil 

  otherButtonTitles:@"확인",nil];

[alert show];

[alert release];

}

    return YES;

}


이 경우 다음과 같은 화면을 볼 수 있을 것이다. 



또한 AppDelegate 상에 application:didReceiveLocalNotification: 메시지를 구현하면 Local Notification을 처리할 수 있다. 이 메시지는 다음에 나오는 [경우2], [경우3]에도 동일하게 동작한다. 아래처럼 구현해보자.

-(void) application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification

{

application.applicationIconBadgeNumber = 0;

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"알림" 

message:[NSString stringWithFormat:@"didReceiveLocalNotification %@",notification.alertBody

  delegate:nil 

  cancelButtonTitle:nil 

  otherButtonTitles:@"확인",nil];

[alert show];

[alert release];

}


다음은 위코드가 실행될 때 화면이다.



[경우2]어플이 실행중이나 background에 위치해 있는 경우 
[경우1]과의 유일한 차이점은 application:didFinishLaunchingWithOptions: 를 통해 UILocalNotification 객체정보를 얻을 수 없다는 것이다. 이 경우에는 이미 어플이 실행중이기 때문에 어플이 처음 실행할때 최초 한번만 호출되는 AppDeleage의 application:didReceiveLocalNotification:가 실행될 수 없기 때문이다. 이 의미는 application:didFinishLaunchingWithOptions: 와 application:didReceiveLocalNotification: 에서 얻어지는 UILocalNotification 객체정보가 같더라도 서로 다른 일을 할 수 있도록 한다는 점을 시사한다.  

application:didReceiveLocalNotification: 메시지는 여전히 호출되므로 이때 UILocalNotification 객체를 처리하면 되겠다.


[경우3]어플이 실행중이며 foreground에 위치해 있는 경우
마지막으로 어플이 화면위에 실행중인 경우이다. 이때도 [경우1], [경우2]와 차이점은 iOS에서 직접적으로 Alert창을 띄워주지 않는다는 점이다. application:didFinishLaunchingWithOptions: 는 당연히 호출되지 않으며 application:didReceiveLocalNotification:  만 호출된다. 


Local Notification 처리에 대한 경우 1, 2, 3을 표로 정리하면 다음과 같을 것이다. 
   경고창   didFinishLaunchingWithOptions를 통한 UILocalNotification참고  didReciveLocalNotification메시지를 통해 UILocalNotification 참고
 경우 1 (어플 실행X)  O
 경우 2 (어플 background)  O
 경우 3 (어플 foreground)


지금까지 설명한 내용 대해서 더 자세히 알고 싶다면 다음 문서를 참고한다.
Scheduling, Registering, and Handling Notifications : http://goo.gl/qHVPi


팁(Tip)
Local Notification을 사용하면서 이런 점은 알아둘 필요가 있다. 

1. 등록시 현재 시간보다 빠른 시간을 등록하면 바로 통지가 된다. 이 점은 어플 버그를 유발할 수 있으므로 각별히 주의하길 바란다. 개발 경험상에서 말씀드린다. (여기서 버그는 실제 버그가 아니라 의도하지 않는 동작을 유발시킨다는 말이다.)

2. 테스트를 위해서는 아이폰 자체 시간설정 기능을 적극 활용하면 되겠다. Local Notification의 통지는 iOS가 스케쥴링을 해주기 때문에 개발자가 통제할 수 없다. 그러므로 아이폰 자체 시간설정 기능을 활용해 테스트할 수 있겠다.

3. PayLoad대신 Custom Data를 사용하는 방법은 별도로 설명을 안했지만 UILocalNotification상에 userInfo속성을 활용하면 된다는 점을 설명하지 않아도 여러분은 잘 사용할 수 있을 것이라 생각한다. ^^


정리하며
Local Notification에 대해서 전반적인 내용을 다뤄보았다. 생각보다 개념자체는 간단하지만 어느 경우에 어떻게 사용하고 동작하는지에 대한 명확한 지식이 없으면 오용할 여지는 많다. 또한 잘못 사용하면 뜻하지 않는 동작을 유발할 수 있기 때문에 등록시 시간을 잘 설정해야하는 것은 꼭 염두해야 한다. 또한 클라이언트 베이스로 등록/처리를 해야하는 부분은 이에 대한 적절한 설계를 바탕으로 하지 않으면 로직이 복잡해져 관리가 어려워질 수 있다는 점도 개인적인 경험이다. 

아무튼 회사에서 이를 이용한 관련 어플을 만들면서 처음 사용해 봤는데 자세히 알지 않고 사용하면 문제가 될 것 같아 정리를 해보았다.


관련글
About Local Notifications and Push Notifications : http://goo.gl/jFFsT
The Notification Payload : http://goo.gl/mulVQ
UILocalNotification 클래스 : http://goo.gl/3TyTg
Scheduling, Registering, and Handling Notifications : http://goo.gl/qHVPi
내가 만든 어플에 Push Notification 적용하기 : http://goo.gl/kH7BQ 
APNS 개발버전과 배포버전의 차이점. : http://blog.jidolstar.com/726
APNS Device Token을 못받아올때 : http://blog.jidolstar.com/725
 
글쓴이 : 지돌스타(http://blog.jidolstar.com/758)  
얼마전 아이폰 어플의 개발 요구사항중에 아이폰내 AppStore로 이동시키는 기능구현이 있었다. 이 글은 그것을 이해하는데 필요한 전반적인 기본 지식을 간단히 정리했다.

Apple iOS Applications의 URL 스키마
인터넷에서 링크는 URL 스키마(scheme)인 http, mailto, ftp, feed등을 이용해 종류가 구분된다. 이는 범용적인 예이다.  반면  iOS 링크는 이보다 더 특별한 기능을 가진다. 가령 "sms:전화번호"로 하면 문자메시지 보낼 수 있는 링크가 되며 "tel:전화번호"는 자동으로 전화를 걸 수 있다. 이런 특별한 스키마를 사용하지 않더라도 http를 그대로써서 필요하다면 관련 어플로 이동시키는 것도 가능하다. 가령, 구글맵의 경우 "http://maps.google.com/maps?q=검색위치" 형태로 접근하면 구글맵 어플이 열린다. 이이튠즈도 "http://itunes.apple.com"으로 시작하면 아이튠즈 어플이 실행된다. 유투브도 비슷하다. 

활용하는 방법은 어플상에서 iOS SDK에서 제공하는 [[UIApplication sharedApplication] openURL: ]을 이용하거나 사파리 주소창이나 링크에 위 사항을 적용하면 되겠다.

지금까지 설명한 URL 스키마들은 모두 iOS에서 기본으로 제공하는 것이다. 

다음 링크에는 iOS URL 스키마의 종류와 사용예를 잘 정리하고 있다.


Third Party Applications의 커스텀 URL 스키마
개발자는 커스텀 URL스키마를 만들 수 있다. 이는 어플만의 URL 스키마를 사용하면 가능해진다. 즉, URL스키마를 이용하면 자신이 만든 어플도 사파리에서 띄울 수 있게끔 유도할 수 있다는 것을 뜻한다.  

다음 글에는 커스텀 URL 스키마를 어떻게 어플에 적용하는가 보여주고 있다.


다음 소개하는 어플은 [[UIApplication sharedApplication] openURL:]을 활용한 어플로 URL 스키마를 테스트 해볼 수 있는 어플이다. (찾아봤더니 진짜 있네? ^^) 

Open URL : http://goo.gl/8n9mV



아이폰 어플에서 AppStore 검색페이지로 이동하기

이 글의 목적은 바로 아이폰 어플에서 아래 화면처럼 AppStore 어플의 검색페이지 이동하여 특정키워드로 검색하는 방법을 설명하는 것이다.  지금까지 URL 스키마를 설명했으니 이것도 URL을 통해 실행이 가능하다.


iOS 개발자 분들이라면 아래와 같은 URL을 이용하면 AppStore의 해당 어플 페이지로 이동한다는 것은 알고 있을 것이다.

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=406292683
http://itunes.apple.com/kr/app/id406292683

이것은 1개의 어플을 찾을때는 유용하다. 그럼 검색은? 특별히 우리 회사에서 만든 어플을 찾아내야 한다면?

http://itunes.com/회사명
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewArtist?id=회사아이디
http://itunes.apple.com/us/artist/회사명/id회사아이디 
item-apps://itunes.apple.com/us/developer/회사명/id회사아이디

등등..... 검색해서 다 해봤지만 전부 아이튠즈 어플로만 이동한다. 앱스토어에 이동해야하는데 말이다. 물론 맥에서는 잘 찾아간다. 단지 아이폰/아이팟터치에서는 아이튠즈와 앱스토어 어플이 분리되어 있는게 문제인 것이다.

하루 걸러서 검색으로 찾은 결과 방법을 알아냈다.
이것도 결국 URL을 이용하면 된다. (맥 사파리나, 아이폰 사파리, [[UIApplication sharedApplication] openURL: ] 을 이용해 접근하면 확인할 수 있겠다.)


마지막 term 파라미터에 회사명만 적어주면 된다. 

아~ 이것을 알아내느라 몇시간을 소비했다. 
좋은 팁이였길 바란다.

글쓴이 : 지돌스타(http://blog.jidolstar.com/751)








개인적으로 ActionScript 3.0 기반에서 개발을 많이 하다보니 Objective-C의 target/selector 형태로 접근하는게 익숙하지 않았다. 사실 ActionScript 3.0에서는 더 고수준으로 랩핑 처리하다 보니 selector격인 함수의 참조만 보내줘도 되긴하다. 그렇지만 이러한 사실이 이해가 된다고 하더라도 매번 target/selector를 보내고 처리하는게 여간 불편하지 않았다.

아래는 Objective-C에서 target/selector를 사용하는 방법이다. 뭔가 다른 클래스에 대리 요청을 하기 위한 방법으로 이렇게 많이 쓸 것이다.

위 방법이 익숙해지면 사용하는데 어렵지는 않다. 그냥 target/selector 넘겨주고 실행해주면 그만이다. 앞서 말했지만 나는 이러한 것에 익숙하지 않다. 그래서 2개를 보내는 형태가 아닌 하나로 묶어서 보내고 싶었다. 아래처럼 말이다. 


위 도식에서 Action클래스는 target/selector를 관리하고 실행해주는 역할을 한다.

뭔가 더 복잡해보인다. 하지만 이 방법의 장점은 target/selector로 두개의 변수를 관리하는게 아니라 이것을 하나로 묶은 Action클래스의 객체만 관리하면 된다는 것이다. 

Action내에 있는 target/selector를 실행하기 위해 위 도식에서 [_tempSuccessAction run]과 같이 하면 된다. 이것을 조금더 확장해서 생각하면 [_tempSuccess runWithData:data] 처럼 할 수 있고 스레드에도 대응시키기 위해 [_tempSuccess runInThreadWithWaitUntilDone:YES] 와 [_tempSuccess runInThreadWithData:data waitUntilDone:YES] 처럼 사용할 수 있도록 Action에 관련 메서드를 추가해도 된다. 이렇게 생각해보니 Action 클래스로 target/selector를 관리하는게 여러가지로 장점이 될 수 있다는 것을 알 수 있다. 

아래 코드는 Action 클래스의 header 정의 부분이다.

//

//  Action.h

//

//  Created by Yongho Ji on 10. 12. 7..

//  Copyright 2010 Wecon Communications. All rights reserved.

//


#import <Foundation/Foundation.h>


//target/selector 하나로 묶고 실행해주는 클래스 

@interface Action : NSObject 

{

@private

id _target; //selector 가지고 있는 클래스 객체 참조

SEL _selector; //target안에 정의된 selector 메서드 

}


//초기화 

-(id)initWithTarget:(id)target selector:(SEL)selector;


//target/selector 실행 

-(void)run;


//target/selector 실행하되 selector인자로 data 넘김 

-(void)runWithData:(id)data;


//(Thread안에서 호출)target/selector 실행.

-(void)runInThreadWithWaitUntilDone:(BOOL)waitUntilDone;


//(Thread안에서 호출)target/selector 실행하되 selector인자로 data 넘김 

-(void)runInThreadWithData:(id)data waitUntilDone:(BOOL)waitUntilDone;

@end



Thread내에서는 runInThread... 를 호출해주면 그만이다. 구현부를 보자.

//

//  Action.m

//

//  Created by Yongho Ji on 10. 12. 7..

//  Copyright 2010 Wecon Communications. All rights reserved.

//


#import "Action.h"



@implementation Action


-(void)dealloc 

{

[super dealloc];

//[_target release];

}


-(id)initWithTarget:(id)target selector:(SEL)selector 

{

if (self = [super init]) 

{

//[target retain];

//[_target release];

_target = target; //retain하지 않고 assign 한다. 왜냐하면 retain하면 메모리 누수를 야기시킬 있으므로 

_selector = selector;

}

return self;

}


-(void)run 

{

@try {

if (_target != nil && _selector != nil

{

[_target performSelector:_selector];

}

}

@catch (NSException * e) {

NSLog(@"%@",e);

}

}


-(void)runWithData:(id)data 

{

@try {

if (_target != nil && _selector != nil

{

@try {

[_target performSelector:_selector withObject:data];

}

@catch (NSException * e) {

[_target performSelector:_selector];

}

}

}

@catch (NSException * e) {

NSLog(@"%@",e);

}

}


-(void)runInThreadWithWaitUntilDone:(BOOL)waitUntilDone 

{

@try {

if (_target != nil && _selector != nil

{

[_target performSelectorOnMainThread:_selector withObject:nil waitUntilDone:waitUntilDone];

}

}

@catch (NSException * e) {

NSLog(@"%@",e);

}

}


-(void)runInThreadWithData:(id)data waitUntilDone:(BOOL)waitUntilDone

{

@try {

if (_target != nil && _selector != nil

{

@try {

[_target performSelectorOnMainThread:_selector withObject:data waitUntilDone:waitUntilDone];

}

@catch (NSException * e) {

[_target performSelectorOnMainThread:_selector withObject:nil waitUntilDone:waitUntilDone];

}

}

}

@catch (NSException * e) {

NSLog(@"%@",e);

}

}



@end



사용방법은 이미 설명했다. 간단한 아이디어지만 좀 더 확장해서 생각해보면 Action 클래스에 추가할 수 있는 것들이 많을 것 같다.


비슷한 이유에서 통지대신 이벤트를 만들어 사용한다.
NSNotification 대신 Event 사용하기 http://blog.jidolstar.com/721

글쓴이 : 지돌스타(http://blog.jidolstar.com/742


스타플에서 '작심삼일' 아이폰/아이팟터치 어플을 배포합니다. 

작심삼일 어플은 '영어공부', '금연하기', '애인만들기', '다이어트', '부자되기', '책읽기'등 신년에 들어서 하고 꼭 하고 싶지만 실천하기 어려운 계획을 실천할 수 있도록 도와주는 것을 목적으로 삼습니다.

또한 각 계획별로 같은 목표를 삼은 사람들과 함께 각자의 고민을 공유하고 실천할 수 있도록 도움을 줄 수 있게 커뮤니티를 지원합니다.

계획을 잘 실천하고 있는지 매일 체크할 수 있는 체크캘린더 기능도 포함하고 있습니다.

그리고 계획시작 3일간 실천의 도움을 주고자 알림서비스를 제공합니다.

스타플에서는 "올해는 꼭 성공하자! 나의 신년계획!" 이벤트를 진행중입니다.

이벤트 페이지 : http://starpl.com/main/event/view/68



시작이 반이라고 합니다. 작심사일 어플을 통해 여러분의 계획을 꼭 실천에 옮겨보세요. ^^


앱스토어 : http://goo.gl/mkGZA
앱스토어 QR 코드 :

스크린 샷입니다.








글쓴이 : 지돌스타(http://blog.jidolstar.com)
iOS 어플상에서 기기의 종류를 알아올 수 있는 코드이다.

#include <sys/sysctl.h>    // sysctlbyname 의 사용을 위해

// 모델 정보 보기 - 상세히
+ (NSString *) platform {
    size_t size;
    sysctlbyname("hw.machine", NULL, &size, NULL, 0);
    char *machine = malloc(size);
    sysctlbyname("hw.machine", machine, &size, NULL, 0);
    /*
     Possible values:
     "i386" = iPhone Simulator
     "iPhone1,1" = iPhone 1G
     "iPhone1,2" = iPhone 3G
     "iPhone2,1" = iPhone 3GS
     "iPhone3,1" = iPhone 4
     "iPod1,1"   = iPod touch 1G
     "iPod2,1"   = iPod touch 2G
     "iPod3,1"   = iPod touch 3G
     */
    NSString *platform = [NSString stringWithUTF8String:machine];
    free(machine);
    
    return platform;
}

출처 : http://cafe.naver.com/mcbugi/81305


Objective-C에서 retain/release 메커니즘을 이해하고 익숙해지는데 오랜 시간이 걸렸다. 이해 자체는 빠를지언정 적절히 쓰는 건 많이 어려운 것 같다.

retain/release/autorelease 를 쓰는 이유는 사실 많이 공개되어 있다. 하지만 retain을 하면 안되는 경우에 대해 다루는 글이 많지 않은 것 같다.

delegate는 기본적으로 retain이 아닌 assign을 한다. 만약 ViewController가 어떤 객체의 delegate대상으로 설정될때 retain을 해버리면 어떤 객체가 delegate를 release해주지 않는 이상 ViewController는 dealloc이 호출되지 않는 문제가 발생한다. 그러면 자연스럽게 메모리 릭(memory leak)이 발생한다. 그렇기 때문에 delegate는 assign을 해주는 것이다.

이런 경우도 있다. UITableViewCell을 커스터마이징처리한 CustomTableViewCell이 있다고 하자. 여기에 UITableViewController를 확장한 MyTableViewController가 이 CustomTableViewCell을 사용한다고 가정하자. 보통 같으면 사용에 문제가 없지만 만약 CustomTableViewCell에서 MyTableViewCeontroller의 메서드를 호출할 수 있게 하기 위해 MyTableViewController 객체 자신(self)과 그 메서드(@selector(myMethod:))로 CustomTableViewCell에서 참조하게 할 수 있다. 이때 MyTableViewController의 참조를 retain해줘버리면 나중에 MyTableViewController이 dealloc 메서드가 호출될 시점을 읽어버릴 가능성이 100%가 된다. 왜냐하면 CustomTableViewCell에서 retain처리된 MyTableViewController의 객체를 다시 release할 수 있는 명확한 메커니즘을 추가하기 힘들기 때문이다. 그래서 이런 경우에도 retain이 아닌 assign을 사용함이 옳다.

조금 다르지만 NSTimer를 이용할때도 비슷한 경험을 할 수 있다. [NSTimer scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:] 메서드를 통해 target과 selector를 넘겨주는데 이때 내부적으로 NSTimer는 자기 자신과 target을 retain시켜주는 것 같다. 그래서 [timer invalidate] 호출해주지 않으면 target의 dealloc이 절대 호출되지 않는다. 역시 이 경우에도 메모리 릭이 발생한다. 그러므로  NSTimer를 시작하고 나서 멈추는 시점은 dealloc 내에서 하면 안되며 UIViewController의 경우 viewWillDisappear나 viewDidDisappear와 같은 메서드에서 invalidate를 호출해줘서 정상적으로 UIViewController의 객체의 dealloc 메소드가 호출되도록 해주어야 한다.

이외에도 굉장히 많은 경우도 메모리 릭은 항상 존재할 수 있다. 그래서 보통 일반적으로 통용되는 규칙을 잘알고 그대로 하는 것이 좋고 그렇게 하는 이유도 이해하면 크게 도움된다.

결국 위의 예제는 여기서 제공해주는 일종의 팁정도로만 생각하고 요점은 항상 dealloc 메서드가 호출되는지 확인하는 자세가 필요하다. 그렇게 되면 최소한 메모리 릭이 발생되는 최초 근본원인은 찾아낼 수 있을 것이다. 

종류가 다른 하나의 팁으로 정확한 원인은 모르겠지만 NSZombieEnabled를 사용 하면 EXC_BAD_ACCESS가 발생하지 않는데, 그것만 없애면  EXC_BAD_ACCESS가 발생하는 경우에는 dealloc 부분에서 디버깅을 해보면 어떤 객체에서 문제가 발생하는지 찾을 수 있다. 이 에러는 보통 과도한 release를 하는 경우 발생하는 것인데, 아무리 봐도 문제점을 찾을 수 없는 경우였다. 이런 경우 dealloc 메서드 내에 [super dealloc]를 실행문의 맨 뒤에 호출하도록 하면 문제가 없어지기도 한다.

그림이나 코드없이 말로만 줄줄 써서 이해가 잘 안갈 수도 있다. 결국 중요한 것은 dealloc이 제대로 호출되는지 항상 체크하라는게 여기서 말하고 싶은것이다.

글쓴이 : 지돌스타(http://blog.jidolstar.com/735)

위 화면은 UINavigationBar 를 보여주고 있습니다.
오른쪽을 보면 버튼이 3개가 붙어 있습니다.
어떻게 한것일까요? 저도 어떻게 할 수 있을까 무척 고민했습니다.
일단 저기에 뭔가 붙이려면 UIViewController에서 self.navigationItem.rightBarButtonItem = [[[UIBarButtonItem alloc]init...]autorelase]을 설정해주면 됩니다.

- initWithBarButtonSystemItem: target: action:
- initWithImage: style: target: action:
- initWithTitle: style: target: action:

위 함수중 1개를 선택해서 객체를 생성할 수 있는데 전부 1개만 넣을 수 있습니다. 2개 이상은 안되죠. 다행히도 아래와 같은 함수가 있습니다.

-initWithCustomView:

이 함수를 이용하면 UIView를 확장한 객체만 뭐든지 들어갈 수 있지요. 당연하지만 앞의 3개의 함수와 달리 버튼을 눌렀을때 액션을 취할 수는 없습니다. 이것은 커스터마이징 해야할 겁니다.

그럼 처음 위 Navigation Bar에서 보여준것처럼 하게 하려면 결국 UIView로 하면 됩니다.
하지만 UIView를 이용하면 위치를 일일히 지정하는 번거로움이 있어서 이런 경우에는 UIToolBar를 사용하면 되겠죠. 즉 아래처럼 하면 됩니다.

self.navigationItem.rightBarButtonItem = [[[UIBarButtonItem alloc]initWithCustomView:myToolBar]autorelease];

결과는 예~ 잘등록됩니다. ^^

하..지..만... 요래 됩니다.




당연하겠죠. UIToolBar 기본배경이 원래 저거니깐요.

이제 배경색만 지우면 되겠지 싶어
myToolBar.opaque = NO 도 해보고...
myToolBar.translucnet = YES 도 해보고...
myToolBar.backgroundColor = [UIColor clearColor] 도 해보고
myToolBar.tintColor = [UIColor clearColor] 도 해보고....

별짓을 다해봤지만.... 배경색이 지워지지 않더군요. 인터넷 뒤져봐도 투명으로 만드는 방법 말고는 설명된 것을 찾기가 어렵더군요. 그냥 UIView 확장해서 만들까 하지만 오기가 생겼습니다.

이리저리 찾아보다가.... 방법을 찾았습니다.

- (void) drawRect:(CGRect)rect {}

결국 위 함수를 오버라이드 해서 내부에 아무것도 정의하지 않으면 된다는 사실을 깨달았습니다.
말그대로 UIToolBar를 확장해서 아래처럼 아무 코드도 넣지 않으면 됩니다.

- (void) drawRect:(CGRect)rect {
    //이것으로 배경을 그리지 않는다.
}

그리고 내부적으로 아래와 같은 코드가 들어가야 합니다. init함수에 아래 코드를 넣으면 완성됩니다.

self.translucent= YES; 


저 버튼들을 눌렀을때 action은 어떻게 처리하냐고요? 그야 방법은 아주 많겠죠? 그건 나름 연구해보시길.... ^^

글쓴이 : 지돌스타(http://blog.jidolstar.com/728)
일반적으로 키보드를 감추기 위해  [myTextField resignFirstResponer] 메소드를 사용하실 겁니다.
UIViewController가 전환할때는 기존 ViewController에 떠 있던 키보드가 자동으로 감춰집니다. 

하지만  firstResponder의 출처를 찾기가 곤란한 경우도 있습니다. 가령.. 저의경우 
중간에 네트워크가 중지되거나 점검페이지등을 붙일때 Controller가 아닌 UIView를 직접 사용해 window의 최상위에 붙이게 되는 경우가 있는데, 이때 ViewController에 키보드가 보여져 있으면 이 페이지 위에 키보드가 그대로 남게 되는 경우가 발생합니다.

꼭 위와 같은 경우가 아니더라도 키보드가 어디를 기준으로 보이든지 감춰줄 수 있는 메서드가 필요했습니다.
저는 아래 메서드를 공통으로 사용할 수 있는 클래스(가령 AppDelegate)에 정의해놓고 언제든지 키보드를 감출 수 있도록 합니다.
여기서 호출할 메소드는 hideKeyboard  입니다. _hideKeyboardRecursion은 제귀함수로 직접 호출하지는 않습니다.

//키보드를 사라지게 하기 위해 사용하는 재귀함수 

- (void)_hideKeyboardRecursion:(UIView*)view 

{

if ([view conformsToProtocol:@protocol(UITextInputTraits)]) 

{

[view resignFirstResponder];

}

if ([view.subviews count]>0

{

for (int i = 0; i < [view.subviews count]; i++) 

{

[self _hideKeyboardRecursion:[view.subviews objectAtIndex:i]];

}

}

}


//키보드 감추기

- (void)hideKeyboard 

{

UIWindow *tempWindow;


for (int c=0; c < [[[UIApplication sharedApplication] windows] count]; c++) 

{

tempWindow = [[[UIApplication sharedApplication] windows] objectAtIndex:c];

for (int i = 0; i < [tempWindow.subviews count]; i++) 

{

[self _hideKeyboardRecursion:[tempWindow.subviews objectAtIndex:i]];

}

}

}


혹시 부족한 점 있으면 보완 부탁드릴께요. 

글쓴이 : 지돌스타(http://blog.jidolstar.com/727)

이 내용은 검색해도 제대로 나와 있는게 없어서 간단히 정리하여 공유하는 수준입니다.

 

APNS에 관심을 가지시는 분들이 많을겁니다.

APNS는 프로바이더가 Push서비스를 하기 위한 시스템 구축할 필요없이 Apple을 도움을 받아 구현할 수 있기 때문에 적은노력으로 최대한의 효과를 볼 수 있는 아주 유용한 서비스이지요.

 

APNS를 접하다 보면 헷갈리는게 있습니다.

 

Provisioing Portal에 들어가면 APNS가 2가지 종류라는 겁니다.

1. 개발버전

2. 배포버전

 

개발버전 APNS는 Provisioning Profile에서 Development와 연관 있습니다. 단순히 Xcode상에서 디바이스로 디버깅할때 유용합니다.

배포버전 APNS는 Provisioning Porfile에서 Distribution과 연관 있습니다. 이는 Adhoc이든 AppStore든 상관없습니다.

 

이렇게 구분된 이유는 저는 개발할때와 배포할때 APNS가 동일하면 발생되는 문제점을 해소하기 위함이라고 이해했습니다.

만약 개발과 배포시 APNS가 동일하다면 서비스하는 도중에 개발하면서 잘못된 APNS를 사용자들에게 보내버릴 수 있는 경우가 발생할 수 있습니다. 이러한 상황을 미연 차단한 것이라고 생각됩니다.

 

그럼... 두가지 버전의 명확한 차이는 무엇일까요?

 

첫째, 바로 발행하는 인증서가 다르겠죠? 인증서는 App ID에서 발행하므로 어플마다 다릅니다.

 

둘째, Device Token 값이 다릅니다. 개발버전의 Device Token과 배포버전(Adhoc, Appstore)의 Device Token은 다릅니다. 이것은 어플마다 다르지 않고 Device마다 다릅니다. 하지만 기기의 고유 UUID와는 다릅니다.

 

셋째, 그리고 프로바이더(java든, php든 상관없이) 입장에서 gateway 주소가 다릅니다. 개발버전에서는 gateway.sandbox.push.apple.com 에 접속하고 배포버전에서는 gateway.push.apple.com에 접속합니다. 포트번호는 둘다 2195이지요.

 

이 부분에 대해서 명확하게(그것도 한글로.. ^^;) 설명한 내용이 없었습니다.

제가 영어를 잘해서 Apple문서를 정독했더라면 알 수 있는 내용이였지만.... 결국 삽질끝에 파악한 내용이네요. ㅎㅎㅎ

 

아무튼 유용한 정보가 되었길...

 

다른 유용글

[iPhone/Java] 내가 만든 어플에 Push Notification 적용하기

APNS Device Token을 못받아올때

글쓴이 : 지돌스타(http://blog.jidolstar.com/724)

 

아이폰 개발시작한지 3~4개월 되어가면서 조금 감각을 익히기 시작했습니다. 
어플도 그동안 3개 만들어 올려보고요.  

물론 사운드, 그래픽을 고급스럽게 다뤄보지는 못했지만 기본 UI기반으로 개발할때도 워낙 이슈가 많다보니 학습과 개발을 병행하는게 정말 쉽지 않더군요.... 

각설하고요 ㅎㅎ

여기에 소개할 것은 UIImageView에 원격 이미지를 비동기로 로드할 수 있도록 하는 기능과 이미지 캐쉬 기능을 추가한 소스를 공개하려고 합니다.(소스 분석은 주석을 참고 ^^)

아이폰 어플 개발하면 UIImageView를 매우 많이 사용할 겁니다.  번들이미지의 경우야 어짜피 문제 없지만 원격이미지를 로드할때는  몇가지 이슈가 발생합니다.

1. 원격이미지를 매번 로드하는 것은 네트워크 부하를 일으키며 특히나 3G사용자들에게 치명적이 될 수 있다.
2. 테이블에 원격이미지를 붙이는 경우에 동기적으로 이미지 로드하는 경우 멈춤 현상을 일으킬 수 있다. 
3. 비동기적으로 이미지를 로드하더라도 한번에 로드할 수 있는 이미지를 제어하지 않으면 어플의 전체적인 퍼포먼스가 죽는다.
4. TableView에서 TableViewCell는 캐쉬처리되어 재사용된다. 그러므로 거기에 붙은 UIImageView도 재사용하게 되는데 스크롤을 빨리 넘기는 경우 기존에 로드 요청한 이미지가 하나의 UIImageView에 계속 적재되는 현상이 발생할 수 있다.

위 이슈에서 1, 2는 금방 이해갈 갈겁니다. 3번의 경우 1,2번의 처리가 잘되었다고 해도, 한 화면에 5개 이상의 이미지를 비동기적으로 로드한다는 것은 스레드를 5개 이상 생성해서 처리한다는 의미와 같습니다. 어플 하나에 스레드를 너무 돌리면 별로 좋지 못하기 때문에 동시에 로드할 수 있는 이미지를 제어해주어야 합니다. 1~2개 정도로요. 
4번 이슈의 경우 예전에 문씨님이 올려주신 [문씨의 강좌]멀티스레딩2<NSOperation>에 올린 글에 소개된 소스의 경우에 발생합니다. 저는 여기에 이미지 캐쉬기능만 넣어서 실제로 썼습니다. 하지만 TableView에서 문제가 발생했습니다. 분명 NSOperation을 이용한 이미지 로드는 2,3 문제를 해결해줍니다. 하지만 TableViewCell을 재사용되기 때문에 빠른 스크롤을 하는 경우 거기에 붙은 UIImageView 하나에  지속적으로 다른 이미지가 붙도록 요청이 되어 이미지가 광고롤링되는 현상마냥 보이는 경우가 발생합니다. 

1,2,3,4 번의 이슈를 모두 해결하고자 간단하게 클래스를 제작했습니다.

사용하는 방법은 너무도 간단합니다. 그저 UIImageView를 붙히고 (IB에서든 코드상이든) #import "UIImageView+AsyncAndCache.h"를  넣습니다. 그 다음 아래 UIImageView 카테고리 4개 함수중 하나를 쓰시면 됩니다.  UIImageView *imageView = [[UIImageView alloc]init]; 하신뒤 [imageView setImageURLString:@"이미지 원격 경로"]; 형태로 쓰시면 됩니다. 

UIImageView를 카테고리로 만들었으므로 기존 UIImageView 기능은 그대로 사용할 수 있겠고요.

UIImageView 카테고리 외에 내부적으로 2개의 클래스가 정의되어 있습니다. 이는 개발자가 직접 제어하지 않고 위 4개 이슈를 해결하기 위해 내부적으로 사용되는 클래스입니다. 소스 분석을 원하신다면 주석을 달아두었으니 참고하시면 되겠습니다.

아래는 header만 올려놓습니다. 구현부는 첨부파일을 참고하세요.

uiimageview asyncandcache.zip


ARC환경에서는 아래것을 사용하면됩니다.(오래된 글이라... 개선여지가 많습니다. )

UIImageView AsyncAndCache.zip



//

//  UIImageView+AsyncAndCache.h

//

//  Created by Yongho Ji on 10. 12. 3..

//  Copyright 2010 Wecon Communications. All rights reserved.

//


#import <UIKit/UIKit.h>


@class AsyncAndCacheImageOperator;

@class AsyncAndCacheImageOperatorManager;


//////////////////////////////////////////////////////////////

//

// UIImageView 대한 카테고리 

// 카테고리는 테이블뷰에 적용된 Cell안에 UIImageView에서 활용하면 좋다.

// UIImageView 주요 기능은 다음과 같다

//

// 1. 이미지 비동기 로드 

//   이미지를 비동기로 로드해서 화면에 이미지가 뜨는데 버벅거림을 없앤다.

// 2. 이미지 캐쉬기능 

//   이미 로드한 이미지는 cache 디렉토리에 캐쉬해서 나중에 반복 요청시 

//   로컬에 저장된 캐쉬 이미지를 로드해서 네트워크 부하를 없애준다.

// 3. 반복적인 이미지 요청에 대한 로드부하 최소화 

//    같은 UIImageView 중복으로 로드 요청한다면 마지막에 요청한 이미지가 적용되도록 한다.

//    그뿐 아니라 수십번 반복해서 요청하더라도 무조건 이미지 로드 요청하지 않고 되도록이면 

//   마지막 이미지를 로드요청하여 네트워크 부하를 줄여준다

// 

// 개선해야할 사항 

//

// 1. 캐쉬기능 강제삭제기능 

// 2. 지정된 시간이 지난 캐쉬 이미지 자동 삭제기능 

// 3. 캐쉬사용여부 결정기능  

// 

//////////////////////////////////////////////////////////////


@interface UIImageView (AsyncAndCache)


//String형태의 이미지 URL 초기화

-(id)initWithURLString:(NSString*)url;


//NSURL 형태의 이미지 URL 초기화 

-(id)initWithURL:(NSURL*)url;


//String형태의 이미지 URL 셋팅 

-(void)setImageURLString:(NSString*)url;


//NSURL 형태의 이미지 URL 셋팅 

-(void)setImageURL:(NSURL*)url;


//동시에 로드할 이미지 최대수  

+(void)setMaxAsyncCount:(NSUInteger)count;


@end


//////////////////////////////////////////////////////////////

//

// 한개의 ImageView 대한 오퍼레이터이다.

// 비동기적으로 로드하는 것을 지원하며 더불어 캐쉬기능까지 지닌다.

// 개발자가 클래스를 직접 사용하지 않는다.

// 클래스는 AsyncAndCacheImageOperatorManager 클래스에서 동작/관리한다.

//

//////////////////////////////////////////////////////////////

@interface AsyncAndCacheImageOperator : NSObject

{

NSURL *_url; //로드할 이미지의 URL 정보 

UIImageView *_imageView; //이미지를 적용할 View

BOOL _canceled; //이미지 적용을 막는다. UIImageView 재사용시 나중에 로드되더라도 이게 YES이면 적용하지 못하도록 해서 사용자들로 하여금 잘못된 이미지가 로드되는 것을 방지 한다.

id _loadCompleteTarget; //이미지 로드가 완료되었을때 호출할 target

SEL _loadCompleteSelector; //이미지 로드를 완료했을때 호출할 selector

}


@property (readonly) UIImageView *imageView;


//초기화 함수 

- (id)initWithURL:(NSURL*)url imageView:(UIImageView*)imageView;


//스레드 적용 함수 

- (void)main;


//이미지 적용 취소

//main 메서드가 실행중일때 스레드자체는 중단시킬 없지만 imageView 로드한 image 적용하는 것은 방지시킨다.

- (void)cancel;


//이미지 로드 완료후 호출할 target/selector 적용 

- (void)setLoadCompleteWithTarget:(id)target selector:(SEL)selctor;

@end


//////////////////////////////////////////////////////////////

//

// ImageView정보를 담은 여러개의 오퍼레이터(AsyncAndCacheImageOperator클래스 객체) 관리한다.

// 개발자가 클래스를 직접 사용하지 않는다.

// setMaxAsyncCount 이용해 한번에 로드할 있는 이미지 갯수를 설정할 있다.

// 중요한 것은 동일한 UIImageView 대해서 다른 이미지 로드 요청이 있는 경우 

// 마지막에 요청한 이미지가 붙도록 하며, 같은 UIImageView 이미지 로드 대기중인 경우에는 

// 이전 UIImageView 대한 Operator 삭제함으로써 부적절한 로드로 인한 네트워크 부하를 최소화 해준다.

//

//////////////////////////////////////////////////////////////

@interface AsyncAndCacheImageOperatorManager : NSObject

{

@private

NSUInteger _maxAsyncCount; //동시에 비동기적으로 로드할 이미지 갯수 

NSUInteger _currentAscynCount; //현재 비동기적으로 로드하고 있는 이미지 갯수 

NSMutableArray *_standByImageOperators; //대기중인 Image Operator

NSMutableArray *_loadImageOperators; //로드중인 Image Operator 

}


//한번에 로드할 있는 이미지 갯수(스레드 최대 갯수)

-(void)setMaxAsyncCount:(NSUInteger)count;


//오퍼레이터 추가 

-(void)addImageOperator:(AsyncAndCacheImageOperator*)imageOperator;


@end



제 소스는 많은 테스트는 거치지 못했습니다. 그러므로 여기 개발자 분들께서 필요하시다면 제 소스를 분석하고 수정하면서 개선해주셨으면 합니다.  

----------------------------
수정사항 1
http://cafe.naver.com/mcbugi/95095 에도 이 글을 올렸습니다.
역시 소스가 공개되니 많은 분들이 테스트도 해주시고 좋네요. 만약 이미지 경로가 image.php?ggg=465.jpg로 되어 있다면 ?ggg=465.jpg 부분을 제대로 가져오지 못하는 버그가 있더군요. [_url path]로 되어 있는 부분을 [_url absoluteString]으로 하면 괜찮다고 합니다. 수정해서 쓰세요. 

수정사항 2
초기에 이미지가 붙어 있는데 주어진 이미지 경로에 이미지를 못불러오는 경우 image = nil이 되기 때문에 초기 이미지를 지우는 부분으로 이상하시다는 분도 계셨습니다. 이 부분은 아래처럼 처리하세요.

if (_canceled==NO) 
{
// 이 부분 추가
if (image)
_imageView.image = image;
}

if (_loadCompleteTarget!=nil) 
{
[_loadCompleteTarget performSelectorOnMainThread:_loadCompleteSelector withObject:self waitUntilDone:YES];
}


수정사항 3
이미지가 제대로 로딩이 안되는 버그가 있는데 메인스레드 관련 문제 때문입니다. 아래처럼 수정하세요.

if (_canceled==NO) {

    dispatch_sync( dispatch_get_main_queue(), ^{

        _imageView.image = image;

        [_imageView performSelector:@selector(layoutIfNeeded) withObject:nil];

    });

}


글쓴이 : 지돌스타(http://blog.jidolstar.com/723)


개인적으로 Flex, ActionScript 3.0 기반에서 개발을 오래도록 해와서 그런지 아이폰의 통지(Notification) 사용법이 꽤 낫설더군요.
그래서 ActionScript 3.0에서 사용되는 Event기반과 비슷하게 한번 만들어 봤습니다.

Event와 Notification은 비슷합니다.  하지만 사용하는 인터페이스가 불편함이 느껴졌습니다.

간단히 개념 설명이 들어가면... 
제가 만든 Event는 다음과 같은 용어를 씁니다.
1. 이벤트 송출자 ( Event Dispatcher)
2. 이벤트 (Event)
3. 이벤트 청취자 (Event Listener) 

이벤트는 데이터입니다. 이벤트가 발생(송출)할때 이벤트명,이벤트송출자,이벤트데이타를 담는 역할을 합니다. 이벤트는 이벤트 송출자가 만들고 이벤트 청취자가 받습니다.

이벤트 송출자는 이벤트를 만들어 보내는 역할을 합니다. 보낼때 이벤트를 송출하는 객체, 이벤트명, 그리고.. NSObject를 확장한 데이터를 담은 객체를 하나로 묶은 이벤트를 만들어주고 등록된 이벤트 청취자중 같은 이벤트명으로 등록된 청취자에게만 이벤트를 전달합니다. 

이벤트 청취자는 송출된 이벤트를 받습니다. 이벤트 청취자는 target/selector 를 지칭하며 청취자 등록시 함께 등록하는 이벤트명에 따라 실행됩니다. 즉, 이벤트 송출시 보내지는 이벤트명과 등록된 청취자의 이벤트 명이 같아야합니다. 반대로 이벤트 명이 다르면 절대 호출되지 않습니다. 


다음은 만들어진 소스의 header 코드입니다. 

//

//  Event.h

//

//  Created by Yongho Ji on 10. 10. 25..

//  Copyright 2010 Wecon Communications. All rights reserved.

//

// 이벤트를 다룬다. 내부적으로 Notification 기능을 한번 감싼형태이다

// 이렇게 만드는 이유는 호스트코드에서 쉽게 사용할 있게 하기 위함이다.

//


#import <Foundation/Foundation.h>


//=================================================

//

// 이벤트 

// 1. 내부 생성클래스이다

// 2. 개발자가 직접 생성하지 않는다.

// 3. 개발자는 등록된 이벤트 청취자로부터 이벤트 객체를 받게 되어 있다

//

//=================================================



@interface Event: NSObject

{

@private

id _dispatcher; // 이벤트 송출자

id _data; // 이벤트 데이타 

NSString *_eventName; // 이벤트  

}


@property (nonatomic, readonly) id dispatcher;

@property (nonatomic, readonly) id data;

@property (nonatomic, readonly) NSString *eventName;


@end



//=================================================

//

// 이벤트 청취자 

// 1. 내부 클래스이며 외부 노출되지 않는다.

// 2. 이벤트 청취 목록을 관리하기 위한 클래스이다

//

//=================================================

@interface EventListener : NSObject

{

@private

id _listener; //이벤트 청취자 

SEL _selector; //이벤트 청취자의 selector

NSString *_eventName; //이벤트 이름 

}


@property (readonly) id listener;

@property (readonly) SEL selector;

@property (readonly) NSString* eventName;


-(id)initWithListener:(id)listener selector:(SEL)selector eventName:(NSString*)eventName;

@end


//=================================================

//

// 이벤트 센터

// 1. 싱글톤 클래스이다.

// 2. [EventCenter defaultCenter] 접근해서 사용한다.

// 3. 이벤트 청취자 등록은 [[EventCenter defaultCenter]add:self selector:@selector(mySelector:) eventName:@"MY_EVENT"] 형태로 한다.

// 4. 이벤트 청취자 삭제는 3가지가 있다

//   - 1개의 이벤트 명에 대한 청취자 삭제 [[EventCenter defaultCenter] remove:self selector:@selector(mySelector:) eventName:@"MY_EVENT"] 형태로 한다.

// - 여러개의 이벤트 명에 대한 청취자 삭제 [[EventCenter defaultCenter] remove:self selector:@selector(mySelector:)] 형태로 한다.

// - 모든 이벤트 청취자 삭제 [[EventCenter defaultCenter] remove:self] 형태로 한다.

// 5. 이벤트 발송은 2가지 방법이 있다.

// - 데이터가 미포함된 이벤트 : [[EventCenter defaultCenter] dispatch:self eventName:@"MY_EVENT"] 

//   - 데이터가 포함된 이벤트 : [[EventCenter defaultCenter] dispatch:self eventName:@"MY_EVENT" data:myData]

//   - 데이터는 NSObject 확장한 것이라면 어떤 것이든 보낼 있다

//   - 이벤트가 발송되면 해당 이벤트 이름으로 등록된 모든 이벤트 청취자를 실행한다.

// 6. 이벤트 청취자는 listener selector 한묶음으로 본다. selector -(void)mySelector:(Event*)event; 또는 -(void)mySelector; 형태로 만들면 되겠다

//   , 인자로 Event객체가 오면 속성값에 dispatcher(이벤트를 발생한 ), eventName(이벤트명), data(이벤트시 보낸 데이타) 참조할 있다.

// 7. UIViewController기반에서 이벤트 등록과 삭제는 반드시 각각 viewWillAppear, viewWillDisappear에서 하도록 한다. 왜냐하면 등록된 이벤트 청취자 관리를 못하면 중복 호출이 있다.

//=================================================

@interface EventCenter : NSObject {

NSMutableArray *eventListeners;

}


//이벤트 기본 Center. 싱글톤 처리 

+(EventCenter*)defaultCenter;

//이벤트 청취자 등록 (중복된 등록은 무시됨)

-(void)add:(id)listener selector:(SEL)selector eventName:(NSString*)eventName;

//이벤트 청취자 삭제. selector, eventName 상관없이 같은 listener 등록되어 있으면 모두 삭제. 이미 삭제되어 있다면 무시

-(void)remove:(id)listener;

//이벤트 청취자 삭제. eventName 상관없이 같은 listener, selector 등록되어 있으면 모두 삭제. 이미 삭제되어 있다면 무시

-(void)remove:(id)listener selector:(SEL)selector;

//이벤트 청취자 삭제. listner, selector, eventName 모두 같아야 삭제된다. 이미 삭제되어 있다면 무시.

-(void)remove:(id)listener selector:(SEL)selector eventName:(NSString*)eventName;

//이벤트 송출. 데이터 미포함 

-(void)dispatch:(id)dispatcher eventName:(NSString*)eventName;

//이벤트 송출. 데이터 포함

-(void)dispatch:(id)dispatcher eventName:(NSString*)eventName data:(id)data;

@end


총 3개의 클래스로 구성되어 있으나 이벤트 송출자 등록, 이벤트 청취자 등록, 이벤트 송출은 모두 EventCenter 클래스가 관장하며, EventCenter는 싱글톤 처리되어 [[Event defaultCenter] ...] 형태로 접근이 가능합니다.

내부적으로 NSNotification을 한번 감싸서 통지를 이벤트로 추상화처리 한 것입니다. 

아마도 Objective-C의 NSNotification 또는 ActionScript의 Event를 사용해보신 경험이 있는 분은 별다른 설명없이도 이 소스를 그냥 가져다가 쓸 수 있습니다.

사용법은 주석으로 간단하게 적어두었습니다. 주의사항도 꼭 확인하시고 사용하시면 됩니다.

개선사항이나 버그가 있다면 댓글 부탁드리겠습니다. ^^

소스는 첨부합니다.


----------------------------------------------
사용법을 문의하시는 분들이 계시네요.  소스도 공개했구 주석처리 다했는데 ^^;;
기본적으로 Notification을 이해하시면 Event도 이해할 수 있습니다. 
그래도 사용하시는데 어려움을 겪으시는 것 같아 간단하게 예제를 들어보지요.

1. 이벤트명 정의 
#define EVENT_WRITE @"eventWrite"

2. 이벤트 발생 
DispatchClass 안에서 아래처럼 코딩합니다.

[[EventCenter defaultCenter]dispatch:self eventName:EVENT_WRITE data:postData];

3. 이벤트 청취 메소드 정의 
ListnerClass 내부에서 아래처럼 정의합니다.

-(void)_myMethod:(Event*)event
{
 PostData *postData = (PostData*)event.data;
 NSLog(@"eventName=%@,  dispatcher=%@",event.eventName, event.dispatcher);
}

4. 이벤트 청취자 등록 
ListenerClass 내부에서 아래처럼 정의합니다. 단 정의시에는 viewDidLoad가 아닌 viewWillAppear나 viewDidAppear등에서 하시는게 메모리 관리가 가능합니다.
[[EventCenter defaultCenter]add:self selector:@selector(_myMethod:) eventName:EVENT_WRITE];

5. 이벤트 청취자 삭제 
ListenerClass 내부에서 아래처럼 정의합니다. 단! dealloc에서는 하지 마세요. 왜냐하면 등록한 listener 내부적으로 retain되기 때문입니다. viewWillAppear등에 add 하셨다면 viewWillDisappear에서 하시면 됩니다. add로 등록하지 않아도 삭제한다고 문제되지 않으니 메모리 관리를 위해서 꼭!!! remove는 호출하셔야 합니다.
[[EventCenter defaultCenter]remove:self selector:@selector(_myMethod) eventName:EVENT_WRITE];

삭제방법은 총 3가지죠. 위 코드는 이벤트에 대한 등록한 청취자 1개만 삭제할때 씁니다. 
하지만 ViewController가 더이상 쓸모가 없어진다면 
[[EventCenter defaultCenter]remove:self] 만 하셔도 self에 정의된 모든 이벤트 청취자를 삭제해줍니다. 



이상입니다. 더 개선할 사항에 대한 아이디어가 있다면 언제든지 답글주세요. ^^

글쓴이 : 지돌스타(http://blog.jidolstar.com/721)



오랜만에 오픈캐스트를 올렸습니다. 즉흥적으로 만든거지만 유용하리라고 생각합니다.

좋은 정보가 되길 바랍니다.

http://opencast.naver.com/FL188/18

글쓴이 : 지돌스타(http://blog.jidolstar.com/694)

애플이 아이패드를 발표하면서 Flash Player 지원을 공식적으로 거부했습니다.
그 이후로 엄청난 논란이 있는 가운데...
Adobe CTO 케빈 린치는 다음 처럼 의견을 제시했습니다.

Adobe 케빈 린치의 '컨텐츠 및 애플리케이션에 대한 오픈 액세스

아무튼 이런 상황에서 아래와 같은 기사도 올라왔네요.
한번 읽어보시고 각자의 의견을 들어보는 것도 좋을 것 같아요. ^^

---------------------------------------------------------------------

[원문]
http://online.wsj.com/article/SB20001424052748703546004575055184080144688.html


[월 스트리트 저널(Wall Street Journal)]


애플(Apple)의 마이크로소프트(Microsoft)화?


2010.02.09 / 홀먼 W. 제킨스 주니어(Holman W. Jenkins, Jr.)


애플은 증오적 라이벌 관계로 인해 제로섬 전략에 집착하는 회사로 전락할 위험에 놓여있습니다.

현재를 언급하는 것이 아니라 애플의 시가총액이 상상할 수 없는 규모에 달하여 마이크로소프트의 시가총액을 뛰어넘는 해의 이야기가 될 수 있습니다. 당연히 축하 인사가 따르겠지만 위로의 말도 함께 따를 것입니다. 제품 개발에만 전념하는 회사의 경우 전략에 집착하는 회사가 될 위험의 소지가 있기 때문입니다. 그리고 여기서 “전략”이란 증오적 라이벌 관계로 인한 제로섬 전략을 의미합니다.

안타깝게도 현재 우리는 신뢰를 찾기 힘든 타락한 세상에 살고 있습니다.

아이패드(iPad)의 예를 들어보겠습니다. 아이패드는 세상에 공개되자마자 “구세주 태블릿”이라는 별명을 얻었습니다. 아이패드는 상상하지 못할 만큼 탁월한 제품이 아닌 단지 애플이 넷북 경쟁에 뛰어들기 위해 출시한 제품으로, 아이팟 터치(iPod Touch)를 확대해 놓은 버전에 불과합니다. 아이패드는 최상의 웹 브라우징 시스템으로 부각될 수 없을 수도 있습니다. 왜냐하면 애플이 웹 상에서 비디오를 전달하는 데 75% 가량 사용되고 있는 플래시(Flash) 지원을 거부했기 때문입니다. 그러나 아이패드(iPad)(‘지불’이라는 영어 PAID의 철자 순서를 바꾸어 만든 말)는 애플의 온라인 서비스를 통해 판매되고 있는 e북, 음악 및 비디오를 사용하기에는 적합한 디바이스로 보입니다. 단도직입적으로 말하자면 아이패드는 마치 아이튠즈(iTunes) 스토어를 후원하기 위해 최적화된 디바이스로 보입니다.


그렇다면 왜 애플은 플래시를 제외시키기로 결정했는지 궁금하지 않을 수 없습니다. 애플과 애플의 후원업체들은 플래시가 짜증나는 웹 광고를 만드는데 사용되는 제품이라는 미학적이고 철학적인 이유를 내세우고 있습니다.


애플이 플래시를 거부하는 이유는 바로 여기에 있습니다. 플래시를 사용하면 아이폰(iPhone) 및 아이패드 사용자는 아이튠즈를 통하지 않고 비디오 및 기타 엔터테인먼트를 사용할 수 있을 것이고 애플 앱 스토어(Apple App Store)에서만 현재 구입할 수 있는 다양한 기능을 무료로 얻을 수 있게 됩니다.


네트 중립성 옹호자들이나 독점 금지법 집행자들이 스티브 잡스(Steve Jobs)를 연행해가는 오류를 범하지 않도록, 한 가지 덧붙이자면 애플은 플래시를 거부할 수 있는 적법한 권리를 가지고 있습니다. 그러나 한 가지 짚고 넘어가야 할 것은 애플은 엄청난 양의 웹 컨텐츠와 사용자를 분리시키려는 전략적 선택을 내세우고 있다는 점입니다. 플래시가 버그를 부른다는 주장 등에 대해 플래시 옹호자의 시점에서 잠시 벗어나 설명해 보겠습니다. 플래시는 다른 비디오 플레이어와의 시장 경쟁에서 우위를 점하고 있으며 10억 명에 달하는 PC 사용자가 정기적인 업데이트를 다운로드하고 있다는 사실은 엄청난 성공이라고 해도 과언이 아닐 것입니다. Hulu.com에서 TV 프로그램을 시청하거나 MLB.com에서 야구 경기를 보거나 Facebook을 통해 친구와 커뮤니케이션할 때에도 플래시가 필요합니다.


현재로선 플래시를 소유하고 있는 어도비는 최소한 플래시 프로그래머가 애플의 앱 스토어를 통해 자신이 개발한 컨텐츠나 애플리케이션을 제공할 수 있도록 몇 가지 툴을 출시하고 있다고 말하고 있습니다. 이것도 애플의 축복이 있어야 가능할 것입니다. 그러나 애플은 미래의 웹 표준은 독점적인 플래시를 대체하게 될 것이라고 주장하고 있습니다. 이것은 지켜봐야 할 일입니다. 플래시는 현재 전세계 95%의 PC에 설치되어 있어 하루 아침에 웹 표준이 바뀔 가능성은 극히 희박합니다. 또한 파이어폭스(Firefox) 같은 브라우저 제작업체 모두가 애플이 말한 새로운 표준과 생각을 함께 하고 있는 것도 아닙니다.


더 크게 우려되는 바는 여기에 있습니다. 애플이 이러한 무모한 목표로 인해 자사의 모바일 디바이스 사용자층을 확대하여 단지 더 많은 사용자가 아이튠즈만 이용하도록 사용자를 가두는 “네트워크 효과”의 매혹적인 유혹에 무릎을 꿇을 수 있다는 점입니다. 애플은 최근까지 제휴 관계를 유지했던 구글(Google)과 전면전에 돌입했습니다.


지난달 말  애플 직원과의 미팅에서 스티브 잡스가  “지금까지 애플은 검색 시장에서 구글과의  경쟁을 피하기 위해 노력했지만 ‘아이폰  타도’ 를 위해 자사의 모바일 디바이스르  출시했다.” 면서 “사악해지지 말자(Don't be evil) " 라는 구글의 모토를 폄하한 발언이 일파 만파 퍼졌습니다.


구글폰으로 인해 아이폰이 없어지지는 않을 것입니다. 시장은 수많은 모바일 디바이스를 수용할 수 있는 여건을 충분히 갖추고 있습니다. 그러나 실제 위협이 되는 것은 수천만 명의 소비자를 앱 스토어인 아이튠즈만 이용할 것을 주입시킬 수 있는 애플의 능력입니다. 구글이 아이패드가 공개되기 며칠 전 자사의 슬레이트 모양의 디바이스 모델을 발표한 것은 의미 있는 행보였습니다. 구글의 모바일 디바이스는 플래시를 지원하고 있습니다. 애플 사용자가 사용할 수 없는 비디오 및 기타 웹 기능을 사용자가 구매하거나 사용할 수 있도록 했습니다.


애플이 아이폰에서 구글을 대체하기 위해 마이크로소프트의 검색 엔진인 빙(Bing)과 거래를 고려하고 있다는 소문이 돌고 있습니다. 또한 애플이 광고 사업에도 뛰어들어 구글의 서비스와 경쟁하기 위해 클라우드 서비스를 확대할 것이라는 소문도 들리고 있습니다. 어디서 많이 들어본 스토리 아닌가요?


네트워크 효과는 권력과 부를 가져오는 방법이 될 수는 있지만 마이크로소프트의 사례에서 볼 수 있듯이 너무 많은 성과는 특권의 지위를 유지하기 위한 방어적이고 망상적 시도로 인해 물거품이 될 수 있습니다. 회사의 최고 심미가이자 완벽주의자가 더 이상 정상적인 의사 결정을 내리지 못하게 되면 과연 애플은 어떤 회사가 될 것인지 많은 전문가들은 의문을 가지고 바라보고 있습니다. 애플이 점점 더 많은 사용자들에게 아이튠즈 앱 스토어만 사용할 수 있는 질이 나쁜 디바이스를 출시하는 회사로 전락되지 않을까 우려되는 바입니다.
 

+ Recent posts