• RxSwift, CleanArchitecture, Reactor, Moya

궁금증을 가진 코드

• 기능 : 닉네임 입력 후 확인 버튼 클릭 시, 중복된 닉네임인지 확인하는 API 통신

• SetNicknameReactor

  // SetNicknameReactor.swift
  
  enum Action {
      /* ... */
      case confirmButtonTap(text: String)
  }
  
  enum Mutation {
      /* ... */
      case isValid(status: SetNicknameUseCase.TextFieldStatus)
  }
  
  func mutate(action: Action) -> Observable<Mutation> {
      switch action {
          /* ... */
          case .confirmButtonTap(let text):
              let dto = ...
              return setNickNameUseCase.isValidText(dto: dto)
                  .map { Mutation.isValid(status: $0) }
  }

• SetNickNameUseCase

  // SetNickNameUseCase.swift
  
  enum TextFieldStatus {
      case duplicationNickname // 중복된 닉네임
      case unknownError // 알 수 없는 에러
      case validNickname // 사용 가능한 닉네임
      case readyToRequest // API 요청 전
  }
  
  func isValidText(dto: PostIsValidNickNameRequestDTO) -> Observable<TextFieldStatus> {
      let request = setNickNameRepository
                      .postIsValidNickName(dto: dto)
                      .share()
  
      let success = request
                      .compactMap { $0.element }
                      .map { $0 ? TextFieldStatus.validNickname : TextFieldStatus.duplicationNickname } 
  
      let fail = request
                  .compactMap { $0.error }
                  .map { _ in TextFieldStatus.unknownError }
  
      return Observable.merge(success, fail)
  }

• SetNickNameRepository

  // SetNickNameRepository.swift
  func postIsValidNickName(dto: PostIsValidNickNameRequestDTO) -> Observable<Event<Bool>> {
      return provider.log.rx.request(.postIsValidNickName(dto: dto))
          .map(ResponseDTO<PostRefreshTokenResponseDTO>.self)
          .map{ $0.isSuccess }
          .asObservable()
          .materialize()
  }

• 위 코드에서, 응답값이 어떤 방식으로 저장되는지 궁금해서 질문을 드렸다.
  • 응답값의 종류는 다음과 같다.
    • 성공
    • 실패 (닉네임 중복 or 기타 에러)

• 놓치고 있었던 부분은, Observable은 값을 저장하는 역할이 아닌, 값이 흐를 수 있는 파이프라인, 즉 stream을 의미한다.

코드 해석

• SetNickNameRepository

  // SetNickNameRepository.swift
  func postIsValidNickName(dto: PostIsValidNickNameRequestDTO) -> Observable<Event<Bool>> {
      return provider.log.rx.request(.postIsValidNickName(dto: dto))
          .map(ResponseDTO<PostRefreshTokenResponseDTO>.self)    // 응답 DTO로 parsing
          .map{ $0.isSuccess }    // 파싱한 데이터의 isSuccess 필드 확인
          .asObservable()        // Single을 Observable<Bool>로 변환
          .materialize()        // Observable<Event<Bool>>로 변환
  }

  • 서버 응답값은 다음과 같고, statusCode 200으로 통신이 성공하게 되면 isSuccess 값에 true을 보내준다.

    struct ResponseDTO<T: Codable>: Codable {
        let isSuccess: Bool
        let code: String
        let message: String
        let data: T?
    }

  • 닉네임 중복 API의 경우, 응답값이 따로 없기 때문에 Observable<Bool> 타입으로 받게 된다. 성공/실패에 따라 Bool에 흘러가는 값이 달라지게 된다.

  • materialize : Event 형태로 바꿔준다.

    • 나는 개인적으로 Single을 이용해서 응답값을 주로 래핑했는데, 팀원분은 materalize를 사용했다.
    • error, completed를 사용하면 스트림이 끊기는 이슈가 발생할 수 있기 때문에 래핑은 필요하다.
    • Single을 활용하는 것과 materialize를 활용하는 것의 장단점은 따로 공부할 예정이다.

• SetNickNameUseCase

  func isValidText(dto: PostIsValidNickNameRequestDTO) -> Observable<TextFieldStatus> {
    let request = setNickNameRepository
                    .postIsValidNickName(dto: dto)
                    .share()    // 응답 결과는 아직 모른다. Observable<Event<Bool>> 타입
  
    let success = request
                    .compactMap { $0.element }
                    .map { $0 ? TextFieldStatus.validNickname : TextFieldStatus.duplicationNickname }
  
    let fail = request
                .compactMap { $0.error }
                .map { _ in TextFieldStatus.unknownError }
  
    return Observable.merge(success, fail)
  }

  
  
  • share() 사용
    • Observable은 subscribe할 때마다 create을 통해 새로운 Observable을 생성한다. 즉, subscribe를 하는 횟수마다 새로운 Observable이 생성된다.
    • 이를 방지하고자 share를 사용하면, subscribe할 때마다 새로운 Observable이 생성되지 않고, 하나의 Observable 시퀀스에서 방출된 아이템을 공유해서 사용할 수 있다.
    • 여기서는 success와 fail이 하나의 request에 대한 값만 받을 수 있도록 share()를 활용한다.

• compactMap { } 사용

  • compactMap은 해당 값이 존재하면 해당 값을 방출하고, 값이 nil이면 해당 이벤트를 무시한다.

  • 즉, compactMap { $0.element } 는 element가 있는 이벤트만을 방출하고, compactMap { $0.error }는 오류가 발생했을 때만 그 오류를 스트림으로 방출하게 된다.

  • compactMap 사용 예시

    let observable: Observable<Int?> = Observable.of(1, nil, 3, nil, 5)
    observable
        .compactMap { $0 }
      .subscribe(onNext: { print($0) })
    
    // 출력 : 1, 3, 5

  
  

• enum Event

    // Event.swift (RxSwift)
    @frozen public enum Event<Element> {
        case next(Element)
        case error(Swift.Error)
        case completed
    }
  
    extension Event {
        // If 'next' event, returns element value
        public var element: Element? {
            if case .next(let value) = self {
                return value
            }
            return nil
        }
  
        // If `error` event, returns error.
        public var error: Swift.Error? {
            if case .error(let error) = self {
                return error
            }
            return nil
        }
    }

  
  

• merge() : success 또는 fail 둘 중 하나만 방출될 수 있따.

• 데이터의 흐름

  1. Repository -> 네트워크 통신 -> 응답
     • 네트워크 통신 성공 (isSuccess == true) -> Observable<true> : 사용 가능한 닉네임
     • 네트워크 통신 성공 (isSuccess == false) ->Observable<false> : 중복된 닉네임 (사용 불가)
     • 네트워크 통신 실패Observable<Error> : 알 수 없는 에러
  
  
  2. UseCase -> Repo 메서드 실행 -> 응답
     • Observable<true> => .validNickname
     • Observable<false> => .duplicationNickname
     • Observable<Error> => .unknownError

0. 새싹 전

• 대학교 4학년 1학기 끝 (한 학기 남은 상태)
• 컴퓨터공학 복수전공 (주요 CS 전공과목 수강)
• 앨런 Swift 문법 마스터 스쿨 수료 (4학년 1학기와 병행)
• Flutter 만지작 경험 (UI 잡는 정도?)

• iOS 쪽으로 해야겠다 결심한 후, 앨런 강의를 통해 문법을 다지고, 프로젝트 경험의 필요성을 가장 많이 느꼈습니다.
• 복수전공자이기 때문에 교내에서도 특별한 프로젝트가 없었기에 더욱 부트캠프를 고려했습니다.
• iOS 분야를 준비하는 입장에서 고려했던 부트캠프는 네부캠, 새싹, 애플아카데미 정도가 있었고, 결과적으로 새싹에 참여하게 되었습니다.
• 수료한 지 6개월이 지난 지금까지도 너무나 좋은 선택이었다고 생각합니다

1. 지원 과정

1. 자기소개서
   • 구글폼을 통해 자기소개서를 제출합니다.
   • 정말 말 그대로 본인에 대한 자기소개와 개발 경험에 대한 문항이 있었습니다.
   • 저는 컴공을 복전한 내용과 전공과목에서 과제로 진행한 프로젝트에 대해 설명했습니다. 앨런에서 Swift 문법 공부를 한 내용도 적었습니다.

2. 테스트 (23/07/02)
   • 미리 강의를 제공해주시고, 해당 강의 내용 기반으로 오프라인 시험을 봅니다.
   • 강의만 잘 보면 충분히 다 풀 수 있는 난이도로 출제됩니다.

3. 면접 (23/07/04 ~ 23/07/08)
   • 오프라인으로 가서 면접을 보게 됩니다. J님과 H님께서 직접 면접을 봐주십니다.
   • 자세한 내용을 설명할 수는 없지만, 워낙 질문의 폭이 다양하기 때문에 단기적으로 준비할 수는 없다고 생각합니다.
   • 다른 후기를 봐도 열정을 보여주면 된다! 라고 하는데... 제가 열정을 잘 보여드렸던건지... 잘 모르겠습니다. 그래도 아마 잘 봐주신 것 같아요

4. 최종 합격 (23/07/10)
   • 메일로 최종 합격 소식을 받았습니다.
   • 나중에 과정에 참여해서 다른 분들과 이야기를 해보면.. 대부분 내가 왜 여기 붙은지 모르겠다 라는 말씀을 많이 하십니다 ㅎ..
   • 지금 생각해보면 6개월동안 과정 내에서 다양한 사람들을 많이 만났는데, 대부분 너무 좋은 분들이었던 것 같아요. 힘들 때 같이 으쌰으쌰 하면서 서로 동기부여도 시켜주고, 서로 웃겨주면서 정말 재미있게 시간을 보낼 수 있었습니다.
   • 면접관 분들의 시각에는 좋은 분들이 다 보이시나봐요 ㅎ

2. 교육과정

• 아무래도 기간이 6개월이다보니 정말 하고 싶은 이야기가 많지만... 하루종일 이걸 쓰고 있을 순 없으니 주저리주저리 하지 말고 최대한 필요한 이야기만 해보겠습니다

1. 수업

• 월화수목금 오전부터 오후까지 수업을 진행하십니다. 대략 오후 3시까지는 수업이라고 생각하셔야 합니다.
• 수업 퀄리티가 압도적입니다. 강의력은 말 할 것도 없고, 지금 생각하면 내용적인 측면에서 커리큘럼이 너무 좋았던 것 같아요.
• iOS 앱 개발이 아예 처음인 사람에게는 최고의 커리큘럼이었다고 생각합니다. (정말... 그냥 다 알려주세요)
• 여담으로.. 수업해주시는 J님의 강의력은... 제가 여태까지 수강한 강의들(중,고,대 수업, 수능 인강 등등..) 중에서도 정말 탑 급이었습니다. 머리통이 아예 빈 백지인데도 수업을 너무 잘해주셔서 꽉꽉 채울 수 있었어요

• 구체적인 수업 내용을 알고 싶으신 분은 제 블로그나 깃허브 레포(Week1~4, Week 6~10, Week 16~17)를 참고해주시면 될 것 같습니다. 매번 깃허브에 정리하려고 했는데 중간중간 정신 못차리고... 똑바로 안했나봐요.

• 매일매일 수업해주신 내용에 대해 강의자료를 제공해주십니다.
• 강의자료에는 체크리스트, 과제, 미션이 있는데요. 최소한 과제까지는 그날 무조건 끝내야 한다고 생각합니다. (바로 다음날 수업이 있기 때문에, 한 번 밀리면 돌이킬 수가 없어요) 다음날 과제에 대한 리뷰도 해주시기 때문에, 꼭! 과제는 그날 끝내야 합니다

• 그리고 수업 때 적어주시는 코드를 강의자료로 다 제공해주시기 때문에, 수업 때 뇌 빼고 부랴부랴 코드만 적는 것 보다는 내용을 최대한 이해하려고 노력하는 게 더 도움이 되는 것 같아요.
• 어차피 끝나고 못 적은 코드는 동기들이나 멘토님께 물어보면 되기 때문에, 저 같은 경우도 일단 내용을 백프로 흡수하려고 노력을 많이 했습니다.
• 수업 끝나고 프로젝트를 열어보면 코드 반, 주석 반 이었던 것 같아요

2. 프로젝트

• 사실 프로젝트가 메인이라고 할 수 있겠죠. 크게 5번의 프로젝트를 진행했습니다
• 대부분 이 프로젝트를 기반으로 수료 시점에 포트폴리오를 만드시게 됩니다.

1. 1차 리캡 (24/08/05)

• 깃헙 레포

• 일반 과제와 달리, 3~4일 정도의 시간을 주십니다. 간단한 앱을 만드는 과제라고 보시면 되는데요. PDF로 앱의 요구사항을 명시해주시고, 거기에 맞춰서 새로운 프로젝트를 만들면 됩니다.
• 과정을 시작한 지 3주 정도 후에 진행했기 때문에, 아주 애기애기스러운 코드를 적게 됩니다. 지금은... 열어보고 싶지 않아요

• 사실 리캡의 하이라이트는 본인이 만든 프로젝트보다, 피드백입니다. 내가 이걸 공짜로 받아도 되나 싶은 정도의 퀄리티로 피드백을 주세요...
• 정말 제 프로젝트를 다 뜯어보시고, 모든 빈틈에 대한 피드백을 주십니다... 아마 수료하신 분들은 다 느끼실 거에요

2. 2차 리캡 (24/09/07)

• 깃헙 레포
  • 이 때 당시 리드미를 어떻게 쓰는지 아예 몰라서.. 그냥 무작정 생각나는 내용을 다 적었습니다. 나중에 수정해야겠다~ 생각했는데, 가끔 보고 읽어보면 옛날 생각도 나서 그냥 내버려 뒀습니다.

• 형식은 1차 리캡과 크게 다른 점은 없습니다.
• 다만, 이 때부터는 본격적으로 포폴에 적을만한 기술 스택을 사용하기 때문에, 대부분 2차 리캡으로 진행한 프로젝트를 포트폴리오에 추가하셨습니다.

• 이때는 왜 그랬는지 몰라도 정말 혼을 갈아서 프로젝트를 만들었던 것 같습니다. 이왕 제출하는거 제대로 한 번 해보자 생각했던 것 같아요.
• 모든 예외처리를 하려고 노력하고, 요구사항에 명시되지 않았지만 일반적으로 사용자가 기대하는 기능도 구현하고... 그런데도 어마어마한 피드백을 보고 아직 멀었구나... 생각하면서 현타가 왔던 기억이 있네요 ㅎ..

3. 개인 앱 (24/09/25)

• 깃헙 레포

• 웬만큼 수업이 진행된 후, 대략 한달 간 개인 앱 프로젝트를 진행하게 됩니다.
• 기획부터 디자인, 개발 및 배포까지 모두 혼자 진행해야 하기 때문에 생각하지 못한 지점에서 시간이 많이 소요됩니다. 미리미리 어떤 앱을 만들지, 그리고 어떤 UI로 만들지 생각을 해둬야 개발에만 진심으로 임할 수 있습니다.

• 저는 생각보다 일정이 미뤄지지 않았고, 나중에 가니까 지쳐서 뭘 더 하려고 하지 않았던 것 같습니다... 좀 더 힘을 냈으면 어땠을까 하는 아쉬움이 있어요

4. Light Service Level Project (LSLP) (23/11/27)

• 깃헙 레포

• 원래 계획된 프로젝트는 아니지만, 교육생 분들의 빵빵한 포트폴리오를 위해 새롭게 만드신 과정이라고 하셨어요!
• 이전까지의 프로젝트와 다른 점은, 서버를 제공 해주십니다. 다양한 API를 제공해주시고, 그걸 활용해서 본인만의 앱을 만드는 프로젝트였습니다.
• 개인적으로 이 때, 네트워크 코드 추상화랑 네트워크 에러 처리 공부하기가 정말 좋았습니다.

• 프로젝트가 완성되면, 본인의 서비스를 발표하는 대회가 열립니다. (우당탕탕 LSLP 경진대회) 열심히 준비해서 내가 개발한 내용을 발표할 수 있어서 굉장히 뿌듯했던 기억이 있습니다.

5. Service Level Project (24/01/01)

• 깃헙 레포

• 그냥 미쳐버린 프로젝트입니다. 이 정도 스케일을 경험할 수 있어서 정말 감사하면서 진행했던 프로젝트였어요
• 뭐 온갖 내용, 이슈 다 나오는데 그 과정에서 얻어가는 게 정말 많았습니다.
• 과정 기간동안 열심히 뛰어오셨다면, 아마 이 때 정말 포텐이 터지실 거에요. 개인적으로 저는 그랬던 것 같습니다

• 프로젝트 내용에 대해서는 리드미에 적어뒀기 때문에 생략하겠습니다. (사실 리드미에 까먹고 못 쓴 내용도 한 바가지 나옵니다... 미쳐버린 프로젝트에요)

3. 면접준비

• 수료 시점이 다가오면 슬슬 취업준비를 하시게 됩니다. 이력서 + 리드미 + 포폴을 모두 만들고 나면 서류 지원을 시작하게 되고, 면접을 보게 되겠죠.
• 면접 질문 리스트를 제공해주시고, 모의 면접을 봐주십니다

• 사실 저는 이 경험을 해보지 못했지만,, 동기 분들의 이야기를 들어보면 큰 도움이 되었다고 합니다.

3. 기타

1. 노력한 점

1. 기록

• 위에 말씀드렸듯이 수업 일정이 굉장이 빽빽하고 내용이 방대하기 때문에, 제대로 정리해두지 않으면 다 잊어버리겠다 생각했습니다. (기억력에 한계가 있기 때문에...)
• 주변 분들을 보니까 노션을 많이 쓰시더라구요. 전 이 때 처음 노션을 사용했는데, 좋은 선택이었다고 생각합니다.

• 수업 내용 + 복습 내용 을 정리했습니다. 아무래도 수업 때 따라 적다보면, 형식 없이 으아아악 하고 받아적게 되는데요. 수업이 끝나고 나면 내용을 다시 읽어보면서, 또 따로 구글링해야하는 건 하면서, 그 날 내용을 정리했습니다.

• 깃허브 레포 를 따로 파서 코드도 모두 정리했습니다. 지금 생각하면 초반에는 거의 매일매일 프로젝트를 새로 만들고, 처음부터 코드를 다시 적는 걸 반복했던 것 같아요. 리드미를 좀 더 자세하게 적어두었다면 어땠을까 하는 아쉬움이 있습니다.

• 매주 1개 이상 블로그 포스트를 작성했습니다. 사실 꾸준함을 보여주기 위한 가장 좋은 지표로 보일 수 있다고 생각했기 때문에, 그 주에 수업에서 배운 내용 또는 스스로 공부한 내용을 정리해서 블로그에 작성했습니다.

2. 플러스 알파

• 개인적으로 6개월동안 많이 성장하고 싶은 생각이 있었기 때문에, 수업에서 배운 내용에서 좀 더 뭘 해보려고 했습니다.

• 기본적으로 과제가 나오면, 이전에 배웠던 내용을 접목시켜서 추가적인 기능을 구현하려고 많이 노력했습니다. 이게 나중에 갈수록 배웠던 양이 정말 많아지는데, 이 과정에서 스스로 복습이 많이 되었던 것 같습니다.

3. 알고리즘

• 시간이 지나면서 항상 딜레마였던 것 중 하나입니다.
• iOS를 더 열심히 공부할까 vs. 알고리즘 병행할까*
• 새싹 중간에 이전 기수분들과 만날 수 있는 시간이 있었는데, 이전 수료생 분께서 알고리즘은 하는 게 좋다는 뉘앙스를 듣고 저는 후자를 선택하게 되었습니다.

• 매일 한 문제 이상 풀려고 노력했습니다. 백준 보니까 67일 연속으로 문제를 풀었다고 나오네요.

  

  

• 사실, 수업이 끝나고 복습하고 과제하면 밤이 됩니다. 그래서 문제 풀 시간이 없어요. 그래서... (이 때 무슨 광기였는지 모르겠는데) 아침 8시까지 새싹에 가서 수업 전에 1~2시간 문제 풀고 수업에 들어갔습니다.
• 아마 안풀었다면 수업 시간에 맞춰서 새싹에 갔을 거라서, iOS와 알고리즘 두 마리 토끼를 다 잡을 수 있지 않았나 생각합니다.

4. 오프라인

• 아무래도 새싹이 역세권도 아니고, 서울 왼쪽에 있기 때문에 통학 시간이 부담스러우신 분들이 많습니다. 그래서 주 2회만 필수 오프라인으로 진행하고, 주 3회는 온라인 줌으로 수업을 진행합니다.
• 저는 코로나 대학 시절을 경험했는데요, 정말 온라인이랑 맞지 않는 사람이라는 걸 뼈저리게 느꼈습니다. 그냥... 수업 틀어놓고 밥먹었던 것 같아요..
• 아무튼 그래서 저는 무조건 오프라인 수업에 참여했습니다. 6개월 동안 시설 공사할 때 빼고는 단 한번도 온라인으로 수업에 참여한 적이 없습니다. 당연히 지각한 적도 없고요.

• 나중에 동기분들과 친해지고 나서, 주말에도 다같이 공부했습니다. 사당역 근처에 좋은 공유오피스가 있어서, 주로 거기에 가서 다같이 으쌰으쌰 할 수 있었어요. (토요일에는 새싹도 열어서 새싹으로도 몇 번 갔어요)

• 그니까... 지금 보면... 그냥 맨날 나가서 공부했네요.. 열품타를 이렇게 태워본 적이 없는 것 같습니다.

2. 아쉬운 점

1. 알고리즘

• 좀 더 했으면 어땠을까 하는 아쉬움이 있습니다. 사실 2달 공부했다 해서 금방 실력이 오르는게 아니기 때문에, 미리 좀 시작했다면... 하는 아쉬움이 남아요.
• 솔직히.. 막상 하니까 시간은 핑계였구나 라는 생각이 들었기 때문에 더욱 아쉬움이 남는 것 같습니다.

2. 프로젝트별 정리

• 저는 거의 매일 새로운 프로젝트를 만들었습니다. 근데 그렇게 하지 말았어야 했어요.

• 예를 들어,

  1. 영화 리스트를 볼 수 있는 화면을 Storyboard로 구현
  2. 영화 리스트를 볼 수 있는 화면을 Code based로 구현
  3. TMDB API를 활용해서 영화 리스트 화면 구현
  4. Realm을 이용해서 영화 리스트에 좋아요 기능 구현

• 이 내용이 다 다른 날에 과제로 나옵니다. 그럼 저는 그냥 귀찮아서 매일 새로운 프로젝트를 만들고, 다시 처음부터 뚝딱뚝딱 만들었어요. (스토리보드였던거 스냅킷으로 바꾸는거 귀찮아ㅏㅏㅏ 하면서...)

• 하지만, 만약 하나의 프로젝트에 이렇게 조금씩 구현하다보면 그 자체가 하나의 포트폴리오용 프로젝트가 됩니다. 그때그때 구현한 내용을 정리도 잘 해두었다면, 더 좋은 퀄리티로 만들 수 있겠죠.
• 과거의 내가 왜 그랬을까... 하는 아쉬움이 있습니다.

• 결과적으로 제가 과제로 만들었던 모든 프로젝트는 실력 향상에는 도움이 되었지만, 뭔가 정리해서 내세울 수는 없는 결과물들이 되었습니다ㅠ

3. 공수산정

• 큼직큼직한 프로젝트를 시작하기 전, 항상 J님께서 강조하십니다.
• *"미리미리 공수산정 잘 해두시고, 계획 내용 & 진행 과정 등등 잘 정리해두세요!"** 제발 좀 잘 정리해두어야 합니다ㅠㅡㅠ

• 처음엔 열심히 합니다. 한 일주일..? 그 다음부터는 개발하느라 지쳐서 뭐 노션 켜지도 않아요.... 이러지 말았어야 했는데....
• J님이 말씀하신 것처럼 매일 30분은 텍스트로 기록한다고 생각하고 미리미리 정리해두어야 합니다....
• 포폴이랑 리드미 쓸 때 코드 보려고 프로젝트 여니까 그냥 지옥이었어요....

• 뮤로그 공수산정

  

• LSLP 공수산정

  

• SLP 공수산정

  

  

3. 마무리

• 어쨌든 벌써 수료한 지 6개월이 지나가지만, 아직까지도 정말 좋은 기억으로 남아있습니다.
• 실력적으로도 너무나 큰 성장을 할 수 있었고, 멘토님들과 동기분들처럼 좋은 사람들을 만날 수 있었어요. 지금도 꾸준히 연락하면서 싱글벙글 놀고 있습니다.
• 인생을 살면서 이런 경험을 할 수 있었다는 게 너무 감사하고, 소중한 기억으로 남을 것 같아요.

• 만약 누군가 새싹 iOS를 추천하냐고 물어본다면, 잔말 말고 빨리 자소서 쓰라고 하고 싶습니다!!

긴 글 읽어주셔서 감사합니다. 궁금하신 점 있으시면 편하게 알려주세요

int arr[10000];
vector<int> v;

1. 초기화, 제거

fill(arr, arr + n, 0);    // 0으로 초기화 (bfs).
fill(v.begin(), v.end(), 0);

memset(arr, 0, sizeof(arr));    // memset. 빠름.

v.clear();    // 크기까지 없앤다.

// remove - size 변화 없음 (다른 값으로 대체)
remove(v.begin(), v.begin() + 10, 3);
// erase - size 변화 있음 (뒤에 있는거 당김)
v.erase(v.begin(), v.begin() + 10);

2. 정렬

sort(arr, arr + n);
sort(v.begin(), v.end());
sort(v.vegin(), v.end(), greator<int>());    // 내림차순

// 사용자 정의
bool compare(int, a, int b) {
    return a < b;
}
sort(v.begin(), v.end(), compare);

3. 최대 최소

*max_element(arr, arr + n);    // 최댓값
*max_element(v.begin(), v.end());
*min_element(arr, arr + n);    // 최솟값
*min_element(v.begin(), v.end());

string, char, int

1. 타입 변환

// char -> int
char ch = '1';
int i = ch - '0';

// int -> char
int i = 3;
char ch = i + '0';

// int -> string 
int i = 10010;
string s = to_string(i);

// string -> int 
string s = "10010";
int i = stoi(s);

// string -> *char
string s = "Hello World";
char *ch = s.c_str();
char ch2[100];
strcpy(ch2, s.c_str());

2. find

// 문자열 포함 여부 확인
string s1;
string s2;
if (s1.find(s2) == string::npos) { cout << "Not Found"; }
else { cout << "Found"; }

// 문자열 내부의 문자열 제거
while (s1.find(s2) != string::npos) {
    size_t pos = s1.find(s2);
    s1.erase(pos, s2.size());
}

Engineering For Testability

1. Testable app code
   • Testable한 코드가 무엇인지 알고, App 코드를 Testable하게 개선하는 방법

2. Scalable test code
   • 앱의 크기나 복잡성이 커져도 대응 가능한 확장성 있는 Test 코드를 작성하는 방법

1. Testable App Code

Unit Test의 구조

• AAA 패턴 : (Arrange - Act - Assert)
  • input : Arrange
  • test : Act
  • output : Assert

Testable Code의 특징

• Control over inputs
  • 입력을 제어할 수 있어야 한다
• Visibility into outputs
  • 출력을 검사할 수 있어야 한다
• No hidden state
  • (코드 동작에 영향을 줄 수 있는) 내부 상태에 의존하지 말아야 한다

Testability Techniques

1. Protocols and Parameterization

Sample View

• segment control (View / Edit) + button (open)

Testable하지 않은 코드

• 버튼 클릭 시 동작하는 메서드
  • URL 구성하는 비즈니스 로직
  • UIApplication 을 통해 URL에 해당하는 앱 전환

• Unit Test 실행
  • (Arrange - Act - Assert) 에서 Assertion을 해야 하는데, 앱을 전환하기 위해 생성된 URL을 검사할 방법이 없다.
  • XCTAssertTrue(예상 URL == Output URL) 을 해야 하는데, url 자체를 꺼내올 수 없는 상황

코드의 문제점

1. 비즈니스 로직(메서드)이 VC에 있다
   • 테스트 시 VC를 생성해야 함

2. 뷰의 입력 상태(segmentControl.selectedsegmentIndex)를 직접 가져온다
   • 테스트 시 뷰의 속성값을 지정해서 간접적으로 입력을 제공주어야 함

3. UIApplication 인스턴스 사용

4. canOpenURL의 반환값에 따라 openTapped의 동작 변화
   • 제어하지 못하는 input이 되어버림.

5. open을 통해 앱을 열었을 때 side effect에 대한 Unit Test 작성 불가
   • 추가적으로, 앱을 다시 foreground로 가져올 방법이 없다.

Testable한 코드 만들기

1. 비즈니스 로직을 VC에서 분리
   • DocumentOpener 라는 클래스 생성 후 로직 이동
   • 테스트 시 VC 생성할 필요 x
   • document와 mode 매개변수를 넣어줄 수 있게 해서 뷰의 상태 가져올 필요 x

2. UIApplication 주입
   • 생성자에서 UIApplication 인스턴스 주입
   • DocumentOpenr에서 직접 호출하지 않도록 함

3. testDocumentOpenerWhenItCanOpen (NOT completed)

   
   • Test를 위해 app 인스턴스를 만들어서 넘겨주어야 한다.
   • 하지만, 타입인 UIApplication을 맞춰주어야 하는데,
     UIApplication은 싱글톤이기 때문에 인스턴스를 생성하려고 하면 에러가 발생한다.
   • 그렇다고 UIApplication을 상속하려고 해도, 싱글톤 성격을 강제하기 때문에 예외가 발생할 수 있다. (And throws an exception to try to make a second instance, even if it's a subclass)

4. 필요한 메서드를 가진 프로토콜 생성 후 생성자 타입 변경
   • 이미 UIApplication에 구현된 메서드를 선언하면, 추가적으로 구현할 필요가 없다
   • 이미 매개변수의 개수와 타입이 완벽히 일치하는 메서드들이 구현되어 있기 때문
   • 메서드 시그니쳐가 동일하다*

5. 제어가 불가능한 UIApplication 대신 제어가 가능한 Mock 객체 생성
   • 프로토콜을 준수하는 Mock 객체 생성
   • canOpenURL은 DocumentOpener로부터의 인풋처럼 행동
     • Test가 컨트롤해야 함
   • open 은 DocumentOpener의 출력처럼 행동
     • Test는 이 메서드를 통과하는 URL에 접근하고자 함. -> 프로퍼티에 저장해두고 나중에 Test가 읽을 수 있도록 함

6. testDocumentOpenerWhenItCanOpen (Completed)
   • Mock 객체를 DocumentOpener의 생성인자로 넘겨준다.
   • DocumentOpener의 open 메서드에 input
   • 예상 URL과 mock의 URL 비교 후 검증 (assert)

Summary

• Reduce references to shared instances & Accept parameterized input
  • UIApplication 싱글톤 인스턴스에 대한 직접 참조를 없애고, 매개변수화된 Input으로 대체
  • 의존성 주입*

• Intoduce a protocol
  • 클래스에 직접 의존하기보다는 프로토콜을 이용하여 인터페이스 분리

• Create a testing implementation
  • 테스트 시 UIApplication 객체를 mock 객체로 대체

2. Separating Logic and Effects

Sample

• 캐시에 저장할 아이템을 정의한 구조체 + 저장된 아이템을 불러오는 프로퍼티

• cleanCache(maxSize: Int) : 캐시 저장 용량을 초과한 아이템을 비워주는 메서드

특징

• Input 1 : 캐시의 저장 용량.
  • 저장 용량은 인자로 넣어줄 수 있기 때문에 제어 가능하다

• Input 2 : 캐시에 저장된 아이템 (FileManager)
  • 캐시에 저장된 아이템을 불러오기 위해 FileManager 사용
  • • -> 실제 File System에 대한 의존성을 가지고 있다는 문제 발생**

      side effect : 메서드가 외부의 속성을 변경하는 것. ex). 메서드 호출 시 전역 변수 변경

  • 따라서, cleanCache 메서드를 통해 실제 File System의 아이템이 clean 되는 게 아니라, 어떤 것을 clean할 지 리턴 값으로 주는 것이 더 낫다!

Protocols and Parameterization 도입

• FileManager에 직접 의존하지 않으면서, 아이템을 받으면 뭘 삭제할지 반환하는 구조로 만들어야 한다.
• 또한, 어떤 캐시 정책으로 아이템을 관리할지도 분리한다

• 직접 지우는 코드와 뭘 지울지 결정하는 코드 분리 가능

1. 캐시에 있는 아이템 받아서 뭘 삭제할지 반환하는 프로토콜
   • 

2. 삭제할 아이템 반환 메서드 구현
   • 
   • 

3. testMaxSizeCleanupPolicy
   1. input 정의
   2. 메서드 호출
   3. Output 받아
   4. 예상 값과 일치하는지 확인
   • Testable Code의 특징 만족
     • 입력 제어 가능
     • 출력 검사 가능
     • 그 외에 어떤 영향을 주는 hidden state x

4. cleanCache
   • 프로토콜을 채택한 구조체를 paramter로 받고 해당 캐시 정책을 통해 어떤 아이템 제거할지 리턴으로 받는다.
   • 즉, cleanCache에는 실제 데이터에 영향을 주는 side effect만 남게 되었다

Summary

• Extract algorithms
  • side effect를 고려하여 비즈니스 로직과 알고리즘 분리

• Functional style with value type
  • Input과 Output을 보이기 위해 값 타입을 사용하는 functional style
  • 알고리즘이 input과 output을 보일 때, functional style을 취한다.

• Thin layer on top to execute effects
  • cleanCache 메서드는 side effect를 일으키는 소량의 코드만 존재 (side effect : FileManger를 통해 외부 실제 데이터에 영향 주는 것)

레퍼런스

https://gist.github.com/timd/3acdb6aa75efb40c03bb25cb60709c6d

[Unit Test] Testable한 코드를 위한 2가지 스킬과 예제 [WWDC17] Engineering for Testability 정리 (1) Testable App Code WWDC2017 Engineering for Testability / Testable App Code - 번역

실시간 장소 검색	Apple Map Annotation

1. 실시간 장소 검색

View

• 검색할 텍스트를 입력할 searchBar, 결과를 나타낼 tableView

  let searchBar = {
      let view = UISearchBar()
      view.placeholder = "떠나고 싶은 장소를 검색하세요"
      view.backgroundImage = UIImage()
      view.searchTextField.backgroundColor = UIColor.appColor(.inputGray)
      return view
  }()
  
  let tableView = {
      let view = UITableView(frame: .zero, style: .plain)
      view.register(SelectLocationTableViewCell.self, forCellReuseIdentifier: "SelectLocationTableViewCell")
      view.rowHeight = 66
      view.separatorInset = UIEdgeInsets(top: 0, left: 18, bottom: 0, right: 18)
      view.contentMode = .scaleAspectFill
      return view
  }()

필요 변수

• searchCompleter: 입력한 문자열에 대해 해당되는 장소를 검색

• searchResults : 검색 결과 장소 배열 저장

• localSearch : 검색된 장소의 정보 저장

  
  private var searchCompleter = MKLocalSearchCompleter()
  private var searchResults = [MKLocalSearchCompletion]()
  
  private var localSearch: MKLocalSearch? = nil {
      willSet {
          localSearch?.cancel()
      }
  }

setting

• delegate 설정

  
  func settingSearch() {
      mainView.searchBar.delegate = self
  
      searchCompleter.delegate = self
      searchCompleter.resultTypes = .pointOfInterest
  }
  
  func settingTableView() {
      mainView.tableView.delegate = self
      mainView.tableView.dataSource = self
  }

UITableViewDataSource

• searchResults 의 요소를 테이블뷰에 나타냄

  extension SelectLocationViewController: UITableViewDataSource {
  
      func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
          return searchResults.count
      }
  
      func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
          guard let cell = tableView.dequeueReusableCell(withIdentifier: "SelectLocationTableViewCell", for: indexPath) as? SelectLocationTableViewCell else { return UITableViewCell() }
  
          cell.titleLabel.text = searchResults[indexPath.row].title
          cell.subTitleLabel.text = searchResults[indexPath.row].subtitle
  
          return cell
      }
  }

