Dev. Oratorium : For Mobile, By Mobile

Title: Android Jetpack: Understand the CameraX Camera-Support Library (Google I/O'19)

Speaker(s): Vinit Modi, James Fung, Franklin Wu, Trevor McGuire

1. 카메라 개발은 어렵습니다. 이유는?

- 앱에서 다양한 OS별로 신경써야함

- 저가형 entry부터 고가의 flagship까지 일관성이 있어야함

- 카메라 API의 복잡성

2. (testlab에서 테스트 다 하면서 개발했다는) CamaraX

 - 현 시장의 90%에 가까운 기기에서 호환됨

 - target SDK가 API 21 이상이면 사용 가능

 - Camera1 Api 및 Camera2 Legay Layer와 일관되게 제공됨.

 - 사용하기 쉬워짐

 - Lifecycle aware: Preview, Image Analysis, Caputre 기능 -> 각 개별 thread 필요 없어짐

 - 

3. 사용 예제

1) Preview

/*display preview on screen*/

//configure preview
val previewConfig = PreviewConfig.Builder().build()

//create preview
val preview = Preview(previewConfig)

preview.setOnPreviewOutputUpdateListener {
    PreviewOutput : Preview.PreviewOutput? ->
    // your code here. e.g. use previewOutput?.surfaceTexture
    // and post to a GL renderer.
}

//attach preview to lifecycle
CameraX.bindToLifecycle(this as LifecycleOwner, preview)

2) Image Analysis

//configure image analysis

//set resolution
val imageAnalysisConfig = ImageAnalysisConfig.Builder()
    .setTargetResolution(Size(1280, 720))
    .build()

//create image analysis
val imageAnalysis = ImageAnalysis(imageAnalysisConfig)

//attach output
imageAnalysis.setAnalyzer({ image : ImageProxy, rotationDegrees : Int ->
    val cropRect = image.cropRect
    //insert your code here
})

//attach image analysis & preview to lifecycle
CameraX.bindToLifecycle(this as LifecycleOwner, imageAnalysis, preview)

 3) Image Capture

/*configure image capture*/

//manage rotation
val imageCaptureConfig = ImageCaptureConfig.Builder()
    .setTargetRotation(windowManager.defaultDisplay.rotation)
    .build()

//create image capture
val imageCapture = ImageCapture(imageCaptureConfig)

//bind all use cases
CameraX.bindToLifecycle(this as LifecycleOwner, imageCapture, imageAnalysis, preview)

//on user action save a picture
fun onClick() {
    val file = File(...)
    imageCapture.takePicture(file,
        object : ImageCapture.OnImageSavedListener {
            override fun onError(error: ImageCapture.UserCaseError,
                                message: String, exc: Throwable?){
                // insert your code here 
            }
            override fun onImageSaved(file: File) {
                // insert your code here
            }
        })
}

Reference

https://www.youtube.com/watch?v=kuv8uK-5CLY

2019/09/02 - [Dev/Android] - [Android] 데이터 바인딩 개념 및 라이브러리 비교(Android Data Binding Library, Kotlin Android Extensions)

안드로이드 앱개발 시

데이터바인딩 설정하는건 정말 간단한데, 그것마저도 가끔씩 까먹어서 요약글 적어놓습니다.

1. build.gradle (app)

2. XML layout

3. Java

Reference

 안드로이드에서는 고전적으로 XML에 선언한 UI와 Java(혹은 Kotlin) 클래스를 연결하기 위해 'findViewById'를 사용했습니다. findViewById를 사용하게 되면 다음의 문제가 발생합니다.

 1) 하나의 View를 전역변수로 저장해서 사용해야함 

   -> 전역변수 선언, findViewById로 연결

 2) 만약 다른 xml에 존재하는 유사한 id를 입력하는 오탈자가 발생?

   -> 빌드 에러는 없는데 런타임 오류 발생

   -> 만약 초기화가 제대로 되지 않을까 걱정근심과 더불어, 객체 생성에 대한 null처리 추가

 이처럼 자연스럽게 발생되는 수 많은 보일러 플레이트 코드들... 아주 간단한 화면이라면 UI의 뷰 혹은 레이아웃이 5개 미만일 수 도 있겠지만, 고객의 요구사항에 따라 뷰의 복잡도가 늘어가는 경우가 다반사 입니다.

 이와 같은 문제를 해결하기 위해 등장한 개념이 바로 데이터바인딩인데요.

Data Binding(데이터 바인딩)은

