순수 함수

• 같은 인자에 대하여 항상 같은 값을 반환한다.

• 함수 외부의 어떤 상태도 바꾸지 않는다.

fun sum(a : Int, b : Int) : Int{
    return a + b
}

위 함수는 동일한 인자 a, b에 대해서는 항상 같은 값을 반환하며 함수 외부의 어떤 상태도 바꾸지 않기 때문에 순수 함수이다.

프로젝트가 커지다보면 부작용을 완벽하게 통제할 수 있는 순수 함수를 만들기는 어렵다. 그래서 평소에 가능한 한 순수 함수에 가깝게 안전한 함수를 구현하려고 노력하는 것이 중요하다.

일급 객체

• 일급 객체는 함수의 인자로 전달할 수 있다.

• 일급 객체는 함수의 반환값에 사용할 수 있다.
• 일급 객체는 변수에 담을 수 있다.

함수형 프로그래밍에서는 함수를 일급 객체로 생각한다. 뒤에 나올 람다식 역시 일급 객체의 특징을 가지고 있다.

만약 함수가 일급 객체면 일급 함수라고 부른다. 그리고 일급 함수에 이름이 없는 경우 '람다식 함수' 혹은 '람다식'이라고 부를 수 있다. 즉, 람다식은 일급 객체의 특징을 가진 이름 없는 함수이다.

람다식

{ x, y -> x + y }

위의 식은 람다식의 예이다. 함수의 이름이 없고 화살표(->)가 사용되었다. 이 두가지가 람다식임을 알 수 있게 하는 특징이다.
위에서 일급 객체에 대해 말할 때 람다식에 대해 언급했다. 이름이 없는 일급 함수 == 람다식 위 함수는 보다시피 이름이 없다!

함수형 프로그래밍의 람다식은 다음과 같다.

• 다른 함수의 인자로 넘기는 함수
• 함수의 결괏값으로 반환하는 함수
• 변수에 저장하는 함수

그러나 아직 위의 예시로는 다른 함수의 인자, 결과값이 되는지 알 수 없고 변수에 저장되는지도 알 수 없으니 고차함수를 보면서 천천히 이해해보도록 하자.

고차 함수

• 다른 함수를 인자로 사용하는 함수
• 다른 함수를 결괏값으로 반환하는 함수

