https://velog.io/@evergreen_tree/Android-MVI-%ED%8C%A8%ED%84%B4 이전에 MVI에 대해 작성했던 글입니다. 연관되는 내용이 많으니, 보고 오시면 이해가 더 쉽습니다. 필자의 개인의 주관적인 생각이 섞여있습니다. 오타, 반박 언제나 환영합니다!

💁‍♂️UDF란?

UniDirectional Data Flow의 약자로, 단방향 데이터 흐름을 의미합니다.

UDF의 규약

• 단방향 수정
• 동기적 실행
• View와 State의 분리

Android의 경우 Activity에 View, Data, Logic이 겹치는 경우 유지보수가 힘들고 테스트가 어렵기 때문에 이전부터 View와 Data를 분리시키려는 노력이 있었습니다. 현재는 AAC Viewmodel의 활약으로 MVVM 등의 아키텍처가 성행하고 있고, 그만큼의 장점을 가져오고 있습니다.

UDF를 이러한 현재 View Data 분리 시스템에 녹일 수 있는데요, UDF의 규약을 가지고 태어난 3개의 아키텍처로 Flux, Redux, MVI가 있습니다. YAPP 21기로 활동하면서 참여한 프로젝트 티미티미에서는 Redux 아키텍처를 채택하여 앱을 개발하였는데요, 왜 선택하게 되었고 어떻게 적용했는지 공유하려고 합니다.

💁‍♀️왜 UDF인가?

상태 문제 예방

• State가 여러 작업에서 참조되고, 뒤엉키게 됨
• 비동기 작업과 얽혀 상태가 복잡해지는 경우가 생김
• ex) 페이스북의 알림 카운트의 동기화가 올바르지 않은 경우

UDF를 적용하면 이러한 장점을 얻을 수 있습니다.

• 상태 변경을 동기적으로 실행하기에, 상태 문제에 대해 안전함
• State 변화 지점이 명확하여 디버깅이 쉽다.

물론, 단점도 있습니다.

• 높은 러닝 커브
• 많은 코드 수와, 복잡한 구조

저도 해당 아키텍처를 적용하면서, 1번의 문턱을 넘기 위해 꽤나 많은 노력을 하였고, 프로젝트를 진행하면서 2번에도 많은 고통을 받았습니다.

위에서 말했듯, UDF의 규약을 가지고 태어난 3개의 아키텍처로 Flux, Redux, MVI가 있다고 하였는데요, 각각의 아키텍처 또한 서로 다른 차이점을 가지고 있습니다.

ViewModel이 가지고 있는 비즈니스 로직을 Reducer에 위임하면서, ViewModel이 책임지는 행위를 줄이고, 발생할 수 있는 문제를 디버깅할때 더 쉽게 찾을 수 있도록 Redux를 채택하게 되었습니다.

💁‍♂️구현

ViewModel에서 Intent를 받아, IntentFlow에 데이터를 발행 (View에서 ViewModel)

fun dispatch(intent: INTENT) {
        viewModelScope.launch {
            _mutableIntentFlow.emit(intent)
        }
    }

다음 과정을 거쳐 state가 최종적으로 생산

open fun start() {
        val initialViewState = getInitialState()
        viewState = _mutableIntentFlow
            .mutate()
            .filter { registerReducer() != null }
            .scan(initialViewState) { prevState, mutate ->
                registerReducer()!!.invoke(mutate, prevState)
            }
            .catch { processError(it) }
            .stateIn(
                viewModelScope,
                // 바로 생산 시작.
                SharingStarted.Eagerly,
                initialViewState
            )
    }

mutate() middleware에서 mutate 작업을 수행한 후 다시 intentflow에 병합됩니다. 이는 스트림의 가장 마지막 데이터를 반환하게 됩니다.

private fun SharedFlow<INTENT>.mutate(): Flow<INTENT> {
        val middlewareList = registerMiddleware()
        return if (middlewareList.isEmpty()) {
            this
        } else {
            middlewareList
                .scan(this.filterNotNull()) { prevIntentFlow, nextMiddleware ->
                    merge(
                        nextMiddleware.mutate(viewModelScope, prevIntentFlow, _singleEventFlow),
                        prevIntentFlow
                    )
                }.last()
        }
    }

MiddleWare은 말그대로 중개자의 역할을 하는데, Intent와 Event를 받아서 상태(State)를 업데이트 할 것인지, SideEffect를 호출할지를 결정하게 됩니다.

interface BaseMiddleware<INTENT : BaseIntent, EVENT: BaseSingleEvent> {
    fun mutate(scope: CoroutineScope, intentFlow: Flow<INTENT>, eventFlow: MutableSharedFlow<EVENT>): Flow<INTENT>
}

피쳐에서 정의한 Intent에 대해 onEach로 SideEffect를 발생시킵니다.(여기서 event를 방출) 그리고 HotFlow로 변환하여 다시 intenFlow에 병합하게 됩니다.