UISearchBarDelegate

• searchBar에 실시간으로 텍스트가 입력될 때마다 searchCompleter.queryFragment에 텍스트를 넘겨주어서 해당하는 장소를 검색하도록 한다

  extension SelectLocationViewController: UISearchBarDelegate {
  
      func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) {
          // 서치바에 입력할 때마다 텍스트 넘겨주기
          if searchText.count != 0 {
              searchCompleter.queryFragment = searchText
          }
      }
  }

MKLocalSearchCompleterDelegate

• searchCompleter의 장소 검색에 대한 결과

  extension SelectLocationViewController: MKLocalSearchCompleterDelegate {
  
      func completerDidUpdateResults(_ completer: MKLocalSearchCompleter) {
          searchResults = completer.results  
          mainView.tableView.reloadData()
      }
  
      func completer(_ completer: MKLocalSearchCompleter, didFailWithError error: Error) {
          print("location 가져오기 에러 발생 : \(error.localizedDescription)")
      }
  
  }

UITableViewDelegate

• 셀을 클릭했을 때, 해당 장소에 대한 정보 전달 (delegate pattern)

  extension SelectLocationViewController: UITableViewDelegate {
      // MKLocalSearchCompletion 타입 데이터
      func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
          tableView.deselectRow(at: indexPath, animated: true)
          search(for: searchResults[indexPath.row])
      }
  
      // searchRequest 생성
      func search(for suggestedCompletion: MKLocalSearchCompletion) {
          let searchRequest = MKLocalSearch.Request(completion: suggestedCompletion)
          search(using: searchRequest)
      }
  
      // 장소 정보
      func search(using searchRequest: MKLocalSearch.Request) {
          searchRequest.resultTypes = .pointOfInterest  // 검색 유형
  
          localSearch = MKLocalSearch(request: searchRequest)
  
          localSearch?.start { [weak self] (response, error) in
              guard error == nil else { return }
  
              guard let place = response?.mapItems[0] else { return }
  
              // 데이터 전달하기 위해 필요한 정보 : 이름, 주소, 위도, 경도
              let placeName = place.name ?? ""
              let placeAddress = place.placemark.title ?? ""
              let placeLatitude = Double(place.placemark.coordinate.latitude)
              let placeLongtitude = Double(place.placemark.coordinate.longitude)
  
              self?.delegate?.sendLocation?(
                  name: placeName,
                  address: placeAddress,
                  latitude: placeLatitude,
                  longitude: placeLongtitude
              )
  
              self?.navigationController?.popViewController(animated: true)
          }
      }

2. Apple Map 위치 표시

Model

• 장소 정보에 대한 구조체

  struct TourLocation: Codable {
      let name: String
      let address: String
      let latitude: Double
      let longtitude: Double
  }

View

• MKMapView 사용

  // 뷰 객체 선언
  let locationView = {
      let view = MKMapView()
      view.clipsToBounds = true
      view.layer.cornerRadius = 10
      return view
  }()
  
  // 뷰 업데이트
  func setUpMapView(sender: TourLocation) {
  
      // 위도, 경도 설정
      let centerLocation = CLLocationCoordinate2D(
          latitude: locationStruct.latitude,
          longitude: locationStruct.longtitude
      )
  
      // 지도에 표시할 범위
      let region = MKCoordinateRegion(
          center: centerLocation,
          latitudinalMeters: 100,
          longitudinalMeters: 100
      )
  
      // annotation (pin 설정)
      let annotation = MKPointAnnotation()
      annotation.title = locationStruct.name
      annotation.coordinate = centerLocation
  
      // locationView 세팅
      locationView.addAnnotation(annotation)
      locationView.setRegion(region, animated: true)
  }
  

레퍼런스

• Interaction with nearby points of interest
• [iOS] 위치 자동완성 검색
• [iOS] MapKit 사용해서 위치 자동완성 검색 기능 구현해보기

기술 스택

UIKit, RxSwift MVVM - C, Input / Output Realm, Alamofire, Socket.IO Sooda 깃허브 레포

1. 소켓 연결 / 해제 시점

1 - 1. 초기 데이터 불러오는 과정 중 소켓 오픈 시점

초기 채팅 데이터 불러오는 로직

채팅방 진입 시, 초기 데이터를 불러오는 로직은 다음과 같다.

1. Realm realm 탐색 후 저장된 채팅의 마지막 날짜 조회
2. HTTP 해당 날짜를 cursor_date 파라미터로 추가하여 읽지 않은 채팅 데이터 요청
3. Realm 응답받은 읽지 않은 채팅 데이터 디비에 저장
4. Realm 읽은 채팅 n개, 읽지 않은 채팅 n개 디비에서 조회 후 VM 배열에 추가
5. View 뷰 업데이트

위 과정에서 소켓을 오픈하는 적절한 시점이 언제일지 고민했다

• HTTP에서 응답받은 데이터 이후의 채팅 데이터를 소켓으로 받는 것이 가장 이상적이다

• 2에서의 HTTP 통신을 간단하게 그려본다면 다음과 같다
  • 1. send request 에서 소켓 오픈 : 1 ~ 3 사이에 오는 채팅을 중복으로 받게 된다. (HTTP, 소켓)
    
  • 4. receive response 에서 소켓 오픈 : 3 ~ 4 사이에 오는 채팅이 누락된다. (HTTP, 소켓 어디서도 받을 수 없다)
    
  • 2 receive request, 3. send response 시점에 소켓을 열어주는 게 가장 좋다고 생각했지만, 이 시점을 클라이언트에서 파악할 수는 없다..

• 최종적으로 내가 소켓 오픈으로 결정한 시점은 1. send request 이다.
  • 중복으로 받는 채팅은 DB에 추가할 때 예외처리를 해서 걸러줄 수 있지만, 누락되는 채팅은 다시 받아올 방법이 없다.
  • 따라서 응답받은 채팅을 DB에 저장할 때, 이미 저장된 채팅 데이터인지 확인하는 로직을 추가한다
  • 이를 통해 소켓 통신과 HTTP 통신의 데이터 중복 이슈를 해결하고, 서버 오류로 인한 중복 데이터 응답에 대해서도 대응할 수 있다

• HTTP 통신 + 소켓 오픈

  /* HTTP 통신 + 소켓 오픈 */
  private func fetchRecentChatting(completion: @escaping () -> Void) {
  
      // 요청 모델 생성 (cursor date 포함)
      var requestModel = /* ... */
  
      // HTTP 요청 - Repo에서 DB에 넣어주는 작업까지 진행
      channelChattingUseCase.fetchRecentChatting(
          channelChattingRequestModel: requestModel,
          completion: completion
      )
  
      // 소켓 오픈 및 응답 대기 <- HTTP 응답이 오기 전에 실행 (completion x)
      self.openSocket()
      self.receiveSocket()
  }

• DB에 채팅 데이터 저장

  /* DB에 채팅 데이터 저장 */
  func addChannelChattingData(dtoData: ChannelChattingDTO, workSpaceId: Int) {
  
      guard let realm else { return }
  
      // 0. 디비에 저장하려고 하는 채팅이 이미 디비에 있는 채팅인지 확인하는 작업
          // - 서버 오류로 인해 중복된 채팅을 받을 가능성이 있음
          // - request를 보냄과 동시에 소켓이 오픈되기 때문에, 서버 입장에서 request를 받기 전, 소켓을 통해 이미 디비에 채팅이 저장될 가능성이 있음.
      if let _ = realm.objects(ChannelChattingInfoTable.self).filter("chat_id == %@", dtoData.chat_id).first {
          print("디비에 이미 있는 채팅. 걸러")
          return
      }
  
      /* ... */
  }

1 - 2. 소켓 open / close 시점

• 기본적으로 채팅 화면이 나타났을 때 open, 화면이 사라졌을 때 close가 되어야 하기 때문에 viewWillAppear 와 viewWillDisappear 에 해당 코드를 작성하였다.

  override func viewWillAppear(_ animated: Bool) {
      super.viewDidAppear(animated)
  
      loadData()    // connectSocket 포함
      startObservingSocket()
  }
  
  override func viewWillDisappear(_ animated: Bool) {
      super.viewWillDisappear(animated)
  
      viewModel.disconnectSocket()
      removeObservingSocket()
  }

  • 채팅 화면에서 push 로 화면 전환이 더 일어날 수 있기 때문에 viewDidLoad 에서 실행하지 않았다.

• 추가적으로 앱이 백그라운드로 나갔을 때 close, 포그라운드로 들어왓을 때 open이 되어야 한다. 이 작업을 하지 않으면, 불필요하게 계속 소켓이 연결되어 있을 수도 있다.
  • SceneDelegate의 sceneDidBecomeActive 와 sceneDidEnterBackground 에 해당 코드를 작성한다.
  • 채팅 화면에서 해당 시점을 알게 하기 위해 NotificationCenter 를 활용한다.
  • 소켓이 연결되어 있는 상태에서 백그라운드로 나가면, 소켓 연결 해제 하고, 다음에 포그라운드로 들어올 때 소켓을 연결해야 한다는 신호를 남겨둔다

/* VC */
// 노티 등록
private func startObservingSocket() {
    // SceneDidBecomeActive에서 소켓 재연결의 필요성을 확인하고, 노티를 보낸다 -> loadData
    NotificationCenter.default.addObserver(
        self,
        selector: #selector(socketReconnectAndReloadData),
        name: NSNotification.Name("socketShouldReconnect"),
        object: nil
    )
}

@objc
private func socketReconnectAndReloadData() {
    print("Scene에서 연락 받음 : 다시 소켓 연결해야 함!\n")

    self.loadData()
}

// 노티 제거
private func removeObservingSocket() {
    NotificationCenter.default.removeObserver(
        self,
        name: NSNotification.Name("socketShouldReconnect"),
        object: nil
    )
}

/* SceneDelegate */
func sceneDidEnterBackground(_ scene: UIScene) {

    // 소켓이 연결되어 있는 상태에서 백그라운드로 앱을 보내면,
    // 1. 일단 소켓 끊어주고
    // 2. 다시 포그라운드 진입 시 소켓 연결하도록 한다
    if socketManager.isOpen {
        socketManager.closeConnection()      // 1.
        socketManager.shouldReconnect = true // 2.
    } else {
        socketManager.shouldReconnect = false
    }
}

func sceneDidBecomeActive(_ scene: UIScene) {

    if socketManager.shouldReconnect {
        // Notification Center로 해당 화면(채팅 화면 - 소켓이 열리는 화면)에 노티 보내기
        NotificationCenter.default.post(
            name: NSNotification.Name("socketShouldReconnect"),
            object: nil
        )
    }
}

• 이 과정에서 같은 소켓에 대해 중복된 handler를 등록할 수가 있기 때문에, 소켓 연결 해제 시 반드시 removeAllHandler 를 실행시킨다.

  /* SocketIOManager */
  func closeConnection() {
      socket.disconnect()
      socket.removeAllHandlers()
      self.isOpen = false
  }

  • 소켓 이벤트 중복 이슈

  중복된 handler로 인해 여러 개의 채팅을 받는 것처럼 동작

2. 서버와 로컬 DB 데이터 동기화

• 현재 로컬 DB (realm) 에는 채팅 정보 외에도 채팅이 이루어지는 채널 정보와 채팅을 전송/수신 하는 유저 정보 가 저장되어 있다.

• 즉, 채팅 데이터를 DB에 저장할 때, channel_ID 와 user_ID 를 DB에서 탐색해서, 이미 저장된 데이터라면 해당 데이터를 FK로 연결하여 채팅 데이터를 저장한다

• 하지만, 만약 유저 정보 (user_name, user_profileImage) 또는 채널 정보 (channel_name) 이 서버에서 수정되었다면 문제가 생긴다.

• 로컬 DB 데이터가 업데이트되지 않으면 같은 유저인데도 채팅방에서 다른 유저처럼 보이는 이슈가 생긴다

• 따라서 채팅방에 들어간 시점에, 항상 채널 정보와 유저 정보 api를 통해 최신 데이터를 받고, 로컬 DB를 업데이트한다!

• 한계 : 결국 업데이트 되는 시점은 정해져 있기 때문에, 해당 시점을 통하지 않는다면 동기화가 되지 않는다. 즉, 채팅방 내에 있을 때 변경되는 데이터에 대해서는 반영할 수 없다.

• 동기화되지 않은 경우와 동기화(해결)한 경우

  동기화 o	동기화 x

3. 같은 디바이스에 다른 계정으로 로그인하는 경우 - 로컬 DB 공유 이슈

• 프로젝트에서는 사용자가 읽은 채팅 을 로컬 DB (realm) 로 관리한다.
• 프로젝트에서는 로그인/로그아웃 이 가능하기 때문에 여러 계정이 로그인할 수 있다.

• 위의 2가지 기획을 구현 중, 여러 계정이 로컬 DB를 공유하는 이슈를 경험하였다.
  • 단순히 기기의 realm 파일을 하나 생성해서 채팅 데이터를 다 저장하면, 여러 계정의 데이터가 당연히 섞여서 들어가게 된다.
  • 이렇게 되면 A 계정에서 읽은 채팅을 B 계정에서는 읽지 않았는데, 읽음 처리가 된다.
  • 서버에 요청하는 pagination date도 비정상적으로 받아오게 된다.

• 위 이슈를 해결하기 위해 여러 방법을 생각해 보았다.

1. 새 계정 로그인 시 DB 초기화

• 데이터 공유 이슈 해결
• 새로운 계정으로 로그인 시 이전 계정의 데이터가 모두 손실되기 때문에 서비스적으로 좋은 방법은 아니라고 생각

2. 채팅 테이블에 '수신자' column 추가

• 각 유저의 고유한 user ID 를 이용해서 채팅 데이터가 realm에 저장되는 테이블에 column을 하나 추가한다.
• 유저 별 데이터가 분리되기 때문에 데이터 공유 이슈 해결
• DB 데이터를 지워야 할 필요 없기 때문에 데이터 손실 문제 해결

• PK 변경 필요 : (chat ID) -> (chat ID, receive user ID)
• 데이터 추출할 때마다 receive user ID 필요 -> 코드 유지보수 측면에서 좋은 방법은 아니라고 생각

3. 계정 간 별개의 DB 파일 생성 (채택)

• realm의 configuration을 이용하여 계정 별 별개의 realm 파일 생성
• 파일 명 : "SoodaRealm_user_(userId).realm"
• DB CRUD를 위한 RealmManager 인스턴스 생성 시점에 키체인에 저장된 user ID 이용해서 realm 파일 새로 생성 or 기존 파일 식별

• 만약 너무 많은 계정이 로그인한다면 그 때마다 계속해서 파일 생성 -> 메모리 오버헤드 발생
• 따라서, 최대 5개의 파일만 생성이 가능하도록 설정
• 5개 초과 시 수정일이 가장 오래된 파일 제거 (LRU)
  

4. 다른 디바이스에 같은 계정으로 로그인하는 경우 - 소켓 응답 예외처리

• 채팅 화면에서 화면이 업데이트되는 경우는 채팅 전송 과 채팅 수신 이 있다.

• 채팅 전송 : 채팅 전송 (HTTP 통신) 이 성공했을 때, 200 응답과 함께 받은 데이터 이용
• 채팅 수신 : 채팅 수신 (소켓 통신) 이 성공했을 때, 수신한 데이터 이용

• 이 때, 전송한 채팅 은 해당 채팅방의 모든 유저에게 전송되기 때문에, 중복해서 소켓으로 응답받게 된다. 이에 대한 예외처리가 필요하다.

구현 방법

• 소켓으로 응답받은 데이터(socketChatData) 의 발신자 user ID 와 현재 계정 user ID 를 비교한다
• 두 값이 같다면, 해당 데이터(socketChatData)는 현재 계정이 보낸 채팅이므로, 전송한 채팅 이라고 할 수 있다.
• 즉, 두 값이 같을 때는 소켓으로 응답을 받았더라도, 데이터 처리를 해주지 않는다.

이슈

• 하나의 기기로만 테스트했을 때는 위 방법에 전혀 문제가 없었지만, 여러 계정에 동시에 로그인한 경우 문제가 발생한다.

• 두 기기에 접속했을 때, 하나의 기기에서 채팅을 보내더라도 실시간으로 다른 기기에서도 업데이트가 되어야 한다.

• 하지만, 소켓으로 응답받은 데이터의 user ID와 현재 계정 user ID가 같으면 수신 처리를 하지 않았기 때문에, 현재 계정이 보낸 데이터라고 판단하고, 응답 처리를 하지 않는다.

• 이러면 로컬 DB에 들어가는 채팅 순서도 엉키기 때문에, 예외처리에 대한 추가적인 기준 이 필요하다.

해결 방법 & 실패

• 단순히 user ID로만 비교하면 위에 보이듯이 멀티 디바이스에 대한 대응이 되지 않기 때문에 user ID로 조건 처리를 하는 것은 적절하지 않다.

