# 프로젝트매니져 STEP 2

@lina0322
안녕하세요 엘림! 코낄이, 해리입니다.
MVVM과 반응형 프로그래밍을 처음 적용해본 프로젝트라, 전반적으로 어설프지만 잘 부탁드립니다! 🙇‍♂️

## 고민한 점 :thinking:

### 1. UIView의 draw(_ rect: CGRect) 메서드 구현한 점
`TaskListHeaderView`, `CountLabel`, `TaskListCell` 타입에서 `draw(_ rect: CGRect)`메서드를 오버라이드하여 구현하였습니다. 해당 메서드 내에서는 UI요소의 프로퍼티를 설정하는 코드를 구현하였습니다.
**CountLabel**

override func draw(_ rect: CGRect) {
    super.draw(rect)

    layer.cornerRadius = bounds.height / 2
}

**TaskListHeaderView, TaskListCell**

override func draw(_ rect: CGRect) {
    super.draw(rect)

    layer.shadowColor = UIColor.black.cgColor
    layer.shadowOffset = CGSize(width: 0, height: 2)
    layer.shadowOpacity = 0.3
    layer.shadowRadius = 5.0
}

위와 같이 프로퍼티를 설정하는 작업이 UI요소의 디자인을 결정짓는 요소이기 때문에 `draw()` 메서드 내에 구현하였는데, `draw()` 메서드가 코어그래픽을 활용하여 UIKit으로 나타낼 수 없는 UI요소를 표현하고자 할 때(ex. 햄버거 그리기) 주로 사용하는 메서드인지에 대한 의문이 있습니다.

결론적으로 `draw`에서 정의해주는 방식을 택했는데 엘림의 의견은 어떠신지 궁금합니다!

<br>

### 2. ViewModel에서 AlertController를 구성하는 로직을 가져도 괜찮은가?
`TaskListViewController`가 가지고 있는 `CollectionView`에 `UILongPressGestureRecognizer`를 달아주는 중에 발생한 고민입니다.

처음에는 `TaskListViewModel`에 UIAlertController를 생성하여 반환하는 함수를 정의해서 뷰모델에서 모든 구성을 해서 `TaskListViewController`에서는 해당 UIAlertController를 present만 하는 방식을 선택했었습니다.

하지만 뷰모델이 UI를 다룬다는 점이 뷰와 뷰모델 사이의 의존성을 증가시킨다고 생각했습니다.
결론적으로 `TaskListViewController`에서 UIAlertController를 구성하게 하였고, 뷰모델에서는 `AlertAction`의 제목과 핸들러에서 해야할 작업을 수행하는 로직을 갖도록 하였습니다.

<br>
<br>

## 조언이 필요한 부분 :bow:
### 1. bind 네이밍은 뷰와 뷰모델 연결할 때만 사용하는 것 일까요?
`TaskListViewModel`에서 `TaskManager`의 `taskList` 프로퍼티를 구독하고 있습니다. 구독을 하는 시점은 `TaskListViewModel`의 인스턴스가 생성되는 시점입니다.

구독하는 행위를 `TaskListViewModel`의 `requestFilteredTaskList()`메소드에서 수행하도록 했는데요, 이때 네이밍을 뷰컨트롤러에서 한 것처럼 `bind~~`와 같은 방식으로 해야할지 아니면 보통 사용하는 네이밍 방식이 어떤게 있는지 궁금합니다. 엘림은 어떤 방식으로 네이밍 하시나요?

<br>

### 2. 반응형 프로그래밍의 방출-구독 구조
이번에 반응형 프로그래밍과 MVVM을 함께 적용하면서, 데이터의 전달 흐름에 대한 고민이 많았습니다.
가능하면 **Model → ViewModel → View**로의 일방향 전달을 지향하고자 했습니다. 그러다 보니 작은 기능을 구현하는데도 많은 어려움이 있었습니다. 필요한 경우 반대방향 혹은 양방향 방출으로 방출과 구독하는 구조도 괜찮을까요? :thinking:

### 2-1. 데이터 전달의 방향성 문제로 구현을 미룬 기능
<img src="https://hackmd.io/_uploads/HJDU8U9S3.png" width=400>

요구사항에 명세되어있지는 않았지만, 저희는 `title`과 `body`가 비어있을 때에는 **Done** 버튼을 비활성화하고자 했습니다.
이 기능을 구현하는 데 다음과 같은 문제가 있었습니다.
1. `TaskFormViewModel`이 `TaskFormViewController`의 UI요소인 `textField`와 `textView`의 변경을 구독하고 있어야 합니다. 이는 저희가 생각한 방향성과 맞지 않았습니다.
2. `TaskFormViewModel`이 `TaskFormViewController`의 UI요소를 구독한다면, `textField`와 `textView`가 비어있는 조건을 검사하기 위해 사용자가 텍스트를 작성 중에 계속해서 변경을 관찰하는게 맞는 방법일지에 대한 고민도 있습니다. 크든 작든 성능상의 문제도 있을것이라 생각됩니다.

저희가 생각한 기능을 깔끔하게 구현하기 위해 엘림의 조언을 여쭤보고 싶습니다!

# 프로젝트 매니저 [STEP 2] Harry, kokkilE

@lina0322
안녕하세요 엘림! 코낄이, 해리입니다.
이번 스텝도 잘 부탁 드리겠습니다!!

<br>
<br>

## 프로젝트 구조
프로젝트 내 타입들 간의 대략적인 관계를 다음과 같이 표현하였습니다.
(관계의 종류나 방향은 나타나지 않고, 서로 연관이 되어 있다는 정도의 의미로 첨부하였습니다.)
VC는 View Controller, VM은 View Model을 의미합니다.
<img src="https://hackmd.io/_uploads/rJI2GTB82.png" width=800>

- 앱 전체에서 관리되는 `taskList: [MyTask]`는 `TaskManager`가 소유하고 있습니다.
- 앱 전체에서 관리되는 `historyList: [History]`는 `HistoryManager`가 소유하고 있습니다.
- 각각의 ViewModel은 `ProjectManagerService`를 참조합니다.
- 각각의 ViewModel은 `ProjectManagerService`를 통해 `taskList: [MyTask]`와 `historyList: [History]`에 CRUD를 요청합니다.
- `taskList: [MyTask]`와 `historyList: [History]`의 변경 사항은 서버(Firebase)와 로컬(Realm)에 반영됩니다.

### 원격, 로컬DB를 관리하는 타입의 역할 분리
#### ProjectManager
- ViewModel에서 접근할 수 있는 객체로 뷰모델에 필요한 정보(컬렉션뷰에 필요한 데이터)와 기능을 제공합니다.
- 데이터의 읽기/추가/이동/수정/삭제 기능을 뷰모델에게 제공합니다.

<br>

#### TaskManager
- ProjectManagerService가 프로퍼티로 가지고 있는 타입입니다.
- MyTask 모델을 `원격 서버 관리타입(FirebaseManager)` 와 `로컬DB 관리타입(RealmManager)`에게 넘겨주면서 관리타입들에게 지시를 하는 타입입니다.

<br>

#### HistoryManager
- ProjectManagerService가 프로퍼티로 가지고 있는 타입입니다.
- TaskManager와 마찬가지로 History 모델을 `원격 서버 관리타입(FirebaseManager)` 와 `로컬DB 관리타입(RealmManager)`에게 넘겨주면서 관리타입들에게 지시를 하는 타입입니다.

<br>

#### FirebaseManager
- TaskManager, HistoryManager 타입들이 프로퍼티로 가지는 타입입니다.
- 직접 Firebase 서버와 통신하여 서버의 데이터베이스 변경을 감시하고 원격 서버 데이터의 CRUD를 할 수 있는 타입입니다.

<br>

#### RealmManager
- TaskManager, HistoryManager 타입들이 프로퍼티로 가지는 타입입니다.
- 직접 로컬 DB인 Realm 객체에 오브젝트를 CRUD 할 수 있는 타입입니다.

