오리대마왕님 텀블러 @kingorihouse - Tumblr Blog

구글 Apps Script 와 Firebase 연동하기

개요

예전에 구글 앱스 스크립트를 이용해 스프레드 시트 내용을 json으로 만들어 구글 드라이브에 올리고, 이 json을 구글 드라이브 호스팅을 이용해 호스팅하는 방법을 발표했다. 하지만 이제 구글 드라이브 호스팅이 중단되었기 때문에 이 방식은 더 이상 동작하지 않아, 세계최고의 안드로이드 앱인 PS4 News에도 문제가 생겼다.

그래서 요즘 핫한 firebase를 이용해 비슷한 동작을 하도록 수정했다. 이 글은 구글 앱스 스크립트를 이용해 firebase realtime db의 내용을 갱신하고, 이를 내려받는 방법을 소개한다.

최종 결과물은 아래와 같다. 최종 결과물이 너무 허접해도 놀라지 마시길.

왕오리님 여행기 사이트

스프레드 시트 생성

우선 제공할 내용을 담은 시트가 필요하다. 물론 이미 있다면 그대로 사용하면 되고. 이 시트에 앱스 스크립트를 추가해야 하기 때문에, 메뉴 중 Tools > Script editor를 선택해서 스크립트를 작성하자.

우선 내가 생성한 시트 내용은 다음과 같다.

이제 Tools > Script editor 에서 스크립트를 작성하자. 예제에선 시트 내용을 json으로 생성한다. 앱스 스크립트 관련 내용은 Google Apps Script를 참고한다. 아래와 같이 테스트 펑션을 만들어 두면, 스크립트 에디터에서 일부분을 테스트해보기 매우 편하다.

이렇게 만들어서 생성한 json 결과물은 다음과 같다. 콘솔에서 test_genData() 를 실행하고, 맥 기준 cmd+enter를 눌러 콘솔을 열면 다음 내용이 출력된다.

