일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 프로토타입 패턴
- ㅓ
- Functional Programming
- a
- Kotlin
- 코틀린
- 디자인패턴 #
- 추상 팩토리
- r
- Observer Pattern
- 빌터패턴
- Abstract Factory
- 옵저버 패턴
- builderPattern
- 디자인패턴
- 팩토리 메소드
- factory method
- PrototypePattern
- ㅋㅁ
- designPattern
- El
- 함수형프로그래밍
- 추상팩토리패턴
- Singleton
- 싱글톤
- Design Pattern
- F
- Today
- Total
오늘도 더 나은 코드를 작성하였습니까?
Compose 상태와 상태홀더 다루기 State & StateHolder 본문
UI Layer, Presentation Layer
UI Element
- Composable Function
- ViewSystem(XML)
UI State
- User에게 보여질 데이터
StateHolder
- 상태를 보관 및 제공
- 로직을 처리
Type of UI State
Screen UI state
- data layer로 부터 제공된 데이터
- 화면에 표시되는 대부분의 정보
- 사용자에게 제공되고 사용자가 가장 관심을 갖는 데이터
UI Eelement state
- UI Eelement의 내부 상태
Type of Logic
business logic
- 제품에 대한 구현체
- 데이터 변화에 대한 요구사항
- 데이터베이스에 CRUD 연산을 수행한다.
ui logic
- 상태(데이터 변화)를 어떻게 보여줄 것 인가
business logic을 통하여 Screen UI state가 생성 및 변경됨.
Screen UI state가 표시 하기 위해 ui logic을 수행한다.
ui logic을 통하여 ui element가 변경됨.
각각의 로직들은 어디서 처리 되어야 할까??
business logic
- Screen level StateHolder (ACC ViewModel)
* ViewModel
- Screen 단위로 사용
- 특정한 UI에 종속되지 않고, 일반적인 데이터를 제공한다.
- LifeCycle과 관련된 참조를 가지고 있으면 안된다.(예 Activity, Fragment Context 등)
- Activit, Fragment, Screen Composable Fun 제외하고 전달을 하지마!
ui logic
- Composable function 내부
- 일반적인 Class
- 얼마나 ui가 복잡한지에 따라서 로직이 있을 위치를 정한다.
* 일반적인 Class StateHolder
- Compoundable => 1개의 StateHolder안에 다른 StateHolder가 참조로 존재할 수 있다.
- UI에 대한 동작을 처리하는 logic을 가지고 있다.
- 재사용 가능한 UI Components(stateless) 안에서 사용되어야한다.
- LifeCycle 관련되 API의 참조를 가질수 있다.
Now in Android 의 StateHolder의 구조.
'Compose' 카테고리의 다른 글
Compose UI Event 다루기 (0) | 2024.11.18 |
---|---|
Event에 따른 UI State 처리방법 (1) | 2024.11.17 |
재사용 가능한 Composable 함수 만들기. (0) | 2024.11.05 |
Compose UI(Composable) 생명주기 (3) | 2024.09.26 |
jetpack compose Side-effects(부수효과) (1) | 2024.02.07 |