googledevkr: February 2013

소셜 스팸 없이 간단하고 안전하게, Google+ 로그인

Tuesday, February 26, 2013

작성자: Seth Sternberg (Director of Product Management, Google+)
게시일: 2013년 2월 26일
원문링크: http://googleplusplatform.blogspot.com/2013/02/google-plus-sign-in.html

Google+ 플랫폼에 애플리케이션 로그인 기능이 오늘 새롭게 출시되었습니다. Android, iOS, 웹용 앱에 상관 없이 사용자는 Google 계정으로 로그인할 수 있으며, 로그인 시 Google+ 정보를 포함하게 되어 사용자는 보다 업그레이드된 경험을 누릴 수 있습니다. Google+ 로그인은 단순하고 안전하며 소셜 스팸을 방지할 수 있습니다.
(한글자막 제공)

이번 초기 릴리즈에서는 사용자를 위해 다음과 같이 4가지 주요 원칙에 집중하였습니다.

1. 단순함과 보안성을 최우선으로!

Gmail나 유튜브, 혹은 다른 Google 서비스에 로그인하면 기존의 인증서를 사용하여 Google 외의 앱으로 로그인할 수 있습니다. Google+ 권한 설정 화면(해당 앱으로 공유하는 정보 및 본인의 액티비티를 볼 수 있는 대상을 간략하게 표기)만 확인하면 설정이 완료됩니다. 또한 Google+ 로그인은 Google 계정에서 사용하는 보호 및 안전 장치(2단계 검증과 같은)가 제공되기 때문에 언제나 안심하고 로그인할 수 있습니다.

로그인된 앱을 관리하는 것 또한 간단합니다. 언제든 plus.google.com/apps에 방문하거나 Andorid에서 새로운 Google 설정 앱을 오픈하세요.

2. 데스크탑과 모바일이 함께 시너지 작용!

많은 개발자들이 웹과 모바일 버전의 앱을 제공하고 있지만, 브라우저, 휴대폰, 태블릿에서 따로 환경을 설정하는 것은 매우 번거로운 일입니다. 오늘부터 Google로 웹사이트에 로그인하면 클릭 한 번으로 해당 모바일 앱을 Android 기기에 설치할 수 있게 됩니다.

3. 정보 뿌리기는 스팸일 뿐, 따라서 공유는 선별적으로!

때로는 공개적으로 사람들과 공유하고 싶은 것(최고 점수 등)도 있지만, 자신만 알고 싶은 정보(체중 감량 목표 등)도 있습니다. 공유할 것이 있다면, Google+ 로그인과 서클을 통해서 공유 대상을 결정할 수 있습니다. 게다가 Google+에서는 “마찰없는(frictionless)" 업데이트 정보를 스트림 여기저기로 뿌려대지 않기 때문에 연관이 있을 때에만 (예를 들어 실제로 검색할 경우) 앱 액티비티를 보여줍니다.

4. 공유는 단순한 감상이 아닌, 행동하기 위한 것!

사진과 동영상은 감상하기에 아주 좋습니다. 하지만 때로는 온라인에서 무엇인가 하기를 원할 때가 있습니다. 따라서 Google+ 로그인을 사용하는 앱에서 정보를 공유할 때, 사용자의 친구들은 Google+ 스트림에서 새로운 종류의 “인터렉티브한" 포스팅을 볼 수 있도록 했습니다. 포스팅을 클릭하면 앱 안으로 들어가게 되며 (예를 들면) 여러분이 공유한 것을 사거나 듣거나 리뷰할 수 있습니다.

안드로이드나 iOS, 또는 웹용 앱을 개발하면서 Google+ 로그인 기능을 포함시키고 싶다면 개발자 문서를 확인하고, 해당 기능이 연동되면 통계를 확인해 보세요. 안드로이드 앱은 Google Play 서비스 최신 버전이 필요하며, 며칠 안에 모든 디바이스로 출시될 것입니다.

다른 개발자들이 Google+ 로그인 기능을 사용한 내용을 확인하려면 아래 사이트 목록을 방문해서 새로운 “Google로 로그인(Sign in with Google)" 버튼을 찾아보세요. (계속해서 출시 예정)
Banjo
Beautylish
Fancy
Fitbit
Flixster
The Guardian
OpenTable
Shazam
TuneIn
USA Today

* 참고 동영상 (한글 자막 제공)*
Google I/O 2012 - Google 플러스 플랫폼 입문

YouTube API 업데이트 따라잡기

Wednesday, February 13, 2013

작성자: Ibrahim Ulukaya (YouTube API 팀)
작성일: 2013년 2월 6일
원문링크: http://apiblog.youtube.com/2013/02/keeping-up-with-youtube-api-updates.html

계속 발전하고 있는 YouTube API의 개선 사항을 지속적으로 파악하려면 릴리즈 노트를 확인하는 것이 좋습니다. 하지만 바쁜 일상으로 인해 주기적으로 업데이트를 할 수 없는 경우가 많죠. 이제 RSS 피드를 구독하면 새로운 기능이 소개되는 즉시 바로 알 수 있습니다.

모든 YouTube API 및 위젯에 대한 릴리즈 노트는 각각 상응하는 RSS 피드를 제공합니다. 사용 가능한 피드 목록은 다음과 같습니다.

YouTube Data API (v3)
YouTube Analytics API
YouTube Android Player API
YouTube IFrame Player API
YouTube JavaScript Player API
YouTube Flash (AS3) Player API
YouTube Upload Widget
YouTube Data API (v2)

