Krello

Trello-style Task Management App 기한: 2022.05.04 ~ 05.20 (13일) 프로젝트에 대한 자세한 내용은 👉 Notion 에서 확인할 수 있습니다

앱 소개

Trello 의 기능을 따라 할일을 관리하는 iOS Application을 만들어 보았습니다. 구현된 기능은 다음과 같습니다:

• 회원 가입과 로그인 기능 구현
• CRUD 중 Read 구현

| 로그인 | 회원가입 | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | | | | - Firebase authentication 을 사용해 email 로그인을 할 수 있습니다.
- 로그인을 하면 firebase 로 부터 인증을 하고 받아온 사용자 uid 를 local 에 저장해 API 호출에 사용합니다.
- 한번 로그인을 하면 앱 종료 후 다시 실행해도 로그인 상태를 유지합니다. | - email, password 로 회원가입을 할 수 있습니다.
- 입력값에 대한 검증을 하고 유효한 값인지 체크합니다.
- 모든 TextField 의 값이 유효하다고 판단이 되면 비로소 회원가입 버튼이 활성화됩니다. |

| 할일 관리 | 드래그 앤 드랍 | | :-------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------: | | | | | - 사용자 키(uid) 에 해당하는 데이터를 firestore 로 부터 불러와 화면에 보여줍니다. | - Drag & Drop 으로 할일을 이동시킬 수 있습니다.(서버에 반영하는 작업은 구현 안됨) |

팀원

| @Eddy | @Kai | @Rosa | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | | | | |👉 프로젝트 회고 | 👉 프로젝트 회고 | 👉 프로젝트 회고 |

사용한 기술

• Unit Test
• View
  • Autolayout programmatically
  • Compositional Layout
• Firebase: Authentication & Storage
• Coordinator pattern

Library

| | Version | | | ---------------------- | ------- | --------- | | SwiftLint | | CocoaPods | | FirebaseAuth | 9.0.0 | CocoaPods | | FirebaseFirestore | 9.0.0 | CocoaPods | | FirebaseFirestoreSwift | 9.0.0 | CocoaPods |

📙 작업 내역

• #35

🤔 고민과 해결

• 현재 Collection View Cell이 TableView의 Delegate, DataSource, DropDelegate, DragDelegate 역할을 모두 맡고 있음. -> 역할 분리가 필요함. 차후 리팩토링 때 진행 필요.
• Collection View Cell이 tableview를 직접 가지고 있는 것이 아니라, TaskStackView가 tableView를 가지고 있는 구조이기 때문에, TaskStackView가 Delegate 역할을 맡는 것이 더 적절해보임.
• 혹은 Cell 안에 별도의 Child View Controller를 구성해서 띄우는 방식도 고려해보았으나, 일단은 해결하지 못하고 기존 구조를 유지함.

💭 기타 설명

해야할 일 목록

• [ ] FireStore에서 Task를 Board의 서브콜렉션으로 변경

설명

• 현재 Board를 가져오는 것은 BoardVC, Task를 가져오는 것은 TaskVC로 구분되어있는 상황임.
• 데이터를 서브콜렉션으로 분리하면 매번 같이 쿼리할 필요없이 별도 쿼리가 가능해짐.
• Task에 만약에 이후에 무거운 데이터가 들어가게 되면, 하나의 다큐먼트에 다 담았을 때 다큐먼트의 쿼리 성능이 저하됨.
• Tasks라는 서브 콜렉션을 만들고 Task를 다큐먼트로 저장하는 게 더 낫다고 판단이 되었음.

참고 - Firestore의 데이터 구조 설계 시 알아야할 것

📙 작업 내역

• [x] 배경화면을 터치하면 키보드를 내린다
• [x] 키보드의 done 버튼을 누르면 키보드를 내린다
• [x] 키보드가 올라왔을때, password textfield 라면 입력이 키보드에 가려지지 않도록 전체 화면을 올린다
• [x] 멤버변수, 메서드를 private 으로 변경
• [x] textfield 의 keyboard 타입 변경
• [x] button unit test

