* TDD란? (Test-Driven-Development)테스트 코드를 먼저 작성 후 작성된 테스트코드에 맞춰 제품 코드를 작성하는 프로그래밍 방법 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나TDD는 단순한 설계를 장려하고 자신감을 불어 넣어 준다* TDD의 창시자 켄트 벡은 "프로그램을 작성하기 전에 테스트를 먼저 하라" 라고 했다. * 위 과정이 기존 개발 과정, 아래 과정이 TDD TDD가 좋은 이유내 코드 및 개선한/개선할 코드에 자신감을 준다.코드를 이래저래 개선해도 '테스트 코드가 지켜줄거야!' 라는 자신감이 붙는다.따라서 개선에 대해 두려움이 없어지고, '일단 바꿔보자'라는 생각을 할 수 있게 된다.즉, 망설임이 없어진다. (= 개발에 속도가 붙는다.)기능 명세 및 테스..
val result = remember(state1, state2) { calculation(state1, state2) }val result1 = remember { derivedStateOf { calculation(state1, state2) } }derivedStateOf* 특정 상태가 계산되거나 다른 상태 개체에서 파생되는 경우 derivedStateOf를 사용한다. derivedStateOf를 사용하면 계산에 사용된 상태 중 하나가 변경될 때마다 계산이 실행된다. * TextField에 영어알파벳을 입력하면 true로 바뀌며, Submit버튼이 활성화 되는 코드이다. * 처음에 u를 입력했을때 버튼이 활성화 된 이후로도 나머지 usernamed을 치는동안 불필요하게 버튼에 state를 보..
* 기본적으로 Composable 함수 안에서는 기존의 방식으로 코루틴을 사용할 수 없다. 대신 Compose에서도 코루틴을 구현할 수 있도록 Effect API라는 것을 제공한다.* 안드로이드에서는 Compose 함수 외부에서 앱 상태가 변화하는 것을 부수 효과(Side Effect)라고 한다. 그리고 공식문서에는 이러한 부수 효과를 일으키는 요소가 Compose 함수 내에 존재해서는 안된다고 정의하고 있다.컴포저블의 수명 주기 및 속성(예: 예측할 수 없는 리컴포지션 또는 다른 순서로 컴포저블의 리컴포지션 실행, 삭제할 수 있는 리컴포지션)으로 인해 컴포저블에는 부수 효과가 없는 것이 좋습니다. * Compose 구성요소들은 언제 리컴포지션이 발생할 지 모르기 때문에 Compose 함수에서 부수..
* Navigation은 크게 3가지로 나뉜다. (NavController, NavGraph, NavHost)NavController: 대상(즉, 앱의 화면) 간 이동을 담당한다. NavGraph: 이동할 컴포저블 대상을 매핑을 담당NavHost: NavGraph의 현재 대상을 표시하는 컨테이너 역할을 하는 컴포저블 1. NavController* NavController는 Navigation 구성요소의 중심 API로, 스테이트풀(Stateful)이며 앱의 화면과 각 화면 상태를 구성하는 컴포저블의 백 스택을 추적한다. 컴포즈 환경에서 NavController는 rememberNavController()를 이용하여 가져올 수 있다.val navController = rememberNavController..
* 화면 또는 UI 상태는 화면에 표시할 내용을 나타낸다(예: 작업 목록). 이 상태는 애플리케이션 데이터를 포함하므로 대개 계층 구조의 다른 레이어에 연결된다.UI 상태는 화면에 표시할 내용을 설명하지만 앱의 로직은 앱의 동작 방식을 설명하고 상태 변경에 반응해야 한다. 로직 유형에는 두 가지가 있다. (UI 동작 또는 UI 로직과 비즈니스 로직)UI 로직은 화면에 상태 변경을 표시하는 방법(예: 탐색 로직 또는 스낵바 표시)과 관련이 있다.비즈니스 로직은 상태 변경 시(예: 결제하기 또는 사용자 환경설정 저장) 실행할 작업이다. 이 로직은 대개 비즈니스 레이어나 데이터 영역에 배치되고 UI 레이어에는 배치되지 않는다.ViewModel은 UI 상태와 앱의 다른 레이어에 있는 비즈니스 로직에 대한 액세스..
State Hoisting(상태 호이스팅)이란?* remember를 사용하여 객체를 저장하는 컴포저블에는 내부 상태가 포함되며 이는 컴포저블을 Stateful로 만든다. 이는 호출자가 상태를 제어할 필요가 없고 상태를 직접 관리하지 않아도 상태를 사용할 수 있는 경우에 유용하다. 그러나 내부 상태를 갖는 컴포저블은 재사용 가능성이 적고 테스트하기가 더 어려운 경향이 있다. * 상태를 보유하지 않는 컴포저블을 Stateless 컴포저블이라고 한다. 상태 호이스팅을 사용하면 stateless 컴포저블을 쉽게 만들 수 있다.* Compose에서 상태 호이스팅은 컴포저블을 스테이트리스(Stateless)로 만들기 위해 상태를 컴포저블의 호출자로 옮기는 패턴이다. Jetpack Compose에서 상태 호이..
* Compose의 UI는 변경할 수 없다. UI를 설계한 후 업데이트할 수 없다. 대신에 UI 상태는 제어할 수 있다. UI 상태가 변경될 때마다 Compose는 변경된 UI 트리 부분을 다시 만든다. 컴포저블은 상태를 수락하고 이벤트를 노출할 수 있다. 예를 들어 TextField는 값을 수락하고 콜백 onValueChange를 노출한다. 이 콜백은 값을 변경하기 위해 콜백 핸들러를 요청한다. var name by remember { mutableStateOf("") }OutlinedTextField( value = name, onValueChange = { name = it }, label = { Text("Name") }) * 컴포저블이 상태를 수락하고 이벤트를 노출하기 때문에 단..
* 상태(state)는 시간이 지남에 따라 변하는 값(예: 채팅 앱에서 마지막으로 받은 메시지)이다. 하지만 상태가 업데이트되는 이유는 무엇일까? Android 앱에서는 이벤트에 대한 응답으로 상태가 업데이트된다. 이벤트는 애플리케이션 외부 또는 내부에서 생성되는 입력이다. 버튼 누르기 등으로 UI와 상호작용하는 사용자기타 요인(예: 새 값을 전송하는 센서 또는 네트워크 응답)앱 상태로 UI에 표시할 항목에 관한 설명이 제공되고, 이벤트라는 메커니즘을 통해 상태가 변경되고 UI도 변경된다. Key idea: State is. Events happen. (상태는 존재하고, 이벤트는 발생한다) * 이벤트는 어떤 일이 발생했다고 프로그램 일부에 알려준다. 모든 Android 앱에는 다음과 같은 핵심 UI 업..
모르는 사이에 조금씩 조금씩..