모든 YouTube API에 대해서 RSS로 업데이트해 드리겠습니다. YouTube for Developers 구글 플러스에 가입하시고 RSS 피드로 최근 API 업데이트 정보를 받으세요!

인터넷상 주민등록번호 사용 제한법 - 앱에도 해당됩니다!

Wednesday, February 13, 2013

앱 개발자 중에서 본인의 앱에서 주민등록번호를 수집 및 사용하고 계신다면, 아래 내용을 참고하시어 빠른 시일 내에 대체 수단을 이용하여 법을 위반하는 경우가 발생하지 않도록 신속한 조치를 부탁드립니다.

정보통신망법 제23조의 2에 따라, 작년 8월부터 원칙적으로 주민등록번호 수집 및 이용이 금지되었고 6개월의 유예 기간이 만료되는 오는 2013년 2월18일부터 전격 단속에 들어갑니다. 이에 따라 방통위에서 2월 말부터 모니터링과 점검을 시작한다고 합니다. 위반 시 망법 제76조 제1항 제2호에 따라, 3천만원 이하의 과태료가 부과될 수 있습니다.

인터넷상 주민등록번호 수집 및 이용 제한

정보통신방법을 적용받는 정보통신서비스제공자는 영리목적으로 웹사이트에서 주민등록번호를 수집 이용하지 못함 (제23조의2)

법령공포: 2012.2.17
벙령시행: 2012.8.18
유예기간: 법령 공포 후 6개월

* 주민등록번호를 수집할 수 있는 예외 상항
(1) 정보통신망법에 따른 본인확인기관으로 지정받은 경우
(2) 법령에서 주민등록번호 수집/이용을 허용하는 경우
(3) 영업 목적상 주민번호 이용이 불가피하여 방통위가 고시하는 경우

본 사항은 웹뿐만 아니라, 앱에도 적용되는 내용입니다. 앱에서 주민등록번호를 수집하거나 이용하는 행위는 불법에 해당합니다. 현재 주민등록번호 수집을 앱에 포함시킨 개발자분들은 서둘러 수정하시고 대체수단을 강구하시길 부탁드립니다!

* 방통위가 제안한 대체 수단은 다음과 같습니다.
1) 대면 방식을 통한 인증 및 신분증 사본 팩스/우편 송부
2) 아이핀
3) 공인인증서
4) 신용카드 인증
5) 휴대폰 인증 (휴대폰을 통한 자동음성응답 및 문자)

2013년에도 “Google Summer of Code”가 개최됩니다.

Tuesday, February 12, 2013

작성자: Carol Smith (Open Source Team)

원문링크: http://google-opensource.blogspot.kr/2013/02/flip-bits-not-burgers-google-summer-of.html

2013년에도 Google Summer of Code가 개최될 예정입니다.

이번 해에 9회째 개최되는 Google Summer of Code는 전 세계 대학생을 대상으로 오픈 소스 소프트웨어 개발을 소개하기 위해 진행되는 혁신적인 프로그램입니다. 전 세계 멘토링 기관의 도움을 받아 학생 개발자들은 본 프로그램을 통해서 다양한 오픈 소스 프로젝트에 참여하게 됩니다. 지난 8년 동안 100개국 6000명의 학생들이 Google Summer of Code에 참여하여 프로그램을 완료하였습니다. 본 프로그램의 목적은 학생들이 여름 방학 동안에 모두를 위한 오픈 소스 코드를 생성하고 릴리즈하면서 학문적 도전을 추구하도록 돕기 위함입니다.

Google Summer of Code에 대해서 주변에 알려주세요. 이번 여름, 오픈 소스 프로젝트 작업에 관심이 있는 대학생 친구가 있거나 오픈 소스 프로젝트에 작업할 학생을 멘토하고자 하는 기관을 안다면, 스케줄과 FAQ를 확인할 수 있는 Google Summer of Code 2013 웹사이트를 알려주시면 됩니다. 자세한 내용은 추후에 공지해 드리겠습니다.

안드로이드 사용자 데이터 처리

Tuesday, February 12, 2013

신뢰할 수 있는 애플리케이션을 만들기 위해서 아래 포스팅 내용을 숙지하세요.

작성자: Nick Kralevich (안드로이드 보안팀 엔지니어)
작성일: 2010년 8월 4일
원문 링크: http://android-developers.blogspot.kr/2010/08/best-practices-for-handling-android.html

반드시 앱 목록에 개인 정보 보호 정책 링크를 포함시키도록 한다

모바일 애플리케이션 사용이 증가함에 따라 애플리케이션에서 사용자의 데이터를 어떻게 사용하는지에 대한 관심 또한 증가하고 있습니다. 안드로이드 플랫폼에서는 사용자를 보호하기 위해서 권한 승인에 대한 광범위한 가이드라인을 포함하고 있지만, 사용자 정보를 어떻게 처리하는지는 궁극적으로 애플리케이션 개발자의 책임입니다. 따라서 개발자가 자신이 사용하는 코드를 제대로 이해하고 권한 요청 여부를 숙고하는 것이 중요합니다. 이러한 문제를 제대로 처리하지 못하면 사용자는 이를 배임 행위로 받아드릴 수 있기 때문입니다.

건전하고 신뢰할 만한 생태계를 유지하는 것은 모든 안드로이드 개발자의 최대 관심사입니다. 신뢰할 수 있는 안드로이드 애플리케이션을 만들기 위해서 다음 사항들을 적용하세요.