🤔 고민과 해결

• 키보드에 가려지는 입력뷰를 어느정도로 올려야 모든 디바이스에 호환이 될까...하는 고민
• self.frame.origin.y = -keyboardSize.height/2
• 현재는 키보드 높이의 절반만큼 뷰를 올리게 되어있다
• 입력 뷰(textfield) 의 위치가 키보드 높이보다 낮다면, 현재 키보드 높이보다 위에 위치하도록 화면을 움직이는 방법도 있을듯 하다

에러 메시지

022-05-16T17:38:46.7993750Z /Users/runner/work/Krello/Krello/KrelloTests/FirestoreServiceTest.swift:50: error: -[KrelloTests.FirestoreServiceTest test_fetchBoards_withUserUid_shouldResponseBoards] : Asynchronous wait failed: Exceeded timeout of 1 seconds, with unfulfilled expectations: "test_fetchBoards_withUserUid_shouldResponseBoards()". 2022-05-16T17:38:46.8310980Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchBoards_withUserUid_shouldResponseBoards]'failed (1.118 seconds). 2022-05-16T17:38:46.8473270Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchLogs]' started. 2022-05-16T17:38:47.3813320Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchLogs]' passed (0.584 seconds). 2022-05-16T17:38:47.3919140Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchUser_shouldResponseUserData]' started. 2022-05-16T17:38:47.6429670Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchUser_shouldResponseUserData]' passed (0.260 seconds). 2022-05-16T17:38:47.6451240Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchUserAll_sholudResponseUserList]' started. 2022-05-16T17:38:47.7733040Z 2022-05-16 17:38:47.762143+0000 Krello[6289:26448] 9.0.0 - [FirebaseAnalytics][I-ACS023012] Analytics collection enabled 2022-05-16T17:38:47.9442460Z Test Case '-[KrelloTests.FirestoreServiceTest test_fetchUserAll_sholudResponseUserList]' passed (0.283 seconds). 2022-05-16T17:38:47.9544120Z Test Case '-[KrelloTests.FirestoreServiceTest test_InsertUser]' started. 2022-05-16T17:38:48.4745540Z Test Case '-[KrelloTests.FirestoreServiceTest test_InsertUser]' passed (0.534 seconds). 2022-05-16T17:38:48.4867780Z Test Suite 'FirestoreServiceTest' failed at 2022-05-16 17:38:48.449. 2022-05-16T17:38:48.4989940Z Executed 5 tests, with 1 failure (0 unexpected) in 2.779 (2.781) seconds 2022-05-16T17:38:48.5103410Z Test Suite 'KrelloTests' started at 2022-05-16 17:38:48.449 2022-05-16T17:38:48.5487400Z Test Case '-[KrelloTests.KrelloTests testExample]' started. 2022-05-16T17:38:48.5589380Z Test Case '-[KrelloTests.KrelloTests testExample]' passed (0.001 seconds).

📙 작업 내역

• #40
• #41
• #8
• #36
• #43

🤔 고민과 해결

• UserDefault 를 써서 로그인 여부 검사.
  • SceneDelegate 에서 UserDefaults 에 저장된 유저 uid 값이 있으면 => 로그인 되었다 => BoardList 화면 띄움
  • uid 값이 없으면 => 로그인 안됨 => Login 화면 띄움
• SceneDelegate 에서 화면 흐름을 제어하도록 함
  • 회원가입 했을때 자동으로 로그인이 되기 때문에 BoardList 화면으로 건너뛰어야 한다
  • 클로저를 이용해 회원가입 이벤트를 최상위 객체(SceneDelegate) 에게 전달하여 화면이동하도록 구현

💭 기타 설명

• UserDefaults 를 사용해 로그인 여부를 체크한 이유
  • 앱을 종료하고 다시 실행했을때 로그인을 유지하기 위해 UserDefaults값을 사용
  • UserDefaults 값은 앱을 삭제하지 않는 이상 계속 앱내부에 저장되는 값
  • 현재 로그아웃 기능은 제외됨
  • UserDefaults 에 저장한 값은 한번 로그인 하면 계속 유지됨
  • => 시간이 지나면 로그아웃 되는 기능이 필요하다면 UserDefaults 에 로그인한 날짜를 저장해 검사할 수 있다

