-클린 아키텍처를 안드로이드 모바일에 적용하면 UI Layer / Domain Layer / Data Layer로 나뉘는데 해당 페이지에서는 UI Layer에 대해서 학습할 것임.

-UI 계층을 Presentation 계층이라고 부르기도 한다. 이곳에서 안드로이드 설계에서 가장 중요한 부분이 이루어진다. MV로 시작하는 여러가지 패턴 / MVC / MVP / MVVM / MVI 라는 4가지의 아키텍처 패턴들은 각기다른 방식으로 UI를 구성한다.

UI 계층(MV?)의 대원칙

Model[What]

어떤 경우이든 Model은 분리되어야 한다.

-/ MVC / MVP / MVVM / MVI / 이 4가지 아키텍처 패턴 중 어느 패턴이든 Model은 UI 계층과 분리가 되어야 한다.

-MVX에서 Model이 의미하는 것은 "데이터를 다루는 어떤 전반적인 로직"을 의미한다.

-Model이라는 것은 어떤 모델링 같은 걸 생각해서 하나의 데이터 엔티티 같은 것 또는 데이터 클래스 같은 것들의 집합 같은 것으로 생각 할 수 있는데 , Model은 이런 것들을 의미하지 않는다.

-[데이터를 다루는 모든 것들 그리고 조금 더 넓은 범위로 생각하면 데이터 레이어] 뿐만 아니라 [도메인 레이어(UI의 비즈니스 로직을 벗어나 있는 다른 무엇인가까지도 좀 더 도메인 지식에 가까운 비즈니스 로직이)]라든가 그런 것까지 포함해서 [데이터 계층에서 다루는 서버에서 무엇인가를 받아오고 쓰고 하는 것들]이라든가 그 다음에 [로컬 데이터베이스에서 어떤 것을 쓴다든가 하는 것들]은 UI의 외적인 부분이라고 할 수 있다. 이런 것들을 Model이라고 한다.

View[How it looks]

View의 역할을 할 수 있는 한 분리시켜야 한다는 공통의 문제 의식이 있다.

-View의 역할을 할 수 있다면 심지어는 MVC 패턴이라고 하여도 , View에서 할 수 있는 일들은 가급적이면 컨텍스트를 이용한 디바이스에서 의존적인 그런 부분들 위주로의 어떤 동작들이 그곳에서 이루어진다.

-그러나 View에서 처리하는 것이 적절하지 않은 작업들은 가급적이면 빼서 다른 쪽으로 넘기도록 하자는 그런 어떤 합의가 생긴 것 처럼 보인다.

Android에서 발생할 수 있는 특수한 상황들을 잘 처리할 수 있는 체계가 필요하다.

-Context라는 것이 안드로이드에 독특하게 존재하는데 이 컨텍스트라는 것은 기본적으로 액티비티가 띄워져 있다면 액티비티 그 자체이기도 하고 애플리케이션 컨텍스트라고 하면 애플리케이션 그 자체이기도 하고 그러면서도 예를 들면 다른 플랫폼에서 얘기하는 것 같은 디바이스 컨텍스트 같은 것들(ex : 권한 허용 / 시스템 전역적인 무엇인가를 한다든가)을 의미한다.

-UI 계층에서 생명주기를 관리해야 한다. : 앱의 안정성을 보장할 필요가 있고 이벤트 처리과정에서 사용자에게 기대하지 않은 동작을 보여줘서는 안된다.

-UI 계층의 코드들이 가능한 많은 부분이 테스트가 가능하도록 만들어야 한다. 안드로이드 같은 경우는 디바이스 종류가 다양하기 때문에 각각의 디바이스 마다 일일이 테스트 하는 것은 사람이 인력에 모든 것을 맡기는 것은 굉장히 어렵기 때문에 결국은 그러한 부분들도 자동화 시킬 필요가 있다. 따라서 테스트가 많이 필요한 것이다.

MVC Pattern

-Model과 View는 일종의 레고 블록 : Model은 저장이라든가 저장을 하고 서버로 어떤 요청을 보내고 하는 모든 것들 데이터 응답등 모든 것들이 모델에서 일어난다. 반대로 View는 일반적으로 유저에게 보여지는 화면이다. 해당 화면과 유저의 특정 부분을 클릭했다든가 하는 유저 이벤트들도 당연히 뷰에서 일어난다.