사용자 정보 보호 정책을 유지한다.

권한을 최소화한다.

사용자에게 정보 수집에 대한 선택권을 준다.

불필요한 정보를 수집하지 않는다.

디바이스 외부로 정보를 보내지 않는다.

하지만 필요한 경우, 암호를 사용하고 데이터 사용을 최소화한다.

모르는 코드를 사용하지 않는다.

디바이스 혹은 사용자 전용 정보를 기록하지 않는다.

사용자 정보 보호 정책을 유지한다

신뢰할 수 있는 애플리케이션은 수집하는 데이터와 수집 목적에 대해서 정직하게 밝힙니다. 그러한 정보 수집이 자신에게 유익하다고 생각할 때, 대체적으로 사용자는 해당 앱들을 통해서 기꺼이 정보를 공유합니다. 애플리케이션에서 수집하는 정보의 종류 및 사용 방법에 대한 상세한 설명과 함께 분명하고 간결한 개인 정보 보호 정책을 제공하면 신뢰와 선의를 구축하는데 큰 도움이 됩니다. Google Play 등록에서 개인 정보 보호 정책으로 바로 연결할 수 있는 링크를 사용자에게 제공할 수 있습니다. (개발자 콘솔에 가서 해당 링크를 추가)

실제로 필요한 권한만을 요청하도록 한다.

권한을 최소화한다

모바일 OS 중에서 안드로이드는 간단하고 쉬우며 OS 강제 권한 모델을 가진 운영체제입니다. 모든 안드로이드 애플리케이션은 필요한 권한을 선언하고 사용자는 애플리케이션이 설치되기 전에 이 권한들을 반드시 승인해야 합니다. 사용자는 과도한 권한을 요구하는 애플리케이션을 불신하는 경향이 있습니다. 예를 들어, 오목 게임을 설치하는 사용자는 사진 찍기가 왜 필요한지 당연히 의문을 가질 수 있겠죠.

사용자에게 정보 수집에 대한 선택권을 준다

개인정보보호의 역설[PDF, 890K]이라고 합니다. 사용자는 기꺼이 정보를 공유하면서도 해당 공유에 대해서 제어권을 가지기를 원합니다. 신뢰할 수 있는 애플리케이션에서는 자신의 정보 사용을 사용자가 제어할 수 있도록 합니다. 예를 들어, 안드로이드 브라우저에서는 사용자가 정보를 공유하는 방법을 제어할 수 있도록 개인 정보 설정 기능을 제공합니다.

불필요한 정보는 수집하지 않는다

신뢰할 수 있는 애플리케이션은 수집하는 정보의 종류를 제한합니다. 불필요한 정보를 수집하는 행위는 (특히 사용하지 않는 경우에) 사용자로부터 불신을 살 수 있습니다. 용도가 확실하지 않은 경우에, 불필요한 정보는 수집하지 않도록 합니다.

디바이스 외부로 정보를 보내지 않는다

사용자 데이터를 처리해야 하는 경우, 디바이스 외부로 정보가 나가지 않도록 해야합니다. 사용자는 자신의 정보가 반드시 휴대폰 내에 있어야 안심합니다. 사용자의 유익을 위한다 하더라도 디바이스 외부로 정보를 보내는 것은 불신을 조장할 수 있습니다.

하지만 필요한 경우, 암호를 사용하고 데이터 사용을 최소화한다.

때로는 정보 수집이 필요할 경우가 있습니다. 이러한 경우, 애플리케이션에서는 해당 정보를 안전하게 처리해야 합니다. 개인 정보 보호 정책을 통해 사용자를 당황스럽게 하거나 불쾌하게 만드는 경우를 방지할 수 있습니다. 경우에 따라 데이터를 디바이스 외부로 전송하기 전에 사용자에게 알려주는 것이 바람직한 경우도 있습니다.

첫 째, 수집하는 데이터의 양을 최소화 합니다. 사용자의 전화번호가 실제로 필요한지, 아니면 지역 번호로 충분한지, 사용자의 비밀 정보를 보호하기 위하여 해당 데이터를 서버로 보내기 전에 데이터에 일방향 암호 해시 함수를 쓸 수 있는지 확인합니다.
사용자가 자신의 데이터를 처리 여부를 제어할 수 있도록 하라.

두 번째, 사용자 데이터를 안전하게 처리하기 위해 암호화는 매우 중요합니다. 종종 휴대폰은 공격자들이 기밀 트래픽을 빼낼 수 있는 신뢰할 수 없는 네트워크에서 사용됩니다. 따라서 전송 중에 데이터를 암호화하는 것은 사용자 정보를 보호하는데 매우 중요한 요소입니다.

마지막으로, HTTP로 서버와 통신할 때 HTTP GET으로 사용되는 URL에 사용자 정보를 암호화하기보다, 메시지 바디 안에 POST하세요. POST를 사용한다고 해서 정보가 누출되지 않는다고 보장할 수는 없지만, URL 안에 넣으면 자동으로 기록될 가능성을 높입니다. 참고로 대다수 웹 서버 소프크웨어는 받은 모든 URL을 기록합니다.

사례 연구: 사용자 즐겨찾기

