DEVFEST 2017 세미나 후기

안녕하세요! 

오늘 DEVFEST 2017 세미나에 다녀왔습니다! 세미나 소개는 제가 설명드리는 것보다 링크의 본문을 보여드리는게 낮겠다 싶어

링크로 대체하겠습니다 :) https://devfest17-seoul.firebaseapp.com/

정말 많은 분들이 세미나를 듣기 위해 오셨는데 개발자열기(?)를 느낄수 있었습니다.

진행되었던 세미나의 세션 스케줄표입니다. 너무 유익한 내용들이 많았는데 몸은 한개인지라 

다 들어보지 못한게 너무 아쉬웠습니다.

저는 아래의 세션들을 참가하였습니다.

1. 이제서야 털어내는 안드로이드 Android Architecture Components(AAC)로 갑시다!

2. Fabric Branch로 사용자 가입경로 완벽 분석하기

3. UI Test 연동으로 배포 두려움 없애기 : CI, Espresso, Dagger2, Mockito, Firebase Test Lab

4. 좋은 코드를 고민하는 주니어 개발자들을 위한 안드로이드 디자인패턴

그럼 잡설은 그만하고 얼른 본문 이야기를 시작하겠습니다.

1. 이제서야 털어내는 안드로이드 Android Architecture Components(AAC)로 갑시다!

발표를 진행 해주신 정현지님

이번 세션은 Google I/O 2017에서 발표된 코드랩 자료를 다함께 모여서 일부 항목을 진행해보는 방식으로 진행 되었습니다.

아래의 코드를 다운받아 Android studio에서 빌드를 돌려보고 왜 AAC인지, 주어진 문제를 어떻게 문제를 풀어가는지,

하다가 모르는점은 무엇인지 다같이 코딩하며 중간중간 설명과 질의시간을 곁들여 주셨습니다.

Android Lifecycle-aware components codelab : goo.gl/vNT3TM

[정현지님 발표내용 중]

- 굉장히 긴 생명주기에 관련 내용들을 개발자가 알고써야 버그들을 피할 수 있는 상태였다.

- MVP, MVC, MVVM 패턴을 습득하여 사용해야 했다.

- 이렇게 학습이 필요한 디자인 패턴을 제외하고, 구글에서 안드로이드 프레임워크단의 생명주기에 대한 부재는 오래 지속되어왔다.

- 공식적으로 AAC를 제공하여 안드로이드 권장사항을 발표했다. ( 가이드도 있다. ) 

ACC를 사용하면?

- Activity의 생명주기들을 자동으로 관리가능.

참고사항

- 원래는 LifeCyclerActivity가 있었는데 AppCompatActivity에 26.1.0부터는 AppCompatActivity에 LifeCyclerActivity가 포함되어있어 디플리케이트 되었다.

ViewModel을 사용하면 어떤 이점이 있을까?

- 앱을 가로/세로 화면회전이 일어났을때 Activity 라이프사이클에 의해서 데이터가 유실되는 경우가 있는데,

ViewModel을 사용하면 앱을 종료하지 않는이상(Foreground 상태) 데이터가 유지된다.

아래의 예제를 따라해보며 기본 ViewModel, LiveData를 배워보자

예제링크

세션을 마치며 느낀점

- 라이플 사이클이 언제 어느 시점에서 동작될지 모르는 상황에서, (물론 알려면 알수 있지만) 

별로 걱정 없이 나는 OnCreate에서 이 함수를 실행시키겠다, 나는 onDestroy에서 이 함수를 실행하겠다라고 명시해줌으로써 라이프사이클의 복잡성에서 해방되는 느낌이었습니다. 또한 ViewModel의 경우 데이터의 유실없이 앱을 종료하지 않는이상 포그라운드 상태에서면 항상 데이터를 유지할수 있어서 생산성이 증가에 도움이 되겠다라는 생각을 하게되었습니다.

2. Fabric Branch로 사용자 가입경로 완벽 분석하기

발표를 진행 해주신 드라마앤컴퍼니 이승민님

Intro

마케팅 진행 시 캠페인을 통한 앱 설치 수는 알 수 있지만, 이후 가입까지 왔는지 또는 어디에서 이탈하였는지, 특정기능을 요구하는 초대링크를 통해서 들어왔다면 바로 원하는 행동을 하였는지 등을 트래킹하기 어렵다. 이런 정확한 마케팅 성과파악을 위해서는 원하는 시점에 코드를 발동하는 Deferred Deep Link를 구현하여야 한다.

Fabric에서는 Deferred Deep Link를 쉽게 구현할 수 있도록 Branch라는 라이브러리를 제공하고 있다. Branch를 통해 어떻게 사용자 가입경로를 분석하는지 알아보자.

Fabric Branch란 무엇인가?

- 웹/앱으로 들어와서 결제까지 진행되는 행동들을 분석할 수 있다.

- 개발 이야기이기도 하지만 마케팅이나 기획자 분들에게 도움이 많이 될것 같다.

- 퍼포먼스 마케팅에 사용할시 효과를 볼 수 있다.

