10 things you need to know about Android and Google Play - Tony Chan (Google), GDG Korea Android 컨퍼런

정상혁정상혁

지난 2013/04/13일, 종로 페럼타회에서 열렸던 '구글 개발자와 함께하는 GDG Korea Android 컨퍼런스 '에서 공유된 내용입니다.

참석해서 메모했던 내용을 정리합니다.

구글 Play와 API, 권장 UI스타일, 정책 등 다양한 주제를 이야기한 발표였습니다. UX설계를 할 때 많은 고민이 필요하겠다고 느꼈습니다.

1. Think Global

  • 한 지역만 염두에 둔다면 기회를 놓히고 있는것이다. 구글 Play 수익의 67%가 미국외에서 나오고 있다.

  • Localization을 고려해라. 구글 Play의 그래픽스와 비디오도 이제 로컬라이즈되었다.

웹애플리케이션은 국제화에 대한 고려를 하는 비율이 높지 않습니다. 앱개발은 반대로 국제화를 고려하지 않는 것이 더 합당한 이유가 있어야하는 듯합니다. 기준이 차이가 생겼다고 느껴집니다.

2. Pure Android

  • 다른 플랫폼의 UI형태를 모망하지 마라. 각각의 플랫폼은 고유한 스타일이 있다.

  • 플랫폼 특화된 아이콘을 밖에서 쓰지 말라.

  • 바닥에 붙은 탭바를 쓰지 마라. (아이폰 스타일)

  • 별도의 라벨이 붙은 백버튼, 'right point caret'(>) 버튼을 쓰지 마라. 백버튼을 플랫폼에서 제공하는 것을 쓰도록 유도해야 한다.

  • UI에 대한 지침을 지키지 않으면 사용자가 안 좋은 Rating을 할 것이다.

  • 이전의 안드로이드 버전에 지원하던 스타일의 레가시 버튼을 쓰지 마라.

  • Action bar를 써라. 곧 support 라이브리리를 통해 하위 버전에서도 ActionBar를 쓸 수 있게 될 것이다. 지금도 오픈소스로 Actionbar-sherlock이 있지만, 기본 SDK에서 이제 지원된다.

  • 가장 최신의 SDK에 targeting하라. 최신의 SDK에서만 돌아가야한다는 의미는 아니다. 하위버전에서도 돌아가도록 만들면서도 상위버전에서는 최신의 UI 요소들을 활용해야 한다.

개별 앱의 UI는 같은 플랫폼 내에서의 일관성을 해치지 않아야한다는 지침을 강조했습니다. 같은 사용자가 2개의 다른 플랫폼을 오가면서 같은 앱을 사용하는 경우보다는, 하나의 플랫폼에서 여러 앱을 사용하므로 플랫폼 내에서의 일관성이 중요한 것은 당연한듯합니다.

기획자나 디자이너 입장에서는 하나의 앱을 출시하면 여러 플랫폼이 동일한 UI로 나오기를 바랄 수도 있을 듯한데, 이러한 지침을 초기부터 염두에 두고 엔지니어가 피드백을 줄 수 있어야겠습니다. 안드로이드 디자인가이드도 정독해봐야겠구나 싶었습니다.

그리고 Actionbar-sherlock에서 해주던 ActionBar의 하위 호환성 지원이 support 라이브러리에 들어간다는 소식도 반가웠습니다. Fragment가 support 라이브러리에서 지원되는 것을 생각하면 자연스러운 개선이기도 합니다.

3. Design for all form-factors

  • Fragment를 써라

  • 타블릿과 폰을 위해서 별도의 프로젝트를 프로젝트를 만드는것은 바람직하지 않다. Fragment를 이용해서 타블릿에서는 하나의 Activity에 여러개의 Fragment가, 폰에서는 Activity당 하나의 Fragment를 보여주는 식으로 구성하면 얼마든지 하나의 프로젝트로 구성할 수 있다.

  • UI요소의 크기는 기기의 해상도에 독립적이도록 DP를 쓰고, 텍스트에는 SP를 써라.

  • 적어도 3개의 레이아웃을 고려해라. 폰, 7인치 타블릿, 10인치 타블릿. DP는 해상도 문제만 해결할 뿐, 다른 사이즈에 대한 문제는 별도로 고려해야 한다.

  • 지원하려는 화면 밀도(Density), 해당도에 맞는 Asset, 이미지을 각각 준비해라. Aliasing은 보기에도 좋기않고 CPU를 많이 사용해서 배터리 사용시간을 짧아지게 한다.