fun main(){
    println(highFunc({ x, y -> x + y}, 10, 20)
}

fun highFunc(sum: (Int, Int) -> Int, a : Int, b : Int) : Int = sum(a, b)

위 예시를 보면 highFunc()함수는 sum이라는 매개변수가 있다. 그리고 이 sum의 자료형은 람다식 형태이다. 즉, highFunc()함수는 sum이라는 변수에 람다식을 저장하여 람다식 함수를 인자로 받아들일 수 있는 고차 함수인 것이다.

이제 람다식에 대해서도 조금 더 감이 올 것이다.

함수형 프로그램의 정의와 특징

• 순수 함수를 사용해야 한다.
• 람다식을 사용할 수 있다.
• 고차 함수를 사용할 수 있다.

Your first coroutine

코루틴은 정지할 수 있는 계산의 인스턴스입니다.

코루틴은 한 블록의 코드를 나머지 코드들과 동시에(병행적으로, concurrently) 실행된다는 측면에서 개념적으로 스레드와 비슷합니다 .

하지만 코루틴은 어떤 특정 스레드에도 묶여있지 않습니다. 코루틴은 한 스레드에서 실행을 일시 중단(지연)하고 다른 스레드를 다시 실행합니다.

코루틴은 가벼운 스레드라고 생각될 수 있지만, 실제 사용할 때 매우 다름을 만드는 여러 중요한 차이점들이 있습니다.

아래 코드를 살펴봅시다.

fun main() = runBlocking { // this: CoroutineScope
    launch { // launch a new coroutine and continue
        delay(1000L) // non-blocking delay for 1 second (default time unit is ms)
        println("World!") // print after delay
    }
    println("Hello") // main coroutine continues while a previous one is delayed
}

위 코드를 실행시키면 아래와 같은 결과가 나옵니다.

Hello
World!

이 코드가 어떻게 실행됐는지 살펴봅시다.

launch는 코루틴 빌더입니다. 이는 새로운 코루틴을 나머지 코드들과 동시에(병행적으로, concurrently) 시작하며 독립적으로 계속 작동합니다. 이것이 Hello가 먼저 출력된 이유입니다.

delay는 특별한 지연(suspending) 함수입니다. 이는 코루틴을 특정 시간동안 지연(중단, suspend)시킵니다. 코루틴을 일시 중단(suspend) 시키는 것은 기존(사용하던) 스레드를 막지(block) 않고 다른 코루틴이 그들의 코드를 위해 기존 스레드를 실행하고 사용할 수 있습니다.

runBlocking도 일반적인 메인 함수의 코루틴이 아닌 구역과 runBlocking중괄호 내부의 코루틴 코드들을 이어주는 코루틴 빌더입니다. 이것은 IDE에서 runBlocking을 시작하는 중괄호 바로 다음에 this:CoroutineScope힌트로 강조 표현된다.

만약 당신이 이 코드에서 runBlocking을 지우거나 깜빡한다면 launch를 호출할 때 다음과 같은 에러가 날 것입니다. launch는 CoroutineScope 안에서만 선언될 수 있기 때문입니다.

Unresolved reference: launch

runBlocking의 이름은 runBlocking 내부의 모든 코루틴의 실행이 완료될 때까지 이를 실행하는 스레드(이 경우엔 메인 스레드)가 호출 기간 동안 차단됨을 의미합니다. 애플리케이션의 최상위 수준에서는 이와 같이 사용되는 runBlocking을 종종 볼 수 있지만 실제 코드 내부(아마도 low level의 코드에서?를 의미하는듯 하다)에서는 거의 볼 수 없습니다. 스레드는 (코스트가) 비싼 리소스이며 스레드를 차단(block)하는 것은 비효율적이고 바람직하지 않기 때문입니다.

Structured concurrency (구조화된 동시성)

코루틴은 structured concurrency(구조화된 동시성)의 원칙을 따르는데, 이는 코루틴의 생명주기를 지정하는 특정한 CoroutineScope에서만 새로운 코루틴을 시작할 수 있다는 것을 의미한다. 위의 예제는 runBlocking이 해당 스코프(범위?)를 설정한다는 것을 보여주며, 이것이 이전 예제에서 1초의 딜레이 후, 'World!'가 출력될 때까지 기다린 다음에서야 종료되는 이유입니다.

실제 앱에서, 당신은 많은 코루틴을 실행할 것 입니다. structured concurrency(구조화된 동시성)은 그것들이 분실되고 누출되지 않도록 보장합니다. 모든 자식(하위) 코루틴들이 완료될 때까지 외부 스코프는 완료할 수 없습니다. 또한 structured concurrency(구조화된 동시성)은 코드의 모든 오류를 적절하게 알려주고 손실되지 않도록 보장합니다.

Extract function refactoring

continue.. 계속 번역하면서 업데이트 할게유

원본 출처

얼마 전, 함께 프로젝트를 하는 디자이너가 내 휴대폰 화면 사이즈를 물어보았다. 이전에 화면의 가로 사이즈 구하는 코드를 사용해본 적이 있었기 때문에 후딱 로그 찍어서 알려주었다. 그리고 디자이너에게 질문이 하나 왔는데..

이거 세로 사이즈 상태 바랑 네비게이션 바 포함된건가요?

어..? 뇌절이 왔다. 생각해보니 이전에는 가로 사이즈만 사용해봐서 측정된 세로 사이즈가 정확히 어디부터 어디까지인지 몰랐다. 그리고 이 과정에서 알게 된 안드로이드의 화면 크기 구하는 방법이다.

일반적인 안드로이드 화면 크기 구하는 방법

val display = this.applicationContext?.resources?.displayMetrics
val deviceWidth = display?.widthPixels
val deviceHeight = display?.heightPixels

자 deviceWidth와 deviceHeight를 Log 찍어보자 아, 그전에 저렇게 구하면 픽셀 값이 나오니 mdpi 기준 dp값으로 바꾸는 코드를 알아보자.

fun px2dp(px: Int, context: Context) = px / ((context.resources.displayMetrics.densityDpi.toFloat()) / DisplayMetrics.DENSITY_DEFAULT)

아래 코드와 같은 의미이다.

fun px2dp(px: Int, context: Context): Float {
    return px / ((context.resources.displayMetrics.densityDpi.toFloat()) / DisplayMetrics.DENSITY_DEFAULT)
}

위에서 구한 deviceWidth와 deviceHeight를 px2dp 함수의 px 매개변수로 넘겨준다.

Log.d("deviceSize", "${px2dp(deviceWidth!!, this)}")
Log.d("deviceSize", "${px2dp(deviceHeight!!, this)}")

내 휴대폰의 경우 갤럭시S21+이고

px2dp를 적용하기 전 픽셀 값 width : 1080, height : 2181

px2dp함수를 적용한 dp값 width : 360, height : 727

갤럭시S21+의 공식 픽셀 값 width: 1080, height: 2400

어라? 뭔가 이상하지 않은가? 가로는 맞는 것 같은데.. 세로는 내가 측정한 픽셀 값과 공식 픽셀 값이 맞지 않는다. dp값 또한 애매하게 727이다. 적어도 10의 자리로 떨어지게 만들었을 것 같은데 말이다. 여기서 생각해볼 수 있는 것은 상태 바(status bar)와 네비게이션 바(navigation bar)이다.

상태 바, 네비게이션 바

상태 바(status bar)란 휴대폰의 맨 위에 시간, 알림, 블루투스, 와이파이 배터리 등의 정보를 보여주는 영역이다. (아래 사진과 같은~)

네비게이션 바(navigation bar)란 아이폰에는 없지만 안드로이드 기기에 있는 최근 사용 앱, 홈, 뒤로가기 버튼이 있는 최하단 영역이다.

최근에는 갤럭시에서도 스와이프 제스쳐를 지원하면서 네비게이션 바를 없애고 제스쳐를 이용할 수 있다. (점점 사용하는 사람들도 늘어나고 있다.)

상태 바(status bar) 크기 구하기

다시 화면의 크기를 찾는 내용으로 돌아와보자. 그럼 2400-2181=219는 어디로간걸까

일단 단위가 커서 계산하기 귀찮으니 dp값으로 변환해서 생각하자 2400을 px2dp함수에 넣어 계산하면 800이 나온다.

그럼? 이제 800-727=73이 어디로 갔는지 찾으면 된다.

근데 여기서의 문제는 73에 상태 바와 네비게이션 바가 모두 포함된 것인지 하나만 포함된 것인지를 모르겠다는 것이었다.

그래서 구글링한 결과 상태 바를 구하는 코드는 아래와 같다.

    fun getStatusBarHeight(context: Context){
        var statusbarHeight = 0
        val resourceId: Int = context.resources.getIdentifier("status_bar_height", "dimen", "android")
        if (resourceId > 0) {
            statusbarHeight = resources.getDimensionPixelSize(resourceId)
            Log.d("deviceSize", "status bar : ${px2dp(statusbarHeight, context)}")
        }
    }

이러면 로그에 상태 바의 세로 dp값이 나올 것이다.

내 휴대폰은(갤럭시S21+) 25가 나왔다.

그럼 727 + 25 < 800 로 아직 부족하다. 여기서 부족한 부분은 네비게이션 바로 추측해볼 수 있다. 그럼 이제 네비게이션 바의 크기를 측정해보자!

네비게이션 바(navigation bar) 크기 구하기

네비게이션 바의 세로 길이를 구하는 코드는 아래와 같다.

    fun getnavigationBarHeight(context: Context){
        val resourceId = resources.getIdentifier("navigation_bar_height", "dimen", "android")
        var navigationbarHeight = 0
        if (resourceId > 0) {
            navigationbarHeight = resources.getDimensionPixelSize(resourceId)
            Log.d("deviceSize", "navigation bar : ${px2dp(navigationbarHeight, context)}")
        }
    }

상태 바 구하는 코드와 거의 유사하다

내 휴대폰의(갤럭시S21+) 네비게이션 바 세로 dp값은 48이 나왔다.

결론

727 + 25 + 48 = 800 이제 드디어 숫자가 딱 맞았다.

상태 바와 네비게이션 바를 제외한 실직적인 앱 화면 크기는 727 상태 바와 네비게이션 바를 합친 디바이스의 화면 크기는 800이다.

혹시 그럼 스와이프 제스쳐를 쓰면 어떻게 되죠?

추가로 궁금해서 네비게이션 바를 스와이프 제스쳐로 바꾸고 다시 측정해보았다. 그럼 스와이프 제스쳐의 경우 하단 영역의 길이가 15로 나온다.

스와이프 제스쳐가 차지하는 하단 영역이 없는 줄 알았지만 측정하고 자세히보니 정말 얇은 영역이 있었다.

760 + 25 + 15 = 800으로 네비게이션 바를 사용할 때보다 꽤 많은 영역이 늘어난다는 것을 알 수 있다.

주의해야할 점

방금의 결론에서 우리가 맨 처음 구했던 deviceHeight는 디바이스 크기 - 상태바 - 네비게이션바였다.

하지만 다른 상황이 있다. 위 경우는 상태 바에 전면 카메라가 포함되어있는 경우이다.

하지만 상태 바에 전면 카메라가 포함되어있지 않은 경우에는 deviceHeight에 상태바(status bar)가 포함되지 않는다.

즉 디바이스 크기 - 네비게이션바라고 생각하면 된다.

내 휴대폰(갤럭시S21+)은 펀치홀 형식의 전면 카메라를 가지고 있어 카메라가 상태바에 포함된다.

그러나 내가 안드로이드 스튜디오에서 사용하고 있는 에뮬레이터의 경우 전면 카메라가 없으므로 상태바에 전면 카메라가 포함되어있지 않다.

해당 에뮬레이터로 크기를 측정해본 결과는 아래와 같다. 디바이스 크기 : 760 deviceHeight : 712 상태바(status bar) : 24 네비게이션 바(navigation bar) : 48

보다시피 760 - 712 = 48로 네비게이션 바의 크기만큼을 제외한 수치이다.

다만 전면 카메라가 상태 바에 포함됐을 경우라는 조건은 100% 확실하다고 말하기는 어렵다. 내가 확신하는 나의 추측일뿐이다.

출처

상태바, 네비게이션 바 구하는 방법 네비게이션 바 크기 관련 갤럭시S21+ 공식 크기

lateinit var binding : ActivityMainBinding
override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)