• 그렇다면 결국, 채팅 데이터 가 정확히 현재 계정이 보낸 채팅인지 확인해야 한다. 즉, 채팅 데이터의 고유한 값인 chat ID 를 이용한다.

• 내가 생각한 로직은 다음과 같다

  1. 채팅 전송
  2. 전송 성공 응답 (200) + 성공한 채팅 데이터 (httpChatData)
  3. httpChatData 의 chat ID를 UserDefaults 에 저장
  4. 소켓 응답 (socketChatData)
  5. socketChatData의 chat ID와 UserDefaults의 chat ID 비교 후 현재 계정에서 보낸 채팅인지 분기 처리

• 위 로직대로면 발생한 문제가 모두 해결되고, 정상적으로 멀티 디바이스 대응이 가능해진다

• 하지만, 실패했다.
  • 4. 소켓 응답 이 2. HTTP 응답 보다 빠르게 온다
  • 애초에 UserDefaults에 전송한 채팅 데이터를 저장하기도 전에 소켓 응답이 와버리기 때문에 분기처리 자체가 불가능했다.
  • chat ID 는 서버에서 정해서 주기 때문에, HTTP 응답이 오기 전까지는 절대 알 수가 없다.

• 결과적으로 멀티 디바이스 대응 이슈 에 대해서는 해결할 수 없었다... 찾아보니 멀티 디바이스에 대한 대응을 위해서는 이 정도 수준보다 훨씬 많은 내용을 더 알아야 하는 것 같다. 추후 기회가 된다면, 이 쪽 내용에 대해서도 공부를 좀 해봐겠다.

UIKit, RxSwift MVVM, Input / Output Realm, Alamofire, Socket.IO UITableView + Cursor-based pagination

Sooda 깃허브 레포

로직

1. Load Data

채팅방에 진입했을 때 해야 할 일은 먼저 화면에 보여주기 위한 채팅 데이터를 불러오는 것 이다.

이 때, 채팅 데이터는 크게 2가지로 나눌 수 있다.

1. 이미 읽은 채팅 데이터
2. 아직 읽지 않은 채팅 데이터

현재 프로젝트에서는 기본적으로 Realm DB에 모든 채팅 데이터를 저장한다. 즉, 읽은 채팅 은 모두 Realm DB에서 꺼내온다.

읽지 않은 채팅 은 서버에 요청에서 받아온다.

1. 읽은 채팅들 (DB에 저장된 채팅) 중 가장 최신 채팅 데이터의 날짜를 변수에 저장한다. -> var lastChattingDate: Date
2. lastChattingDate 부터 Date() // 현재 시각 까지의 채팅 데이터를 서버에 요청한다. 이 데이터들이 읽지 않은 채팅 이 된다.

채팅방에 들어간 순간, 읽지 않은 채팅들도 모두 읽음 처리가 되어야 하기 때문에, 서버에서 응답받은 위 데이터들은 DB에 바로 저장한다.

모든 채팅 데이터가 DB에 저장이 완료되었을 때, 그제서야 DB에서 데이터를 꺼내서 화면에 보여준다.

채팅방 진입 시, 실시간으로 오는 채팅도 받아야 하기 때문에 소켓을 오픈해주어야 한다. 오픈 시점에 대한 이야기는 일단 패스한다.

2. Pagination

채팅방에 처음 들어갔을 때, 스크롤 시점은 "여기까지 읽으셨습니다" 셀이 가운데에 위치하도록 했다.

    self.mainView.chattingTableView.scrollToRow(
        at: indexPath,
        at: .middle,
        animated: false
    )

따라서, 해당 셀 기준으로 위 / 아래 방향 pagination이 가능해야 한다

위 방향	아래 방향

채팅 데이터는 모두 DB에 저장되어 있기 때문에 지정한 개수만큼 DB에서 꺼내온다 "특정 날짜 이전/이후 로 30개의 채팅 데이터를 꺼낸다"

따라서 pagination의 offset으로 이용할 변수가 필요하다. var previousOffsetTargetDate: Date? var nextOffsetTargetDate: Date?

pagination을 통해 채팅 데이터를 불러왔으면, offset 변수를 업데이트한다.

아래 방향 pagination은 기존에도 여러 번 구현해본 적이 있었기 때문에 큰 어려움 없이 할 수 있었다. 배열에 append로 추가 데이터를 붙이고, tableView.reloadData() 를 실행하면 된다.

위 방향 Pagination (UITableView Reverse Pagination)

트러블 슈팅

처음엔 아래 방향 pagination과 크게 다를 게 없다고 생각했다.

pagination이 일어나는 시점에 arr.insert(contentsOf: newArr, at: 0) tableView.reloadData() 를 실행했지만, 이러면 순식간에 여러 번 Pagination이 일어난다.

이러한 문제가 발생하는 이유는 (내가 판단했을 때) tableView.reloadData 가 완료되면 사용자의 스크롤 시점은 기존에 보고있던 cell 위치와 동일해야 한다. 이건 당연히 그래야 하고, 구현 목적에도 일치한다.

이 cell 위치는 tableView의 indexPath를 기준으로 맞춰진다. 즉, 내가 기존에 indexPath [0, 10] 셀을 보고 있었다면 tableView.reloadData() 이후에도 [0, 10] 번째 셀을 보게 된다.

하지만 위로 Pagination을 구현할 때는 배열의 앞에 새로운 데이터를 넣어주기 때문에 tableView.reloadData() 이전과 이후에 [0, 10] 번째 데이터는 다른 데이터가 된다.

예를 들어, 내가 추가로 30개의 데이터를 배열의 맨 앞에 넣어줬을 때, reload 이전에 보고 있던 셀의 위치가 [0, 10] 이라면 reload 이후에 해당 셀의 위치는 [0, 40] 이 된다.

즉, 내가 보고 있어야 할 셀은 [0, 40] 인데, 새로 넣어준 [0, 10] 번째 데이터를 보고 있으니까 pagination 조건에 또 맞게 되고, 순식간에 여러 번 pagination이 일어나버린다.

prefetchRowsAt 을 이용한다면, pagination이 실행되는 조건 (ex. indexPath.row == 1) 이 tableView.reload 이후에도 연속으로 계속 실행된다

scrollViewDidScroll 을 이용해도 역시, pagination이 실행되는 조건 (ex. contentOffset.y < 100) 이 tableView.reload 이후에도 연속으로 계속 실행된다. 이 때는 아예 contentOffset.y 값이 커지지가 않고, 음수까지 내려가버리게 된다.

willDisplayRow 도 이하 동문.

해결 방안

CGAffineTransform(scaleX: 1, y: -1) 메서드나 "ReverseExtension" 라이브러리를 통해서 테이블뷰 자체를 상하 반전시키게 되면 쉽게 구현이 가능하다. 하지만 나는 위 / 아래 pagination을 모두 구현시켜야 하기 때문에 이건 의미가 없다.

결국 내가 구현해야 하는 건 새로운 데이터는 배열 앞에 붙이고, 테이블뷰 위에 새로운 셀도 그리지만, 스크롤 위치는 기존과 동일해야 한다

tableView.insertRows 메서드를 이용했다. 사실 위에 새롭게 붙는 데이터에 대해서만 cell을 다시 그려주면 되기 때문에 테이블뷰의 모든 셀을 다시 그리는 tableView.reloadData를 반드시 사용할 필요는 없다. 그래서 insertRows 메서드를 떠올렸다.

insertRows 메서드를 사용함으로써 위에 겪었던 트러블 (indexPath 기준으로 위치 고정) 을 해결할 수 있었다.

다만 이 때는 새롭게 붙이는 데이터의 개수를 알고 있어야 하기 때문에 기존 메서드의 수정이 필요했다. (completionHandler의 매개변수 cnt)

viewModel.paginationPreviousData { [weak self] cnt in
    let indexPaths = (0..<cnt).map { IndexPath(row: $0, section: 0) }
    self?.mainView.chattingTableView.insertRows(at: indexPaths, with: .bottom) 
}

3. NewMessageToastView

채팅방에 진입하면 소켓 통신을 통해 실시간 채팅 응답을 받을 수 있다. 실시간 채팅 응답에 대해 UI적으로 어떻게 반응해야 할 지 고민해보았다.

1. 스크롤 위치가 상대적으로 아래에 있을 때 새로운 채팅을 맨 아래에 보여주고, 스크롤 시점도 맨 아래로 움직인다

2. 스크롤 위치가 상대적으로 위에 있을 때 새로운 채팅을 toast view 형태로 보여주고, 스크롤 시점은 유지한다 뷰를 클릭하거나 스크롤을 아래로 내리면 hidden 처리한다

이 때 "상대적"의 기준은 모호하기 때문에 일단 임의로 설정하였다.

// isBottom이 true 일 때 "상대적으로 아래에 있다"고 판단한다
let isBottom = scrollView.contentSize.height - scrollView.contentOffset.y < 800

case 1	case 2

뷰를 클릭하거나 스크롤을 아래로 내리면 toastView hidden

클릭	스크롤

실시간 채팅 응답 로직

위 과정이 UI적으로 봤을 때는 경우의 수가 2개이지만, 실제 코드로 접근하려고 하면 3개로 늘어난다. 아래 방향 Pagination 이 있기 때문이다

아래 방향 pagination의 완료 여부 에 따라 추가로 분기 처리를 진행했다. 이 처리를 하지 않으면, 채팅 순서가 꼬일 수 있다.

아직 디비에서 채팅 데이터를 모두 꺼내지도 않았는데, 새로 온 채팅을 무작정 VM 배열에 붙이게 되면 순서가 꼬이게 된다

경우의 수

1. 스크롤 위치가 상대적으로 아래 (isBottom == true) (이 경우는 반드시 아래 방향 pagination이 완료되어 있다)

2. 스크롤 위치가 상대적으로 위 (isBottom == false) && 아래 방향 pagination 완료 o (isDoneNextPagination == true)

3. 스크롤 위치가 상대적으로 위 (isBottom == false) && 아래 방향 pagination 완료 x (isDoneNextPagination == false)

소켓 통신으로 newChat 데이터 응답
tableView에 나타날 데이터 배열 : chatArr (VM)

case 1.
1. (Repository) DB에 newChat 저장
2. (VM) chatArr.append(newChat)
3. (VC) tableView.reloadData()
4. (VC) tableView.scrollToBottom()


case 2.
1. (Repository) DB에 newChat 저장
2. (VM) chatArr.append(newChat)
3. (VC) tableView.reloadData()
2. (VC) showNewMessageToastView(newChat)


case 3.
1. (Repository) DB에 newChat 저장
2. (VC) showNewMessageToastView(newChat)

newMesssageToastView 클릭 로직

뷰를 클릭하면 테이블뷰의 맨 아래로 스크롤 시점을 움직여야 한다. 이 때도 역시 아래 방향 pagination의 완료 여부에 따라 분기 처리가 필요하다

디비에서 채팅을 모두 꺼낸 상태가 아니라면, 스크롤 시점을 맨 아래로 내리더라도 최신 데이터를 확인할 수 없기 때문이다 따라서 이 경우에는 디비에 남은 채팅 데이터를 모두 꺼내는 과정 이 필요하다

경우의 수

1. 아래 방향 pagination 완료 o
2. 아래 방향 pagination 완료 x

case 1.
1. (VC) tableView.scrollToBottom()


case 2. 
1. (VM) fetchAllNextChattingData
2. (VC) tableView.reloadData()
3. (VC) tableView.scrollToBottom()

4. Send Message

채팅을 구현할 때 메세지 수신은 소켓, 메세지 전송은 HTTP 를 이용했다

따라서 전송 버튼을 눌렀을 때, HTTP Request로 채팅 전송 요청을 하게 되고, 성공 응답을 받았을 때 해당 채팅 데이터(newChat)를 VM 배열에 붙여주는 방식이다.

이 때도 역시 아래 방향 pagination의 완료 여부에 따라 분기 처리가 필요하다. (newMessageToastView 클릭 로직의 경우와 동일하다)

메세지를 전송하게 되면 결국 소켓으로도 해당 응답을 받기 때문에, 소켓 응답에서는 내가 보낸 메세지를 필터링해주는 작업이 필요하다 (추후 정리)

case 1	case 2

경우의 수

1. 아래 방향 pagination 완료 o
2. 아래 방향 pagination 완료 x

case 1.
1. (VM) chatArr.append(newChat)
2. (VC) tableView.reloadData()
3. (VC) tableView.scrollToBottom()
4. (VC) initInputView()


case 2. 
1. (VM) fetchAllNextChattingData()
2. (VM) chatArr.append(newChat)
3. (VC) tableView.reloadData()
4. (VC) tableView.scrollToBottom()
5. (VC) initInputView()

UIKit, RxSwift DispatchGroup PHPicker, UIDocumentPicker, UIDocumentInteractionController Remote Push Notification, NotificationCenter RxDataSources, RxTableViewSectionedAnimatedDataSource

Sooda 깃허브 레포

UI

1. Chatting Input View

• 채팅으로 전송할 데이터를 입력하는 곳 텍스트, 이미지, 파일 전송 가능

  No data - button disabled	only text - 1 line	only text - 4 or more lines	with files

1. chattingTextView: UITextView

• 텍스트 3줄까지 화면에 보이게 구현. 4줄 이상부터 스크롤 가능

  no file	with files

  // View
  let chattingTextView = {
      let view = ChannelChattingTextView()
      view.isScrollEnabled = false    // 초기 스크롤 불가능 (4줄 이상부터 가능)
      return view
  }()
  
  override setConstraints() {
      [
          chattingTextView.topAnchor.constraint(equalTo: self.topAnchor, constant: 3.2),
          chattingTextView.leadingAnchor.constraint(equalTo: plusButton.trailingAnchor, constant: 8),
          chattingTextView.trailingAnchor.constraint(equalTo: sendButton.leadingAnchor, constant: -8),
          chattingTextView.heightAnchor.constraint(equalToConstant: 31.6),   
      ].forEach{ $0.isActive = true }
  
      // fileImageCollectionView의 유무에 따라 bottom Layout 결정
      chattingTextView.bottomAnchor.constraint(
          equalTo: self.bottomAnchor, constant: -3.2
      ).isActive = fileImageCollectionView.isHidden
  }
  
  

// VC // TextView extension VC: UITextViewDelegate {

  func textViewDidChange(_ textView: UITextView) {

      let size = CGSize(width: view.frame.width, height: .infinity)
      let estimatedSize = textView.sizeThatFits(size)

      // estimatedSize
      // 1줄일 때 31.6
      // 2줄일 때 47.3
      // 3줄일 때 62.6

      if estimatedSize.height > 65 {
          textView.isScrollEnabled = true
          return
      } else {
          textView.isScrollEnabled = false

          // 레이아웃 중 height 수정
          textView.constraints.forEach { constraint in
              if constraint.firstAttribute == .height {
                  constraint.constant = estimatedSize.height
              }
          }
      }
  }

}

<br>

### 2. `fileCollectionView`
- 전송할 이미지 또는 파일 표시
- 이미지(.jpeg, .png, .jpg)는 썸네일 표시,
파일(.pdf, .zip, .mp3, ...)은 아이콘 표시
- x 버튼 눌러서 삭제 가능

<br>