📙 작업 내역

• [X] 회원가입 화면 구현
• [X] validaton 구현
• [X] firebase Auth 서버 정보 보내기 구현

🤔 고민과 해결

• Validation 의 기준이 정확하지 않아서 네이버 회원가입 validation 참고 했습니다.
• 특히 password 부분에서 해메서 Eddy 의 도움을받아 진리표 작성후 로직구현 했습니다.

password | passwordConfirm | password Message | passwordConfimation Message -- | -- | -- | -- empty | empty | 필수항목입니다 | 필수항목입니다 empty | 같음 | 필수항목입니다 | 필수항목입니다 empty | 다름 | 필수항목입니다 | 비밀번호가 일치하지않음 Not empty, Invalid | empty | 형식이 맞지않습니다(위) | 필수항목입니다 Not empty, Invalid | 같음 | 형식이 맞지않습니다(위) | 비밀번호가 일치합니다(아래) Not empty, Invalid | 다름 | 형식이 맞지않습니다(위) | 비밀번호가 일치하지않음 Valid | empty | 사용가능한 비밀번호 입니다(위) | 필수항목입니다 Valid | 같음 | 사용가능한 비밀번호 입니다(위) | 비밀번호가 일치합니다(아래) Valid | 다름 | 사용가능한 비밀번호 입니다(위) | 비밀번호가 일치하지않음

💭 기타 설명

• 현재 회원가입 화면 구성

  

• 화면

버그가 발생한 상황, 맥락

• 프로젝트를 다시 다운받아서 빌드한 상황.

기대한 결과 vs 현재 결과

• 빌드가 정상적으로 작동해야 하는데,
• build 중에 cycle이 있다고 뜨면서 Krello.app을 재귀적으로 호출하는? 그런 에러가 생겼음.

에러 메시지

해본 시도

• 검색을 통해서 제안된 솔루션은
• 현재 빌드 시스템 설정을 레거시 빌드 시스템 설정으로 바꾸기
• Pod 제거하고 다시 install 하기.
• Clean build 하기
• ~/Library/Developer/Xcode/DerivedData에 있는 모든 빌드 폴더 삭제하기.

📙 작업 내역

• [ ] Entity를 파일 분리
• [ ] FirestoreRequest 프로토콜, UserRequest 타입을 추가

🤔 고민과 해결

• Firestore service를 addService, getService로 나누려다가, 그것보다는 우리가 요청하는 다양한 타입과 리소스를 직접 타입으로 추가하여 generic하게 실행할 수 있도록 만드는 것이 더 좋다고 생각하여 리팩토링을 시도함.
• 아직 해결되지 않은 문제는, reference와 data까지는 제네릭하게 만들었는데, Query나 Save의 다양한 케이스들을 다 커버하지 못함. Task-Save의 경우는 array에 추가하는 함수를 사용하며, Boards-Query의 경우는 getDocument가 아닌 getDocuments를 써야함. 또는 커스텀 객체를 넘겨 저장할 때와 딕셔너리로 넘겨서 저장하는 케이스도 있음.
• 이처럼 다양한 쿼리와 저장의 케이스가 있기 때문에, 실제 요청 함수와, 응답 처리 함수도 generic하게 만들어야 하는데, 그 부분을 어떻게 해야할지 감이 잘 오지 않음.
• Generic하게 네트워킹 레이어를 만드는 예제를 참고해서 계속 고민해볼 예정

💭 기타 설명

📙 작업 내역

• #51

🤔 고민과 해결

고민 1.0 : BoardCollectionViewCell 역할을 분담 시키기에 크게 2 가지 옵션이 있었습니다.