이제는 제대로 알고 쓰고 싶어서 한 번 찾아보았다.

모듈에 뷰 바인딩을 사용하도록 설정되면 모듈에 포함된 각 XML 레이아웃 파일의 바인딩 클래스가 생성된다. 각 바인딩 클래스에는 루트 뷰 및 ID가 있는 모든 뷰의 참조가 포함된다.(그래서 id가 없으면 참조되지 않는다)

또한 모든 바인딩 클래스에는 상응하는 레이아웃 파일의 루트 뷰에 관한 직접 참조를 제공하는 getRoot() 메서드가 포함된다. 아래 예에선 ActivityMainBinding클래스의 getRoot() 메서드가 ConstraintLayout 루트 뷰를 반환한다.

<MainActivity의 xml파일>

<androidx.constraintlayout ... >
         <TextView android:id="@+id/tv_login_id" ... />
        <EditText android:id="@+id/et_login_id" ... />
        <ImageView android:id="@+id/iv_logo" ... />
        <Button android:id="@+id/btn_login" ... />
</androidx.constraintlayout.widget.ConstraintLayout>

액티비티에서 뷰 바인딩 사용

액티비티에 사용할 바인딩 클래스 인스턴스를 설정하려면 액티비티의 onCreate() 메서드에서 다음 단계를 따른다.