### 3. `plusButton`
- 전송할 이미지 또는 파일 추가
- 이미지, 파일 합 최대 5개 전송 가능

  이미지 추가|파일 추가|둘 다 추가 + 삭제|
  :--:|:--:|:--:|
  ![](https://velog.velcdn.com/images/s_sub/post/9c9e38f3-50e8-4f7d-a3d4-f7108e3fe91d/image.gif)|![](https://velog.velcdn.com/images/s_sub/post/7885dab9-50ff-4357-ba22-85a57f0a0176/image.gif)|![](https://velog.velcdn.com/images/s_sub/post/dff50f32-4d52-471d-ae73-15eb630706e9/image.gif)|



<br>


- 이미지 추가 : **PHPicker** 
  ```swift
  extension VC: PHPickerViewControllerDelegate {

      func showPHPicker() {
          var configuration = PHPickerConfiguration()

          configuration.selectionLimit = 5
          configuration.filter = .images

          let picker = PHPickerViewController(configuration: configuration)
          picker.delegate = self
          present(picker, animated: true)
      }

      func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) {

          if results.isEmpty { return }

          // 이미지 + 파일 합 최대 5개
          guard let curCnt = try? viewModel.fileData.value() else { return }
          let enableCnt = 5 - curCnt.count
          if results.count > enableCnt {
              // show alert
              return
          }

          // 선택한 순서에 맞춰서 넣어주기 위해 미리 size 맞춰서 배열 선언
          var imageArr = Array(
              repeating: FileDataModel(
                  fileName: "image.jpeg",
                  data: Data(),
                  fileExtension: .jpeg
              ),
              count: results.count
          )

          // 비동기 작업의 종료 시점 파악하기 위해 DispatchGroup 활용
          var group = DispatchGroup()

          for (index, item) in results.enumerated() {
              group.enter()
              let itemProvider = item.itemProvider
              if itemProvider.canLoadObject(ofClass: UIImage.self) {
                  itemProvider.loadObject(ofClass: UIImage.self) { [weak self] image , error  in

                      guard let image = image as? UIImage else { return }
                      guard let imageData = image.jpegData(compressionQuality: 0.01) else { return }     
                      imageArr[index].data = imageData
                      group.leave()

                  }
              }
          }
          picker.dismiss(animated: true)

          // 종료 시접에 VM 배열 업데이트
          group.notify(queue: .main) { [weak self] in
              guard var fileArr = try? self?.viewModel.fileData.value() else { return }
              fileArr.append(contentsOf: imageArr)
              self?.viewModel.fileData.onNext(fileArr)
          }

      }
  }

• 파일 추가 : UIDocumentPicker

  extension VC: UIDocumentPickerDelegate {
  
      func showDocumentPicker() {
  
          let picker = UIDocumentPickerViewController(
              forOpeningContentTypes: [.pdf, .gif, .avi, .zip, .text, .mp3, .movie],
              asCopy: true
          )
  
          picker.delegate = self
          picker.allowsMultipleSelection = true
          present(picker, animated: true)
      }
  
      func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) {
  
          // 이미지 + 파일 합 최대 5개
          guard let curCnt = try? viewModel.fileData.value() else { return }
          let enableCnt = 5 - curCnt.count
          if urls.count > enableCnt {
              // show alert
              return
          }
  
          // 배열에 넣어줄 타입으로 변환
          var dataArr: [FileDataModel] = []
          for url in urls {
              // url : FileManager 주소
              if let fileName = url.absoluteString.extractFileName(),
                 let fileExtension = url.absoluteString.fileExtension() {
                  dataArr.append(
                      FileDataModel(
                          fileName: fileName,
                          data: (try? Data(contentsOf: url)) ?? Data(),
                          fileExtension: fileExtension
                      )
                  )
              }
          }
  
          // VM 배열 업데이트
          guard var fileArr = try? viewModel.fileData.value() else { return }
          fileArr.append(contentsOf: dataArr)
          viewModel.fileData.onNext(fileArr)
      }
  
  }

4. sendButton

• 텍스트 또는 이미지, 파일이 있을 때 버튼 활성화 (빈 값 전송 불가능)
• 채팅 데이터 전송 로직 실행

5. keyboard appear / disappear

• 기기 키보드가 올라오고 내려감에 따라 테이블뷰의 시점을 맞춰줌

• 최대한 상수를 쓰고 싶지 않았지만,, 일단 구현을 최우선으로 둠.. 기기 대응 시 코드 수정 필요함

• 추후 구현해보고 싶은 점 : 카카오톡, 슬랙처럼 테이블뷰의 스크롤에 키보드 스크롤이 같이 적용되는 UI

  no data	with data

  extension VC {
      // observer 등록
      private func startObservingKeyboard() {
          let notificationCenter = NotificationCenter.default
  
          notificationCenter.addObserver(
              forName: UIResponder.keyboardWillShowNotification,
              object: nil,
              queue: nil,
              using: keyboardWillAppear
          )
  
  

      notificationCenter.addObserver(
          forName: UIResponder.keyboardWillHideNotification,
          object: nil,
          queue: nil,
          using: keyboardWillDisappear
      )
  }

  // keyboard appear
  private func keyboardWillAppear(_ notification: Notification) {
      print("*** keyboardWillAppear ***")

      let key = UIResponder.keyboardFrameEndUserInfoKey
      guard let keyboardFrame = notification.userInfo?[key] as? CGRect else { return }

      // 스크롤을 이동할 높이
      let height = keyboardFrame.height - 83 

      let currentOffset = mainView.chattingTableView.contentOffset.y
      let newOffset = max(currentOffset + height, 0)

      // 키보드가 움직이는 시간 0.25 second (Keyboard Responder로 확인 가능)
      UIView.animate(withDuration: 0.25) {
          self.mainView.chattingTableView.setContentOffset(CGPoint(x: 0, y: newOffset), animated: false)
      }
  }

  private func keyboardWillDisappear(_ notification: Notification) {
      print("*** keyboardWillDisappear ***")

      let key = UIResponder.keyboardFrameEndUserInfoKey
      guard let keyboardFrame = notification.userInfo?[key] as? CGRect else { return }

      // 이슈 : keyboardFrame.height가 75 정도로 나온다.
      // "일단" keyboardWillAppear에서 확인한 값 상수로 선언

      let keyboardHeight: CGFloat = 336

      let height = keyboardHeight - 83

      let currentOffset = mainView.chattingTableView.contentOffset.y

      let newOffset = currentOffset - height

      UIView.animate(withDuration: 0.25) {
          self.mainView.chattingTableView.setContentOffset(CGPoint(x: 0, y: newOffset), animated: false)
      }
  }

}

- 참고 레퍼런스 : 카카오톡, 슬랙, 잔디

  카카오톡|슬랙|잔디|
  :--:|:--:|:--:|
  ![](https://velog.velcdn.com/images/s_sub/post/4a941ac7-f52c-4f3d-a5a5-74c883c85fca/image.gif)|![](https://velog.velcdn.com/images/s_sub/post/abd5689d-f4e6-468d-9b51-71de92030cb6/image.gif)|![](https://velog.velcdn.com/images/s_sub/post/896b6c81-71aa-4152-a08e-370ed5283cef/image.gif)|
  * 테이블뷰 스크롤 + 키보드 스크롤 맞물림|* 테이블뷰 스크롤 + 키보드 스크롤 맞물림|* 테이블뷰 스크롤과 키보드 상관 x|
  * 테이블뷰 탭 시 <br>키보드 disappear<br>+ 스크롤 시점 같이 이동 o|* 테이블뷰 탭 시 <br>상세페이지 이동<br>키보드 상관 x|* 테이블뷰 탭 시<br> 키보드 disappear <br>+ 스크롤 시점 이동 x|




<br>


## 2. Chatting TableView Cell
- 채팅을 통해 받을 수 있는 데이터는 크게 다음과 같다. 
    1. 텍스트
      2. 사진
      3. 파일
    각 데이터의 유무에 따라 셀 디자인이 달라진다. - **stackView 활용**

![](https://velog.velcdn.com/images/s_sub/post/fb8131d1-10d1-4972-a37d-cbd6c3232840/image.jpeg)

![](https://velog.velcdn.com/images/s_sub/post/633e9266-cd31-45d8-8747-997bfb22c835/image.jpeg)


![](https://velog.velcdn.com/images/s_sub/post/78840327-4f55-4f1b-a60e-b926d036bcc1/image.jpeg)




### 1. 텍스트 - `UILabel`
- 텍스트가 써있는 UILabel과, 테두리 역할을 하는 UIView를 만들어서 구현

<br>

### 2. 이미지 - `ChannelChattingCellContentImageSetView`
- 이미지 개수는 최대 5장까지 가능하며, 개수에 따라 레이아웃이 다르다.
- 뷰 내에 imageView를 미리 5개 만들어두고, 들어오는 이미지 배열의 count에 따라 다른 레이아웃 함수를 실행한다.
![](https://velog.velcdn.com/images/s_sub/post/4a842407-8afe-471b-8e26-c0b864954a52/image.jpeg)



### 3. 파일 - `FileContentView`
- 파일 개수 역시 최대 5개까지 가능하다. 
- 미리 인스턴스 5개 만들어두고, `stackView.addArrangedSubView(view)`
- 파일 개수에 따라 Hidden 처리
- 파일 확장자에 따라 다른 아이콘 (`UIImageView`) + 파일 이름 (`UILabel`)


- 뷰 클릭 시 **UIDocumentInteractionController** 이용해서 preview 화면 - **delegate pattern 활용**

  .pdf|.zip
  :--:|:--:
  ![](https://velog.velcdn.com/images/s_sub/post/238a524f-d777-422c-a0d9-815c0be08022/image.gif)|![](https://velog.velcdn.com/images/s_sub/post/27222b05-c688-4ceb-8a40-ef3dc5b091f4/image.gif)

  ```swift
  // VC
  func downloadAndOpenFile(_ fileURL: String) {
      // fileURL : 서버에 저장된 파일 주소

      // 1. 네트워크 통신으로 파일 Data 다운
      NetworkManager.shared.requestCompletionData(
          api: .downLoadFile(fileURL)) { response in
              switch response {
              case .success(let data):
                  print(data)

                  // 마지막 '/' 기준 뒤 문자열이 파일 이름
                  guard let fileName = fileURL.extractFileName() else { return }

                  // Document 내부 경로 설정
                  let fileManager = FileManager()
                  let documentPath = fileManager.urls(for: .documentDirectory, in: .userDomainMask).first!.appendingPathComponent("\(fileName)")

                  do {
                      try data.write(to: documentPath)
                  } catch {
                      print(error)
                  }

                  // 파일 오픈
                  DispatchQueue.main.async {
                      self.interaction = UIDocumentInteractionController(url: documentPath)
                      self.interaction?.delegate = self
                      self.interaction?.presentPreview(animated: true)
                  }

              case .failure(let networkError):
                  print("에러 발생 : \(networkError)")
              }
          }
  }

3. Update Chatting List View

• 채팅 리스트들을 볼 수 있는 화면에서도 실시간 채팅에 대한 대응을 해주어야 한다. (가장 최신 채팅 내용이 화면에 나타나야 한다)
• 하지만 그렇다고 모든 채팅방에 대해 소켓을 열어두고, 실시간 채팅에 대한 응답을 처리하는 건 비효율적이다.
• 그래서 push notification 을 이용했다.
  • push로 받은 데이터를 확인해서, 실시간으로 화면에 최신 채팅을 보여준다
• 이 과정에서 자연스러운 애니메이션을 보여주기 위해 RxDataSource의 RxTableViewSectionedAnimatedDataSource를 이용했다.

기본 Chatting List View	실시간 채팅이 왔을 때 대응

• RxDataSource tableView 구현

  // VC
  func bind() {
      // DMListTableView - RxDataSource
      let dataSource = RxTableViewSectionedAnimatedDataSource<DMListSectionData>(
          animationConfiguration: AnimationConfiguration(
              insertAnimation: .fade,
              reloadAnimation: .fade,
              deleteAnimation: .fade
          )
      ) { data, tableView, indexPath, item in
          guard let cell = tableView.dequeueReusableCell(withIdentifier: DMListTableViewCell.description(), for: indexPath) as? DMListTableViewCell else { return UITableViewCell() }
          cell.designCell(item)
          return cell
      }
  
      output.dmRoomSectionsArr
          .bind(to: mainView.dmListTableView.rx.items(dataSource: dataSource))
          .disposed(by: disposeBag)
  }
  
  

// VM let dmRoomSectionArr = BehaviorSubject<[DMListSectionData]>(value: []) // 타입은 배열이긴 하지만, 실질적인 배열의 크기는 1

// Model struct DMListSectionData { var header: String var items: [Item] }

extension DMListSectionData: AnimatableSectionModelType { typealias Item = DMChattingCellInfoModel typealias Identity = String

  var identity: String {
      return header
  }

  init(original: DMListSectionData, items: [DMChattingCellInfoModel]) {
      self = original
      self.items = items
  }

}

struct DMChattingCellInfoModel { let roomId: Int let userInfo: UserInfoModel var lastContent: String var lastDate: Date var unreadCount: Int }

- #### `Push Notification 응답`
  ```swift
  // AppDelegate
  func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
      // 포그라운드 상태에서 알림 받기

      guard let userInfo = notification.request.content.userInfo as? [String: Any] else { return }

      /* ... */

      // 2. 디엠 채팅인 경우
      if let dmChatInfo: PushDMChattingDTO = self.decodingData(userInfo: userInfo) {    // 디코딩 메서드 따로 구현

          // 현재 보고 있는 채팅방은 아닌지 확인 (현재 접속한 채팅방의 채팅은 푸시 알림 x)
          if !self.checkCurrentDMRoom(chatInfo: dmChatInfo) {

              // 푸시 알림
              completionHandler([.list, .badge, .sound, .banner])

              // NotificationCenter 이용해서 DMListView에 새로운 채팅이 왔음을 알림
              let userInfo: [String: Any] = [
                  "workspaceId": Int(dmChatInfo.workspace_id)!,
                  "opponentId": Int(dmChatInfo.opponent_id)!,
                  "content": dmChatInfo.aps.alert.body,
                  "opponentName": dmChatInfo.aps.alert.title
              ]

              NotificationCenter.default.post(
                  name: Notification.Name("receiveDMChattingPushNotification"),
                  object: nil,
                  userInfo: userInfo
              )
          }
      }
  }


  // VM
  func transform(_ input: Input) -> Output {

      /* ... */

      // Observer 등록
      NotificationCenter.default.addObserver(
          self,
          selector: #selector(receiveDMChattingPushNotification),
          name: Notification.Name("receiveDMChattingPushNotification"),
          object: nil
      )
  }

  @objc private func receiveDMChattingPushNotification(_ notification: Notification) {

      if let userInfo = notification.userInfo,
         let opponentId = userInfo["opponentId"] as? Int,
         let workspaceId = userInfo["workspaceId"] as? Int,
         let content = userInfo["content"] as? String,
         let opponentName = userInfo["opponentName"] as? String
      {
          // VM에서 가지고 있는 dmRoomSectionArr 중, 해당되는 채팅방을 찾고, (opponent id 이용)
          // 해당 채팅을 배열에서 맨 앞으로 옮긴다 (remove -> insert)

          do {
              var newArr = try self.dmRoomSectionsArr.value()    // 새롭게 onNext로 넣어줄 배열

              var targetIndex: Int = 0    // 해당되는 채팅의 index

              for i in 0..<newArr[0].items.count {
                  if newArr[0].items[i].userInfo.userId == opponentId {
                      targetIndex = i
                      break
                  }
              }

              // 새롭게 업데이트될 채팅방 정보
              var newItem = newArr[0].items.remove(at: targetIndex)
              newItem.lastDate = Date()
              newItem.lastContent = content
              newItem.unreadCount += 1

              // 1. remove 후 onNext (애니메이션 때문)
              self.dmRoomSectionsArr.onNext(newArr)

              // 2. insert 후 onNext (애니메이션 때문)
              newArr[0].items.insert(newItem, at: 0)
              self.dmRoomSectionsArr.onNext(newArr)

          } catch {
              print("Error")
          }
      }
  }

• UIKit, RxSwift
• Clean Architecture, MVVM-C
• Sooda 깃허브 레포

1. 개요

1. 선택한 이유

• VC에서 화면 전환에 대한 로직을 떼어내기 위해
• 보다 독립적으로 VC 인스턴스 관리 (이전/다음 화면을 알지 못하게 함)

2. 과정

• 여러 레퍼런스에서 대부분 비슷한 Coordinator 클래스를 사용하고 있어서 처음 학습하는 데 큰 어려움은 없었다.
• 다만, 탭바 코디네이터 관련해서는 구조가 헷갈리는 부분이 있어서 Coordinator pattern with Tab Bar Controller 이 글의 도움을 많이 받았다
• 코디네이터 클래스 자체에 대한 이해보다는 화면 전환 플로우 방식을 이해하는 데 시간을 많이 소요했다.
• 코디네이터 패턴을 구현하면서 내가 필요하다고 느끼는 부분에 대해서는 코드를 추가했다.

2. 코드

1. protocol Coordinator

1. 가장 최상위 코디네이터인 AppCoordinator 를 제외하고 모두 부모 코디네이터를 갖는다
2. 각 코디네이터는 하나의 navigationController 를 갖는다.
   • 두 개 이상을 갖지 못하도록 스스로(?) 규칙을 정했다.
3. 현재 살아있는(?) 자식 코디네이터들을 저장한 배열이 있다.
   • 탭바 코디네이터를 제외하고는 대부분 단 하나의 자식 코디네이터만 살아있다.
4. 모든 코디네이터의 타입은 enum CoordinatorType 의 case에 존재하고, 각 코디네이터마다 본인의 타입을 저장하는 프로퍼티가 있다.
   • 코디네이터가 종료될 때, 부모 코디네이터에서 자식 코디네이터 배열을 초기화할 때 사용한다.
5. 새로운 코디네이터가 생성된다는 건 결국 새로운 화면이 나타난다는 뜻이기 때문에, 첫 번째로 어떤 화면 또는 어떤 플로우가 실행될지 정의해주어야 한다.
6. 현재 코디네이터가 종료될 때 다음 타겟 코디네이터를 정하고 종료되어야 한다.
   • 모든 코디네이터에 대해 동일하기 때문에, extension Coordinator 에서 메서드를 선언한다.

  protocol Coordinator: AnyObject {

      // 1. 부모 코디네이터
      var finishDelegate: CoordinatorFinishDelegate? { get set }

      // 2. 각 코디네이터는 하나의 nav를 갖는다
      var navigationController: UINavigationController { get set }
      init(_ navigationController: UINavigationController)

      // 3. 현재 살아있는 자식 코디네이터 배열.
      var childCoordinators: [Coordinator] { get set }

      // 4. Flow 타입
      var type: CoordinatorType { get }

      // 5. Flow 시작 시점 로직
      func start()

      // 6. Flow 종료 시점 로직. (extension에서 선언)
      func finish(_ nextFlow: ChildCoordinatorTypeProtocol?)
  }

  extension Coordinator {
      func finish(_ nextFlow: ChildCoordinatorTypeProtocol?) {
          // 1. 자식 코디 다 지우기
          childCoordinators.removeAll()

          // 2. 부모 코디에게 알리기
          finishDelegate?.coordinatorDidFinish(
              childCoordinator: self,
              nextFlow: nextFlow  
          )
      }
  }

2. protocol CoordinatorFinishDelegate: AnyObject

• 자식 코디네이터가 종료된 경우, 부모 코디네이터가 이를 알아야 하기 때문에 delegate pattern 을 이용해서 알려준다.
• 만약 자식 코디네이터가 없는 경우, 이 프로토콜을 채택하지 않는다.
• 알려줄 때, 2가지 정보를 전달한다
  1. 종료된 자식 코디네이터의 타입
  2. 다음에 실행되어야 할 코디네이터의 타입

     protocol CoordinatorFinishDelegate: AnyObject {
     func coordinatorDidFinish(childCoordinator: Coordinator, nextFlow: ChildCoordinatorTypeProtocol?)
     }
     
     

// ex. extension AppCoordinator: CoordinatorFinishDelegate {

func coordinatorDidFinish(
    childCoordinator: Coordinator,
    nextFlow: ChildCoordinatorTypeProtocol?
) {
    // 1. 자식 코디 배열 초기화 (사실상 하나밖에 없었기 때문에 빈 배열이 된다)
    childCoordinators = childCoordinators.filter { $0.type != childCoordinator.type }
    // 2. nav에 연결된 VC 모두 제거
    navigationController.viewControllers.removeAll()

    // 3. 다음 타겟 코디 실행
    // 3 - 0
    if nextFlow == nil { }

    // 3 - 1. Child 코디인 경우
    else if let nextFlow = nextFlow as? ChildCoordinatorType {
        /* ... */
    }

    // 3 - 2. Child 코디보다 더 하위 코디인 경우 -> 직접 특정해야 한다 
    // ex). 탭바의 자식 코디인 경우
    else if let nextFlow = nextFlow as? TabBarCoordinator.ChildCoordinatorType {
        /* ... */
    }

    // 3 - 3. 부모 코디를 타고 가야 하는 경우
    else {
        self.finish(nextFlow)
    }

}

<br>

### `3. protocol ChildCoordinatorTypeProtocol`
- 모든 부모 코디네이터는 자식 코디네이터의 정보를 `enum` 으로 저장한다.
- 코디네이터가 종료되는 시점에서, target 코디네이터의 정보를 전달할 때 이 `enum` 으로 다음 코디네이터를 특정한다.
- 따라서 `coordinatorDidFinish` 메서드에서는 모든 자식 코디네이터를 매개변수로 받을 수 있어야 하고, 이를 위해 이 프로토콜을 선언한다.
- 모든 부모 코디네이터에서 저장하는 자식 코디네이터 `enum` 은 이 프로토콜을 채택한다

```swift
protocol ChildCoordinatorTypeProtocol {
}


// ex.
// AppCoordinator
extension AppCoordinator {
    enum ChildCoordinatorType: ChildCoordinatorTypeProtocol {
        case splash
        case loginScene
        case tabBarScene
        case homeEmptyScene
    }
}

4. CoordinatorType

• 앱 내에 있는 모든 코디네이터의 종류

• 각 코디네이터별로 프로퍼티로 어떤 종류인지 저장하고 있다

  enum CoordinatorType {
    case app
    case splash, loginScene, homeEmptyScene, tabBarScene
  
    /* ... */
  }

3. 내가 적용한 코디네이터 패턴

1. 새로운 코디네이터를 만드는 기준

• 결론부터 말하면, 내가 정한 새로운 코디네이터를 만드는 기준은 새로운 navigationController가 필요한 경우 이다.

트러블 슈팅

• 이 기준이 없을 때는, 대강 하나의 플로우는 하나의 코디로 관리하면 되겠지~ 라고 생각하고 구현을 시작했다.
• 이렇게 시작하고, 바로 멈추게 되는 지점이 있었는데, 연속으로 화면 present가 실행되는 경우 이다. (이 때, present를 실행하는 객체는 코디의 navigationController 이다)
  1. Onboarding View를 관리하는 코디에서 SelectAuth View present
  2. SelectAuth View를 관리하는 코디에서 EmailLogin View present

• 위 과정은 하나의 Coordinator에서 진행할 수 없다.
  • 하나의 VC는 반드시 하나의 VC만 present 할 수 있다 (multiple 불가능)
  • 즉, 코디는 nav가 하나만 있기 때문에 present로 화면 전환을 할 수 있는 건 단 한 번 뿐이다.

• 결국, 위와 같은 플로우에서는 추가적인 코디가 필요할 수밖에 없다...
  • 새로운 VC를 present시켜줄 코디의 nav가 필요하기 때문이다

• 그래서 1번 과정에서는 새로운 코디를 생성하고, 그 코디의 nav를 present하는 방식으로 구현했다.
• 새로운 navigationController가 필요한 경우*

• 다만 2번 과정에서는 새로운 코디를 생성할 필요가 없다. EmailLogin VC의 navigationController는 따로 하는 일이 없기 때문이다. 즉, 새로운 navigationController가 필요 없다

• 이게 내가 세운 새로운 코디네이터를 만드는 기준 이다. 만약 EmailLoginView의 nav에서 push나 present 등 추가로 해야 하는 일이 있다면, 이 역시 새로운 코디를 생성해야 할 것이다.

코드 정리

// LoginSceneCoordinator (Onboarding View)
class LoginSceneCoordinator: LoginSceneCoordinatorProtocol {

    /* ... */

    func showSelectAuthFlow() {
        // TODO: selectAuthFlow 시작. present로 진행. 별도의 navigationController 주입

        // 새로 만드는 nav는 어차피 여기서 관리하지는 않을거고, 새로운 코디에서 관리할 예정이기 때문에 현재 코디에서 따로 변수로 가지고 있을 필요는 없다
        // 단지, 현재 코디와 다른 nav를 가질 수 있도록 주입해주는 것 뿐임
        let nav = UINavigationController()
        let selectAuthCoordinator = SelectAuthCoordinator(nav)
        selectAuthCoordinator.finishDelegate = self
        childCoordinators.append(selectAuthCoordinator)
        selectAuthCoordinator.start()   // 코디의 첫 화면 세팅

        // 여기서 직접 present 실행
        navigationController.present(selectAuthCoordinator.navigationController, animated: true)
    }
}


// SelectAuthCoordinator (SelectAuth View)
class SelectAuthCoordinator: SelectAuthCoordinatorProtocol {

    /* ... */

    func start() {
        showSelectAuthView()
    }

    // 초기 화면
    func showSelectAuthView() {
        let selectAuthVM = /* ... */
        let selectAuthVC = /* ... */
        selectAuthVM.didSendEventClosure = /* ... */

        navigationController.pushViewController(selectAuthVC, animated: false)
    }

    // present로 EmailLoginView (추가적인 nav가 필요 없기 때문에 여기서 present 실행)
    func showEmailLoginView() {
        let emailLoginVM = /* ... */
        let emailLoginVC = /* ... */
        emailLoginVM.didSendEventClosure = /* ... */

        // nav는 화면에 보이는 것 외에 다른 기능은 없다
        let nav = UINavigationController(rootViewController: emailLoginVC)
        navigationController.present(nav, animated: true)
    }
}

2. 코디네이터 종료 시, 다음 타겟 코디네이터 지정

• 내가 참고한 코디네이터 레퍼런스에서는 코디네이터가 finish로 종료되면, 부모 코디에서 그 코디의 타입에 따라 다음 코디를 정하고, 이를 실행시켰다.

• 하지만 하나의 코디가 종료될 때 상태에 따라 서로 다른 코디가 실행될 가능성이 있기 때문에 추가적인 코드의 필요성을 느꼈다.

1. Child : 타겟 지정 후 finish

• 모든 코디네이터에 대해 finish 메서드는 extension Coordinator에서 미리 선언이 되어있다. 여기서 delegate pattern을 이용해 다음 타겟 코디를 매개변수로 넣어서 메서드를 실행한다

• 이 때, 매개변수로 넣는 타겟 코디는

• 타겟코디의_부모코디.ChildCoordinatorType.타겟코디* 형식으로 넣어준다.

  • 모든 부모코디는 ChildCoordinatorType 으로 본인의 자식 코디 종류를 저장하고 있다.

    extension TabBarCoordinator {
        enum ChildCoordinatorType: ChildCoordinatorTypeProtocol {
        case homeDefaultScene(workspaceId: Int)
        case dmScene(workspaceID: Int)
        case searchScene, settingScene
    }   

  • 즉,다음 타겟 코디를 넘겨줄 때는, 그 부모 코디가 누구인지도 알아야 한다.

    self?.finish(
      TabBarCoordinator.ChildCoordinatorType.homeDefaultScene(workSpaceId: workSpaceId)
    )

  • 모든 코디의 finish 메서드는 동일

    extension Coordinator {
      func finish(_ nextFlow: ChildCoordinatorTypeProtocol?) {
          // 1. 자식 코디 다 지우기
          childCoordinators.removeAll()
    
          // 2. 부모 코디에게 알리기
          finishDelegate?.coordinatorDidFinish(
              childCoordinator: self,
              nextFlow: nextFlow  // 다음 타겟 코디
          )
      }
    }

2. Parent : didFinsih로 종료된 코디와 다음 코디 확인

• 결과적으로 자식 코디가 종료될 때, 부모 코디에서 전달받는 값은
• 자식 코디의 타입 (CoordinatorType)* 과
• 다음 타겟 코디 (ChildCoordinatorTypeProtocol)* 이다.

• 자식 코디의 타입은 코디의 자식 코디 배열을 초기화하는 용도로 사용한다.

  childCoordinators = childCoordinators.filter { $0.type != childCoordinator.type }

• 다음 타겟 코디는 분기 처리가 필요하다
  • 위 구조에서, A 코디네이터가 종료된 상황을 생각해보자
  • 그럼 P2 코디에서 didFinish 가 실행될 것이고, 다음 타겟 코디를 실행시켜주어야 한다.
  • 분기 케이스는 총 4개이다 1. 타겟 코디가 없는 경우 2. P2의 Child 코디인 경우 (ex. C) 3. P2의 Child 코디보다 하위 코디인 경우 (ex. D) 4. P2의 Parent 코디를 타고 가야 하는 경우 (ex. B, P3)

*1. 타겟 코디가 없는 경우 *

• nextFlow가 nil인 경우. 따로 작업할 내용 없다

  if nextFlow == nil { }

2. Child 코디인 경우

• 해당 플로우를 시작하는 메서드 실행

  else if nextFlow = nextFlow as? ChildCoordinatorType {
      /* ... */
  }

3. Child 코디보다 더 하위 코디인 경우

• 직접 특정해서 정확히 누구인지 알아야 한다

  ex). 탭바코디의 자식코디
  else if let nextFlow = nextFlow as? TabBarCoordinator.ChildCoordinatorType {
      /* ... */
  }

4. Parent 코디를 타고 가야 하는 경우

• 현재 코디네이터도 종료시키고, 타겟 코디를 그대로 부모에게 전달한다

  else {
      self.finish(nextFlow)
  }

3. 커스텀 얼럿 VC을 띄우는 위치

• 프로젝트에서 자주 사용되는 커스텀 얼럿을 ViewController로 구현하였다.

• 처음에는 위 얼럿도 하나의 VC이기 때문에 코디네이터에서 띄워주어야 한다고 생각했다.
• 그래서 코디네이터에서 얼럿 창을 띄우는 메서드를 구현했다.

• 그럼 얼럿 창의 버튼 클릭 시 네트워크 통신이 필요한 경우,
• 코디네이터에서 네트워크 통신을 진행해야 한다....*
  • 물론 버튼 클릭 후 화면 전환을 바로 진행할 수 있는 건 좋지만,
  • 화면 전환 로직이 목적인 코디에서 네트워크 콜을 하고 있는 건 절대 좋지 않다.

• 그래서 이 이슈 이후에는 얼럿 창 정도는 VC에서 띄워주기로 결정했다. 버튼 클릭 시 네트워크 통신까지는 해당 VM의 역할이라고 판단했다. 이후 화면 전환이 필요한 경우에만 Coordinator에게 event로 알려준다.

4. Coordinator와 VM의 통신

• 화면 전환이 필요한 시점에, VM은 Coordinator에게 이 사실을 알려주어야 한다.
• 생각나는 방법은 두 가지였다. 클로저와 delegate

delegate를 통해 이벤트 전달

• 이를 구현하기 위해서는 프로토콜을 통해 VM에서 코디네이터를 알고 있어야 한다
• 결국, 해당 VM에서는 무조건 하나의 코디네이터를 특정해서 알고 있어야 하고, 해당 코디에서만 실행되는 이벤트를 전달해야 한다. 중심이 코디
• 하지만, 어떤 View는 여러 코디네이터에서 사용되기도 한다. 이 때, VM이 하나의 코디만 알고 있게 구현한다면 다른 코디에서는 VM에게 이벤트를 전달받지 못하게 된다.
• 물론, 여러 코디를 알고 있는 VM에게 이벤트를 받기 위해 한 번 더 프로토콜을 추상화할 수는 있지만, 너무 비효율적이고 유지보수에 좋아 보이지는 않는다.

closure를 통해 이벤트를 전달

• 클로저를 통해 이벤트를 전달하면, 중심이 VM 이 된다.
• VM은 본인이 실행할 이벤트를 실행하면 되고, 해당 VM에 연결된 코디에서 각 이벤트별로 화면 전환을 실행한다.

• 이를 위해 모든 VM에는 어떤 화면으로 전환될지에 대한 enum Event 가 존재한다.

  // HomeDefaultVM
  extension HomeDefaultViewModel {
    enum Event {
        case presentWorkSpaceListView(workSpaceId: Int)
        case presentInviteMemberView
        case presentMakeChannelView
        case goExploreChannelFlow        
        case goChannelChatting(workSpaceId: Int, channelId: Int, channelName: String)
        case goBackOnboarding
    }
  }
  

// HomeDefaultCoordinator - showHomeDefaultView class HomeDefaultSceneCoordinator: HomeDefaultSceneCoordinatorProtocol {

/* ... */

func showHomeDefaultView(_ workSpaceId: Int) {
    let homeDefaultVM = /* ... */
    homeDefaultVM.didSendEventClosure = { [weak self] event in
        switch event {
        case .presentWorkSpaceListView(let workSpaceId):
            self?.showWorkSpaceListFlow(workSpaceId: workSpaceId)

        case .presentInviteMemberView:
            self?.showInviteMemberView()

        case .presentMakeChannelView:
            self?.showMakeChannelView()

        case .goExploreChannelFlow:
            self?.showExploreChannelFlow(workSpaceId: (self?.workSpaceId)!)

        case .goChannelChatting(let workSpaceId, let channelId, let channelName):
            self?.showChannelChattingView(
                workSpaceId: workSpaceId,
                channelId: channelId,
                channelName: channelName
            )

        case .goBackOnboarding:  
            self?.finish(AppCoordinator.ChildCoordinatorType.loginScene)
        }
    }
    let vc = HomeDefaultViewController.create(with: homeDefaultVM)
    navigationController.pushViewController(vc, animated: true)
}

}

<br>

### 5. 특정 화면으로 즉시 이동하기 (Push Notification 클릭)