override fun mutate(
        scope: CoroutineScope,
        intentFlow: Flow<CreateProjectIntent>,
        eventFlow: MutableSharedFlow<CreateProjectSingleEvent>
    ): Flow<CreateProjectIntent> {
        return intentFlow.run {
            merge(
                filterIsInstance<CreateProjectIntent.ChangeProjectName>()
                    .onEach {
                        Timber.e(it.toString())
                    }
                    .shareIn(scope, SharingStarted.WhileSubscribed()),
...

reducer에서는 이전 상태를 가지고 비즈니스 로직을 수행하게 되는데, 이 과정에서 상태 변경이 일어날 수 있게 됩니다.

 .scan(initialViewState) { prevState, mutate ->
     registerReducer()!!.invoke(mutate, prevState)
 }

reducer를 통해 새로운 상태를 정의하는 과정입니다.

override fun invoke(action: BaseIntent, state: CreateProjectState): CreateProjectState {
    var newState = state
    when (action) {
        is CreateProjectIntent.ChangeProjectName -> {
            newState = newState.copy(
                projectName = action.name
            )
        }

.catch { processError(it) } 과정에서 발생하는 에러를 캐치하고, 처리할 수 있습니다.

또한 StateFlow로 변환하여 View에서 ViewState를 관찰하고, update 할 수 있는 환경을 제공합니다.

참고 : https://medium.com/@maryangmin/data-uni-directional-architecture-in-android-데이터-단방향-구조-fd7ef26e80fc

Github : https://github.com/YAPP-Github/21st-ALL-Rounder-Team-3-Android/tree/develop/core/src/main/java/com/yapp/timitimi/redux

참고 :https://maryang-developer.medium.com/data-uni-directional-architecture-in-android-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%8B%A8%EB%B0%A9%ED%96%A5-%EA%B5%AC%EC%A1%B0-fd7ef26e80fc Feat : @jshme

YAPP 후원을 통해 얻은 인프런 수강권으로 피그마 강의를 듣고, 스터디를 진행하며 작성하게 된 후기입니다.

Figma 입문 스터디를 시작하게 된 계기

IT 연합동아리 YAPP 21기로 활동하면서 느낀 점 중 하나는, 다른 기업과 연계하여 구성원들에게 스터디가 가능한 환경을 잘 조성해 준다는 점입니다. 이번 21기 기수에서는 인프런과 연계하여 수강권을 제공해 주었고, 다양한 강의들 중 어떤 걸 고르면 좋을까 고민하게 되었습니다. Android 개발자로서 디자이너와 협업하다 보면 Figma라는 툴을 많이 사용하게 되는데, 개발자와 디자이너를 편리하게 해주는 다양한 기능을 제공하는 Figma 툴에 매력에 한번 배워보고 싶어졌고, 수강하게 되었습니다.

스터디 진행

YAPP에서 진행했던 다른 스터디(알고리즘, 이펙티브 코틀린)와는 다르게 이 스터디는 혼자서 차근차근 진행해 보고 싶어 1인 스터디를 진행하게 되었습니다. 강의를 처음부터 들으며 매주 할당량을 채워나가기 시작했습니다. 스터디 도중에 회사 과제 전형을 마주치게 되었는데, 과제 전형을 진행하면서 컴포넌트화 같은 작업들을 적용해 보기도 했습니다.

후기

스터디 후반에는 면접 일정과 YAPP 활동들이 겹쳐 완주하지는 못했지만, 피그마의 핵심 기능들을 익힐 수 있게 되었습니다. 또한 아래 사진처럼 배웠던 내용을 활용해서 디자인 시스템을 직접 만들어 보는 경험을 할 수 있었습니다. Fimga 툴을 익힌다고 해서, 디자인의 신이 된다거나 현업 디자이너들의 센스를 따라갈 순 없지만, Android 개발하면서 자주 접하는 툴이고 디자이너와 소통을 위해서 한번쯤 배워보는 것도 나쁘지 않다고 생각합니다.

람다식 내에서 외부 변수를 변경하는 것에 대해 아무런 의문을 느끼지 않다가, 문득 궁금증이 생겼습니다. 함수를 작성하는 시점에는 람다식의 블럭 내부가 실행되지 않다가, 호출되는 시점에 실행될텐데 과연 어떻게 동작하게 될까요?

람다 캡쳐링 📸

• 람다식 외부에서 정의한 변수를 참조하는 것

var tabIndex by remember { mutableStateOf(0) }
tabData.forEachIndexed { index, text ->
    Tab(
        ...
        onClick = { tabIndex = index },
        ...
    )
}

위 코드는 Jetpack Compose에서 Tab 클릭 시 tabIndex가 변경되는 예시입니다. tabIndex는 onClick에 할당된 람다식의 외부 변수이지만, 클릭하는 시점에서 tabIndex가 index에 할당됩니다. 코틀린에서 어떻게 람다식에서 외부 변수를 변경시킬 수 있을까요?

In JAVA ☕

자바에 대한 이야기를 또 빼놓고 갈 수가 없습니다

자바에서는 람다식이 final 변수로 선언된 지역 변수에 접근만 가능했고, 변경이 불가능했습니다. 왜냐하면** JVM 메모리 구조 상, 지역변수가 스택에 저장**되기 때문입니다. 람다식 바디의 생명주기가 종료되면, 내부의 지역변수 할당을 해제해야 하므로 외부 지역변수의 변경이 가능할 수가 없는 구조입니다.

따라서 자바는 외부 지역변수를 복제한 데이터를 통해 읽기가 가능한 캡쳐링만을 허용했습니다.

In Kotlin 🎯

코틀린에서는 val을 포획했는지, var을 포획했는지에 따라 달라지는 것을 디컴파일 한 결과를 통해 확인할 수 있는데요, 한 번 살펴보겠습니다.

val을 캡쳐한 경우

fun main() {
    val immutable = 0
    exampleFunction(lambda = { immutable })
}

fun exampleFunction(
    lambda: () -> Int
) {
    lambda()
}

디컴파일

public final class MainKt {
   public static final void main() {
      final int immutable = 0;
      exampleFunction((Function0)(new Function0() {
         public Object invoke() {
            return this.invoke();
         }

         public final int invoke() {
            return immutable;
         }
      }));
   }

   public static void main(String[] var0) {
      main();
   }

   public static final void exampleFunction(@NotNull Function0 lambda) {
      Intrinsics.checkNotNullParameter(lambda, "lambda");
      lambda.invoke();
   }
}

val의 경우, 자바와 마찬가지로 final로 선언되어 해당 값이 캡쳐되는 것을 확인할 수 있습니다.

var을 캡쳐한 경우

fun main() {
    var mutable = 0
    exampleFunction(lambda = { mutable++ })
}

fun exampleFunction(
    lambda: () -> Int
) {
    lambda()
}

디컴파일

public final class MainKt {
   public static final void main() {
      final Ref.IntRef mutable = new Ref.IntRef();
      mutable.element = 0;
      exampleFunction((Function0)(new Function0() {
         public Object invoke() {
            return this.invoke();
         }

         public final int invoke() {
            Ref.IntRef var10000 = mutable;
            int var1;
            var10000.element = (var1 = var10000.element) + 1;
            return var1;
         }
      }));
   }

   public static void main(String[] var0) {
      main();
   }

   public static final void exampleFunction(@NotNull Function0 lambda) {
      Intrinsics.checkNotNullParameter(lambda, "lambda");
      lambda.invoke();
   }
}

보이시나요? IntRef라는 final 클래스에 의해 래핑되고, 내부적으로 변경이 가능한 변수로 포획한다는 것을 확인할 수 있습니다. IntRef로 생성된 클래스는 JVM 힙에 할당 될 것이기 때문에 람다 블록에서 변수를 변경하고 생명주기가 끝나도 영향을 받지 않을 수 있습니다.

public static final class IntRef implements Serializable {
        public int element;

        @Override
        public String toString() {
            return String.valueOf(element);
        }
    }

Nexters 21기의 첫 프로젝트인 "클라이머를 위한 출석 시스템 홀디" 를 배포하면서 생긴 Issue를 해결하기 위한 과정을 담았습니다.

Issue💡

Debug에서 정상적으로 작동하던 홀디 앱을, 출시를 위해 Release Variants로 설정하여도 잘 작동되는지 확인해 보고자 하였습니다.

그런데 앱 로그인, 온보딩이 끝나고 홈 화면으로 들어가는 시점에서 갑자기 앱이 종료되는 현상이 발생하였습니다. 에러는 다음과 같았습니다.

2022-08-30 15:13:33.779 28548-28548/? E/AndroidRuntime: FATAL EXCEPTION: main
    Process: team.nexters.semonemo, PID: 28548
    java.lang.NullPointerException: Parameter specified as non-null is null: method kotlin.jvm.internal.Intrinsics.checkNotNullParameter, parameter <this>
        at team.nexters.data.moim.mapper.MoimMapperKt.toDomain(Unknown Source:2)
...

Nullable의 문제❓

먼저, 로그에 Error가 찍혀있으니 주어진 에러를 해결하는 것을 초점에 두었습니다.

Data단에서 받은 Response를 Domain Model로 변환하는Mapper에서 위와 같은 에러가 발생하였습니다. 그렇기 때문에 에러의 이유를 다음 2 가지 중 하나일 거라고 생각했습니다.

1. 서버에서 Nullable한 값을 보내기 때문에 클라이언트 측에서도 모델의 프로퍼티를 Nullable로 지정해야 한다.
2. 데이터 직렬화는 잘 되었으나, 역직렬화에 문제가 발생했다.

위 두가지 에러를 해결해 보았으나, 근본적으로 해결되지는 않았습니다.

Debug와 Release의 차이에서 오는 것인가❓

결국 다시 처음으로 돌아왔습니다. 이번에는 Debug에서 발생하는 에러가 Release에서만 발생한다 에 초점을 두었고 buildTypes 에서 코드를 최적화 하는 코드를 살펴보았습니다.

각각의 역할은, 다음과 같습니다

• debuggable : 디버깅 여부
• minifyEnabled : 사용하지 않는 코드 제거 및 코드 난독화
• shrinkResources : 사용하지 않는 리소스 제거

StackOverFlow에서 비슷한 맥락의 오류를 발견했고, minifyEnabled , shrinkResources 를 적용하는 부분에서 에러가 발생했을 가능성을 염두하여 최적화 옵션 적용을 제거했습니다.

해결❓

최적화 옵션을 적용하지 않음으로서 당장은 해결할 수 있었습니다. minifyEnabled은 난독화 여부를 결정하는데, 난독화란 클래스 명이나 함수 명들을 a,b 등의 문자로 치환시켜 기존 코드의 보안성을 강화하는 것을 말합니다. *그러나, 단순히 최적화 옵션 적용이 안된다는 이유만으로 최적화 옵션을 버릴 수는 없었습니다. *

진짜 해결❗

MinifyEnabled를 통해 클래스 파일이 난독화가 되면, 클래스나 파일 명이 a,b,c 등이 되어 Reflection을 사용할 수가 없었습니다. 문제가 되는 코드에서 딱히 Reflection을 사용하지 않았는데, 알고보니 Retrofit 에서 Generic Parameter에 대해 Reflection을 사용하고 있다는 것을 알게 되었습니다.

Reflection을 사용하는 클래스 등, 난독화가 되면 안되는 것들은 Proguard에 정의함으로써 방지할 수 있게 됩니다. _따라서 아래와 같이 Proguard Rule을 설정함으로써, MinifyEnabled를 적용했을 때 문제 없이 작동될 수 있었습니다. _

# Retrofit does reflection on generic parameters. InnerClasses is required to use Signature and
# EnclosingMethod is required to use InnerClasses.
-keepattributes Signature, InnerClasses, EnclosingMethod

# Retrofit does reflection on method and parameter annotations.
-keepattributes RuntimeVisibleAnnotations, RuntimeVisibleParameterAnnotations

# Keep annotation default values (e.g., retrofit2.http.Field.encoded).
-keepattributes AnnotationDefault

...

Retrofit, Glide 등 외부 라이브러리는 공식 문서에 가면 Proguard Rule이 기재되어 있습니다.

💡개요

협업하는 개발자들 끼리 서로의 코드를 다 살펴볼 순 없습니다. 특히, 각자 개발한 UI에 대해 한눈에 알아보는 것은 더욱 힘든 일입니다.

UI Test를 작성하는 것 만으로도 이것이 어떻게 작동하는지 유추가 가능하게 되고, 이것은 일종의 문서 역할을 하게 됩니다.

프로젝트 덕키(Duckie)는 독립적인 디자인 시스템(Quack-Quack)을 가지고 있습니다. 덕키의 거의 모든 컴포넌트는 디자인 시스템의 컴포넌트로 이루어질 것이므로 중요성은 이루 말할 수가 없습니다. 따라서 UI Test를 통해 UI가 올바르게 작동하는지 검증하고, 안정성을 검증하는 과정을 필수로 거치게 되었습니다. https://github.com/sungbinland/duckie-quack-quack

🎆Semantic

UI Tree에 의미론적인 요소를 부여한 체계 라고 할수 있습니다

.View System에서는, 각 View가 계층 구조 내에 정의되고, 관련 속성을 보유할 수 있었습니다.

컴포저블같은 경우 시각적 표현에 중점을 두는 background라던지, text라던지 상위 컨테이너의 정렬을 포함한 트리 구조를 방출합니다. 

이러한 의미에서 *Semantic은 방출된 시점에 컴포저블에 의미를 부여하고 찾기 위한 시스템이라고 볼 수 있습니다. *

Compose의 UI 테스트는 Semantic을 사용하여 UI 계층 구조와 상호작용 하게 됩니다. Semantic tree는 UI 계층 구조와 함께 생성되고 UI 계층 구조를 형성합니다

각각의 UI요소에 시맨틱이 의미를 부여하게 되는데, 이 의미라는 것은 Test FrameWork에서 접근할수 있는 방식을 말합니다. 즉, composeTestRule.*onNodeWithText(text) 같은 방식으로 Semantic Node에 접근할 수 있는 방식을 말합니다.*

💁‍♀️Example

junit4 환경에서 간단한 버튼 테스트를 진행하면서 테스트의 흐름을 짚어보겠습니다.

ComposeTestRule

ComposeTestRule은 component, Activity를 시작하는 방법 및 finder, actions, assertions 등을 제공하는 인터페이스입니다. 특정 액티비티를 지정하고 싶다면 createAndroidComposeRule() 을 통해 생성할 수 있습니다.

@get:Rule
val composeTestRule = createComposeRule()

SetContent

덕키 디자인 시스템(Quack-Quack) 에서는 각각의 컴포넌트를 테스트 해야하므로, createComposeRule()을 생성하여 노드를 제공해야 합니다.

Semantic Node를 식별하기 위해, Companion Object에 선언한 TEST_TAG를 지정해 줍니다.

composeTestRule.setContent{
      Button(onClick = { }) {
        Text(TEST_TAG)
    }
}

Finders

Semantic은 UI 요소에 의미를 부여한다고 했습니다.

Finder는, 주어진 어떠한 조건을 통해 의미가 부여된 노드를 찾을 수 있게 해줍니다.

예를들어, argument로 주어진 Text를 가지고 있는 Semantic Node를 찾으려면 composeTestRule.onNodeWithText(TEST_TAG) 를 호출하면 됩니다. 해당 메서드는 SemanticsNodeInteraction 를 반환하고, 찾은 노드에 대한 Interaction을 진행할 수 있습니다.

혹은 onAllNodes 를 사용하여 여러 노드를 선택할 수도 있습니다.

Assertion

특정 요소가 있는지, 화면에 나타났는지 등에 대한 상태를 확인합니다.

composeTestRule.onNodeWithText(TEST_TAG).assertIsDisplayed()

이처럼 Finder, Assertion, Action을 적절히 활용하여 요소를 찾아 속성을 확인하고 Interaction을 실행하는 테스트를 작성하면 됩니다.

https://developer.android.com/jetpack/compose/semantics?hl=ko

https://developer.android.com/jetpack/compose/testing?hl=ko

https://joebirch.co/android/jetpack-compose-accessibility-semantics/

Nexters 21기 CS 스터디의 첫 번째 주제로 이어서 스케줄러에 대해 포스팅하게 되었습니다. 스케줄러를 왜 사용하는지와 스케줄링 알고리즘의 종류에 대해 알아봅시다.

📕스케줄러

어떤 프로세스에게 자원을 할당할지 결정하는 운영체제 커널의 모듈

다중 프로그래밍(Multi-programming)에서는, CPU의 이용을 극대화하기 위해 항상 어떤 프로세스가 실행될 수 있도록 하고, 시분할(Time-Shared)은 프로세스 간 문맥 전환이 빠르게 이루어질 수 있도록 해야 합니다.

운영체제는 스케줄러를 통해 CPU를 사용하려고 하는 프로세스 사이의 우선 순위를 관리하고 이것을 스케줄링 이라고 부릅니다.

프로세스는 일생 동안 다양한 스케줄링 큐 사이를 이동하는데, 프로세스를 스케줄링하기 위한 Queue에는 세 가지 종류가 존재합니다.

1. 작업 큐(Job Queue) : 시스템 안의 모든 프로세스들로 구성
2. 준비 큐(ready queue) : 메인 메모리에 존재하며, 준비 완료 상태에서 실행을 대기하는 프로세스들로 구성
3. 장치 대기 큐(device queue) : 특정 입/출력장치를 대기하는 프로세스들의 리스트들로 구성

스케줄러의 종류

1. 단기 스케줄러(CPU Scheduler) : CPU와 메모리 사이를 담당하는 스케줄러
   • 실행 준비가 완료되어 준비 큐에 있는(메모리에 존재하는) 프로세스들 중에서 선택하여 CPU를 할당
   • 단기 스케줄러는 자주 수행되므로 빨라야 함
2. 중기 스케줄러(Swapper) : 메모리에서 CPU를 점유하기 위해 경쟁하는 프로세스를 디스크로 보내는 스케줄러
   • 시분할 시스템(Time-shared)과 같은일부 운영체제에서 도입
   • 다중 프로그래밍의 정도를 완화
   • 차후 다시 프로세스를 메모리로 불러와서 중단되었던 지점에서 실행을 재개하는 스와핑(swapping) 기능을 함
3. 장기 스케줄러(Job Scheduler) : 메모리와 디스크 사이를 담당하는 스케줄러
   • 디스크 상의 프로세스를 선택하여 준비 큐로 저장(메모리로 적재)
   • 다중 프로그래밍의 정도(메모리에 있는 프로세스의 수) 제어
   • 수십 초 내지 수 분 단위로 호출되기 때문에, 속도가 느릴 수 있음

✒스케줄링

스케줄러가 메모리 내의 프로세스에게 CPU를 할당하는 것

스케줄링의 목적

CPU 이용률 최대화 (Max CPU utilization) 처리량 최대화 (Max throughput) 총 처리 시간 최소화 (Min turnaround time) 대기 시간 최소화 (Min waiting time) 응답 시간 최소화 (Min response time)

CPU의 스케줄링 결정은 다음 네 가지 상황 하에 발생합니다.

1. 실행 상태 → 대기 상태(I/O 요청이나 자식 프로세스들 중의 하나가 종료되기를 기다리기 위해 wait를 호출할 때
2. 실행 상태 → 준비 완료 상태(인터럽트가 발생할 때)
3. 대기 상태 → 준비 완료 상태(I/O의 종료 시)
4. 실행 상태 → 종료 상태

스케줄링은 비 선점 스케줄링과, 선점 스케줄링으로 나뉘어 집니다.

비 선점 스케줄링

한 프로세스가 CPU를 할당 받으면 다른 프로세스에 CPU 할당이 불가능합니다.

• 위 스케줄링 상황 중 1번과 2번인 경우, 현재 실행중인 프로세스도 없는 상황에서 준비 큐에 존재하는 프로세스를 실행시켜야 하므로 협조적인 성격을 가집니다.
• 스케줄러의 작업량이 적고 문맥 교환 오버헤드가 작지만, 처리율이 떨어집니다.
• 일괄 작업 방식 스케줄러에 사용됩니다.(FCFS, SJF, Priority)

선점 스케줄링

현재 실행중인 프로세스를 밀어내고 더 우선 순위가 높은 프로세스를 스케줄링 합니다.

• 문맥 교환 오버헤드가 많음
• 공유 메모리를 사용할 경우, 이전 프로세스 데이터 내용을 선점된 프로세스가 영향을 줄 수 있으므로 조정에 필요한 비용을 유발합니다.
• 커널 프로세스 선점으로 생기는 경쟁을 통해 커널의 데이터 보안 문제가 발생합니다.
• 시분할 방식 스케줄러에 사용됩니다.(RR, SRT, 다단계 큐, 다단계 피드백 큐)

⚙스케줄링 알고리즘

다음 문제를 통해 FCFS, SJF, SRTF, Pritority Scheduling, RR을 이해해 보겠습니다.

다음과 같은 상황에서, 각 스케줄링 알고리즘에 대해 Gantt 차트를 그려 비교해 보겠습니다.

평균 대기시간 = 대기시간/프로세스 개수

대기시간 = 처리시간 - 버스트 시간

처리 시간 = 완료 시간 - 도착 시간

FCFS

• 먼저 도착한 프로세스에게 서비스 해주는 방식
• 비선점형 스케줄링
• CPU를 할당받으면 버스트가 완료되기 전까지 CPU를 반환하지 않음

문제점

• convoy effect : 버스트 시간이 짧은 프로세스들이 늦게오면 CPU를 양도 받기를 기다려야해서 CPU와 장치 이용률이 저하됨

SJF

• 버스트가 가장 짧은 프로세스에게 먼저 CPU를 할당
• 위의 경우는 비선점형의 경우로, 자신의 CPU 버스트를 끝내기 전에는 선점되지 않음
• 선점형의 경우에는 남은 시간 보다도 더 짧은 CPU 버스트가 도착하면 그 프로세스가 선점됨(SRTF, Shortest-Remaining-Time-First, SRTF)

문제점

• starvation : 버스트 시간이 긴 프로세스들이 CPU를 무한히 대기하게 됨
• SRTF의 경우새로운 프로세스가 도달할 때마다 스케줄링을 다시하기 때문에 CPU burst time(CPU 사용시간)을 측정할 수가 없음

Priority Scheduling

• 가장 높은 우선순위를 가진 프로세스에게 CPU를 할당
• 선점형의 경우 더 높은 우선순위의 프로세스가 도착하면 선점당함
• 비선점형의 경우 더 높은 우선순위의 프로세스가 도착하면 준비 큐의 head로 넣어짐

문제점

• starvation : 우선순위가 낮은 프로세스들이 CPU를 무한히 대기하게 됨

해결책

• aging : 오랫동안 대기하는 프로세스들의 우선순위를 점진적으로 증가시키는 방법

Priority Scheduling

• 시분할 시스템에 적합
• 각 프로세스는 시간 할당량(time quantum) 또는 시간 조각(time slice)라는 작은 단위의 시간을 획득하고, 이 시간이 지나면 프로세스는 선점되고 준비완료 큐의 tail에 추가됨

장점

• 준비 완료 큐에 n개의 프로세스가 있고 시간 할당량이 q이면, 각 프로세스는 자신의 다음 시간 할당량이 할당될 때 까지 (n-1) x q 시간 이상을 대기하지 않음. 즉 response time이 빨라짐

성능

• 시간 할당량이 매우 크면, FCFS랑 같아짐
• 시간 할당량이 작으면 문맥 전환으로 인한 오버헤드가 발생함(최소 문맥 교환 시간 10 마이크로초 미만) 보다 커야함
• 적정한 시간 할당량을 부여하는 것이 과제

Nexters 21기 CS 스터디 첫 번째 주제로 프로세스와 스레드에 포스팅하게 되었습니다. 프로세스와 스레드의 차이를 알고 작동하는 방식에 대해 이해하는 것이 요점일 것 같습니다.

📜프로세스

프로세스는 수행 중인 프로그램을 의미합니다.

디스크에 저장된 실행 파일을 프로그램이라고 하고, 메모리에 적재되어 CPU 자원을 할당 받아 실행되고 있을 때 프로세스라고 부릅니다.

운영체제는 다양한 프로그램을 Windows에서 Ctr+Alt+Delete 명령어를 통해 운영체제에 의해 관리되고 있는 프로세스의 목록을 확인할 수 있습니다.

프로세스의 구성

• 스택(Stack) : 임시 데이터 저장소(함수의 매개변수, 복귀 주소, 지역 변수)
• 힙(Heap) : 실행 중에 동적으로 할당되는 메모리
• 데이터 섹션(Data) : 전역 변수
• 텍스트 섹션(Text) : 프로그램 코드를 포함
• 프로그램 카운터, 레지스터

프로세스 제어 블록(PCB)

특정 프로세스와 연관된 여러 정보를 수록한 블록입니다.

하나의 프로세스가 CPU 자원을 사용하다가 다른 프로세스가 CPU 자원을 사용하기 위해서는, 이전 운영체제가 프로세스의 상태를 기억하고 있어야 합니다. 프로세스 간 병행 수행을 위해 CPU 할당을 스위치 하는 것을 문맥 교환이라고 하고, 문맥 교환을 위해서 PCB를 필요로 합니다.

PCB에는 다음과 같은 프로세스의 상태가 저장됩니다.

• 프로세스 상태, 번호
• 프로그램 카운터
• CPU 레지스터
• CPU 스케줄링 정보(우선순위, 스케줄링 큐 포인터)
• 메모리 관리 정보(프로세스에 할당된 메모리)
• 회계 정보(CPU 사용량, 경과 시간)
• 입/출력 상태 정보(프로세스에 할당된 입출력 장치, 열린 파일 리스트)

멀티 프로세스

하나의 응용 프로그램을 여러 개의 프로세스로 구성하여 각 프로세스가 하나의 작업을 처리

ex) 구글 크롬 브라우저같은 경우 브라우저, 렌더러, 플러그인 프로세스로 나뉨

• 장점 : 프로세스 간 독립적이어서 동기화 작업이 필요하지 않으므로 안정성이 확보된다.
• 단점 : 메모리를 공유하지 않으므로 IPC라는 통신 기법을 통해 프로세스 간 통신을 해야하는데, 이 과정이 어렵고 복잡하다. 또한 문맥 교환 과정에서 오버헤드가 발생할 가능성이 높다.

📍스레드

• CPU 이용의 기본 단위
• 프로세스의 실행 단위

스레드의 구성(Multi Thread)

스레드는 스레드 ID, 프로그램 카운터, 레지스터 집합, 스택으로 구성되어 있습니다. 그리고 같은 프로세스에 속한 다른 스레드와 코드, 데이터 섹션, 열린 파일이나 신호 같은 운영체제 자원을 공유합니다.

각자 스택과 PC 레지스터 값을 가지고 있어 각각의 스레드가 독립적인 작업을 수행할 수 있고, 명령어의 어디까지 수행 했는지 알 수 있습니다.

멀티 스레드

하나의 프로세스를 멀티 스레드를 통해 자원을 공유하고, 자원의 생성 및 관리의 중복성을 최소화하여 수행 능력을 향상시키는 것을 멀티 스레딩이라고 합니다.

ex) 디스플레이 갱신, 네트워크 요청 응답들은 대부분 멀티 스레드(2개 이상의 스레드)로 동작합니다.

장점

• 응답성 : 프로세스의 일부분이 봉쇄되거나, 긴 작업을 수행해도 프로그램을 지속 수행할 수 있습니다. 특히 사용자 인터페이스 설계에 유용합니다.
• 자원 공유 : 프로세스의 자원들과 메모리를 공유하기 때문에, 같은 주소 공간 내에 여러개의 다른 작업을 하는 스레드 수행이 가능합니다.
• 경제성 : 스레드 생성과 문맥교환 오버헤드가 프로세스 보다 적습니다.
• 규모 적응성 : 멀티 프로세서 구조에서 각각의 스레드를 병렬로 수행할 수 있습니다.

단점

• 동기화 문제 : 멀티 스레드가 멀티 프로세스보다 확연한 장점을 보이지만, 이는 멀티 스레드의 동기화 문제를 잘 해결했을 때의 이야기 입니다. 서로 다른 스레드가 Data, Heap 공간을 공유하기 때문에, 스레드 동기화 기법을 통해 처리해야 합니다.
• 하나의 스레드에 문제가 발생하면 전체 프로세스가 영향을 받아 강제 종료될 수 있습니다.

📌 멀티 프로세스 대신 멀티 스레드를 사용하는 이유

• 자원을 효율성 증대 및 처리 비용 감소 : 프로세스 생성 시 자원을 할당하는 시스템 콜이 감소하고, 스레드 간의 자원 공유가 간단하기 때문에 자원 소모가 적습니다.

• 응답 시간 단축 : 프로세스의 경우 Context Switching 시 CPU 레지스터, RAM과 CPU 사이의 캐시 메모리가 초기화되기 때문에 오버헤드가 큰 반면, 스레드는 Context Switching시 Stack영역만 처리하면 되므로 스레드 간의 문맥 교환 속도가 빠릅니다.

대신, 서로 다른 스레드가 Data, Heap 공간을 공유하기 때문에, 스레드 동기화 기법을 통해 처리해야 합니다.

참고 자료 https://cocoon1787.tistory.com/688

Compose로 UI를 작성하면서 "Modifier' can't be called in this context by implicit receiver. Use the explicit one if necessary" 라는 이슈를 만나게 되었고, 그런 김에.. 재사용 가능한 Composable을 올바르게 작성하는 방법을 공유하려고 합니다.

1. 문제 파악하기

예시로 쉽게 파악할 수 있게, 토이프로젝트의 일부 화면을 가져왔습니다. 위 화면은 Compose로 작성된 UI입니다. 저는 여기서 반복적으로 사용되는 코드를 줄이고 이를 하나로 묶기 위해 Composable 함수를 작성하려고 합니다.

그러면 여기서 반복적으로 사용되는 컴포넌트는 무엇일까요?

흰색 배경에 Round Corner을 가지고 있는, 이 Box가 공통적으로 사용되고 있습니다.

Box(
    modifier = modifier
            .fillMaxWidth()
            .height(68.dp)
            .clip(RoundedCornerShape(20.dp))
            .background(White),
        contentAlignment = alignment
    ) {
         Text(
                modifier = Modifier.padding(start = 16.dp),
                text = buildAnnotatedString {
                            withStyle(SpanStyle(fontSize = 14.sp, fontWeight = FontWeight.Bold)) {
                                append("지금은 땅이 쉬는중이에요\n")
                            }
                            append("커밋해서 잔디 씨앗을 뿌려주세요")
                        },
                color = Black,
                fontSize = 12.sp,
                fontFamily = suit,
                fontWeight = FontWeight.Normal
         )
    }
}

기본적으로 위 화면은 이러한 코드들로 이루어 지고 있습니다. 하나의 컴포저블을 작성하는데에는 이렇게 처리해도 그렇게 큰 문제는 없습니다.

그러나, 이러한 컴포저블이 많아졌을 때 round corner와 background를 컴포저블을 작성할 때 마다 설정해 주는것은 너무 비효율적입니다. 그래서 우리는 이를 재사용이 가능하도록 컴포저블 함수로 분리시키겠습니다.

2. Composable 함수 만들기

이런 함수를 하나 만들어 줍니다. 유동적으로 변화해야 하는 부분은 parameter로, 공통적으로 적용되는 부분은 블록 내에 작성될 것입니다.

먼저 공통점을 찾아야 겠죠?

1.  RoundCornerShape(20.dp)
2.  background(white)

이렇게 두개 정도가 될 것입니다. 하지만 크기나 정렬, 클릭 가능 여부 등, Modifier 의 속성같은 경우는 유동적으로 변경될 수 있어야 합니다.

예를 들면 아래 사진과 같이, 일정한 비율로 한 행에 존재할 수 있고, 들어갈 내용물도 달라야 합니다.

그러면 위의 것들을 종합하여 컴포저블 함수를 작성해 보겠습니다.

@Composable
internal fun RoundCornerBox(
    modifier: Modifier,
    alignment: Alignment = Alignment.CenterStart,
    content: @Composable BoxScope.() -> Unit
) {
    Box(
        modifier = modifier
            .clip(RoundedCornerShape(20.dp))
            .background(White),
        contentAlignment = alignment
    ) {
        content()
    }
}

함수의 인자로 modifier, alignment, content 를 받고 있습니다.

modifier 같은 경우 클릭 가능 여부나 크기 등이 바뀔 수 있으므로, 상태를 외부에서 전달 받을 수 있도록 합니다.

alignment 같은 경우, 기본적으로 CenterStart를 사용하는데 잔디 이미지같은 경우 아래에 위치하므로 필요 시 다른 것을 전달하면 됩니다.

content 를 통해서 다른 위젯들을 전달받을 수 있습니다. 그러나 여기서 중요한 점이 하나 있습니다.

content 들은 전달받아 Box 내부에서 사용됩니다. 그런데 여기서 수신 객체를 BoxScope 로 지정해 주지 않으면 다음 오류가 발생합니다. 왜냐하면 Box같은 경우, BoxScope 내에 지정된 자식들이 align 될 수 있으므로, 전달받은 인자들이 BoxScope에 포함된다는 의미로 수신객체를 지정해줘야 합니다.

@Composable
inline fun Box(
    modifier: Modifier = Modifier,
    contentAlignment: Alignment = Alignment.TopStart,
    propagateMinConstraints: Boolean = false,
    content: @Composable BoxScope.() -> Unit
) 

3. 사용하기

RoundCornerBox(
        modifier = Modifier
               .fillMaxWidth()
               .height(106.dp),
       alignment = Alignment.BottomCenter
){
    Image(
         modifier = Modifier
                  painter = painterResource(id = R.drawable.refresh),
                  contentDescription = "refresh"
    )
    ...
}

사용할 때는 이런식으로 사용하면 됩니다. 결과적으로 background와 round corner을 계속 지정해 주지 않아도 유동적으로 사용할 수 있게 되었습니다!

개발하면서 sealed class를 잘 모르고 썼던 것 같아서 이번 토픽으로 정하게 되었습니다. Navigation, State등의 상태 나열 등에 썼었던 것 같은데 왜 sealed로 선언하는지 그 이유를 보겠습니다.

🧷sealed class

Sealed class는 자기 지신이 추상 클래스이고, 자신을 상속받는 서브 클래스를 가질 수 있습니다.또한 부모 클래스를 상속받는 자식 클래스의 종류을 제한합니다.

open class State(
    val data: String? = null
)

open class로 선언된 State를 상속받는 클래스는 다른 곳에서 참조하여 상속받아 사용할 수 있습니다.

sealed class State()

하지만 sealed class는 해당 패키지 내에서만 자식 클래스를 상속할 수 있는 추상 클래스입니다.

추상 클래스이기 때문에 sealed class의 인스턴스를 생성할 수는 없습니다.

sealed class 선언 방법

1. 보통 선언 방법

sealed class State

object Success : State()
object Failure : State()

2. Nested class(중첩 클래스로 선언)

   sealed class State{
    object Success : State()
    object Failure : State()
   }

   
   
   

🚩sealed class의 특징

자식 클래스 제한

sealed class와 그 하위 클래스는 한 패키지 내에 존재하기 때문에, 컴파일 시간에 컴파일러에게 이들이 알려집니다. 그렇기 때문에 반대로 다른 파일에서는 하위 클래스들을 선언하면 오류가 발생합니다.

동일 패키지 내라는 것은 package com.evergreen.todaycommit.domain.usecase 라는 패키지가 있다면 이 usecase 내에서만 선언되어야 한다는 뜻입니다.

sealed class State()

class Success : State()
class Failure : State()

생성자 제한

sealed class State(){
    private constructor(data: String): this()
    protected constructor(data: String, data2: String): this()
}

private, protected 이 두 가시성 만을 가질 수 있습니다.

✋sealed class의 장점

여태까지 특징을 설명했지만 어떤 상황에 사용하는 지 아직까지 감이 오지 않을 것 입니다. sealed class의 장점은 자식 클래스를 패키지 내에 제한하는 sealed class의 특징에서 나옵니다. when을 사용할 때, 하위 클래스들의 케이스를 else 없이 커버할 수 있습니다.

이런 예시를 한번 생각해 봅시다.

어떠한 상태를 표현하려고 합니다

1. 성공
2. 로딩중
3. 에러

이러한 경우에 따라 메시지를 출력하는 예제를 만들어 보겠습니다.

abstract class로 구현

abstract class State

class Loading : State()
class Success : State()
class Error : State()

fun test(state: State){
    return when(state){
        is Success -> "성공"
        is Loading -> "로딩중"
        is Error -> "에러"
    }
}

위 코드는 컴파일시 아무런 오류가 없을까요? 개발자의 입장에서는 State의 모든 케이스를 커버해 줬으니 오류가 나지 않을 것이라고 예상합니다. 하지만 결과는 이렇습니다. 내용을 보면, else 브랜치를 필요로 한다는 문구를 볼 수 있습니다. 왜냐하면, 컴파일러가 State를 상속받은 하위 클래스들의 종류를 다 알지 못하기 때문입니다.

그렇다면 이 코드에서 else -> "그 외 상태" 문구를 추가해 주면 끝이지 않겠느냐 하는 생각이 드실 수도 있습니다.

컴파일러가 딱히 오류를 잡아주지 않아 정상적인 코드라고 생각할 수 있지만, *Error라는 상태를 else에서 상태가 없음으로 체크하고 있습니다. *

프로그래밍에 있어서 개발자의 실수를 줄이기 위해 많은 노력을 해야만 하는데, 이러면 실수는 커녕 실수했는지도 모르는 상황이 발생해 버립니다.

sealed class로 구현

sealed class State

class Loading : State()
class Success : State()
class Error : State()

fun test(state: State): String{
    return when(state){
        is Success -> "성공"
        is Loading -> "로딩중"
        is Error -> "에러 발생"
    }
}

sealed class로 선언된 State를 상속 받았을 때에는 else 브랜치가 없어도 오류가 나지 않고 있습니다. 왜냐하면 컴파일러가 State의 자식 클래스를 알고있기 때문입니다.

자 이제 sealed class의 장점에 대해 알 수 있게 되었습니다. 추가적으로 왜 class에 초록색 출이 쳐져 있는지 알아보겠습니다. sealed class의 sub class가 상태를 가지고 있지 않거나, equals를 상속받고 있지 않다고 말합니다. 따라서 이를 object로 변환하는 것을 권하고 있습니다.

왜냐하면 클래스는 기본적으로 hashcode(),eqauls()를 가지고 있고, 딱히 상태를 가지고 있지 않은데 class로 선언되면 생성 될 수록 메모리가 낭비되기 때문입니다.

코틀린에서 object로 선언하게 되면 singleton으로 생성되므로, 이럴 때에는 object로 선언해 줘야 합니다.

sealed class VS enum class

sealed class State{
    object Loading : State()
    data class Success(val data: String) : State()
    data class Error(val throwable: Throwable, val message: String) : State()
}

또한 여기서enum class와의 차이점이 나오는데, enum class에서는 열거형을 표현하기 위해 클래스의 타입이 정해져 있고 object로 설정되지만 sealed class 는 하위 클래스들이 여러 객체를 생성할 수 있습니다.

참고 자료 https://kotlinlang.org/docs/sealed-classes.html#location-of-direct-subclasses https://kotlinworld.com/165?category=924651

https://velog.io/@evergreen_tree/KotlinDelegation 이전 글에 이어서, 이번에는 Delegated Property에 대해 포스팅하겠습니다. KProperty 라는 생소한 개념도 나와서 함께 작성해 보았습니다.

📢Delegated Property

• Class Delegation과 비슷하게 프로퍼티의 getter, setter를 다른 객체에 위임하는 것을 의미합니다.

Character라는 클래스에서 프로퍼티를 갱신하거나, 참조할 때 마다 값을 출력하는 상황을 예로 들어 보겠습니다.

class Character {
    var hp: Int = 0
        get() {
            println("Get hp : $field")
            return field
        }
        set(value) {
            println("Get hp : $value")
            field = value
        }

    var mp: Int = 0
        get() {
            println("Get hp : $field")
            return field
        }
        set(value) {
            println("Get mp : $value")
            field = value
        }
}

fun main() {
    val character = Character()
    character.hp = 100
    character.mp = 200
    println("캐릭터의 hp는 ${character.hp} mp는 ${character.mp}")
}

Character라는 클래스 내에서 접근자를 작성해주고, main에서 프로퍼티를 변경해 준 후 결과를 보겠습니다.

그리 복잡하지 않은 코드이지만, 이 다섯줄을 출력하기 위해 소비하는 코드가 너무 많습니다. 또한 중복된 내용을 담고 있습니다. 코드를 보면 접근자의 동작이 같은 형식을 띄고 있기에, 이를 따로 클래스에 담아서 수작업으로 위임해보겠습니다.

Delegation without by

class Delegator(private val name: String) {
    var value: Int = 0
    fun getter(): Int{
                println("get $name : $value")
        return value
    }
    fun setter(newValue: Int){
                println("set $name : $value")
        value = newValue
    }
}

class Character {
    var hpDelegator = Delegator("hp")
    var mpDelegator = Delegator("mp")

    var hp: Int
        get() = hpDelegator.getter()
        set(value) = hpDelegator.setter(value)

    var mp: Int
        get() = mpDelegator.getter()
        set(value) = mpDelegator.setter(value)
}

fun main() {
    val character = Character()
    character.hp = 100
    character.mp = 200
    println("캐릭터의 hp는 ${character.hp} mp는 ${character.mp}")
}

결과는 전과 똑같습니다.

총 코드 라인 수는 그렇게 달라지지 않았지만, Delegator에게 공통 형식의 접근자를 만들고 위임함으로써 재사용성이 올라갔습니다. 하지만 아직까지 중복되는 코드가 많아보입니다.

이제 코틀린의 by 키워드를 통해 이를 더 줄여보겠습니다.

Delegation using by

import kotlin.reflect.KProperty

class Delegator(private var value: Int) {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): Int {
        println("get ${property.name} : $value")
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: Int) {
        println("set ${property.name} : $newValue")
        value = newValue
    }
}

class Character(hp: Int, mp: Int) {
    var hp by Delegator(hp)
    var mp by Delegator(mp)
}

fun main() {
    val character = Character(0,0)
    character.hp = 100
    character.mp = 200
    println("캐릭터의 hp는 ${character.hp} mp는 ${character.mp}")
}

Delegator클래스에서 연산자 오버로딩을 통해, getValue와 setValue를 제공하게 되면, Character클래스의 hp와 mp에 접근자를 위임받아 사용할 수 있게 됩니다.

getValue와 setValue 라는 연산자 오버로딩을 구현하기 위해서는, 지정된 파라미터를 꼭 제공해야 합니다.

Kproperty는 kotlin.reflect 패키지에 선언된 인터페이스로, val or var로 선언된 프로퍼티의 정보를 가지는 인터페이스입니다.

operator fun getValue(thisRef: Any?, property: KProperty<*>) {
        println("set ${property.name} : $newValue")
 }

만약 val hp라면 property.name 에서 “hp”에 대해 얻을 수 있습니다. KProperty의 인스턴스는 Reflection 연산자인 ::으로부터 얻을 수 있습니다.

참고 자료 https://kotlinlang.org/docs/delegation.html#overriding-a-member-of-an-interface-implemented-by-delegation

코틀린에서 많이 사용하는 by 키워드, 특히나 뷰모델을 사용할 때 많이 봤었습니다. val viewModel: MainViewModel by viewModels() 단순히 viewModel을 위임하는 것이라고 알고 있었는데, 위임한다는 것이 무슨 의미이고, 어떤 식으로 작동하는지 알아보려고 합니다.

🌎Delegate Pattern

소프트웨어 엔지니어링에서 delegate pattern(위임 패턴) 은 객체 합성이 상속과 동일하게 코드 재사용을 할 수 있도록 하는 객체 지향 디자인 패턴이다. https://en.wikipedia.org/wiki/Delegation_pattern Delegate Pattern은 디자인 패턴 중 하나로, 한 객체가 다른 객체로부터 기능 일부를 넘겨받아 데이터를 제공하거나 특정 작업을 수행 할 수 있게 하는 것입니다.

🚩In OOP

객체지향에서는 상속을 허용하지 않는 클래스에 새로운 기능을 추가할 때 위임을 사용할 수 있습니다. 위임을 사용하면 상속하지 않고 기존 기능을 그대로 사용하면서 새로운 기능을 추가 할 수 있습니다.

🏬Delegation In Kotlin

Kotlin에서는 Delegate Pattern을 by라는 키워드로 제공하고 있습니다. 이 by 라는 키워드는 Delegation을 직접 구현하는 데에서 생기는 보일러 플레이트 코드의 감소를 목적으로 사용됩니다.

Class Delegation

interface Champion {
    val hp: Int,
    val mp: Int,
    fun info()
}

League of Legend라는 게임을 예시로 들어서 설명해 보겠습니다. Champion이라는 인터페이스는 체력과 마나를 뜻하는 hp, mp, 체력과 마나 정보를 출력하는 info() 메서드를 가지고 있습니다.

class User(private val champ: Champion) : Champion {
    override val hp: Int = champ.hp
    override val mp: Int = champ.mp
    override fun info() = champ.info()
}

User라는 클래스는, Champion을 직접 구현하는 것이 아닌, Champion 인터페이스의 구현체를 인자로 받아, 프로퍼티와 메서드를 위임 받고 있습니다

class Ezreal : Champion {
    override val hp: Int = 500
    override val mp: Int = 400

    override fun info() {
print("체력은 $hp, 마나는 $mp 입니다.")
    }
}

fun main(){
    val user = User(Ezreal())
    user.info()
}

자 그러면 이렇게 User에 Champion의 구현체인 Ezreal을 전달하면, User 객체는 Ezreal을 상속받지 않더라도 Ezreal의 기능을 사용할 수 있습니다.

하지만, 프로퍼티가 많으면 많아질수록 위임하는 코드는 많아질 것이고, 이는 불필요한 코드를 야기할 것입니다.

이를 위해 코틀린에서 지원하는 키워드가 by 입니다.

class User(private val champ: Champion) : Champion by champ

Champ by champion parameter로 들어온 champion을 by 라는 키워드를 통해 위임해주면 이처럼 한줄로 해결할 수 있게 됩니다.

위임 된 클래스에서 변수를 선언하는 경우

class User(private val champ: Champion) : Champion by champ {
    override val hp = 300
}

fun main(){
    val user = User(Ezreal())
    user.info()
}

하지만, by 키워드를 사용하여 위임된 클래스에서 프로퍼티를 따로 설정해 두었을 때, delegate object인 user는 이를 모르게 됩니다. 즉, hp 300은 출력되지 않게 됩니다.

그렇다면 왜 Delegation을 사용하는가? 상속 받으면 되는 것 아닌가?

코틀린의 기본 라이브러리는 open되지 않은 final클래스입니다.

코틀린에서는 표준 라이브러리의 무분별 상속을 지양합니다. 상속을 통해 클래스의 확장을 필요로 할 때가 있는데 위임을 사용하면 상속과 비슷하게 final 클래스의 모든 기능을 사용하면서, 동시에 기능을 확장할 수 있습니다.

다음 포스팅으로 이어집니다! https://velog.io/@evergreen_tree/KotlinDelegation-2.-Delegated-Property

참고 자료 https://kotlinlang.org/docs/delegation.html#overriding-a-member-of-an-interface-implemented-by-delegation

이번 토픽은 inline class입니다. inline fun은 사용해 봤지만 inline class는 사용해 본적이 없는 것 같아서 주제로 선정하게 되었습니다. 클래스 내부 구조를 살펴볼 때 몇번 본 것 같은데, 왜 사용하는지 알아보겠습니다.

🏃‍♀️Inline Class : 컴파일러가 부리는 마법

@JvmInline
value class Password(private val s: String)

• 다른 변수와 혼동되지 않기 위해 값을 래핑할 수 있는 클래스
• value로 선언함으로써 컴파일러가 객체를 생성하지 않고 값을 매핑해 줌

@JvmInline 어노테이션과 value 키워드를 붙이면 value(inline) 클래스를 선언할 수 있습니다.

@JvmInline 은 KotlinJs, KotlinNative 등 다른 버전과 호환을 위해 존재하는 어노테이션 입니다.

이렇게만 보면 어차피 wrapper 클래스를 사용할거면 data class를 사용하지 굳이? 라는 생각이 들 수 있습니다. 물론 저도 맨 처음에는 그렇게 생각했었습니다. 그런 여러분들을 위해 준비해보았습니다!

🤷‍♂️Why use Inline Class?

Sometimes it is necessary for business logic to create a wrapper around some type. However, it introduces runtime overhead due to additional heap allocations. Moreover, if the wrapped type is primitive, the performance hit is terrible, because primitive types are usually heavily optimized by the runtime, while their wrappers don't get any special treatment.

To solve such issues, Kotlin introduces a special kind of class called an inline class. Inline classes are a subset of value-based classes. They don't have an identity and can only hold values.

공식 문서에 나와 있는 내용을 요약하면 이렇습니다.

비즈니스 로직을 위해 특정 type을 Wrapper로 감싸줘야 할 때가 있는데, 이 때 객체를 생성하기 위해 힙 할당을 하게 됨으로써 런타임 오버헤드가 발생하고 성능 저하가 일어난다는 이야기를 하고 있습니다. 따라서 이를 해결하기 위해 inline 클래스를 사용할 수 있습니다.

솔직히 아직까진 잘 모르겠습니다. 처음부터 차근차근 짚어나가겠습니다.

fun alarm(millis: Long){
    print("$millis 밀리 후에 알람이 울립니다.")
}

fun test(){
    alarm(2000L)
}

alarm이라는 함수를 통해 간단히 출력하는 것을 구현해 보았습니다.

여기서 2000L이라는 parameter를 넣어 호출해 보겠습니다.

별 문제 없어 보이는 코드일 수 있습니다. 하지만 2000밀리세컨드는 2초라는 사실을 잘 모르는 경우도 있을 것이고 , 다른 비즈니스 로직을 적용하더라도 소수만 알아 들을 수 있는 어떠한 값이 있을 것입니다.

이러한 문제를 Wrapper Class를 작성함으로써 해결할 수 있습니다.

fun alarm(duration: Duration){
        print("{$duration.millis} 밀리 후에 알람이 울립니다.")
}

fun test(){
        alarm(Duration.seconds(2))
}

data class Duration private constructor(
        val millis: Long,
) {
    companion object {
        fun millis(millis: Long) = Duration(millis)
        fun seconds(seconds: Long) = Duration(seconds * 1000)
    }
}

이런 식으로 Duration class를 통해 2초라는 사실을 바로 확인할 수 있습니다.

그러나, data class를 사용한다면 매번 alarm을 호출할 때 마다, Duration이라는 객체를 생성하여 할당해 줘야 합니다.

추가 힙 할당으로 생기는 런타임 오버헤드를 방지하기 위해, value라는 modifier를 앞에 붙여주어 inline class를 선언해 보겠습니다.

fun alarm(duration: Duration){
        print("{$duration.millis} 밀리 후에 알람이 울립니다.")
}

fun test(){
        alarm(Duration.seconds(2))
}

@JvmInline
value class Duration private constructor(
        val millis: Long,
) {
    companion object {
        fun millis(millis: Long) = Duration(millis)
        fun seconds(seconds: Long) = Duration(seconds * 1000)
    }
}

value class로 선언된 Duration은, 파라미터로 들어올 때, 객체의 프로퍼티로 대체됩니다. 자바로 디컴파일 하면서 무슨일이 일어나고 있는지 확인해 보겠습니다.

data class

public static final void alarm(@NotNull Duration duration) {
      Intrinsics.checkNotNullParameter(duration, "duration");
      String var1 = duration.getMillis() + " 밀리 후에 알람이 울립니다.";
      System.out.print(var1);
}

자바로 디컴파일 했을 때, data class로 선언된 Duration 의 경우, 객체 자체를 받아서 객체 내의 프로퍼티를 가져오고 있습니다.

value class

public static final void alarm_ZlhV6Ys(long duration) {
      String var2 = duration + " 밀리 후에 알람이 울립니다.";
      System.out.print(var2);
   }

fun alarm(duration: Duration) 분명히 코틀린 코드는 Duration을 받고 있으나, 자바로 디컴파일 했을 때 위와 같이 Duration 내의 프로퍼티를 가져오고 있습니다.

여기서 디컴파일 시 _ZlhV6TYs 처럼 특정한 문자열을 붙이는 것을 맹글링이라고 합니다.

@JvmInline
value class People(val name: String){
    fun f(people: People) {}
    fun f(name: String) {}
}

위와 같이 메서드 오버로딩을 적용했을 때, 맹글링이 적용되지 않는다면 디컴파일 하였을 때 메서드 이름과 parameter가 중복이 됩니다.

이처럼, 컴파일러가 자동으로 최적화를 진행해 주기 때문에, 객체를 할당하지 않아도 Wrapper 클래스를 통해 가독성을 높일 수 있습니다.

🧏‍♀️value class의 특징

• 프로퍼티를 하나만 가질 수 있음

• equals(), toString(), hashCode() 메서드만 생성(data class는 copy(), componentN() 까지 생성)

• === 연산을 지원하지 않음

• val 프로퍼티만 허용

결론은 어떠한 데이터를 Wrapper 클래스로 감쌀 때, value class를 사용하자가 되겠습니다..!

참고 자료 https://kotlinlang.org/docs/inline-classes.html https://velog.io/@dhwlddjgmanf/Kotlin-1.5에-추가된-value-class에-대해-알아보자

자바에서도 Generic에 대해 얕게 이해하고 있었는데, Kotlin에서 in, out를 만나니까 제대로 이해하지 못하고 있다는걸 깨닫게 되었습니다. Kotlin 공식 문서를 참고하여 포스팅하였습니다.

🖐Generic

• Data Type Generalize
• 클래스 내부에서 사용할 Data Type을 컴파일 시 미리 지정하는 것을 의미합니다.

Class 혹은 Interface 선언

class State<T>(t: T) {
    var value = t
}

자바와 마찬가지로, 클래스에 <type argument>를 붙여, 선언합니다.

인스턴스 생성

val state: State<String> = State<String>("ㅎㅇ")

클래스의 인스턴스를 생성할 때, <> 안에 데이터 타입을 명시하고 인스턴스를 생성할 수 있습니다.

val state = State("ㅎㅇ")

혹은, 따로 데이터 타입을 명시하지 않고 생성자를 통해 유추할 수 있다면 컴파일러가 자료형을 자동으로 추론합니다.

🤷‍♂️Variance

제네릭을 설명할때 이 Variance(가변성) 이라는 개념을 빼놓을 수 없습니다.

Variance는 제네릭 타입의 계층 관계가 어떤지를 나타내는 개념입니다. Variance에는 세 가지 종류가 있습니다.

Type A가 Type B의 하위 타입일 때

• invariance(무공변) : Class<A> 와 Class <B>의 상속 관계가 없음
• covariance(공변) : Class<A>는 Class<B>의 하위 타입
• contravariance(반공변) : Class<A>는 Class<B>의 상위 타입

코틀린에서는 자바와 마찬가지로 기본적으로 Generic Class 간 invariance(무공변) 상태입니다. 이는 밑에서 공변성을 이해할 때 더 쉽게 이해할 수 있을 것입니다.

객체지향 제 5원칙 중, 리스코프 치환 원칙을 지키기 위해서는, 상위 타입이 사용되는 경우 하위 타입의 인스턴스를 통해 동작할 수 있어야 합니다. Generic에서도 이를 지키기 위해서 Variance라는 개념을 사용하게 됩니다.

👨‍🦳Covariance

먼저 자바에서 예를 들어보겠습니다.

Java에서의 covariance(공변)

interface Collection<E> ... {
    void addAll(Collection<E> items);
}

임의로 addAll이라는 메서드를 작성합니다.

매개변수로 받은 items에게 E 타입의 모든 item을 넘겨주는 메서드입니다.

void copyAll(Collection<Object> to, Collection<String> from) {
    to.addAll(from);
}

copyAll을 통해 to로 받은 인자가 addAll을 호출하여 from에게 데이터를 넘겨줘봅시다. _위의 코드는 오류가 날까_요?

네. 왜냐하면 String는 Object의 하위 타입이지만, List<String>은 List<Object>의 하위 타입이 아니기 때문입니다. 이를 무공변(invariance) 관계라고 합니다 위와 같은 경우 런타임 안정성을 보장하기 위해 컴파일 타임에 오류를 발생 시킵니다.

자바에서는 이를 해결하기 위해 와일드 카드라는 개념을 이용합니다.

interface Collection<E> ... {
    void addAll(Collection<? extends E> items);
}

익숙하지 않은 <? extends E> 가 보이는군요. 자바에서는 <? extends E> 를 통해서 E 타입 또는 E의 하위 유형을 허용할 수 있게 하여 covariance(공변) 관계로 만듭니다.

자 다시 공변성에 대해서 짚고 가보겠습니다.

• covariance(공변) : Type A가 Type B의 하위 타입일 때 Class<A>는 Class<B>의 하위 타입

Generic Type 이 상속 관계를 가지고 있더라도 Generic Class는 상속 관계가 아닙니다. 즉, 기본적으로 무공변 상태인 것입니다. 자바에서는 이를 해결하기 위해 wildcard type argument를 제공하고, 공변 관계로 만들 수 있습니다.

이제 우리는 Generic의 covariance에 대해 이해할 수 있게 되었습니다.🎈

Kotlin에서의 covariance(공변)

interface List<out E> ... {
   addAll(items: List<E>)
}

fun copyAll(to: List<Object>, from:List<String>) {
    to.addAll(from);
}

Kotlin에서는 클래스에 out을 붙여 컴파일러에게 공변 상태임을 알려주게 됩니다.

보통 제네릭 인자가 생산자가 되는 경우, 즉 제네릭 타입에서 들어온 인수가 하위 타입이어서 상위 타입에 안전하게 할당하는 경우 out이 사용됩니다. 코틀린에서는 이 out 이라는 수식어를 Variance Annotation이라고 부릅니다.

👩‍🦰contravariance(반공변)

공변의 반대 개념으로, 공변을 보완하기 위해 나온 개념입니다. 공변과는 대조적으로 제네릭 인자가 소비자가 되는 경우에 반공변성을 부여합니다.

Java에서는 <? super E> , 코틀린에서는 in 을 통해서 반공변성을 부여합니다.

Kotlin의 예시를 하나 들어보겠습니다.

interface Comparable<in T> {
    operator fun compareTo(other: T): Int
}

fun demo(x: Comparable<Number>) {
    x.compareTo(1.0) 
    val y: Comparable<Double> = x
}

Type Number의 하위 Type은 Double입니다. 하지만 T가 in 이기 때문에 인수로 들어오는 Comparable<Number> 는 하위 타입이 됩니다. 따라서 x의 데이터를 Double로 형변환 한 후, y에게 x를 대입하여도 컴파일 에러가 발견되지 않게 됩니다.

The Existential Transformation: Consumer in, Producer out! :-) → T가 소비자면 in, T가 생산자면 out으로 이해하면 될 것입니다.

🏓Kotlin VS JAVA

근데 여기서 Kotlin과 Java와 차이점은 무엇일까요?

Kotlin에서는 interface(혹은 class)에 out 키워드를 붙여 공변성을 제공하고, 자바는void addAll(Collection<? extends E> items); E를 사용하는 메서드에 공변성을 제공합니다.

• Kotlin에서는 이 방식을 Declaration-Site Variance(선언 위치 변환)

• 자바에서는 이 방식을 Use-Site Variance(사용 위치 변환) 이라고 부릅니다.

뭐가 더 좋을까요? 라고 부른다면, 뻔하지만 Java의 상위 호환인 Kotlin입니다.

Kotlin에서는 클래스에서 out을 한번 선언하면 되지만, Java에서는 매번 붙여줘야 하기 때문에 불필요한 코드가 발생합니다. 물론 코틀린에서도 Use-Site Variance를 제공합니다.

참고 문서 https://kotlinlang.org/docs/generics.html#type-erasure

✅ 코틀린의 다른것이 궁금할땐 아래 링크 확인 https://velog.io/@ham2174

코틀린 기본 문법 중 프로퍼티에 대한 이해를 확실하게 하고, 설명할 수 있을 정도로 이해하기 위해 글을 작성하게 되었습니다.

🧴캡슐화

객체지향 프로그래밍에는 캡슐화라는 개념이 있습니다. 데이터와, 그 데이터를 처리하는 메소드를 묶어 클래스 안에 보호하는 것입니다. 이를 위해 내부 데이터는 private으로 접근할 수 없게 하고, public으로 선언된 메서드를 통해 접근했었습니다.

☕At Java

자바에서는 이를 구현하기 위의 아래 방식을 사용했었습니다.

class Person {
    private String name;

    Person() {

    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

객체의 상태를 나타내는 데이터를 Field, 객체가 하는 행동을 Method라고 하였습니다. 또한 캡슐화를 위해 getter와 setter 메서드를 작성하여 데이터에 접근하도록 하였습니다.

하지만 위 방식은 필드가 많아짐에 따라 getter와 setter의 보일러 플레이트 코드를 증가시켰습니다.

🙋‍♂️코틀린의 Property란?

• field + getter + setter == property

class Person {
    var name: String = ""
}

코틀린에서는, 다음과 같이 변수를 선언하기만 하여도 내부적으로 getter와 setter를 구현합니다. 이를 함께 불러 property라고 부릅니다.

public final class Person {
   @NotNull
   private String name = "";

   @NotNull
   public final String getName() {
      return this.name;
   }

   public final void setName(@NotNull String var1) {
      Intrinsics.checkNotNullParameter(var1, "<set-?>");
      this.name = var1;
   }
}

코틀린에서 작성된 Person를 디컴파일 해보면, 다음과 같은 자바 코드를 볼 수 있습니다.

🙋‍♂️getter와 setter

var <propertyName>[: <PropertyType>] [= <property_initializer>]
    [<getter>]
    [<setter>]

property를 선언하는 문법입니다. getter와 setter를 따로 선언하지 않아도, getter와 setter가 내장되어 있습니다.

class Person {
    var name: String = ""
        get() = field
        set(value){ field = value }
}

만약 이를 직접 구현한다면 이렇게 생겼습니다. field라는 식별자를 통해 데이터에 접근할 수 있고, 매개변수를 value 등으로 제공할 수 있습니다.

field 식별자는, backing field입니다. 적어도 하나 이상의 기본 접근자를 사용할 때 만들어집니다.

val isEmpty: Boolean
    get() = this.size == 0

이런 상황에서는 field가 만들어지지 않습니다.

또한 접근자를 커스텀 할 수도 있습니다.

get() 응용

class Person(val height: Int, val weight: Int) {
    val bmi: Int 
        get() = this.weight / (this.height * this.height)
}

area라는 변수는, width x height의 값을 가지고 있어야 합니다. 만약 코드를 이처럼 작성하게 된다면, area를 호출할 때 마다, width x height를 계산하여 호출하게 됩니다.

set() 응용

var date: String
    get() = this.toString()
    set(value) {
        dateToString(value)
    }

마찬가지로 setter에 setDataFromString이라는 어떠한 데이터를 가져와 String으로 Parsing하는 메서드를 통해 호출할 때 마다 할당할 수 있습니다.

private 접근자

class Person{
    private var cardNumber: String = "121-121-1"
        private get() = field
}

class Person{
    var cardNumber: String = "121-121-1"
        private set
}

위와 같이 접근자를 private으로 선언할 수도 있습니다.

• getter을 private으로 선언했다면, 변수도 private 해야합니다. 외부에서 참조하지 않고 내부에서 사용될 수 있습니다.
• setter를 private으로 선언했다면, 외부에서 값을 가져올 순 있지만, 할당할 수는 없게 됩니다.

참고문서 https://kotlinlang.org/docs/properties.html

클린 아키텍처로 프로젝트를 진행하면서 겪었던 많은 고민을 공유하기 위해 글을 작성하게 되었습니다. 늘 그랬듯 많은 관심과 지적 부탁드립니다.

안드로이드 앱 개발을 시작하던 초기에, 같이 프로젝트를 진행하면서 멘토였던 선배로부터 디자인 패턴과 함께 아키텍처라는 개념을 처음 접하게 되었습니다. 당시 RecyclerView조차 제대로 이해도 못하는 수준이었고, 모듈을 나눠서 관리하구나! 정도로 이해했습니다. 클린아키텍처의 ㅋ자도 몰랐던 거였죠..

클린 아키텍처에 대한 좋은 글들이 매우 많습니다. 안드로이드에서의 클린 아키텍처를 한마디로 말하자면 관심사의 분리라고 할 수 있습니다. 사실 한마디로 말하기에는 너무 크고 심오한 내용인 것 같습니다.

💁‍♂️Monolithic Clean Architecture

초기 안드로이드 개발을 시작할때 진행했던 프로젝트의 구조가 위 그림과 같았습니다. 기본적으로 주어지는 app 모듈 내에, domain, Data, Presentation 패키지로 나누었습니다. Domain Layer를 한번 살펴볼까요?

public class ConvenienceUseCase implements RetrofitOnSuccess {

    private ConvenienceMarkerRepository convenienceMarkerRepository;
    private ConvenienceFragment convenienceFragment;
    private ArrayList<Document> list = new ArrayList<>();

    public ConvenienceUseCase(ConvenienceFragment convenienceFragment){
        convenienceMarkerRepository = new ConvenienceMarkerRepository();
        this.convenienceFragment = convenienceFragment;
    }

    public void sendLocalName(String Category){ 

    ...

먼저 Repository를 멤버변수로 참조하고 있기에 객체 간 결합도가 강한 것을 확인할 수 있습니다. 또한 안드로이드 프레임워크에 의존성이 없어야 하고, Presentation에 대해 몰라야 하는데 Fragment를 알고 있습니다. 부분적인 코드 뿐 아니라, 전체적으로 보더라도 단일 모듈로 클린 아키텍처를 적용하게 되면서,** 클린 아키텍처의 약속이 잘 지켜지지 않고 있었습니다.**

💁‍♂️Multi Module Clean Architecture

최근 진행한 프로젝트에서는 위와 같은 구조를 설계했습니다. 먼저 Multi Module로 구성되어 있기 때문에, 각 모듈이 가지는 종속성을 구분할 수 있습니다. Clean Architecture을 기반으로 설계한 모듈 구조이므로, 아래의 의존성 관계를 가집니다. Presentation -> Domain <- Data Domain은 다른 레이어를 몰라야 합니다. 또한 안드로이드에 대한 종속성을 가지면 안됩니다.

Domain 단에 작성한 코드는 당장 다른 플랫폼으로 옮기더라도 사용 가능할 수 있을 정도여야 한다. 따라서 순수한 Java,Kotlin 언어로 작성되어야한다.

자,이제 여기서 우리는 Domain에 안드로이드 종속성을 부여하지 않기 위해 많은 고민을 하고, 얼마나 Layer를 나눌 것인가 고민합니다.

🤾‍♀️첫 번째 시련 - Paging3 구현

interface UserRepository {
    ...
    suspend fun getUser(query: Int): Flow<PagingData<UserModel>>
    ...
}

Domain/Repository에 있는 UserRepository 인터페이스 입니다. User의 행동 단위를 모아 인터페이스로 선언하게 되고, Data Layer에서는 이를 구현하여 네트워크 작업이나 DB 작업을 하게 됩니다.

💁‍♂️혹시 코드에서 이상한 점을 느끼셨나요? 맞습니다. Domain Layer에 안드로이드 라이브러리인 PagingData가 있습니다.

물론 Data단에서는 PagingData를 다루고 성공 실패에 대한 로직을 처리하여, Wrapper로 감싸서 전달할 수도 있습니다. 다만 그것은 네트워크 통신을 담당하는 Data Layer에 어울리지 않다고 생각했습니다. 테스트 종속성을 추가하거나, flow로 감싸서 전달하는 방법도 있으나, ViewModel단에서 성공 실패를 처리하기 위해 위 방법을 사용했습니다.

또한 이런 이야기를 들었습니다.

아키텍처는 결국 협업을 위해 존재하는 것이다. 타당한 이유가 있다면, 어느 정도 틀 안에서 같이 일하는 동료들과의 협업을 위해 어떠한 룰을 만들어 정하면 되는 것이다.

안드로이드의 특성상, 아키텍처를 통해 완전히 코드를 분리하는 것은 어렵다고 생각하였기에, 특수한 경우에는 의존성을 주입하기로 결정하였습니다.(ex hilt)

🤾‍♀️두 번째 시련 - Retrofit Response

한번이 어렵지,, 두번은 어렵지 않았습니다. SkyDoves에서 제공하는 Sandwich의 ApiResponse 를 사용하여 결과 콜백을 처리할 수 있게 하였습니다.

interface UserRepository {
    suspend fun login(loginModel: LoginModel): ApiResponse<AuthResponse>
}

loginUseCase(LoginModel(email, password.sha256())).suspendOnSuccess{
    ...
}

안드로이드 의존성이 아니며 Result class를 따로 만들지 않아도, 거의 모든 통상적인 경우를 처리할 수 있기에 충분히 도입할 만 하다고 생각하였습니다.

ApiResponse is an interface to construct standardized responses from Retrofit calls.

🤸‍♂️결론

클린 아키텍처는 관심사의 분리를 통해 테스트가 용이하게 하고, 유지보수가 용이할 수 있게 계층을 나누어 코드를 분리하는 것이라고 할 수 있습니다. 코드라는것이 개발자마다 다양하고, 생각하는 기준도 다르기에 각각 다르게 적용될 수밖에 없다고 생각합니다. 물론 _Uncle Bob_이 의도하는 클린아키텍처의 성격에서 크게 벗어나면 안되겠지만, 협업하는 공동체에서의 룰을 지키며 적절히 사용한다면 되는 것이 아닐까 생각합니다. 긴 글 읽어주셔서감사합니다

https://velog.io/@evergreen_tree/Android-MVVM-AAC-FireBase-Google-Logind 에서 이어집니다!

🤜Example

다음 예제는 FireBase를 통해 Google 로그인을 구현하는 예제입니다.

AAC와 MVVM을 이용해 구현해 보았습니다.

🏬Structure

간단하게 두 패키지로 구분하였습니다.

repository에는 Repository, ui에는 Activity와 ViewModel이 있습니다.

🌎Repository

class AuthRepository(
) {
    private val firebaseAuth = FirebaseAuth.getInstance()
    private val _userLiveData = MutableLiveData<FirebaseUser>()
    val userLiveData: LiveData<FirebaseUser>
        get() = _userLiveData

    fun getUser(idToken: String) {
        val credential = GoogleAuthProvider.getCredential(idToken, null)
        firebaseAuth.signInWithCredential(credential).addOnCompleteListener {
            if (it.isSuccessful) {
                _userLiveData.postValue(firebaseAuth.currentUser)
            } else {
                //실패처리
            }
        }
    }
}

먼저 Repository입니다. MVVM의 Model 부분을 담당하게 됩니다.

ViewModel에서 위 코드를 작성하고 처리하지 않는 이유는, 역시나 유지보수 때문입니다.

위 예제는 단순히 Firebase 로그인만을 구현하고 있지만, DB에서 다른 테이블을 조회할 수도 있고, Github API를 통해 어떤 데이터를 가져올 수도 있습니다. 그러한 단위들을 Repository로 구현하여 제공한다면 좀 더 효율적으로 코드를 관리할 수 있습니다.

LiveData

AAC에서 제공하는 라이브러리로, RxJava,와 유사하게 Observer 패턴을 통해 데이터를 구독하고 발행할 수 있습니다. (추후 Observer 패턴에 대해 포스팅 하겠습니다.)

Repository에서 LiveData 형태로 ViewModel에 제공함으로써, 추후 Activity가 데이터 변경을 관찰하여 View에 보여줄 수 있게 할 것입니다.

🚀ViewModel

class MainViewModel : ViewModel(){
    private var authRepository: AuthRepository = AuthRepository()
    private val _userLiveData = authRepository.userLiveData

    val userLiveData: LiveData<FirebaseUser>
        get() = _userLiveData


    fun getUser(idToken: String){
        authRepository.getUser(idToken)
    }
}

View는 ViewModel에 대해 알고 있기 때문에, getUser을 호출하여 데이터를 변경시킬 수 있습니다.

즉, View의 Event를 통해 ViewModel의 메소드를 실행시켜 주면, Repository를 알고있는 ViewModel은 데이터 변경을 요청한다는 의미입니다.

fun getUser(idToken: String) {
        ...
        firebaseAuth.signInWithCredential(credential).addOnCompleteListener {
            if (it.isSuccessful) {
                _userLiveData.postValue(firebaseAuth.currentUser)
            } 
                ...
        }
    }

ViewModel에서 데이터 변경을 요청하였고, 성공시 liveData를 currentUser로 변경합니다.

Activity는 이 LiveData를 ViewModel을 통해 관찰하고 있기 때문에, 이 변경을 감지하게 됩니다.

🚆Activity

class MainActivity : AppCompatActivity() {
    private lateinit var getResult: ActivityResultLauncher<Intent>
    private val viewModel: MainViewModel by viewModels()
    private val binding: ActivityMainBinding by lazy {
        ActivityMainBinding.inflate(layoutInflater)
    }
    private lateinit var googleSignInClient: GoogleSignInClient

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(binding.root)
        setGoogleLogin()
        viewModel.userLiveData.observe(this) {
            binding.textView.text = it.displayName
        }
        binding.loginButton.setOnClickListener {
            login()
        }
        getResult = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
            if (it.resultCode == Activity.RESULT_OK) {
                val task = GoogleSignIn.getSignedInAccountFromIntent(it.data)
                try {
                    val account = task.getResult(ApiException::class.java)!!
                    viewModel.getUser(account.idToken!!)
                    Toast.makeText(this, "로그인 성공", Toast.LENGTH_SHORT)
                        .show()

                } catch (e: ApiException) {
                    Toast.makeText(this, e.localizedMessage, Toast.LENGTH_SHORT).show()
                }
            }
        }
    }

    private fun login() {
        getResult.launch(googleSignInClient.signInIntent)
    }

    private fun setGoogleLogin() {
        val gso = GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
            .requestIdToken(BuildConfig.WEB_CLIENT_ID)
            .requestEmail()
            .build()
        googleSignInClient = GoogleSignIn.getClient(this, gso)
    }
}

액티비티 코드입니다. 중요한 부분만 짚고 넘어가겠습니다.

private val viewModel: MainViewModel by viewModels()

여러가지 방법이 있을 수 있겠지만, Android KTX 라이브러리를 통해 뷰모델을 위임하였습니다.

여기서 뷰모델을 생성하게 되는데, 여기서 중요한 부분이 있습니다.

ViewModel은 activity, Fragment 등의 Context를 참조하는 클래스를 가지고 있으면 안됩니다.

https://velog.io/@evergreen_tree/안드로이드-액티비티-생명주기 먼저 보고 가시면 좋습니다.

ViewModel의 생명주기는 View의 생명주기와 다릅니다. 기기의 화면이 회전되어 액티비티가 onDestroy를 호출할 때에도 ViewModel은 살아있습니다. 잘못되면 Memory Leak(필요하지 않은 메모리를 계속 점유하고 있는 현상)이 발생할 수 있습니다.

따라서 intent 같은 activity를 참조하는 메서드도 ViewModel에서 실행하지 않았습니다.

하지만 여기서 또 문제가 생깁니다. MVVM을 지키려면 intent 결과 메서드도 ViewModel에 작성해야 하는 거 아니야?

🤷‍♂️관심사 분리의 선?

override fun onCreate(savedInstanceState: Bundle?) {
        ...
        binding.loginButton.setOnClickListener {
            login()
        }
        getResult = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
            if (it.resultCode == Activity.RESULT_OK) {
                val task = GoogleSignIn.getSignedInAccountFromIntent(it.data)
                try {
                    val account = task.getResult(ApiException::class.java)!!
                    viewModel.getUser(account.idToken!!)
                    Toast.makeText(this, "로그인 성공", Toast.LENGTH_SHORT)
                        .show()

                } catch (e: ApiException) {
                    Toast.makeText(this, e.localizedMessage, Toast.LENGTH_SHORT).show()
                }
            }
        }
    }
...
private fun login() {
        getResult.launch(googleSignInClient.signInIntent)
}

필자도 저 위의 짧은 코드를 작성하기 위해 많은 고민을 했습니다.

Google 로그인은 intent를 통해 유저의 토큰을 가져오게 되는데, 이는 분명히 UI와 관련되지 않은 로직일 것이고 ViewModel에 들어가야 한다고 생각했습니다.

그래서 ViewModel을 생성할 때, interface를 만들어 제공하고 Callback형식으로 사용하는 것은 어떤가 고민을 하였지만,, 실력 좋은 현업자의 이야기도 들어보고, 여러 사람들의 코드를 확인해본 결과 intent 로직은 Activity에서 처리하는 것이 좋다고 생각하였습니다.

디자인 패턴에 너무 얽매이는 것은 좋지 않다. 디자인패턴, 아키텍처는 결국 협업을 위해 존재하는 것이다. 물론 디자인 패턴을 지키지 말라는 것이 아니다. 타당한 이유가 있다면, 어느 정도 틀 안에서 같이 일하는 동료들과의 협업을 위해 어떠한 룰을 만들어 정하면 되는 것이다.

Data Obersving

override fun onCreate(savedInstanceState: Bundle?) {
        ...
        viewModel.userLiveData.observe(this) {
            binding.textView.text = it.displayName
        }
       ...

위 코드가 Activity에서 뷰모델의 데이터를 관찰하고 있는 부분입니다.

button onclick → intent → viewModel.getUser() → repository.getUser() 을 통해 데이터가 변경되면,

이렇게 관찰하고 있다가 바뀐 데이터를 View에 보여주게 됩니다.

긴 글 읽어주셔서 감사합니다.

github : https://github.com/EvergreenTree97/MVVM-LiveData-Firebase-Example

참고 자료 https://blog.gangnamunni.com/post/aac_mvvm/

구글 로그인을 구현해볼 겸 안드로이드 Architecture Components를 활용해 mvvm과 observer pattern을 이해하기 위해 예제를 만들게 되었습니다. 생각보다 mvvm의 View와 Logic 분리에 고민을 많이 하게 되는 시간이었습니다. 조언, 반박 언제든 환영입니다!

👨‍🦳서론

위 이미지는 필자가 처음 안드로이드 개발을 시작했을 때의 패키지 구조입니다.

Model, Network, Activity 등등의 코드가 아주 자유분방하게 섞여있습니다.

또한 내부 코드도 마찬가지로 다양하게 혼재하고 있습니다.

앱의 규모가 작고, 혼자서 진행하는 프로젝트이면 그렇게 큰 문제가 일어나지는 않을 것입니다.

하지만, 앱의 규모가 커지면 커질수록, Activity와 Fragment의 코드는 방대해질 것이며, app 패키지 내에서 원하는 파일을 찾기 위한 비용이 만만치 않을 것입니다.

먼저 소개할 AAC라는 개념은 위 문제를 포함하여 앱을 개발하면서 만날 수 있는 문제들을 해결하기 위해 라이브러리를 제공합니다.

🤷‍♂️Android Architecture Components(AAC)

→ 안드로이드 앱을 개발하면서 자주 만날 수 있는 문제들을 쉽게 해결할 수 있는 라이브러리들의 모음

• 테스트와 유지관리가 쉬운 앱을 디자인하도록 돕는 라이브러리 모음
• ViewModel은 앱 회전시 제거되지 않는 UI 관련 데이터를 저장
• LiveData를 사용하여 모델 변경되면 뷰에 알리는 데이터 개체를 빌드
• ~~Room은 SQLite 개체 매핑 라이브러리 RxJava, Flowable, LiveData Observable을 반환~~

그래서 왜 사용하는가?

개발자의 평생 과제인 유지보수를 위해서 ,정확히는 관심사의 분리를 위해서 입니다.

View에 모든 코드를 관리하는 것에서 생기는 문제를 해결하기 위해 AAC인 LiveData, ViewModel을 사용하면서 아래의 아키텍처를 적용합니다. 위의 다이어그램은 구글에서 권장하는 아키텍처를 다이어그램으로 표현한 것입니다.

1. View(Activity/Fragment)는 ViewModel의 LiveData를 구독하고 있습니다. 따라서 ViewModel의 데이터가 변경되면 Activity에 보여지게 됩니다.
2. ViewModel은 LiveData를 가지고 있으며, 로컬의 DB, 혹은 Network 통신을 통해 데이터를 가져와 발행할 수 있습니다.

한줄 요약하면, Repository로부터 ViewModel에서 데이터를 관리하고 View는 이를 관찰하고 있다는 것입니다. 이제 여기서 AAC를 적용하여 MVVM 패턴을 적용할 수 있습니다.

💁‍♂️MVVM 패턴

→ UI와 Logic을 분리할 수 있는 디자인 패턴입니다. 구조는 아래 이미지와 같습니다.

Model

• 데이터 모델, 비즈니스 로직, 데이터를 포함합니다
• 보통 Repository(DB,Network)에서 데이터를 반환합니다.

View

• Activity, Fragment등, 뷰의 역할을 담당합니다.
• 비즈니스 로직은 배제하지만, UI 관련 로직, intent는 수행할 수 있습니다.

ViewModel

• View에서 보여줘야 하는 데이터와, 명령을 담고 있습니다.
• 보통 View가 Viewmodel의 데이터를 바라보고 있는 "Observer Pattern"의 형태로 사용되기 때문에 ViewModel에서 모델의 데이터를 변경하면 이를 감지하고 변경된 데이터를 View가 보여줍니다.

여기서 AAC ViewModel과 MVVM의 ViewModel은 다릅니다. AAC ViewModel : UI 데이터를 유지, 관리하기 위해 AAC에서 제공하는 클래스 MVVM ViewModel : MVVM 아키텍처에서의 한 역할, View의 데이터를 관리해주고 바인딩 해주는 역할

의존성 관계

View → ViewModel → Repository

View는 ViewModel을 알지만, Repository는 ViewModel을 모릅니다. (import 하고 있지 않다는 뜻입니다.)

FireBase와 GoogleLogin 관련된 문서는 공식 문서만큼 잘 나와있는 곳이 없는 것 같습니다.

여기를 참고해주세요!

다음 포스팅에서 예제를 통해 이해해 보겠습니다. https://velog.io/@evergreen_tree/Android-MVVM-AAC-FireBase-Google-Login-2

https://velog.io/@evergreen_tree/AndroidMVI-2.-MVI%EC%9D%98-Purecycle 에서 이어집니다.

🚶‍♂️SideEffect

항상 모든 흐름이 Pure cycle로 이루어 질 순 없습니다.

앱은 외부세계의 상태를 변화시켜야 하는 상황이 발생하기도 하고, 외부 세계로부터 상태가 변화될 수 있습니다.

예를들어, Composable 함수 같은 경우, compose 내의 State가 변경되면 이를 통해 재 호출 되어 Recomposition 되는 형태로만 존재해야 합니다.

@Composable
fun ExampleButton{
    SideEffect{
        systemUiController.setStatusBarColor(
            color = BackgroundColor
        )
    }
}

하지만 위 코드처럼, systemUiController의 상태를 변경시켜야 하는, 즉 SideEffect를 발생시켜야 하는 상황에 직면하기도 합니다.

SideEffect()는, Composition이 성공적으로 완료되었을 때 부수 효과를 예약하는 함수로 Compose에서 부수 효과를 처리하기 위한 방법 중 하나입니다.

Compose 얘기는 여기하지 하고, 안드로이드의 Orbit FrameWork 이용하여 MVI의 SideEffect Cycle을 구현해 보겠습니다.

👨‍💼Side effect Cycle

SideEffect Cycle은 기존 Pure Cycle에 SideEffect를 추가한 것입니다. intent()를 사용하여 새로운 상태를 생성함과 동시에 부수 효과를 실행하고, 인텐트로 결과를 내보내거나 아무 일도 일어나지 않습니다.

버튼을 클릭했을 때 토스트 메시지를 출력하는 간단한 앱을 MVI + Compose로 만들어 보겠습니다.

SideEffect 정의

data class CalculatorState (
    val total: Int = 0
)

sealed class CalculatorSideEffect{
    data class Toast(val text: String): CalculatorSideEffect()
}

• SideEffect에 대한 클래스를 생성합니다.

함수형 프로그래밍인 자바스크립트에서도, Side Effect는 존재합니다. 함수가 일관된 결과를 보장하지 못하거나, 함수 외부 어디든지 조금이라도 영향을 주는 경우에 발생하게 됩니다.

SideEffect Post

class CalculatorViewModel: ViewModel(), ContainerHost<CalculatorState, CalculatorSideEffect> {

    override val container =container<CalculatorState,CalculatorSideEffect>(CalculatorState())

    fun add(number :Int) = intent{//intent - 앱의 상태를 변화시키려는 의도
        postSideEffect(CalculatorSideEffect.Toast("Adding $number to ${state.total}!"))
        reduce{
                 state.copy(total = state.total + number)
        }
    }
}

• ViewModel 에서 State와 SideEffect를 가지고 container를 재정의합니다.

• add라는 메소드를 intent에 담고 Toast라는 SideEffect에 Toast에 들어갈 메시지를 담아 SideEffect를 보냅니다.

• 연산된 결과를 reduce를 통해 새로운 state를 만들어 내는 과정은 Pure Cycle과 같습니다. 단지 postSideEffect가 추가 되었을 뿐입니다.

Launch SideEffect

@Composable
fun TestPage(
    viewModel: CalculatorViewModel,
)

...

LaunchedEffect(viewModel){
viewModel.container.sideEffectFlow.collect{
when(it){
            is CalculatorSideEffect.Toast -> Toast.makeText(context,it.text, Toast.LENGTH_SHORT).show()
        }
    }
}
...

• Composable 함수에서 LaunchedEffect 블럭 안에서, SideEffect를 수집하고, Toast를 실행하면 끝입니다.

✍MVI의 장단점

장점

• 앱의 상태가 하나뿐이기 때문에, 상태 충돌이 없음
• 데이터의 흐름이 정해져 있어 흐름을 이해하고 관리하기 쉬움
• 각각 값이 불변하기 때문에, 스레드 안정성을 갖는다.

단점

• 러닝커브가 높음 (필자도 이해하느라 어려웠습니다.)
• 위의 앱에서 봤듯이, 간단한 앱이라도 Intent와 Model을 가져야 함
• 작은 변경도 Intent를 거쳐야함
• Model Update를 위해 매번 새로운 인스턴스를 생성해야 해서, 너무 많은 객체가 만들어지면 GC가 빈번하게 작동될 수 있음

🙋‍♂️이상으로 MVI 시리즈를 마치겠습니다. 감사합니다.

참고 자료 https://sungbin.land/아직도-mvvm-이젠-mvi-시대-319990c7d60 https://medium.com/@kimdohun0104/mvi-패턴에-대한-고찰-이유와-방법-그리고-한계-767cc9973c98 https://dev.to/kaleidot725/implementaing-jetpack-compose-orbit-mvi-3gea

https://velog.io/@evergreen_tree/Android-MVI-%ED%8C%A8%ED%84%B4 에서 이어집니다.

✌Pure Cycle과 Side effect Cycle

MVI는 순수 함수로 이루어진 Pure Cycle과, 부수효과가 포함되어있는 SideEffct Cycle로 표현할 수 있습니다.

이번 포스팅에서는, https://orbit-mvi.org/ MVI 프레임워크 중 하나인, orbit을 사용해 MVI의 Pure cycle에 대해 이해하겠습니다.

순수 함수와 부수 효과에 대해 들어보신 적이 있나요❓

---

함수형 프로그래밍 : 부수 효과를 없애고 순수 함수를 만들어 모듈화 수준을 높이는 프로그래밍 패러다임

• 부수 효과 : 외부의 상태를 변경하는 것, 함수로 들어온 인자의 상태를 직접 변경하는 것
• 순수 함수 : 부수효과가 없는 함수 즉, 어떤 함수에 동일한 인자를 주었을 때 항상 같은 값을 리턴하는 함수

👰Pure Cycle

순수 함수는 어떤 함수에 동일한 인자를 주었을 때 항상 같은 값을 리턴하는 함수입니다.

Pure cycle은 순수 함수와 동일한 맥락입니다

_Pure cycle_은 intent(event) == state,을 만족하는 사이클입니다. 즉 어떠한 의도로 인해 발생하는 결과는 항상 “상태” 입니다.

버튼을 누르면 아래 숫자가 증가하는 프로그램을 Compose와 MVI 형식으로 아주 간단하게 만들어 보았습니다.

intent()를 통해, add(number: Int)이벤트를 발생 시켜서 기존 count 값에 number을 더해 새로운 상태를 생성하는 예제를 살펴보겠습니다.

의존성 추가

implementation("org.orbit-mvi:orbit-viewmodel:4.3.2")
testImplementation("org.orbit-mvi:orbit-test:4.3.2")

→ 먼저 orbit 의존성을 추가합니다. 왜 Framework를 이용해야 하는지는 이전 글(https://velog.io/@evergreen_tree/Android-MVI-%ED%8C%A8%ED%84%B4)에 나와있습니다.

Model 생성

data class CalculatorState (
    val total: Int = 0
)

→ View에 렌더링 할 값인 total 을 가지는 Model(State)을 생성합니다.

ViewModel 생성 및 intent 정의

class CalculatorViewModel: ViewModel(), ContainerHost<CalculatorState, CalculatorSideEffect> {

    override val container = container<CalculatorState,CalculatorSideEffect>(CalculatorState())

    fun add(number :Int) = intent{ 
        reduce{
            state.copy(total = state.total + number)
        }
    }
}

• ViewModel 에서 State와, SideEffect를 가지고 container를 재정의합니다. container에 선언에는 State와 SideEffect를 명시해 줘야 하는데, 일단은 Pure cycle에 대해서만 설명할 것이므로 임의로 넣어놨습니다.

• add라는 메소드를 intent에 담고 연산된 결과를 reduce를 통해 새로운 state를 만들어 냅니다.

• reduce는 순수 함수로, 그저 새로운 state를 만들어 냅니다.

Rendering

@Composable
fun TestPage(
    viewModel: CalculatorViewModel,
) {
    val state by viewModel.container.stateFlow.collectAsState()
        Column{
                Button(onClick ={viewModel.add(1)}){
                Text("1이 증가하는 버튼")
    }
      Text("${state.total}")
}

→ 버튼의 이벤트로 viewModel.add() 를 전달하게 되면 ViewModel에서 Intent로 감싸져 새로운 상태를 생성하게 됩니다.

val state by viewModel.container.stateFlow.collectAsState()

view는 상태를 관찰하고 있기 때문에, Recomposition이 발생하여 새로운 상태를 렌더링 하게 됩니다.

이처럼 pure cycle은 상태 관리에서 가장 중요한 역할을 하고, 개발자의 실수를 줄여줍니다. 예상 가능한 값을 반환하기 때문에 테스트 코드를 작성하기에 용이합니다

👉다음 포스팅에서는 SideEffect Cycle 에 대해서 알아보겠습니다.

https://sungbin.land/아직도-mvvm-이젠-mvi-시대-319990c7d60 https://medium.com/@kimdohun0104/mvi-패턴에-대한-고찰-이유와-방법-그리고-한계-767cc9973c98 https://dev.to/kaleidot725/implementaing-jetpack-compose-orbit-mvi-3gea

TDD에 대해 공부하면서, 테스트 코드 예시를 작성하면서 이해하기 전에, 사용하는 디자인 패턴에 대해 이해하는 것이 테스트 코드 작성에 도움을 줄 수 있을 것 같아, 이번 프로젝트에서 사용할 MVI 패턴에 대해 알아보려고 합니다.

❓디자인패턴, MVC, MVP, MVVM

디자인 패턴은, 개발하면서 생기는 공통적인 문제를 해결하기 위한 솔루션 입니다.

mvc, mvp, mvvm 같은 패턴들은 관심사의 분리를 통해 테스트 코드의 작성을 용이하게 해주는 등, 대규모 개발에 있어서 필수 불가결한 요소가 되었습니다.

mvc 패턴의 View와 Model 사이의 높은 결합도는 mvp, mvvm 패턴을 파생시켰고, 데이터와 뷰를 분리함으로써 얻는 장점으로 인해 현재는 많은 프로젝트에 mvp, mvvm 패턴을 사용하고 있습니다.

하지만, 이들도 마냥 장점만 있는 것은 아니었습니다.

mvp, mvvm 패턴을 적용하면서 직면하는 문제로 두 가지가 발생하였습니다

🤦‍♀️상태 문제

• 안드로이드는 어떻게 보면 상태의 집합입니다. 화면에 나타나는 모든 정보나, 버튼 활성화 등 상태들로 구성되어 있습니다.
• 상태들을 관리하기 힘들어지고, 의도하지 않는 방향으로 제어가 된다면 상태 문제가 됩니다. 상태 문제의 좋은 예시로, 로그인이 실패했을 때 지속적으로 다음 화면이 보여 지는 상황이 발생합니다.

🤦‍♂️부수 효과

• 네트워크 통신, 데이터베이스 접근 등의 부수 효과들로 인해 발생합니다.
• 다이얼로그, 토스트 메시지, 액티비티의 이동도 이에 포함됩니다.
• 여러 비동기 작업들이 섞여서 어떤 결과를 얻을 지 예상할 수 없고 이에 따라 상태변화에 어려움을 겪습니다.

위 문제들을 MVI에서 어떻게 풀어나가는지 확인해 보면서, MVI에 대해 알아보겠습니다.

🔥MVI

MVI는 Model, View, Intent로 이루어져 있으며, 데이터베이스, 네트워크 통신등의 작업을 진행하기 위해 SideEffect를 포함합니다.

• 사용자 또는 시스템의 Action을 포함하는 Intent가 발생합니다.
• Intent를 통해 Model이 reducing되고, Model을 Observing 하고 있던 View는 Rendering을 통해 View를 업데이트 합니다.
  

View

• Activity나 Fragment, 즉 하나 이상의 View

Model

• 앱의 단일 상태
• 뷰가 화면에 렌더링 해야 하는 것들을 명시해주는 응답으로 다음과 같은 것들이 포함 될 수 있습니다.
  • 프로그레스 진행률
  • 서버로부터 받은 데이터 목록
  • 예외
• 다른 레이어와의 단방향 레이어 흐름을 위해 변경 불가 해야합니다.

Intent

• 사용자 또는 앱 내의 상태를 바꾸려는 의도
• 모델은 인텐트를 통해서, 새로운 상태로 변화할 수 있다.
  • MVI의 단점 중 하나로, 가벼운 변경 사항도 이를 적용해야 합니다.

이유는 https://appmattus.medium.com/top-android-mvi-libraries-in-2021-de1afe890f27 에서 확인할 수 있습니다. 위 링크에서, 왜 MVI 라이브러리를 사용하는지, MVI 프레임워크들의 종류들과 평가에 대해서 확인할 수 있습니다.

예고편

MVI는 순수 함수로 이루어진 Pure cycle과, 부수효과가 포함되어있는 Side effct cycle로 표현할 수 있습니다.

다음 포스팅에서는, https://orbit-mvi.org/ MVI 프레임워크 중 하나인, orbit을 사용해 MVI의 Pure cycle에 대해 이해하겠습니다.

순수 함수와 부수 효과에 대해 들어보신 적이 있나요❓

---

함수형 프로그래밍 : 부수 효과를 없애고 순수 함수를 만들어 모듈화 수준을 높이는 프로그래밍 패러다임

• 부수 효과 : 외부의 상태를 변경하는 것, 함수로 들어온 인자의 상태를 직접 변경하는 것
• 순수 함수 : 부수효과가 없는 함수 즉, 어떤 함수에 동일한 인자를 주었을 때 항상 같은 값을 리턴하는 함수

참고 문서 https://sungbin.land/아직도-mvvm-이젠-mvi-시대-319990c7d60 https://medium.com/@kimdohun0104/mvi-패턴에-대한-고찰-이유와-방법-그리고-한계-767cc9973c98 https://dev.to/kaleidot725/implementaing-jetpack-compose-orbit-mvi-3gea https://yoon-dailylife.tistory.com/117