1. 생성된 바인딩 클래스에 포함된 정적 inflate() 메서드를 호출하면 액티비티에서 사용할 바인딩 클래스 인스턴스가 생성된다.

2. getRoot() 메서드를 호출하거나 Kotlin 속성 구문을 사용하여 루트 뷰 참조를 가져온다.

3. 루트 뷰를 setContentView()에 전달하여 화면상의 활성 뷰로 만든다.

    private lateinit var binding: ActivityMainBinding
   
    override fun onCreate(savedInstanceState: Bundle) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)
    }

   뷰 모델을 사용할 때

   binding.tvLoginId.text = viewModel.loginId
   binding.button.setOnClickListener { viewModel.loginClicked() }

   
   

프래그먼트에서 뷰 바인딩 사용

프래그먼트에 사용할 바인딩 클래스 인스턴스를 설정하려면 프래그먼트의 onCreateView() 메서드에서 다음 단계를 따른다.

1. 생성된 바인딩 클래스에 포함된 정적 inflate() 메서드를 호출하면 프래그먼트에서 사용할 바인딩 클래스 인스턴스가 생성된다.
2. getRoot() 메서드를 호출하거나 Kotlin 속성 구문을 사용하여 루트 뷰 참조를 가져온다.
3. onCreateView() 메서드에서 루트 뷰를 반환하여 화면상의 활성 뷰로 만든다.
   

