Dev. Oratorium : For Mobile, By Mobile

1. MyBatis는?

- 기존 JDBC코드는 Connection과 Statement를 통해 쿼리를 전송하면 연결받고 Close하는 방식을 사용.

 ==> 이를 프레임워크화를 하여 캡슐화를 한것이 mybatis. 

- JDBC 코드를 간편하게 사용할 수 있고 SQL문장과 프로그래밍 코드가 분리되어 있어 사용하는데 있어 편리

- 또한 라이브러리를 통해 매개변수를 전달하고 결과를 추출하는 일이 간단히 처리가능 

2. iBATIS -> MyBatis : 이름 변경의 이유?

Apache Proejct팀이 iBATIS를 ~2.3까지 개발 하였음.

이후 해당 팀이 google code 팀으로 이동하면서, 이름을 MyBatis로 변경하여 2.5부터 개발 진행중.

3. 차이점

1) Java 요구사항 차이점

iBATIS : JDK 1.4 이상 가능
MyBatis : JDK 1.5 이상 가능(MyBatis 3.2 이상 버전은 JDK 1.6 이상 요구)

2) 패키지 내부 구조 변경

iBATIS : com.ibatis.*

MyBatis : org.apache.ibatis.*

3) sqlMap.xml 내부구조 변경

iBATIS: parameterMap

MyBatis: parameterType (dtd 변경 - http://mybatis.org/dtd/mybatis-3-mapper.dtd) 

4) pom.xml 설정

<!-- iBATIS pom.xml -->
<dependency>
    <groupid>org.apache.ibatis</groupid>
   <artifactid>ibatis-sqlmap</artifactid>
   <version>2.3.4.726</version>
</dependency>

<!-- MyBatis pom.xml -->
<dependency>
    <groupid>org.mybatis</groupid>
   <artifactid>mybatis</artifactid>
   <version>3.4.5</version>
</dependency>
 
<dependency>
   <groupid>org.mybatis</groupid>
   <artifactid>mybatis-spring</artifactid>
    <version>1.3.1</version>
</dependency>

(상위버전이 필요하다면 maven repository에서 확인)

5) 네임스페이스 방식 변경

iBATIS : <sqlMap namespace=”User”>

MyBatis : <mapper namespace=”myBatis.mapper.UserMapper”>

네임스페이스 사용은 필수, userStatementNameSpace설정 제거

Reference

https://sdevstudy.tistory.com/18

https://uwostudy.tistory.com/19

https://hunit.tistory.com/200

Title: Build a Modular Android App Architecture

Speaker(s): Yigit Boyar, Florina Muntenescu

1. 어떻게 모듈화된 안드로이드 앱 아키텍쳐를 구축할 것인가?

1) 왜 우리는 이를 구축해야하는가?

  (1) Scale 문제

      - 한두명이 아닌, 여러명이 공통 개발을 할 때, 각자의 담당하는 바를 간섭하지 않고 개발하기란(without stepping on each other's toes) 어렵다. 그래서 이를 방지하고자 이런 모듈들로 나눠서 만들 수 밖에 없다는 의미.

  (2) maintainability 유지보수성

      - 만약 monolithic application, 즉 하나의 거대한 아키텍쳐를 가진 앱을 마주하게 된다면? 안드로이드 개발자가 수십 수백개의 레이어들을 마주하게 되고 이를 파악하고 분석하는 것은 매우 어려운 일이다. 대신에, 만약 이 레이아웃들을 각 특징(feature)에 기반하여 그룹화 한다면, 용도의 파악이 용이진다. 또한 굉장히 길고 이상한 이름(weird name)으로 목록이 생기지 않는다. 

  (3) Faster compilation 빠른 컴파일

      - 왼쪽은 monolithic application의 예, 오른쪽은 modulaized application된 예다. 만약 '(designer_news_)comment.xml'라는 파일을 1개 수정했다고 가정 했을때, 컴파일시 커버 범위는 다음과 같다.

  (4) Faster CI(Continuous Integration) 빠른 지속적 통합

      - 만약 다음과 같은 모듈 구조를 가진 앱이 있다고 가정하자.

      - 이 중에서 module5를 수정 한다고 했을때, 변화가 올바른지 확인하기 위해서 테스트를 해야하는 부분은 오로지, module5가 depend 하고 있는 app부분만 확인하면 된다. 따라서 테스트를 할 때, 연관되지 않은 다른 부분들을 실행할 필요가 없다. 

      - 이에 대해서 '우리는 incremental CI이 없다!'라고 말할 수 있다. 그래서 AndroidX 개발에서 의존성 그래프에 대한 플러그인, 파일들이 변화된 위치와 해당 파일들이 포함된 모듈이 무엇인지에 대한 Git History를 알 수 있도록 하는 플러그인들을 작성했다. 그리고 영향받은 모듈들에 대한 모든 테스트를 실행하였다. 해당 작업에 대한 링크는 다음과 같다. http://goo.gle/androidx-dependency-tracker 

  (5) Good for business

      - APK 사이즈가 작아지는 장점이 있다. Play store의 통계에 따르면, APK 사이즈에 따라 사람들이 설치를 시작하고 중단하는 비율이 다음과 같다. 즉 앱의 사이즈가 작으면 보다 많은 이용자를 끌어들일 수 있다.

      - 또한 PM이 "내가 정말 멋진 라이브러리를 찾아가지고 왔어!"라고 아이디어를 들고 와도, 이것이 좋은지 안좋은지 싸울 필요가 없다. 다이나믹하게 개발하고 A/B 테스트를 진행하면 됨.

2) 그렇다면 어떻게 모듈화 할 것인가? feature or layer?

  (1) feature modularization

     + 참고: https://developer.android.com/studio/projects/android-library?hl=ko

      - 앱 모듈을 라이브러리 모듈로 변환할 때, 기존 앱 모듈의 build.gradle 파일을 열면 맨 위에 다음과 같이 표시 되어 있다.

apply plugin: 'com.android.application'

      - 이를 다음처럼 플러그인 할당을 변경하고 sync를 맞춘다.

apply plugin: 'com.android.library'

      - 모듈의 전체 구조는 동일하게 유지되지만, 이제 Android 라이브러리로 작동하며 빌드에서 이제 APK 대신 AAR 파일이 생성됩니다.

  (2) feature modularization

+ 내가 해석을 해놓고도 개떡같아서 무슨 말인가 싶어서 차이점에 대해 찾아보았다.

   https://tjandroid.blogspot.com/2018/11/api-implementation.html 블로그에 따르면, 

- 해석중

Reference

https://www.youtube.com/watch?v=PZBg5DIzNww

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

 안드로이드에서는 고전적으로 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