DP에 대해서는 아래 그림 1장이 직관적인 이해에 많은 도움이 되었습니다. 11355F45516932300FB576

(이미지 출처 : http://www.kmshack.kr/317#.UWy9VIpdUbj )

웹에서는 '방탄형 웹’이나 '반응형 웹디자인’에 대한 많은 노하우가 공유되고 있는데, 안드로이드에서도 점점 더 섬세한 노하우들이 공유될 것 같습니다.

4. Correct back button behaviors

  • 앱의 메인 화면에서 사용자는 홈스크린으로 바로 돌아갈 수 있어야 한다. 종료 할때 다이얼로그로 종료할지 물어보는 방식으로 Back에 대한 이벤트를 강제적으로 막지마라.

많은 앱이 이렇게 되어 있지 않기에 다소 의외의 가이드라고 느껴졌습니다. 이것도 일관성을 생각하면 의미 있는 지침입니다.

5. Proper notification

  • 핵심 기능에 대해서 통지해라. 광고에 Notification을 쓰지 마라.

6. App quality improvement

한글 번역도 http://googledevkr.blogspot.kr/2013/01/app-quality-guidelines.html 에서 보실 수 있습니다.

(이 포스트를 쓰고 난 후에 권순선님께서 알려주셨습니다.)

7. Permission

  • 핵심기능에 필요한 최소한의 권한만 부여하도록 해라.

  • 민감한 권한을 너무 많이 가지고 있으면 당신에게 해가 된다. 앱의 다운로드 숫자나 주목 받을 기회가 줄어들 것이다.

8. Google play service

  • 구글에서 제공하는 서비스 API를 나열하면서 소개.

  • Maps API 2, Google+, Google Authorization, Google Play services APK 등

위 내용은 http://developer.android.com/google/play-services/index.html에 자세히 나와 있습니다.

9. New platform API

  • 새로 추가된 API를 간단히 나열.

    • Lock screen widget

    • Seconary display

    • Day dreams (interactive screensaver mode)

    • Natvie RTL(right-to-left) support

    • Tablet sharing

  • 최근 업데이트된 API 소개

    • GCM

    • Analystic SDK

    • In-app Billing V3 (V2는 더이상 쓰지마라)

    • Youtube android player

자세한 내용은 http://developer.android.com/about/versions/jelly-bean.html에 있습니다.

발표된지는 한참된 기능이지만, 이렇게 모아서 보니 앱개발자가 화면을 다양하게 활용할 수 있는 여지가 더 늘어나고 있다고 느껴졌습니다. 이에 따라 새로운 사업모델도 나올 수 있었는데, 이런 아이디어들이 기획부서에서만 나오기를 기다리는 것보다 개발자들도 적극 제안을 해 보면 어떨까하는 생각이 들었습니다. 개발자들은 새로운 API가 추가되는것을 늘 관심있게 보고 있기 때문에 자연스럽게 아이디어가 나올만도 합니다. Lock screen widget을 이용한 광고 제품이 나왔듯이, 앞으로도 그런 기회가 많이 남아 있을 것이라고 기대가 됩니다.

10. Publishing on google play

  • Google play는 풍부하게 미디어를 활용한다.

    • 특징을 멋지고 깔끔한 이미지로

    • 스크린샷

    • 짧은 유튜브 동영상

    • 로컬라이케이션

  • 대표적인 정책 위반 사례들.

    • 3rd party 지불

    • 다운로드를 위해 3rd party 사이트로의 연결

    • 스팸 키워드

    • 별점에 인센티브 부과

  • 정책에 대한 자세한 내용은 http://bit.ly/google-play-policy-edu 참조

정책에 따라 구현이 달라져야 할 부분을 미리 파악하고 있으려면 꾸준한 관심을 가져야겠습니다.

Spring tag library + Tomcat7.x 또는 Glassfish 2.2.x의 EL Injection 위험

정상혁정상혁

취약점의 조건

아래 조건을 모두 충족시킨다면 코드는 치명적인 Remote code execution 취약성이 존재할 여지가 있습니다.

  1. EL 2.2를 지원하는 서블릿 컨테이너를 쓰거나 EL 2.2 라이브러리를 직접 jar파일로 참조해서 쓰고 있다. (대표적으로 Tomcat 7.x혹은 Glassfish 2.2.x)

  2. Spring 3.1.x 미만 버전을 쓰고 있다.

  3. Spring의 JSP Tag( <spring:message.. 등)을 쓰고 있다.

  4. Spring의 JSP Tag에서 EL을 지원하는 속성에 사용자가 입력한 값이 들어갈 수 있다.

위에서 첫번째 조건이 해당하지 않더라도 다른 취약점을 조심해야 합니다. EL 2.2을 사용하지 않더라도 JSP 2.0이상을 지원하는 서블릿 컨테이너를 쓰면서 2,3,4에 해당하는 코드라면 어플리케이션의 중요한 정보를 노출시킬 수 있는 취약점이 존재할 위험이 있습니다. Remote code execution만큼 심각하지는 않지만, 역시나 조치가 필요합니다.

이 취약 지점은 의도하지 않은 정보를 노출할 수 있는 위험성으로 이미 2011년 9월 지적되어 보안되었으나, 이번달인 2013년 1월에는 같은 취약 지점을 통해서 원격 코드를 실행하는 기법이 발견되어 위험성 등급이 올라갔습니다. 즉, 해당 라이브러리가 취약성을 유발한다는 점 자체는 새로운 것이 아니고, 이미 이를 보강하는 버전이 나와 있습니다.

이 취약점의 원인과 조치방법은 아래 링크에 정리해놓았습니다. (코드가 들어간 글은 GIST를 쓰는 것이 훨씬 편하네요.)

Markdown + Dropbox

정상혁정상혁

  • 업데이트

    • 2019.04.10 : 현시점에서는 Calepin 서비스도 종료되었습니다.

    • 2013.03.05 : GIST에 썼던 글을 옮기어 봅니다.

      • Springnote 서비스 종료 전에 쓴 글이라서 Springnote의 마이그레이션 코드는 이제는 쓸수가 없네요)

