[컨퍼런스] Android Dev Summit 2019 EXTENDED SEOUL 참석후기

2019.12.21

컨퍼런스를 다니며 기억보단 기록을 하고자 합니다

 

---

 

안녕하세요 이번에는 구글의 연중행사인 Android Dev Summit 2019를 리캡 하는 형태로 진행되는 Android Dev Summit 2019 Extended Seoul에 참석하였습니다.

2019. 12. 21 (토) Android Dev Summit 2019 Extended Seoul  

 

 

다른 행사 참여로 몇번 가본 적 있는 구글 스타트업 캠퍼스입니다.(입구와 기업부스는 사진을 찍지 못했습니다 ㅠ)

이날 부스는 뱅크샐러드와 핀다에서 운영하며 사은품을 나누어 주었습니다.(사은품은 제일 아래에!!)

저는 2번째 라인에 앉아서 발표를 들었습니다.

그럼 이제 어떠한 주제로 발표가 진행되었는지 하나씩 알아보겠습니다.

(발표에서 나온 코드들은 이번 포스팅에서는 많이 다루지 않았으며, 직접 공부하며 추가 포스팅을 통해서 코드를 소개하겠습니다.)

● Android Security 라이브러리 살펴보기! - 권태환

 1. Android Security Library 소개

  - minSdk : 23

  - Last Version : alpha2 (May 23, 2019) : (Google Dev Summit이후에도 아직 업데이트되지 않았습니다....)

  - 제공하는 것들 : EncriptedFile, EncriptedSharedPreferences

  - KeyAlias 생성: Android KeyStore를 이용한 Masterkeys generator

 

 2. Android Security Library 사용법

minSdk가 23보다 낮으면 빌드 자체가 되지 않는다.

dependencies { 
	implementation "androidx.security:security-crypto:1.0.0-alpha02"
}

EncryptedSharedPreference                                                                                                      EncryptedFile

 3. Android Security Library 주의사항

  - KeyAlias : masterKeyAlias는 String 변수여서 변경이 가능하다. 그리고 동작에 문제가 없다. 하지만 MasterKeys를 사용하는 것을 권장한다.

  - EncryptedFile : File openFileOutPut사용 시 주의해야 한다. 이미 생성된 동일한 파일이 있으면 Exception 발생

       해결방법 - 기존 파일 제거(데이터 손실주의), 기존 파일을 읽어 새로 저장

 

아직 사용해보지는 않았지만 사용하면서 해당 라이브러리가 설치 수준의 keyAlias를 제공하는지 디바이스수준의 keyAlias를 제공하는지 생각해보면 좋을 것 같습니다.(아마 설치수준의 keyAlias를 제공하지 않을까 예상됩니다). 보다 자세한 내용은 여기에서 확인하실 수 있습니다.

 

● New Android Studio - 노현석

Android Studio 4.0에서의 변경사항들을 발표해주셨습니다.

 

 - build.gradle

build.gradl(~v3.6)                                                                                                     build.gradle(v4.0)

 build버전을 직접 버전을 명시하지 않고 variant로 정의하여 사용할 때에는 v3.6 이전에서는 신규 버전에 대한 하이라이팅을 해주지 않았습니다. 하지만 Android Studio 4.0부터 위와 같은 방식으로 버전을 정의하여도 신규 버전에 대해서 하이라이팅 하여 표시를 해주게 됩니다.

 

 - build speed

 Build 분석 시 Build task의 Critical path를 기준으로 speed를 분석할 수 있습니다.

 

 - Multi Preview

언어별 레이아웃                                                                                                       디바이스별 레이아웃

레이아웃을 동시에 볼 수 있는 디자인 도구를 지원합니다.

 

 - Desugaring

Android Studio 3.0 이상에서는 D8에서 Desugaring을 통해 Java8 언어 기능을 지원하고 있습니다. 하지만 Java8의 일부 API는 최소 버전의 제약은 존재합니다. 이러한 문제점을 Androud Studio 4.0에서 build.gradle에 아래의 Flag를 추가함으로써 최소버전의 제약 없이 Java8 API를 사용할 수 있습니다.

android {
	complieOptions { 
    	// 새로운 Language API를 지원하기위한 Flag
    	coreLibraryDesugaringEnabled true
    }
}

 

 - JetPack Compose

핫한 JetPack Compose입니다.

이렇게 핫하지만 아직 pre alpha 단계입니다. 언제든지 변경될 가능성이 있으며, 아직 실무에 적용하기에는 무리가 있어 보입니다.

그래도 계속해서 구글에서도 핫한 주제로 다뤄지고 있는 만큼 계속해서 주시할 필요는 있을 것 같습니다.

 

 - Debugging

 디버깅 중 Break Point를 지나치거나 추가 코드를 넣고 싶을 때가 있습니다. 이럴 때 Android Studio 4.0

 에서는 Apply Changes기능을 지원합니다. 

 

좀더 자세한 내용은 여기에서 확인 하실수 있습니다.

● Developing Themes with Style - 안명욱

실무에서도 놓칠 수 있는 Themes와 Style에 대해서 발표해주셨습니다.

 

Style & Theme

스타일은 속성의 집합이며, 특정 뷰에만 사용되며 다른 뷰에는 사용되지 않습니다. 반면에 테마는 스타일의 한 종류로 특정 뷰 유형뿐만 아니라 전체 앱이나 활동이나 뷰에서 사용될 수 있습니다.

 

프로젝트 적용 방식에 따라 스타일과 테마의 차이가 있습니다. 뷰에 스타일을 적용하면 뷰는 해당 뷰에만 적용되고 뷰의 하위 뷰에는 적용되지 않습니다. 그러나 테마를 적용한다면, 모든 Child View에도 적용됩니다.

 