findViewById와의 차이점

뷰 바인딩에는 findViewById를 사용하는 것에 비해 아래와 같은 중요한 장점이 있다.

• Null Safety: 뷰 바인딩은 뷰의 직접 참조를 생성하므로 유효하지 않은 뷰 ID로 인해 null 포인터 예외가 발생할 위험이 없다. 또한 레이아웃의 일부 구성에만 뷰가 있는 경우 바인딩 클래스에서 참조를 포함하는 필드가 @Nullable로 표시된다.
• Type Safety : 각 바인딩 클래스에 있는 필드의 유형이 xml 파일에서 참조하는 뷰와 일치한다. 즉, 클래스 변환 예외가 발생할 위험이 없다.

이런 차이점은 레이아웃과 코드 사이의 비호환성으로 인해 런타임이 아닌 컴파일 시간에 빌드가 실패하게 된다는 것을 의미한다. 즉, 컴파일에서 빌드가 실패하므로 우리가 오류를 찾기 더 쉽다.

데이터 바인딩과 비교

뷰 바인딩과 데이터 바인딩은 모두 뷰를 직접 참조하는데 사용할 수 있는 바인딩 클래스를 생성한다. 하지만 뷰 바인딩은 보다 단순한 사용 사례를 처리하기 위한 것이며 데이터 바인딩에 비해 다음과 같은 이점을 제공한다.

• 더 빠른 컴파일: 뷰 바인딩에는 주석(annotation) 처리가 필요하지 않으므로 컴파일 시간이 더 짧다. (데이터 바인딩에서 @{}를 말하는듯 하다. 그래도 데이터바인딩은 쓰는게 )
• 사용 편의성: 뷰 바인딩에는 특별히 태그된 xml 레이아웃 파일이 필요하지 않으므로 앱에서 더 신속하게 채택할 수 있다. 모듈에서 뷰 바인딩을 사용 설정하면 모듈의 모든 레이아웃에 뷰 바인딩이 자동으로 적용된다.

반대로 뷰 바인딩에는 데이터 바인딩과 비교할 때 아래와 같은 제한사항이 있다.

• 뷰 바인딩은 레이아웃 변수 또는 레이아웃 표현식을 지원하지 않으므로 xml 레이아웃 파일에서 직접 동적 UI콘텐츠를 선언하는데 사용할 수 없습니다. (코틀린 파일에서 TextView, Button과 같은 요소들을 추가할 수 없다? 정도로 이해했음)
• 뷰 바인딩은 양방향 데이터 바인딩을 지원하지 않는다.(데이터 바인딩은 지원한다.)