퍼포먼스 마케팅이란?

 - 원하는 행동을 유도하는 마케팅

    > 사용자가 가입을 하게, 결제를 하기 하는 마케팅 

    > 행동을 잘 유도 하였는지 기준에 따른 측정이 중요하다.

ex ) 인스타에 몇시에 어떤 내용을 올렸더니 몇 프로가 유입되고, 이탈이 되었는지 행동에 따른 측정이 가능하다.

    => 어떤식으로 측정하는가, 추후에 어떻게 운영할 것인가에 대한 부분이 굉장이 중요하다.

하나의 상황을 들어보자

- 서비스에서 신규유저를 어떻게 유입하는가?

     - 마케팅 채널별로 

     ㄴ 페이스북으로 들어온 유저수

     ㄴ 인스타로 들어온 유저수

     ㄴ etc

그렇다면 어떻게 Fabric Branch를 쓸까?

- 마켓링크에 래퍼러를 붙인 스토어 링크를 전달한다.

참고로 Google Play Console에서 사용자 획득에 보면 어디서 유입된 유저인지 알수 있다.

(콘솔에서 알아서 파악해주니깐 여기까지는 우리가 할 것이 없다.)

따라서 마케팅의 성과를 어느정도는 보여줄수 있다.

하지만 단순 다운로드수가 의미는 있지만 결국 이 사람이 가입했는지, 결제를 했는지가 더 큰 의미가 있다.

그리고 광고를 이탈하는 원인이 무엇일까 찾는것이 핵심인데.Google Play Console에 이게 안된다.

아무것도 조치를 취하지 않으면 알수 없다. 

- 어디서 왔는지 알수 없다.

    ㄴ 앱을 진입하였을 때 유입 마케팅 채널을 구분하는 값이 없다. ( 레퍼러는 스토어 진입시에 측정되고 사라지는 값이기 때문)

그럼 이 문제를 어떻게 해결하는가?

- Deferred Deep Link를 사용하자

ex) 

[일반적인 사례]

티셔츠 50% 할인하는 페이지가 있다. > 사용자가 누름 > 앱이 설치되어있지 않으면 다운로드 > 앱을 실행시 첫 페이지가 뜬다.

[Deferred Depp Link를 사용시] 

티셔츠 50% 할인하는 페이지가 있다. > 사용자가 누름 > 앱이 설치되어있지 않으면 다운로드 > 앱을 실행시 티셔츠 할인 페이지로 이동시킨다.

이 딥링크를 직접 구현하면 엄청 힘들다. 다행이 Dynamic Link(Firebase), Fabric Branch를 사용해서 해결가능!

브랜치는 딥뷰라는 기능이 있다. 딥링크는 그 페이지로 이동이 끝인데, 딥뷰를 사용하면 그 사이 중간에 특정 페이지를 넣을수 있다.

(iOS때문에 이것을 선택했다.) 

ex) 페이지 fail일때 특정 페이지를 띄워준다.

만들어보자

- 대시보드에서 모든것을 다 할 수 있다.

- 단순히 페이지 링크만 넘기는게 아니라 커스텀한 값을 넘길 필요가 있다.

- 티셔츠 페이지를 가고 싶다면 티셔츠에대한 아이디값이 있을것. 

- 미리보기 (이미지)도 커스텀 할 수 있다. 미리보기도 어느정도 조정이 가능!

- 결론 : 사용자가 내가 만든 링크를 누르면 우리가 원하는 데이터를 수집할 수 있다.

광고하자

- 페이스북이나 인스타에 올렸다.

- 그럼 어떻게 원하는 정보를 얻을수 있을까?

방법

1. Branch 설치

2. Deferred Deep Link 값 받기

onNewIntent(인텐트로 값을 받는다), onStart(데이터들을 초기화 한다)

> sharedPreference에 저장해두고 값이 있으면 A처리 없으면 B처리

개발 핵심 Flow

링크생성 > 링크클릭 > 앱있음 > 앱시작 > Deep Link Paraneter 받기 > 로그인 및 가입 등 행동 이벤트 보내기

   앱없음 > 스토어 > 앱설치 > 앱시작 > Deep Link 파라미터 받기 > 로그인 및 가입 등 행동 이벤트 보내기

결론

- 데이터의 중요성을 이해하고 적절한 수단을 찾아 적용하려는 마음가짐이 중요하다.

질의응답

Q.1 안드로이드, iOS만 아니라 웹도 트래킹이 가능한가? 

> 예 가능합니다.

Q.2 iOS도 안드로이드와 같이 잘 동작하나요?

> iOS때문에 Deferred Deep Link를 선택했다. DeepView에 가보시면 앱이 없을때 그 DeepView로 가게된다. 그래서 그 DeepView의 페이지로 이동된다. DeepView 내에서 > Store로 보낼수 있다. 우리가 컨트롤 할 수 있는 웹페이지를 중간에 하나 더 넣을수 있기 때문에 iOS에서도 잘 동작한다. 실제로 드라마앤컴퍼니에서 사용중이다.

Q.3 해당 라이브러리 사용시 앱용량이 증가하나요?

