7월 21일(목) 20:00 ~ 20:30 @은수 @조동진

질문 사항 🙋

• 안드로이드에 맞춰진 디자인도 리젝 사유에 들어갈 수 있겠죠,,,? (ex. 구글에서 제안하는 탭바 플로팅 효과, 오른쪽 상단에 수정,삭제,신고하기 탭 디자인) iOS는 HIG에 맞춰서 따로 디자인 해야 될까요?

  → 같은 맥락으로 디자인과 유사한 SFsymbol이 있다면 해당 사진을 쓰는 것보다 symbol로(systemName 으로 불러와서) 쓰는 게 아무래도 더 좋은가요?

  • 앱 개발 시 안드랑 ios랑 똑같아야 한다고 생각 → 사용자들은 따로 만들어지는 지 모름
  • 하나의 앱처럼!
  • SF symbol 사용하면 리젝당할 일은 절대 X
  • 하지만 디자이너가 준 asset을 사용하는 게 더 좋을 듯. 우리 눈에는 비슷하지만 조금 다를 수 있다.

• 회원가입 과정 중에 뷰를 모두 present 방식으로 화면 전환을 하고 있는데, 이런 점이 앱이 리젝 당하는 데에 영향을 끼칠 수 있는지 궁금합니다.
  • HIG에 안 따른다고 꼭 리젝 당하지는 않음
  • 세세한 정해진 규칙, 애플이 제공하는 로그인 버튼 규격이 다름
  • 그렇게 막 까다롭지는 않다, 리젝 한 사람이 다시 심사
  • 회원가입에서 모든 화면 present → 리젝 당할 확률 있음 (네비게이션 Bar → 뒤로가기)

• (시간 남으면) 설명하기 간단한 VC 보여드리고 이 VC를 MVVM으로 하려면 어떻게 하면 좋을지 궁금합니다
  • Pass

• 파일 구조 관련,,, 현재 API를 연동할 때마다 하나의 VM 파일을 만들어서 static 함수로 만들어서 사용하고 있는데 이게 일반적인 것인가요?
  • Pass
  • ViewModel을 통해 호출하는 게 맞는 듯 .. ?

• 저희가 현재 화면 전환과 동시에 데이터를 전달해야 할 때, 전환될 VC의 프로퍼티에 데이터를 직접적으로 주입하고 있습니다. 이렇게 하나의 VC에서 다른 VC 안의 데이터를 직접 변경하는 게 안 좋다고 들었는데 어떤 방식을 사용하는 게 좋을까요?

  

  • 전달하고 싶은 매개변수를 가진 생성자를 하나 더 만든다
  • 생성자에서 넘겨준다
  • 넘겨주려는 데이터를 private으로 선언!

  ---

  데이터 바인딩 (MVP)

  viewdidload에서 아웃풋에 따른 처리 함수 등록

  • 일단 MVVM에 어긋남
  • 뷰모델은 요청이 무슨 뷰컨트롤러에서 온지 몰라야 함
  • 어디서 온지 알면 결합도가 높아짐
  • 이렇게 호출하는 건 MVVM에 어긋나는 것
  • input: 뷰컨으로부터 받기
  • output: 뷰컨으로 전달 (결과)
  • 버튼 누르면 뷰모델로 인풋 전송 → API 호출 → 아웃풋으로 뷰컨에게 전달 → 결과에 따라 뷰컨을 동적으로 변경
  • RxSwift
  • MVP, MVVM 패턴

• 컴포넌트를 생성할 때, 아래 사진과 같이 클로저 안에 서브뷰로 들어갈 컴포넌트를 동시에 생성하는 방식이 좋은 건지 궁금합니다. (또는 따로 꺼내어서 나중에 addSubviews로 넣는 게 차라리 나은지)

  

  DeliveryVC.swift

  • 가독성 측면에서는 안에 넣어서 한번에 생성하는 게 더 좋음 → 외부에서 다시 접근할 필요 없을 때는
  • 다시 접근해야 하는 컴포넌트면 → 따로 빼서 선언

• 서버에 request 할 때 사용할 parameters를 일회성 전역 데이터로 저장해서 사용해도 되나요 ? (서브뷰 5개에서 각각 request 할 데이터를 저장해야 하기 때문에 화면 간 데이터 전환이 복잡 → 정적으로 사용중)
  • 장기적으로 지속적으로 발생하면 유지보수 힘듬
  • 하나의 방법이기 때문에 나쁘지만은 않다.
  • 뷰모델 자체를 싱글톤으로 만들기도 → 화면간 뷰모델 전달 필요 없음