일시: 2024-11-18

참석자: 정유진, 임형준, 노진환, 김도윤, 김정호

• 회의 진행 안건
  • 친구: 팔로우 형식인지 승인 형식인지
  • DB 구조 : RDB, NoSQL 스키마 관련
  • 동기화 정책

💡 친구: 팔로우 형식인지 승인 형식인지

1️⃣ 팔로우 형식

• 고려사항
  • 내 도감, 지도를 공개할 것인지 안 할 것인지
    • 전체 공개, 친구에게만 공개, 비공개
  • 사진별로 공개설정을 할지 전체를 일괄로 할지
    • 사진별로 한다면 저장화면에 추가로 넣어야 하나요
    • 유저가 촬영 이후 저장하기 너무 귀찮을 듯

2️⃣ 승인 형식 ✅

1. 검색에서 USER 검색(이메일)
2. 검색해서 나온 사람의 옆의 친구 추가 요청하기 버튼 클릭
3. 친구 요청이 전송됨
4. 추가 시 친구에게 알림
   • 알림 모아두는 곳 필요
5. 친구에게 알림 오는 형식
   • 팝업 메세지 or 메세지 함
6. 친구가 승인 or 거부 시 나에게 알림
   • 팝업 메세지로 알려줄 것인가?
     • 사진 찍을 때 나오지 않도록 조절 필요
   • 메세지 함에 승인했다고 알림 넣어둘 것인가?
7. 승인되었을 경우 각자의 친구 목록에 추가됨
8. [지도에서는 어떻게 볼 수 있도록 할 것인가?] ⇒ 논의 거리

3️⃣ 결론: 승인 형식으로 결정

• 유저가 앨범이나 지도의 공개설정을 하는건 귀찮아 할것 같다. 사진 촬영 이후 저장하기까지 지금도 많은 동작이 필요함
• 이왕 할 거 어렵게 가자!
• 우리 앱은 SNS 보다는 도감에 초점을 맞춰야 하므로, 기타 관련 앱을 보았을 때 친구 추가 승인 형식이 많았다.
• 사적인 사진(생물 들고 찍은 내 얼굴 혹은 나만 볼꺼야!)이 있을 수 있는데 그런 사진을 팔로우 방식으로 누구나 볼 수 있다면 사용자 입장에서 안좋게 보일 수도,,,

💡[친구 추가] 고려 사항들 정하기

• 알림 모아두는 곳 필요(메세지 함)

1️⃣ 팝업 메세지를 할 것인가?

• push 알람인지 앱 내의 팝업인지
• 승인, 거절을 여기에서도 가능하게 할 것인지
  • 여기에서 무조건 해야 하는지
  • 나중으로 미룰 수 있는지
  • 알림용도로만 사용하는지
• 앱내 팝업 알람보단 push 알람을 통해 친구 추가 요청이 왔다는 것을 알려준다.
  • push 알람을 클릭하면 우리가 만들었던 친구 추가 요청?(승인 거절) 페이지로 이동
  • 마이페이지에서도 아이콘을 통해 이동 가능
  • 마이페이지에서는 알람이 왔다는 것을 Android Developers Bedge 을 통해 알려주기

결론

• 시간을 고려하여 현재는 푸시 알림만 오게 하고 이후에 시간이 되면 팝업 관련 논의 진행하기
• push 알림 공부 필요
  • FCM
  • Notification
  • BroadCastReceiver & FCM

2️⃣ 메세지 함에 승인했다고 알림 넣어둘 것인가?

• 조용히 추가되는 것이 좋다 👍 👍
  • 조용히 거절되는 게 좋다
• 승인했을 경우 ⇒ 승인했어요~ 메세지
  • 거절했을 경우 ⇒ 거절했어요~ 메세지

결론

• 조용히 친구 추가되도록 함
  • 거절되었을 경우 다시 버튼이 친구 추가 버튼으로 바뀌어 있게

3️⃣ 지도에서는 어떻게 볼 수 있도록 할 것인가?

ⓐ 친구 목록을 통해서 친구의 도감 & 지도를 볼 수 있게 할 것인지 ⇒ 결론: 넣자

1. 넣자 👍 
2. 넣지 말자
3. 시간 되면 넣자(우선순위 분배 예정) 👍 👍 👍

ⓑ 지도 화면에서 친구 목록 접근해서 필터링 걸면 해당 친구들의 지도가 겹쳐서 표시되게 할 것인지 ⇒ 결론: 여러명 우선 시도