[Push Notification 설정](https://velog.io/@s_sub/%EC%83%88%EC%8B%B9-iOS-23%EC%A3%BC%EC%B0%A8#3-push-notification-%EC%84%A4%EC%A0%95)

<br>

## 4. 후기
### 1. 장점
#### VM에서 VC로 굳이 화면 전환 시점을 알려줄 필요 없음
- 기존에는 VC에서 화면 전환을 담당했기 때문에
VM에서 특정 시점이 되면 VC로 결과를 알려주어야 했다. (Output)

- 코디네이터를 쓴 이후에는 이 과정 자체가 필요가 없다. VC는 더 이상 화면 전환을 담당하지 않기 때문에 VM에서는 VC에게 시점을 알리지 않고, 바로 클로저를 통해 코디에게 시점을 알려준다.


- 단순히 VC의 코드가 줄었다고만 생각했는데, Output으로 VC에게 이벤트를 전달하는 코드도 줄어들었다.


<br>

#### VC의 독립성
- 물론 대부분의 화면은 이전/다음 화면이 명확하기 때문에 VC에서 이 흐름을 알고 있더라도 큰 문제는 없다.
- 그래도 코디네이터를 이용하면 각 VC는 이전 화면이 뭐였는지, 다음 화면은 뭐가 될 지 전혀 알지 못하기 때문에 보다 독립적인 인스턴스가 될 수 있다.

<br>

### 2. 단점
- 만약 연속된 present가 많고, present로 올라온 뷰에서도 계속 화면 전환이 필요하다면, 그만큼 코디네이터가 또 필요하게 된다. **(코디네이터를 새로 만드는 기준)**


- 이러면 하나의 코디네이터가 거의 하나의 View만 관리하게 되기 때문에 굳이 코디네이터를 쓸 필요가 없다고 생각했다.

- 물론 화면 전환에 대한 로직을 분리시킬 수는 있지만, 이 정도를 위해 매번 코디네이터를 새로 만드는 건 리소스 낭비라고 생각이 든다.

• UIKit, RxSwift
• Clean Architecture, MVVM-C
• Sooda 깃허브 레포

1. 개요

1. 선택 이유

• MVVM 적용 후, 확실히 VC의 역할이 많이 줄어들었으나 여전히 VM이 너무 많은 역할을 수행하고 있었다. 레이어 분리를 통해 가능한 한 VM의 역할을 더 줄여보고자 했다.
• 계획 상 test를 진행해보려고 했기 때문에, test에 용이하다는 코드를 적용시키고자 했다.

2. 진행 과정

• 구글링해서 정말 많은 레퍼런스를 읽어보았지만,, 솔직히 글만 읽었을 때 직관적으로 이게 뭔지 잘 이해하기 쉽지 않았다

• 그래서 제일 많이 등장한 프로젝트인 iOS-Clean-Architecture-MVVM를 클론하면서 레이어별로 어떤 코드를 작성했는지 보고, 어떤 방식으로 레이어가 연결되는지 공부했다. 확실히 코드를 먼저 작성해보고 다시 레퍼런스를 읽어보니까 눈에 좀 보이기 시작했다.

• 어느 정도 구조를 익힌 후, 바로 프로젝트를 생성하고 Clean Architecture를 도입했다.

  

  

  • 머릿속에 그림이 도저히 그려지지 않을 땐, 직접 굿노트에 써가면서 구조를 익혔다

3. 글 작성 방향

• 블로그에 정리를 한다면 아키텍처 내용에 대한 글을 적어야 하나 생각했는데, 그러기에는 이미 너무 좋은 글들이 많다. 굳이 또 같은 그림을 넣고, 똑같은 설명을 해야 할까 싶었다. 그리고 사실,, 추상적인 글을 보고 나조차도 제대로 이해하지 못했기 때문에,,,

• 그래서 아키텍처에 대한 설명보다는 내가 어떻게 적용했는지에 대해 정리해보려고 한다. 아무래도 사람마다 기준이 다르기 때문에, 내가 이해하고 적용한 방법이 좋은 방향이 아닐 수도 있다. 몇 년 후의 나는 또 다른 구조를 생각하고 있을 수도 있다. 어쨌든, "클린 아키텍처에 대한 내용" 보다는 "내가 적용한 클린 아키텍처"에 대해 작성해보려고 한다.

2. 내가 적용한 클린 아키텍처

아키텍처 구조

폴더링

  Sooda
  ├── Util
  │   ├── Enum
  │   ├── Constant
  │   └── Extension
  │
  ├── Resource
  │   ├── Assets
  │   ├── Font
  │   └── Base
  │
  ├── Domain
  │   ├── Entity
  │   ├── UseCase
  │   └── Interface
  │   
  ├── Presentation
  │   ├── CustomView
  │   ├── Scene #1
  │   │   ├── View
  │   │   ├── ViewModel
  │   │   ├── ViewController
  │   │   └── Coordinator
  │   ...
  │   └── Scene #n
  │       ├── View
  │       ├── ViewModel
  │       ├── ViewController
  │       └── Coordinator
  │
  ├── Data
  │   ├── UserDefaults
  │   ├── Keychain
  │   ├── Network
  │   │   └── DataMapping
  │   ├── Socket
  │   │   └── DataMapping
  │   ├── Realm
  │   │   └── DataMapping
  │   └── Repository
  │
  ├── Network
  │   ├── NetworkManager
  │   └── NetworkRouter
  │
  ├── Socket
  │   ├── SocketManager
  │   └── SocketRouter
  │
  ├── Realm
  │   └── RealmManager
  │
  └── Application
      ├── AppDelegate
      ├── SceneDelegate
      └── AppCoordinator

1. 중점적으로 생각한 부분

인스턴스 별 역할 분리

• 아키텍처를 도입한 이유이기 때문에 가장 중점적으로 고려하였다. 기존 VM의 역할을 최대한 분배하고, UseCase와 Repository도 적절한 역한 분리가 이루어지도록 했다.

의존성 방향

• 레이어 별 의존성의 방향을 유지시켜서 외부 레이어에 수정이 발생하더라도 내부 레이어에 영향이 없도록 했다.

2. 레이어 별 기능

1. Presentation Layer

• 실제 화면에 가장 가까운(?) 영역이다. MVVM-C 패턴으로 구현하였다.
• View는 뷰 객체, VC는 사용자 interaction, Coordinator는 화면 전환 로직을 수행한다
• 다른 레이어와 연결되는 부분은 VM이고, 최대한 불필요한 가공 없이 VC에게 필요한 데이터와 로직을 제공한다.

2. Domain Layer

• 프로젝트에 가장 필수적인 요소가 있는 영역이다.
• 가장 내부에 위치한 계층으로, 본인들이 어떻게 활용되는지 알 수 없다.

• Entity는 프로젝트에서 사용하는 모델 이다. 모든 곳에서 접근이 가능한 구조체들을 모아두었다.
  • Presentation Layer에서는 이 모델을 바로 뷰 객체에 보여주는 용도로 사용
  • Data Layer에서는 Entity 변형시켜서 요청 모델을 생성, 외부에 데이터를 요청하고, 응답이 오면 응답 모델을 Entity로 변형시킨다 (DataMapping)

    Enterprise wide business rules, "가장 고수준의 규칙"

• UseCase는 비즈니스 로직 이다. Repository (Data Layer)에서 전달하는 로직을 조합하고, 구조를 변형시켜서 VM (Presentation Layer)로 전달한다.
• Interface는 Repository를 UseCase에서 사용하기 위한 프로토콜이다. 실제 Repo들은 Interface를 이용한 의존성 주입을 통해 UseCase에서 활용된다 (DIP)

3. Data Layer

• Repository에서 외부 통신(?)을 통해 날 것의 데이터(?)를 받는다
• HTTP API, Socket, DB, Push Notification에서 제공하는 데이터를 받아서 DTO 타입 으로 저장한다.
• 결국 이 데이터를 UseCase에게 전달해주어야 하기 때문에 DataMapping을 통해 Entity 타입으로 변환시킨다.

3. 트러블

1. 여전히 뚱뚱한 VM

• 역할에 대한 명확한 기준 없이 무작정 코드로 구현만 하다보니, 자연스럽게 기존 방법대로 구현하면서 여전히 뚱뚱한 VM을 볼 수 있었다.
• 사실상 Repository는 네트워크 통신 응답만 하고, UseCase는 추가 가공 없이 그걸 그대로 VM에게 전달만 하고 있었다. 결국 나머지 모든 일을 VM에서 해주어야 했다.
• 이 사태를 인지하고 인스턴스 별 명확한 기준 이 필요하다고 생각했다.

2. 여전히 중복되는 코드

• 클린 아키텍처를 통해 레이어를 분리하여 역할을 나누면 중복된 코드를 줄일 수 있다.
• 예를 들어 같은 API 통신 또는 realm CRUD 작업이 여러 화면에서 필요한 경우, 기존에는 모든 VM에서 같은 코드를 작성해야 했다. 물론 Singleton Manager를 통해 어느 정도 중복된 코드를 줄일 수는 있지만, 추가 가공이 필요한 경우 결국 같은 코드를 작성해야 한다.
• 이러한 코드들(비즈니스 로직)을 UseCase와 Repository를 통해 캡슐화하고 재사용할 수 있도록 한다.
• 원래 이렇게 되어야 하는데, 이 역시 명확한 기준이 없다보니 또 여기저기 같은 코드를 남발하고 있었다.

3. 나름대로 해결 방안

• 결국 내가 해야 할 건 인스턴스 별 명확한 기준 세우기 였다
• 분리 기준은 오로지 "VM, UseCase, Repo의 역할 분리"와 "코드 중복 최소화"에 집중하면서 세웠다
• 사실 test에 적합한 기준인지도 확인을 했어야 하는데, 이번 프로젝트에서 test를 진행하지 못했기 때문에 여기에 대해서는 확인하지 못했다.

1. Repository
   • 외부 데이터(날 것의 데이터) 를 DTO 타입으로 디코딩
   • DTO 타입의 데이터를 Entity 타입으로 Mapping해서 전달

2. UseCase
   • Repo 데이터를 VM이 사용하기 편하도록 가공해서 전달
   • 최대한 VM이 바로 활용할 수 있도록 가공한다
   • 여러 Repo 데이터를 조합, 타입 변환 등

3. ViewModel
   • UseCase 데이터를 불필요한 가공 없이 활용
   • VC와의 interaction에 집중

3. 후기

1. 장점

1. VM의 역할 분리

• 결과적으로는 VM이 확실히 날씬해졌다. Presentation Layer에 필요한 내용만 VM에서 확인할 수 있기 때문에 가독성도 좋아졌다

2. DTO의 장점

• DTO 사용을 통해 사용 위치에 따라 필요한 데이터만 가지고 있을 수 있게 되었다.
• 기존에는 네트워크 응답으로 받은 데이터와 DB에서 꺼내온 데이터를 그대로 View에서도 사용했기 때문에 불필요한 데이터를 가지고 있는 경우도 있었고, 분명 같은 뷰에 나타나야 하는 데이터인데 타입이 다른 경우 등 여기저기서 많이 꼬이기도 했다.
• 이제는 확실히 구조체 자체를 사용 위치에 따라 분리해두었기 때문에 사용하기도 편하고, 가독성 역시 좋아졌다.
• init과 toDomain 을 통해 Entity와 상호작용하기 때문에 사용하기에도 크게 어렵지 않았다.

2. 단점

1. 작업량 증가

• 어쩔 수 없이 작업량 자체는 많아진다. 단순한 뷰를 만들려고 해도 생성해야 하는 파일 개수가 몇 배로 늘어난다.
• 그래서 미리 구조를 잘 생각해두고 구현을 시작해야 한다. 중간에 빠진 내용을 추가하려면 여러 파일을 돌면서 연결된 모든 레이어를 수정해야 하기 때문에 쉽지 않다.

2. 역할 분리에 대한 명확한 기준이 없다면,, 클린하지 않은 구조...

• 처음에 역할 분리에 대해 명확한 기준이 없이 무작정 구현만 했을 때, 오히려 파일만 많아지고 코드를 보기가 더 힘들었다. 이게 클린한게 맞을까..? 싶은 의문이 많이 들었던 시기다.

3. 의존성 방향이 정답인지에 대한 의문

• 클린 아키텍처의 장점은 의존성 방향이 고정되어 있기 때문에 외부 레이어에 수정이 생기더라도 내부 레이어에는 영향이 없다는 것이다. 추가적인 수정을 하지 않아도 되기 때문에 이는 확실한 장점이 된다
• 하지만 내부 레이어에 수정이 자주 생기는 프로젝트라면...? 아직 실무에 나가보지 않았기 때문에 경험하지는 못했지만, 만약 Entity를 자주 수정한다면 결국 모든 레이어를 또 수정해야 한다. 이런 경우, 클린 아키텍처가 과연 좋은 아키텍처가 될 수 있을까 하는 의문이 생겼다.

3. 아쉬운 점

1. 테스트 부재

• 시간 관계상 테스트를 진행해보지 못한 점이 가장 아쉽다. 추후에 시간이 된다면 테스트를 진행해보고, 내가 세운 기준이 테스트에도 적합한지 확인해보려고 한다.

2. ViewModel 프로토콜 부재

• UseCase와 Repository는 인터페이스, 즉 프로토콜을 이용한 의존성 주입을 통해 활용된다.
• ViewModel도 역시 이와 동일하게 구현하려 했으나, 기존에 사용하던 Input / Output 방식도 프로토콜로 구현하고 있어서 여기서 발생하는 충돌 때문에 직접 구현체로 사용할 수 밖에 없었다.
• 분명 같이 사용할 수 있는 방법은 있을 것이기 때문에, 추후 코드를 수정해볼 생각이다.

추가할 내용이 있으면 계속해서 수정해 나가겠습니다. 감사합니다.

• 앱에서 원격 알림을 받기 위해서는 서버 와 device token 이 필요하다

• 동작 구조
  1. APNs 에 앱을 등록한다
  2. device token 을 받는다
  3. device token 을 서버에 전달한다
  4. 푸시 알림이 필요한 시점에 서버는 APNs에게 메세지 데이터 와 device token 을 보낸다
     • 이 때, APNs와 서버는 TLS 통신을 하며, 서버에는 인증서가 준비되어 있어야 한다
  5. 받은 device token을 통해 APNs는 기기를 식별하여, 알림 데이터를 푸시 알림으로 보내준다

• APNs (Apple Push Notification Service)
  • 애플 기기로 푸시 알림을 전송하는 서비스
  • 오직 APNs만 기기에 직접적으로 푸시 알림을 보낼 수 있다
  • 고유한 device token을 통해 특정 디바이스로 알림을 보낸다

• Device Token
  • 앱과 디바이스 모두에게 유일성을 갖는다
  • 서로 다른 앱에서 같은 device token을 사용할 수 없고, 다른 디바이스에 설치된 같은 앱에서도 다른 device token을 사용한다
  • APNs만 해독이 가능하다
  • 로컬 저장소에 device token을 저장해두지 않는다

2. FCM Token

• FCM (Firebase Cloud Messaging)
  • 무료로 메세지를 안정적으로 전송할 수 있는 교차 플랫폼 메시징 솔루션
  • 설정에서 APNs Auth Key 를 등록한다
  • 푸시 알림을 대신 전송하는 대리자(delegate) 역할을 수행하고, 실질적으로는 APNs 서버에 푸시 알림에 대한 요청을 한다.

• 공식 문서에서는 등록 토큰 이라고 하는 FCM Token은 앱 시작 시 생성된다

  • 등록 토큰을 수신하기 위한 delegate을 설정한다

    // 공식 문서에 있는 코드
    Messaging.messaging().delegate = self

  • 최초 앱 시작 시, 토큰이 업데이트되거나 무효화될 때 신규 또는 기존 토큰을 가져온다 어떠한 경우든, 유효한 토큰이 있는 didReceiveRegistrationToken 메서드를 호출한다 이 때, 서버에 해당 토큰을 전달하거나, NotificationCenter를 이용해 앱 전체에 알린다

    // 공식 문서에 있는 코드
    func messaging(_ messaging: Messaging, didReceiveRegistrationToken fcmToken: String?) {
      print("Firebase registration token: \(String(describing: fcmToken))")
    
      let dataDict: [String: String] = ["token": fcmToken ?? ""]
      NotificationCenter.default.post(
        name: Notification.Name("FCMToken"),
        object: nil,
        userInfo: dataDict
      )
      // TODO: If necessary send token to application server.
      // Note: This callback is fired at each app startup and whenever a new token is generated.
    }

  • .token(completion: ) 메서드를 통해 원하는 시점에 직접 토큰을 가져올 수도 있다

    // 공식 문서에 있는 코드
    Messaging.messaging().token { token, error in
      if let error = error {
        print("Error fetching FCM registration token: \(error)")
      } else if let token = token {
        print("FCM registration token: \(token)")
        self.fcmRegTokenMessage.text  = "Remote FCM registration token: \(token)"
      }
    }

3. 프로젝트 적용

Sooda

• UIKit, RxSwift
• FirebaseMessaging
• Sooda 깃허브 레포

1. 세팅

• GoogleService-Info.plist 파일 추가
• Signing & Capabilities에 Push Notification 추가
• 인증서 등록 및 Profile 등록

AppDelegate - didFinishLaunchingWithOptions

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

    // GoogleSerice-info.plist에 File I/O 하는 기능
    FirebaseApp.configure()

    // 알림 delegate 설정
    UNUserNotificationCenter.current().delegate = self

    // 알림 허용 확인
    UNUserNotificationCenter.current().requestAuthorization(
        options: [.alert, .sound, .badge, .providesAppNotificationSettings]) { didAllow, error  in
        print("Notification Authorization : \(didAllow)")
    }

    // 원격 알림에 앱 등록
    application.registerForRemoteNotifications()


    // Messaging delegate 설정
    Messaging.messaging().delegate = self


    return true
}

AppDelegate - didRegisterForRemoteNotificationsWithDeviceToken

func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
    // deviceToken (APNs 토큰)을 가져와서 Messaging의 apnsToken 설정
    Messaging.messaging().apnsToken = deviceToken
}

func application(_ application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: Error) {
    print(error)
}

• application.registerForRemoteNotifications()이 성공적으로 실행되면 위 메서드를 통해 deviceToken을 받는다.
• 만약 실패 시 didFailToRegisterForRemoteNotificationsWithError 메서드가 실행된다.

• 무조건 이 둘 중에 하나가 실행되어야 하는데, 정말 가끔 둘 다 실행이 안되어서 deviceToken을 받지 못하는 경우가 꽤 있었다.... 이것저것 해도 실행이 계속 안되다가 또 갑자기 되고,,, 아직 이유는 모르겠는데, Xcode 껐켰 후 실행된 경험이 있다....

AppDelegate - didReceiveRegistrationToken

func messaging(_ messaging: Messaging, didReceiveRegistrationToken fcmToken: String?) {
      let firebaseToken = fcmToken ?? "No Token" 

      KeychainStorage.shared.fcmToken = firebaseToken
}

• firebase에서 fcm token을 받고, 이를 키체인에 저장한다.
• 만약 여기 말고 앱 내의 다른 곳에서 fcm Token을 받고 싶다면, 아래 코드를 실행한다

  Messaging.messaging().token { token, error in
    if let error = error {
      print("Error fetching FCM registration token: \(error)")
    } else if let token = token {
      print("FCM registration token: \(token)")
    }
  }

2. 서버 통신

• FirebaseMessaging에서 받은 fcm token을 서버에 전달해준다
• 서버 DB에는 서버에 전달한 계정과 fcm token이 함께 저장되고, 해당 계정에 push notification이 필요한 경우, 저장된 fcm token의 기기로 알림을 보내준다.

• 현재 프로젝트에서 deviceToken을 서버에 전달하는 API
  • 회원가입 /v1/users/join
  • 로그인(이메일, 카카오, 애플) /v1/users/login
  • FCM deviceToken 저장 /v1/users/deviceToken

2.5 deviceToken 업데이트 시점에 대한 고민 지점

• 로그인 또는 회원가입 시 deviceToken 전송
• token이 업데이트되었을 때 deviceToken 전송
• 로그아웃 시 deviceToken 정보 삭제

• 만약 여러 기기에서 로그인을 시도한다면,
  • 서버 DB 테이블에 계정 당 deviceToken을 하나만 저장할 수 있다면 가장 최신에 로그인한 계정으로 push notification이 보내진다.
  • 하지만 실질적으로 사용자가 자주 사용하는 기기는 가장 최신에 로그인한 기기가 아닐 수 있다.
  • 이런 경우, 앱 내의 특정 화면을 정해서 그 화면에 사용자가 접속했을 때 해당 계정의 deviceToken을 업데이트 해주는 것도 좋은 방법인 것 같다.

3. Push Notification 설정

• 이번 프로젝트에서는 채팅 알림을 받도록 구현이 되어있다.

• push notification 수신 시 구현 내용

  채팅에 해당하는 채팅방에 들어가면 푸시 알림이 오지 않는다	푸시 알림을 클릭했을 때, 해당 채팅방으로 바로 화면 전환

1. 채팅에 해당하는 채팅방에 들어가면 푸시 알림이 오지 않는다

// AppDelegate
// 포그라운드에서 알림 받기
func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {

    guard let userInfo = notification.request.content.userInfo as? [String: Any] else { return }

    // 1. 채널 채팅인 경우
    if let channelChatInfo: PushChannelChattingDTO = self.decodingData(userInfo: userInfo) {
        // userInfo 디코딩해서 푸시 알림 내용 확인

        // 현재 보고 있는 채팅방이 아닌 경우만 푸시 알림
        // (UserDefaults 이용해서 현재 보고 있는 채팅방 여부 확인)
        if !self.checkCurrentChannel(chatInfo: channelChatInfo) {
            completionHandler([.list, .badge, .sound, .banner])
        }
    }

    // 2. 디엠 채팅인 경우 - 생략
}

2. 푸시 알림을 클릭했을 때, 해당 채팅방으로 바로 화면 전환

AppDelegate

• 푸시 알림 클릭 시, NotificationCenter를 통해 SceneDelegate에게 알림 내용을 보낸다.

  // 푸시 알림을 클릭
  func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {
  
      guard let userInfo = response.notification.request.content.userInfo as? [String: Any] else { return }
  
      // 1. 채널 채팅인 경우
      if let channelChatInfo: PushChannelChattingDTO = self.decodingData(userInfo: userInfo) {
          // userInfo 디코딩해서 푸시 알림 내용 확인
  
          if let channelId = Int(channelChatInfo.channel_id),
             let workspaceId = Int(channelChatInfo.workspace_id) {
  
              let userInfo: [String: Any] = [
                  "channelId": channelId,
                  "workspaceId": workspaceId
              ]
  
              // Notification Post -> SceneDelegate에 observer
              NotificationCenter.default.post(
                  name: Notification.Name("channelChattingPushNotification"),
                  object: nil,
                  userInfo: userInfo
              )
          }
      }
  
      // 2. 디엠 채팅인 경우 - 생략
  
  

  completionHandler()

}

<br>

##### SceneDelegate
- NotificationCenter를 통해 푸시 알림 클릭에 대한 노티를 받으면, 
AppCoordinator 메서드 실행 
(모든 화면 초기화 후 해당되는 채팅방으로 화면 전환)
  ```swift
  class SceneDelegate: UIResponder, UIWindowSceneDelegate {

      var appCoordinator: AppCoordinator?

      func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {

          /* ... */

          setNotification()    // 노티 등록
      }
  }


  extension SceneDelegate {

      private func setNotification() {
          // 1. 채널 채팅
          NotificationCenter.default.addObserver(
              self,
              selector: #selector(channelChatPushClicked),
              name: Notification.Name("channelChattingPushNotification"),
              object: nil
          )
      }    


      // 1. 채널 채팅
      @objc
      private func channelChatPushClicked(_ notification: Notification) {

          if let userInfo = notification.userInfo,
              let channelId = userInfo["channelId"] as? Int ,
              let workspaceId = userInfo["workspaceId"] as? Int {

                  appCoordinator?.showDirectChannelChattingView(
                      workSpaceId: workspaceId,
                      channelId: channelId,
                      channelName: nil
                  )
          }
      }

AppCoordinator

• showDirectChannelChattingView : 현재 쌓여있는 뷰를 모두 초기화시키고, 곧바로 채팅 화면으로 전환한다.

• 코디네이터 구조

  class AppCoordinator: AppCoordinatorProtocol {
  
      /* ... */
  
      func showDirectChannelChattingView(
          workSpaceId: Int,
          channelId: Int,
          channelName: String?
      ) {
          /*
          1. AppCoordinator child removeAll
  
          2. AppCoordinator showTabbarFlow(workspaceId: Int)
  
          3. TabbarCoordinator prepareTabBarController(selectedItem = 0)
  
          // channel
          4 - 1. HomeDefaultCoordinator showChannelChatting
  
          //dm
          4 - 2. HomeDefaultCoordinator showDMChatting
          */
  
  

      // 1. child coordinator removeAll
      childCoordinators.removeAll()
      navigationController.viewControllers.removeAll()


      // 2. show tabBar flow
      let tabBarCoordinator = TabBarCoordinator(navigationController)
      tabBarCoordinator.finishDelegate = self
      tabBarCoordinator.workSpaceId = workSpaceId
      childCoordinators.append(tabBarCoordinator)
      tabBarCoordinator.start()
      // (-> homeDefaultCoordinator start)


      // 3. HomeDefaultCoordinator show ChannelChatting
      for i in 0...3 {
          if let homeDefaultCoordinator =  tabBarCoordinator.childCoordinators[i] as? HomeDefaultSceneCoordinatorProtocol {

                  homeDefaultCoordinator.showChannelChattingView(
                  workSpaceId: workSpaceId,
                  channelId: channelId,
                  channelName: channelName
              )
          }
      }
}

```

레퍼런스

Apple Developer - Registering your app with APNs Firebase - Cloud Messaging 개발자 소들이 - APNs :: Push Notification 동작 방식 FCM을 도입할 때 고려할 것들 Jihyun Kim - IOS에서 이미지가 있는 푸시알림 구현하기 웅쓰 - iOS 앱 Push 알림 이해하기

• 클라이언트와 서버 간 연결을 종료하기 전까지 연결된 통신 계속 유지
• 연결 시작 단계, 연결 유지 단계, 연결 종료 단계로 상태 구분

• 양방향 통신(full-duplex), 실시간(Real-Time) 네트워킹
  • HTTP와 달리 요청이 없더라도 서버 -> 클라이언트 데이터 송신 가능
  • 원하는 시점에 서로 데이터 주고받기 가능

WebSocket 구현

Preview

• WebSocketManager 싱글톤 패턴
• URLSessionWebSocketTask, URLSessionWebSocketDelegate
• UPBit WebSocket API 활용
• SwiftUI, Combine

Model

// 응답 데이터 모델
struct OrderBookWS: Decodable {
  let timestamp: Int
  let totalAskSize, totalBidSize: Double
  let orderbookUnits: [OrderbookUnit]

  enum CodingKeys: String, CodingKey { /*...*/ }
}

struct OrderbookUnit: Codable {
  let askPrice, bidPrice, askSize, bidSize: Double

  enum CodingKeys: String, CodingKey { /*...*/ }
}


// 뷰 데이터 모델
struct OrderBookItem: Hashable, Identifiable {
  let id = UUID()
  let price: Double
  let size: Double
}

struct Market: Codable, Hashable {
  let id = UUID()
  let market: String
  let koreanName: String
  let englishName: String

  enum CodingKeys: String, CodingKey { /*...*/ }
}

class WebSocketManager: NSObject

싱글톤 + 필요한 프로퍼티 선언

  static let shared = WebSocketManager()

  private override init() {
      super.init()
  }

  private var timer: Timer?    // 5초에 한 번씩 Ping 보내기 위한 타이머
  private var webSocket: URLSessionWebSocketTask?
  private var isOpen = false   // 소켓 연결 상태
  var orderBookSbj = PassthroughSubject<OrderBookWS, Never>()
  // RxSwift PublishSubject   -> Combine PassthroughSubject
  // Rx는 데이터 타입만 설정       -> Combine은 에러 타입도 설정

1. open

• 소켓 연결 -> delegate의 didOpen으로 연결 확인
• URLSession - default - webSocketTask 활용
• iOS 13부터 webSocketTaks 등장

  func openWebSocket() {
      if let url = URL(string: "wss://api.upbit.com/websocket/v1") {
          let session = URLSession(configuration: .default, delegate: self, delegateQueue: nil)
          // -> URLSessionWebSocketDelegate 프로토콜 채택
          webSocket = session.webSocketTask(with: url)
          webSocket?.resume()
          ping()
      }
  }

2. close

• 소켓 해제 -> delegate의 didClose로 해제 확인

• 다양한 CloseCode가 존재하는데 주로 .goingAway와 messageTooBig 사용

• VM, VC와 따로 동작하는 timer 관리 중요 (Keyword : run loop)

  func closeWebSocket() {
      webSocket?.cancel(with: .goingAway, reason: nil)
      webSocket = nil
  
      timer?.invalidate()
      timer = nil
  
      isOpen = false  
  }

3. send

• 소켓 통신을 통해 받고 싶은 데이터를 요청 포맷에 맞춰서 요청

  func send(_ codes: String) {
   let requestStr = """
   [{"ticket":"test"},{"type":"orderbook","codes":["\(codes)"]}]
   """
  
   webSocket?.send(.string(requestStr), completionHandler: { error  in
       if let error { print("send Error : \(error.localizedDescription)") }
   })
  }

4. receive

• 필요한 순간에 서버에서 데이터를 받는다

  func receive() {
      if isOpen { // 소켓이 열렸을 때만 데이터 수신이 가능하도록 한다
          webSocket?.receive(completionHandler: { [weak self] result  in
              switch result {
              case .success(let success):
                  print("receive Success : \(success)")
  
                  switch success {
                  case .data(let data):
                      print("success - data : \(data)")
  
                      do {
                          let decodedData = try JSONDecoder().decode(OrderBookWS.self, from: data)
                          // RxSwift .onNext -> Combine .send
                          self?.orderBookSbj.send(decodedData)
                      } catch {
                          print("decodingError : \(error.localizedDescription)")
                      }
  
                  case .string(let string):
                      print("success - string : \(string)")
  
                  @unknown default:
                      fatalError()
                  }
  
              case .failure(let failure):
                  print("receive Fail : \(failure.localizedDescription)")
                  self?.closeWebSocket()  // 소켓 데이터가 제대로 오지 않기 때문에, 닫아준다
              }
  
              // recursive
              self?.receive()
          })
  
      }
  }