자료를 정리하는 형식과 도구에 대한 고민

회사에서 만든 자료들은 MOSS(Microsoft Office SharePoint Server)나 위키, 메일함 등이 있으니 큰 아쉬움은 없는데, 개인적인 자료들은 어떻게 정리하고 보관, 공유할지가 늘 고민이 됩니다.

저는 공개하고 싶지 않은 것들은 에버노트와 드롭박스를 쓰고, 공유할 자료들은 스프링노트와 이글루스 블로그을 활용하고 있습니다.코드들은 주로 Github와 Gist에 올립니다.

이렇게 다양한 서비스를 쓰다보니 자료를 서비스 간에 이동을 할 일이 생기면 많이 불편합니다. 예를 들면 에버노트에 있는 자료를 블로그에 올린다거나 스프링노트에 있는 글을 구글사이트로 옮길 때가 그렇습니다.그냥 한 두 페이지면 복사해서 붙여넣기를 하겠지만, 여러 페이지를 옮길 때 그렇게 하면 단순 반복 작업에 들어가는 시간이 아깝습니다.웹 브라이저나 웹 에디터의 차이 때문에 칸 맞추기 같은 사소한 편집에 시간을 많이 허비하기도 합니다.웹이나 클라언트 환경 등 다양한 환경에서 모두 편집이 간편했으면 하는 바램도 있었습니다. 우분투를 쓰는 시간이 많다보니 MS워드처럼 특정 OS가 종속적인 편집기는 별로 좋아하지 않기도 합니다. 그리고 정리한 내용을 자주 찾아보니 검색과 탐색 기능을 쓰기 쉬웠으면도 했습니다.

이번에 스프링노트가 종료될 예정이라 어떤 형식으로 자료를 정리할 것인지에 대한 고민이 더 커졌습니다.