-Model과 View는 일종의 레고 블록 : 그러면 뷰에서 제공하는 컴포넌트들과 모델에서 제공하는 컴포넌트들이 있을 때 이것들을 레고 블럭과 같이 만들어서 사용해서 조합하는 역할은 컨트롤러가 한다. 예를들어 유저가 어떤 입력을 했을 때 컨트롤러가 먼저 받아 들여서 이 입력이 어떤 의미가 있겠다는것을 받아들이고 어떻게 그릴지에 대한 명령을 뷰한테 내린다. 말 그대로 컨트롤러가 컨트롤러가 되는것이다. 웹앱에서는 웹의 어떠한 부분이 바뀌어야 된다든가 특정 HTML을 보여주는 것에 대한 결정도 컨트롤러가 해서 해당 뷰를 생성해서 해당 뷰가 보여지도록 하는 역할까지도 컨트롤러가 담당한다.

-컨트롤러 자체는 뷰와 모델이 충분히 잘 설계가 되어있다는 전제하에 컨트롤러에서는 결정권에 대한 로직들만 가지고 있는 형태로 해서 이렇게 각각의 어떤 역할들의 책임들이 명확하게 분리가 되는 형태로 만들 수 가 있다. 예를들어 어떤 View를 보여줄까를 결정한다든가 하는 것도 Controller에서 일어나고 어떤 데이터 요청이라든가 그런게 필요하다고 하면 모델에 요청을 보내고 받아서 다시 View에 알려주고 하는 것들도 컨
트롤러가 하게 된다.

-Controller는 에러가 발생했을 때의 처리도 담당한다. 어떤 에러가 발생했다고 했을 때 어떻게 보여줘야 될 지 그리고 사용자에게 어떤 에러를 보여줘야 될지를 결정할 뿐만 아니라 개발자에게 어떤 종류의 에러가 발생했는지 로그를 보여주는 것도 컨트롤러가 담당한다.

-MVC 패턴의 특이한 점은 Model과 View 사이를 직접 연결할 필요가 없고 연결해서도 안된다. 초기부터 Model과 View의 연결이 끊긴것이 아니라 오랜 합의에 걸쳐서 Model과 View 사이에 있는 의존성은 끊는게 좋겠다라는 합의가 도출되었고 현재의 MVC 패턴에선는 Model과 View는 통신을 하지 않는 방향으로 결정되어 있다.

-안드로이드에서는 MVC가 잘 동작하지 않는다.

• 모바일 환경의 문제
  
  -1. 복잡한 비동기 처리 유저이벤트 , 시스템 이벤트 등의 여러 이벤트들이 View를 통해서 Controller로 오게된다. 이때 , Controller에서는 이런 것들은 전부 다 처리하기에는 어려움이 있기 때문이다.
  
  -2. UI 로직을 분리하기가 어렵다. 웹에서는 View와 Controller를 완전히 독립적인 형태로 UI 로직의 구현이 가능하지만 모바일은 그렇지 않다.

• 안드로이드의 문제(View ~ Controller 분리가 애매하다.)
  
  -1.안드로이드의 XML은 Layout만 제공하기 때문에 UI 로직이 들어갈 수 없어.
  
  -2.Activity 또는 Fragment가 Controller를 담당하는 역할이 불가피한데 그럼 결구겡는 Activity 또는 Fragment가 View , Controller를 모두 담당하게 된다. 그럼 Activity와 Fragment가 돼지코드가 된다.
  
  -위 둘의 문제를 해결하기 위해서 Activity와 Fragment에서 inflate 과정을 통해서 XML이 실질적으로 어떤 메모리상의 코드로 존재하게 되는데 이것을 ViewController에게 위임하는 것이다. 특정 영역들을 infalte 할 수 있도록. 이렇게 되면 기존에 Activity가 View와 Controller의 역할을 동시에 하던 문제를 해결하고 Activity는 Controller의 일부 기능만 담당하고 특정 화면이 시작 될 때의 엔트리 포인트만을 제공해준다. 그러나 ViewController가 동작하기 위해서는 Context가 필요한데 결국 ViewController가 context에 의존하게 되면 테스트가 어려워진다. 따라서 궁국즉어론는 View와 Controller를 완전히 분리하는 것만이 해결책이 된다. 근데 Compose는 쌉가능 근데 Compose는 MVVM 이 잘어울린다능...
  

Non-MVC Patteren

-Activity는 아주 제한적인 Controller의 역할만 맡는다.(Entypoint만 담당한다.)

MVP 접근 방법

-MVP Pattern에서는 View와 Controller의 역할을 최대한 가져가서 View와 Presenter로 넘기는 것이 가장 좋은 전략이다.

MVVM / MVI 접근 방법

-View와 Model 사이를 극단적으로 끊어내서 View가 어떤 일을 하고 있는지 Model이 어떤일을 하는지 모르게 만드는 것이 가장 궁극적인 지향점이다.

-UDF의 흐름이 View 방향으로만 흐로도록 하는것이다.