Designing Beautiful Apps without Designer - Google HackFair 세션

어제 오늘(2012년 11월 17-18일) 구글 핵페어가 있었습니다. 많은 세션들이 있었는데 18일 세션중에 구글에서 근무하는 UX디자이너분 (Tony Kim)이 진행하신 세션이 기억에 남습니다.  세션을 들으면서 인상적인 내용만 메모차원에서 남겨봅니다. 추후에 비디오가 공개된다고 하니 한번 꼭 들어보세요! [추가 2012/12/10] 발표자 분이 내용정리를 해주셨습니다. 아래 링크에서 확인하세요~ http://uxfactory.com/921 [추가] 프리젠테이션 파일이 공개되었습니다. https://docs.google.com/file/d/0ByZGJ926FVmTeXZpbmZWS1Z0VEU 구글은 엔지니어의 천국, 아시아 ux 직군 직원수가 1자리수!! 디자이너가 참여하는 프로젝트를 럭셔리 프로젝트 라고 부를 정도로 디자이너가 참여하지 않는 프로젝트가 많다. 구글이 실패한 플젝들을 보면 buzz, answers, dodgeball, wave, google x, notebook 등등등.. 이중 Wave를 보면 기능은 정말 많았다. 그래서 사용자들이 이걸 어떻게 활용해야할지 혼란스러워했다. 너무 많은 feature를 가진 앱은 실패하기 쉽다. 그럼 과연 좋은 앱이란? 제대로된 1개의 기능만 제공하는 것! 10가지의 구글 디자인 원칙 1. Useful 2. Fast :milisecond 단위의 가이드를 가지고 있다. 버튼 응답속도는 얼마 안에.. 3. Simple 4. Engaging 5. Innovate 6. Universal 7. Profitable 8. Beautiful 9. Trustworthy 10. Pesonable ; Add a human touch. Cafe studies : 구글 방문자들에게 테스트 Lab  Field : 실 환경에서 테스트(가정방문) AB테스트 : log d...

안드로이드 개발자 간담회 - Definitive Android Design

9월 17일 저녁 안드로이드 개발자 간담회가 구글코리아에서 있었습니다. 이 간담회에는 아시아지역의 안드로이드 Developer Advocate들이 국내의 안드로이드 개발자들을 대상으로 여러 주제에 관해 세션을 진행했습니다. 그 중 Definitive Android Design 세션의 내용을 좀 자세히 정리해봅니다. Definitive Android Design 이 세션은 안드로이드의 다양한 화면 구성에 대응하는 방법에 대한 전반적인 기술정보를 공유하는 자리였습니다. 이미 많은 내용들이 안드로이드 디자인가이드 문서 에 공개되어 있고 커뮤니티에 의해 한글화된 문서  도 있어 많은 분들이 알고 계신 내용이지만 총정리를 해주더군요! 안드로이드 개발자들은 꼭 공부하고 기억해야할 내용입니다. Devices and Displays 안드로이드는 이제 많은 기기에서 사용됩니다. 그 기기들은 매우 다양한 화면 크기와 형태를 가지고 있습니다. 각각의 단말에 일일히 대응하는것은 매우 어려운 일이 되겠지만 안드로이드 프래임웍에서는 이를 쉽게 만들어주는 많은 기능을 이미 가지고 있습니다.  DIP(device independent pixel)를 사용하자. 초기에 안드로이드 개발되는 앱들이 dp단위 대산 px단위를 사용해 다양한 단말화면에서 화면이 엉망으로 표시되는 경우가 종종 있었습니다. dp단위를 사용하면 다양한 단말에서 동일한 크기의 버튼, 이미지를 기대할 수 있습니다. 아래 그림은 각각의 dpi 에서 Baseline안에 표시되기에 필요한 이미지의 크기를 나타내 주고 있습니다.  안드로이드 프래임웍에서는 특정 dpi의 이미지가 다른 dpi 단말에서 보여지게 되는 경우 이미지를 자동으로 Scale up하거나 Scale down하여 화면에 보여줍니다. Scale up이되는 경우에는 아이콘이 좀 뭉개지는 현상이 발생하기도 하고 또 매번 사용시마다 단말상에서 Scaling 작업이 이루어지게되므로 이...

Fragment는 왜 만들어졌을까요?

