728x90
반응형
1. Android Jetpack
- aac의 ViewModel ?
- 구성요소의 라이프사이클을 알고있어서 Activity나 Fragment의 Destroy시 onClear 함수를 통한 데이터 해제
- DataBinding ?
- Ui 요소와 데이터를 프로그램적 방식으로 연결하지 않고, 선언적 형식으로 결합할 수 있게 도와주는 라이브러리
- ButterKnife와 비슷한기능
- LiveData ?
- 1) Observer 패턴: LiveData는 관찰 가능한, Observable 데이터 홀더 클래스
- ViewModel과 View 간의 통신을 쉽게 한다. 여러 위치(SQLite, ArrayList, ViewModel)에서 데이터 참조를 추가 및 삭제하는 여러 호출을 수행하는 대신, 데이터 변경을 관찰하고 데이터를 자동으로 업데이트
- 장점: 데이터가 항상 최신상태, 자원이 공유될 수 있음
- 2) 앱의 생명주기가 활성화(STARTED, RESUME) 상태인 옵저버들에게만 최신 상태의 데이터를 줘
- 일반 식별 가능한 클래스와 달리 LiveData는 앱 구성요소의 생명 주기를 인식 (뷰가 백그라운드에 있으면 뷰의 데이터를 업데이트하지 않음)
- 장점: 메모리 누수가 없음, 생명주기 처리 안해도됨, 구성 변경 올바르게 처리
- 1) Observer 패턴: LiveData는 관찰 가능한, Observable 데이터 홀더 클래스
- MutableLiveData ?
- LiveData에는 저장된 데이터를 업데이트하는 데 공개적으로 사용 가능한 메서드가 없어 이를 보조해주는 객체 (setValue(T)-기본스레드 및 postValue(T)-백그라운드 스레드)
- 일반적으로 ViewModel에서 사용되며 ViewModel은 관찰자에게 변경 불가능한 LiveData 개체만 노출
- ObservableField 와 LiveData의 차이점
- ObservableField는 Lifecycle을 모르나 LiveData는 Lifecycle을 알고 있다.
Room
Paging
Navigation
WorkManager
2. Android 아키텍쳐 (MVC / MVP / MVVM)
- **클린아키텍쳐**에 ****대해 이해한대로 설명해주세요.
- 앱 구성요소는개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 제거할 수 있습니다.
- 따라서 앱 구성요소에 앱 데이터나 상태를 저장해서는 안 되며 앱 구성요소가 서로 종속되면 안 됩니다.
- 아키텍처 원칙은
- 1) 관심사 분리 : UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 함
- 2) Model에서 UI 도출하기 : Model은 앱의 View 객체 및 앱 구성요소와 독립되어 있으므로 앱의 수명 주기 및 관련 문제의 영향을 받지 않음, 데이터나 상태를 저장
- https://meetup.nhncloud.com/posts/345
- **MVC** 개념과 장단점은?
- Model + View + Controller
- Controller : 사용자의 입력(Action)을 받고 처리하는 부분입다.
- Controller는 View를 선택할 뿐 직접 업데이트 하지 않습니다. (View는 Controller를 알지 못합니다.)
- View는 Model을 이용하여 화면을 나타냅니다
- View와 Model 사이의 의존성이 높다는 것입니다. View와 Model의 높은 의존성은 어플리케이션이 커질 수록 복잡하지고 유지보수가 어렵
- **MVP** 개념과 장단점은?
- Model + View + Presenter
- Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분입니다. View와 Model을 붙여주는 접착제 역할
- MVC 패턴의 단점이었던 View와 Model의 의존성을 해결 (Presenter를 통해서만 데이터를 전달 받기 때문)
- 그러나, View와 Presenter 사이의 의존성이 높음
- **MVVM** 개념과 장단점은?
- Model + View + View Model
- View Model : View를 표현하기 위해 만든 View를 위한 Model. View와 Model 사이에서 데이터를 관리해주고 바인딩 해주는 역할
- Command 패턴과 DataBinding을 사용하여 View와 Model 사이의 의존성이 없음
- MVVM ViewModel과 AAC ViewModel의 차이
- MVVM의 ViewModel의 역할
- View와 Model 사이에서 데이터를 관리해주고 바인딩 해주는 역할
- AAC의 ViewModel의 역할
- 화면 회전 같은 환경에서 데이터를 보관하고 라이프사이클을 알고있어서 Activity나 Fragment의 Destroy시 onClear 함수를 통한 데이터 해제의 역할을 하고있습니다. (데이터를 관리하고 바인딩하라는 목적아님)
- AAC ViewModel을 아키텍처 MVVM ViewModel 처럼 사용 가능. 거기에 화면회전에 대한 데이터 유지까지 있으니 더 좋겠죠. 하지만 AAC ViewModel은 Activity 내에서 1개만 생성가능합니다.
- AAC ViewModel은 Activity안에서의 싱글톤 개념인데 MVVM 패턴에서 뷰와 뷰모델은 1:n 관계를 가지기 때문에 Activity 내의 여러 Fragment를 가질시에 여러 Fragment에 ViewModel을 사용하긴 어렵겠죠?
- MVVM의 ViewModel의 역할
- 각 동작 순서
- mvp
- Controller는 사용자의 Action를 확인하고, Model을 업데이트합니다.
- Controller는 Model을 나타내줄 View를 선택합니다.
- View는 Model을 이용하여 화면을 나타냅니다.
- 사용자의 Action들은 Controller에 들어오게 됩니다.
- mvc
- View는 데이터를 Presenter에 요청합니다.
- Presenter는 Model에게 데이터를 요청합니다.
- Model은 Presenter에서 요청받은 데이터를 응답합니다.
- Presenter는 View에게 데이터를 응답합니다.
- View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.
-
- 사용자의 Action들은 View를 통해 들어오게 됩니다.
- mvvm
- View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달합니다.
- View Model은 Model에게 데이터를 요청합니다.
- Model은 View Model에게 요청받은 데이터를 응답합니다.
- View Model은 응답 받은 데이터를 가공하여 저장합니다.
- View는 View Model과 Data Binding하여 화면을 나타냅니다.(뷰는 뷰모델을 관찰(Observe))
- mvp
-
- 사용자의 Action들은 View를 통해 들어오게 됩니다.
- binding
- Data Binding을 이야기 한 것으로, ViewModel에 특정 프로퍼티와 컨트롤의 특정 프로퍼티를 서로 연결해서 ViewModel의 프로퍼티의 값이 변경되면, 자동으로 컨트롤의 프로퍼티 값도 변경되는 형태
- Command
- view에서 발생하는 사용자의 Interaction을 ViewModel에 전달
- MVVM과 MVP 각각에서 View는 무엇을 의미하나요?
728x90
반응형