이렇게 비교를 해봤지만 사실 뷰 바인딩과 데이터 바인딩을 모두 사용하는 것이 가장 좋은 것 같다.

추가로 궁금했던 것들

항상 inflate(), setContentView() 메서드에 대해 궁금했었다. 매크로처럼 이녀석들을 항상 호출하면서 대체 뭘까하며 생각했었다. 그래서 조금 더 찾아봤다.

inflate()

위에 1번에서 말했듯이 inflate() 메서드를 호출하면 액티비티에서 사용할 바인딩 클래스 인스턴스가 생성된다.

즉, inflate()는 xml에 표기된 레이아웃들을 메모리에 객체화시킨다. xml 파일을 객체화해서 코드에서 사용하기 위함이다. xml 파일은 단순한 디자인 정보로 이 정보를 가지고 실제로 화면에 띄우기 위해서는 xml에 정의된 속성들에 맞게 메모리에 올려야한다.

setContentView()

setContentView() 함수는 첫 번째 인자로 넘겨주는 xml 레이아웃 리소스 id에 해당하는 파일을 파싱하여 뷰(view)를 생성, 속성을 지정, 상하관계에 맞춰 배치한다.(xml 파일을 객체화시킨다.) 이런 일련의 과정을 전개(inflate)라고 부른다.

그래서 우리는 setContentView() 메서드 밑에서 xml에 있는 UI 요소들을 끌어와 쓸 수 있는 것이다. 바로 메모리에 올라가 객체화 되었기 때문이다.

setContentView() 메서드는 xml 문서를 inflate하기 위해 내부적으로 LayoutInflater 클래스를 참조한다.

inflater

xml 파일을 inflate하기 위해서 LayoutInflater 클래스를 제공한다. LayoutInflater를 생성하는 여러가지 방법이 있다.

(액티비티에서는 아래처럼 쉽게 할 수 있긴 하지만 그래도 자세히 알아봤다.)

binding = ActivityMainBinding.inflate(layoutInflater)
setContentView(binding.root)

context.getSystemService() context에서 LayoutInflater를 가져오는 방법

val inflater : LayoutInfalter = context.getSystemService(Context.LAYOUT_INFLATER_SERVICE)

Activity에서 getLayoutInflater 액티비티에서는 LayoutInflater를 쉽게 얻어올 수 있도록 getLayoutInflater()를 제공한다. 액티비티는 자신 window의 LayoutInflater를 사용한다.

val inflater : LayoutInflater = getLayoutInflater()

LayoutInflater.from() LayoutInflater에 static으로 정의되어있는 LayoutInflater.from을 통해 LayoutInflater를 만드는 방법이다.내부적으로 context.getSystemService를 호출하고 있으며, 같은 context에서는 같은 객체를 리턴하기 때문에 굳이 멤버 변수로 선언해 놓지 않고 필요할 때마다 호출해서 사용해도 괜찮다.

val inflater : LayoutInflater = LayoutInflater.from(context)

근데.. 그럼 우리가 액티비티에서 사용하던 아래 layoutInflater는 무엇일까?

binding = ActivityMainBinding.inflate(layoutInflater)
setContentView(binding.root)

layoutInflater에 ctrl + 커서를 해보면 아래와 같이 나온다.

Activity public LayoutInflater getLayoutInflater()

즉 우리가 위에서 봤던 getLayoutInflater()이다.

참고 출처 https://developer.android.com/topic/libraries/view-binding?hl=ko https://developer.android.com/reference/android/view/LayoutInflater https://soo0100.tistory.com/1017 https://lktprogrammer.tistory.com/156 https://velog.io/@appletorch/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-Inflate%EC%9D%B4%EB%9E%80 https://medium.com/vingle-tech-blog/android-layoutinflater-b6e44c265408 https://blog.naver.com/pistolcaffe/221285539895