바른생활(http://blog.jidolstar.com/746)은 아이폰/아이팟터치(안드로이드용도 마켓에서 직접 다운로드 받을 수 있습니다.)용으로 개발되어 다이어트, 운동, 공부등과 같은 일상적으로 세우는 계획을 실천할 수 있게 도와주는 기능을 가집니다.  간단히 일자별로 자신의 계획을 체크하고 일지도 작성해가며 같은 관심사를 가진 사람들과 커뮤니케이션을 할 수 있는 구조로 되어 있죠. 하루에 한번씩 계획체크 푸쉬도 날려주고요. 더 많은 기능을 넣는 것도 고려했지만 사용자 필요성을 좀더 파악한 다음에 하기로 결정한 상태라서 일단 보류했습니다.

얼마전 아이폰용 바른생활 어플이 무료순위에 상위에 올라왔습니다.  신기한 것은 이 어플은 무려 1개월 전에 앱스토어에 등록되었던 것인데 무료상위권에 들어간것이 너무 신기했었죠. 알고 봤더니 앱스토어 메인화면에 최신 및 추천목록에 올라왔더군요. 어떠한 경로로 여기에 올라가게 된 것일까요? 최신은 분명 아니므로 이 화면에 대한 수동적 관리가 있었던 것으로 판단이 됩니다.  또는 앱스토어 자체에 추천시스템이 어느정도 작용도 했겠죠?

아무튼 어플을 홍보할 수 있는 마케팅 채널을 여러군데 있지만 거의 모두 돈을 들여야 합니다. 그나마 무료이면서 강력한 마케팅 영역은 앱스토어일겁니다. 초반에 상위에 못올라가면 다시 순위에 올라가기 힘든데, 이렇게 올라간 것을 보면 새학기가 시작되면서 이런 어플에 대한 필요성이 있다고 판단이 되었나봅니다. 아주 간단한 어플이지만 최소한의 기능으로 최대한의 효과를 내게끔 만들었던 것이 추천이 될 수 있었던 결정적인 요인이 아니였나 생각합니다. 결국 사용자는 복잡한 어플 싫어합니다. 그렇다고 너무 단순한 것도 싫어하죠. 어느정도 목적에 부합하는 어플이라면 사용자들은 이용해줍니다. 

이번 경험이 다음 어플을 만들때 결정적인 고려사항을 준것이라고 볼 수 없지만 그래도 많은 생각을 하게 만들어 준 것 같습니다.  바른생활 어플을 사용하시는 분들께 부족함에도 잘 사용해주셔서 감사의 말을 여기에 대신하고 싶습니다. ^^

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

★★★★★ 바른생활 ★★★★★
매번 계획만 하는 당신, 실천하게 만들어드립니다!

■ 체크캘린더 ■

매일매일 새해 계획의 성공/실패를 캘린더에 체크하세요!

체크캘린더를 보면서 하루하루 성취감을 느껴보세요.


■ 계획일지 ■

하루하루 계획에 대한 일지를 작성할 수 있습니다!

일지를 쓰면서 나의 계획에 대한 다짐을 곱씹어보세요.


■ 푸시알림 ■

매일 푸시알림으로 나의 계획을 상기시켜드립니다!

바른생활은 꾸준히 계획을 실천할 수 있도록 돕는 최고의 도우미랍니다.


■ 커뮤니티 ■

모든 일은 혼자하면 힘들고 포기하게됩니다. 하지만 우리에겐 동지가 있습니다!

계획 별로 커뮤니티를 지원하여 같은 계획을 가진 사용자와 만나세요.

서로 격려하고, 정보를 교류하면 모두가 승리할 수 있습니다!

[바른생활]어플로 실천하는 사람으로 다시 태어나세요!


■ (구)작심삼일 업그레이드 기능 ■

1. 내 마음대로 계획 추가하기
2. 계획 시작일 설정기능
3. 편리해진 홈화면 인터페이스
4. 계획 일지쓰기 추가

(작심삼일 아이디로 로그인 할 수 있습니다)


■ 다운로드 ■ 
아래 주소에 접속하시면 '바른생활' 어플을 무료로 다운로드 받으실 수 있습니다.

아래 QR 코드로 접근하셔도 다운로드 받을 수 있습니다.




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

*** 스타플 계정으로 연동되는 어플









스타플 타임라인 모바일 업로더 출시했습니다.

감성 SNS 스타플(starpl.com)에서 제공하는 타임라인(timeline.starpl.com)을 모바일로 즐기세요!
아이폰으로 촬영한 사진과 글을 언제 어디서든 업로드할 수 있습니다.


* PC에서 이용하시면 놀라운 타임라인의 모습을 볼 수 있습니다.(http://timeline.starpl.com)
* 스타플 계정으로 로그인 할 수 있습니다.
* 추후 지속적인 업데이트로 다양한 기능을 제공할 예정입니다.


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


다운로드 받기
아래 주소로 접속하시면 다운로드 받으실 수 있습니다.


QR코드로 다운로드 받기
아래 QR코드로 접속하시면 앱스토어에서 다운로드 받으실 수 있습니다.



스크린샷








스타플에서는 이외에도 여러가지 어플을 출시해 운영하고 있습니다.


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


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

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

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

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

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

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

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



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


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

스크린 샷입니다.








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

최근 아이폰 어플을 공부하고 개발하고 배포까지 하면서 개발시 꼭 체크하거나 염두해야할 일을 생각나는데로 정리해 보았다. 

 

1. 메모리는 항상 관리한다.

Instruments를 이용해 Memory leaks를 반드시 한다. 특히 View Controller가 전환시, 또는 데이터 통신후에 체크하도록 하는 것이 중요하다. Instruments를 이용하면 완벽하지 않지만 문제를 해결할 수 있는 발판을 마련해준다.

 

또한 Build만 해보지 말고 Build and Analyze를 통해 잠재적으로 메모리 leaks가 생길 부분을 찾도록 한다. 완벽하지 않지만 retain후 release를 안한 부분도 은근히 잘 찾아주므로 꼭 활용하길 바란다.

 

2. 디바이스 테스트는 필수

아이폰 시뮬레이터에서 동작을 잘하던 것이 디바이스에서 테스트 하면 중간에 멈추던가 이상한 동작할 하는 경우가 발생한다. 거의 대부분 이것은 메모리 문제이다. 디바이스는 제한된 메모리이기 때문에 메모리 경고가 자주 일어난다. 또한 이러한 메모리 문제는 View Controller에서 viewDidLoad 메소드를 다시 호출시켜 그에 따른 대책을 마련하지 않으면 어플이 죽거나 이상한 동작을 하게 된다.

 

디바이스에서 테스트는 개발 중간중간 자주 해야한다. 그렇지 않고 시뮬레이터에서만 개발하다가 디바이스에 올린뒤 발생하는 문제를 해결하려면 노력이 배 이상이 들 수 있다.

 

 

3. Memory Warning을 지나치지 말아라.

일단 아이폰 시뮬레이터의 메뉴를 보면 강제적으로 메모리 경고를 줄 수 있다. 그렇게 되면 AppDelegate와 View Controller에서 메모리 경고를 감지할 수 있게 된다. 경고가 발생하면 필요없는 자원을 해제 시키길 바란다. 또한 View Controller에서는 viewDidUnload 메소드가 호출될 수 있다. 이때 self.myView = nil 처리가 되어 있으면 이 객체는 메모리 반환이 되고 나중에 viewDidLoad와 viewWillAppear 호출된다. 이 때 중복된 메소드 호출이나 잘못된 메모리 반환으로 어플이 중간에 중지되거나 이상한 데이터를 View상에 보여주게 된다. 이런 처리도 말끔하게 해주어야 된다. 결국 View Controller의 라이프 사이클을 잘 이해하는 것이 중요하고 그에 따라 대처해야한다.

 

 

4. 인터페이스 빌더를 잘 활용하자.

개발자이기 때문에 인터페이스 빌더를 사용안하고 오로지 코딩으로 뷰배치를 하시는 분들이 있다. 초반에 아이폰 개발때는 이 방법이 좋을 수 있다. 무언가 코드안에서 다 해결할 수 있기 때문이겠다. 하지만 아이폰과 같은 작은 기기의 어플들은 긴 기간의 개발을 요구될 수 없다. 짧은 기간안에 빠른 승부를 내야하는게 바로 아이폰 어플이라고 본다. 뭔가 View 구성을 코드로만 하다 보면 개발자는 나중에 지쳐버린다. 한 페이지 View를 만드는데 만해도 엄청난 노력이 들어가야 한다.

 

인터페이스 빌더를 이용해 ViewController 단위로 만들고 TableView에 보일 Cell들도 만들면 여러분은 어느정도 View 구성하는 스트레스에서부터 해방될 수 있다. 완벽하지 않지만 복잡한 배치를 위해 골머리 쌓는 일에서는 거의 70~80% 해방된다. 게다가 ViewController의 코드도 많이 짧아진다. 왜냐하면 View를 구성하기 위한 코드가 많이 줄기 때문이다.

 

또한 인터페이스 빌더를 이용하면 Command+R 만으로 시뮬레이터에서 View를 미리 볼 수 있다. 이런 것들을 활용하면 개발에 많이 도움된다.

 

 

5. SVN을 이용한 소스 관리를 꼭 하자.

개발하면서 소스관리 툴하나 쓰지 않는다는 것은 사실 말이 안된다. Eclipse와 같은 툴을 다뤄봤던 사람이라면 소스관리를 위해 SVN을 많이 사용했을 것이다. 협업을 위한 것도 있지만 개인적으로 쓰더라도 소스 관리는 반드시 필요하다. Xcode는 기본적으로 SCM 기능이 있어 이것으로 소스관리가 가능하다. Eclipse에 비해서 많이 불편한 편이지만 익숙하면 쓸만하다.

 

6. 최적화에 만전을 기하자.

아이폰은 데스크탑과 다르게 제한된 메모리, 제한된 CPU 기반이다. 그러므로 이런 제한된 환경에서도 부드럽게 동작하도록 노력해야한다. 가령 이미지를 프로세싱 하더라도 cache처리를 해야할지 말아야 할지, Thread나 Operator를 이용해 데이터를 가져오거나 말아야할지 등을 잘 결정해서 개발해야한다. 까페에 문씨님이 올린 Operator 활용법을 참고하면 좋겠다.

 

7. 다양한 장치에서 구동되도록 하자.

애플 개발 정책(?)상 xcode를 배포하면서 번들로 있는 SDK는 항상 최신을 유지한다. 그래서 구버전의 아이폰이나 아이팟 터치에 동작하도록 만들 필요가 있다. iOS 4 기반으로 개발하더라도 약간의 옵션 조정으로 3.0, 3.1 에서도 동작하도록 할 수 있다. 그것은 Groups & Files에서 어플의 이름을 선택한뒤 info에서 Build 탭을 선택한다. 거기서 iOS Deployment Target을 iOS 3.1 등으로 맞추면 가능하다. 물론 SDK 상에서 상위버전시에만 구동이 되는 부분에 대해서는 따로 조치를 취해야 하며 장치 구성상 전혀 사용할 수 없는 부분은 아에 AlertView등으로 알려줘야한다. 가령 카메라의 경우 구형 아이팟터치는 동작하지 않듯이 말이다.

 

8. [myObject release]; 후에는 반드시 myObject=nil 을 하자.

@property로 지정된 속성의 경우 self.myObject = nil 하는 것만으로도 [myObject release];myObject=nil; 이 진행된다. 하지만 속성이 @property로 지정되어 있지 않은 경우에는 self.myObject로 접근할 수 없으므로 release만 할 수 있다. 하지만 [myObject relase];만 하면 문제가 발생할 수 있다. 가령, release를 한뒤 retainCount가 0가 되면 이것은 이제 좀비가 된다. 이 좀비객체에 어떠한 메시지를 보내면 무조건 어플 죽는다. 하지만 myObject=nil 처리하면 nil에 어떤 메시지를 보내도 무시해버린다. 이러한 문제는 좀처럼 눈에 보이지 않게 어플을 죽게하는 요인이 된다. 정상적인 상황에서는 이런 문제가 안생기는데, 디바이스에 물려서 돌리면 어플 죽은 범인이 여기에도 있다. 왜냐하면 디바이스는 제한된 메모리로 waning이 빈번하게 날 수 있고 그에 따라서 viewDidLoad등이 다시 호출되면서 좀비가된 myObject를 엑세스해버리는 현상이 발생할 수 있기 때문이다. release후 다시 새로운 객체로 할당해 retain 하더라도 그냥 버릇처럼 [myObject release];myObject=nil; 이런식으로 하는게 좋다.

 

 

이외에도 많겠지만 일단 생각나는데로 정리해보았다.


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

#ifdef ~ #else ~ #endif 
#define 

위 구문은 C, C++ 계열을 경험한 분들이라면 익숙한 내용일겁니다.
Xcode상에서 이것을 적절하게 활용하는 방법을 간단히 소개합니다.

커스텀 로그출력 

#ifdef USE_LOG

#define NSLog( s, ... ) NSLog(@"%s(%d) %@", __FUNCTION__, __LINE__, [NSString stringWithFormat:(s), ##__VA_ARGS__])

#else

#define NSLog( s, ... )

#endif


위 코드처럼 사용한다면 USE_LOG가 정의되어 있으면 그 안에 있는 #ifdef~ #else 안에 정의된 #define 매크로가 사용되어집니다.  
즉 NSLog()사용시 커스터마이징된 NSLOG()로 출력해줍니다. USE_LOG가 정의되어 있지 않다면 #else ~ #endif내의 #define 매크로가 사용되어 지며  NSLog()를 사용한 모든 코드는 전부 무의미하게 만듭니다. 

이런 형태로 정의한 이유는 개발할때는 분명 상세한 로그가 필요하지만 배포시에는 필요없기 때문입니다. 개발시에 따로 커스터마이징된 NSLog를 사용하는 이유는 디버깅시에 좀더 상세한 로깅이 필요하고 NSLog()를 코딩하느라 힘빼지 않고도 단순히 원하는 내용만 삽입해도 어느 함수에서 실행된 건지, 몇번째 라인인지 등의 내용도 함께 출력해줄 수 있습니다. 

위 코드는 *.pch 에 넣어두시면 작성된 모든 코드에 적용됩니다. 꽤 유용하겠죠?


로컬,원격 접속 제어

#ifdef LOCAL 

#define _DEFAULT_URL @"http://localhost:8080"

#else

#define _DEFAULT_URL @"http://gateway.jidolstar.com"

#endif


위 방식의 경우 배포/개발에 상관없이 로컬테스트, 원격테스트를 각각 진행하고 싶을때 유용합니다. 가령, 일반 Debug시에는 로컬에서 테스트 해야하므로 LOCAL이 정의되어 있어야 합니다. 하지만 앱스토어에 올리는 경우라면 정의될 필요가 없는겁니다. Debug시더라도 Debug Local, Debug Remote로 나누어 관리할 필요도 있고 또는 배포라도 테스트 배포를 위해 Adhoc을 사용하는 경우는 Local, Remote로 나눠서 배포할 필요도 있을겁니다. 이럴때 이 방법은 유용합니다. 이 코드 또한 *.pch에 넣어두시면 됩니다.


사용방법
위 2가지 코드의 의미와 활용에 대해서는 언급했습니다. 하지만 구체적으로 어떻게 XCode상에 설정해야 저 코드를 사용할 수 있는지  설명하지 않았습니다.  

초반 프로젝트에 대한 Info에서 Build에는 Debug와 Release 설정만 있을겁니다.  Adhoc및 AppStore로 배포하기 위해서 이 설정을 두개 더 늘려 Debug, Release, Distribution Adhoc, Distribution AppStore 를 만들겁니다. 사실 위에서 언급한 내용이 없다면 이 정도로만 가져가셔도 테스트, 배포는 문제없습니다만...  로컬/원격 테스트를 빈번하게 진행해야한다던가 하는 경우라면 이야기가 좀 달라집니다. 위 코드에 필요한 #define을 매번 주석을 처리했다 풀었다 하는 것도 꽤 귀찮거든요. 

그래서 저는 Debug 를 하나더 카피해서 Debug Remote를 만들고 기존 Debug는 Local로 만듭니다. 
Distribution Adhoc도 Distribution Adhoc Local, Distribution Adhoc Remote 로 만듭니다. 하지만 Distribution AppStore는 로컬테스트는 진행하지 않으므로 그대로 둡니다.

그런다음 (맥 사파리에서는 네이버카페 글편집기가 이미지를 첨부할 수 없네요.)
Debug Local 설정을 선택후  Preprocess Macro 를 찾아 USE_LOG=1 LOCAL=1 을 입력합니다. 
Debug Remote 설정에는 Preprocess Macro에 USE_LOG 만 넣습니다.
Distribution Adhoc Local 설정에는 LOCAL=1 을 넣습니다. 
Distribution Adhoc Remote 와 Distribution AppStore 설정에는 아무것도 할필요가 없습니다.

이렇게 한다음 원하는 설정을 이용해 컴파일하는 것만으로 로그를 출력할지 말지, 로컬접속인지 원격접속인지 구분할 수 있게 됩니다. 

알고보면 진짜 별거 아닌데.... 이런 팁 하나하나가 생산성을 극대화 시키기 때문에 소개합니다.
좋은 팁 있으면 많이들 알려주세요. ^^

글쓴이 : 지돌스타(http://blog.jidolstar.com/722)
개인적으로 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)

+ Recent posts