완전한 등록 절차 없이, 각 사용자들의 즐겨찾기 목록을 관리하는 앱을 만든다고 가정해 봅시다. 이론적으로 볼 때, 사용자의 전화번호나 디바이스 ID, SIM ID를 조합해서 서버로 보내면 됩니다. 하지만 굳이 사용자로 하여금 자신의 개인 정보 사용에 대해서 우려하게 만들 필요는 없습니다. 대신, 식별 정보가 무엇이든지 간에 일방향 해시 서명을 사용하여 보내는 방법은 어떤가요? 아니면 더 나은 방법으로, 랜덤 고유 ID를 만들어 휴대폰에 저장하고 해당 ID를 애플리케이션에 등록키로 사용하는 방법도 있습니다. 그러면 각 사용자들의 즐겨찾기 정보를 받으면서도 민감한 정보를 보내거나 저장할 필요가 없겠죠.

모르는 코드를 사용하지 않는다

오픈 소스 안드로이드 환경에서, 라이브러리와 프레임워크 형태로 다른 사람의 코드를 많이 사용하는 것은 일반적인 (혹은 바람직한) 일입니다. 하지만 해당 코드가 사용자의 정보를 부적절하게 처리하고 있다면 문제가 될 수 있습니다. 따라서 다른 개발자의 소스를 사용하기 전에 반드시 코드를 확인해야 합니다.

사용자 및 디바이스 전용 정보를 기록하지 않는다

애플리케이션 개발자는 디바이스 상에 기록되는 로그에 주의를 기울여야 합니다. 안드로이드에서는 용이하게 휴대폰 로그를 작성할 수 있으며 로그캣 결과 값을 확인하면 알 수 있듯, 해당 로그는 다양한 애플리케이션에서 보내는 랜덤한 디버깅 정보처럼 보이지만, 실제로 매우 중요한 정보를 가지고 있습니다. 안드로이드에서 로그는 공유되는 리소스로 READ_LOGS 권한을 가진 애플리케이션에서 사용할 수 있습니다 (물론 사용자가 동의할 경우에만). 휴대폰 로그 데이터가 일시적이고 재푸팅 시에 삭제된다 하더라도 사용자 정보를 부적절하게 기록하면 의도하지 않게 사용자 정보를 다른 애플리케이션으로 누출시킬 수도 있습니다.

안드로이드 애플리케이션 SD 카드에 설치하기

Thursday, February 7, 2013

안드로이드 애플리케이션을 SD 카드에 설치하는 것과 관련한 이슈가 계속해서 제기되고 있습니다. 여러분의 이해를 돕고자 관련 블로그 포스팅을 한글로 제공합니다. 참고 바랍니다.

SD 카드에 설치된 앱 - 자세히 알아보기

작성자: Suchi Amalapurapu
게시일: 2010년 7월 8일
원문 링크: http://android-developers.blogspot.kr/2010/07/apps-on-sd-card-details.html

안드로이드 2.2에서는 SD 카드 등과 같은 외부 저장 장치에 애플리케이션을 설치할 수 있는 기능을 제공합니다. 이를 통해 사용자는 더 많은 앱을 설치할 수 있으며, 게임과 같이 큰 규모의 에셋을 필요로 하는 앱에 유용합니다. (“SD 카드에 설치된” APK의 모든 콘텐츠가 SD카드에 설치되는 것은 아니라는 점을 주의: dex 파일, 개인 정보 디렉토리, 네이티브 공유 라이브러리는 내부 저장소에 보관됨)

설정 앱에 있는 “앱 관리(Manage Applications)" 화면에서 “SD 카드" 탭이 제공됩니다. 앱 관리 목록에서 표기되는 크기는 내부 저장소에서 앱이 차지하는 공간만을 포함하고 있습니다.

“앱 정보” 화면에 “SD 카드로 이동” 또는 “휴대폰으로 이동” 버튼이 있지만, 종종 비활성화되어 있습니다. 복사가 금지된 앱 및 시스템 앱 업데이트는 SD 카드로 이동할 수 없으며 SD 카드에서 작동한다는 것을 명시화하지 않습니다.

설치 우선권 제어하기

SD 카드 설치는 안드로이드 2.2에서 제공하는 선택 사항으로, 사용자가 아닌 개발자에 의해 결정되며 안드로이드 2.2 이전에 개발된 앱에 영향을 주지 않습니다.

앱 개발자는 루트 매니페스트 요소에서 android:installLocation 필드를 아래 값 중 하나로 설정할 수 있습니다.
> internalOnly: 내부 저장소에만 설치하기. 내부 저장 공간이 부족하면 저장 공간 에러 발생.
> preferExternal: 안드로이드 시스템에서 외부 저장소에 앱을 설치하기. 저장 공간이 없을 경우, 해당 앱은 내부 저장소에 설치됨.
> auto: 안드로이드 시스템에서 최적의 설치 장소를 결정. 디폴트 시스템 정책은 내부 저장소에 먼저 앱을 설치. 시스템 저장 공간이 부족할 경우, 애플리케이션은 외부 저장 장치에 설치됨.

installLocation이 명시되지 않은 경우 (안드로이드 2.2 이전 버전 애플리케이션의 경우), 애플리케이션은 내부 저장소에 설치됩니다. 애플리케이션 업데이트는 디폴트로 기존 설치 장소가 유지되지만, 개발자가 업데이트에서 installLocation 필드를 변경할 수 있습니다. 외부 저장 장치에 설치 가능한 애플리케이션을 이전 버전 디바이스에 설치한다고 해도 호환성에는 문제가 없으며, 해당 애플리케이션은 내부 저장소에 설치되게 됩니다.