아래내용은  "Google I/O 2012 - So You've Read the Design Guide; Now What" 세션에 나온 Fragment에 관한 정보를 정리한 것입니다. Activity와 View를 가지고도 Dynamic한 UI를 만들 수 있습니다. View와 Activity를 아래와 같이 구성한다고 생각해봅시다. 화면 구성요소를 ListView와 DetailView로 구분하고 이를 담고 있을 Activity를 생성합니다.. Single-Pane화면에서는 두개의 Activity가 사용되고 Dual-Pane구성에서는 하나의 Activity를 사용합니다. Activity+View를 사용한 구성 이렇게 구성되 있는 상태에서 카메라 기능을 사용한다고 생각해 봅시다. 카메라 기능을 사용하기 위해서는 아래와 같은 코드가 필요합니다. Intent camera = new Intent ( MediaStore . ACTION_IMAGE_CAPTURE );   startActivityForResult ( camera , RESULT_PICTURE_RESULT ); 이런 식으로 startActivityForResult를 호출해 onActivityResult를 통해서 받은 데이터를 처리하게 될것입니다. Activity+View를 사용한 구성에서는 위와 같은 코드가 View의 내부에 위치하게 될겁니다.(View코드를 재활용한다고 했을때요!) 하지만 코드에서 필요한 중요 기능들은 Activity의 내부에 포함되어 있습니다. ( startActivityForResult나 onActivityResult함수) 위의 그림과 같은 구성에서는 그 기능들이 ListActivity와 DetailActivity 의 onActivity에서 View로 이벤트를 위임해주는 구현이 각각 들어가야합니다. 이것은 반복적이고 매우 귀찮은 작업입니다. 또 화면별 메뉴구성을 다르게하기 위한 코드(onOptionMenuXXX 들)나...

Nexus 7은 흥미로운 화면크기를 가졌습니다.

안드로이드 프래임웍의 어머니인 Dianne Hackborn 의 https://plus.google.com/105051985738280261832/posts/6eWwQvFGLV8 에 대한 번역글 입니다. Nexus 7은 흥미로운 화면크기를 가졌습니다. 7 인치. 800x1280. "tvdpi" density (수치로 보면 213). dp단위로는 600 x 961 먼저 화면크기에 대해 이야기해보죠. raw해상도를 무시하면 이것은 보통의 7인치 타블랫과 마찬가지가지인 7" 타블랫입니다. 600x1024 화면을 가지는 몇몇 7"타블랫이 있긴한데 그것들은 다른 density(mdpi)를 가지고 있습니다. Density로만 따지면 우린 동일한 화면 공간을 가지고 있습니다. 600x961 또는 600x1024는 각각 16:10 또는 16:9 화면의 차이일 뿐입니다. 가장 크게보면, 최신 안드로이드 화면을 분류하는 기준인 "작은 화면 폭"의 정의의 측면에서 이들은 모두 -sw600dp입니다. 몇몇 분들이 Nexus 7인 10"UI의 화면 사이즈를 그져 화면 크기만 줄인게 아니다라는 글을 남기셨네요. 어느 정도 사실입니다. 물론 큰 화면의 phone UI도 아닙니다. 시스템과 앱에서는 각각 가장 최적으로 동작하는 UI를 사용합니다. 예를 들어 시스템 UI(Status bar나 Navigation bar, 설정화면)에서는 600dp화면에서 너무 조밀하기 때문에 Phone UI를 사용합니다. 다른 앱들은 타블랫 UI를 섞어 사용합니다. -- 예를 들면 Gmail앱은 대화목록에서는 타블랫 UI를 사용하고 메시지 화면에서는 가로모드, 세로모드에 따라서 각각 폰과 같은 단일 pane UI, 타블랫과 같은 dual-pane 을 사용합니다. 기존의 PhoneUI을 확대시켜 큰 화면을 지원하려는 개발자에게는 이것은 화면 구성의 큰 변혁이 일어나야 한다는 걸 의미합니다. 그리고 layout 담당자에게 모...

android.support.v7.widget.GridLayout 사용하기

