UIStatusBar에 현재 앱 상황 보여주기 (트위터 앱처럼..)

트위터 공식 앱에서 트윗 작성을 하면 화면 상단의 UIStatusBar이 가려지면서 “트윗 전송 중”, “전송 완료”라는 글자가 나타났다가 사라진다. 이 부분 처리가 궁금했는데 github에서 관련 코드를 찾았다. https://github.com/brunow/BWStatusBarOverlay 위 경로에서 받은 코드를 분석하며 구조를 살펴보았는데, 이전에 내가 해보았던 방법과 달랐다… (역시… ㅠㅠ) 일단 위 코드에서 중요한 부분은 UIWindow를 상속받은 클래스이며, window의 level을 UIWindowLevelStatusBar에서 + 1(above)하는 것. 또한 보여주길 원하는 시점에서 window에 올린 UIView를 보여줄 때는 self.hidden = NO로 해야한다는 것이다. 그 외 부수적으로 눈여겨 봐야할 부분은 클래스가 singleton 모델로 구현이 되어 있다는 것 (개인적으로 singleton 모델을 반기지는 않지만 위 코드는 당근 singleton이 맞음!) 이 부분만 염두한다면 코드 보기가 수월할 것이다. 위에서 언급한 부분으로 클래스를 살짝 구현해봤는데 이전에 내가 했던 방법에서 문제가 되었던 부분이 말끔히 해결되었다. (이전에 구현한 코드의 문제점은 메시지가 나타난 후 push/pop 했을 때 view가 깨지는 문제였다.) 배웠다면 써먹어야지~! 구현한 것 돌아가는 것 살짝 동영상으로 찍어봤습니다. YouTube capture 앱 테스트도 해볼 겸.. 영상에서는 상단 Status Bar 변화를 잘 보면 이해하실거라…

트위터 연동 시 직접할 것인가? iOS SDK에 내장된 framework를 이용할 것인가?

iOS5부터는 iOS SDK 자체에 twitter.framework가 추가되어 쉽게 트위터와의 연동이 가능하게 되었다. 하지만 직접 연동하는 방법과 내부 framework를 이용하는 방법 간에 차이가 있다. 구현 복잡도를 생각했을 때, 당연히 내부 라이브러리(Twitter.framework)를 이용하는 것이 간편하다. 더욱이 Twitter 홈페이지에 가서 어플리케이션으로 등록하는 절차도 생략가능하니 얼마나 편한가? 출처가 중요한 데이터일 때, 미세한 차이는 바로 여기에 있다. 복잡도에서 설명했듯이 iOS에 내장된 트위터 프레임워크를 이용할 때 트위터 홈페이지에 가서 어플리케이션을 등록하지 않는다는 사실. 인지하였었나? 직접 연동 시에는 Oauth 특성 상 토큰을 부여받아야 하고 이를 위해서 서버에 어플리케이션 등록 과정을 거치게 되는데 이 과정이 생략되었다는 의미는 누군가 이 과정을 대신해주고 있다는 것이다. 즉, 앱스토어 등록 시스템에서 자동으로 등록한다는 것으로 생각해볼 수 있다. 조금 상세하게 살펴보자. 트위터 API를 연동하면 많은 데이터들이 나온다. 트윗 하나에 이렇게 많은 정보가 담겨있는지 놀란 분도 많을 것이다. (직접 샘플을 보고 싶은 분은 링크를 눌러서 화면 하단에 나타나는 JSON 형태를 보라. 하나의 트윗이다..) 이 정보 중 source라는 것이 있다. 한국말로 설명하자면 출처. 트윗이 작성된 클라이언트…

ACAccount.framework를 이용하여 시스템에 설정된 트위터 계정에 접근 시, 설정된 트위터 계정이 없을 때 처리 방법

iOS5 이상 버전에서는 Twitter.framework와 ACAccount.framework가 추가되어 손쉽게 트위터를 연동할 수 있다. (참고 : iOS5에 내장된 Twitter.framework 사용하기) ACAccount를 이용하여 시스템에 설정된 트위터 계정에 접근했을 때 설정된 트위터 계정이 없을 때 처리 방법을 어떻게 생각할 수 있을까? UIAlertView를 이용하여 현재 시스템에 설정된 계정이 없다고 사용자에게 알려 설정을 유도하고 가능하다면 설정으로 이동 External OAuth Library를 이용하여 WebView를 통해 연동 Twitter 개발자 사이트에서 등록한 Application의 권한을 요청(reverse_auth / xauth)하여 처리 OAuth 1.0a의 구조를 잘 알거나 External Library를 가지고 있는 경우에는 관점에 따라 2번이 가장 쉬운 방법이 될 수도 있다. (필자가 회사에서 이전에 수행했던 ‘아임리얼맛집‘은 2번의 방법으로 OAuthConsumer Library를 이용하여 연동하는 방법을 선택하였다.) 3번의 경우는 Twitter에 사용해야되는 이유를 영어로 적어 보내고 요청에 대한 답을 하염없이 기다려야 한다는 큰 단점이 있다. (영어에 자신 있다면 도전!하는 것도 추천.)   결론적으로 위에서 고려한 3가지 방안 중에 1번 방법이 가장 간단할 것이고 “가능하다면 설정으로 이동”이 관건이 되는 부분이다. reverse_auth를 고민하며 이리저리 코딩을 하다가 bulit-in twitter composer를 사용해보게 되었다. 그러다가…

Twitter와 Facebook이 iOS에 통합되면서 바라본 Server와 Client 공유 주체에 대한 생각

iOS5에서는 Twitter가 iOS 내부에 framework로 자리잡았고, iOS6에서는 Facebook이 자리를 잡았다. 이 서비스들의 계정을 담당하는 ACAccount framework가 확장이 가능한 형태였고 다른 서비스들이 여기에 자리잡지 않을까란 생각을 했었는데 역시나였다. 한국에서는 사용빈도가 거의 없는 중국 SNS인 웨이보도 이번 iOS6에 통합되었다. 앞으로 또 어떤 서비스가 ACAccountType으로 자리잡을지… 이 부분에서 궁금점이 하나 생긴다. 기존의 web-based 서비스에 Twitter와 Facebook의 연동은 일반적으로 서버에서 이루어졌었다. 따라서 클라이언트에서는 연동 페이지를 서버측에서 받아서 보여주는 행위만 하였고, 더불어 공유 시 공유를 할 것인가 말 것인가를 서버측에 전달했었다. 하지만 여기서의 단점은 서버측 네트워크 비용이다. 예상 외의 네트워크 비용이 들어간다는 것이다. 그리고 공유 시점이다. 서버 DB에 데이터가 입력이 성공했을 경우 서버측에서는 다시 이를 공유하게 되는데 순차적으로 처리되어야 하기 때문에 사용자는 이 처리가 끝날 때까지 기다려야 했다. 문제는 공유 시점에서 오류가 났을 경우에 클라이언트에서는 오류 메시지를 보내게 되고 사용자는 retry를 했을 때 서버에서는 이를 처리하기 위한 로직이 필요한 상황이 된다. 중복 자료라고 등록을 안하거나 공유만 따로 수행하거나 기타 등등… 만약 이를 클라이언트에서 한다면? 일단…