• 제안
  • 1명~5명까지만 겹쳐서 볼 수 있게 하기 👍
  • 겹치지 말고 그냥 1명 것만 보기 : 검색하여 친구 보기
    • UI 지저분해질 것 같아서 ( 추측 )
    • 하게 된다면 UI 를 잘 살려야 한다… 못살릴꺼면 그냥 한명만
  • 일단은 유저 본인/친구 한명씩만 보고 이후에 시간되면 여러명 동시에 띄우기
  • 여러 명 해보고 안되면 한 명으로 변경

결론

• ⓑ 지도 화면에서 친구 목록 접근해서 필터링 걸면 해당 친구들 지도 겹쳐서 표시 클러스터링 시도→ 판단 후 안되면 1명으로 변경하여 나, 친구 중 1개만 볼 수 있도록 함
  • 위의 사항이 구현된 후 ⓐ 친구 목록을 통해서 친구의 도감 & 지도를 볼 수 있게 하는 것 진행

💡DB 구조 : RDB, NoSQL 스키마 관련

https://github.com/boostcampwm-2024/and04-Nature-Album/pull/126

1️⃣ NULL 허용 Column이 무엇이 있는가?

• RoomDB는 NULL값 X 상태

결론

• 전부 not null 타입으로 변경

2️⃣RoomDB에도 FileName만 저장하기?

결론

• 뭐가 더 효율적인지 비교해봐야 할 듯
  • 사이즈, 속도

💡 동기화: 정책

질문

• 내가 동기화를 한다고 해도 친구가 동기화 되지 않은 상태라면 친구의 최신 데이터를 볼 수 없다는 점

  ⇒ 오프라인이 가지는 어쩔 수 없는 문제

결론

• Wifi 상태에서만 진행 👍
  • 대량 이미지가 있기 때문
• 특정 시간(자정) 및 동기화 버튼 클릭 시 동기화
  • 동기화 버튼 클릭 시 데이터 상태라면 사용자에게 한 번 더 안내
  • 최근 동기화 시간 알려주기
• 밤 12시에 백그라운드에서 wifi 연결되어 있을 때 동기화

동기화

• Room DB의 데이터를 서버로 보내기
• 만약 앱 데이터를 삭제했다면,,? → 서버에서 데이터 가져오기?

참고: 동기화 전략

• 정기적 동기화
  • 일정 간격(예: 10분 또는 30분)으로 주기적으로 서버와 동기화합니다. 이렇게 하면 서버와 로컬 데이터 간의 최신 상태를 유지할 수 있습니다. 단, 사용자 데이터 사용량을 증가시킬 수 있으므로 적절한 간격 설정이 중요합니다.
• 이벤트 기반 동기화 → 촬영시 사진 업로드
  • 사용자가 특정 동작(예: 새 데이터 생성, 업데이트, 삭제)을 할 때 서버와 즉시 동기화합니다. 실시간 성격이 중요한 경우 유용하며, 불필요한 데이터 사용을 최소화할 수 있습니다.
• 백그라운드 동기화
  • 앱이 실행 중이지 않을 때(예: Wi-Fi에 연결되었을 때) 백그라운드에서 동기화가 수행되도록 합니다. 데이터가 중요하거나 실시간 동기화가 필요하지 않은 경우 적합한 방법입니다.
• 온디맨드 동기화
  • 사용자가 명시적으로 요청(예: 새로고침 버튼 클릭)할 때만 동기화합니다. 동기화 트래픽을 줄일 수 있으나, 친구의 데이터가 최신이 아닐 수 있는 단점이 있습니다.
• 충돌 해결 전략
  • 동기화 시 충돌 가능성을 대비해 충돌 해결 방식을 정의하는 것이 좋습니다. 예를 들어, 클라이언트 우선, 서버 우선, 타임스탬프 기반 등의 방식을 사용할 수 있습니다.
• 혼합형 전략
  • 위의 방법들을 혼합하여 상황에 맞게 유연하게 동기화합니다. 예를 들어, 사용자가 업데이트한 데이터를 즉시 동기화하고, 앱을 여는 순간에 서버와 정기적으로 동기화하도록 설정할 수 있습니다.

💡 친구 NoSQL

현재 Firebase NoSQL 상태

친구 관련 데이터가 뭐가 필요한지

• Email
• Name

→ 언제든지 자유롭게 수정 가능

찾아보기

대략적 진행 예정

월 [학습 Day]

• 리컴포지션 정리
• UI
• 클러스터링
• 이미지 압축 문서화 위주로 구현
• 학습 & 문서화