Color

Android에서는 색상값을 ARGB or RGB형태로 표현할 수 있습니다.

 

Rule

  - Use literal names for resources

 색상명을 지정할 때는 색상의 이름을 색상명을 그대로 사용하는 것이 좋다고 합니다.

 

  - Use consistent style names

직접 정의한 스타일에서 상속하려는 경우에는 parent 특성을 사용할 필요가 없습니다. 대신, 상속하려는 스타일의 이름을 마침표로 구분하여 새 스타일의 이름 앞에 붙이기만 하면 됩니다. 예를 들어, 위에서 정의한 AppTheme스타일을 상속하는 새 스타일을 생성하되, 색상을 파란색으로 만들려면 다음과 같이 새 스타일을 작성하면 됩니다.

 

  - Layer your themes for re-use

 버전이나 테마 색상에 따라 다른 style을 적용해야 할 경우 xml만 나누어 작성하게 되면 각각의 xml에 많은 코드들이 들어가게 됩니다. 이를 재사용 가능하도록 style에도 상속을 통한 재사용성을 높일 수 있습니다.

 

베이스에 공통된 정보를 두고 특정 테마에 적용할 코드들을 작성해줄 수 있습니다.

 

- Split files based on purpose

기존에 구분되어있는 xml 파일들에 모두 작성하게 되면 파일이 엄청나게 커지고 해당 속성들을 찾기 힘들어진다고 합니다. 그래서 몇 가지 방법을 제안하고 있습니다.

 

https://blog.mindorks.com/build-material-and-dark-themes-apps-using-style-in-android

● LiveData with Coroutines and Flow - 이우춘

아직 Coroutines에 대한 이해가 깊지 않아서 좀 더 공부 후에 포스팅하도록 하겠습니다.

● WorkManager: the Beginning - 안성용

 Before WorkManager

- WorkManager = AlarmManager + JobScheduler (+GCM)

- WorkManager는 force-stop이 되더라도 앱을 재실행하면 작업을 다시 예약합니다.

- WorkManager 2.3에서는 Worker에 Progress, Foreground 기능을 제공합니다.

- WorkManager는 최소 15분 이상 간격으로만 반복 작업이 가능하고, AlarmManager처럼 정확한 시간에 동작을 보장하는 기능이 아니란 점을 주의하여 사용하셔야 합니다.

 

아직 WorkManager를 사용해본 적은 없지만 나중에 사용할 때 참고할만한 아주 좋은 발표였습니다.

보다 자세한 내용은 여기에서 확인하실 수 있습니다.

● 안드로이드 DI 어떻게 하나요? (Feat. Dagger2) - 이승민

  1. DI는 무엇인가요?

  - Dependency Injection (의존성 주입)

  - A class가 B class를 필요로 할 때 외부에서 생성된 B class 객체를 전달받는다면 의존성 주입이다.

 

  2. DI툴은 무엇이 좋나요?

  - Manual DI : 개발자가 직접 객체 생성(activity/fragment에서 생성)

  - Koin : Serveice Locator ( RunTime Type Check )

  - Dagger : Generated Code ( CompileTime Type Check )

 

구글의 선택

  3. Dagger 간단 사용법

  - Module : 의존성 생성 class

  - Bind / Provide : 의존성 생성 method  

  - Component : Module 실행

  

Dagger에는 몇 가지 가이드라인들이 존재합니다. 대표적으로 2가지가 있습니다.

-Android Injector 따르기

-Google Guide 따르기

발표에서는 Android Injector를 사용하기를 권하고 있습니다. 이유는 아직은 Android Injector가 안드로이드 구조에 편하며, SubComponent관리가 편하기 때문이라고 합니다.

 

이렇게 가이드나 사용방법이 여러 가지인 이유는 Dagger는 Android를 위한 DI가 아니라 Java를 위한 DI였기 때문에 Dagger를 안드로이드에 맞춰 사용하기 위한 방법이 다양해진 탓인 것 같습니다.

 

Dagger에 대한 추가적인 내용들은 나중에 공부해서 따로 더 자세히 올려보도록 하겠습니다.

 

  4. Improving Dagger

 - Dagger support in Kotlin

 - Simple Dagger in Android

 - Testing Utility

 

개인적으로 Koin은 개인 앱을 만들면서 사용하고 있고, Dagger와의 차이를 알고 있었습니다. Dagger의 학습곡선을 고민하며 저는 프로젝트에 Koin을 도입하였고, 사용하다 보니 발표 내용에서 나왔듯이 런타임에서 생기는 Crash들에 대해서 생각하던 중 좋은 발표를 듣게 되어 Dagger에 대해서 한번 고민해보는 계기가 된 것 같습니다.

● 마치며

이번 행사에서는 핀다와 뱅크 샐러드에서 채용과 관련한 부스를 운영하며 다양한 굿즈와 스티커를 제공해주었습니다.(뱅크샐러드는 담요!) 그리고 마지막에 뱅크샐러드에서 부스에서 설문에 참여한 인원을 대상으로 스타벅스 5만 원 쿠폰을 추첨 이벤트를 진행했는데요. 역시 저는 아닙니다.....ㅋ 언제쯤 이런 추첨에 당첨이 될까요?? ㅋㅋ

이번 행사도 유익하고 새로운 정보들을 얻을 수 있었습니다.

올 한 해도 거의 얼마 남지 않았군요. 미리 메리 크리스마스.!! 새해 복 많이 받으세요!!

끝까지 읽어 주셔서 감사합니다.😁

 

 

감사합니다.

❤️

Love YourSelf