Android 4.0 에서 제공되기 시작한 GridLayout은 화면을 구성하는 데 매우 편리한 구성요소입니다. 하지만 사용할 수 있는 API 레벨이 14!!! 아마 왠만한 앱 개발자라면 그 아무도 GridLayout을 함부로 사용할 수는 없었을 겁니다. ㅠ.ㅠ 그런데 Support Library r7 부터 이 문제를 해결해줄 android.support.v7.widget.GridLayout 가 조용히 등장했습니다.  하지만 안드로이드 개발자 블로그에도, 개발자 사이트에서도 검색조차 잘 안되고 있는 슬픈 상황입니다. Support라이브러리를 통해 GridLayout를 한번 사용해 볼까요? 기능 일단 기능은  http://android-developers.blogspot.kr/2011/11/new-layout-widgets-space-and-gridlayout.html  에서 말하고 있는 android.widget.GridLayout 완전히 동일합니다. 간단히 설명하면 화면을 Grid영역으로 나누고 각각의 자식요소들의 위치와 크기를 지정하는 방식으로 레이아웃을 구성하는 방법입니다. GridLayout를 사용하면 기존에 Layout여러개를 중첩해서 구성해야했던 구조를 간단하게 구현할 수 있습니다. 내 앱 프로젝트에서 사용하기 1. ADT업데이트 먼저 ADT와 SDK Tools을 최신버전으로 업데이트 합니다. (현재 최신 버전은 r19로 GridLayout이용하기 위해서는 r17이상으로 업데이트되어야 합니다.) (SDK가 설치된 경로는 ANDROID_SDK 라 칭합니다.) $ANDROID_SDK/extras/android/support/v7/gridlayout/ 위 경로에 안드로이드 라이브러리 프로젝트의 형태로 gridlayout support라이브러리가 자리잡고 있습니다. 2. 프로젝트 import 이클립스에서 이 경로에서 프로젝트를 import ...

Ubuntu 10.04에 Sun Java 6 JDK 설치하기 (2012년 기록)

기록의 적용 환경: 아래 내용은 Ubuntu 10.04에서 작업한 2012년 기록입니다. 사용 중인 운영체제 버전과 저장소가 다른 경우에는 그 환경에 맞는 설치 안내를 확인하세요. ubuntu에 jdk 패키지가 빠진 이후로 설치가 매우 어려워졌다. 다행히 debian쪽에는 패키지가 남아 있어서 그쪽을 사용하는 방법으로 시도해보기로 했다.  sudo add-apt-repository "deb http://ftp.debian.org/debian squeeze main contrib non-free" sudo apt-get update sudo apt-get install sun-java6-jdk 이렇게 했는데 데비안 apt저장소 키가 등록이 안됬다고 나온다. 이럴땐 서버 gpg키를 받아서 등록해주자. (AED4B06F473041FA는 위에서 나온 에러에 포함) gpg --keyserver subkeys.pgp.net --recv-keys AED4B06F473041FA gpg -a --export AED4B06F473041FA | sudo apt-key add - 이렇게게 했는데도 로컬 apt저장소 용량이 작다고 나온다. 좌절하지 말고 설명대로 아래와 같이 저캐시 용량을 늘려준다. sudo vi /etc/apt/apt.conf.d/70debconf 맨 밑줄에  APT::Cache-Limit "100000000"; 추가 후에 sudo apt-get clean && sudo apt-get update --fix-missing 이렇게 삽질은 한 후에 누가 만들어 놓은 한방에 처리하는 스크립트를 찾았다. 하하하;;; https://github.com/flexiondotorg/oab-java6

Fragment 시작하기 - dfxkorea

DevFestX Korea 에서 안드로이드 Fragment에 관한 발표를 진행했습니다. 많은 분들이 관심을 보여주시고 발표후 직접오셔서 많은 질문 해주셨네요. 아주 재밌는 시간이었습니다. 특히 ViewPager에 대한 관심과 ActionBarSherlock 에 대해서 많은 관심을 갖고 계신것 같았습니다. 몇몇 질문에 대해서는 추가 포스팅을 통해 자세히 공유하도록 하겠습니다. :)

맥 파일시스템 확장 속성 변경하기

