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를 사용해보게 되었다. 그러다가…

UIWebView 배경색 지정 및 그라데이션 없애기

UIWebView를 사용할 때는 검은 배경색에 그라데이션이 지정되어 있다. 기본으로 사용하면 일단 WebView인 것을 알리게 되고 통일성도 없어서 난감할 때가 있다. 이 때 사용할 수 있는 자그만한 팁! – (void)setScrollViewBackgroundColor:(UIColor *)color { for (UIView *subview in [_webView subviews]) { if ([subview isKindOfClass:[UIScrollView class]]) { /* 배경색 지정 */ subview.backgroundColor = color; for (UIView *shadowView in [subview subviews]) { if ([shadowView isKindOfClass:[UIImageView class]]) { /* 그라데이션 숨기기 */ shadowView.hidden = YES; } } } } } 참고 사이트 http://stackoverflow.com/questions/3009063/remove-gradient-background-from-uiwebview http://stackoverflow.com/questions/8667150/uiwebview-background-is-set-to-clear-color-but-it-is-not-transparent

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

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

하위 버전을 기준으로 할 것인가? 상위 버전을 기준으로 할 것인가?

일반적으로 하나의 앱을 만들 때 컨셉을 결정하고 이에 대한 아이디어를 구체화한 다음 요구사항이 명확해지면 UI Flow를 그리게 된다. 이 때 한국적인 방식(?)으로 일을 한다면, 기획자나 디자이너 또는 두 파트 함께 이에 대한 UI Flow를 그리게 되고 개발자에게 전달된다. 개발자에게 전달된 flow는 한 번 이상의 feedback을 주고 받으며 개발에 들어가게 된다. 이 feedback의 대부분은 가능한지 혹은 불가능한지, 작업 공수에 대한 얘기가 될 것이다. 또한 더 자세히 들여다보면 OS 버전에 따른 기능의 가능, 불가능 혹은 많은 공수 투입이 결정된다는 것이다. 예를 들어, 최신 OS에서는 아주 멋진 디자인 feature가 추가가 되었고 디자이너도 이를 자신의 프로젝트에 꼭 도입을 하고 싶어한다고 간주하자. 물론 개발자라고 그런 욕심이 없을까? 삼위일체(?)로 모두 해당 기능을 꼭 적용해보고 싶어할 것이다. 하.지.만! 개발자는 여기서 한 가지 고민을 하게 될 것이다. 고민의 내용은 최신 OS에서만 구현이 쉽게 되지만, 구 OS에서는 구현이 쉽지 않다는 것이다. 결국 개발자는 기획자에게 확인을 한다. 호환 OS의 범위. 즉, deployment OS target을 어떻게 결정할 것이냐고. 그럼  기획자는 대부분…

Facebook Hack – Seoul 간단 참여후기 (2)

Facebook Hack – Seoul 후기 2편입니다. 1편은 http://y8k.me/?p=289 에서 보실 수 있습니다. 생에 처음으로 참여한 Hackathon 행사여서 준비보다는 참여하는데 의의를 두자고 생각하고 도전해봤습니다. 행사장에서 친해진 황인서님과 쉬는 시간마다 이런저런 아이디어를 짜내다가 Facebook 의 새로운 feature인 Open Graph 로 targeting을 하고 어떤 컨텐츠로 해볼까 저녁을 먹으면서 논의를 하고 확정을 했습니다. 둘 다 Observer로 갔다가 의지에 불타올라 참여까지 한 상황이었죠.. 황인서님은 알고봤더니 목욕의 신 앱을 개발한 멤버더군요. +ㅁ+b 이 게임을 이용해볼까 고민하다가 Action Type을 다중화하기가 어렵다는 결론이 도출되어 평소 고민이 많았던 ‘아임인핫스팟‘ 을 이용해보기로 결정하였습니다. 아직 Open API를 제공하고 있진 않지만 Client를 구현했던 프로젝트이어서 API를 알고 있었고 Action을 다양하게 설정할 수 있다는 점이 선택하게 된 가장 큰 장점이었습니다. 회사 프로젝트 담당PM님에게 허락을 득하고 API 담당 개발자분께 자문을 구하는데까지 성공! (낙정PM님 경환PD님 감사합니다!) 결정 이후에는 이런저런 잡담을 나누면서 맛난 저녁 식사를 했습니다. (아래 사진) 늦은 점심 후에 이른 저녁식사라 많이 먹진 못했지만 신선한 참치회와 초밥, 그리고 다양한 음식들로 등록비 25$는 충분히 보상받았구나!! 라는 느낌을…