애플리케이션 개발자는 adb 설치 플래그로 개발 중인 코드를 외부 저장소에 명시적으로 설치할 수 있습니다 (내부 저장은 -f, 외부 저장은 -s를 사용하여 installLocation 필드를 오버라이드). 또한 adb shell pm 코맨드로 디폴트 설치 장소를 오버라이드하여 SD 카드에 애플리케이션 설치를 검증 및 테스트해 볼 수 있습니다.

adb shell pm setInstallLocation option
*option은 아래 항목 중 하나:
> 0 [auto] 시스템이 결정
> 1 [internal only]
> 2 [external]

현재 설치 장소는 아래 코맨드를 통해서 받을 수 있습니다.
adb shell pm getInstallLocation

SD 카드에 설치할 준비가 되지 않을 경우, 해당 디폴트를 변경하면 애플리케이션이 오동작할 수 있음을 주의하세요.

USB 대용량 저장소 인터렉션

안드로이드 시스템은 SD 카드에 저장된 애플리케이션의 ADK를 안전한 애플리케이션 전용 컨테이너에 저장합니다. ApplicationInfo 오브젝트 안에 있는 flagFLAG_EXTERNAL_STORAGE는 애플리케이션이 SD 카드에 설치되어 있다는 것을 알려줍니다. 이 저장 공간은 SD 카드에 저장된 앱이 삭제되면 제거됩니다.

안드로이드 디바이스에서 SD 카드가 언마운트되면, SD 카드에 설치된 애플리케이션을 더 이상 사용할 수 없습니다. 내부 저장소는 그대로 남아 있으며 해당 앱은 SD 카드를 다시 넣지 않고도 삭제될 수 있습니다.

안드로이드 프레임워크에서는 몇몇 브로드캐스트 인텐트를 제공하여 론처 등과 같이 다른 애플리케이션의 리소스에 접근하는 애플리케이션 (소규모) 종류를 지원합니다.

> SD 카드가 언마운트되면, 브로드캐스트 인텐트에 있는 추가 속성을 통해서 비활성화 앱 목록 및 이에 상응하는 애플리케이션 uid 목록과 함께 ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE
> SD 카드가 마운트되면, 브로드캐스트 인텐트에 있는 추가 속성을 통해서 활성화된 애플리케이션과 이에 상응하는 애플리케이션 uid 목록과 함께 ACTION_EXTERNAL_APPLICATIONS_AVAILABLE

ACTION_PACKAGE_ADDED, ACTION_PACKAGE_REMOVED 등과 같은 브로드캐스트 인텐트를 처리하는 애플리케이션은 추가적인 알림을 처리하게 됩니다. 애플리케이션이 내부에서 외부 저장 공간으로 (혹은 그 반대로) 옮겨지는 경우, 애플리케이션은 먼저 비활성화되었다가 (브로드캐스트 인텐트 ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE 포함), 에셋 리소스가 복사되고 나서 애플리케이션이 활성화됩니다 (브로드캐스트 인텐트 ACTION_EXTERNAL_APPLICATIONS_AVAILABLE 포함).

보안 및 성능에 주는 영향

SD 카드에 있는 애플리케이션은 Linux의 루프백 인터페이스로 마운트되고 디바이스 전용키로 암호화되기 때문에 다른 디바이스에서 암호를 해독할 수 없습니다. 이는 보안 수단이며 복사 방지를 제공하지는 않는다는 점을 주의하세요. 해당 앱들은 디바이스 내부 저장소에 설치된 보통 애플리케이션의 리소스처럼 모든 사용자에게 읽기 권한을 허용합니다. 복사가 방지된 애플리케이션은 외부 미디어에 설치할 수 없습니다. 안정성을 위하여 시스템 애플리케이션의 업데이트도 외부 매체에 설치될 수 없습니다. 외부 저장 장치에 저장된 애플리케이션 리소스는 읽기만 지원하며, 따라서 SD 카드에 애플리케이션 로딩 및 론칭에 성능 이슈는 없습니다.

SD 카드 콘텐츠 교환 혹은 이동

안드로이드 디바이스에서 SD 카드를 교환할 때 언제나 그렇듯, 이전 카드에서 새로운 카드로 콘텐츠를 물리적으로 복사하는 경우 시스템은 아무 변화도 없었던 것처럼 새로운 카드에서 데이터를 사용하게 됩니다. SD 카드에 설치된 앱의 경우에도 마찬가지입니다.

SD 카드에 설치하지 않아야 하는 경우

SD 카드에 앱을 설치함으로 얻는 장점은 간단합니다. 바로 저장 공간을 확보하기 위한 다툼이 줄어든다는 것입니다. 하지만 SD 카드가 제거되거나 USB 대용량 저장 모드일 경우에 앱이 비활성화된다는 가장 분명한 대가를 치러야 합니다. 단지 인터렉티브 액티비티가 아니라 서비스를 실행하는 것을 포함합니다. 이밖에도 장치 제거는 애플리케이션의 위젯, 입력 방식, 계정 관리자, 장치 관리자, 라이브 월페이퍼, 라이브 폴더 등을 비활성화하며 다시 활성화시키기 위해서는 사용자의 명시적 동작이 필요로 합니다.

안드로이드 디자인 문서 - 방향 탐색 (Navigation)

Tuesday, February 5, 2013