애플리케이션 UI와 비즈니스 논리를 연결하는 프로세스를 뜻합니다.

 findViewById를 해소하기 위해 ButterKnife 라이브러리 등이 있었지만, 데이터 바인딩 개념을 보다 더 공고히 만든 라이브러리는 현재 대표적으로 2가지가 있습니다. 즉, 공식적으로 구글에서 만들어준 Android Data Binding Library와 Kotlin Android Extensions(약칭 KTX)입니다. 

 사실 저는 처음에 두가지가 같은 것인 줄 알았습니다. 요새 트렌드가 코틀린이고, 전 아직 내부 프로젝트 협의 여건상, 자유롭게 코틀린으로 갈아타지 못한 유저라서 더 혼동이 되었는데요. 저와 같은 초보자들을 위해 설명 드리자면, 둘 다 findViewById로 인한 문제를 간소화 한다는 점에서는 동일하지만, 사실 성질이 다릅니다.

두 라이브러리의 공통점

• findViewById로 처리했던 코드를 간소화하며, xml에 선언한 id를 자동으로 인식하여 클래스에서 사용 가능하다.

두 라이브러리의 차이점

• Android Data Binding Library는 자바와 코틀린 둘 다 사용이 가능한 '데이터 바인딩' 라이브러리입니다. XML에서 직접 레이아웃의 뷰 안에 어떤 클래스의 데이터를 셋팅할 것인지 <data> 태그를 통해 설정할 수 있습니다.
•  KTX는 당연하게도 코틀린 확장 라이브러리기 때문에 코틀린에서만 사용 가능한 기법입니다. 대신 코틀린과 KTX의 기법을 통해 (@parcelize annotation라던지) 보일러 코드가 없도록 만들 수 있습니다.

 이에 대해 구글에서는 Android Data Binding을 사용하기를 권고하는 것으로 여겨집니다. 이유는 코틀린에서만 사용이 가능하고, Nullability를 노출하지 않는 등이 있다고 합니다. 관련된 아티클은 다음 링크를 보시면 좋을 것 같습니다.

Reference

https://www.youtube.com/watch?v=u6koIr-EFi4

 몇년 사이에 신규로 프로젝트를 생성한다면, AppCompatActivity부터 마주하는 분들이 있을 것 같습니다. 그러나 저처럼 오래된 프로젝트 코드를 마주하면, Activity와 AppCompatActivity를 함께 발견할 수 있습니다.

AppCompatActivity는 안드로이드의 하위버전을 지원하는 Activity의 일종입니다.

  Activity에서 사용하는 메소드의 API Level을 확인하면, 메소드에 따라 안드로이드 운영체제의 버전이 다른 경우가 존재합니다. (이건 비단 Activity뿐만이 아니라 모든 컴포넌트들에 해당되는 이야기겠지요.) 

  Android 3.0(API level 11)부터, 기존 디폴트 테마를 사용하는 모든 Activitiy들은 app bar로 ActionBar를 가지고 있습니다. 그러나 app bar에는 다양한 안드로이드 버전이 릴리즈되면서 점진적으로 새로운 특징들이 추가 되었습니다. 그 결과, 네이티브 액션바는 기기가 지원할 수 있는 안드로이드 시스템의 버전에 따라 이를 다르게 의존하는 형태로 바뀌게 됩니다. 이와 대조적으로 최신 특징들은 툴바의 support library 버전에 추가 되면서, support lirary를 사용할 수 있는 어느 기기에서도 사용 가능하게 됩니다.

  물론 최신기능만이 탑재된 최신 OS 버전의 앱만 만든다면 상관없겠지만, 혹시라도 국내보다 구형기계를 많이 사용하는 지역, 즉 해외 수출용으로 모든 운영체제에 100% 지원이 되어야한다면? 타겟으로 하는 OS 이외에도 하위버전을 얼마나 커버하는 지를 확인 해야 합니다. 

  예전에는 경우에 따라 이 Support Library의 버전도 확인해야 했습니다. 그러나 이제는 Support Library가 아닌 AndroidX로 개별 개발자의 고생이 많이 덜어지도록 전환되었기 때문에, 이 부분만 알고 잘 연결한다면 Acitivty에 대한 문제는 거의 없지 않을까 싶네요.

  따라서 여러 하위버전을 매번 확인하기 번거롭고, 혹시나하여 안전하게 지원하고 싶다면, AppCompatActivity는 항상 옳은 선택입니다. 

 Activity를 AppCompatActivity로 전환하기 위해서는 

 1) extends에서 AppCompatActivity로 변경

 2) AndoridManifest.xml에서 해당 클래스를 아래처럼 변경

theme은 다음 설정을 내포하고 있습니다.

그렇다면, Acitivty는 deprecated된 것일까요? 아닙니다. Activity는 모든 종류의 Activity의 Base입니다. Acitvity의 상속을 받는 관계를 '부모<-자식'으로 표현했을 때 다음과 같습니다.

 물론 사실 이 Activity 또한 Context라는 super class로부터 시작합니다. 이에 대한 설명은 https://stackoverflow.com/questions/31297246/activity-appcompatactivity-fragmentactivity-and-actionbaractivity-when-to-us 에서 Farhana님의 답글이 명쾌했으므로, 이를 참고 하시면 좋을 것 같습니다. 아래는 해당 부분입니다.

Reference

Image Refernece