• 1.0 BoardViewController 가 모든 delegation 과 데이터 업데이트 을 수행한다.

  • 장점 : 모든 로직을 BoardViewController 가 가지고 있으므로 구현이 쉽다.
  • 단점 : BoardViewController 가 너무 커지고 코드를 이해하기 힘들어진다.

• 2.0 새로운 viewController 에 BoardCollectionViewCell 의 delegation 과 dataSource 업데이트 로직을 분담시킨다.

  • 장점: BoardViewController 과 새로운 viewController 의 역할에 따른 로직을 분리시킬수 있기때문에 Massive VC 를 피할수있고, 코드를 이해하기 쉬워진다.
  • 단점: 각 VC 의 역할을 분명히 나눌수 있어야 역할이 나뉜것을 똑바로 이해할수 있기때문에 잘못 구현할시 코드가 더욱 복잡해 질수 있다.

해결

• BoardViewController 모든 로직을 가지고 있으면 VC 가 너무 커지고 코드의 재사용성 이 떨어지기 때문에 새로운 VC 를 만들어 역할을 분담 시켰습니다.
• 새로운 ViewController 의 이름은 TaskViewController 라 정했고, task 에 관한 모든 역할을 수행하도록 설계했습니다.

고민 2.0 : TaskViewController 를 어디에 배치시킬까 ?

• 1.0 BoardCollectionViewCell 안에 TaskViewController 를 프로퍼티로 할당시킨다.

  • 장점 : Cell 의 reusability life cycle 을 고려하지 않아도 된다. (구현이 쉬움)
  • 단점 : Cell 과 TaskViewController 의 의존성이 높아져서 재사용성이 떨어지고, test 가 어려워진다.

• 2.0 TaskViewController 를 BoardViewController 의 childViewController 로 만든다.

  • 장점: 느슨한 결합으로 구현가능하다.
  • 단점: 하나의 cell 에 여러개의 childVC 가 생성되지 않도록 신경써야함. (구현이 어렵다)

해결

• TaskViewController 를 BoardViewController 의 childViewController 로 만드는 방식을 선택했습니다.
• 그 이유는 Cell 이 TaskViewController 를 알게 되면 1.0 의 단점이 있을 뿐만아니라 taskVC 가 데이터를 전달 받는 방식이 cell 을 거치고 해야하기 때문에 코드가 복잡해질수 있기때문입니다.
• 2.0 방법은 cell 의 life cycle 과 addSubView, removeSubView 되는 시점에 대한 이해가 필요해서 구현이 조금 어렵긴하지만, cell 과 boardViewController 사이에 느슨한 결합으로 구현할수 있어서 2.0 방법으로 구현해봤습니다.

💭 기타 설명

Task 타입 수정

NSItemProvider 는 데이터나 파일을 drag and drop 이나 copy/paste 작업중에 사용 되는 item provider 클래스. 그리고 TableView Drag and Drop 에서 사용되는 NSItemProvider 는 NSItemProviderWriting, NSItemProviderReading 를 준수하고 있어야함. 기본적으로 이 두개의 프로토콜을 채택하고 있는 클래스들은 NSString, NSAttributedString, NSURL, UIColor, UIImage 등이 있기때문에 바로 Drag and Drop이 가능함. 하지만 위의 타입외의 사용자 별도 타입으로도 사용 하려면 NSItemProviderWriting, NSItemProviderReading 프로토콜을 준수하도록 해야 한다. 따라서 현재 프로젝트의 Task 타입을 위의 프로토콜을 따르도록 수정. 참고

해야할 일 목록

• [x] TaskViewController 생성 후 delegation 옮기기
• [x] BoardViewController 의 cellForItemAt 에서 taskViewController 를 생성후, childViewController 로 지정
• [x] 기존 Task 모델 을 drag and drop 에 사용하기 위해 NSItemProviderReading, NSItemProviderWriting, Codable 프로토콜 채택

📙 작업 내역

• #59

🤔 고민과 해결

BoardListVC 와 TaskViewVC 의 TableViewDataSource 를 합치는데 numberOfSections , numberOfRowsInSection 의 구현이 달라서 TableConfigurator 라는 스트럭쳐를 제네릭한 TableViewDataSource 에 프로퍼티 설정 해주었습니다.