* 많은 안드로이드 앱에서 Back 및 Up 버튼 동작이 일관되지 않게 동작함으로 인해서 사용자들이 불편을 겪는 문제가 발생하고 있습니다. 해당 버튼들의 동작에 대한 개발자의 이해를 돕고자, 안드로이드 디자인 가이드에서 Navigation (방향 탐색) 섹션을 한글 문서로 포스팅합니다. 방향 탐색 기능 구현에 참고하시기 바랍니다.
이전(Back) 및 상위(Up) 키로 방향 탐색원문 링크: http://developer.android.com/intl/ko/design/patterns/navigation.html
전반적인 사용자 경험에 있어서 일관적인 방향 탐색 기능을 제공하는 것은 필수적인 요소입니다. 일관성 없고 예상에 벗어나는 기본 탐색 기능처럼 사용자를 실망시키는 것도 드물겠죠. 안드로이드 3.0 에서는 글로벌 방향 탐색 동작에 중요한 변경 사항을 도입했습니다. 이전 및 상위 방향 탐색을 위한 본 가이드라인을 신중하게 이행하여 사용자가 예상 가능하고 신뢰할 수 있는 방향 탐색 기능을 제공하세요.

안드로이드 2.3 이하 버전에서는 앱 내부 탐색을 지원하기 위해서 시스템 이전(Back) 버튼에 의존했습니다. 하지만 안드로이드 3.0 에서는 액션바를 선보임으로, 앱 아이콘과 왼쪽 방향 탈자 기호( < )로 이루어진 제 2의 방향 탐색 장치인 상위(Up) 버튼이 소개되었습니다.

상위(Up) vs. 이전(Back)

상위 버튼은 화면간 계층 관계에 근거하여 앱 내에서 방향탐색을 하기 위해서 사용됩니다. 예를 들어, A 화면 에서 아이템 목록을 보여주면 아이템을 선택하여 B 화면(아이템 세부 내용 표시)으로 이동하게 되며, B 화면에서는 A 화면으로 돌아가기 위해서 상위 버튼을 제공해야 합니다.

화면이 앱에서 최상단에 있는 경우 (즉, 앱의 홈에 있는 경우), 상위 버튼은 보이지 않도록 합니다.

시스템 이전 버튼은 사용자가 최근에 본 화면 기록을 통해서 역순으로 탐색을 할 때 사용됩니다. 대체적으로 이전 버튼은 앱의 상하 계층이 아닌, 화면 간에 일시적인 관계에 근거하여 동작합니다.

이전에 본 화면이 현재 화면의 상위에 있을 경우, 이전 버튼을 누르면 상위 버튼을 누르는 것과 동일하게 동작하며 이는 흔히 발생하는 동작입니다. 하지만 사용자가 앱 안에서 머무르도록 하는 상위 버튼과 다르게 이전 버튼은 홈 스크린이나 다른 앱으로 사용자를 이동시킬 수 있습니다.

이전 버튼은 다음과 같이 화면 간 탐색과 직접적으로 연관되지 않은 몇몇 기능을 지원합니다.

플로팅 창 제거하기 (대화 상자, 팝업)
컨텍스트 액션바 제거, 선택 항목에서 하이라이트 제거하기
온스크린 키보드(IME) 감추기

앱 내에서 탐색하기

다중 진입점을 가진 화면 이동

어떤 화면은 앱의 계층 간에 엄격한 상하 구조를 가지고 있지 않아서 여러 진입점을 통해서 접근할 수 있습니다. 일례로 설정(Setting) 화면의 경우, 앱 내의 어떤 화면에서도 해당 화면에 접근할 수 있습니다. 이러한 경우에 상위 버튼은 이전 버튼과 동일하게 자신을 호출했던 화면으로 돌아가도록 합니다.

화면 내에서 뷰 변경하기

화면에서 뷰 옵션을 변경하는 경우에는 상위 또는 이전 버튼 동작을 변경하지 않습니다. 화면은 앱 계층 구조 안에서 여전히 동일한 위치에 있고 어떠한 탐색 기록도 새로 생성하지 않기 때문입니다. 이러한 뷰 변경의 예는 다음과 같습니다.

탭 및 또는 좌우 스와이프를 사용하여 뷰 전환
드롭다운을 사용하여 뷰 전환
목록 필터링
목록 정렬
표시 문자 변경 (줌 등)

동일 계층에 있는 화면 간 탐색

아이템 목록에서 각 아이템의 세부 내용로 이동하는 탐색을 앱에서 지원하는 경우, 해당 아이템에서부터 목록의 이전/이후 아이템으로 직접 이동할 수 있도록 지원하는 것이 바람질 할 때도 있습니다. 예를 들어 Gmail의 동일한 받은 편지함 내부의 메일에서 왼쪽 혹은 오른쪽으로 스와이프하여 신규 혹은 이전 메일을 쉽게 확인할 수 있습니다. 이때 화면 내에서 뷰를 변경하는 것과 마찬가가지로, 방향 탐색은 상위 또는 이전 버튼 동작을 바꾸지 않습니다.

하지만 참조하는 목록으로 엮여있지 않은 연관된 세부 뷰 사이를 브라우징할 때 주목할만한 예외 상황이 발생합니다. 예를 들어, Play 스토어에서 동일한 개발자가 만든 여러 앱이나 동일한 아티스트의 다양한 앨범을 검색하는 경우가 이에 해당됩니다. 이러한 경우에 각 링크를 따라가면서 기록을 생성하고, 이전 버튼을 통해서 이전에 본 화면으로 이동할 수 있습니다. 상위 버튼은 이러한 연관된 화면을 거치지 않고 가장 최근에 본 컨테이너 화면으로 이동해야 합니다.