{tours=[{title=hongkong, articles=[{title=홍콩 여행1, url=https://brunch.co.kr/@kingori/6}, {title=홍콩 여행2, url=https://brunch.co.kr/@kingori/7}]}, {title=north_europe, articles=[{title=북유럽 여행1, url=https://brunch.co.kr/@kingori/10}, {title=북유럽 여행2, url=https://brunch.co.kr/@kingori/11}]}]}

Firebase 프로젝트 설정

DB 생성하고 테스트하기

firebase콘솔 > 새 프로젝트 만들기 메뉴를 이용해 프로젝트를 만든다. firebase엔 여러 기능이 있는데, 일단은 디비만 필요하니 요쪽만 들여다본다.

메뉴 중 Database 선택하고, 우선은 read / write 가 제대로 되는지부터 살펴봐야 하기 때문에 규칙 탭으로 이동해서, anonymous read / write 가 되도록 설정한다. 더 자세한 내용은 reference 문서 를 참고한다.

{ "rules": { ".read": true, ".write": true } }

이제 write 잘 되는 지 실행해보자. 명령창에서 대충 이렇게 입력하고 실행하면 콘솔의 디비에 내용이 들어온 걸 확인할 수 있다.

curl -X PUT -d '{ "first": "Jack", "last": "Sparrow" }' 'https://kingoritours.firebaseio.com/tours.json'

디비 내용이 수정된 걸 확인했다면 얼른 anonymous write 권한은 뺏어두자.

{ "rules": { ".read": true, ".write": false } }

권한 설정하기

아무나 write하진 못하게 막아두었으니, 이제 관리자만 내용을 update할 수 있도록 작업해야 한다.

fireabse rest api는 header나 parameter를 이용해 access token을 직접 넘겨서 인증을 할 수 있다. 이번 예제에선 어차피 관리자 혼자만 업데이트하면 되니까 이 내용만 살펴보자. firebase 콘솔의 auth 메뉴엔 여러 권한 관리 방법을 제공하는데, 관리자만 내용 update하는 경우엔 이쪽을 들여다 볼 필요가 없더라. 관리자의 access token만 잘 만들면 된다.

firebase 콘솔 좌상단의 톱니바퀴 > 권한을 누르면 "IAM 및 관리자" 페이지로 이동한다. 여기서 좌측 메뉴 중 "서비스 계정"을 선택하고,서비스 계정 만들기를 선택한다. 만들면 json 파일을 하나 다운로드 하는데, 이 파일은 잃어버리지 않도록 잘 관리해야 한다.

방금 만든 서비스 계정을 이용해 access token을 만들어야 하는데, 이 내용은 레퍼런스 문서에 잘 나와있다. 다만 java 예제코드만 나와있으니, 다른 언어 사용자라면 구글 oauth 관련 문서를 참고하자.

자바 기준으로 위 예제의 코드를 실행하려면 google auth client library가 필요하고, 이 라이브러리는 링크에서 받을 수 있다.

이제 access token도 구했으니, 앱스 스크립트로 이동해서 firebase 연동을 해 보자. 몇 번의 권한 팝업이 뜨고 실행에 성공할 것이다.

function exportToFirebase() { var options = { "method" : "put", "payload" : JSON.stringify(genData()) }; UrlFetchApp.fetch('https://kingoritours.firebaseio.com/tours.json?access_token=12345' , options); }

이렇게 만든 json은 브라우저에서도 쉽게 접근해서 확인할 수 있다.

하지만 이렇게 만든 access token 의 유효기간은 그리 길지 않기 때문에 주기적으로 실행되는 스크립트라면 어느새 access token이 만료되어 문제가 생긴다. 따라서 access token을 계속 발급받아야 한다.

access token을 발급받기 위해, 이 stackoverflow 링크에 언급된 앱스 스크립트 라이브러리를 사용했다. 스크립트 에디터의 Resources > Libraries 를 누르고, 라이브러리 이름 입력 란에 MJ5317VIFJyKpi9HCkXOfS0MLm9v2IJHf 를 입력한 다음, 다시 스크립트 에디터 메뉴 중 File > Project properties > Script properties 에 jsonKey 라는 키를 하나 만들고, 값은 아까 내려받은 json 파일의 내용을 모조리 붙여넣는다. 다음엔 라이브러리 readme 의 내용을 firebase에 맞게 다음과 같이 살짝 고치면 access token을 매번 생성할 수 있다

웹페이지 호스팅

이제 json까지는 쉽게 만들었는데, 만약 html 페이지로 보여주고 싶다면 firebase의 호스팅을 이용하면 된다. 호스팅은 로컬의 특정 디렉터리를 cli 도구를 이용해 firebase 쪽으로 올려주는 기능을 한다.

위에서 만든 json을 실제 보여주는 것 까지 해보려면 html 페이지가 필요해서 간단히 만들어보았다.

<html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script> <script type="text/javascript"> function fetchData() { $.getJSON( "https://kingoritours.firebaseio.com/tours.json" , function(data) { var table = $("#content") var html = ''; $.each( data.tours, function( k,v) { html = html+ '<tr><td rowspan="'+v.articles.length+'">'+v.title+'</td>'; $.each( v.articles, function(k,v) { if( k != 0 ) { html = html + '<tr>'; } html = html + '<td><a href="'+v.url+'">'+v.title+'</a></td></tr>'; }); }); $('#content tr:last').after(html); }); } </script> </head> <body> <table id="content"> <thead> <tr> <td>Tour name</td> <td>Article</td> </tr> </thead> <tbody> </tbody> </table> </body> <script type="text/javascript"> fetchData(); </script> </html>

cli 도구가 워낙 잘 만들어져있어서 하라는데로 하면 끝!

#firebase #google apps script

Android Weekly 171 ~ 180 리뷰

밀린 Android Weekly 몰아보기!

171

Testing Intents With Espresso Intents

오, espresso intent를 사용하면 espresso에서 간단하게 1) 외부에서 넘겨받을 인텐트의 값을 만들어낼 수도 있고, 2) 호출된 인텐트의 값이 제대로 들어왔는지 확인할 수 있네!

Unit Testing RxJava Observables and Subscriptions

RxJava를 안써서 잘 모르겠지만, 나중에 단위테스트라도 적용할라치면 도움이 될 듯 하다.

Observable 테스트 하고 싶다면 TestSubscriber 써라

subscribe 하는 클래스 동작 테스트하고 싶다면 observable 목킹하고, 기본 스케쥴러를 override

Observable 실행 훅을 등록해서 observable 트래킹하라.

Android Feature Graphic Generator

플레이 콘솔에 앱을 출시하려면 아이콘 외에도 몇 가지 이미지 리소스를 더 올려야 한다. 스샷은 어찌어찌 만들겠지만 피쳐 이미지만 해도 디자인이랑 친하지 않은 개발자에겐 만들기 귀찮은 노릇인데, 대충 글자만 휘갈긴 이미지를 손쉽게 만들 수 있는 사이트이다.

172

Speed up your app

도전적인 제목에 걸맞게 아주 훌륭한 글이다. Systrace, Traceview, AllocationTracker 등 여러 성능 측정 도구들을 소개하고, 메모리나 드로잉 쪽에서 신경써야 할 부분을 총망라한 글이다. 굳굳! 근데... 알아도 실상 몇개만 쓰게 되네.

Approaching Android with MVVM

data binding을 이용해서 안드로이드에 MVVM 모델을 구현하는 방법을 소개한다. 코드까지 제시한 꽤 친절한 포스팅이니 찬찬히 보면 도움이 될 듯 하다.

Archi

또 다른 MVP / MVVM 예제. 너무 많다 ㅎㅎ

173

Optimizing Android bytecode with ReDex

페이스북이 만든 코드 최적화 도구인 redex를 소개하는 글이다. proguard 등도 이미 bytecode 최적화를 하고 있는데, 어떤 점에서 더 나은 지 모르겠네.

Android development like a pro

fragment의 단점을 지적하며 presentation 계층을 도입했는데 내가 보기엔 fragment보다 훨씬 더 복잡해보이는데 내가 잘못 이해를 했나? 게다가 WeakReference까지 총출동하고 구현체 하나밖에 없을 interface를 선언하는건 좀 이해가 안된다. @_@

Async Android

여러 안드로이드의 비동기 구현 모델을 소개하며, RxJava의 상대적인 장점을 설명한다. 기승전RxJava.

Functional Android (II): Collection operations in Kotlin

kotlin엔 정말 다양한 collection 함수들이 있구나! 당장 써먹을 수 없어서 군침만 흘리게 되네.

Annotations to support your contracts

support annotation에 대한 간단한 소개이다. @IntDef 류, @Nullable 류, @UiThread 류의 애노테이션을 잘 쓰면 정적분석의 도움을 받아 잠재적 오류를 찾아낼 수 있으니 적극적으로 사용합시다!

ExplosionField

뷰를 폭발시키는 애니메이션을 제공하는 재밌는 라이브러리이네. 우와! 소스를 살짝 보니 ValueAnimator를 만들어서 뷰로 부터 bitmap을 만들고, bitmap 기반으로 부서진 조각(Particle)을 만들어서 애니메이션을 돌리네. 아이디어 멋지다!

RxJava for Android App Development

O'Reilly가 제공하는 RxJava for Android App Development라는 공짜 e-Book을 받을 수 있다. 30페이지 남짓하지만 RxJava를 처음부터 익히려는 사람(나?)에겐 도움이 될 듯.

174

Sharing files on Android in a world with runtime permissions

안드로이드 M의 런타임 퍼미션은 참 많은 괴로움을 만들었는데, 이 글에선 action_send 를 받아 처리하는 쪽에서 READ_EXTERNAL_STORAGE 퍼미션을 처리해야하는 괴로움을 다룬다. 글에서 언급한 mike murphy 아저씨의 글 Runtime Permissions, Files, and ACTION_SEND에선 이 내용을 좀 더 다루고 있다.

file:// 가 넘어오면 READ_EXTERNAL_STORAGE 퍼미션 취득해서 접근하면 되고, content uri 가 넘어오면 FileProvider를 "잘" 쓰면 된다. 난 ContentProvider를 직접 써서 잘 몰랐는데, FileProvider엔 문제가 있나보군. 크으...

175

Vectors For All (almost)

내가 쓴 글, 안드로이드 프로젝트에 vector drawable을 적용해보려고 삽질했던 기록과 비슷한 결론이다. 아직 svg -> vector drawble 변환 도구의 완성도가 높지 않아, 디자이너가 만들어준 svg를 이용해 벡터를 본격적으로 활용하기 쉽지 않다.

Develop a secured Android application

보안 측면에서 더 안전한 앱을 만들기 위한 몇 가지 방안을 제시한다. 우선 네트웍 보안 강화를 위해 X509TrustManger를 확장한 커스텀 클래스를 제안한다. 다음으로 SharedPreference 보안 강화를 위한 방안을 제안한다. 마지막으로 소스코드 리버스엔지니어링을 어렵게 만드는 방법을 제안한다. 첫 두가지는 재밌는데 마지막은 난독화하고 native library 쓰라는 좀 뻔한 이야기이네.

Beware EditText on API 21

api 21에서만 edit text의 하단 padding이 다른가보다. 이건 또 몰랐네. 으으으...

TextSurface

텍스트로 꽤 멋진 애니메이션을 만들어주는 라이브러리이다. 멋지네! 이름대로 surface view로 만들었나?

176

Android Basic Project Architecture for MVP

또다른 MVP 글. 근데 Domain Layer 라는 게 좀 난데없다. Model layer 를 다르게 언급하고 싶었던 것 같은데, 그냥 모델 레이어라고 하는게 맞지 않았을라나. 그리고 GetPopularTitlesUsecaseController 코드를 보면 막 이쪽 이벤트 버스에서 unscribe 하고 저쪽 이벤트 버스에 subscribe 하는데, 이게 관리가 되려나. 갸우뚱...

MVP 라는 타이틀을 빌어 사람마다 다 맘대로 구현한다는 느낌이 무럭무럭 든다.

Material ProgressBar

롤리팝 프로그래스 바와 머티리얼 프로그래스 바를 비교한 영상이 첨부되어 있는데, 난 뭐가 다른지 잘 모르겠다 -_-;

Testing the Geofencing API

genymotion , genymotion shell 을 이용해 geofencing API 테스트를 이야기하는데, genymotion shell을 이용해 위치조작하는 방법이라고 이해하면 될 듯 하다. 잘 이용하면 위치 simulation을 자동화하는 데 좋은 힌트가 될 듯 하다.

Using hardware layers to improve Android animation performance

하드웨어 레이어를 이용하면 애니메이션 성능을 올릴 수 있다는 글. 요약하면 애니메이션 시작 전 hardware layer 설정 -> 애니메이션 실행 -> layer 리셋하라. min api lv 16+ 이고, ViewPropertyAnimator 를 쓴다면 간단히 withLayer() 메서드만 붙여도 된다. 하지만 여러 자식들이 animation 되는 와중에 parent에 hardware layer를 적용한다면 invalidate 될 때 마다 GPU 캐싱이 일어나 성능이 오히려 떨어질 수 있으니 조심해서 적용하라고 한다. 이런 문제는 개발자 옵션에서 "Show hardware layers updates"를 켜서 계속 녹색불이 들어오는지를 보고 확인할 수 있다.

마지막 부분에 샘플을 가지고 테스트한 내용도 있으니 앱에 애니메이션을 사용하고 있다면 꼭 알아둬야 할 내용으로 보인다. 굳굳

Build a Material Design App with the Android Design Support Library

design support lib.을 이용해 머티리얼 디자인 적용하는 방법을 알려준다. 그것보다 이 google codelab 사이트 굉장히 잘 만들었네!

Android Development Tidbits // No. 2

짧은 안드로이드 개발 팁을 적은 글이다. 시리즈가 더 많이 있으니 함께 읽어보자. : 1, 3, 4 , 5, 6, 7, 8

몇 가지 눈에 띄는 걸 꼽아보면 다음과 같다. * 머티리얼 디자인의 8dp 레이아웃 확인용 앱: keylines * sqlite query 의 ? 변수 개수는 한정되어 있음: Limits In SQLite 의 9번 항목인데, 나도 한번 문제가 된 적이 있다. 저런 한계가 있다는 것과 별도로, ? 변수를 동적으로 추가하는 쿼리를 만든다는 것 자체가 문제라고 생각한다. * ContentLoadingProgressBar : 껌뻑하고 바로 사라지는 progressbar를 피하기 위해선 잠깐 기다렸다 progressbar를 보여줘야 하는데, 이 클래스를 쓰면 쉽게 구현을 할 수 있나보다. * If you want your views to save state, you MUST give them an id : 예전에 form을 복구할 때 뭔가 이상하게 복구되어서 id 들을 손봤던 기억이 난다. * When opening the camera app on Android 6.0+ with an intent, you need to request Camera permissions to actually get back a result : 이거는 정말 이해가 안감. 굳이 app 자체적으로 permission 선언할 필요없이 컨텐트에 접근하라고 intent 만들었으면서 (가이드도 그렇게 하고), 카메라 intent를 날리려면 앱이 camera permission을 선언해야 한다. 뭔가 어뷰징 (ex. 몰카앱?) 을 막기 위한 용도라고는 보이긴 하지만.

FlowingDrawer

효과 끝내준다 ㅎㅎ

ViewInspector

뷰 profiling, layout 분석 등등이 다 들어가있는 종합 선물세트네. 한번 적용해봐야겠다. 깃헙 페이지에 나온 관련 도구들도 살펴보면 좋을 듯.

177

Mastering the Coordinator Layout

design support lib. 에 추가된 coordinator layout 소개 글이다. 이것도 익혀둬야 하는데 언제 써볼런지 @_@

The Complete Guide to Creating and Publishing an Android Library

제목에서 얘기하듯, android library 프로젝트를 sonartype의 repo에 올리는 방법을 잘 설명하고 있다. 안해봤지만, 왠지 이것만 따라하면 다 될 것 같은 느낌적인 필링

Fragment transitions with shared elements

activity transition 과 달리 fragment transition에선 shared element 처리가 훨씬 간단한 듯 하다. fragment transition에서 shared eleement 활용 방법을 잘 정리한 글이다.

Exploring Google Play Services: Place Picker & Autocomplete

플레이 서비스만 이용해도 위치 피커 / 자동완성을 쉽게 구현할 수 있구나!

plaid

머티리얼 디자인 쇼케이스 앱인데, 제작자가 구글의 nick butcher이니 더 눈여겨봐야할 듯!

178

The Perils of Loading Native Libraries on Android

멀쩡히 들어가있는 라이브러리인데도 UnsatisfiedLinkError 크래시 건이 잡히는데, 이 문제의 발생 원인을 분석하고, 해결책으로 Relinker 라는 라이브러리를 제공한다. ReLinker v1.2 is Here! 도 같이 읽어보면 좋을듯.

native library를 쓰는 앱이라면 ReLinker를 한번 들여다봐얄듯!

Debugging RxJava on Android

gradle plugin으로 동작하는 frodo라는, rxjava 로깅 도구를 소개한다. 깃헙 스타가 850개나 되네! RxJava를 공부하게 된다면 유용하게 활용할 수 있을 듯 하다.

On Activities using Theme.NoDisplay

화면에 보이지 않는 액티비티를 선언할 때 Theme.NoDisplay로 테마를 지정하면, 윈도우 자체가 생성되지 않기 때문에 바로 finish() 하는 경우가 아니라면 앱 크래시의 위험이 있으니, 이 경우엔 Theme.Translucent.NoTitleBar로 테마를 설정하라는 이야기.

Fixed aspect ratio with the Percent Support Library 23.1

오호, PercentRelativeLayout등을 이용하면 자식 뷰의 aspect ratio를 xml 상에 app:layout_aspectRatio="178%" 형태로 바로 지정할 수 있구나. 기존엔 이거 하려면 화면 폭 알아낸 다음, 거기에 종횡비 구하고 나서 처리했어야 하는데. 굳굳

Dynamic Android dependency versions done right

gradle dependency의 라이브러리 버전을 동적으로 판단하도록 설정하면 아마 lint warning이 떴던 걸로 기억한다. 너무 동적이면 문제가 될 수 있으므로 이 글에선 generateLock, saveLock 이란 gradle의 옵션을 소개한다.

./gradlew --refresh-dependencies generateLock saveLock

근데 나는 그냥 동적 버전 쓰지 않겠다. 굳이 여기저기 까서 의존 라이브러리 버전을 확인해야 하는 수고를 해야하나? 또한 버전 올리면 명시적으로 커밋을 남기는 것도 필요하고.

179

Unique Identifiers: There’s a better way with Instance ID

아이폰에선 디바이스 고유값을 시스템이 제공했는데, 안드로이드에선 이런 값을 관리하기가 수월하지 않았다. 하지만 이젠 instance id를 이용하면 이런 작업을 좀 더 쉽게 할 수 있다. 하지만 이름 그대로 앱 인스톨 인스턴스 별 식별자라서 해당 디바이스에 앱을 재설치한다면 값이 바뀌게 되니, 디바이스 고유값이 필요하다면 uuid api 등을 이용해 직접 관리해줘야 한다.

RxJava’s Side Effect Methods

RxJava에서 steam과 독립적으로 활용할 수 있는 메서드를 제공하나보다. resource 정리 등등에 활용할 수 있나본데, RxJava를 써 봤어야 말이지...

FlycoTabLayout

오와, 짱이다. 탭에 빨간 점, 뱃지 인티케이터 다 구현된 라이브러리네. 중국분이 만들었나본데, 같은 아시아라서 요구사항이 비슷했나. 여튼 이것만 갖다 쓰면 다 될 듯.

180

Improving UX with RxJava

RxJava 의 debounce 등을 이용해 똘똘하게 자동완성을 구현하는 방법을 설명한다. 뒷 부분엔 에러처리를 소개하고 있는데, 네트워크 연결되면 자동으로 재시도한다고 얘기했는데 이 전략은 좀 동의하기 어렵지만, 하여간 RxJava를 이용해 복잡한 시나리오를 깔끔하게 구현하는 방법을 소개한다.

Exploring Meaningful Motion on Android

animator, interpolator, transition 까지 안드로이드 애니메이션의 여러 부분들을 간략히 소개해준다. 한번 다시 복기하는 용도로 좋은 글.

Overscroll AppBarLayout Behavior

overscroll일 때 상단 이미지에 확대 효과를 주는 방법을 설명한다. 이 기능을 쓸 일은 없을 듯 하지만, overscroll일 때의 대응방법을 참고할 때 좋을 듯.

#android #Android Weekly

IntelliJ의 structural search를 이용해 xml 의 특정 attribute 이름 바꾸기

며칠동안 나를 괴롭히던 난제를 해결했다.

풀고싶던 문제는 intellij(Android Studio) 에서 특정 tag의 특정 attribute의 이름을 손쉽게 바꾸는 방법은 무엇인가! 이다.

예를 들어 안드로이드 프로젝트의 모든 레이아웃 xml 파일을 뒤져

이런 녀석들을 찾아서

이렇게 고치는 작업을 한방에 하는 방법이다. 이걸 왜 해야하냐면, 사용하고싶은 library 프로젝트에서 사용중인 custom view의 custom attribute 를 원래 프로젝트에서 이미 사용중이라면 원래 프로젝트의 custom attribute를 바꾸는 수 밖에 없기 때문이다.

IntelliJ 에는 structural search and replace 라는 멋진 기능이 있다. 막 명령어 찾아서 try { } catch 로 감싸는 등의 마술을 부릴 수 있는 도구이다. 다행히 java 뿐 아니라 xml 컨텍스트도 제공한다. 딱 하나 문제가 있는데, 사용하기가 매우매우 복잡해. ㅠㅠ

내가 하고싶은 검색 & 변환 작업은 다음과 같다.

tag 중 mytag 를 찾는다.

이 중 앞쪽 namespace 별칭을 불문하고 특정 속성을 찾는다 (ex. my:title or myns:title )

이제 namespace 별칭은 유지하고선 속성 이름만 바꿔놓는다. 속성값도 그대로 유지한다. (ex. my:title="abc" -> my:myTitle="abc", myns:title="anc" -> myns:myTitle="abc")

별로 어려워보이지 않지만 이틀동안 삽질을 했다. -_-;; 수작업으로 했어도 이미 했겠지만 이놈의 개발자병 때문에 방법을 찾아내느라 고생을 했네.

결론부터 말하면

search template: <$tag$ $attr$="$val$"/>

replace template: $result$

Edit variables... 를 누르면 나오는 대화상자에는

tag: Text/regexp 에 mytag 입력, min 과 max count 모두 1로 설정

attr: .*:title 입력, min 은 1, max 는 unlimited로 설정 , 맨 밑의 target of the search 체크

val: min 은 1, max 는 unliimited로 설정

result: Script text를 다음과 같이 입력 __context__.namespacePrefix + ":myTitle=\""+ __context__.value+"\""

다른 조합도 가능한지 모르겠지만, 이미 너무 지쳐서 알고싶지 않다.

저 __context__ 가 대체 뭔가는 신들린 구글링으로 XmlAttributeImpl라는 걸 찾아냈다. 그러니 다른 속성을 사용하고 싶다면 위 코드에서 속성쪽을 찾아보세요.

자, 이제 검색을 누르면 검색 목록에 이쁘게 xml 중 속성 이름들이 나오고, "Preview Replacement" 를 누르면 namespace prefix가 이쁘게 박힌 결과물이 보일것이다.

야호!

참고로 structural search는 꽤 느리기 때문에 큰 프로젝트라면 찾고싶은 파일들의 scope를 잘 조정해두길 권한다.

#intelilj #structural search #xml

안드로이드 프로젝트에 vector drawable을 적용해보려고 삽질했던 기록

제목 그대로 안드로이드 프로젝트에 vector drawable을 적용하려고 삽질했던 기록을 남겨본다.

vector drawble 적용방식 선택

안드로이드는 vector drawable을 지원한다. xml 형태로 선언한 vector drawable을 프로젝트의 res/drawable 폴더에 넣어두면 이쁘게 잘 보여준다. 물론 min sdk level이 걸려있다. 21 이상에선 그냥 잘 되고, 그 이하에서도 지원하려면 두 가지 선택지가 존재한다. 관련 내용은 Add Multi-Density Vector Graphics 문서에 잘 설명되어 있는데, 간단히 정리하면 다음과 같다.

png 생성 방식: vector drawable을 만들어두면 빌드 시점에 해상도별 png를 자동으로 만들어낸다. 따라서 구버전에선 그냥 png 불러오면 되므로 vector drawable 관련된 고민을 할 필요가 없다. 용량 측면에선 이득이 없다. 그래도 기존엔 해상도별 png 를 다 관리해야 했지만 이젠 xml 파일 하나만 관리하면 되니 관리 측면에선 간결해지는 이점이 있다.

support lib의 처리 방식: support lib의 은총을 받아 처리한다. 하지만 png 직접 쓸 때와 달리 코드나 xml 상에서 고려해야 할 부분이 생긴다. 아얘 png가 없어지니 용량 측면에선 도움이 된다.

실무 프로젝트에 적용을 한다고 생각했을 때, support lib 방식보단 안전한 png 생성 방식을 선택했다. 위에도 적었듯이 용량 측면에서 메리트는 거의 없지만, 리소스 파일 관리는 꽤 편해질 듯 했다. png 생성 방식을 택할 경우, 어떤 해상도의 png를 만들어낼지 gradle에 선언해야 한다. 선언 안하면 mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi 까지 쫙~ 만들어지는 아름다운 광경이 펼쳐진다. stackoverflow 링크에서 보듯, 최신 gradle 환경에선 다음과 같이 선언하면 된다.

defaultConfig { vectorDrawables.generatedDensities = ['hdpi','xhdpi'] }

어떤 어떤 해상도를 선택해야할까? 많이 만들어두면 그만큼 용량을 차지할거고, 적게 만들면 21 미만의 고해상도 디바이스에선 이미지가 뿌옇게 보일거다. 이건 각자 생각하기 나름일 것 같은데, 내 생각엔 xxhdpi 까진 만들어줘야 하지 않을까 싶다. xxxhdpi 디바이스는 대게 21 이상 기기라고 가정할 수 있을 것 같고. 오히려 지금 시점엔 굳이 hdpi 까지 만들어야할까? 라는 고민을 할 수도 있을 듯 하다.

svg to vector drawable

vector drawable을 한땀 한땀 코딩해서 만들순 없고, 일반적인 상황이라면 안드로이드 스튜디오의 Vector Asset Studio을 이용해 svg를 vector drawble로 변환하는 방안을 택해야 한다.

근데 이 vector asset studio가 아직은 svg를 많이 가린다. svg 명령어 중 지원하지 않는 명령이 많고, 세심하게 svg를 만들지 않았다면 warning이 뜨면서 제대로 된 vector drawble이 만들어지지 않는다. 막 깨져보인다거나 한다. 결과물은 vector asset studio에서 바로 확인할 수 있다.

처음 디자이너분이 일러스트레이터나 sketch로 만든 svg를 주셨을 때 거의 모든 경우 제대로 인식을 못했다. 이 경우 svgomg라는 웹 애플리케이션을 이용해 svg를 최적화하면 꽤 괜찮게 vector drawable로 변환이 된다. 하지만 나와 디자이너분이 실험을 할 때 style 태그와 관련된 부분에서 결국 gg를 쳤다. 색칠을 일일이 fill 속성으로 만들어내야 하는데, 한땀한땀 svg를 텍스트에디터로 수정하지 않는 이상 해결책이 거의 없어보인다.

결국 포기

꿈과 희망을 갖고 시작했지만 결국 포기했다. 내 프로젝트는 많은 디자이너, 많은 개발자가 참여하고 있다. 뭔가 중앙 집중식으로 벡터 리소스(svg)를 관리하지 않고, 디자이너분들이 필요할 때 마다 svg를 만들어서 개발자에게 전달해야 하는데, 모든 디자이너 분들이 저 vector asset studio 최적화된 svg를 만들어내는건 불가능하다. 백보 양보하여 개발자들이 svg를 까서 손수 편집해서 적용한다고 해도, 이미지는 여러번 핑퐁치면서 수정되어야 하는데 그 때 마다 개발자들이 매번 svg를 편집해야 하는 수고를 치뤄야한다면 차라리 깔끔하게 vector drawble을 포기하는게 낫겠다 싶다.

내 생각에 vector drawble을 실무 프로젝트에 활용하려면, 브랜드 아이콘 등 고정된 아이콘 셋만 한벌 만들어두고 이것만 관리하는 상황이 아니라면 불가능할 듯 하다. 신기능 추가될 때 마다 svg를 몇개씩 만들어내야 한다면 그 때마다 개발자랑 계속 핑퐁치면서 svg를 수정해야 하는데, 이건 말도 안된다. material icon set 같이, 전사 표준 아이콘 셋 같은걸 관리하는 환경이 아니라면 포기. 디자이너분이 안드로이드 스튜디오의 vector asset studio를 직접 이용해서 svg를 검수하는 그림을 상상을 해 봐도 도저히 각이 안나온다.디자이너 분들이 해상도별 png를 만들어내는 수고를 덜어보고자 vector drawble 고민을 시작했는데, 왠걸 이건 훨씬 더 수고가 많이 든다.

그래서 깔끔하게 포기했다. vector asset studio가 지금보다 훨씬 똘똘하게 svg를 변환해 주지 않는 이상, 실무 프로젝트에 활용하기 어렵다고 생각한다.

#android

RxJava is hot property among experienced Android developers these days, but this powerful library for handling asynchronous data in Android apps can be difficult to learn. In this O’Reilly report, mobile software engineer Matt Dupree introduces you...

오렐리가 공짜로 나눠주는 전자책이다. RxJava에 입문하려는 안드로이드 개발자를 위한 책이고, 딱 내가 그런 상황이라서 읽어보니 꽤 좋았다. 35페이지 정도 되니 부담없이 읽을 수 있고, 설명도 명쾌하여 좋았다.

다들 그렇게 설명하는지 모르겠지만 익숙한 Iterable을 들어 Observable을 설명하여 좋았다.

이 책을 읽고, gaemi님이 열심히 정리한 RxJava with Android - 1 - RxJava 사용해보기 를 읽어보면 더 정리가 잘 될 듯 하다.

RxJava는 이미 대새이니 이 책 읽고 나도 대세에 합류해봐야지!

#rxjava #android

Android Weekly 161~170 리뷰

밀린 Android Weekly 몰아보기!

근데... 너무 밀렸다. 2015년 9월 내용이네-_-;

161

Spock Ahoi!

읽기 좋은 테스트를 작성하기 위한 시도는 끊임없이 계속 되고 있다. 이 글에선 spock 이라는 프레임워크를 이용해 안드로이드 테스트 코드를 깔끔하게 작성하는 방법을 소개한다. spock은 groovy 기반으로 테스트 코드를 작성하나보다. 흐음, 근데 테스트 작성을 위해 그루비까지 끌고와야 할까?

Java 8 Stream on Android

retrolambda와 lightweight stream api를 조합해서 안드로이드에서 java 8 의 stream 비슷하게 collection을 다룰 수 있도록 하는 방법을 소개한다. 그런데 실무 프로젝트에 사용하기엔 왠지모르게 좀 걱정이 앞선다. 또한 댓글에선 지적한 stream과 달리 lazy evaluation이 안된다는 큰 단점도 걸리고.

Gradle tip #3: Tasks ordering

gradle에서 task 의존관계, 실행순서를 지정하는 방법을 소개한다. dependsOn 정도밖에 몰랐는데 여러가지 많네. 본문에서도 소개하지만, finalizedBy 메서드는 최신 버전인 2.10 에서도 여전히 incubating 상태이다.

B.dependsOn A : A를 먼저 실행한 다음 B를 실행한다.

B.mustRunAfter A : B와 A가 모두 실행될 경우, B는 A 다음에 실행한다.

A.finalizedBy B : A를 실행해도 B가 실행된다.

Mortar-architect

mortar를 이용해 구성한 애플리케이션 구조로 파악되는데, Activity도 없이 ViewPresenter 등등으로 앱을 구성하니, 이쯤되면 이게 안드로이드 앱인가 싶다. 너무 멀리 간 것 아닌가.

ThreeTenABP

거장 jake wharton의 프로젝트로, java 8에 Date와 Calendar를 대체하기 위해 추가된 JSR-310 java.time.* 패키지의 안드로이드 포팅이다.

자바에서 Date, Calendar를 다뤄보면 꽤나 짜증이 나는데, 한번 적용해보고싶어지네.

162

android lint summary

커맨드라인에서 lint 결과를 보여주는 도구인데, 난 html로 봐서 쓸 일은 없을 듯. 근데 이쁘다.

A First Glance at Stetho tool

페북이 만든 안드로이드 앱 디버깅 브릿지 도구? stetho를 소개한 글이다. stetho는 정말 짱이다. 이 글에선 view단을 보여줬는데, 무엇보다 network과 db 네비게이션엔 이만한 도구가 없다. 이거 몰랐을 땐 힘들게 proxy등에 붙었지만 stetho를 쓰면 아주 쉽게 network 단 추적을 할 수 있고, db도 직접 쿼리를 날리거나 update 등의 작업도 할 수 있다. 업무용으로 본격적으로 앱을 개발한다면 stetho는 필수 중의 필수이다.

Architecting Android…The evolution

retrolambda, rxjava, dagger 다룬 글들은 매우매우 많아서 딱히 열심히 읽어보진 않았는데, 마지막 gradle script 부분이 꽤 재밌다. 아래와 같이 dependency를 바로 설정하지 않고, 일종의 dictionary를 만들어서 쓰는데, 여러 서브 모듈이 비슷비슷한 라이브러리 의존성을 가진다면 이렇게 중앙에 정의해두고 쓰는 것도 좋겠다.

dataTestDependencies = [ junit: "junit:junit:${jUnitVersion}", assertj: "org.assertj:assertj-core:${assertJVersion}", mockito: "org.mockito:mockito-core:${mockitoVersion}", robolectric: "org.robolectric:robolectric:${robolectricVersion}", ]

Improving Your Code With Android Support Annotations

support library에 있는 support annotation 중 몇 개를 소개했다. 이 글도 살짝 보고, 전체 support annotation 목록도 한번 살펴보자.

GlidePalette

유명한 이미지 로더 라이브러리인 glide에서 쉽게 palette 기능을 쓸 수 있도록 도와주는 라이브러리. 재밌네~

awesome-android-ui

안드로이드 ui 라이브러리 목록인데, 엄청나게 많다. 우와! 시간가는 줄 모르고 봤네.

163

Glide - How Yelp’s Android App Loads Images

yelp 기술 블로그에 올라온 이미지 로더 라이브러리인 glide의 장점 소개 글이다. 가볍게 읽어보자.

Overview of the Android Design Support Library

또다른 design support library 소개글이다. 쓰으윽~ 한번 목록과 동영상 훓어보자.

InstaMaterial meets Design Support Library

instagram에 머티리얼 디자인을 적용해보는 샘플 프로젝트인 instamaterial 시리즈에 design support library를 적용해본 글이다. navigation view, fab, coordinator layout을 적용했다. 멋지네!

MAKING A TDD-BASED HACKERNEWS CLIENT FOR ANDROID

앱의 여러 구성 요소에 단위 테스트를 적용하는 방법을 참고할 수 있다.

Connect With the World Around You Through Nearby APIs

nearby api를 소개하는 구글 개발자 블로그 글이다. 처음엔 places api와 같이 위치정보 관련 기능인줄 알았는데, 근처의 앱 사용자들에게 메시지를 날릴 수 있는 기능이네. 오호! 흔들어 친구 맺기와 유사한 류의 기능에 활용할 수 있을 듯 하다. 글을 보니 이미 trello에 사용하고 있다고 하니 한번 trello 가지고 테스트해봐야겠다.

164

Deferring Observable code until subscription in RxJava

square의 dan lew 아저씨가 열심히 RxJava 관련 글을 올려주고 있다. RxJava는 글만 읽고 실전에선 아직 써 보지 못했지만, 제목과 내용만 봐선 observable을 subscribe 할 때 까지 값 평가를 지연시키는 내용인가보다. 하아, RxJava는 또 언제 해보나.

MVVM on Android using the Data Binding Library

design support library에 추가된 data binding 기능을 이용하되, ViewModel 레이어를 중간에 끼어넣어 구현하는 방법을 알려준다. 내가 data binding을 사용한다고 해도 이런 방식을 취할 듯 하다.

How to centralize the support libraries dependencies in gradle

몇몇 다른 글에서도 본, gradle에서 의존성 부분을 깔금하게 정리하는 팁이다.

WilliamChart

꽤 이쁜 차트 라이브러리이다. 2012년 말 프로젝트를 할 때만 해도 차트 라이브러리가 몇 개 안되고, 그다지 이쁘지 않았는데 요즘은 참 이쁜 챠트 라이브러리가 많네.

Blurry

이미지 블러 라이브러리이다. 설정쪽을 보니 renderscript도 사용하나보다. 블러 쓸 일이 있다면 유용하겠네. 2.3 이상 사용가능.

165

Android Testing Blueprint

unit test, instrumentation test 등 다양한 테스트를 작성하기 위한 참고자료이다. 굳굳

RxJava Code Review Part 1

RxJava 코드 분석글이다. 엄청 많을 줄 알았는데 part1, part2 두개가 전부네. 읽어봐야 할 텐데...

Flux Architecture on Android

facebook에서 클라이언트 사이드 웹 애플리케이션 용으로 제안한 flux 아키텍쳐를 안드로이드에 적용해 본 방법을 설명한다.

dispatcher는 액션을 store에 전달하는 역할을 하는데, 여기선 eventbus로 구현했다. view는 말 그대로 ui 뷰로, 안드로이드에선 activity나 fragment가 담당한다. store가 핵심인 듯 한데, 비즈니스 로직, 상태, 상태 변경 이벤트 발행 등을 담당한다. 중간에 보면 sotres are not repositories 흥미로운 대목이 나온다. API나 DB에서 데이터 가져오는 게 store의 역할이 아니라 action이 제공한 data들을 가지고 state관리하는 게 핵심인 듯 하다. data 가져오는 건 action을 만들어내는 action creator가 하네.

뭔가 개념은 좀 심플한 듯 한데 이것도 한번 살펴봐야 할 듯.

Using Espresso for Easy UI Testing

espresso로 ui 테스트 하는 방법을 소개한다. UI 테스트를 할 경우, api 등의 호출로 결과를 받을 때 까지 대기해야 하는 경우가 생기는데, 단순히 thread.sleep 등으론 부족한 점이 많다. 여기선 IdlingResource 라는 interface를 이용해 이런 경우를 깔끔하게 처리하는 방법을 알려준다. 굳굳!

166

Face Detection in Google Play services

구글 플레이 서비스가 제공하는 mobile vision api 중 얼굴 식별 관련 기능을 설명한다. mobile vision api는 얼굴 식별, 바코드(+QR코드) 인식 두가지 기능을 제공한다. 직접 만들긴 굉~~~장히 어려운 기능인데 굳굳!

FlatBuffers in Android - introduction

api 통신은 거의 json으로 대동단결한 상태인데, 이 녀석은 오가는 데이터량이나 자바 객체로 파싱하는 비용 면에선 그다지 바람직하지만은 않다. 이런 욕구를 해소하기 위해 구글은 flatbuffer를 제공한다. flatbuffer는 모델에 대한 스키마를 정의한 후, 라이브러리가 제공하는 컴파일러를 실행하면 모델 객체, 변환된 데이터 파일(json to flatbuffer binary)를 생성한다. 이 글은 이러한 과정을 쉽게 따라할 수 있도록 설명한다. 모든 데이터 통신에 flatbuffer을 활용하긴 어렵겠지만, 특별히 복잡한 모델 구조나 양이 많은 데이터의 경우엔 꽤 효과적인 방식이라고 생각한다.

Iconify just got a lot better

Iconify라는 라이브러리를 소개한다. TextView를 확장해서 폰트 기반 아이콘을 손쉽게 표현해 주는 뷰를 제공한다. custom font도 사용할 수 있고, 빙빙 돌아가도록 설정도 가능하다. 빙빙 돌아가는 걸 어떻게 구현했을까 찾아보니 span의 canvas rotate를 하고,post animation을 붙이는 방법을 썼다. 오호~ 재밌네!

Quick return with CoordinatorLayout

design support library에 추가된 CoordinatorLayout을 이용해 quick-return view를 만드는 방법을 쉽게 설명했다. 굳굳~

List of Android Testing Libraries

안드로이드 테스트에 필요한 라이브러리, 도구들의 목록이다.

167

Tinting drawables

support library가 제공하는 DrawableCompat과 다른 방식으로 구현한 TintedBitmapDrawable을 소개한다. 그런데 굳이 이걸 써야할까 싶은 생각이 들긴 하네.

Percentage Based Dimensions and Margins with the Percent Support Library

linear layout 이나 relative layout이라는 두 개의 도구만 쓰다보면 중첩된 레이아웃을 피하기 어렵다. 정말 복잡한 거라면 모르겠는데, "아 이거 꼭 이 방법밖에 없나!" 하고 아쉬울 때가 많은데, Percent support library까지 활용하면 좀 더 레이아웃을 간단히 만들 수 있을 듯 하다. percent 패키지 제공하는 레이아웃은 PercentFrameLayout 과 PercentRelativeLayout 두 가지이니, 아마도 relative layout을 주로 쓸 듯.

A small leak will sink a great ship

square에서 공유한 메모리 릭 탐지 사례. leak canary를 이용해 메모리 릭을 찾아갔더니 범인은 alert dialog에서 흔히 쓰는 DialogInterface.OnClickListener였다고. 이 과정을 찾아내는 과정을 설명하는데 재밌으니 한번씩 읽어보시라.

Coordinator Behavior example

coordinator layout 샘플인데 꽤 훌륭해보인다!

168

Tools of the Trade

tools namespace, support annotation을 설명한다. 잘 활용하면 안드로이드 스튜디오에서 손쉽게 잠재적인 문제를 찾아낼 수 있다.

Speed up your app

이 글은 systrace, MAT, hierarchy viewer 등 다양한 성능측정도구를 소개한다. 근데 pt만 봐선 어떤 부분을 강조하는지 잘 감이 오질 않는다. youtube 영상도 같이 봐얄 듯

Android Camera 2 API

camera api는 한번 살짝 써 본 경험밖에 없는데, 기계마다 너무너무 달라 이쪽도 다신 해 보고 싶지 않았다. os 버전 올라가면서 api 레벨 21에 camera2 api 가 도입되었는데, 이 pt를 읽어봐도 아후 굉장히 복잡하다. 그냥 카메라 api는 앞으로도 접근할 일이 없었으면 하는 생각만 들 뿐이네.

Preferences Support Library: Preference Fragments for API 7+, no matter the Activity

Preferences Support v7 Library를 이용하면 구버전 os에서도 더 이상 PreferenceActivity이 아닌 Activity에서 PreferenceFragment를 이용해 preference ui를 구성할 수 있다. 근데 이거 많이 쓰나? 실제 프로젝트에선 설정 화면에서도 워낙 이런 저런 디지안 등이 많이 들어가서 한번도 써보질 않았는데.

Android Architecture

MVC, MVP, MVVM 아키텍쳐를 간략히 소개한다. 근데 이거만 봐선 딱히 감이 잘 안오지... MVP 관련해선 구글이 만든 android architecture 쪽을 같이 살펴봐야 할 듯.

Announcing the Android Auto Desktop Head Unit

안드로이드 오토용 앱을 개발하려고 자동차에 들어앉을 순 없으니 딴 방법이 있어야지! sdk에 포함된 데스크탑 헤드 유닛을 이용하면 음성 출력, 입력 모두 잘 테스트할 수 있다. 다만 설정 관련해선 Run and Test Auto Apps 부분을 잘 읽어봐야 한다. 파나소닉 등의 실물 헤드유닛의 경우엔 구글 플레이에 오토 앱으로 출시를 해야만 동작하기 때문에 그 전엔 무조건 DHU를 써야 한다.

Using styles and themes without going crazy

theme, style을 적용하는 방법을 설명한 글이다. 안드로이드 N에선 multi-window 관련해서 또 뭔가 달라진다는데, 안드로이드 테마는 다뤄본지 너무 오래되어 이젠 가물가물한데 엄청 구렸다는 기억만 대충 남아있네.

MVVM using Data Binding

안드로이드 databinding을 이용한 mvvm 샘플이라는데, mvp 샘플등과 함께 비교해봐얄 듯...

SCViewPager

요즘 자주 보이는 뷰페이저에 애니메이션을 적용하는 라이브러리 샘플이다. 근데 뒷 페이지용 뷰를 어떻게 먼저부터 알고 있나 보니 그냥 해당 뷰를 따로 가지고 있네.

169

Unleash functional power on Android (I): Kotlin lambdas

kotlin 얘기는 참 많은데, view.setOnClickListener() 를 어떻게 줄이는 지 하나하나 보여주는 단계가 참 재밌네.

... 이번 호에는 별로 관심 가는 토픽이 없네

170

Google Play Services: Using the Nearby Connections API

nearyby api로 통신하는 샘플코드이다. 나중에 nearby api를 사용하게 된다면 한번 살펴봐야겠네!

Flowchart for background work, alarms, and your app

한장으로 정리한 백그라운드 작업 선택 흐름도!

HomeMirror

헉, 스마트 거울 프로젝트의 레파지토리도 있었네! 엄청 탐난다.

LayerVisualizer

안드로이드 ui의 레이어를 3d로 살펴볼 수 있게 해 준다. 예전에 웹 페이지도 이렇게 보여주는게 있었는데.

RxMarbles

Rx* 계열의 메서드의 동작을 비주얼하게 보여준다. 멋지네!

#android #Android Weekly

아포가토

Android N 맛보기

안드로이드 N 신규기능 중 눈에 띄는 부분만 살짝 확인해본 기록을 적어본

환경 구성

Android N Developer Preview 에 자세한 정보 있음

OS만 띄워보겠다면

Android Beta Program에 보유중인 기계를 등록 : 넥서스 6, 9 5x, 6p만 해당함

해당 다바이스로 OTA 날아오니 설치하면 됨

앱을 빌드하겠다면

android sdk manager를 이용해 N Preview SDK, 최신 SDK Tool 설치

안드로이드 스튜디오 2.1 설치

프로젝트 gradle 설정 업데이트 { android { compileSdkVersion 'android-N' buildToolsVersion '24.0.0-rc1' ...

defaultConfig { minSdkVersion 'N' targetSdkVersion 'N' ... } ... }

아직 N preview google api가 제공되지 않기 때문에 구글맵 등을 이용하려면 gradle에 직접 의존 관계를 추가해야 한다. 일단 마시멜로 버전을 업어오자. compile fileTree(dir: "${android.getSdkDirectory().getAbsolutePath()}/add-ons/addon-google_apis-google-23/libs", include: '*.jar')

뭐가 추가되었나

추가된 건 많긴 하지만 당장 눈에 띄는 것만 살펴봤다.

멀티윈도우

최근 앱 목록(이걸 개요화면/Overview Screen이라고 부르는군)에서 앱 타이틀을 길게 누르거나, 빈 사각형의 앱 목록 버튼을 길게 누르면 멀티윈도우 모드로 진입힌다.

분리된 윈도우 중 다른 윈도우가 활성화되었을 경우엔 활성화되지 않은 윈도우의 앱은 paused 상태이지만 사용자에겐 보이는 상태이다. 이젠 서로 다른 윈도우 간 drag-n-drop도 된다고 한다.

멀티 윈도우 모드로 들어가거나, 멀티 윈도우 상태에서 창 크기를 조절할 때 onConfigurationChanged() 가 호출되니 이걸 알아서 잘 처리해야 한다.

manifest의 application/activity 항목에 android:resizeableActivity=[true|false] 속성이 추가되었고, 기본 값은 false이다. android:supportsPictureInPicture=[true|false]도 추가되었다.

멀티윈도우에서 특정 액티비티를 다른 윈도우로 띄우는 기능도 있다. Intent.FLAG_ACTIVITY_LAUNCH_ADJACENT 인데, 이 flag는 문서에서 FLAG_ACTIVITY_NEW_TASK 와 함께 쓰라고 되어있다. 하지만 이렇게 해선 동작하지 않고, 다음 StackOverflow 글에서 지적하듯, FLAG_ACTIVITY_MULTIPLE_TASK 와 함께 써야 한다. 근데 이 액티비티 저 액티비티에 막 써보면 기상천외한 현상이 일어나니 조심하자.

PiP 기능도 추가되었다고 하는데, 안드로이드 TV 관련 기능으로 보여 이건 그냥 건너뛰자.

Notification

기존엔 Wear용 노티에서만 가능했던 바로 답장 기능(inline reply)이 폰에서도 가능해졌다. 샘플코드만 따라 해 봐도 쉽게 만들 수 있다. Wear용 노티 만들어 봤다면 아주 쉽게 구현할 수 있다.

다만 reply 전송을 누르고 나면 노티 옆의 프로그레스가 하염없이 돈다. 처음엔 내가 뭘 잘못했나 생각했는데, 앱 샘플의 관련 코드를 보면 저 프로그레스는 무조건 돌기 때문에 답장 완료되었을 때 어떤 식으로든 끊어주는 건 개발자가 알아서 해야 한다.

번들 노티의 경우엔 일단 내 관심사가 아니라서 건너뛴다. 대충 읽어선 Inbox 스타일과 뭐가 다른지 감이 안오네.

#android #android n

Geneva Model Cinema를 샀다

새로운 음향 장비를 사고싶다

예전, 티비가 없을 땐 야마하 앰프에 티악 스피커를 물려 라디오도 듣고, 영화도 봤다. 티비를 사고나서도 광출력으로 연결해서 나름 유용하게 쓰긴 했는데, 티비 리모콘으로도 여러 동작이 잘 되었지만 가장 중요한 전원 이 리모콘으로 동작하지 않았다.

앰프 전원 넣으려고 몇 십 미터를 걷는것도 아닌데 묘하게 요것 때문에 앰프를 잘 쓰지 않게 되었다. 웃기게도 그럼에도 티비 스피커보단 좋은 음질로 듣고 싶은 욕심은 남아있었다. 그렇게 욕심이 나면 2미터 기어가서 전원 버튼을 누르기만 하면 되는데...

또 한가지는 블루투스로 컴퓨터나 핸드폰 음악을 재생하고 싶은데 이것도 안되었다. 앰프에 물릴 수 있는 네트워크 오디오 기기는 굉장히 비싸고, 크롬 캐스트 오디오의 경우엔 광출력도 되기 때문에 딱 좋은 선택인데 뭔가 땡기진 않았다. 이미 마음속으론 뭔가 사고싶었던 것이지...

여튼 주렁주렁 스피커 사서 배치할 마음은 없고, 티비 스피커는 별로고, 블루투스 음악도 듣고싶어 찾아본 게 사운드바였다. 야마하 제품 유명한 건 이미 알고 있었고, 하이마트에서도 삼성이나 LG 사운드바를 팔고 있어서 관심은 1그램 정도 있었다. 하지만 좀 더 뒤져보니 요즘은 사운드바에 우퍼까지 끼워팔고 있는데 독립된 우퍼마저 별로 설치하고 싶지가 않았다.

사운드베이스라는 게 있더라

더 뒤져보니 사운드바 말고 사운드베이스라는 카테고리도 있었다. 길쭉한 사운드바와 달리 사운드베이스는 티비를 얹어놓을 수 있는 판때기 형태이다. 우퍼도 한 통으로 되어 있어서 걸리적 거리는 독립형 우퍼도 아니고.

유명한 hifi 사이트인 whathifi에 Best soundbases라는 글이 올라와서 공부를 좀 하기 시작했는데, 막상 국내에서 정식으로 파는 건 야마하 정도밖에 보이질 않았다. 직구까지 할 엄두는 나질 않네. 그리고 사운드바와 달리 이쪽은 가상 5.1채널이니 이런 사운드바 쪽과 달리 2.1채널 정도에 머물러있는 분위기였다. 흠, 그냥 사운드바 살까? 아니면 사운드베이스 좀 더 뒤져볼까? 마음이 계속 오락가락하고 있었다.

Geneva Model Cinema로 샀다

그러다 판교 현대백화점에 갔는데, whathifi에서 베스트 상품으로 꼽은 geneva model cinema를 만든 geneva 매장이 있었다. 이 브랜드 매장이 현대백화점에 있을거라곤 상상도 안했는데.

실물을 보니 생각보다 컸고, 생각보다 쌔끈했다. 이뻐. 사고싶어. 블루투스 apt-x 미지원, dts 미지원, hdmi 미지원 등이 머릿속에 떠올랐지만 몰라. 이쁘니깐 살래.

매장에서 간단히 청음도 해 보고, 블루투스 연결도 한번 해 보고 싸모님을 모시고 와서 같이 보고선 그냥 덜컥 사버렸다.

참고로 이 브랜드는 극동음향에서 총판으로 들여오고 있고, 모델 씨네마는 인터넷 쇼핑몰이나 백화점이나 죄다 99만원에 팔고 있다. 그나마 가장 싸게 사는 방법은 현대카드 privia 쇼핑에서 2% 할인받은 후 M포인트를 몰아쓰는 방법일 듯 하다.

개봉

새빨간 상자에 포장되어 왔다.

구성은 단촐하다. 여러 언어로 된 매뉴얼 1부, 광케이블, 리모컨, 전원선, 여분의 스티커

매뉴얼엔 Korean을 직역해서 그런지 한국어도 아니고 한국인이라고 적혀있다. 어차피 매뉴얼에 별 내용이 없기 때문에 번역이 거슬린다고 불편할 건 없다.

리모컨 배터리 교체하기 되게 빡빡하다. usim 교체할 때 쓰는 것 같은 핀이 하나 들어있는데 저걸로 쑤셔도 잘 안열린다.

리모컨 배터리 슬롯 내부엔 나름 스프링도 들어있는데 왜이리 빡빡하게 안튀어나오는지...

단자도 단촐하다. 이어폰 크기 단자, 광입력, 동축입력, 일반 라인 입력. From GENEVA, with love!

전체적인 모습

하단부의 우퍼가 눈에 띈다.

설치 끝!

처음 봤을 땐 엄청 넙대대하다고 생각했는데, 위 사진을 보듯이 삼성 50인치 티비 스탠드가 겨우겨우 얹혀질 정도였다. 좀만 티비가 커도 얹지를 못하겠네.

TV/블루투스 연결

가장 중요한 것 중 하나가 얼마나 쉽게 조작하는지 이다. 기존 야마하 앰프도 전원 버튼 손으로 누르기 귀찮아서 안썼으니까.

전원은 티비를 켜면 알아서 켜진다. 아마 광입력을 계속 확인하다가 입력 들어오면 켜지는게 아닌가 싶다. 티비를 끄면 15분 뒤에 꺼진다고 한다. 지켜보고 있진 않아 모르겠지만 티비 끄고 다음날 보면 꺼져있는걸 보면 하여간 되는 것 같다.

음량도 삼성TV 리모컨으로 조절이 된다. 삼성TV의 자체 스피커는 꺼버리고, 외부 스피커만 나오게 설정한 다음, 연동 기기 브랜드에서 GENEVA를 입력하니 잘 동작한다.

대부분의 조작은 올레TV 리모컨으로 하는데, 여기서 직접 TV의 음량조절을 하면 이건 좀 굼뜨다. 뭔가 애매하게, 어떤 경우엔 잘 안되는 것 같기도 하다가 잘 되기도 해서 애매하다. 올레TV를 볼 때의 볼륨조절은 대게 셋탑 자체 볼륨 조절로 해결해서 큰 문제는 아닌데, 불편한다.

삼성TV는 음성출력을 PCM/DTS/DTS Neo 인가를 지원하는데, 이상하게 DTS는 활성화가 안되네. 하여간 뭐 이쪽은 그냥 포기하고 PCM으로 가야한다. 저런거 지원받고 싶다면 애초에 야마하 쪽을 선택하는게 맞을 듯. 그냥 욕심을 버리자.

블루투스 연결도 잘 된다. 맥북과 안드로이드 연결을 해 봤는데 다 잘 된다. 다만 기본이 TV연결로 되어있기 때문에 블루투스로 모드를 변경해야 하는데, 이러려면 결국 씨네마 베이스의 리모콘을 쓰던가 직접 기기 상단의 M 버튼을 눌러줘야 한다. 대부분 TV를 보지, 교양있게 TV끄고 음악 들을 일은 많지 않아서 뭐 이건 좀 더 써 봐야 불편한지 감이 올 하다.

음질

이 기계 저 기계 비교 청취를 많이 한 것도 아니어서 비교는 못하겠지만 만족스럽다. 맨날 밤에만 켜기 때문에 볼륨을 많이 못올려봤는데, 언제 낮에 볼륨을 한껏 올려서 들어보고 싶네. 다만 생각보다 베이스가 높아서 적응을 좀 해야겠다. 리모컨으로 베이스와 트레블을 조정할 수 있는데, 크게 차이를 못느꼈다.

한가지 문제는 스피커들이 좁은 앞쪽에 몰려있어서 그런지, 좌우로 위치를 좀 벗어나면 소리가 확 달라진다. 가요를 틀어놓고 자리를 벗어나니 보컬 목소리는 하나도 안들리더라고. 일반 앰프 스피커라면 L/R을 벌려서 설치해서 그런가 이렇게 확 차이가 나는 걸 몰랐는데, 하여간 이 제품은 TV앞에서 들어야 가장 잘 들을 수 있을 듯 하다.

끝

99만원이니 입문용 AV 풀셋보다도 비싼 가격이긴 한데, 이거저거 귀찮은 사람 + 이쁜 장비를 원하는 사람에겐 좋은 선택이 아닐까 싶다. 하지만 hdmi 입력, dts등등 여러 효과를 기대하진 마시길.

#geneva model cinema #soundbase

뭔가 공중도시같은 느낌. 근데 집에 가고싶은 마음만 한가득 흐규(현대백화점 판교점에서)

Android Weekly 151~160 리뷰

밀린 Android Weekly 몰아보기! 게으름피우다 또 한참 밀려버렸네.

151

How to add a Native Facebook Like Button to your Android app using Facebook SDK for Android v4

제목이 매우 긴 포스팅이다. 제목 그대로 페북 SDK를 이용해 앱에 like 버튼을 붙이는 방법을 설명하는데, 본론인 like 버튼 붙이기는 유용한지 잘 모르겠지만 페북 SDK 연동을 굉장히 자세히 설명했기 때문에 페북을 연동할 생각이라면 참고하면 좋겠다.

본론으로 돌아가, 페북 SDK도 like 버튼을 제공하긴 하는데, 1. like 하기 전엔 like 수를 알 수 없고, 2. 페북 앱이 깔리지 않았다면 like 자체를 할 수 없다. 그래서 이 글에선 위 두 가지 조건을 충족하는 ui작업을 설명한다. 이걸 별도의 library로 제공하기도 하니 like를 붙일 계획이라면 참고하면 좋을 듯.

Dagger 1 to 2 migration process

Dagger 1 -> 2 마이그레이션 과정을 예제를 이용해 잘 설명한 글이다. Dagger 1과 2의 차이를 이해하는데 도움이 많이 되네. 프로젝트에도 써먹어봐야 할텐데...

MaterialViewPager

머티리얼 디자인의 view pager 구현이다. 멋지다. 예전에 스와이프 + 상단 스크롤 구현을 하려다 포기했던 기억이 나서, 이 라이브러리의 코드는 한번 꼭 들여다봐야겠다.

androidtool-mac

맥용 안드로이드 개발 보조도구이다. 스크린샷, 비디오 녹화, apk 인스톨 등 기능이 있네. 우왕, 당장 써봐야겠다!

152

LeakCanary: Detect all memory leaks!

메모리 릭을 찾아주는 유용한 도구이다. 액티비티를 종료할 때 gc를 호출해서 액티비티 진입 전/후 메모리를 비교한다. 그런데 항시 돌리기엔 앱 사용성이 많이 떨어져서 간간히 사용하는 정도로 활용해야 하고, singleton 등이 너무 많이 detect되는 부분도 조금은 아쉽다. 물론 추가적인 커스터마이징으로 이런 부분은 극복이 가능할 듯. 그래도 도움이 많이 된다.

Custom ViewGroups

커스텀 뷰 그룹을 만드는 방법을 간단히, 하지만 효과적으로 설명한다. 비슷한 주제로 나도 간단히 글을 남겼으니 요것도 참고하시길.

이번 호엔 별로 눈에 띄는 내용이 없네...

153

Google Play Services: Using the Places API

플레이 서비스에 추가된 place API를 적용하는 방법을 설명한다. 예전 POI 관련 기능을 개발할 때 지도는 구글맵을 써도 주변 POI 정보는 관련 api가 없어서 어쩔 수 없이 foursquare의 api를 썼던 기억이 나는데 이젠 구글이 POI 관련 api까지 제공하니 나중에 위치 기반 서비스를 한다거나 할 때 활용하면 편할 것 같다. 물론 한국 내 정보는 다음이나 네이버에 비해 만족스럽지 않긴 하지만.

Boosting the performance for Gradle in your Android projects

꽤 널리 알려진 gradle 빌드 속도 올리기 팁을 소개한다.

build.gradle

task wrapper(type: Wrapper) { gradleVersion = '2.4' }

.gradle/gradle.properties

org.gradle.daemon=true org.gradle.parallel=true

The Ins and Outs of Gradle

안드로이드 gradle에 입문하는 분들에게 도움이 될 소개글이다.

Hardware-accelerated disk encryption in Android 5.1

안드로이드 5.1엔 디스크 암호화에 하드웨어 가속 기능이 추가되었다고 한다. 벤치마크 결과를 보면 소프트웨어 처리한 경우보단 2배 더 빠르지만, 그럼에도 불구하고 암호화 하지 않은 경우보단 40% 느리다고 한다. 넥6 등의 디바이스는 이미 지원을 할 수 있지만 안정성의 문제로 실제 활성화되어 있진 않다고 한다.

아직 안드로이드의 OS 수준의 암호화는 소프웨어어적 처리만 지원하고, 이걸 켜면 디스크 I/O가 두배 정도 느려질테니 활성화되기 어려운 상태로 보이네.

Espresso UI testing with RxJava

RxJava를 Espresso에 사용할 수 있도록 만든 RxPresso 소개글이다.

강력한 언어가 필요한 곳이 어쩌면 테스트가 아닐까 싶은데, 그런 점에서 꽤 괜찮은 시도로 보인다. 멋지네!

rxPresso.given(mockedRepo.getUser("id")) .withEventsFrom(Observable.just(new User("some name"))) .expect(any(User.class)) .thenOnView(withText("some name")) .perform(click());

Frame Animations in Android

안드로이드에서 frame animation을 구현하는 방법을 설명한다. 전통적으로 animation-list를 사용하면 되었는데, animated-selector는 처음 구경했네. lollipop 이상만 지원할 거라면 아주 쉽게 구현할 수 있게 되었네!

154

Using Transitions API to Create Android App Animations

Activity 정도의 transition은 사용했는데 kitkat에선 transition framework란게 추가되었었네. scene을 정의하고, scene 간 애니메이션을 줄 수 있어서 뭔가 유용하게 쓰일 수 있을 듯 하다. 안드로이드 training에도 관련 문서가 있으니 이쪽 먼저 들여다봐야겠다.

음, 154도 그닥 볼 거리가 많진 않았다.

155

Only on Android

유명한 roman nurik 아저씨의 포스팅이다. 5개의 앱들이 상호작용하여 핸드폰의 배경사진을 와치의 배경으로 설정하는 과정을 설명한다. 안드로이드로는 이런 것도 가능해! 라는 플랫폼 자랑. 5개의 앱들을 엮는 과정이 재밌다.

cheesesquare

구글에서 support library를 만드는 chris banes가 만든 android design library 데모. 오호!

156

Android Design Support Library

구글 I/O 에서 소개된 design support library의 여러 컴포넌트를 소개한다.

157

Gradle tip #1: tasks

이제 gradle 모르곤 android 개발을 하기 어려운 시기가 되었는데도 gradle 문법은 볼 때 마다 헷갈린다. 3개 파트로 나뉜 글인데, 읽으면 도움이 많이 될 듯?

Developing for Android, III: The Rules: Performance

유명한 chet haase 아저씨의 글이다. 여러 좋은 말씀들이 적혀있는데, 그 중 levelDB 소개 글이 눈에 띄인다.

서비스에 대한 언급에선 Services Should Be Bound or Started, Not Both라는 부분이 눈에 띄고, Avoid View-Related References in Asynchronous Callbacks 등도 눈에 띈다.

Part I 부터 시리즈 전체를 한번씩 쭉 읽어보면 좋을 듯.

Open-sourcing Facebook Infer: Identify bugs before you ship

안드로이드 개발에 사용할 수 있는 정적 분석도구가 이미 꽤 여러가지가 있는데, 페이스북이 만들었다고 하니 다시한번 눈길이 간다. github 페이지를 보니 여전히 열심히 개발중이네. 오호!

Droidcon Montreal - Dave Smith - Mastering Recycler View

Recycler view 내부 동작을 다룬 발표라서 한번 봐 둬야겠다.

158

Exploring the new Android Design Support Library

design support library의 여러 컴포넌트를 소개하는데, 이런 저런 옵션 용도를 잘 보여준다. 굳굳

Why you should avoid using an event bus

나도 eventbus를 꽤 오랫동안 사용해오고 있는데, 마구 쓰면 위험할 수 있는 도구라는 데 동의한다. 이 글은 몇 가지 주의해야 할 점을 얘기하고 있다

이벤트 처리 도중에 또 이벤트를 만들어서 eventbus로 던지지 말아라.

이벤트가 생기면 바로 subscriber들에게 전달될거라고 생각하지 말아라.

그리고 이런 저런 대안으로 역시나 RxJava를 소개... 역시나 대세는 RxJava인건가!

Level-up with Android Studio Shortcuts and Live Templates

여러 안드로이드 스튜디오 단축키 팁들을 적어뒀다. 다 수족같이 부리면 좋겠지만, 그렇진 못해도 몇 개는 익혀둡시다.

Hidden Cost of Transparency (100 Days of Google Dev)

투명은 비싸다! 가아아아아급적 피하자!

159

Codelab for Android Design Support Library used in I/O Rewind Bangkok session

요것도 design support library 관련 글인데, 실제 적용하는 code lab 부분을 기록해 둔 글이라 도움이 많이 될 듯 하다.

Boom! Screenshot! Level up your test debugging with RunListener

ui automator 테스트 라이브러리를 이용해 손쉽게 스샷을 찍는 방법을 알려준다.

Android TextView-LinkBuilder

텍스트뷰에 링크를 넣는 쉬운 방법으론 fromHtml 정도가 있을텐데, 이 라이브러리도 편하게 쓸 순 있을 듯 하다. 하지만 쓸 일이 있을까?

160

Use colorPrimary to colorize your App Bar

테마를 이용해 툴바 색상을 지정하는 방법을 다룬다. 이젠 액션바가 아닌 앱바가 정식 명칭이군.

Introducing DeepLinkDispatch: Easy Declaration and Routing of Your Deep Links

딥링크를 쉽게 활용하기 위해 airbnb가 만든 DeepLinkDispatch 소개 글이다. 웹이랑 앱이랑 같이 운영하는 서비스라면 고민해볼 내용이겠다.

Part 2 – Welcome Snackbar, Goodbye Toast!

여러 파트로 나눠 snackbar를 다루고 있다. design support library에서 가장 눈에 띄는 부분 중 하나가 snackbar인데, toast를 완전히 대체하긴 어렵겠지만 undo 등등 사용자 경험을 높이는 데 유용할 듯 하다.

CatKit

고양이 placeholder. 이게 뭐야 ㅋㅋㅋ

LAYOUT TRAVERSALS ON ANDROID

레이아웃 패스 등을 다룬 좋은 자료인데, 아이고 어렵다. 영상이랑 같이 찬찬히 봐야겠다.

#android #Android Weekly

Android Weekly 147~150 리뷰

밀린 Android Weekly 몰아보기!

147

The Hitchhiker’s guide to Android Testing, part 2: Espresso

espresso 초기 설정 관련 글이다. 구체적인 설정/실행 방법을 담고있다.

TED MOSBY - SOFTWARE ARCHITECT

mosby라는 안드로이드 MVP 프레임워크를 다룬 글이다.

안드로이드에서의 MVP 개괄로 시작해, mosby로 구현하는 방법까지 상세히 소개한다. ViewState라는 모듈을 이용해 화면 회전을 처리한다는 부분이 눈에 들어오네. 너무 상세해서 다 읽어보진 않았는데, 나중에 MVP 프레임워크를 고를 때,혹은 직접 구현하려고 할 때 참고하면 도움이 많이 될 듯 하다. 고민이 많이 녹아든 듯?

Android Graphics Pipeline: From Button to Framebuffer (Part 1)

두 파트로 나눠 안드로이드의 뷰 표현을 상세히 설명한다. 아주 상세히 설명하기 때문에 어렵다T_T

으음... 어렵다. ICS에선가 개선된 display list reordering 관련 내용도 다루는데, 역시 어렵다. 지적 호기심이 충만하신 분들은 한번 읽어보시길.

Dagger 1 to 2 migration process

제목만 보면 안드로이드용 DI 프레임웍인 dagger 1에서 2로 마이그레이션 하는 내용만 다룰 것 같은데, 앞단에 안드로이드 환경에서의 DI 관련 이슈와 함께 2가 1보다 나은 점도 간략히 다루고 있어서 훓어봐 두면 좋을 글이다. 그런데 dagger 2가 1보다 나은 가장 중요한 이유가 proguard friendly 때문이라니...

본론으로 들어가선 안드로이드 MVP에서 DI를 활용한 샘플 프로젝트를 dagger 1에서 2로 마이그레이션 하는 과정을 보여준다. Component라는 것이 생겨서 Module 선언 시 annotation으로 지정한 것들을 Component 클래스의 annotation으로 지정하는구나. 근데 dagger 1도 살짝 관련 글들만 읽어봐서 영 무슨 이야기인지 다가오진 않네. dagger 2 쓸 일이 생기면 그 때 다시 보는걸로...

Custom Drawables

아래 요구사항을 충족하기 위한 구현을 custom drawable로 구현한 과정을 설명한다.

구현 결과물은 gist로 공개되어 있다. 큰 틀에서 본 구현은 다음과 같다.

level drawable로 reveal 정도를 표현했다. 5000을 selected로, 0과 10000을 unselected로, 0~4999와 5001~10000을 그 사이 단계로 정의했다.

draw() 메서드에서 selected drawable과 unselected drawable을 섞어 canvas에 그린다. Canvas.clipRect() 로 level 비율에 맞게 두 drawable을 잘라 그렸다.

재밌는 아이디어네!

AlarmManager Regression in Android 5.1

안드로이드 5.1부턴 AlarmManager.setRepeating()의 최소 실행 주기가 1분으로 예고도 없이 바뀌어버렸다는 내용을 지적한 글이다.

4.4부터 setRepeating() 이 배터리 수명을 늘이기 위해 부정확한 주기로 수행되었지만, 이는 targetSdk 를 19 이상으로 했을 경우에만 해당했다고 한다. 하지만 5.1부터는 모든 앱이 다 이렇게 동작하니 주의하라고 한다. 이 문제에 대한 대안으로, 짧은 시간에 반복 수행할 내용은 postDelayed()로 구현하라고 이야기한다.

예고도 없이 스펙이 바뀌는 건 참 싫다!

WaitingDots

말 줄임표가 뿅뿅 애니메이션을 하는 귀여운 라이브러리이다.

구현을 보니 각 점 마다 별도의 Span으로 구현했고, 이 Span마다 ObjectAnimator를 두었다. Span에도 ObjectAnimator를 붙일 수 있는 건 처음 알았네!

148

How to install different app variants on one Android device

하나의 디바이스엔 같은 application id를 가진 앱은 하나만 깔린다. 하나 이상 깔려면 application id 를 바꿔야 한다. 이 글은 gradle 환경에서 application id를 바꿔가며 앱을 빌드하는 방법을 알려준다.

ant 시절에도 이런 방법은 있었는데, application id는 manifest의 선언 부 뿐만 아니라 앱의 여기저기 녹아들어가서 두 앱이 독립적으로 동작하게 만드는데는 꽤나 손이 많이 간다. 이 글에선 그런 부분까지 꼼꼼하게 다뤘는데, gradle config에서 resValue 까지 선언할 수 있는 건 처음 알았네. 코드 부분은 BuildConfig를, manifest 부분은 resource를 이용한다면 꽤 많은 appliation id가 언급된 부분을 gradle에서 손쉽게 바꿔버릴 수 있겠다. 굳굳.

Pseudolocalization: Visiting Android's Bizarro World

pseudolocalization은 엉터리 localization을 적용해서 앱의 건강성을 확인하는 테스팅 방법이라고 한다. 처음 들어봤네.

안드로이드 빌드는 이미 pseudoLocalesEnabled 옵션을 제공하고 있었다. release note의 0.14.2 부분에 아래와 같이 언급이 되어 있다. 오, 처음 알았어!

BuildType.pseudoLocalesEnabled flag to include fake locales in apk.

en_XA, ar_XB 라는 두 개의 엉터리 locale이 추가된다고 하니, 디바이스의 언어 설정을 바꿔서 테스트해 보면 된다. 오호!

Dagger 2 + Espresso 2 + Mockito

제목 그대로 dagger 2 + espresso 2 + mockito 로 테스트하는 방법을 알려준다. 하아, 언제 테스트 제대로 하나... T_T

Introduction to Model-View-Presenter on Android

또 다른 MVP 이야기. 이번엔 RxJava + Nucleus 라는 자신이 만든 mvp 프레임웍을 기반으로 설명한다. 다들 mvp 프레임웍 하나씩 들고나오는구나!

Triumph! Android Studio 1.2 Sneaks In Full Testing Support

안드로이드 스튜디오 1.2엔 unit test supporting 기능이 생겨 robolectric 돌리기가 매우 수월해졌다. 이 글은 이 쉬워진 환경에서 robolectric 3.0을 돌리는 방법을 설명한다. 쉬워졌기 때문에 방법도 간단하다~

recyclerview-animators

제곧내. RecyclerView에 애니메이션을 손쉽게 적용할 수 있도록 돕는 라이브러리다. 와우~

FlipViewPager.Draco

오, 플립 애니메이션을 멋지게 활용하는 라이브러리네! 하지만 min sdk level이 14...

richeditor-android

안드로이드용 rich text editor... 이지만 난 쓸 일이 있을까? 기능은 꽤 많다.

SmartTabLayout

텝 전환에 다양한 효과를 제공하는 라이브러리이다. 재밌는 효과들이 많네.

149

How to respond to any messaging notification on Android

NotificationListenerService를 구현하고, 사용자가 해당 앱이 다른 앱의 notification을 읽어올 수 있게 허용할 경우, 다른 앱의 notification이 수신되면, 수신된 notification 정보를 이용해 이런 저런 작업을 할 수 있다. 만약 해당 notification이 WearableExtender를 이용해 만든 RemoteInput을 담고 있다면 바로 응답까지 만들어낼 수 있다. 카톡, 라인, 페북메시지 알림이 오면 자동으로 "지금은 운전중입니다" 와 같은 기능을 만들 수 있다. 안드로이드라서 가능한 기능이네 ^^

Android: Determine when App is Opened or Closed

안드로이드 앱을 만들다보면 앱이 떠 있는지, home 버튼을 눌러서 닫았는지 등이 궁금할 때가 있다. 기본 api만으론 이걸 판단하기 꽤 까다로와서 이런 저런 꼼수들이 많이 개발되었다. 애시당초 api에 없는 건 안하는 게 맞겠지만...

이 글에선 activity 마다 자신이 foreground로 진입했는지, 아닌지를 구현해서 (onStop, onStart 등에서 flag 전환) 이를 구현하는 방법을 보여준다. 하지만 댓글에 보면 이 글의 방식에 대한 지적이 있는데, api 11에 추가된 isChangingConfigurations() 를 쓰면 중간의 timer 작업이 훨씬 깔끔하지 않느냐는 이야기가 있고, api 14에 추가된 Application.ActivityLifecycleCallbacks 를 쓰면 간단하다는 얘기도 있다. 하지만 저자가 이야기하듯, 구버전 지원을 위해선 이런 귀찮은 구현을 피할 수 없지 않을까 하는 생각이 든다.

Android’s 10 Millisecond Problem: The Android Audio Path Latency Explainer

기타로 녹음을 해 보면 귀로 들리는 것에 비해 녹음되는 타이밍이 살짝씩 밀려 latency가 적잖이 신경쓰인다. 애플이야 맥 시절부터 전문 음악 처리 애플리케이션도 많았고, 전통적으로 오디오 처리에 강세를 보였기 때문에 iOS에도 많은 음악 전문 앱들이 있다. 하지만 안드로이드에는 latency가 꽤 크기 때문에 이런 전문 오디오 앱을 만들기 힘든가보다. 이 글은 안드로이드에선 어째서 이런 latency가 발생하는지 설명한다. 근데 뭔 얘긴지 봐도 모르겠다. 하여간 이 그림이 총정리 버전이다.

이걸 보면 안드로이드에서 하이엔드 오디오 처리 앱을 만들기는 불가능할 지도 모르겠네.

material-dialogs

api 8+ 부터 지원하는 머티리얼 다이얼로그 라이브러리이다. 깔끔하니 좋구나!

Curved-Fab-Reveal-Example

curved animation + reveal animation의 조합을 보여준다. 근데 결과물이 썩 이쁘진 않은데? :-p

vector-compat

롤리팝에 추가된 VectorDrawble의 하위 호환버전인데, 하위 버전이 api level 14+ 라니...

재밌어 보이긴 한데, 실무에선 이런 부분까지 하위호환을 해야 하나? 싶긴 하다.

150

Missing Android Material Components

머티리얼 디자인 가이드에서 소개하는 widget들을 구현하는 방법을 소개한다. 슬라이드가 좌우/상하 모두 이동하니 나처럼 좌우로만 넘겨보지 마시기를. 포스트 하단에 각 페이지에 대한 설명도 친절히 설적어두었다.

What's new in Android Testing Droidcon Italy 2015

안드로이드 테스트와 관련된 중요한 내용은 다 담은 아주 좋은 자료네. 새로운 junit4 기반의 unit test, instrumentation test와 함께 espresso, ui automator까지 다룬다. 최신 안드로이드 테스트 환경과 관련된 거의 모든 내용이 다 망라되어 있는 듯!(물론 내가 아는 범위에서...)

Support Libraries v22.1.0

구글에서 서포트 라이브러리를 만드는 chris banes가 블로그에 쓴 22.1.0 서포트 라이브러리의 주요 변경점을 적은 글이다. AppCompatActivity, AppCompatDialog, theme 등의 굵직한 부분도 유용한데, ColorUtils, DrawableCompat 등 잘 모르고 있던 부분이 나에겐 더 유용했다. 앞으론 tint 많이 써야겠다.

NotRxJava guide for lazy folks

제목이 좀 헷갈리긴 한데, RxJava가 왜 유용한지를 직접 구현해가면서 깨닫게 해 주는 글이다. 대충 넘겨보느라 각 단계를 자세히 읽어보진 않았는데, 시간들여 찬찬히 읽어보면 도움이 많이 될 것 같다.

#Android Weekly #android

Android Weekly 143~146 리뷰

밀린 Android Weekly 몰아보기!

143

Reverse engineering using Androguard - Part 1

Androidguard라는 apk 리버스엔지니어링 도구를 2 파트에 걸쳐 소개한다. 하지만 대게 원하는 건 소스코드일텐데, 글만 읽으면 manifest, layout xml, resource 등의 정보만 얻을 수 있는 것 같다. 뭔가 REPL형식으로 동작해서 편할 것 같긴 한데 쓸 일이 있을까?

Nexus 4 + MultiROM = the ultimate Android testing device

넥4에 MultiROM이란 프로그램을 얹으면 kitkat~lollipop등의 정식 롬 뿐 아니라 cyanogenmod등에서 만든 커스텀롬 등을 손쉽게 교체해서 부팅할 수 있나보다. 장난감 앱 아닌 이상 여러 안드로이드 디바이스에서 필수로 테스트해 봐야 하는데, 하나의 디바이스에서 여러 버전을 바꿔가며 실험해볼 수 있으니 편하겠다. 하지만 내 경우에도 회사엔 여러 디바이스가 있고, 내가 개인적으로 만들어봤자 장난감 앱 수준이라 쓸 일이 있나 싶네.

Scrolling RecyclerView – Part 3

RecyclerView의 smooth scroll엔 duration이 없어서, 여기에 duration을 추가한 구현을 설명한다. duration 자체는 그닥 필요치 않아 보이지만, 내부의 smoothscroll 로직, smoothscroller 설명은 알아두면 도움이 될 것 같다.

CREATING A WATCH FACE WITH ANDROID WEAR API | PART 1

두 파트에 걸쳐 안드로이드 웨어용 와치페이스를 만드는 방법을 설명한다. 설정하고, 설정을 전송하는 부분까지 꼼꼼하게 설명하고 있어서 와치페이스 만들 일이 있으면 참고하면 좋을 듯 하다. 안드로이드와치 하나 사야할텐데...

Continuous Delivery for Android

유명한 CI 도구인 jenkins를 안드로이드 앱 개발 프로세스에 활용하는 방법을 알려준다. pull request - merge 후 빌드 여부 확인하기, lint 돌리기등의 일반적인 태스크 외에 직접 만든 signing plugin도 소개하고, Google Play Android Publisher Jenkins Plugin로 배포까지 하는 방법을 설명한다. 안드로이드 개발 프로세스에 CI를 적용할 생각이 있다면 유용할 듯!

Don't break the chain: use RxJava's compose() operator

안드로이드 개발자 사이에서 한창 유행중인 RxJava의 compose() 명령을 설명한 글. applySchedulers 라는 작업을 예시로 들어 compose를 쉽게 설명한다. RxJava를 사용한다면 알아두면 좋을 듯 하다. 이 글을 쓴 Daniel Lew 아저씨도 square 사람으로 알고 있는데, 이 회사는 괴물들만 다니나.

DialogPlus

안드로이드의 다이얼로그 라이브러리도 이젠 굉장히 많아졌다. holo style, material stype등등. 이 라이브러리는 material design을 채용했는데, 단순 디자인 뿐 아니라 하단에서 쑥 올라오는 형태도 지원하네. 오우! API 10+

144

A useful stack on android #3, compatibility

롤리팝에서 추가된 vector drawable, reveal animation 등을 구버전에서 다룰 땐 어떻게 해야 하는지 설명한다. 똑같이는 못해도 얼추 그럴싸하게 적용하는 방법을 다룬다. 그런데 읽어봐도 꽤 많은 os 버전을 다뤄야하는 입장에선, 게다가 이상한 디바이스가 너무 많아서 엄두가 나지 않는다. T_T

A New Reference App for Multi-device Applications

멀티 디바이스 애플리케이션이라고 해서, 여러 단말에서 뭔가 싱크가 되는 앱인줄 알았는데 안드로이드, 안드로이드 오토, 안드로이드 웨어 대응한 앱이란 의미였네. 미디어 플레이어인데, 나중에 오토나 웨어용 확장을 만들어야 한다면 참고하면 좋을 듯 하다. 아무래도 구글 샘플이니 믿고 참고해봄직 하네.

Supporting multiple themes in your Android app (Part 2)

안드로이드 theme는 너무 복잡한데, 이 글은 한 앱에서 여러 theme를 적용할 때 참고할 내용을 잘 정리해 두었다. 굳이 동적으로 theme을 갈아치울 일이 없더라도 참고해 둘 만한 내용이 많다. theme에 custom attribute 적용하기, 살짝 언급된 drawable에 theme의 속성 적용하기 등등.

중간에 살짝 언급되긴 했는데, api level 21 미만에선 drawable에서 속성값을 찾아가는 부분에 버그가 있나보다. 회피 방법은 google i/o 2014 앱의 픽스를 참고하라는데, 저게 픽스가 맞긴 한가?

롤리팝에 추가된 tint를 color filter를 이용해 흉내내는 방법도 유용해보인다. 이 방법을 이용하면 앱의 bitmap resource 갯수를 줄일 수도 있기 때문에 디자이너도 환영할 듯 하다.

Kotlin for Android (I): Introduction

자바의 대안으로 언급되는 jvm 기반 언어인 kotlin을 간략히 소개하는 글이다. 전에 jake wharton이 쓴 글도 읽어보면 도움이 될 듯. 가장 현실적인 대안이 될 듯 하다. 난 null check 부분이 가장 인상적이었다. 굳굳!

Android MVP - An Alternate Approach

안드로이드 앱 설계 시 Actiivty가 너무 많은 작업을 한다는 점이 항상 지적이 된다. 이 글은 MVP 스타일을 안드로이드에 접목하기 위한 저자의 방식을 소개한다. 기존의 구현들은 MVP 패턴 적용 시 Activity가 view 역할을 했다고 하는데, 이 글에선 activity에 presenter역할을 맡겼다. 내가 적용해왔던 패턴도 activity가 presenter 비스무리한 역할을 했기 때문에 오히려 이러한 설계 방식이 낯익게 다가왔다. 요즘은 MVP 패턴 구현을 위한 라이브러리로 mortar가 많이 언급되던데, mortar를 이용하면 어떻게 구현할 수 있는지도 살펴봐야겠다.

How to publish your open source library to Maven central

gradle 기반의 프로젝트를 maven central에 올리는 방법을 소개한다. 예전에 줏어듣기론 꼭 mvn을 깔아야먄 올릴 수 있는 것 같았는데, 이젠 gradle만으로도 퍼블리시를 할 수 있구나!

TIPS AND TRICKS FOR ANDROID MATERIAL SUPPORT LIBRARY 2: ELECTRIC BOOGALOO

머티리얼 디자인 중 ripple effect를 적용하는 방법, 다이얼로그에 원하는 테마 색 지정하는 방법, 하위 버전에서도 간단히 tint를 적용하는 방법(결국 버전 분기 타서 colorfilter 먹이는 방법이다)을 설명한다. 머티리얼 디자인의 효과를 입힐거라면 꽤 유용한 팁이다.

Going multiprocess on Android

안드로이드 앱은 기본적으로 하나의 process로 실행된다. 하지만 manifest에 android:process 속성만 주면 서비스, 액티비티 등 해당 컴포넌트는 별개의 프로세스로 실행된다. 이렇게 프로세스를 쪼개면 프로세스는 각각의 메모리를 할당받기 때문에 메모리를 좀 더 쾌적하게 확보할 수 있고, 음악 플레이어의 음악 플레이 서비스와 같이 계속 샐힝되어야 할 필요가 있는 컴포넌트는 ui를 담고있는 프로세스가 이런 저런 이유로 죽어도 실행을 보장받기가 수월하기 때문에 유용하다. 하지만 프로세스가 분리되면 vm도 분리되어 버리기 때문에 static field도 동일 참조가 아니게 되는 등 두 프로세스 간 데이터 교환이 쉽지 않을 수 있다. 잘 설계해서 다른 프로세스에서 도는 서비스는 별개의 데이터들을 사용하고, ui 프로세스와는 intent나 handler등을 이용해 독립적으로 구성된 데이터를 전송하면 문제는 해결할 수 있을 것 같다. 말은 쉽지.

여튼 실행을 보장받아야 하는 백그라운드 서비스를 가진 앱이라면 참고하면 좋을 글이다.

145

Android UI Automated Testing

구글 테스팅 블로그에 올라온 글이다. 다 읽어보면 좋긴 한데, 마지막에 친절하게 요약이 되어 있으니 이거라도 알아두자.

UI 테스트를 e2e test(end to end test: 실서버까지 모두 연동한 상태에서 실행하는 테스트)의 형태로 하지 마. 대신 단위 테스트, 통합 테스트, UI 테스트를 만들어서 실행해.

fake server 등 활용해서 독립적으로 실행되도록 해.

테스트하기 쉽도록 의존성 주입 가능하게 앱을 만들어.

애플리케이션을 모듈, 라이브러리로 쪼개서 독립적으로 테스트를 해. 그리고 이 모듈들의 통합 테스트를 만들어서 검증해.

컴포넌트화 한 ui 테스트는 e2e 테스트보다 훨씬 수행속도 빠르고 안정적이니까 꼭 이렇게 해.

아... 참 실천하기 어려운 말이다.

Material Design Navigation Drawer

sizing, styling, navigating의 3부에 걸쳐 navigation drawer에 머티리얼 디자인을 입히는 과정에서 고민할 거리들을 다룬다. 거의 논문수준으로 구글의 여러 앱들에서 navigation drawer가 어떻게 적용되었는지 비교하는지 다룬다. 웃기게도 구글 앱들에서 조차 서로 다르게 동작하고 있다는 게 함정. 지금에 와선 google i/o 2015를 가장 레퍼런스 모델로 보는 게 맞을 듯 하다. 하여간 navigation drawer를 사용하고, 최신 트렌드에 발맞춰 구현하고 싶다면 꼭 읽어봐야 할 글이다.

1부 sizing에선 폭, 상단 이미지의 높이, 프로필 이미지 사진 크기 등을 다룬다.

폭: 폰에선 320dp, 테블릿에선 400dp 을 max로. 본문에도 언급한 Material Design on Android Checklist에선 폭을 다음과 같이 정의한다. 굉장히 구체적이어서 역시 구글스럽달까. > No wider than 320dp on phones and 400dp on tablets, but no narrower than the screen width minus the standard toolbar height (360dp - 56dp = 304dp on the Nexus 5)

헤더 높이: 폭: 높이 = 16:9 로 높이를 설정

프로필 사진: 대충 64dp가 이런 저런 기기에서도 보기 좋더라~

2부 스타일링에선 머티리얼 들어오면서 혼란이 있었던 몇가지 항목을 다룬다.

높이: 왼쪽에서 튀어나올땐 상태바까지 덮고, 오른쪽에서 튀어나올 땐 상태바를 안덮는다.

아이콘: DrawerArrowStyle에 <item name=”spinBars”>true</item> 속성을 주면 멋진 애니메이션이 나온다. 하지만 머티리얼 들어와선 드로워가 액션바를 덮기 때문에 이 애니메이션을 볼 일이 없다(째려봐야 보인다). 쓸데없는 애니메이션은 끄는게 낫다. 저 속성에 false를 줘도 의도한 대로 동작하지 않았다. 그래서 onDrawerSlide 메서드를 override해서 해결했다.

프로필 사진: 보더를 주지 않는다. 둥글게 깎는다. 크기는 위에 언급한 64dp 수준.

커버 사진: 실험해 봤더니 40~50% 검정색 먹인게 이쁘더라. 상태바 위에 얹여야 하므로 ScrimInsetsFrameLayout 갖다써라.

선택 항목들: 구글 앱마다 제각각인데 대충 이렇게 하는게 낫겠더라. ripple 이펙트 먹이자.

선택 항목의 header/ footer: header는 pinning해 두는게 맞는 것 같고(즉, 항목 늘어나도 스크롤 안되게 고정해 둬야겠고), footer는 항목 많을 땐 pinning하지만 항목 적을 땐 그냥 맨 마지막 항목 다음에 자연스럽게 붙이자. <- 근데 이거 구현하려면 어떻게 해야하지? listview 높이와 (item 높이 * 항목 수) 비교해서 계산해야 하나? @_@

3부 내비게이팅은 구현과 관계는 없는, 내비게이션 원론적인 이야기를 한다. 햄버거 메뉴라고 부르는 내비게이션 드로워가 나오면서 옛날 방식인 대시보드 스타일이 필요가 없어졌다. 하지만 내비게이션 드로워 적용 시 고민해야 할 부분이 생겼다. 드로워가 있는 화면의 요건은 다음과 같다. * 현재 화면에 드로워가 존재한다. + 존재함을 사용자가 알 수 있다 (햄버거 아이콘 등) * 현재 화면에 형제(sibling) 화면이 존재한다. 즉, 내비게이션 트리 상에서 동일 depth의 다른 화면이 존재함. * 현재 화면이 트리의 최상위 노드이다.

업(up) 내비게이션 화면의 요건은 다음과 같다. * 현 화면의 부모/상위 화면이 존재한다. * 현 화면이 최상위 화면이 아니다. * 반드시 거쳐가야 하는 형제 화면이 존재하지 않는다.

내비게이션 드로워의 가장 큰 문제는 사용자가 이 녀석의 존재를 알아차리지 못한다는 것이다. 저 세줄 짜리 그어진 아이콘 가지고 "아, 사이드 메뉴 존재하는군!" 알아차릴 사용자는 극히 적으니. 휴우. 이건 대체 어케 풀어야 할까?

A Blurring View for Android

투명 액션바를 붙이고, 위로 스크롤하면 배경 이미지가 슥~ 블러링되는 방식이 한때 유행했다. 근데 머티리얼 나오고 난 다음엔 이런 유행이 사라진 것 같기도 하네. 여튼 블러링이 말이 쉽지 자칫 잘못하면 굉장히 많은 연산이 필요해서 앱 성능에 영향을 미칠 요소가 많았다. 구현체도 순수 java, render script, ndk 등등이 난무했고.

이 글은 500px에서 활용한 블러링 뷰 구현을 소개한다. 데모 비디오에서 보듯 실시간 블러링이 가능하네. 다른 구현들은 대게 백그라운드에서 비트맵 가지고 블러링된 이미지를 만들어내기 때문에 동영상과 같은 실시간 블러링은 하기 힘들다. renderscript를 이용해 구현했고, 이젠 renderscript support library가 있기 때문에 froyo부터 지원가능하다고 한다. 하지만 아무리 그래도 성능 생각하면 그냥 4.0 이상 정도부터 동작하게 하는게 모두를 위해 좋은 방법이지 싶네.

만약 blur 처리가 필요하게 된다면 기억해뒀다가 실험해봐야겠다.

The mysterious case of the Bundle and the Map

hashmap을 intent bundle에 넣었다 빼오면 문제가 없지만, treemap을 넣었다 빼면 ClassCastException이 난다. 왜 난 TreeMap을 넣었는데 뽑아올 땐 난데없이 HashMap이 되는가!

TreeMap map = (TreeMap) getIntent().getSerializableExtra("map"); java.lang.ClassCastException: java.util.HashMap cannot be cast to java.util.TreeMap

이 이유를 열~심히 설명한다. 대강 Parcel.writeMap 내부에서 맵을 풀어서 저장하고, 이걸 복구하는 readHashMap에서 HashMap 형태로 복구하기 때문이라고 알아두면 되겠다. 한마디로: intent에 맵 넘길 일 있으면 HashMap에 담아서 넘기자. 아니면 map을 serialize하는 객체로 한번 더 감싸서 넣던지.

146

Introducing Yahnac: Where RxJava Meets Firebase and Content Providers

Firebase, rx, cursor loader를 이용해 구현한 yahnac(Yet Another Hacker News Android Client)라는 앱의 소개이다. github에 소스코드도 제공하니, 저들을 엮어쓰는 부분이 궁금하다면 살펴보면 도움이 많이 될 듯 하다. 대충 소개만 읽으면 firebase로 제공하는 데이터를 rx로 땡겨 db에 저장하고, 이걸 cursorloader로 ui로 땡겨가는 구현인 듯 하다. cursorLoader로 땡겨가는 건 좀 색다른 듯?

Stetho for Android debug builds only

페이스북에서 만든 도구인 stetho를 debug 빌드에만 적용하는 방법을 소개한다. stetho 정말 물건이다. chrome의 chrome://inspect 를 통해 앱의 network, db를 크롬 개발자 도구를 이용해 조회하는 도구인데, 정말 편하다. 또 크롬 개발자 도구가 워낙 잘 만들어져서 네트웍 로깅 보는데 이것보다 나은 도구를 본 적이 없다. 소켓통신의 경우도 적절히 도구를 손봐서 사용하면 잘~ 들여다볼 수 있다. db도 쿼리를 직접 날려버릴 수 있어서 진짜 짱이다!

Custom Colour Spans

TexView등에 적용할 수 있는 컬러 스팬을 소개한다. 안드로이드의 span은 굉장히 강력하고 유연한데, 이리저리 둘러봐도 그냥 Html.fromHtml() 메서드를 이용하는 방식이 제일 편하더라. 하지만 이 글에서 소개한 ColorStateListSpan 같은 것은 결국 만들어서 써야하는데, 잘만 쓰면 유용할 듯 하다. 하지만 대게는 그냥 style 수준에서 해결하기 때문에 굳이 이런 클래스가 필요할런지.

좀 지나긴 했지만, 이 글은 span 관련 기능을 아주 잘 정리해두었다. 짱!

Using the JobScheduler API on Android Lollipop

롤리팝에 추가된 JobScheduler API를 자세히 소개한 글이다. 근데 이런 api는 단순 ui같이 보여주고 말고 정도가 아니라 앱의 기본적인 활동에 영향을 끼치기 때문에 api level별로 분기해서 적용하기도 쉽지 않아서 어떤 전략을 써야 할지 감이 오지 않는다. 충전 시작하면서 wifi 연결될 때 서버 동기화 한번 땡겨온다거나 하는 경우에 유용할 것 같긴 한데, 그럼 하위 api 레벨에선 어떻게 해야 할지. 둘이 타이밍이 너무 달라지면 그건 또 어떻게하고. 이런 저런 고민하다보면 사용 못할 것 같은데 말이지. 그렇다고 호기롭게 min api level 21로 할 수도 없고.

M — Model in MVC, MVP, MVVC in Android

재밌는 글이다. 흔히들 MVC 등을 언급할 때 M을 단순 entity 클래스 수준으로 잘못 이해하고 있는데, 그게 아니라 엔티티를 다루는 전체 계층(layer)이라는 점을 지적한다.

MVC에서 M을 단순 UserModel.java 수준으로 알고 있다면, 이 UserModel을 db에서 가져온다거나 네트웍에서 fetch하는 작업은 오롯이 C의 몫이 되어야 하는데, 이러다보면 user fetch 코드가 이 C, 저 C 에 흩어질 수 밖에 없다. 설계하기에 따라 C는 액티비티가 될 수도, 따로 정의한 클래스들이 될 수 있겠고. UserModel이란 엔티티를 db나 네트웍에서 fetch한다거나 하는 건 모두 모델 레이어 안에서 처리해야 한다는게 글쓴이의 주장이다. 대게 UserModelApi 나 UserModelRepository 등의 클래스가 이런 역할을 담당할 듯? 여튼 C가 activity라면 activity는 단순히 이들 클래스의 매서드를 호출하기 때문에 코드 중복의 여지가 줄어들것이다.

나도 이런 구조에 동의~

Android Performance Case Study Follow-up

유명인 romain guy의 안드로이드 그래픽 퍼포먼스 관련 글이다. 여기선 Tracer라는 도구를 이용해 OpenGL 관련 명령들이 사용하는 시간을 확인하고, 성능 문제를 파악하는 방법을 보여준다. 예시에선 알파값 관련 문제로 굉장히 많은 명령이 일어났다.

음... 근데 어렵다. OpenGL 관련 내용을 모르니 저 Tracer 결과를 봐도 뭐가 문젠지 알기 어렵네. T_T

Bandhook-Kotlin

kotlin으로 짠 Bandhook 이라는 애플리케이션이다. 오우, kotlin으로 앱 만들 일 있으면 참고하면 많이 도움이 될 듯 하네!

Introducing Fresco: A new image library for Android

페이스북에서 만든 이미지 로더(본문에선 파이프라인이라고 얘기하지만...)인 fresco를 소개하는 글이다. 전반부에 죽~ 설명한 부분을 짧게 요약하자면 AndroidBitmap_lockPixels 라는 NDK 명령을 이용해 ashmem이라는 메모리 영역에 이미지를 로딩한다. 이 메모리 영역은 네이티브 힙 비스무리한 공간인데, lazy하게 메모리를 free하는 특징이 있단다. BitmapFactory.Options.inPurgeable=true 옵션도 이미지를 ashmem에 올릴 수 있지만, 이미 메모리가 unpinned된 이미지를 다시 그려야 할 때 이미지 디코딩이 UI 쓰레드에서 일어나기 때문에 성능 문제가 발생한다. inBitmap 플래그도 좋은데, 일단 3.0 이상에서만 동작하고, 4.4 이전엔 같은 크기의 이미지에서만 먹혔기 때문에 쓰기 쉽지 않다. 하지만 자기들이 사용한 저 명령어를 이용하면 메모리 release만 조심하면, 두 마리 토끼를 다 잡을 수 있다고 한다. 백그라운드 디코딩으로 성눙을 잡고, ashmem 영역을 이용해 lazy free 한 안전한 메모리 영역을 확보하고. GC도 필요없고.

또 하나, drawee라는 이미지 디스플레이 프레임웍을 만들었단다. 이미지 로딩 전 placeholder를 보여주다 로딩 후 원본 이미지를 보여주기 등의 작업을 자연스럽게 처리하기 위해 안드로이드의 Drawable을 이용하는데, 이 각 상황에 맞는 Drawable을 보여주고 조작하고 하는 등의 작업을 해 주는 프레임웍인가보다.

fresco가 너무 복잡하고 무겁다는 지적을 본 적이 있는데, 한번 샘플이라도 돌려봐야겠다. 아직까진 현업에서 쓰기엔 glide가 가장 좋은 선택이라고 생각하는데, fresco는 어떨런지.

The Making of Falcon Pro 3

falcon pro 3라는 앱을 만드는 과정의 이야기를 담은 자료다. 글 url을 보듯이 sqlite가 아니라 realm을 db로 사용한 점이 눈에 띈다. 그 외엔 picasso, retrofit, otto, butterknife 등 역시 모든 사람들이 사용하는 square 오픈소스들을 활용했네. realm 사용 부분이 꽤 재밌다. 앱을 깔아서 써 보니 정말 빠릿빠릿하게 잘 만들었네!

#android #Android Weekly

Android Weekly 139~142 리뷰

밀린 Android Weekly 몰아보기!

139

A Look At Android Support Annotations

support library에 들어있는 support annotation의 용도를 자세히 설명한다. 이 애노테이션은 개발 단계에서 IDE가 똑똑하게 validation을 하기 위한 용도이다. 이번 구글 I/O에서 발표된 내용 중엔 이 애노테이션을 잘 활용하면 디버거 붙여놓고 객체 상태를 볼 때 알 수 없는 정수값이 아닌, 관련 리소스값을 명확하게 보여줄 수 있다.

다른 것 보다 intdef의 경우 보험 상 enum을 사용하던 부분을 걱정없이 int로 대체하는데 많이 도움이 된다.

An exploration in Material Design

Feedly 앱의 머티리얼 디자인 적용기. 근데 원래 홀로 디자인을 잘 적용해서 그런지 딱~히 임팩트가 크진 않네. 8dp 그리드, 컬러, 상단 바, 우측 패널 부분이 인상깊었다. 하지만 우측 패널에서 보이는, 머티리얼 샘플이나 앱들에서 보이는 글자 애니메이션은 너무 과하지 않나~ 하는 생각이 든다.

7 Rules for Creating Gorgeous UI (Part 2)

딱히 머티리얼 디자인이나 앱 디자인 관련 내용은 아니지만, 눈여겨 볼 만한 여러가지 디자인 팁들을 제공한다. 하지만 현업에서 내가 이런 내용을 써 먹을 일은 거의 없겠지.

StyledDialogs for Android

2.2+ 에서 활용할 수 있는 머티리얼 디자인의 다이얼로그. 깔끔하니 좋아보인다. 하지만 DialogFragment로 구현되어 있는데, DialogFragment는 좀 꺼려지네. 관련 크래시를 많이 접해서 차라리 그냥 고전적인 Dialog가 더 좋은데.

140

A useful stack on android #2, user interface

머티리얼 디자인 적용 방법을 보여주는 좋은 자료이다. 툴바, 팔렛트, 트랜지션, 벡터 드로어블까지 소개한 종합 선물셋트네!

RecyclerView Animations Part 1 – How Animations Work

두 개의 파트로 나눠 리사이클러뷰의 애니메이션 작동방식을 설명한다. 파트1 에선 RecyclerView 와 LayoutManager 사이에서 어떤 식으로 뷰를 다뤄서 등장/퇴장 애니메이션이 가능한지 설명하였고, 파트2는 좀 더 내부구현을 다룬다. 굉장히 자세히 다루는데, 파트2는 따라가기 어려울 정도로 쉽지 않네. LayoutManager를 만들 게 아니라면 실제로 여기까지 이해하고 쓸 필요는 없을 것 같긴 한데, 굉장히 흥미로운 내용이니 관심있으면 눈여겨 봐 두면 좋겠다. 근데 어렵다.

ProTip: Menus are positioned over their emitting elements

머티리얼 가이드라인 중 셀렉트 박스가 옵션 위에 얹혀야 한다는 내용이 있나보네. 내용도 간단히 PopupMenu 스타일에 <item name="android:overlapAnchor">true</item> 속성만 추가하면 된다고 하니, 잊어버리지 말고 적용해봐야겠다.

Building a RecyclerView LayoutManager – Part 1

3부로 나뉘어진 글로, RecyclerView의 짝궁인 LayoutManager를 직접 구현할 때 고려해야 할 점을 굉장히 자세히 설명한다. LayoutManager 직접 만들 일이 언제 있겠나 싶긴 하네.

material-calendarview

CalendarView 의 backport인데, min sdk 버전이 14라니, 쓸 일이 있을까 싶긴하다. 데모는 이쁘긴 한데.

141

An Investigation into Flow and Mortar

square는 fragment를 싫어하는지, fragment를 custom view로 대체하려는 시도를 블로그에 올리기도 했고, fragment를 대체할 flow 와 mortar를 공개했다. 이 글은 flow와 mortar를 이용해 복잡한 뷰를 구현하는 방법을 설명한다. flow는 screen이란 개념으로 뷰를 조합하여 화면을 구성하는 라이브러리이고, mortar는 dagger와 엮여 Blueprint, Presenter라는 모듈로 의존성을 주입한다.

Flow는 Screen을 이용해 애플리케이션을 구성한다. Screen은 POJO 객체로, 내부에 로직과 View를 포함하고 있고, Flow 객체는 Screen의 백스택을 관리한다.

그런데 내 경우를 보자면 아직까진 태블릿 등의 대응을 해 보지 않아서 그런지, fragment는 tab, view pager 정도에만 사용해와서 뭔가 새로운 설계를 적용할 필요를 거의 느끼지 못했다. 제일 문제를 많이 일으키는 건 오히려 dialog fragment였고, 이건 차라리 그냥 dialog로 대체해서 처리한 적이 많았고. 아직까진 필요성을 크게 느끼지 못하겠네.

How-To Create a Working Kiosk Mode in Android

안드로이드 앱을 키오스크같이 만드는 방법을 설명한 재밌는 글이다. 쓸 일은 없을 것 같긴 한데, 시스템 다이얼로그 끄기, 여러 하드웨어 버튼 무효화하기, 홈 버튼으로 내려버려도 다시 좀비같이 살아나기 등의 방법을 설명한다.

LoganSquare

전에도 슬쩍 본 것 같은, 빠른 속도를 표방한 json 파서이다. 애노테이션을 이용해 컴파일 타임에 미리 클래스를 만들어둬서 파싱을 빠르게 하는 듯. 아이디어는 좋은데 진짜 많이 쓰이나?

Using the Android Auto Media Browser

안드로이드 오토는 미디어 브라우저와 메신저 모드의 2가지 모드를 제공한다. 이 글은 이 중 미디어 브라우저 모드로 동작하는 방법을 설명한다. 꽤나 자세히 설명하고 있으니 혹시나 음악 플레이어 앱 등을 만든다면 적용해봐도 좋을 듯 하네.

AwesomeText

안드로이드의 Span은 잘 활용하면 굉장히 다양한 효과를 줄 수 있다. 하지만 쓰기가 귀찮고 번거롭다. 이 라이브러리는 Span에 여러 효과를 손쉽게 줄 수 있도록 돕는다. 직접 이 라이브러리를 쓸 일은 없을 것 같지만 나중에 Span을 다룰 일이 있을 때 참고삼아 활용해보면 좋을 듯 하네.

142

Sending Messages to Android Auto

이 글은 앱이 안드로이드 오토에서 메신저 모드로 동작하도록 만드는 방법을 설명한다. 역시 술술 따라하다 보면 쉽게 적용해볼 수 있다. 하지만 안드로이드 오토 자체가 메신저 모드에선 그닥 제공하는 기능이 없기 때문에 좀 아쉽다.

참고로 시뮬레이터 앱에서 보는 것과 실물 기기에서 돌려보는 게 차이가 꽤 나므로 실무에서 고민한다면 실 기기를 하나 장만해야 제대로 테스트 해 볼 수 있을 것이다.

Replace AsyncTask and AsyncTaskLoader with rx.Observable – RxJava Android Patterns

RxJava 이야기는 하도 여기저기서 나와서 이젠 안쓰면 안될 것 같은 느낌마저 들 정도이다. 이 글은 복잡하게 얽힌 요청이 아닌, 간단한 네트웍 요청을 처리하는 방법을 알려주는 RxJava 소개 문서 정도로 보면 된다.

MPAndroidChart

안드로이드 차트 라이브러리인데 디자인 아주 훌륭하네! 예전에 차트 라이브러리 가져다 쓸 때 customizing하느라 손이 꽤 갔었는데 이 라이브러리는 디자인이 훌륭해서 손이 많이 안 갈 것 같다. 나중에 차트 쓸 일이 있다면 활용해보고 싶다.

ArcAnimator

머티리얼 관련 앱들을 보면 원이 쑥~ 커지면서 transition하는 등의 애니메이션을 보여주는데, 이런 transition 제작에 도움이 되는 라이브러리.

#Android Weekly #android

참으로 오랫만에 책 한권을 다 읽었다. 이젠 절판된 단편 SF 모음집으로, 몇년 전 알라딘에서 할인행사를 할 때 냅다 샀던 것으로 기억이 난다.

하인라인, 아이작 아시모프, 필립 K. 딕, 어슐러 르 귄 등 유명한 작가의 단편 작품 24편이 실려있다. 집중력이 떨어져서 장편보단 단편이 좋은(-_-;) 나에게 딱 맞는, 재밌는 책이었다.

책 자체는 읽다말다해서 읽은 기간이 굉장히 오래되어 딱히 뭐가 제일 재밌었는진 기억이 안나는데, 최근 읽은 후반부에서 가장 재밌었던 소설은 파이어즈 앤터니란 작가의 은하치과대학이다. 은하치과대학이라는 은하계에서 알아주는 치대에 지원한 지구인이 주인공으로, 실기 시험과 필기 시험, 시험 전날 일어나는 사건 사고가 매우 재밌게 그려져있다. 분량도 짧으니 혹시나 다른 SF소설 묶음집에서 찾아볼 수 있다면 한번 읽어보세요~

이미 절판된 책이라 구하긴 어려울텐데 가볍게 읽을 SF소설을 찾고 있다면 도서관 등에서 찾아보세요.

#sf #독후감

2015 구글 I/O 참관기

시작

5/28, 29 이틀 동안 샌프란시스코에서 열린 구글 I/O에 다녀왔다. 안드로이드 개발자들은 꼭 가보고 싶어하는 행사인데, 이렇게 참석할 수 있어서 참 행운이었다.

샌프란시스코는 작년 10월에 AnDevCon 참석하느라 한번 다녀와서 시내는 조금 익숙했다. 1년도 지나지 않아 이 곳에 다시 오게 될 줄은 몰랐는데. 그런데 10월보다 훨씬 춥게 느껴졌다. 두꺼운 후드티를 챙기지 않았다면 낭패였을 뻔 했네.

공항 입국심사를 하는데 새로운 기계가 생겼다. 원래 입국심사 할 때 입국심사관이 양손 지문을 다 찍고, 사진도 찍는데 이걸 전자기기로 대체했다. 줄 서 있는데 "이번이 미국에 처음온거니?" 물어봐서 아니라고 했더니 기계 쪽으로 안내를 하더라. 여기에 지문 찍고, 사진 찍으니 뭔가가 출력되어 나왔는데 커다랗게 X 표가 쳐져 있었다. 다른 분들이랑 얘길 해 보니 이게 X 표 쳐지면 다시 심사관에게 지문, 사진을 찍어야 하고 통과되면 그냥 지나갈 수 있나보더라. 아무튼 이젠 이 기계 덕에 미국 입국심사가 조금은 빨라지지 않을까 싶네.

컨퍼런스 전날 도착했다. 키노트 참석하려면 선착순이라고 해서 공항에서 Bart를 타고 Powell역에 내리자 마자 모스콘 센터로 직행해서 뱃지를 받았다. 목걸이형 뱃지, NFC태그 달린 팔찌, 첫날 after hour party 참석용 팔찌, 물통, 티셔츠를 받았다.

참석자는 키노트 참석 여부에 따라 지정된 로얄 구역에 좌석이 확보된 회색 태그, 키노트 참석할 수 있지만 줄 서야하는 파랑 태그, 키노트 참석 못하는 오랜지 색 태그로 구분이 되었다. GDG 운영진 분들은 회색 태그를 받았더라. 난 파랑 태그였고, 늦게 뱃지를 수령하신 분들은 오렌지 색 태그를 받았다.

호텔에 짐 풀고 간단히 시내 구경을 했다. 코스는 작년이랑 똑같이, 부에나비스타에서 아이리시 커피 한 잔 먹고, 보딘에서 크램 챠우더 먹고, 피셔맨스와프 슬 둘러보고 돌아오는 프로그램이었다. 아우 왜이리 추워!

숙소로 돌아와서 잠깐 쉰다는게 내리 뻗어 자다가 9시에 일어나 월그린에서 맥주와 물, 과자 좀 사고 버거킹에서 햄버거 하나 사서 호텔로 돌아왔다. 호텔에 와선 네오위즈 인터넷에서 온 3분과 우리팀 분들 이랑 맥주 좀 마시고 첫날을 마무리했다. 사온 버거킹 반쪽을 먹었는데, 미국이라고 막 엄청 버거가 크다거나 하진 않더만.

현장 소감

첫날은 키노트에 참석하려고 일찍 일어났다. 어차피 시차 때문에 눈이 번쩍 떠 지더만. 9시 시작이라 7시에 나가면 충분하겠지 생각했는데 이미 우리가 갔을 땐 줄이 모스콘 센터를 거의 한바퀴 감싸고 있었다. 사람들 부지런하네~ 줄 서있는데 옆에서 커피, 바나나, 도넛을 나눠줬다. 참 좋네.

한참 기다려서 키노트 행사장에 들어왔다. 삼면의 벽을 스크린으로 애워쌌는데 굉장히 멋졌다. 그 화면에서 퐁을 하는데, 구경하다가 목 돌아가는 줄 알았네.

시간이 되어 멋진 영상이 나온 다음 (사운드도 굉장히 훌륭하더라! 와우!) 본격적으로 키노트가 시작되었다. 키노트를 영상으로 보는 것과 행사장에서 바로 보는 건 확실히 감동의 차이가 컸다. 우와~ 내가 I/O 키노트 현장에 와 있다니! 어차피 키노트 내용은 여러 기사들이 나보다 더 잘 정리해 뒀으니 내용 정리는 다 건너뛴다. ㅎㅎ

난 안드로이드 앱 개발자라 안드로이드 세션을 집중적으로 들었다. 세션은 크게 커다란 방에서 진행하며 녹화도 되는 공식적인 세션과 sandbox talk라고 따로 녹화는 하지 않고 소규모로 진행하는 세션으로 구분되었다. 공식 세션은 신기술 발표 위주였기 때문에, 난 안드로이드와 관계되는 공식 세션과 sandbox talk를 섞어 들으려고 했다. 그런데 sandbox talk 진행되는 장소가 너무 좁고, 장소 자체도 강의실 형태가 아니라 둥그런 천막같이 이쁜 형태라서 많은 사람을 도저히 수용할 수 없었다. 사람들이 막 벽의 빈 틈으로 고개 디밀고 깨끔발을 하면서 들었는데, 조금만 지나도 너무 피곤해지더라. 게다가 대부분의 sandbox talk가 30분이었는데 10분은 정리하느라 20분 정도만에 끝났다. 그러니 뭔가 기대했던 깊이의 지식을 얻긴 어려웠다. 게다가 발표된 신기술 중에 엄청 재밌어보이는 것들이 많이 포함되어 있어서 차라리 공식세션만 계속 들었어야 했나 하는 생각이 들었다.

세션 정리

Android M

퍼미션 퍼미션을 간단하게 정리하고, 사용자가 on/off 할 수 있는 건 참 환영할 만한 개선이다. 그런데 개발자 입장에선 사용자가 언제 퍼미션을 뺐어갔는지 모르니 일일이 신경을 써야 해서 과연 어떤 헬게이트가 열릴지 모르겠다.

크롬 커스텀 탭 앱에서 웹을 보여줄 때 지금까진 웹뷰를 띄워거나 외부 웹 브라우저로 던지는 방법을 사용했다. 하지만 웹뷰의 경우엔 사용자가 기존에 웹 브라우저에 저장해둔 세션을 유지하기도 어렵고, 여러가지 기능 제한이 있어서 아쉬운 점이 많았다. 크롬 커스텀 탭은 이 둘을 적절히 절충한 방식으로, 실제론 크롬 브라우저의 탭이 뜨지만 여기에 여러가지 커스터미이징(UI 변경, 커스텀 버튼 추가 등)을 할 수 있다. 그런데 우리나라 사람들이 크롬 브라우저 많이 쓰나? 개발자들이야 다들 자기가 좋아하는 브라우저를 깔아 쓸테지만, 대부분의 사용자들은 기본 브라우저만 쓸 텐데. 아니면 네이버나 다음 앱을 브라우저 용도로 사용하는 경우도 많고.

앱 링킹 안드로이드 사용 중 일부 앱과 관련된 링크를 누르면 "어떤 앱으로 띄울래?" 알림이 뜨는데 이 부분을 이제 더 스마트하게 처리하게 된다. manifest의 intent filter에 autoVerify 속성을 주고, 웹 사이트엔 statements.json란 문서를 등록해 두면 앱과 관련된 url을 바로 해당 앱으로 띄운다. 이 기능은 꽤 유용할 듯 싶다.

나우 온 탭 키노트 때 보고 깜짝 놀랐던 기능이다. 키노트 데모에선 skrillex 음악을 틀어놓고 나우 온 탭 기능을 켠 상태에서 "이 사람 본명이 뭐야?" 라고 물어보니 자동으로 질의를 "skrillex 본명이 뭐야?" 라고 바꾸곤 결과를 보여줬다. 링크를 읽어보니 구글이 뷰 계층을 뒤져 텍스트/이미지를 가져와서 이를 해석한다고 한다. 난 특정 api를 구현해야 하나 생각했는데 대단하네. 링크엔 비밀정보 노출등의 내용이 언급되어 있으니 더 알고 싶으면 링크를 읽어보세요.

doze 모드 어느 정도 폰을 사용하지 않으면 doze 모드에 진입하는데, doze 모드에선 walk lock등이 무시된다고 한다. 이제 배터리 수명 좀 늘어나려나...

오토 백업 앱 데이터를 사용자의 구글 드라이브에 자동으로 하루에 한번씩 암호화해서 싱크해 둔다고 한다. 앱 재설치, 기기 교체 등의 경우 백업된 데이터로 앱을 복구한다고 하네. udid 같은 파일도 복구된다면 이래저래 쓰임새가 많을 듯 하다.

Smart lock 딱히 이번 I/O 에서 발표된 건 아닌 듯 싶기도 한데, 롤리팝에서 이미 등장했지만 모르고 있었던 기능이다. 위치, 신체 활동에 따라 기기 락을 풀어두는 기능이다. 예를 들어 집에선 잠금 모드가 되지 않는다거나, 내가 계속 들고 다니는 와중엔 잠금이 되지 않는 등의 설정이 가능하다.

Multi Window Mode 화면 분할 모드가 생긴다는데... 키보드 뜨는 위치, 강제 화면 로테이트 등이 어떻게 처리될런지 모르겠네.

안드로이드 개발 도구 & 라이브러리

안드로이드 스튜디오 1.3 이제 NDK 개발도 가능하다고 한다. CLion이 AS에 탑재된다고 하네. 또 여려 annotation이 추가되어 코딩 시점에 validation이 가능하고, 이 정보를 디버그 시에도 활용한다고 한다. 더 이상 중단점 걸고 인스턴스의 속성을 볼 때, view 의 visibility 값이 0 이나 1 이 아닌, INVISIBLE, VISIBLE 등의 값으로 표시된다! Theme, style의 미리보기도 강화된다고 하고(!!), 그레들도 빨라질거라고.

jack & jill 새로운 툴 체인인 jack & jill 도 언급했다. 자바 8도 지원할거라고 하고, 여러 속도 개선이 이뤄진다고 하니 기대된다!

cloud test lab 기기 파편화 대응을 하려고 지금까진 앱 개발사들이 자체적인 노력을 했는데, 이제 실 기기 테스트를 지원하다고 한다. 멍키테스트 비스무리한 자동 테스트도 가능하고, espresso 등의 도구용으로 만든 테스트 케이스도 돌릴 수 있다고 한다. 개발자 콘솔에 포함되어 제공될 예정이라네.

Design Support Library 스낵바, FAB, 툴바 애니메이션 등 머티리얼 디자인의 요소들을 쉽게 구현할 수 있는 라이브러리. 하지만 아직 버그가 너무 많아서 좀 더 기다려봐야 할 듯.

GCM GCM 인증방식이 바뀐다고 한다. instance id라고 하던데, 뭔가 udid 같은 성격으로 보인다. ios 지원도 하고, subscibe 모델도 지원한다고 하니 소규모 앱에선 꽤 유용할 듯 싶다.

Data Binding xml이 단순 레이아웃만 처리하던 수준을 벗어나 이제 바인딩 관련 기능도 들어간다고 한다. 단순 data 바인딩하면 되는 뷰라면 꽤 편하게 활용할 수 있을 듯 하다. 또한 findViewById 할 필요 없이 view id 를 가지고 바로 뷰 필드에 접근할 수 있게 되어 많이 간편해질 듯 하다.

기타 프로젝트

GoPro를 이용해 손쉽게 VR 컨텐트를 만들 수 있는 JUMP, 섬유를 터치 센서로 이용하는 Jackquard, 레이더 센서 Soli 등의 프로젝트도 매우 흥미로웠다.

그리고 넥서스 사용자라면 바로 구글 플레이에서 Splotlight Stories 받아서 체험해 보길 권한다. 영화를 360도로 찍어서 마치 FPS 즐기듯 볼 수 있는데 너무 신기하더라.

정리

sandbox talk는 장소의 문제, 세션 깊이의 문제 등 좀 실망스러운 부분이 있었다. 내가 I/O의 성격을 잘못 알았나. 오히려 이런 기술 세션보단 눈돌아가는 신기술 체험 & 안드로이드 생태계 개발자의 축제의 장으로 받아들였다면 I/O를 훨씬 잘 즐길 수 있었을 것이다.

여러모로 즐거운 경험이었고, 기회가 닿는다면 한번 쯤 참여해보시길 권한다.

#google i/o #io2015

parse.com의 api 호출 테스트하느라 만들어본 intrumentation test 작성기

parse.com에 만들고 있는 앱에 테스트 데이터를 만들고, api도 호출해 보고 싶어졌다. robolectric을 사용해보려고 했다. 이런 거 손으로 한두번 돌려보다가 결국 나중엔 자동화 도구를 찾게되기 마련이라 애초에 처음부터 준비를 하는게 시간과 에너지를 절약하는 길이다.

android studio 최근 버전에선 robolectric을 사용하기 매우 편해졌다. robolectric도 이번엔 과감히 3.0을 사용했다. 연동 방법은 이 글에 잘 나와있다. 요약하면 android studio에서 unit test TestArtifact 기능 활성화 하고, robolectric 3.0 의존 관계만 gradle에 추가하면 그냥 끝난다. 예전엔 gradle plugin도 추가하고 이것저것 해 줘야 했는데 엄청 편해졌다. 게다가 3.0엔 RobolectricGradleTestRunner 도 추가가 되어 더 편해진 듯.

하지만 테스트 실행하면 바로 아래 예외가 튀어나온다.

Exception in thread "ParseRequest.NETWORK_EXECUTOR-thread-1" java.lang.UnsatisfiedLinkError: no javacrypto in java.library.path

딱 이 예외는 아니지만 비슷한 문제가 robolecric github 이슈에 등록이 되어있고, 'unit test에선 직접 api 호출하지 말고 mocking하세요' 라는 교과서적인 대답이 달려있다. 이게 참 맞는 말이긴 한데, 슬쩍슬쩍 api 호출 한두개 할 때 robolectric을 쓰기가 어려워져서 아쉽네.

저 예외를 꾸역꾸역 해결해서 robolectric으로 내가 원하던 api 호출이 가능하게 만드느니 그냥 자연스럽게 instrumentation test를 만들어서 해결하는 방향으로 선회했다.

instumentation test는 정말 오랫만에 다시 들여다봤는데, 이 쪽도 그 사이에 많이 바뀌었다. Building Instrumented Unit Tests를 보면 이제 android testing support library 덕분에 junit4 기반으로 테스트를 만들어서 돌릴 수 있다. 내 경우 현재 최신인 22.1.1 support v4와 test runner v0.2 를 같이 붙이니 support annotation의 버전 차이 때문에 gradle의 dependency에 문제가 생겼다. 이 문제는 아래와 같이 해결했다.

androidTestCompile 'com.android.support:support-annotations:22.1.1' androidTestCompile('com.android.support.test:runner:0.2') { exclude group: 'com.android.support', module: 'support-annotations' }

이제 android studio의 Test Artifact를 다시 Android Instrumentation Tests로 돌리고, app/src/androidTest/java 밑에 테스트 클래스를 만들어서 돌리니 잘~ 실행이 된다. 워낙 테스트가 간단하고 프로젝트가 (아직은) 작아서 그런지, 예전 느낌과 달리 빌드와 실행도 금방 끝나네. 항상 robolectric에만 의존하는 습관이 있었는데, 어찌보면 단위 테스트보다는 일종의 통합 테스트라고 볼 수 있는, 직접 api 호출하는 테스트는 intrumentation test가 답인지도 모르겠다. 예전에 비해 이젠 작성하기도 많이 편해졌다. 작성 샘플은 안드로이드 문서를 참고하면 된다.

#android #instrumentation_test #test

Trending Blogs

Recently Viewed Blogs

오리대마왕님 텀블러