[Fix] #344- 콕 찌르기 1차 QA 반영

[lsj8706]

🌴 PR 요약

• 콕 지르기 피쳐의 1차 QA 사항들을 수정했습니다.

🌱 작업한 브랜치

• feature/[Fix] Poke QA 반영 #344

🌱 PR Point

1. 온보딩, 메인 뷰에서 Pull To Refresh 가이드 문구가 모호하다는 피드백이 있어서 문구를 수정했습니다. "화면을 밑으로 당기면 다른 친구를 볼 수 있어요"에서 "화면을 당기면 다른 친구를 볼 수 있어요"로 변경
2. 찌르기 성공 시에도 토스트 생성
3. 토스트 유지 시간 4초 -> 2초로 변경
4. 토스트 중복 생성 방지
5. 온보딩 뷰에도 토스트가 발생하도록 로직 추가
6. 콕 찌르기의 다른 뷰에서 A 유저를 대상으로 찌르기를 성공했고 뒤로 가기 버튼을 눌러서 메인뷰로 돌아왔을 때 A 유저가 뷰에 있다면 찌르기 버튼을 비활성화 해달라는 요구사항이 추가되어 해당 로직 추가
7. 콕찌르기 알림 리스트 뷰로의 푸시알림 딥링크 라우팅 추가

📌 참고 사항

6번 사항을 구현하기 위해 NotificationCenter를 활용했습니다.
총 3개의 뷰 (내 친구뷰, 내 친구 리스트뷰, 찌르기 알림 뷰)에서 찌르기를 했을 때 이벤트를 메인 뷰에서 받아와야 했는데 이 구조는 NotificationCenter가 적합하다고 생각했습니다. 즉, 위의 세 뷰에서 찌르기를 성공하면 NotificationCenter에 찌르기 당한 유저의 모델을 post하고 PokeMainView 모델은 Notification Publisher를 구독하고 있다가 기존 PokeResponse Output 스트림에 합쳐서 뷰로 전달합니다.

기존 pokedResponse 스트림을 유지하면서 업스트림을 추가한 방식이라 반응형 프로그래밍의 장점을 살리고자 했습니다.

let notiName = NotiList.makeNotiName(list: .pokedResponse)
NotificationCenter.default.publisher(for: notiName)
    .compactMap { $0.object as? PokeUserModel }
    .subscribe(output.pokeResponse)
    .store(in: cancelBag)

딥링크 관련

현재 요구사항에서는 콕 찌르기 알림 리스트 뷰로의 딥링크만 존재합니다. 따라서 문제가 없지만 만약 콕 찌르기 메인 뷰로의 라우팅("home/poke")이 생긴다면 조금 애매해집니다.
왜냐하면 현재 기획에서는 친구가 없는 유저는 메인 뷰로 접근하지 못하고 온보딩에 묶어두어야 하기 때문입니다. -> 딥링크 만으로는 유저가 온보딩 대상인지 알지 못하는 문제가 있습니다.

이 문제는 온보딩에서 묶어두는 상황을 제거하여 기획적으로 풀면 제일 좋을 것 같고 그것이 힘들다면 기술적으로는 딥링크 쿼리로 온보딩 대상인지 받아와서 분기처리 하는 방법이 있습니다. 하지만 친구 관계라는 것이 상대방이 답장을 언제 하냐에 따라 푸시 알림 전송시에는 온보딩 대상이지만 유저가 딥링크로 이동할 당시에는 온보딩 대상이 아니게 될 수 있기 때문에 정확성이 떨어진다는 단점이 있습니다.

또는 라우팅을 시도할 때마다 서버 통신을 해서 온보딩 대상인지 받아오는 방법도 있지만 네트워크 모듈에 딥링크 관련 객체들이 접근해야 한다는 문제점이 있습니다.

🥕 추가 수정 사항 (01.01 기준)

앞서 딥링크 관련하여 콕 찌르기 메인 뷰로 라우팅해야 할 때 온보딩 대상 유져를 식별할 수 없는 문제가 있다고 했는데 @elesahich 승호형이 제안한 방식으로 문제를 해결했습니다.

그전에 딥링크 로직을 조금 수정했습니다.
DeepLinkTreeNode에 isDestination: Bool 속성을 추가하여 해당 딥링크 구현체가 최종 종착지 뷰인지를 저장하도록 했습니다.
만약 "home/poke/notification-list" 형태의 URL로 딥링크가 온다면 [HomeDeeplink(), PokeDeepLink(), PokeNotificationListDeepLink()] 형태로 구현체가 파싱됩니다. (이전 PR 참고)

