Machine_웅_Note

유연한 레이아웃 만들기 ConstraintLayout 사용 다양한 화면 크기에 맞게 반응형 레이아웃을 만드는 가장 좋은 방법은 ConstraintLayout을 UI의 기본 레이아웃으로 사용하는 것입니다. ConstraintLayout을 사용하면 레이아웃에 있는 다른 뷰와의 공간적 관계에 따라 각 뷰의 위치와 크기를 지정할 수 있습니다. 이러한 방식으로 화면 크기가 변경될 때 모든 뷰가 함께 이동하고 확장할 수 있습니다. ConstraintLayout으로 모든 레이아웃 시나리오를 해결할 수는 없지만 어떤 레이아웃을 사용하든 하드 코딩 레이아웃 크기를 사용해서는 안 됩니다 (특히 동적으로 로드되는 목록에는 RecyclerView를 사용해야 함) https://developer.android.com/train..

* 컴파일 시점에서 대거를 지원하는 툴들이 지원되고 있다. => 컴포트넌트를 구현하게되면, 컴포넌트를 토대로 해서 인젝터라는게 생성이 된다. => 인젝트 매서드를 구현해줘야한다 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 처리할 수 있는 로직을 만들어야 함. => 엑티비티는 컨트롤러로 아주 제한적인 일만 해야한다. ( 예를 들..

예시 => isVaild 를 테스트 하게되면 isVaild는 프라이빗이기 때문에,, public으로 바꾸지 않아야 한다. => isVaild 정책의 변경에 따라 저 코드는 문제가 될수 있다. => set , process , assert 하는 구조는 앞으로도 계속 되는 구조임으로 기억하자. => 트렌젝션을 직접 만들어서 처리를 해보는 것이 좋다. => 테스트를 통해서 나올 결과를 가지고 판단을 해야하지, 나온 결과를 또다른 조작을 통해서 판단 검증해서는 안된다. => 위에 예시에서는 createUser로 만든 계정을 아래서 db에 넣음으로써 검증을 하는 또다른 조작을 하고 있다. 완결성 : 테스트는 전부를 가지고 있어야한다, 완성되어있어야 한다. => 그 테스트케이스 안에는 테스트하고자 하는 것을 정확일..