<br>

저희가 생각한 로컬,원격 DB와 상호작용하고 뷰모델에 어떤 정보와 기능을 제공해주는지의 역할에 따라 분리를 해보았는데, 적절했는지 아니면 더 좋은 의견이 있으신지 엘림의 조언이 궁금합니다..

<br>
<br>

## 고민한 점 :thinking:
### 1️⃣ 서비스의 정의와 프로젝트 기획
- 저희가 진행하는 프로젝트가 사용자에게 제공해주는 서비스가 무엇인지를 정의하는 것에 고민을 많이 했습니다.
- 처음 생각했던 방향은 사용자에게 할일의 추가/수정/삭제 하는 단순히 할일 관리 서비스만 제공하는 것이라고 생각했습니다.
- 해당 서비스를 제공하기 위해서 로컬 데이터베이스, 리모트 서버 두 가지 다 동기화 해야하는 이유가 무엇일까에 대한 고민을 해봤습니다. 네트워크에 관한 문제까지 겹치게 되면서 로컬과 원격서버의 동기화에 대한 여러 문제가 발생할 수 있는 경우의 수를 생각했을 때, **네트워크가 없는 환경에서는 변경사항이 있어서는 안된다**는 결과를 도출했습니다.
- 예시로 아이폰의 메모앱에서는 로컬 환경의 메모와 iCloud 서비스를 활용한 메모의 폴더가 다르다는 점, 카카오톡 로컬환경에서 메세지가 작성되지 않고 예전 대화목록을 볼 수 있다는 점에서 프로젝트의 기획을 어떤 방향으로 할 지 정할 수 있었습니다.

<br>
<br>

### 2️⃣ 로컬DB와 원격DB의 동기화 문제
- 네트워크에 연결 되어있을 때와 연결 되지 않았을 때 어떤 방식으로 동기화를 해주어야할까 고민을 많이했습니다.
- 저희가 생각한 기획은 다른 Apple 기기에서도 원격 서버를 공유해서 데이터가 일치해야한다고 생각하고 기획하였습니다.
- 따라서 네트워크 연결이 되어있지 않은 기기에서 CRUD 작업을 했다가 갑자기 네트워크에 연결이되 동시간대에 다른 기기에서 CRUD가 일어나면 충돌이 발생할 수 있을 여지가 있다고 생각했습니다.
- 결론적으로 네트워크 연결이 되어있는지를 감시하여 연결되어 있지 않다면, 로컬DB로부터 데이터를 읽어오고 추가/수정 버튼, 스와이프 액션, 롱탭 제스쳐를 비활성화하여 CRUD 작업이 발생하지 않도록하였고, 네트워크 연결이되면 서버에 있는 데이터로 동기화를 할 수 있도록 하였습니다.

<br>
<br>

### 3️⃣ 위 고민의 결과로 구현한 기능
- 앱 실행 시 네트워크에 연결되어 있다면 원격DB로 데이터를 요청합니다. 네트워크에 연결되어 있지 않다면 로컬DB로 데이터를 요청합니다.

#### 앱 구동 중 네트워크 연결이 유지될 경우
- 편집한 데이터는 바로 원격DB와 로컬DB에 반영됩니다.
- 다른 기기에서 변경된 데이터가 원격DB에 반영된다면, 원격DB와 연결된 모든 기기에서 변경 사항을 반영하고 로컬DB에 반영합니다.

#### 앱 구동 중 네트워크 연결이 유지되지 않을 경우
- 앱에 저장된 데이터를 기반으로 읽기 작업만이 가능합니다.
- 셀의 스와이프 액션, 롱터치 액션, 데이터 추가 버튼, 데이터 편집을 위한 Edit버튼이 비활성화됩니다.

#### 앱 구동 중 네트워크 비연결 -> 네트워크 연결 상태로 변경될 경우
- 원격DB로 데이터를 요청하여 원격DB의 데이터를 앱과 로컬DB에 반영합니다.

<br>
<br>