이제 이 배열에서 마지막 객체인 PokeNotificationListDeepLink에만 isDestination를 true로 설정하여 나머지 객체들인 HomeDeepLink, PokeDeepLink는 종착지가 아니라 경로 뷰임을 알 수 있게 했습니다.

이로 인해 앞으로 딥링크 라우팅을 할 때 전체 flow를 전부 뷰에 쌓는 것이 아니라 종착지 뷰임을 확인하고 종착지 뷰만 쌓을 수 있게 되었습니다.

다시 본론으로 돌아와서 Poke 메인 뷰가 종착지인 딥링크가 도착하면 우선 Poke 메인 뷰를 띄우고 API를 호출하여 온보딩 대상인지 확인합니다. 맞다면 온보딩 뷰로 rootModule을 온보딩 뷰로 변경하여 dismiss 없이 온보딩 뷰로 전환합니다..!

📸 스크린샷

기능	스크린샷
�내친구 뷰의 찌르기 이벤트를 메인 뷰에서 받아서 버튼 비활성화

📮 관련 이슈

• Resolved: [Fix] Poke QA 반영 #344

[elesahich]

세진아!! 고생했어~~~ 코멘트 몇개 한번 봐주겠어?

[elesahich]

세진아 이게 토스트는 계속 최신 정보를 보여주는게 좋을 것 같거든! 요걸 해결하는 몇개의 방법이 있을것 같아

1. mdsToast가 있으면 dismiss해주고 show 로직을 다시 돌린다 (재귀적으로든 뭐든)
2. MDSToastType이 현재 Toast와 다른 경우에만 dismiss하고 show 로직을 다시 돌린다

등등이 있겠는데 Toast라는 컴포넌트 특성상 빠르고 responsibility 있게 정보전달을 해줘야 하다 보니 1번이 어떨까 싶어~
기대하는 동작은 기존 토스트가 2초밖에 보여지지 않았더라도 즉각 dismiss 되고 새로운 토스트를 보여주는 동작이야!

[elesahich]

(참고) 그래서 채널톡은 요렇게 되어있엉 (1번임)

[lsj8706]

이렇게 동작하도록 수정했어!!
상세한 예시 영상까지 첨부해줘서 고마워~~!🤩

[elesahich]

잘 이해한건지 알려주라~

1. 알림이 왔다는 건 친구가 있다는것과 동치가 아니므로 알림이 왔어도 PokeMain으로 보내는 케이스가 있다면 온보딩으로 가야한다는 것
2. 그런데 현재는 알림리스트로 단독으로 보낼수 있어서 문제가 없는것이고!

이런 경우라면 나는 이건 PokeMain으로 보내고, 여기에서 판단해서 다음 라우팅을 하는게 책임소지가 명확히 있는것 같아서 요게 어떨까 하는 생각이야~

(- 1. 딥링크로 여기까지 이동했다면 - 2. userId 기반으로 verification 하고 - 3. 필요에 따라 라우팅 하기(온보딩으로))

[lsj8706]

잘 이해한 거 맞아!!

그럼 PokeMain에서 뷰가 로드될 때 온보딩 유저인지 한 번 더 확인하고 온보딩 대상이면 자체적으로 온보딩 뷰로 전환을 시켜야 한다는 의미이지~? (PokeMain뷰에서 온보딩 대상 여부 확인 API 호출한다는 의미!)

[elesahich]

응 맞아~ 내 생각은 그러하고~ 그렇기 된다면 매 coordinator의 route 시에 하는건 좋지 않을것 같고 이니셜라이저에 boolean 같은 것으로 구분해서 e.g.) 'isRouteFromRoot': Bool - true일 때만 점검하도록 하면 어떨까 싶어!!

[lsj8706]

이런식으로 우선 PokeMain으로 보내고 서버 통신을 해서 온보딩 대상이라면 온보딩 뷰로 보내도록 구현했어!
영상에서는 아주 잠깐 PokeMain이 스치듯이 보여서 구분은 힘들겠다...ㅎㅎ
상세한 내용은 PR 내용에 적어뒀는데 괜찮은지 한 번 확인해줄 수 있을까~~? 🤗 @elesahich

[elesahich]

넘 고생했씀니다~~ 💖