사내 공용 프린터 드라이버는 설치할때 마다 꼭 말썽을 피운다. 설치중에 항상 오류를 내는 것이다. 몇번 패키지 내부에 들어가서 preflight, postflight, VolumeCheck 파일에 실행권한을 주고 해결하곤 했는데 이번엔 제대로 동작하지 않았다. 직접 터미널로 들어가보니 평소에 보지 못하던 @ 표시가 눈에 띄었다. 이것은 무엇일까?  검색해보니 이것은 Extended file attribute 가 존재한다는 뜻! ( http://en.wikipedia.org/wiki/Extended_file_attributes ) 이 속성은 ls 옵션엔 -@를 추가하면 확인이 가능하다. 확인해보니 문제의 파일들에 대해서 com.apple.quarantine 속성이 걸려있었다. $ xattr -p com.apple.quarantine preflight 0006;4f8cf8e5;Chrome;95741EED-A78B-4BC3-931A-B76D7486172A|com.google.Chrome 이 속성은 다운로드된 파일에 대해서 다시 한번 확인을 묻는데 사용되는 속성이다. 결국 이 속성 때문에 제대로 설치가 진행되고 있지 않았던 것이다. $ xattr -d com.apple.quarantine * 위 방법으로 속성을 제거한 후 설치에 성공!

ADT업데이트(r17)후 발생하는 NoClassDefFoundError 해결하기

ADT업데이트 후 혹은 이클립스 재설치후 빌드만 다시했을 뿐인데 갑자기 멀쩡하던 앱이 죽기 시작합니다. 난 아무것도 한게 없는데 왜 이런 시련이 왔을까요? 과연 무엇이 문제일까요? 원인 이름 그대로 Class가 패키지에 함께 포함되지 않아서 발생한 문제입니다. 무엇이 이 문제를 발생시켰을 까요? ADT가 업데이트되면서 의존성을 체크하는 루틴이 크게 변경되었습니다.(자세한 내용는 요기 참고하세요.  Android 프로젝트 의존성 처리 방식 변경 ) 기존 jar를 추가하면서 이클립스에서 build path를 추가했던것 기억하시죠? 수동 Build Path추가 일반적인 경우 libs 폴더에 jar프로젝트를 넣어두고 이렇게 수동으로 빌드패스를 추가해서 사용해 왔습니다. 그런데 이번 ADT업데이트 이후에 Android Dependencies가 만들어지면서 libs내의 jar를 자동으로  빌드패스에 추가가 됩니다. 이 jar들은 배포시에 함께 패키징 됩니다. 그럼 아무런 문제가 없지 않느냐? 맞습니다. libs폴더에 기존에 jar파일들을 넣어 두셨다면 문제가 발생하지 않습니다. libs 대신에 lib 폴더(또는 다른폴더)에 jar를 넣어두었기 때문에 NoClassDefFoundError가 발생하게됩니다. 해결방법 1) 가장 쉽고 옳은 방법 기존에 jar가 들어있는 폴더이름을 libs 로 변경하세요. 폴더를 libs로 변경하신후 기존 ADT r16이하를 사용하는 개발자 분들을 위해서 수동으로 빌드패스를 추가해주셔도 좋습니다. 하지만 공동 개발자들의 수가 그리 많지 않다면 ADT를 r17로 업데이트 하는게 더 좋은 방법입니다. (ADT r17버전은 기존 버전보다 개선사항이 매우 많습니다. http://developer.android.com/sdk/eclipse-adt.html  , SDK Tools업데이트도 꼭 함께 해주세요.) 2) 쉽지만 안좋은 방법 안드로...

Android 프로젝트 의존성 처리 방식 변경

이 글은 아래 링크의 대한 번역글입니다. http://tools.android.com/recent/dealingwithdependenciesinandroidprojects 이번(r17) Android SDK 부터 안드로이드 프로젝트에서 라이브러리 의존성을 체크하는 방식이 개선되었습니다. 먼저 Ant-based 빌드 시스템과 이클립스 플러그인이 동일하게 동작하도록 변경되었습니다. 프로젝트는 소스폴더와 라이브러리 프로젝트, jar파일 의존성을 갖습니다. 이제 라이브러리 프로젝트를 project.properties 에 넣기만 하면 자동으로 다음 경로들에서 의존성을 찾아 냅니다. 프로젝트의 libs/*.jar 라이브러리 프로젝트의 생성물 라이브러리 프로젝트의 libs/*.jar  위 항목들과 프로젝트 소스의 컴파일 결과물이 함께 dex에서 처리되어 APK를 생성하게됩니다. 프로젝트들간에 동일한 jar를 사용하는 여러 라이브러리를 포함할 수 있기 때문에 빌드시스템은 모든 경로에서 jar를 찾아내 중복되는 jar를 제거합니다. 이로 인해 흔히 보았던 문제인 "already added"가 더 이상 발생하지 않을 것입니다. 중요한 변경사항 : 라이브러리 프로젝트가 R 클래스를 생성하고 패키징 하는 방식이 변경됨! 더 이상 R 클래스가 라이브러리 프로젝트의 jar 에 포함되지 않습니다. 라이브러리 프로젝트는 그들이 의존하는 라이브러리 프로젝트의 R클래스를 만들어 내지 않습니다. 메인 앱 프로젝트가 라이브러리에 포함된 R클래스를 그들 자체의 R클래스와 함께 만들어 집니다. 이것은 이제 라이브러리 프로젝트가 의존하는 다른 라이브러리 프로젝트의 R클래스를 가져오지 못함을 의미합니다. 이제는 앱의 R클래스가 모든 필요한 리소르를 모두 포함하고 있기 때문에 이는 더이상  필요하지 않습니다. (주 : 라이브러리 프로젝트에서 다른 라이브러리 프로젝트의 리소스를 참고가 더이상 불가능함을 의미합니다.) ...