세부 뷰에서 제공하는 정보에 근거하여 더욱 스마트한 상위 버튼 동작을 구현할 수 있습니다. 위에서 설명한 Play 스토어 예제를 연장해서, 사용자가 도서를 확인한 이후 해당 내용을 영화로 각색한 정보를 확인하기 위해서 세부 페이지로 이동했다고 가정해 봅시다. 그러한 경우에 상위 버튼은 사용자가 이전에 본적이 없는 컨테이너(영화)로 이동하게 할 수 있습니다.

홈 스크린 위젯 및 알림을 통해 앱으로 진입하기

홈 스크린 위젯이나 알림을 사용하여 사용자가 앱 계층안에 있는 화면으로 바로 이동할 수 있게 할 수 있습니다. 예를 들어, Gmail의 받은 편지함 위젯과 새 메일 알림은 모두 받은 편지함 화면을 건너뛰고 사용자가 해당 메일로 바로 이동할 수 있게 해줍니다.

이러한 경우 두 가지 모두, 상위 버튼은 다음과 같이 처리합니다.

도착 화면이 일반적으로 앱 내의 특정 화면에서 출발하는 것이라면 상위 버튼은 해당 화면으로 이동해야 합니다.
그렇지 않으면 상위 버튼은 앱의 최상위(“홈") 화면으로 이동해야 합니다.

이전 버튼의 경우, 태스크의 백스택에 앱의 최상위 화면으로 이동하는 모든 상위 탐색 경로를 삽입하여 방향 탐색을 더욱 예측 가능하게 만들어야 합니다. 이는 어떻게 앱에 진입했는지 망각한 사용자가 앱에서 나가기 전에 해당 앱의 최상위 화면으로 이동할 수 있게 해줍니다.

예를 들어 Gmail의 홈 스크린 위젯은 메일 쓰기로 바로 진입하는 버튼을 제공합니다. 메일 쓰기 화면에서 상위나 이전 버튼을 누르면 먼저 받은 편지함으로 이동하고, 받은 편지함에서 이전 버튼을 누르면 홈으로 돌아갑니다.

간접 알림 (Indirect notifications)

앱이 동시에 다양한 이벤트 정보를 표시해야 할 경우, 사용자를 삽입 화면(interstitial screen)으로 이동하게 하는 단일 알림을 사용할 수 있습니다. 이 화면은 이벤트를 간단히 설명하고 사용자가 해당 앱으로 진입할 수 있도록 경로를 제공합니다. 이러한 형태의 알림을 간접 알림(indirect notifications)이라고 합니다.

일반적인(직접) 알림과는 다르게, 간접 알림의 삽입 화면에서 이전 버튼을 누르면 백스택에 다른 화면이 추가되지 않고 알림이 발생한 시점으로 사용자를 이동시킵니다. 사용자가 삽입 화면에서 앱으로 진행하면, 상위 버튼과 이전 버튼은 위에 설명된 대로 삽입 화면으로 복귀하지 않고 일반적인 알림과 마찬가지로 동작하여 앱 내에서 탐색하게 됩니다.

예를 들어 Gmail 사용 중에 캘린더로부터 간접 알림을 받았다고 가정해 봅시다. 해당 알림을 터치하면 삽입 화면이 열리고, 다른 이벤트 알림도 보여주게 됩니다. 사용자가 이전 버튼을 누르면 Gmail로 복귀하게 됩니다. 특정 이벤트를 터치하면 삽입 화면에서 나오게 되고 캘린더 앱으로 가서 이벤트 세부 사항을 보여주게 됩니다. 이벤트 세부 사항에서 상위 버튼과 이전 버튼을 누르면 캘린더의 최상위 레벨로 이동하게 됩니다.

팝업 알림

팝업 알림은 알림 서랍(notification drawer)에 들어가지 않고 바로 사용자에게 보여주는 알림입니다. 팝업 알림은 사용자 응답이 적시에 요구되는 경우 및 사용을 중단하는 것이 필요한 경우에 한정하여 드물게 사용됩니다. 예를 들어, 토크(Talk)는 영상 채팅 초대를 통보하기 위해 이러한 형태의 알림을 사용하며 몇 초 후에 자동으로 종료됩니다.

팝업 알림의 탐색 방식은 간접 알림의 삽입 화면에서 사용하는 방식과 밀접합니다. 이전 버튼은 팝업 알림을 제거합니다. 사용자가 팝업을 통해 앱으로 진입하면 상위 및 이전 버튼은 표준 알림으로 앱 내를 탐색하는 방식과 동일하게 동작합니다.

앱 간의 방향탐색

안드로이드 시스템의 근본적인 강점 중에 하나는 앱이 다른앱을 실행해서 사용자가 한 앱에서 다른 앱으로 직접 이동할 수 있게 해주는 기능입니다. 예를 들어, 사진 찍는 기능이 있는 어떤 앱에서 카메라 앱을 활성화시킬 수 있는데, 카메라 앱은 사진을 관련 앱으로 리턴해 줍니다. 개발자는 쉽게 다른 앱의 코드를 사용할 수 있고 사용자는 일반적으로 수행되는 동작에 일관적인 경험을 누릴 수 있기에 개발자와 사용자 모두에게 큰 유익을 줍니다.

앱간 탐색을 이해하려면, 아래에서 다루는 안드로이드 프레임워크 동작을 이해하는 것이 중요합니다.

액티비티, 태스크, 인텐트

안드로이드에서 액티비티(activity)는 사용자가 수행할 수 있는 모든 관련 동작 및 정보에 관한 화면을 정의하는 애플리케이션 컴포넌트입니다. 앱은 본인이 생성한 액티비티와 다른 앱에서 재사용한 액티비티로 구성되어 있는 액티비티의 집합입니다.

태스크(task)는 사용자가 어떤 목적을 달성하기 위해서 따르는 일련의 액티비티입니다. 단일 타스크는 단 하나의 앱에서 제공하는 액티비티만을 사용할 수도 있고, 여러 다른 앱의 액티비티를 사용할 수도 있습니다.

인텐트(intent)는 어떤 앱이 동작 수행을 하는데 다른 앱의 도움을 받고자 한다는 신호를 보내는 매커니즘입니다. 앱의 액티비티는 어떤 인텐트에 응답을 보낼 수 있는지 알려줄 수 있습니다. “공유하기"와 같이 흔히 사용하는 인텐츠의 경우, 사용자는 해당 요청을 수행할 수 있는 여러 앱을 설치했을 수도 있습니다.

예제: 공유 지원을 위한 앱간의 방향탐색

액티비티, 태스크, 인텐트가 어떻게 동작하는지 이해하기 위해, 한 앱에서 다른 앱을 사용하여 어떻게 콘텐츠를 공유할 수 있는지 생각해 보겠습니다. 예를 들어, Play 스토어 앱을 홈에서 론치하는 것은 새로운 태스크 A를 시작하는 것입니다 (아래 그림 참조). Play 스토어에 들어가서 탐색하고 홍보 도서의 세부 사항을 살펴보기 위해 터치하면 다른 액티비티를 추가하여 연장함으로써 사용자는 동일한 태스크에 머물러 있습니다. 공유하기 액션을 실행하면 공유하기 인텐트를 처리하기 위해 등록된 액티비티 목록( 다른 앱에서 제공하는)을 보여주는 대화상자를 보여줍니다.

사용자가 Gmail로 공유하기를 선택했을 경우, Gmail의 메일 쓰기 액티비티가 새로운 태스크가 생성되는 것이 아니라 태스크 A에 연이어 추가됩니다. Gmail이 백그라운드로 실행되는 자신의 태스크를 가지고 있다 하더라도 아무 영향도 받지 않습니다.

메일 쓰기 액티비티에서, 메일을 보내거나 이전 버튼을 터치하면 사용자가 도서 세부 항목 액티비티로 돌아가게 됩니다. 이어서 이전 버튼을 터치하면 Play 스토어를 통해서 되돌아가게 되어 결국에는 홈 화면에 이르게 됩니다.

하지만 메일 쓰기 액티비티에서 상위 버튼을 터치하면 사용자는 Gmail에 남고자 하는 의지를 보이는 것입니다. Gmail의 메일 목록 액티비티가 보이고, 이를 위해 새로운 타스크 B가 생성됩니다. 새로운 태스크는 항상 홈에 시작을 두고 있기 때문에, 메일 목록에서 이전 버튼을 터치하면 홈으로 복귀하게 됩니다.

태스크 A는 백그라운드에 남아있기 때문에 사용자가 이후에 돌아올 수 있습니다 (예를 들어, 최근 앱 화면 화면을 통해서). Gmail이 이미 백그라운드에서 실행하는 자신의 태스크를 가지고 있다면, 태스크 B로 대체되게 됩니다. 이전 상황은 사용자의 새로운 사용 목적에 따라 제거되는 것입니다.

앱 계층 내에서 액티비티가 인텐트를 처리하기 위해 등록하는 경우에 상위 탐색 구현 방법에 대한 가이드는 홈 스크린 위젯 및 알림을 통해서 앱으로 진입하기를 확인하세요.

개발자 가이드

올바른 상위 버튼 및 이전 버튼 탐색으로 앱을 개발하기 위한 세부 정보를 확인하려면, 각각 Implementing Ancestral Navigation 과 Implementing Temporal Navigation를 참조하세요.

한국 구글 개발자 사이트를 홍보해 주세요!

Sunday, February 3, 2013

한국 구글 개발자 사이트(http://googledevkr.blogspot.kr/)에서는 구글에서 진행하는 다양한 개발자 관련 행사(핵페어, 코드랩, 해커톤, GCi 등)는 물론, 구글 제품 개발 기술과 관련한 중요한 내용들이 공지되고 있습니다.
구글의 중요한 최신 개발 정보를 많은 사람들에게 전달하고자 하는 취지에서, 본 사이트를 자신이 이용하는 SNS나 인터넷 게시판에 공개글로 홍보해 주시는 분들을 추첨하여 소정의 상품을 드리고자 합니다!
홍보글을 올리신 분은 여기에 자신의 이메일과 자신이 올린 게시글의 링크를 입력해 주세요. :)
또한 본 사이트의 콘텐츠 이메일 구독을 신청하시는 분들도 추첨하여 상품을 드리고자 합니다. 블로그의 <이메일 가입>란에 자신의 이메일을 입력하기만 하면 바로 신청됩니다.

* 본 이벤트는 중요도 있는 최신 개발 정보를 가능한 많은 개발자들에게 전달하고자 하는 취지에서 진행되고 있는 행사로, 2월 4일부터 2월 18일까지 2주간 유효하며 참여하신 분들 중에서 임의로 추첨하여 총 30명에게 선물을 지급할 예정입니다. 많은 관심 부탁드립니다. :)

Korea Blog