요구사항을 정리하면

  • 자료를 이동하는 비용이 적어야하고 (이식성)

  • 자료의 모양 때문에 편집을 하는 시간이 되도록 없었으면 하고

  • 특정 환경에 종속적이지 않은 다양한 문서 편집기를 사용할 수 있어야 하고

  • 검색 기능을 간편하게 쓸 수 있어야 한다.

이런 점들을 고민하다보니 우선 정리하는 자료의 형식은 마크다운을 선택하게 되었습니다. Github와 Gist를 쓰면서 그 단순함에 만족을 했고, 텀블러, 트렐로등 지원하고 있는 서비스도 늘어가고 있어서 이식성도 높다고 생각했습니다.

그리고 원본 데이터를 파일단위로 관리하고 싶었습니다. 쓰던 서비스가 망하더라도 파일을 단순히 복사해서 다른 서비스로 옮길 수 있다면 이전 비용이 적을 것이기 때문이였습니다.

Github를 이용한 Octopress도 검토했으나, 버전관리까지는 필요없이 최종 파일만 관리하면 되었기 때문에 Dropbox를 썼으면 좋겠다고 생각했습니다.

사람 생각은 다 비슷한지, 이미 Dropbox + Markdown을 이용한 블로그와 위키 서비스가 나와 있었습니다.

Calepin( =Markdown + Dropbox)로 블로그 만들기

Calepin을 이용해서 http://book.benelog.net이라는 블로그를 만들어봤습니다.그동안 여러 곳에서 정리하던 읽은 책에 대한 메모를 Markdown으로 정리한 것입니다.

아래와 같이 .md 파일의 처음 시작에 날짜와 제목, URL, 태그 등의 정보를 달아주고, 파일을 [Dropbox 공유폴더]/Apps/Calepin이라는 폴더로 복사합니다.

Date: 2012-07-19
Title: 어제를 버려라
Slug: 어제를_버려라
Tags: IT업계

그리고 Calepin 사이트에 가서 'Publish’버튼을 누르면 약속된 폴더에서 파일정보를 읽어와서 블로그를 생성해 줍니다.

calepin

이 정보를 바탕으로 블로그를 만들어줍니다. 아래와 같이 굉장히 단순한 디자인인데, 저는 이 정도로 충분하다고 느꼈습니다.

book benelog net

scriptogr.am라는 서비스도 거의 비슷한 기능을 제공하는데, 블로그 테마 등 약간의 커스터마이징이 가능합니다. wikipackit도 사용법은 유사하고, 위키 페이지간의 링크 기능을 제공하지만, 현재까지는 페이지를 비공개로만 관리할 수 있습니다. 앞으로 유사한 서비스가 더 많이 나올수도 있고, 이전 비용도 크지 않으니 언제든지 좋은 서비스가 나오면 갈아탈 생각입니다.

스프링노트 마이그레이션

저는 스프링노트로 관리하던 페이지들 중 일부는 http://wikipackit.com 으로 옮겼습니다. 스프링노트의 API를 이용해서 Markdown형식으로 스프링노트 페이지를 다운로드하는 스크립트를 작성했습니다.Python과 Pandoc을 활용했습니다.

Eclipse Markdown Text Editor

편집기로는 주로 Eclipse에서 Markdown Text Editor을 사용하고 있습니다.Eclipse가 무거운 편이지만, Platform Runtime Binary를 찾아서 최소한 도로 설치하면 50MB가 넘지 않게 비교적 가볍게 쓸 수도 있습니다. 예를 들어 Eclipse 3.8의 최소설치를 위한 파일은 아래 링크에서 찾으실 수 있습니다.

편집을 하면서 HTML렌더링을 할 수도 있고, Eclipse의 단축키를 그대로 활용할 수도 있습니다. 예를 들어 파일을 찾을 때 Ctrl + Shift + R키를 눌러서 파일명의 일부를 입력해서 바로 찾아가는 것들이죠.

eclipse markdown plugin

이렇게 구축한 글쓰기와 자료정리 환경을 굉장히 만족하면서 쓰고 있습니다. Markdown을 지원하는 서비스나 도구들은 앞으로 계속 나올 듯하고, 스스로 만들기도 쉽기 때문에 더 편하게 쓸 수있는 가능성도 크다고 봅니다.