Machine_웅_Note

https://sungbin.land/%EC%95%84%EC%A7%81%EB%8F%84-mvvm-%EC%9D%B4%EC%A0%A0-mvi-%EC%8B%9C%EB%8C%80-319990c7d60 아직도 MVVM? 이젠 MVI 시대! Orbit을 이용한 MVI 디자인패턴 알아보기 sungbin.land * intent가 android intent가 아니었다... ( 그랬군.... ) * Redux의 개념을 사용한다.

Hilt 란? Dagger API를 Android에서 설치하고 설정하고, 테스트 하는 과정을 쉽게 해주는 오픈소스 래퍼 라이브러리 주목적 - 테스트를 위한 의존성 주입 설정 기능 추가 - Android 앱에서 반복적으로 가장 많이 사용되는 보일러플레이트 코드를 제거 => Dagger 와 Hilt 비교 ! => 위의 그림의 형태로 구조가 자동적으로 만들어져 있다고 보면 된다. => HiltAndroidApp 만 넣는것 만으로 다른 초기화가 필요 없음 => AndroidEntryPoint 만으로 자동으로 필드주입, 인젝션이 다른곳에 있다면 자동으로 들어감 => 모듈의 설정이 약간 바뀌었다, 컴포넌트 지정 필요 x 어디에 인스톨되는지 표기 필요 

* 컴파일 시점에서 대거를 지원하는 툴들이 지원되고 있다. => 컴포트넌트를 구현하게되면, 컴포넌트를 토대로 해서 인젝터라는게 생성이 된다. => 인젝트 매서드를 구현해줘야한다 1. Application 단에서 전역적으로 선언. => public 으로 해서 DaggerApplicationComponent.create() => 앞서 ApplicationComponent를 만들면 자동으로 Dagger라는 접두어가 달린 클래스가 자동으로 생성 된다. 2. Activity에서 super.onCreate 위에 Dagger 인스턴스를 만들어준다. (applicationContext as MyApplication).appComponent.inject(this) * 이걸로 기본 세팅은 끝났다. 주입될 대상이 될 클래스..

- 이제는 안드로이드 개발에 있어서 필수적인 부분으로 자리 잡았다. => 일관적으로 객체(의존성)를 만드는 방법이 정해진곳이 따로 있고, 만들어서 필요한 곳에 전달한다. 왜 의존성 주입을 사용하지 ?? => 객체(의존성)을 밖에서 만들어서 주입을 하게 하면, 코드 재사용상이 높아진다. => 클라이언트 코드의 변경 없이도 손쉽게 다른 형태의 DataSource 인스턴스를 만들 수 있다. => 객체의 생성 과정이 바뀌더라도 클라이언트 코드에 영향을 주지 않는다. => 클라이언트는 interface로만 객체를 알고 있으면 되므로, 보다 나은 설계가 가능하다. - 추상화, 멀티모듈에서 모듈별 의존성을 떼어내는 데에 매우 유용 => 코드를 테스트 가능하게 한다 ( 객체의 생성방..

=> 코틀린에서 invoke 해서 사용할 정도의 수준인 경우 . => 코틀린에서는 값객체를 이용한 패턴을위해 inline으로 지원해 준다. => 레포지토리란 ? 저장방식이 어떻게 되는지를 감쳐주는 역할을 한다. => 데이터스토어는 기본적으로 인터널 클래스로 만들어서 다른곳에서 노출되지 않게 만들어 준다. * Data Store는 기존의 쉐어드 프리퍼런스의 문제가 많아 대체해서 사용하기 위해서사용 하자 ( 디바이스마다 다르게 동작하는 문제라거나, 비동기가 아니라 동기적으로 동작을 한다거나 하는 문제 등 ) * 로컬을 사용하는경우 어느정도 데이터 용량이 커지기 전까지는 사용할만한다. => 할 수 있는한 가장 낮은 레벨에서 처리하는게 좋다. => 개발자가 아닌 기획자 등과 논의..

1. 도메인 주도 설계 ( DDD ) 개론 - 주된 철학 , 원리 그리고 전략적 설계 => 그프로젝트에서 의미있는 용어를 만들고 정하는 것. => 기술적인 용어 x , 도메인 용어 x , 상호 합의된 언어 => 도메인 모델을 만드는데 핵심은 사용자 스토리 이다.

강의를 통틀어서 도메인/데이터 계층 부분이 제일 중요하다고 할 수 있다.. 집중.. 1. 앱 아키텍처의 미드필더라고 할 수 있는, 도메인 계층을 어떻게 설계 할 것인가. 사고실험 ) 2번 - 보통 이렇게 시작을 한다. ( 문제는 - 앱에 구현이 어떻게 될까에 대해서는 도움이 안된다. ) 3번의 문제 - 디자인이 계속 바뀔 수 밖에 없기때문에 비효율. 4번 - 기술검토 부분 ( 재활용 x ) => 보통의 경우 데이터 설계로 시작하는 경우가 대부분인데 이렇게 되면, 앱의 경우에는 어떻게 구현을 해야할지에 대해서는 알 수 없고, 도움이 되지 않는다. Bast Case => UI와 DB 연결을 제외하고도 핵심시나리오를 구현 할 수 있기 때문에 나중에 재활용이 가능하다. => 테스트를 먼저 진행하면서 할수 있다...

* 앱 전체의 state를 하나의 머신으로 처리를 하면 어떨까..? I : (intent) 예시 ) API 요청 -> 미들 웨어 -> API 호출 -> store 저장 -> 리듀서에서 가공 -> UI 적용 => 전체 흐름에 대한 그림을 이해해는데 어려울수 있음. => 각각의 코드들이 여러군데 흩어져있임 => 로직의 복잡도가 높아지거나, 미리 염두해서 계획해야한다. => 오히려 MVVM 에서 MVI 에서 복잡하게 처리해야 할 것들을 간단하게 처리할수 있다.

https://developer.android.com/topic/architecture 앱 아키텍처 가이드 | Android 개발자 | Android Developers 앱 아키텍처 가이드 이 가이드에는 고품질의 강력한 앱을 빌드하기 위한 권장사항 및 권장 아키텍처가 포함되어 있습니다. 참고: 이 페이지는 Android 프레임워크 기본을 잘 아는 사용자를 대상으 developer.android.com 여기에 계속 MVVM 에 관련된 내용이 계속해서 다뤄질 예정이다. * 상위객체 state Holder * view는 구독을 해서 이벤트를 통보받는 형태 ( 콜백, Observable 같은거.. ) => 만약에없다면 UIstate data class 를 만들어서 관리하는게 일반적이다. =>state holde..

UI 계층 ( 프레젠테이션 계층 ) 1. MVx 의 대원칙 => Model : 단순하게 데이터 영역이 아니라. UI 로직 외에 도메인 계층에 가까운 비지니스 로직을 포함한다고 봐야 한다. => configuration change 에대해서 처리할 수 있는 체계도 필요하다 2.MVC => android robolectric unit test 어느정도 테스트를 할 수는 있지만 한계가 있다. 해결방법 1) 뷰의 분화 ( 복잡도를 낮출 수 있음 ) 2) 뷰 컨트롤러를 만든다 => 프로세스가 종료되는 것도 염두 해야한다. ( 전화가와서 백그라운드로 전환, 메모리부족, 타입아웃에러 등 ) - saveState 처리할 수 있는 로직을 만들어야 함. => 엑티비티는 컨트롤러로 아주 제한적인 일만 해야한다. ( 예를 들..