5. ping

• 서버에 의해 연결이 끊어지지 않도록 주기적으로 ping을 보낸다 (120초 Idle Timeout)

• 선언해둔 timer 활용

  private func ping() {
      self.timer = Timer.scheduledTimer(withTimeInterval: 5.0, repeats: true, block: { [weak self] _ in
  
          self?.webSocket?.sendPing(pongReceiveHandler: { error  in
              if let error {
                  print("Ping Error : \(error.localizedDescription)")
              } else {
                  print("Ping Success") 
              }
          })
      })
  }

extension WebSocketManager: URLSessionWebSocketDelegate

• URLSessionWebSocketDelegate를 타고타고 올라가보면, 최종적으로 NSObjectProtocol 을 채택하고 있다.
• 즉, 원래대로라면 WebSocketManager 에서 NSObjectProtocol의 필수 프로퍼티와 메서드를 구현해야 한다.
• 이러한 번거로움을 줄이기 위해 이미 해당 내용을 구현하고 있는 NSObject를 WebSocketManger가 상속받도록 한다

• 소켓이 연결되었을 때와 해제되었을 때 실행되는 메서드

  extension WebSocketManager: URLSessionWebSocketDelegate {
  
      func urlSession(_ session: URLSession, webSocketTask: URLSessionWebSocketTask, didOpenWithProtocol protocol: String?) {
          print(#function)
          print("WebSocket OPEN")
  
          isOpen = true
  
          receive()    // 데이터 수신 시작
      }
  
      func urlSession(_ session: URLSession, webSocketTask: URLSessionWebSocketTask, didCloseWith closeCode: URLSessionWebSocketTask.CloseCode, reason: Data?) {
          print(#function)
          print("WebSocket CLOSE")
  
          isOpen = false
      }
  }

class SocketTestViewModel: ObservableObject

필요한 프로퍼티 선언

var marketData: Market    // 어떤 코인인지

@Published var askOrderBook: [OrderBookItem] = []    // 매도 정보
@Published var bidOrderBook: [OrderBookItem] = []    // 매수 정보

// RxSwift disposeBag -> Combine cancellable
private var cancellable = Set<AnyCancellable>()

init

• 소켓 연결. 즉, VM 인스턴스를 만들면 바로 소켓 통신이 시작된다

  init(market: Market) {
      self.marketData = market
  
      WebSocketManager.shared.openWebSocket()
  
      WebSocketManager.shared.send(marketData.market)
  
      // Rx subscribe        -> Combine sink
      // Rx Scheduler(.main) -> Combine receive
      // Rx Dispose          -> Combine AnyCancellable
      WebSocketManager.shared.orderBookSbj
          .receive(on: DispatchQueue.main)
          .sink { [weak self] order in
              guard let self else { return }
  
              self.askOrderBook = order.orderbookUnits
                  .map { .init(price: $0.askPrice, size: $0.askSize)}
                  .sorted { $0.price > $1.price }
  
              self.bidOrderBook = order.orderbookUnits
                  .map { .init(price: $0.bidPrice, size: $0.bidSize)}
                  .sorted { $0.price > $1.price }
          }
          .store(in: &cancellable)
  }

deinit

• VM 인스턴스가 해제되면 소켓 연결 중단
• 만약 메모리 누수가 발생해서 deinit 함수가 실행되지 않으면 소켓은 영원히 해제되지 않는다. 주의하기

  deinit {
      WebSocketManager.shared.closeWebSocket()
  }    

WebSocket 결과

IAP 특성 & 정책

1. 개발자 계정의 모든 앱 기준, 최대 10,000개의 앱 내 구입 제품 생성 가능

2. 사용자 경험을 위해, 국가/지역 설정 불가능. 특정 국가에만 보여주거나 숨기기 불가능

3. 유니버셜의 경우에도 일부 플랫폼에 대해 인앱 상품 제거 불가능
   • 유니버셜 : AppStoreConnect에서 두 개 이상의 플랫폼 유형 선택
   • 동일한 앱 내 구입 상품을 여러 플랫폼에서 제공할 수 있어야 한다

4. 자동 갱신 구독 및 비소모성 인앱 상품의 경우 가족 공유 설정이 가능하지만, 가족 공유 한 번 하고나면 비활성화 불가능

5. 앱 내 구입 삭제는 최소 31일 전 공지가 필요하며, 프로모션에 인앱 상품이 포함되어 있다면 미리 종료해야 한다

6. 인앱 상품 생성
   • 상품 종류 (소모성, 비소모성, 자동 갱신, 비자동 갱신) 선택 후 등록
   • Localization에 대한 추가 / 제거 가능
   • 프로모션 이미지 추가 및 제거 (iOS 11 이상)
     • 앱 내 구입 상품을 App Store에서 홍보 가능
       • 한 번에 최대 20개의 프로모션 이미지 가능
   • 앱 심사 정보 추가
     • 추가 정보와 인앱 상품이 포함된 스크린샷으로 심사 진행
     • 심사 시에만 반영되고, App Store에는 반영되지 않는다

7. Sandbox 테스트 계정
   • 결제 테스트 가능 (iOS 14 이상)
   • 결제 실패 테스트 가능
   • "구독" 같은 기능 테스트할 때 유용함 자동 갱신 구독 테스트
     • 지속 기간 단축, 구독 해지 전까지 최대 5회 자동 갱신
     • (1주일: 3분, 1개월: 5분, ... 1년: 1시간)
   • 만약 Sandbox 계정이 아닌 실제 결제로 테스트를 할 경우, 구매자가 직접 애플에 환불 요청을 해야 한다
     • 개발자에게 환불 처리하는 것은 불가능

8. AppStore 서버 알림 URL
   • AppStoreConnect [일반 정보] -> [앱 정보]
   • 사용자의 인앱 상품에 대한 변경 알림 (구독 중지, 구입 환불, ...)

9. StoreKit 2 사용 가능
   • async / await 도입
   • StoreKit 1의 각종 제약 수정
   • 실시간으로 변하는 상태 체크가 쉽게 가능해짐

IAP 구현

1. 유료 개발자 계정 생성 및 유료 응용 프로그램 계약 서명
2. App Store Connect에서 앱 네 구입 설정
3. Xcode로 앱 내 구입 활성화
4. 앱 내 구입 디자인 및 제작
5. 앱 내 구입 테스트
6. App Store에 앱 및 앱 내 구입 출시

1. 유료 개발자 계정 생성 및 유료 응용 프로그램 계약 서명

2. App Store Connect에서 앱 내 구입 설정

3. Xcode 앱 내 구입 활성화

4. 앱 내 구입 디자인 및 제작 (코드 구현)

IAPService.swift

import StoreKit

• SKProduct : 상품 정보 (price, name, ...)
• SKPayment : 지불 정보 (product id, request data)
• SKPaymentRequest : 결제 요청 시 사용 타입 (delegate로 성공/실패 알려줌)
• SKPaymentQueue.default() : 데이터 가져오기에 사용

ProductRequestCompletionHandler

• 내부 딜리게이트를 통해 IAP 성공/실패 알 수 있고, 외부에도 completion 제공하는 식으로 구현하기 위해 따로 completion 정의
• completion은 외부에서 정의하고, 실행은 내부에서 불림 (delegate 패턴)

  // completion 정의. (외부에서 정의하고, 내부에서 실행)
  typealias ProductRequestCompletionHandler = (_ success: Bool, _ products: [SKProduct]?) -> Void

protocol IAPServiceType

• 외부에서 필요한 메서드 명시

  • getProducts : products 항목 (상품 정보) 가져오기
  • buyProduct : product 구입
  • isProductPurchased : 구입했는지 확인
  • restorePurchased : 구입한 목록 확인

  // 프로토콜 -> 외부에서 필요한 메서드 명시
  protocol IAPServiceType {
      var canMakePayments: Bool { get }
  
      func getProducts(completion: @escaping ProductRequestCompletionHandler)
      func buyProduct(_ product: SKProduct)
      func isProductPurchased(_ productID: String) -> Bool
      func restorePurchases()
  }

class IAPService

• NSObject 상속 (StoreKit 사용), IAPServiceType 채택

  class IAPService: NSObject, IAPServiceType {

• 필요한 프로퍼티 선언 및 init

  • productIDs : 앱스토어 커넥트에 등록된 productID
  • purchaseProductIDs : 구매한 productID
  • productRequest : productID로 부가 정보 조회하기 위한 인스턴스
  • productsCompletionHandler : 사용하는 쪽에서 성공/실패 했을 때 completion을 통해 값을 넘겨줄 수 있다.

    // 필요한 프로퍼티
    private let productIdentifiers: Set<String>
    private var purchasedProducts: Set<String> = []
    private var productRequest: SKProductsRequest?
    private var productsCompletionHandler: ProductsRequestCompletionHandler?
    

  // 상품 정보 받아서 초기화 및 SKPaymentQueue 연결 init(productIdentifiers: Set) {

  // "com.blogPost.App.~~"
  self.productIdentifiers = productIdentifiers
  
  self.purchasedProducts = productIdentifiers.filter {
      // UserDefaults에 저장해둔 구매 여부
      UserDefaults.standard.bool(forKey: $0) == true
  }
  
  super.init()
  
  SKPaymentQueue.default().add(self)
  // App Store와 지불정보를 동기화하기 위한 Observer
  // -> SKPaymentTransactionObserver 프로토콜 채택

  }

• canMakePayment : 사용자의 디바이스가 현재 결제가 가능한지 확인

  var canMakePayments: Bool {
      return SKPaymentQueue.canMakePayments()
  }

• 프로토콜 메서드 정의

  // 상품 정보 조회
  func getProducts(completion: @escaping ProductsRequestCompletionHandler) {
      self.productRequest?.cancel()
      self.productsCompletionHandler = completion
      self.productRequest = SKProductsRequest(productIdentifiers: self.productIdentifiers)
      self.productRequest?.delegate = self
      // -> SKProductsRequestDelegate 채택
      self.productRequest?.start()    // 인앱 상품 조회 시작
      // -> delegate 함수 실행 (SKProductsRequestDelegate)
  }
  
  // 상품 구입
  func buyProduct(_ product: SKProduct) {
      let payment = SKPayment(product: product)
      SKPaymentQueue.default().add(payment)
      // -> paymentQueue() 함수 실행
  }
  
  // 구입 확인
  func isProductPurchased(_ productID: String) -> Bool {
      return self.purchasedProducts.contains(productID)
  }
  
  // 구입 내역 복원
  func restorePurchases() {
      SKPaymentQueue.default().restoreCompletedTransactions()
  }

extension IAPService: SKProductsRequestDelegate

• getProducts에서 completionHandler를 캡쳐해두고, 여기서 실행한다

  extension IAPService: SKProductsRequestDelegate {
  
      // App Store Connect에서 상품 정보 조회
      func productsRequest(_ request: SKProductsRequest, didReceive response: SKProductsResponse) {
  
          let products = response.products
  
          self.productsCompletionHandler?(true, products)
  
          self.clearRequestAndHandler()
  
          // 출력
          products.forEach { item in
              print("Found Product : \(item.productIdentifier) \(item.localizedTitle)")
          }
      }
  
  

  // fail
  func request(_ request: SKRequest, didFailWithError error: Error) {

      self.productsCompletionHandler?(false, nil)

      self.clearRequestAndHandler()

      // 출력
      print("Error : \(error.localizedDescription)")
  }

  // 초기화
  private func clearRequestAndHandler() {
      self.productRequest = nil
      self.productsCompletionHandler = nil
  }

}

<br>


#### `extension IAPService: SKPaymentTransactionObserver`
- `SKPaymentQueue`에서 처리되는 일
  - `purchased`, `failed`, `restored`, `deferred`, `purchasing`
  - 구매 성공 or 구매 복원 시 UserDefaults 업데이트 및 noti 해주기
  ```swift
  extension IAPService: SKPaymentTransactionObserver {
      func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {
          print(#function)

          for transaction in transactions {
              let state = transaction.transactionState

              switch state {
              case .purchasing:
                  print("구매하는 중")
              case .purchased:
                  print("구매 완료")
                  completePurchase(transaction: transaction)
              case .failed:
                  print("구매 실패")
                  failPurchase(transaction: transaction)
              case .restored:
                  print("구매 복원")
                  restorePurchase(transaction: transaction)
              case .deferred:
                  print("deferred")
              @unknown default:
                  fatalError()
              }
          }
      }

      // 구매 완료 (성공)
      private func completePurchase(transaction: SKPaymentTransaction) {
          print(#function)

          guard let id = transaction.original?.payment.productIdentifier else { return }
          deliverPurchaseNotificationFor(id: id)
          SKPaymentQueue.default().finishTransaction(transaction)
      }

      // 구매 실패
      private func failPurchase(transaction: SKPaymentTransaction) {
          print(#function)

          if let transactionError = transaction.error as NSError?,
             transactionError.code != SKError.paymentCancelled.rawValue {
              print("TransactionError : \(transactionError.localizedDescription)")
          }
          SKPaymentQueue.default().finishTransaction(transaction)
      }

      // 구매 복원 성공
      private func restorePurchase(transaction: SKPaymentTransaction) {
          print(#function)

          guard let id = transaction.original?.payment.productIdentifier else { return }
          deliverPurchaseNotificationFor(id: id)
          SKPaymentQueue.default().finishTransaction(transaction)
      }

      private func deliverPurchaseNotificationFor(id: String?) {
          guard let id else { return }

          self.purchasedProducts.insert(id)
          UserDefaults.standard.set(true, forKey: id)

          NotificationCenter.default.post(
              name: .iapServicePurchaseNotification,    // 곧 정의
              object: id
          )
      }

      func paymentQueue(_ queue: SKPaymentQueue, removedTransactions transactions: [SKPaymentTransaction]) {
          print(#function)
      }
  }

extension Notification.Name

• 노티 관리를 위한 메세지 정의

  extension Notification.Name {
      static let iapServicePurchaseNotification = Notification.Name("IAPServicePurchaseNotification")
  }

MyProducts.swift

enum MyProducts

• Product ID를 가지고 있는 Wrapping 타입. (IAPService를 wrapping한다)

  enum MyProducts {
      static let productID = "com.blogPost.s_sub.heart100"
      static let iapService: IAPServiceType = IAPService(productIdentifiers: Set<String>([productID]))
  
      static func getResourceProductName(_ id: String) -> String? {
          id.components(separatedBy: ".").last
      }
  }

IAPTestViewController.swift

class IAPTestViewController

• 구현한 내용 이용하기

  class FinalIAPTestViewController: UIViewController {
  
    private let restoreButton = UIButton()
    private let buyButton = UIButton()
    private let productLabel = UILabel()
  
    private var products = [SKProduct]()
  
    func setting() {...}
  
  

override func viewDidLoad() {
    super.viewDidLoad()

    setting()
    getProducts()
}

// 상품 정보 조회
func getProducts() {
    MyProducts.iapService.getProducts { [weak self] success, products in
        if success,
           let products = products {
            DispatchQueue.main.async {
                self?.products = products
                self?.productLabel.text = "\(products.first?.productIdentifier ?? "")\n \(products.first?.localizedTitle ?? "")"
            }
        }
    }
}

// 구매 버튼 클릭
@objc func buyButtonClicked() {
    MyProducts.iapService.buyProduct(products.first!)
}

// 복구 버튼 클릭 (구입 목록 조회)
@objc func restoreButtonClicked() {
    MyProducts.iapService.restorePurchases()
}


// 노티 세팅
func setNotification() {
    NotificationCenter.default.addObserver(
        self,
        selector: #selector(handlePurchaseNoti(_:)),
        name: .iapServicePurchaseNotification,
        object: nil
    )
}

@objc private func handlePurchaseNoti(_ notification: Notification) {
    // 노티 핸들 (뷰 업데이트)
}

}

## 6. 앱 내 구입 테스트

![](https://velog.velcdn.com/images/s_sub/post/d48fd8b4-9be6-4951-8e31-60025a949e78/image.png)

![](https://velog.velcdn.com/images/s_sub/post/9779011e-d36f-445e-8fa5-66a73e2e2dc2/image.png)

![](https://velog.velcdn.com/images/s_sub/post/96e98957-4f8d-446c-8663-f2bd732e73ba/image.png)

![](https://velog.velcdn.com/images/s_sub/post/6a3a050e-a7b3-41f2-aaea-cc1cac7aecf2/image.png)


<br>
<br>
<br>



# 영수증 유효성 검증
---
- 위 코드 상에서는 따로 영수증 검증을 하지 않았지만, 사용자가 상품을 구매하려고 할 때 영수증 유효성에 대한 검증을 해야 한다.
- 서버가 없는 경우 클라이언트 상에서 검증하고, 서버가 있을 때는 영수증 정보를 서버에 전달한다.
- **영수증 검증이 완료된 후에 트랜잭션을 종료한다**   
`SKPaymentQueue.default().finishTransaction(transaction)`


### 1. 영수증 정보
```swift
func getReceiptData(_ productIdentifier: String) -> String? {
    if let receiptURL = Bundle.main.appStoreReceiptURL,
       FileManager.default.fileExists(atPath: receiptFileURL.path) {

       do {
               let receiptData = try Data(contensOf: receiptFileURL)
            let receiptString = receiptData.base64EncodedString(
                options: NSData.Base64EncodingOptions(rawValue: 0)
            )
            return receiptString

       } catch {
               print("구매 이력 영수증 데이터 변환 과정에서 에러 : \(error.localizedDescription)")
            return nil
       }

    }

    print("구매 이력 영수증 URL 에러")
    return nil
}

2. 영수증 검증 (서버 x)

• Validation URL Endpoint
  • Sandbox URL : https://sandbox.itunes.apple.com/verifyReceipt
  • Production URL : https://buy.itunes.apple.com/verifyReceipt

1. 클라이언트 -> 애플 (production URL)
   • 애플 서버(production URL)로 영수증 정보를 POST로 보낸다

2. 애플 -> 클라이언트
   • 애플 서버에서 응답값을 클라이언트에게 보낸다
   • status 값이 0이면, 유효한 영수증으로 판단한다
   • status 값이 21007이면, Sandbox 테스트용 영수증임을 의미한다

3. 클라이언트 -> 애플 (sandbox URL)
   • 2에서 21007을 받았으면, 해당 정보를 sandbox URL로 다시 보낸다

4. 애플 -> 클라이언트
   • status 값이 0이면, 유효한 영수증으로 판단한다.

• 이 과정에서 만약 cancellation_date_ms 라는 키가 추가되어서 응답이 왔다면, 환불 영수증으로 판단한다
• 유효한 영수증으로 판단될 경우, 구매한 인앱 상품에 대한 로직을 클라이언트에서 처리한다. (광고 제거, 테마 사용, ...)

3. 영수증 검증 (서버 o)

• 서버가 있다면, 영수증 유효성 검증은 서버에서 진행한다.
• 이 경우 클라이언트의 역할에 대해 보자
  

1. 클라이언트 -> 서버 : 인앱 구매 목록 요청 / 응답

• 가장 먼저, 클라이언트에서 사용자가 이미 상품을 구매했는지 에 대한 판단을 해주어야 한다
• 만약 비소모성 상품이라면, 더 이상 구매가 불가능하도록 처리해주어야 한다
• 즉, 서버에게 해당 사용자의 인앱 구매 목록에 대한 데이터를 요청하고, 이미 상품을 구매했는지 체크한다.

• 사용자가 해당 상품을 안드로이드 기기의 구글 플레이 스토어에서 다운받은 앱에서 구매했을 가능성도 생각해야 한다. 이 경우에도 역시 상품의 구매 상태를 유지시켜주어야 하기 때문에 항상 서버에게 사용자의 구매 목록에 대한 요청을 해야 한다.

• 응답을 받으면 인앱 상품 표시 / 구매 상태에 반영한다

2. 클라이언트 -> 서버 : 구매 가능 여부 요청 / 응답

• 진짜 구매가 가능한지에 대한 요청을 서버에게 보낸다. 구매 목록에 없는 걸 확인했더라도, 이 이후부터 구매 요청 사이에 사용자가 다른 기기에서 구매할 가능성을 고려한다. 이 찰나의 순간에 다른 디바이스에서 결제가 이루어질 수도 있기 때문이다

3. 클라이언트 -> 애플 : 인앱 결제 요청 / 응답

• 애플 서버에 실제 결제에 대한 요청을 진행한다

4. 클라이언트 -> 서버 : 영수증 검증 요청 / 응답

• 결제 정보에 대한 영수증 검증을 서버에 요청한다. 이 경우에는 서버에서 영수증 검증을 하고, 결과를 응답으로 보내준다.

5. 클라이언트 -> 서버 : 인앱 결제 완료 요청 / 응답

• 최종적으로 결제에 대한 완료 요청을 진행한다

구매 복원 (restore)

• 만약 내가 아이폰을 바꿨다고 하자. 이전 기기에서 사용하던 앱을 새롭게 다운받았는데, 이전 기기에서 해당 앱의 "광고 제거" 상품을 구매했다.
• 이러한 경우에, 반드시 구매 복원을 해주어야 한다.

• 구매 복원은 비소모성 상품에 대해 가능하고, 소모성 상품에 대해서는 불가능하다

• 구매 복원에 대한 기능은 필수로 구현해야 하고, 없다면 리젝 사유가 될 수 있다.

• 만약 서버가 존재해서 구매 복원에 대한 기능을 서버에서 자체적으로 해주고 있다면, 앱 내에서 구현하지 않아도 된다. (심사 제출 시 소명으로 언급해주면 된다)

• 즉, 서버가 없다면 애플 계정에 따라 클라이언트 상에서 체크하는 과정이 필요하지만, 서버에서 사용자의 구매 내역을 저장해주고 있다면 굳이 클라이언트 상에서 이 기능을 구현할 필요는 없다.

• iOS 14부터 도입
• SwiftUI로만 구현 가능 (UIViewRepresentable 불가능)

• 위젯은 미니앱이 아니다
  • 사용자에게 정보를 보여주기 위한 도구에 불과
  • 위젯 자체가 하나의 앱 기능을 할 수는 없다
  • 메모리 30MB 제약

• 버전
  • iOS 14 : 홈 화면, 오늘 보기
  • iOS 16 : + 잠금 화면
  • iOS 17 : + Mac Desktop, iPad Lock Screen, StandBy, Watch Smart Stack

• Widget Configuration (속성 편집에 대한 기능)

  • Static Configuration : 위젯 편집 항목이 나타나지 않으며, 사용자가 설정을 변경할 수 있는 옵션이 없다

  • Intent Configuration : 위젯 편집 기능을 통해 사용자가 여러 Intent값을 수정할 수 있도록 위젯을 구성할 수 있다 : iOS 17부터 'AppIntentConfigutation' 으로 변경

  • Activity Configuration : Live Activity

Widget Extension

• 새로운 타겟으로 'Widget Extension'을 추가한다

  

• 기본적으로 폴더 단위로 나눠지게 되고, 다른 타겟이기 때문에 접근 제어자에 따라 기존 프로젝트에 대한 접근 여부가 결정된다.
• 또는 인스펙터 영역의 Target Membership에서 사용 범위를 정할 수 있다.

코드

• 위젯 파일은 크게 4가지의 struct로 구성되어 있다.
  • Provider에서 사용자가 설정한 시간에 맞춰 위젯을 업데이트할 수 있게 한다
  • Entry에서 위젯에 필요한 데이터를 제공한다
  • EntryView는 Entry를 통해 구성하며, UI를 담당하는 역할과 유사하다
  • Widget에서는 static, intent, activity인지에 따라 최종적인 위젯을 구성한다

1. Provider

• "어떤 시간대에 어떻게 업데이트할지"
• typealias를 통해 사용할 구조체를 정한다

  struct Provider: TimelineProvider {
    typealias Entry = SimpleEntry
  

- 사용자는 짧은 시간 내에 위젯을 보아야 하기 때문에, 위젯에 로딩이 길면 좋지 않다.
- 그래서 미리 위젯 뷰를 그리고 있다가 시간에 맞춰 뷰를 업데이트하고, TimelineEntry 배열을 통해 특정 시간에 위젯을 업데이트 할 수 있도록 한다.
- 즉, Provider는 위젯의 디스플레이를 업데이트할 시기를 WidgetKit에게 알려주는 역할을 수행한다
![](https://velog.velcdn.com/images/s_sub/post/9843c8c3-90a4-4dec-973f-a48121bdb225/image.png)


#### 1. placeholder
- 위젯을 최초로 렌더링할 때 사용한다 (스켈레톤 뷰 역할)
- 데이터를 보여줄 때까지 걸리는 시간동안 보여줄 뷰
- 사용자가 잠금 화면에서 민감한 정보를 숨기도록 선택한 경우 잠금 해제 전까지 placeholder로 위젯을 숨길 수 있다
- AOD 화면에서 잠금 전까지 보이지 않도록 구성할 수 있다
  ```swift
  func placeholder(in context: Context) -> SimpleEntry {
      SimpleEntry(
          date: Date(),
          emoji: "😀",
          title: "플레이스 홀더 타이틀",
          price: 1200000
      )
  }

2. getSnapshot

• 위젯 추가할 때 미리보기 화면 (위젯 갤러리)
• 위젯을 구성하는 데이터가 네트워크 통신을 통해서 가져오거나, 계산하는 데 몇 초 이상 걸릴 경우를 대비해 mock 데이터를 이용해 빠르게 위젯을 그릴 수 있도록 설정할 때도 이용

  func getSnapshot(in context: Context, completion: @escaping (SimpleEntry) -> ()) {
      let entry = SimpleEntry(
          date: Date(),
          emoji: "😎",
          title: "미리보기 타이틀",
          price: 16000000
      )
      completion(entry)
  }

3. getTimeLine

• 위젯 상태 변경 시점 (시간에 대한 핸들링)

• 뷰를 미리 렌더링하고 올린다. (위젯의 작동 방식 - Meet WidgetKit)

• Widget 상태가 변경될 미래 시간이 포함된 timelineEntry 배열과 timeline 정책을 포함하고 있는 Timeline을 반환한다

• .atEnd는 TimelineReloadPolicy 구조체에서 설정되어 있는 타입 프로퍼티로, 타임의 마지막 날짜가 지난 후, WidgetKit이 새로운 타임라인을 요청할 수 있도록 지정하는 정책 에 해당한다.

  func getTimeline(in context: Context, completion: @escaping (Timeline<Entry>) -> ()) {
      var entries: [SimpleEntry] = []
  
      let currentDate = Date()
  
      // 타임라인 배열
      for hourOffset in 0 ..< 30 {
          let entryDate = Calendar.current.date(byAdding: .hour, value: hourOffset, to: currentDate)!
  
          let entry = SimpleEntry(
              date: entryDate,
              emoji: "😇",
              title: "타임라인 타이틀",
              price: 2000000
          )
  
          entries.append(entry)
      }
  
      let timeline = Timeline(entries: entries, policy: .atEnd)
      // .never : 요청 x
      // .after : 특정 시간 이후
  
      completion(timeline)
  }

2. Entry

• 위젯을 구성하는 데 필요한 데이터를 갖는다
• TimelineEntry 프로토콜을 채택한다
  • date : 필수로 가져야 하며, 위젯이 다시 그려질 시간에 대한 정보를 갖는다
  • relevance : 스마트 스택을 가진 위젯에서 위젯의 우선순위를 결정한다. (Score가 높은 위젯이 스택의 최상단으로 올라오도록 설정되어 있다)

    struct SimpleEntry: TimelineEntry {    
      let date: Date
      let emoji: String
      let title: String 
      let price: Int
    }

3. EntryView

• Provider를 통해 Entry를 제공받으면, Entry를 이용해서 위젯의 뷰를 그려준다

• Entry를 매개변수로 가지는 SwiftUI View이기 때문에 원하는 UI를 자유롭게 구성할 수 있다

  struct MyCoinOrderBookWidgetEntryView : View {
      var entry: Provider.Entry   // 프로퍼티로 Entry에 대한 정보를 넣어준다
  
      var body: some View {
          VStack {
              Text(entry.date, style: .time)
              Text(entry.emoji)
              Text(entry.title)
              Text(entry.price.formatted())
          }
      }
  }

4. Widget

• 최종적으로 WidgetConfiguration을 구성한다

• 동일한 크기의 여러 위젯을 만들 수 있는데, kind는 위젯의 고유한 문자열이다.

• .configurationDisplayName, description 을 통해 위젯 갤러리에서 보일 위젯의 이름과 설명을 설정할 수 있다

• .supportedFamilies 를 통해 제공할 위젯의 크기를 설정할 수 있다

  // 위젯의 정보
  struct MyCoinOrderBookWidget: Widget {
      let kind: String = "MyCoinOrderBookWidget"  
  
      var body: some WidgetConfiguration {
          StaticConfiguration(kind: kind, provider: Provider()) { entry in
              if #available(iOS 17.0, *) {
                  MyCoinOrderBookWidgetEntryView(entry: entry)
                      .containerBackground(.fill.tertiary, for: .widget)
              } else {
                  MyCoinOrderBookWidgetEntryView(entry: entry)
                      .padding()
                      .background()
              }
          }
          .configurationDisplayName("보유 코인")  
          .description("실시간 시세를 확인하세요")
          .supportedFamilies([.systemSmall, .systemLarge, .systemMedium])
      }
  }

App Group

• 위젯과 앱은 엄연히 다른 앱이기 때문에, 데이터를 share하고 싶으면 AppGroup을 만들어 주어야 한다.
  • AppGroup을 통해 App과 App Extension 간 데이터를 공유할 수 있다
  • Extension의 Bundle은 Container App 번들에 포함되어 있지만, 두 가지는 각각 Container를 가지고 있기 때문에 둘 사이에는 데이터가 share되지 않는다.

• "Singing & Capabilities" 에서 App Group을 추가해준다

Share UserDefaults

• UserDefaults 역시 App과 App Extension에서 저장되는 위치가 다르기 때문에 shared container를 만들어서 처리하는 과정이 필요하다

1. UserDefaults.groupShared

• 해당 아이디를 가진 그룹 내에 있는 UserDefaults에 저장할 수 있도록 한다

  extension UserDefaults {
    static var groupShared: UserDefaults {
        let appGroupID = "group.widgetTest.myCoinOrderBook"
        return UserDefaults(suiteName: appGroupID)!
    }
  }

2. Entry View

struct MyCoinOrderBookWidgetEntryView : View {
    var entry: Provider.Entry   // 프로퍼티로 Entry에 대한 정보를 넣어준다

    var body: some View {
        VStack {
            Text(entry.date, style: .time)
            Text(entry.emoji)
            Text(UserDefaults.groupShared.string(forKey: "Market") ?? "기본값" )
            Text(entry.title)
            Text(entry.price.formatted())
        }
    }
}

3. Setting

.onAppear {
  UserDefaults.groupShared.set(viewModel.market.koreanName, forKey: "Market")
}

WidgetCenter

1. getCurrentConfiguration

• 현재 활성화되어 있는 위젯 정보를 확인할 수 있다

  WidgetCenter.shared.getCurrentConfigurations { response in
      switch response {
      case .success(let info):
          print(info)
      case .failure(let error):
          print(error)
      }
  }

  

2. reloadTimeLines

• 필요한 시점에 위젯을 업데이트할 수 있다

  .onAppear {
      viewModel.fetchOrderBook()
  
      print("----- 현재 활성화 되어 있는 위젯 -----")
      WidgetCenter.shared.getCurrentConfigurations { response in
          switch response {
          case .success(let info):
              print(info)
          case .failure(let error):
              print(error)
          }
      }
  
      print("이전 : ", UserDefaults.groupShared.string(forKey: "Market"))
      UserDefaults.groupShared.set(viewModel.marketData.koreanName, forKey: "Market")
      print("이후 : ", UserDefaults.groupShared.string(forKey: "Market"))
  
      WidgetCenter.shared.reloadTimelines(ofKind: "MyCoinOrderBookWidget")
  }

  

• 앱에서 UI는 Data에 의존 해서 자신의 상태를 결정한다 (Data 변경 -> View 갱신)

• UIKit에서는 Data의 변경 시점마다 UI 업데이트에 대한 모든 코드를 작성해야 한다. 따라서 Data 변경에 따른 View 관리가 쉽지 않았다.

• 이러한 불편함을 해소하기 위해 SwiftUI에서는 Source of Truth 를 통해 Data와 UI 사이의 의존 관계 를 만들고,
• Data의 상태가 변하면 body를 rendering* 하라는 하나의 의존 관계로 정의하고 있다.

Source of Truth

• View에서 읽는 모든 Data에는 Source of Truth 가 존재한다 -> @State

• 메인 화면과 상세 화면의 Data가 동일해야 한다면, 동일한 Data 요소는 한 군데에서 다뤄져야 한다 -> @Binding

  Source of Truth : Derived Value = @State : @Binding

• SoT는 단일(Single Source of Truth)로 존재해야 하며, 이를 복제하는 것은 상태의 불일치를 일으킬 수 있다.

• 즉, Data의 변경에 자동으로 UI가 반응하는(의존 관계) SwiftUI에서는 Data에 대한 관리가 중요한데, 단 하나의 데이터 를 다른 뷰에게 전달함으로써 데이터를 여러 곳에서 복사해서 사용하는 사이드이펙트까지 방지할 수 있다.

Property Wrapper

• 데이터의 일관성을 유지하기 위해, SwiftUI에서는 다음과 같은 Property Wrapper를 사용한다.

1. @State

• View에서 가지는 Source of Truth로, Data에 대한 상태를 저장하고 관찰한다.

• 해당 View가 Data를 소유하고 관리한다는 개념을 명시적으로 나타내기 위해 private 접근 제어자를 사용하는 것이 좋다.

• "상태 프로퍼티" @State 는 　1. 이 Data는 변할 수 있고, 2. View가 Data에 의존성을 가진다는 것을 의미한다.

• 즉, Data가 변경이 되면 View도 변경되어야 한다는 의미로, 변경 사항이 감지될 때마다 매번 View를 새로 그려준다.

• @State를 통해 하나의 Single Source of Truth가 생성된다

2. @Binding

• 외부에서 Source of Truth를 주입받고 참조받는다.

• 상위 뷰가 가진 상태를 하위 뷰에서 사용하고 수정할 수 있도록 하는 Derived Value 이다.

• 값을 읽고 수정하여 다른 뷰에 갱신된 데이터를 전달한다.

• $ 접두어를 사용하며, 내부적으로 PropertyWrapper의 projectedValue를 이용한다는 것을 의미한다

• 같은 뷰에서 값을 읽거나 쓰는 경우에는 $ 없이 일반 변수처럼 사용이 가능하다.

3. @Published

• ObservableObject 프로토콜에서 프로퍼티를 선언할 때 사용되는 property wrapper

• @Published 로 선언된 프로퍼티의 값이 변경될 때마다 뷰 업데이트

  ObservableObject 프로토콜

  • 클래스에 ObservableObject 프로토콜을 채택하면, 이 프로토콜은 해당 클래스의 인스턴스를 관찰하고 있다가 내부의 @Published 로 선언된 데이터가 변경이 될 때마다 신호를 보내주고, 신호를 받은 뷰는 업데이트된다.

4. @StateObject

• ObservvableObject 프로토콜을 구독하고 값이 업데이트될 때마다 뷰를 갱신하는 propertywrapper

• @Published 로 선언된 데이터가 변경될 때의 신호를 받는다

• @StateObject 로 선언된 인스턴스는 생성 시점에 한 번 초기화되고, 이후 뷰의 렌더링 여부와 상관 없이 @StateObject 로 선언된 변수는 뷰 내에서 재사용된다.

5. @ObservedObject

• ObservvableObject 프로토콜을 구독하고 값이 업데이트될 때마다 뷰를 갱신하는 propertywrapper

• @State와 @Binding의 관계처럼 @StateObject로 선언한 인스턴스를 함께 공유하고 싶을 때 사용한다 즉, 상위 뷰에서 @StateObject 로 만든 데이터를 하위 뷰에게 전달하고 싶을 때, 데이터를 주입해주면 하위 뷰에서는 인스턴스를 직접 생성하지 않고 전달받아 사용할 수 있다.

• @ObservedObject 로 선언된 인스턴스는 뷰가 렌더링될 때 인스턴스가 새롭게 생성되기 때문에 기존에 @StateObject로 주입받은 데이터가 휘발될 수 있다.

참고

WWDC : Data Flow Through SwiftUI SwiftUI) Source of Truth란?

일반적인 UserDefualts 사용 방법

enum Key: String {
    case email, nickname, phone
}

// set
UserDefaults.standard.set("0@naver.com", forKey: Key.email.rawValue)
UserDefaults.standard.set("보리밥", forKey: Key.nickname.rawValue)
UserDefaults.standard.set("010-1234-1234", forKey: Key.phone.rawValue)

// get
let email = UserDefaults.standart.string(forKey: Key.email.rawValue)
let nickname = UserDefaults.standart.string(forKey: Key.nickname.rawValue)
let phone = UserDefaults.standart.string(forKey: Key.phone.rawValue)

1. enum UserDefaultsManager

UserDefault에 직접 접근하지 않고, 열거형 UserDefaultsManager를 통해 접근한다

enum UserDefaultsManager {

    // 컴파일 최적화 측면 - enum 내부에 선언한다
    enum Key: String {
        case email, nickname, phone
    }

    // 1. email 
    static var email: String {
        get {
            UserDefaults.standard.string(forKey: Key.email.rawValue) ?? "No Email"
        }
        set {
            UserDefaults.standard.set(newValue, forKey: Key.email.rawValue)
        }
    }

    // 2. nickname
    static var nickname: String {
        get {
            UserDefaults.standard.string(forKey: Key.nickname.rawValue) ?? "No Nickname"
        }
        set {
            UserDefaults.standard.set(newValue, forKey: Key.nickname.rawValue)
        }
    }

    // 3. phone
    static var phone: String {
        get {
            UserDefaults.standard.string(forKey: Key.phone.rawValue) ?? "No Phone"
        }
        set {
            UserDefaults.standard.set(newValue, forKey: Key.phone.rawValue)
        }
    }
}

/* ===== 사용 ===== */
UserDefaultsManager.email = "1@naver.com"
UserDefaultsManager.nickname = "보리보리밥"
UserDefaultsManager.phone = "010-1234-1234"

let email = UserDefaultsManager.email
let nickname = UserDefaultsManager.nickname
let phone = UserDefaultsManager.phone

2. struct MyDefaults

구조체 MyDefaults 로 한 번 더 감싼다

struct MyDefaults {
    let key: String 
    let defaultValue: String 

    var myValue: String {
        get {
            UserDefaults.standard.string(forKey: key) ?? defaultValue
        }
        set {
            UserDefaults.standard.set(newValue, forKey: key)
        }
    }
}


enum UserDefaultsManager {

    enum Key: String {
        case email, nickname, phone
    }

    static var email = MyDefaults(key: Key.email.rawValue, defaultValue: "No Email")
    static var nickname = MyDefaults(key: Key.nickname.rawValue, defaultValue: "No Nickname")
    static var phone = MyDefaults(key: Key.phone.rawValue, defaultValue: "No Phone")
}

/* ===== 사용 ===== */
UserDefaultsManager.email.myValue = "2@naver.com"
let email = UserDefaultsManager.email.myValue

2.5 struct MyDefaults + Generic

위 구조체 형식으로 만들면, 결국 myValue 타입이 달라질 때마다 또 다시 연산 프로퍼티를 여러 개 만들어야 한다. 이를 해결하기 위해 Generic 을 활용한다.

struct MyDefaults<T> {
    let key: String 
    let defaultValue: T

    let myValue: T {
        get {
            UserDefaults.standard.object(forKey: key) as? T ?? defaultValue
        }
        set {
            UserDefaults.standard.set(newValue, forKey: key)
        }
    }
}

3. Property Wrapper

구조체 MyDefaults 에 대해 propertyWrapper의 역할을 하도록 한다. 기존에 myValue로 선언한 프로퍼티를 wrappedValue 로 교체함으로써 사용 시 코드를 더 줄일 수 있게 된다

@propertyWrapper
struct MyDefaults<T> {
    let key: String 
    let defaultValue: T

    var wrappedValue: T {
        get {
            UserDefaults.standard.object(forKey: key) as? T ?? defaultValue
        }
        set {
            UserDefaults.standard.set(newValue, forKey: key)
        }
    }
}

enum UserDefaultsManager {

    enum Key: String {
        case email, nickname, phone
    }

    @MyDefaults(key: Key.email.rawValue, defaultValue: "No Email")
    static var email

    @MyDefaults(key: Key.nickname.rawValue, defaultValue: "No Nickname")
    static var nickname

    @MyDefaults(key: Key.phone.rawValue, defaultValue: "No Phone")
    static var phone
}


/* ===== 사용 ===== */
UserDefaultsManager.email = "3@naver.com"
let email = UserDefaultsManager.email.myValue

1. 소개

• 사용 라이브러리 : FSCalendar

• 구현 기능
  • 하루 선택 시 원 모양 배경으로 선택 날짜 표시
  • 시작/마지막 날짜 선택 시 두 날짜를 포함한 기간을 이어진 배경으로 표시

• 아이디어
  • Stack Overflow - How to select range fscalendar
  • FSCalendar Custom Cell 적용
  • 기본적으로 FSCalendar에서 제공하는 selection 효과를 사용하지 않고, 커스텀 셀의 배경을 바꿔가면서 UI를 구현한다

• 단점
  • 셀 클릭 시마다 calendar.reloadData()를 실행해야 하기 때문에 리소스 낭비가 심하다.

2. 구현

(1). Calendar Setting

• 사용할 calendar에 대해 기본적인 세팅을 한다

  var calendar = FSCalendar()
  
  calendar.scrollDirection = .vertical    // 스크롤 방향
  calendar.allowsMultipleSelection = true // 여러 날짜 선택 가능
  
  calendar.register(SelectDatesCustomCalendarCell.self, forCellReuseIdentifier: SelectDatesCustomCalendarCell.description())  // 커스텀 셀 등록
  
  calendar.appearance.titleFont = .boldSystemFont(ofSize: 18)    // 날짜 표시 레이블 폰트 설정
  calendar.appearance.headerTitleFont = .boldSystemFont(ofSize: 20)    // 월 표시 레이블 폰트 설정
  
  calendar.today = nil    // 기본 오늘 선택 해제
  calendar.appearance.selectionColor = .clear    // 기본 선택 배경 투명 -> 커스텀 셀 배경으로 표시
  calendar.appearance.caseOptions = .weekdayUsesSingleUpperCase  // 요일 텍스트를 영어 한글자로 표시
  
  // 기본 색상 선택
  calendar.appearance.titleDefaultColor = .black
  calendar.appearance.headerTitleColor = .black
  calendar.appearance.weekdayTextColor = .black
  calendar.appearance.titleSelectionColor = UIColor.appColor(.main1)

(2). enum

• 편의를 위해 날짜 타입을 enum으로 정의해준다.

  enum SelectedDateType {
      case singleDate    // 날짜 하나만 선택된 경우 (원 모양 배경)
      case firstDate    // 여러 날짜 선택 시 맨 처음 날짜
      case middleDate // 여러 날짜 선택 시 맨 처음, 마지막을 제외한 중간 날짜
      case lastDate   // 여러 날짜 선택시 맨 마지막 날짜
      case notSelectd // 선택되지 않은 날짜
  }

(3). Custom Cell

• 3개의 인스턴스가 필요하다
  • leftRectangle, rightRectangle, circle
  • 선택된 날짜의 타입(firstDate, middleDate, endDate)에 따라, 어떤 인스턴스를 Hidden 처리할지 결정한다.
    

레이아웃 및 기본 설정

  class SelectDatesCustomCalendarCell: FSCalendarCell {

    var circleBackImageView = UIImageView()
    var leftRectBackImageView = UIImageView()
    var rightRectBackImageView = UIImageView()

    func setConfigure() {

        contentView.insertSubview(circleBackImageView, at: 0)
        contentView.insertSubview(leftRectBackImageView, at: 0)
        contentView.insertSubview(rightRectBackImageView, at: 0)
    }

    func setConstraints() {

        // 날짜 텍스트의 레이아웃을 센터로 잡아준다 (기본적으로 약간 위에 있다)
        self.titleLabel.snp.makeConstraints { make in
            make.center.equalTo(contentView)
        }

        leftRectBackImageView.snp.makeConstraints { make in
            make.leading.equalTo(contentView)
            make.trailing.equalTo(contentView.snp.centerX)
            make.height.equalTo(46)
            make.centerY.equalTo(contentView)
        }

        circleBackImageView.snp.makeConstraints { make in
            make.center.equalTo(contentView)
            make.size.equalTo(46)
        }

        rightRectBackImageView.snp.makeConstraints { make in
            make.leading.equalTo(contentView.snp.centerX)
            make.trailing.equalTo(contentView)
            make.height.equalTo(46)
            make.centerY.equalTo(contentView)
        }

    }

    func settingImageView() {
        circleBackImageView.clipsToBounds = true
        circleBackImageView.layer.cornerRadius = 23

        // 선택 날짜의 배경 색상을 여기서 정한다.
        [circleBackImageView, leftRectBackImageView, rightRectBackImageView].forEach { item  in
            item.backgroundColor = UIColor.appColor(.main3)
        }
    }
  }

날짜의 타입에 따라 셀의 배경 정해주기

  class SelectDatesCustomCalendarCell: FSCalendarCell {
      func updateBackImage(_ dateType: SelectedDateType) {
          switch dateType {
          case .singleDate:
              // left right hidden true
              // circle hidden false
              leftRectBackImageView.isHidden = true
              rightRectBackImageView.isHidden = true
              circleBackImageView.isHidden = false

          case .firstDate:
              // leftRect hidden true
              // circle, right hidden false
              leftRectBackImageView.isHidden = true
              circleBackImageView.isHidden = false
              rightRectBackImageView.isHidden = false

          case .middleDate:
              // circle hidden true
              // left, right hidden false
              circleBackImageView.isHidden = true
              leftRectBackImageView.isHidden = false
              rightRectBackImageView.isHidden = false

          case .lastDate:
              // rightRect hidden true
              // circle, left hidden false
              rightRectBackImageView.isHidden = true
              circleBackImageView.isHidden = false
              leftRectBackImageView.isHidden = false
          case .notSelectd:
              // all hidden
              circleBackImageView.isHidden = true
              leftRectBackImageView.isHidden = true
              rightRectBackImageView.isHidden = true
          }

      }

  }

(4). ViewController

프로토콜 연결

  class SelectedDateViewController: UIViewController {
      func settingCalendar() {
          mainView.calendar.delegate = self
          mainView.calendar.dataSource = self
      }
  }

필요한 변수

class SelectedDateViewController: UIViewController {
    private var firstDate: Date?    // 배열 중 첫번째 날짜
    private var lastDate: Date?        // 배열 중 마지막 날짜
    private var datesRange: [Date] = []    // 선택된 날짜 배열
}

cellFor date

extension SelectedDateViewController: FSCalendarDataSource {

    // 매개변수로 들어온 date의 타입을 반환한다
    func typeOfDate(_ date: Date) -> SelectedDateType {

        let arr = datesRange

        if !arr.contains(date) {
            return .notSelectd    // 배열이 비어있으면 무조건 notSelected
        }

        else {
            // 배열의 count가 1이고, firstDate라면 singleDate
            if arr.count == 1 && date == firstDate { return .singleDate }    

            // 배열의 count가 2 이상일 때, 각각 타입 반환
            if date == firstDate { return .firstDate }
            if date == lastDate { return .lastDate }

            else { return .middleDate }
        }
    }

    func calendar(_ calendar: FSCalendar, cellFor date: Date, at position: FSCalendarMonthPosition) -> FSCalendarCell {

        guard let cell = calendar.dequeueReusableCell(withIdentifier: SelectDatesCustomCalendarCell.description(), for: date, at: position) as? SelectDatesCustomCalendarCell else { return FSCalendarCell() }

        // 현재 그리는 셀의 date의 타입에 기반해서 셀 디자인
        cell.updateBackImage(typeOfDate(date))

        return cell
    }
}

didSelect

extension SelectedDateViewController: FSCalendarDelegate {
    func calendar(_ calendar: FSCalendar, didSelect date: Date, at monthPosition: FSCalendarMonthPosition) {

        // case 1. 현재 아무것도 선택되지 않은 경우 
            // 선택 date -> firstDate 설정
        if firstDate == nil {
            firstDate = date
            datesRange = [firstDate!]

            mainView.calendar.reloadData() // (매번 reload)
            return
        }

        // case 2. 현재 firstDate 하나만 선택된 경우
        if firstDate != nil && lastDate == nil {
            // case 2 - 1. firstDate 이전 날짜 선택 -> firstDate 변경
            if date < firstDate! {
                calendar.deselect(firstDate!)
                firstDate = date
                datesRange = [firstDate!]

                mainView.calendar.reloadData()    // (매번 reload)
                return
            }

            // case 2 - 2. firstDate 이후 날짜 선택 -> 범위 선택
            else {
                var range: [Date] = []

                var currentDate = firstDate!
                while currentDate <= date {
                    range.append(currentDate)
                    currentDate = Calendar.current.date(byAdding: .day, value: 1, to: currentDate)!
                }

                for day in range {
                    calendar.select(day)
                }

                lastDate = range.last
                datesRange = range

                mainView.calendar.reloadData()    // (매번 reload)
                return
            }
        }

        // case 3. 두 개가 모두 선택되어 있는 상태 -> 현재 선택된 날짜 모두 해제 후 선택 날짜를 firstDate로 설정
        if firstDate != nil && lastDate != nil {

            for day in calendar.selectedDates {
                calendar.deselect(day)
            }

            lastDate = nil
            firstDate = date
            calendar.select(date)
            datesRange = [firstDate!]

            mainView.calendar.reloadData()    // (매번 reload)
            return
        }


    }
}

didDeselect

extension SelectDateViewController: FSCalendarDelegate {
    // 이미 선택된 날짜들 중 하나를 선택 -> 선택된 날짜 모두 초기화
    func calendar(_ calendar: FSCalendar, didDeselect date: Date, at monthPosition: FSCalendarMonthPosition) {

        let arr = datesRange    
        if !arr.isEmpty {
            for day in arr {
                calendar.deselect(day)
            }
        }
        firstDate = nil
        lastDate = nil
        datesRange = []

        mainView.calendar.reloadData()    // (매번 reload)
    }

3. 완성

1. PublishSubject

• 초기값이 없다

• 구독 이후 전달받은 이벤트부터 반영된다

• complete 이후의 이벤트는 반영되지 않는다

  func aboutPublishSubject() {
      let publish = PublishSubject<Int>()
  
      publish.onNext(20)
      publish.onNext(30)
  
      publish
          .subscribe(with: self) { owner , value in
              print("PublishSubject onNext - \(value)")
          } onError: { owner , error in
              print("PublishSubject onError - \(error)")
          } onCompleted: { owner in
              print("PublishSubject onCompleted")
          } onDisposed: { owner in
              print("PublishSubject onDisposed")
          }
          .disposed(by: disposeBag)
  
      publish.onNext(3)   // 요기부터 반영
      publish.onNext(45)
      publish.on(.next(9))
  
      publish.onCompleted()
  
      publish.onNext(200)
      publish.onNext(500)
  }

  

2. BehaviorSubject

• 초기값이 있다 (선언 시 값을 넣어준다)

• 구독하기 전 가장 마지막 이벤트를 반영한다 (버퍼처럼 가지고 있는다)

• complete 이후의 이벤트는 반영되지 않는다

  func aboutBehaviorSubject() {
      let behavior = BehaviorSubject(value: 100)
  
      behavior.onNext(20)
      behavior.onNext(30) // 얘는 요게 찍히네!!
  
      behavior
          .subscribe(with: self) { owner , value in
              print("BehaviorSubject onNext - \(value)")
          } onError: { owner , error in
              print("BehaviorSubject onError - \(error)")
          } onCompleted: { owner in
              print("BehaviorSubject onCompleted")
          } onDisposed: { owner in
              print("BehaviorSubject onDisposed")
          }
          .disposed(by: disposeBag)
  
      behavior.onNext(3)
      behavior.onNext(45)
      behavior.on(.next(9))
  
      behavior.onCompleted()
  
      behavior.onNext(200)
      behavior.onNext(500)
  }

  

3. ReplaySubject

• 초기값이 없다

• 선언 시 버퍼 사이즈를 넣어준다

• 구독 시점 기준 버퍼 사이즈만큼 이전 이벤트부터 반영된다

• complete 이후의 이벤트는 반영되지 않는다

  func aboutReplaySubject() {
      let replay = ReplaySubject<Int>.create(bufferSize: 3)
  
      replay.onNext(1)
      replay.onNext(2)
      replay.onNext(3)
      replay.onNext(4)
      replay.onNext(5)    // 요기부터 찍힘!! <- 구독한 시점 기준으로 버퍼 사이즈만큼
  
      replay.onNext(20)
      replay.onNext(30)
      replay
          .subscribe(with: self) { owner , value in
              print("ReplaySubject onNext - \(value)")
          } onError: { owner , error in
              print("ReplaySubject onError - \(error)")
          } onCompleted: { owner in
              print("ReplaySubject onCompleted")
          } onDisposed: { owner in
              print("ReplaySubject onDisposed")
          }
          .disposed(by: disposeBag)
  
      replay.onNext(3)
      replay.onNext(45)
      replay.on(.next(9))
  
      replay.onCompleted()
  
      replay.onNext(200)
      replay.onNext(500)
  }

  

4. AsyncSubject

• 초기값이 없다

• 구독 전 이벤트는 반영되지 않는다

• complete 직전 이벤트 하나만 반영된다

• complete 이후의 이벤트는 반영되지 않는다

  func aboutAsyncSubject() {
      let async = AsyncSubject<Int>()
  
      async.onNext(1)
      async.onNext(2)
      async.onNext(3)
      async.onNext(4)
      async.onNext(5)
  
      async.onNext(20)
      async.onNext(30)
      async
          .subscribe(with: self) { owner , value in
              print("AsyncSubject onNext - \(value)")
          } onError: { owner , error in
              print("AsyncSubject onError - \(error)")
          } onCompleted: { owner in
              print("AsyncSubject onCompleted")
          } onDisposed: { owner in
              print("AsyncSubject onDisposed")
          }
          .disposed(by: disposeBag)
  
      async.onNext(3)
      async.onNext(45)
      async.on(.next(9)) // 요기만 찍힘!
  
      async.onCompleted()
  
      async.onNext(200)
      async.onNext(500)
  }

  

CombineLatest

• 두 개의 Sequence를 하나의 Sequence로 엮는다
• 서로 다른 타입의 Sequence를 받을 수 있고, 다른 타입의 Sequence를 만드는 것도 가능하다

예시

let email = emailTextField.rx.text.orEmpty
let password = passwordTextField.rx.text.orEmpty

let validation = Observable.combineLatest(email, password) { first , second in
    return first.count > 8 && second.count > 6
}

validation
    .bind(to: signInButton.rx.isEnabled)
    .disposed(by: disposeBag)

validation
    .subscribe(with: self) { owner , value in
        owner.signInButton.backgroundColor = value ? UIColor.blue : UIColor.red
        owner.emailTextField.layer.borderColor = value ? UIColor.blue.cgColor : UIColor.red.cgColor
        owner.passwordTextField.layer.borderColor = value ? UIColor.blue.cgColor : UIColor.red.cgColor
    }
    .disposed(by: disposeBag)

BehaviorSubject vs. PublishSubject

• CombineLatest 는 엮어주는 두 Sequence에 모두 최초 이벤트가 있어야 합쳐진 Sequence에서 이벤트가 발생한다. 즉, 초기값이 없는 경우 이벤트가 발생하지 않는다.

1. BehaviorSubject 사용

• 선언할 때 넣어준 초기값부터, onNext로 전달하는 이벤트들도 잘 반영된다

  func testCombineLatest() {
      let a = BehaviorSubject(value: 2)
      let b = BehaviorSubject(value: "가")
  
      Observable.combineLatest(a, b) { first , second in
          return "결과 : \(first) & \(second)"
      }
      .subscribe(with: self) { owner , value in
          print(value)
      }
      .disposed(by: disposeBag)
  
      a.onNext(100)
      a.onNext(200)
      a.onNext(300)
  
      b.onNext("감")
      b.onNext("남")
      b.onNext("담")
  }

  

2. PublishSubject 사용

• 두 subject 객체에 모두 값이 지정되기 전까지 subscribe가 일어나지 않는다

  func testCombineLatest() {
      let a = PublishSubject<Int>()
      let b = PublishSubject<String>() 
  
      Observable.combineLatest(a, b) { first , second in
          return "결과 : \(first) & \(second)"
      }
      .subscribe(with: self) { owner , value in
          print(value)
      }
      .disposed(by: disposeBag)
  
      a.onNext(100)
      a.onNext(200)
      a.onNext(300)
  
      b.onNext("감")
      b.onNext("남")
      b.onNext("담")
  }

  

RxCocoa

• 최초 이벤트가 없을 때는 CombineLatest 이벤트가 발생하지 않는다는 건 알겠다.

• Q. 그럼 맨 처음에 예시로 든 TextField.rx.text.orEmpty 는 초기값을 넣지 않았는데, 왜 이벤트가 잘 실행되었을까?
• A. TextField.rx.text.orEmpty 는 초기값이 없는 것이 아니고, 빈 문자열을 이벤트로 전달하기 때문에 정상적으로 combineLatest 이벤트가 실행된다

• Q. 그럼 RxCocoa에서 제공하는 위와 같은 친구들은 모두 초기값이 있는 거라고 봐도 될까?

• A. 그렇지 않더라.

  • 궁금해서 Button.rx.tap 을 두 개 만들어서 똑같이 테스트했는데, 하나의 버튼만 클릭했을 때는 이벤트가 발생하지 않고 나머지 버튼을 클릭한 순간 정상적으로 combineLatest 이벤트가 발생함을 확인할 수 있었다.

  
  let a = signInButton.rx.tap
  let b = signUpButton.rx.tap
  
  let emit = Observable.combineLatest(a, b) { first , second in
      print("탭탭 컴바인 레이티스트")
  }
  emit.subscribe(with: self) { owner , _ in
      print("탭탭 섭스크라이브")
  }
  .disposed(by: disposeBag)

  

1. 반환값 타입 : Disposable

• 일반적으로 사용하는 subscribe 함수는 반환값이 존재한다

  let textArray = BehaviorSubject(value: ["Hue", "Jack", "Koko", "Bran"])
  
  // 구독하기 -> 반환값의 타입은? : Disposable
  textArray.subscribe(with: self) { owner , value in
      print("onNext - \(value)")
  } onError: { owner , error in
      print("onError - \(error)")
  } onCompleted: { owner in
      print("onCompleted")
  } onDisposed: { owner in
      print("onDisposed")
  }

• 그래서 이렇게만 쓰면 반환값을 사용하지 않았다는 노란색 warning이 뜬다

• 반환값의 타입은 Disposable 이라는 프로토콜인 걸 확인할 수 있다

• 어쨌든 이 반환값을 사용해야 하고, 그래서 일반적으로 disposeBag에 담는 코드를 뒤에 붙여준다

  let textArray = BehaviorSubject(value: ["Hue", "Jack", "Koko", "Bran"])
  
  // 구독하기 -> 반환값의 타입은? : Disposable
  textArray.subscribe(with: self) { owner , value in
      print("onNext - \(value)")
  } onError: { owner , error in
      print("onError - \(error)")
  } onCompleted: { owner in
      print("onCompleted")
  } onDisposed: { owner in
      print("onDisposed")
  }
  .disposed(by: disposeBag)

2. Observable과 Subject 차이 (dispose 관점)

• Subject와 Observable의 정의를 배울 때 Subject는 Observable과 Observer의 역할을 모두 수행한다 라고 배웠다

• 그럼 dispose되는 시점에 어느 차이가 있는지 확인해보자

  
  let textArray = BehaviorSubject(value: ["Hue", "Jack", "Koko", "Bran"])
  let textArray = Observable.from(["Hue", "Jack", "Koko", "Bran"])
  
  /* subscribe 코드는 위와 동일하다 */

  

  

• Observable로 선언한 경우, onNext로 방출이 끝나면 그 즉시 onCompleted가 실행되고, onDisposed까지 실행되면서 dispose가 완료되었음을 확인할 수 있다
• 하지만 Subject로 선언한 경우, onNext 실행 이후 별다른 코드가 보이지 않는다

• 단순하게 정의에서 차이점을 생각하면,
• Observable*은 데이터를 방출한 순간, 역할을 다 했다. 하지만 Subject는 Observer의 역할, 즉 데이터를 전달받을 수도 있기 때문에 아직 역할이 남았다고 표현할 수 있다.
• 따라서 Subject 는 onCompleted가 실행되지 않고, dispose도 역시 실행되지 않는다

3. dispose 실행 (onError, onCompletd)

• dispose 는 리소스가 정리됨을 의미하고, 메모리가 해제됨을 의미한다. 즉, 더 이상 할 일이 없을 때 dispose가 실행된다

• 2번에서 유추할 수 있는 점은, 아마 onError 또는onCompleted가 실행된다면 그 즉시 dispose가 실행될 것이다

• onCompleted 에 대해서는 2번에서 확인했으므로, onError를 실행시켜보자

• onError 실행시키는 것도 생각보다 간단하진 않다

  enum JackError: Error {    // Error 프로토콜의 열거형
      case invalid
  }
  
  textArray.onNext(["hihi"])
  textArray.onNext(["ho"])
  
  textArray.onError(JackError.invalid)    // Error 이벤트 전달
  
  textArray.onNext(["a", "b", "c"])        // 여긴 전달이 되지 않을 것이다
  textArray.onNext(["d", "e", "f"])

  

• onError 이벤트가 실행된 순간, dispose가 실행되는 것을 확인할 수 있다

• 당연히 dispose 된 이후에 onNext로 전달한 이벤트는 받을 수 없다

4. 직접 dispose (Disposable 프로토콜)

• 여태까지 정리한 내용은
  1. subscribe 이후에는 disposeBag 이라는 곳에 Stream을 담아둔다
  2. onError 또는 onCompleted가 실행되면 알아서 dispose가 실행된다

• 근데 onError 나 onCompleted가 실행되지 않았더라도 내 맘대로 dispose시키고 싶을 수도 있다. 즉, 내가 원하는 시점에 dispose를 실행시키고 싶다

• 코드를 살짝 변형시켜서, subscribe 한 Stream 자체를 변수에 담는다

  let textArrayValue = textArray
                          .subscribe(with: self) { owner , value in
                              print("next - \(value)")
                          } onError: { owner , error in
                              print("error - \(error)")
                          } onCompleted: { owner in
                              print("completed")
                          } onDisposed: { owner in
                              print("disposed")
                          }

• 요렇게 코드를 작성하면, 맨 처음 1번에서 목격한 노란색 워닝이 뜨지 않는다 (반환값을 상수에 받았으니까)
• 1번에서 확인했듯이, 상수의 타입은 Disposable 이다
  • Disposable 프로토콜의 정의를 타고 들어가면 dispose 메서드가 있고, 이게 내가 해야 실행시켜야 하는 메서드이다.

• 즉, 이제 원하는 시점에 메서드를 실행시키기만 하면 된다

  DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
      textArrayValue.dispose()    // "dispose" : 직접적으로 리소스를 정리함
  }

5. disposeBag의 메커니즘

• 여태까지 정리한 내용은, Stream을 dispose 하기 위해서
  1. onError 또는 onCompleted 가 실행되거나
  2. Stream을 상수에 저장해서 직접 메서드를 실행해야 한다

• 그럼 여태까지 Rx를 배우면서 항상 당연하게 적었던 .disposed(by: disposeBag) 은 뭐냐
• 위의 두 케이스에 있지 않기 때문에 여태까지 작성한 Stream들은 모두 메모리에 남아있고, 꾸준히 메모리 누수를 발생시키고 있었던 것일까?

• 는 당연히 아니고, disposBag을 통해 dispose 메서드가 실행되고 있었다

• DisposeBag 클래스의 정의를 타고 들어가보자 (설명에 필요하지 않은 내용은 지웠다)

  public final class DisposeBag: DisposeBase {
  
      // state
      private var disposables = [Disposable]()
  
      /// This is internal on purpose, take a look at `CompositeDisposable` instead.
          private func dispose() {
          let oldDisposables = self._dispose()
  
          for disposable in oldDisposables {
              disposable.dispose()
          }
      }
  
      private func _dispose() -> [Disposable] {
          self.lock.performLocked {
              let disposables = self.disposables
  
              self.disposables.removeAll(keepingCapacity: false)
              self.isDisposed = true
  
              return disposables
      }
  
      deinit {
          self.dispose()
      }
  } 

• 간단하게 코드를 훑어보면,
  1. 내가 disposeBag에 담아둔 Stream들이 disposables 라는 배열에 저장된다
  2. dispose 메서드가 실행되면, 그 배열을 반복문으로 돌면서 각 Stream에 대해 dispose() 를 실행한다. 위에서 내가 직접 dispose() 를 실행시킨 부분과 동일하다
     • 두 dispose가 다르다는 점을 주의하자
  3. dispose 메서드가 실행되는 시점은, 인스턴스가 deinit될 때이다

• 정리하면, VC 또는 VM 클래스에서 계속 생성하고 다녔던 let disposeBag = DisposeBag() 인스턴스가 deinit될 때, 해당 disposeBag이 물고 있던(?) 모든 Stream에 대해 dispose가 실행된다.

• 따라서, 해당 VC 또는 VM 클래스가 deinit되는 순간 메모리 정리가 싹 되기 때문에 메모리 누수가 발생하지 않는다

6. rootVC의 dispose

• 5번을 정리하면, 어차피 VC가 정상적으로 deinit 되면, Stream들의 메모리 누수 걱정을 할 필요가 없다
• 하지만 rootVC는 deinit이 실행되지 않을 것이다. 만약 rootVC의 Stream에 대해 dispose를 실행해야 한다면 어떻게 해야 할까

1. 직접 dispose

• 첫 번째 방법은 4번에서 했던 것처럼 모든 Stream에 대해 직접 dispose 메서드를 실행하는 것이다

• 4번과 동일하게, disposeBag에 담지 않고 모든 Stream을 상수에 담아주었다

  let increment = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)
  
  let incrementValue = increment
      .subscribe(with: self) { owner , value in
          print("next - \(value)")
      } onError: { owner , error in
          print("error - \(error)")
      } onCompleted: { owner in
          print("completed")
      } onDisposed: { owner in
          print("disposed")
      }
  
  let incrementValue2 = increment
      .subscribe(with: self) { owner , value in
          print("next - \(value)")
      } onError: { owner , error in
          print("error - \(error)")
      } onCompleted: { owner in
          print("completed")
      } onDisposed: { owner in
          print("disposed")
      }
  
  let incrementValue3 =  increment
      .subscribe(with: self) { owner , value in
          print("next - \(value)")
      } onError: { owner , error in
          print("error - \(error)")
      } onCompleted: { owner in
          print("completed")
      } onDisposed: { owner in
          print("disposed")
      }
  
  

// 필요한 시점에, 내가 직접 dispose 한다! DispatchQueue.main.asyncAfter(deadline: .now() + 3) { incrementValue.dispose() incrementValue2.dispose() incrementValue3.dispose() }

#### 2. disposeBag 교체
- 근데 위 코드처럼 저러고 있으면, Stream의 양이 많아질수록 부담스럽다. 점점 편리한 `disposeBag` 이 생각나게 된다. 
- `disposeBag` 이 해줬던 것처럼, 물고 있는 모든 Stream에 대해 한 번에 `dispose`를 실행시킬 수는 없을까?


- 편리한 `disposeBag`의 기능을 사용하기 위해, 실행되어야 하는 것은 **disposeBag 인스턴스의 deinit 메서드**이다.
- 5번에서는 VC가 `deinit`될 때, 당연히 `disposeBag`도 `deinit`된다고 소개했다.
- 하지만, 이 경우가 아니더라도 충분히 `disposeBag`의 `deinit`을 실행시킬 수 있다

<br>

- **인스턴스를 교체한다**
  ```swift
  let increment = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)

  increment
      .subscribe(with: self) { owner , value in
          print("next - \(value)")
      } onError: { owner , error in
          print("error - \(error)")
      } onCompleted: { owner in
          print("completed")
      } onDisposed: { owner in
          print("disposed")
      }
      .disposed(by: disposeBag)

  increment
      .subscribe(with: self) { owner , value in
          print("next - \(value)")
      } onError: { owner , error in
          print("error - \(error)")
      } onCompleted: { owner in
          print("completed")
      } onDisposed: { owner in
          print("disposed")
      }
      .disposed(by: disposeBag)

  increment
      .subscribe(with: self) { owner , value in
          print("next - \(value)")
      } onError: { owner , error in
          print("error - \(error)")
      } onCompleted: { owner in
          print("completed")
      } onDisposed: { owner in
          print("disposed")
      }
      .disposed(by: disposeBag)


  // 필요한 시점에, 내가 직접 dispose 한다!
  DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
      self.disposeBag = DisposeBag()
  }

Summary

• dispose : 메모리에서 해제. 리소스 정리

• 실행 시점
  1. onError, onCompleted 실행
  2. Disposable 프로토콜의 dispose 메서드 직접 실행
     1. 직접 인스턴스에 접근해서 실행
     2. DisposeBag 클래스 이용
        • 일반적으로 VC 또는 VM이 deinit되면 disposeBag 인스턴스도 deinit되고 물고 있던 Stream들 dispose
        • rootVC라서 deinit 될 일이 없다면 원하는 시점에 disposeBag 인스턴스 교체

        • 기존 disposeBag의 deinit 실행

추가 : TableViewCell의 재사용

• 테이블 뷰 셀 위에 버튼이 있고, 해당 버튼을 누르면 화면 전환이 일어나는 코드를 작성한다
• 셀 위의 버튼.rx.tap 과 화면 전환 코드(navigation push)를 subscribe로 연결한다. (VC의 cellForRowAt 부분에서 작성한다)

/* SearchTableViewCell 의 인스턴스 */
let appNameLabel: UILabel
let appIconImageView: UIImageView
let downloadButton: UIButton    // 화면 전환을 연결할 버튼
var disposeBag: DisposeBag

/* SearchTableViewController */
var data = ["a", "b", "ab", "abcde", "de", "db", "abcd"]  // 데이터 변경 시 편의를 위해 따로 배열을 관리한다
lazy var items = BehaviorSubject(value: data)    
let disposeBag = DisposeBag()

func bind() {
    // cellForRowAt
    items.bind(to: tableView.rx.items(
                    cellIdentifier: SearchTableViewCell.identifier,
                    cellType: SearchTableViewCell.self
    )) { (row, element, cell) in
        cell.appNameLabel.text = element
        cell.appIconImageView.backgroundColor = .green

        // 버튼과 화면 전환 구독
        cell.downloadButton.rx.tap
            .subscribe(with: self) { owner , value in
                owner.navigationController?.pushViewController(SampleViewController(), animated: true)
            }
            .disposed(by: cell.disposeBag)    // cell 인스턴스의 disposeBag을 사용한다
    }
    .disposed(by: disposeBag)
}

• 요기서 문제는, tableView의 cell은 재사용된다 즉, 재사용되는 동일한 cell에 중복해서 subscribe를 해주고 있는 꼴이 된다
• subscribe로 연결한 액션은 화면 전환이기 때문에, 버튼을 한 번 누르면 연속해서 화면 전환이 일어난다

• 셀의 재사용 때문에 발생한 문제는 대부분 prepareForReuse 에서 해결할 수 있는 것 같다
• 위 코드도 마찬가지로 prepareForReuse에 코드를 작성해주면 되는데, 문제 원인이 중복된 subscribe이기 때문에, 매번 셀을 만들 때, subscribe를 끊어주면 된다

• disposeBag을 교체해준다

  override func prepareForReuse() {
      super.prepareForReuse()
  
      disposeBag = DisposeBag()
  }

• 앱스토어에 심사를 올리기 전, 테스터들을 모집해서 앱 성능에 대한 테스트를 받는다

• 내부 테스트
  • 100명 제한이 있다
  • 애플에게 심사를 따로 받지 않는다
  • 사용자 및 액세스 추가 과정이 필요하다

• 외부 테스트
  • 10,000명 제한이 있다
  • 애플에게 심사를 받아야 테스트가 가능하다
  • 사용자 및 액세스 추가 과정이 필요하지 않다

• 나는 내부 테스트로, 같이 공부하는 팀원들에게 앱 테스트를 부탁했다

1. 앱 등록

• App Store Connects Apps에 들어가서 신규 앱을 등록한다
  • 번들 ID는 Certificates, Identifiers & Profiles에서 등록할 수 있다

2. 신규 사용자 등록

• 사용자 및 액세스에 들어가서 신규 사용자를 등록한다
  • 내부 테스터에게 적절한 역할을 줄 수 있다. (사용자 지원이 권한이 가장 적다)
  • 추가 리소스는 따로 선택하지 않고, 앱은 내가 테스트를 부탁할 앱을 선택한다

• 초대 버튼을 누르면 해당 이메일의 사용자에게 초대 메일이 발송된다.
• 수신자가 수락을 누르면 사용자 및 액세스 화면에서 테스터들을 확인할 수 있다

3. 내부 테스팅 그룹 생성

• 테스트해주는 인원이 많으면 그룹을 만들어서 따로 관리하는 것도 좋다
• + 버튼을 누르면 기존에 사용자 및 액세스 에서 초대한 리스트가 뜬다

앱 빌드 추가

• 이걸 제일 먼저 했어야 했는데, 까먹었다

앱 Archive

• Xcode로 열심히 만든 앱을 애플 서버에 올리기 위한 작업이다

• 버전 정보와 빌드를 확인한다
  • 1.0 (1) 로 올라갈 예정

• 빌드 기기를 Any iOS Device (arm64)로 하고, Product - Archive 클릭한다

• 시간이 좀 지나면 이런 창이 뜨는데,
• Validate App* 누르고, Distribute App 누르면 된다
  • 빌드하는게 목적이기 때문에, 세부적인 내용은 생략한다.. 웬만하면 next 눌렀더니 성공했다

• Distribute App까지 마치면 아래 화면을 확인할 수 있다

TestFlight - 2

4. 내부 테스트 시작

• 다시 TestFlight 화면으로 돌아오면 버전이 올라와있는 걸 확인할 수 있다 (아마 아카이빙하고 시간이 꽤 있어야 올라오는 것으로 알고 있다)

• 따로 암호화하는 건 없기 때문에 아니요 체크하고 내부 테스트 시작한다

• 테스트를 시작하면, 메일로 테스트플라이트 초대 메일이 발송된다

5. 테스트플라이트 앱 다운로드

• View in TestFlight 클릭 후 순서대로 다운로드하면 실제 내 기기에서 앱을 테스트할 수 있다!

앱스토어 심사 제출

• 앱 제작의 최종 목적은 결국 내 앱을 앱스토어에 출시하는 것이다
• 출시하기 위해서는 애플의 심사를 받아야 하고, 승인을 받아야 앱스토어에서 앱을 다운로드할 수 있다
• TestFlight에 앱을 올리는 과정을 마쳤다면, 사실 심사를 제출하는 과정은 크게 어렵지 않다. 심사를 위한 추가 정보만 준비가 되었다면, 금방 할 수 있다

1. iOS 미리보기 및 스크린샷

스크린샷

• 앱 목업 스크린샷을 제출해야 한다.
• 목업 스크린샷 사이트 를 이용했다
• 아이폰 용 앱이라면 6.5 디스플레이와 5.5 디스플레이에 대한 스크린샷을 필수로 제출해야 하고, 6.7 디스플레이는 선택이다
  • 처음에 이거 몰라서 세개 다 만들었다... (빌드 추가를 하기 전에는 필수 글자가 뜨지 않았다...)

프로모션 텍스트

• 앱 설명 위에 3줄 정도 미리 표시되는 글이다. 나는 앱 설명으로 충분하다고 생각해서, 따로 적지 않았다

설명

• 앱에 대한 설명을 적어준다
• 앱 소개, 주요 기능, 서비스 접근 권한 안내, 문의 등 정보를 적어주었다

(버전 업그레이드 사항)

• 출시 이후, 업데이트 할 때 아마 뜨는 것 같다
• 업데이트한 내용을 적어준다

키워드, 지원 URL, 마케팅 URL, 버전, 저작권

• 키워드 : 앱스토어 검색 시 내 앱이 뜨게 하고싶은 키워드를 적어준다. (독특한 키워드를 적어주면, 해당 키워드로 검색 시 내 앱만 뜨게 할 수 있다)
• 지원 URL : 개발자에게 연락할 수 있는 사이트 링크를 추가한다
  • 나는 여기서 큰 문제가 되지 않았는데, 해당 링크로 들어갔을 때 이메일이나 전화번호 등 직접적으로 연락할 수 있는 수단이 없으면 리젝당한 경우도 있었다
• 버전 : 출시하고 싶은 버전
• 저작권 : 이건 정확하게 모르겠는데, 개인 개발자라면 대부분 연도 + 이름 을 적는 것 같다

빌드 추가

• 테스트플라이트 올릴 때와 동일하게 빌드 올려주면 된다

2. 앱 심사 정보

• 로그인 정보 : 로그인이 필요한 앱이라면, 리뷰어가 테스트하기 위한 샘플 계정을 추가해준다.
• 연락처 정보 : 개발자 연락처를 적어준다
• 메모 + 첨부 파일 : 리뷰어가 꼭 알아야 하는 내용을 메모에 적어준다. 예를 들어, 한국에서만 사용 가능한 api를 활용한 앱이라면 메모에 해당 내용을 명시해주고, 첨부 파일에 그 기능을 녹화 또는 캡처해서 올려준다.

3. 심사 제출

• 이 외에도 앱 정보, 가격, 개인정보 등 저장해야 하는 정보가 많은데, 그건 따로 설명할 내용이 없어서 생략한다
• 마지막으로 주의해야 하는 부분은, 심사에 추가 버튼만 누르고 끝내면 안된다
• 심사에 추가 버튼을 눌렀다면, 그 다음 앱 심사에 제출 이었나..? 버튼이 하나 더 있다. 이 버튼을 눌러야 제대로 심사가 올라간다!

4. 기다림

• 심사를 제출했으면, 이제 결과를 기다리면 된다.
• 보통 짧으면 몇 시간, 길면 며칠이 걸린다고 하는데 내 주변 사람들은 대부분 하루 정도 걸린 것 같다
• 나는 제출하고 2시간 만에 승인 결과를 받았다
• 짧은 시간이었지만, 그래도 기다리는 동안 그 떨림은 정말 쉽지 않았다..ㅎ
• 출시 앱 링크

나중에 참고하기 위해 출시 경험을 간단하게 기록해보았습니다. 혹시 잘못된 부분이 있다면 알려주시면 감사하겠습니다