> 전후 비교해봤을때 체감상 크지 않다.

3. UI Test 연동으로 배포 두려움 없애기

- 개발자는 효율적으로 게을러야 한다.

- CI, Espresso, Dagger2, Mockito, Firebase Test Lab

INDEX

1. 배포 프로세스 공유 및 개선

2. 안드로이드 테스팅 설계 및 시행 착오

3. 앞으로 개발방향

Unit Testing

- 안명 높은 안드로이드 단위 테스트

    - context 분리

    - 스파게티 코드 제거

- Fast and Unfragile

    - 로직의 근간 : 코드는 틀리지 않는다.

왜 이 세션은 후기가 이렇게 짧은가요?

- 자리가 없어서 맨 뒷자리에 앉았는데 화면이 잘 보이지 않았다.

- CI, Espresso, Dagger2, Mockito, Firebase Test Lab내용이 한번도 해보지 않은 것들이라 어려울 것이라 짐작은 했는데

   역시나.. 현재의 상태에서는 너무 이해가 힘들었다 ㅠㅠ 발표자 분께 죄송합니다.

- 그래도 모르는 부분이 왕창 생겨서 이해하기 위해서 더 열심히 해야겠다 라는 자극은 되었습니다 감사합니다.

4. 좋은 코드를 고민하는 주니어 개발자들을 위한 안드로이드 디자인 패턴

이제 그냥 동작하는 앱은 만들수 있는데 어떻게 하면 더 좋은 코드를 만들수 있을까?를 고민하는 분들이 들으시면 좋을것 같다.

왜 우리는 좋은 코드를 고민할까요?

- 좋지 않은 코드를 짜다보니 너무 고생을 많이 한다.

좋지 않은 코드를 짜면?

- 기획이 조금 바뀌었을 뿐인데 수정되야할 코드가 많다.

- 코드를 딱 한 줄만 수정 했는데 6개의 버그가 터진다.

- 관련된 코드들이 어디에 있는지 못 찾겠다.

- 예전과 비슷한 기능을 추가하는데 또다시 수백줄을 코딩해야한다.

=> 확장과 유지보수가 힘듬

=> 생산성 저하

=> 야근

좋은 코드를 짜려면?

- 우리랑 같은 고민을 했을 예전 개발자들의 뇌를 빌린다.

open source, design pattern(GoF 개발자들) 

디자인 패턴이란?

- 일반적으로 발생하는 문제를 재사용 가능한 코드로 짜서 내놓은 해결책

=> 빠르게 문제를 해결할 수 있음.

=> 생산성 증가

=> 칼퇴

- 문제 상황을 빠르게 판단하고 해결

- 코드 재사용을 통해 개발 속도 증가

- 개발자들끼리 공통의 해결 방법(구조) 공유

    - 다른 개발자들과 의사소통과 코드 파악에도 유리

Design pattern for Android

- 안드로이드에서는 어떤 문제가 반복될까?

상황1. 데이터가 변경될 때 여러 화면들을 업데이트 하고 싶다.

    ( Observer pattern = RxJava or 

      Command Parttern = EventBus & Otto )

Observer Pattern 

- 지정한 객체에 상태 변화가 있을 때 등록한 옵저버에게 알려주는것.

상황2. 생성자에게 넘겨야하는 파라미터가 너무 많아요!

class Developer(a,b,c,d,e,f....z){

...

}

- 가독성 저하

- 모든 파라미터를 한번에 넘겨줘야함

- 순서도 잘 지켜야함.

=> 빌더패턴으로 사용가능

복잡한 객체의 생성을 표현으로부터 분리시키는 것

> 가독성이 좋아지고, 각 파라미터마다 별도의 처리를 해주기도 좋다.

> 코드가 많기 때문에 단순한 객체에 사용하는건 피하는게 좋다.

상황 3 - 제공되어 있는 API를 그대로 사용할 수 없어요.

Adapter Pattern

- 이미 제공되어 있는 클래스의 인터페이스를 필요한 인터페이스로 변환하는것.

어떤것이 좋은가?

- 이미 검증된 클래스를 수정하여 사용하는 것보다 안정적이게 추가 기능을 구현할 수 있다.

상황 4 - 프로그램 내에서 새로 생성되지 않고 기존의 인스턴스가 리턴되는 클래스가 필요해요. Singleton

상황 5 - 모든 요소들에 동일한 처리를 해야해요 Iterator pattern ex) ArrayList

결론 

- 좋은 코드를 고민하는 개발자들에게 디자인 패턴은 하나의 방법이 될 수 있다.

DEVFEST 2017 세미나를 마치며 느낀점

- 아직 가야할 길이 많음 다시한번 느낌.

- 기초부터 차근차근 해보자라는 생각을 가지게 됨.

- MVP, MVVM, ACC를 공부하고 내것으로 만들자.

- 디자인 패턴은 알면 알수록 생산성에 기여한다.

- 건강한 코드를 만들기위한 노력을하자.

- 아직 늦지 않았으니 열심히하되, 스스로 정한 방향을 다시 한번 점검하자.

끝까지 읽어주셔서 고맙습니다!