에러 메시지

• Drop 에러

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of sections. The number of sections contained in the table view after the update (1) must be equal to the number of sections contained in the table view before the update (1), plus or minus the number of sections inserted or deleted (0 inserted, 1 deleted). Table view: <UITableView: 0x143017600; frame = (0 50; 252.667 504); clipsToBounds = YES; gestureRecognizers = <NSArray: 0x60000250b270>; layer = <CALayer: 0x600002bae4c0>; contentOffset: {0, 0}; contentSize: {252.66666666666666, 55}; adjustedContentInset: {0, 0, 0, 0}; dataSource: <TtGC6Krello19TableViewDataSourceCS_4Task: 0x600000f683c0>>'

• Cell indexPath 증가하지 않는 버그
  • Task 모델을 2개가 들어간게 확실한데, dataSource 의 indexPath 가 증가하지않고 첫번째 모델의 title 만사용하여 cell 의 제목이 같음.

📙 작업 내역

• [x] 화면 이동을 담당하는 객체(coordinator) 구현
• [x] ViewController 에서 coordinator 를 이용해 화면 이동하도록 적용

🤔 고민과 해결

• ViewController 에서 화면이동을 하고 있기때문에, 다음 화면에 대한 정보를 알아야 하는 점이 불가피하다
  • 이점이 ViewController 간 결합을 강하게 하므로, 화면이동을 하는 객체를 두어 이를 해결한다
• 사용자의 입력 한번에 화면 이동이 연쇄적으로 발생해야 한다면, 연결되어 있는 ViewController 에 이벤트를 전달하는 코드가 분산되어 진다.
  • 화면 이동만을 위해 이벤트를 전달해야 하므로, 불필요한 코드라고 느껴졌다. 이를 단순화 하기 위해 모든 화면에 대한 흐름을 관리하는 객체가 필요했다

☀️ 리펙토링 결과

리펙토링 전, 이벤트를 최상단 객체까지 전달하는 구조였다:

화면 이동을 담당하는 Coordinator 객체 구현 후, ViewController 는 coordinator 에게 화면 이동을 요청하기만 되는 구조로 변경되었다:

장점

• ViewController 내부에서 다른 ViewController 를 생성하지 않게 됨으로써 의존성이 줄어들었다.
• 연쇄적으로 화면이동을 처리해야 할때, 이를 관장하는 객체를 둠으로써 이벤트 처리가 편리해 졌다.
• 화면 이동 로직을 분리함으로써 Massive View Controller 에서 조금은 벗어날 수 있게 되었다

단점

• Coordinator 하나가 모든 화면의 이동을 처리하므로 책임이 많아졌다
  • ⇒ Child Coordinator 로 분리할 필요가 생김
• 처리해야 할 문제들이 계속 생겨남
  • Coordinator 를 작게 분리하기
  • alert 창을 띄우는 것도 Coordinator 에서 할 것
  • present, dismiss 하는 화면에 대한 처리

💭 기타 설명

• Rosa 의 Coordinator 적용기
• 참고자료1: coordinator 소개와 예제
• 참고자료2: 예제

해야할 일 목록

• [ ] SignupManager 모델 객체 추가
• [ ] SignupVC가 SignupService 프로토콜을, SignupService 프로토콜을 SignupManager가 채택하도록 변경
• [ ] SignupManager가 형식 FormatValidator와 중복 DuplicationValidator와 최종 유저 정보 추가 FirestoreService에 의존하도록 변경.

이유

• ViewController가 Networking이나 다른 Model의 의존성이 낮아짐.

현재 겪고 있는문제

• Cell 이 Dequeue 되면서 tableStackView 가 사라짐.
• prepareReuse 와 didEndDisplaying 에서 removeFromSuperview() 를 호출하긴하지만 cell 이 다시 재사용되면서 addSubView 를 해야하는데 안돼고 있는 상황인것 같음