(TIL) 2020-11-13 기록

오늘 한 일

• 오늘은 컨디션이 좀 안 좋아서 작업을 많이 하지 못했다 ㅜㅜ
• 국제화 작업은 메세지가 다 나오고 나서 해야 효율이 나올 것 같아서 잠시 중단하고 하드코딩을 계속 하기로 했다.
• 대신 1:1 대화방 앱바, 페이지, 그리고 리스트뷰와 항목 위젯, 그리고 항목 모델, 대화방 목록 상태 관리 provider, 그리고 대화방 목록 Stream에 listen해서 받아와서 계속 대화방 목록을 갱신하는 로직을 만들었다.
• 그 외에 안 읽은 메세지와 새로운 메세지가 있을 때 알림을 주기 위해서 DB 구조를 조금 바꿨다.
• 메세지 읽음, 읽지 않음 여부는 각 메세지마다 {“참여자1”:”dummy”} 이런 map 형태로 저장해 참여자가 읽을 때마다 map에서 내가 있는지 체크하고 있으면 삭제하는 식으로 만들었다. 이러면 각 메세지 별로 읽음, 안 읽음 표시를 할 수 있고 몇 명이 읽었는지도 표시할 수 있다.
• 다만 이렇게 하면 내가 새 메세지를 받고 있는지를 체크하기가 좀 애매해진다. 그래서 userdata 컬렉션 아래에 하위 컬렉션을 하나 더 만들어서 각 대화방 별로 새로운 메세지 개수만 세어서 알려주고 그 대화방에 입장하거나 여튼 어떠한 방식으로든 확인하게 되면 0으로 만들어주면 될 것 같다. 그리고 각 대화방 문서와 같은 수준에서 total_count 키값을 하나 만들어서 Cloud Function에서 하위 각 대화방 문서들이 업데이트 될 때마다 total_count를 계산해주도록 하면 될 것 같다.
• 고민을 하긴 했지만 이게 최선인가?에 대해서는 나는 확신할 수가 없다. 개선이 필요해 보이기도 한다. 너무나 많은 저장 공간을 쓰는 것 같다.
• 그리고 지금 대화방 목록을 갱신하는 함수는 snapshot이 직전의 snapshot과 다를 때마다 새로운 목록을 생성해서(이 과정에서 비동기 함수가 두 개 정도 더 들어간다.) 대화방을 갱신하는데 아무리 생각해도 이건 너무 비효율적인 것 같아 최적화가 필요하다.
• 그런데 어차피 바뀐 대화방만 감지해서 바꾼다고 한다면 어차피 이게 배열이라 결국 순차 탐색을 해서 바뀐 부분을 찾아야 할 텐데… 시간복잡도로 보면 크게 다르지 않을 수도 있을 것 같다… 일단 좀 더 고민해봐야겠다.
• 아니면 각 대화방을 따로 listen해서 업데이트 하는 것도 괜찮을 것 같다. 대화방 상위 컬렉션은 listen해서 대화방 개수가 달라지면 그때만 목록을 새로 만들고 그런 게 아니라면 각 대화방을 따로 업데이트 하면 괜찮을 것 같기도 하다.

  모레 할 일

• 일단 오늘 만든 로직을 좀 최적화해야겠다.
• 1:1 대화방은 크게 복잡할 거 없는 화면이라 각 로직들 테스트해보고 이상 없으면 메인화면 내비바 클릭/좌우드래그 제스쳐에 따라 움직이는 애니메이션을 구현해야겠다.