일시: 2024-11-04

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

💡 진행할 사항

1. 멘토링 일정 정하기 (수요일2명 금요일 3명)
2. 월요일 오기 전 : 자료 조사 쌓기

• 카메라, GPS, 권한, Room, Firebase(기초, 로그인 전) 등등 기술 조사 각 기술 별 페이지 파기
  • 제일 먼저 조사하기 시작한 사람
  • 토글로 자신이 조사하는 것 적어두기
• 클린 아키텍처, 구글 권장 아키텍처, MVVM, MVI, MVP(Most Valuable Player), MVC 등 공부하고 정리해보기

1. 문서 정리 및 발표 준비
2. 카메라, GPS, 권한 등등 기술 조사 해온 것 토론 및 기술 스택 선정
3. Gradle, SDK 등 버전 정하기
   • 코알라 vs 무당벌레 ⇒ 코알라
     • 다운 링크 : https://developer.android.com/studio?hl=ko
     • 정호 : Android Studio Koala | 2024.1.1 Patch 1
4. 기술 확정, 프로젝트 생성
5. ui composable 생성 및 앱 시작하기, 도감 구현 진행
6. 주간 백로그 작성하기

💡기술 스택 정하기

1️⃣ 카메라

시스템 카메라

• CameraX를 잠깐 써봤을 때 화질이 좋지 않았었다.
• AI를 사용하더라도 매 프레임마다 돌리는 것이 아닌 최종 결과물만으로 처리하면 되는 것 아닌가?
• CameraX를 실행해보았으나 compile SDK 버전을 34 이상으로 실행하거나 라이브러리 버전을 낮춰야 한다. https://developer.android.com/jetpack/androidx/releases/camera
• 그냥 내장 카메라 쓰는 것이 오히려 더 깔끔하고 간단하게 구현할 수 있을 것 같다는 생각.
  • 물론 그렇게되면 GPS상태를 두 번 확인해야하는 번거로움…
  • 내장 카메라 쓰면 취소, 확인 같은 처리도 간단하게 되는 것 같다..? ← 좀 더 확인해야함

CameraX

• 후에 도입할 AI나 혹은 GPS 상태에 따른 처리를 간단하게 처리할 수 있기 때문에 CameraX가 나을 것 같다는 생각.
• Intent를 통한 카메라 전환 관련 공식문서를 찾아보려고 했는데 생각보다 자료가 없었다.
  • 심지어 공식문서에는 deprecated된 코드가 아직도,,,
• GPS 상태를 카메라에 UI로 표시하여 안내할 수 있다. 또한, 우리 앱만의 디자인을 카메라에 적용할 수 있을 것 같다.

Google Play 출시 관련

• Google Play에 출시를 하기 위해서는 targetSdk가 Android 14 (API 수준 34) 이상을 타겟팅해야 한다.

  https://developer.android.com/google/play/requirements/target-sdk?hl=ko

  https://support.google.com/googleplay/android-developer/answer/11926878?hl=ko

  https://cool-developer.tistory.com/44

문제 상황

• 2대 2의 상황
• Google Play 출시까지 고려한다면 targetSdk는 34 이상이 충족되어야 함으로 CameraX 적용이 가능해진다. 그러나 34 미만의 기기는 CameraX가 제대로 적용되지 않는 문제가 있어 SDK 대응이 필요했다.

결론

• Intent 먼저 기능 개발 후 targetSdk 34이상은 CameraX 적용해보기

2️⃣ 아키텍처

• 구글 권장 아키텍처 vs 클린 아키텍처

https://velog.io/@donghune/Clean-%EA%B3%BC-Google-Recommended-Architecture-%EC%9D%B4%EC%95%BC%EA%B8%B0

https://f-lab.kr/insight/clean-architecture-vs-google-recommended-architecture-20240905

https://holy0823.tistory.com/4

• 안드로이드 권장 아키텍처

  • 도메인 레이어 선택

  • 단방향 flow

    

    https://brunch.co.kr/@oemilk/218

• 클린 아키텍처
  • 도메인 레이어 필수
  • 도메인 레이어를 서로 바라봄 = UI 레이어와 Data 레이어가 Domain 레이어에 의존

의견

• 우리 앱의 복잡성은 높은 편이 아니다. 비즈니스 로직이 많지 않기 때문에 도메인 레이어가 굳이 필요 없어 보인다. 따라서 구글 권장 아키텍처로 가는게 좋다고 생각한다.
• 우리 앱에서 사용할 레포지토리의 종류가 여러 개인 것이 아니며, 이를 활용해서 비즈니스 로직을 다양하게 구성하는 것 또한 아니다. 그러므로 현재 프로젝트에서는 클린아키텍처까지는 필요하지 않아 보인다.
• 클린 아키텍처에 대해 제대로 파악하지 못했다.
• 구글 아키텍처도 잘 모르는데 클린 아키텍처는 더욱 더 모른다… ← 지금까지 도메인 레이어의 필요성을 단 1도 느끼지 못했다. ← 그냥 google android에서 권장한다는 아키텍처를 쓰는것이 나아보인다. (개인적인 의견) 👍

결론

• 구글 권장 아키텍처

3️⃣ 사진 저장 방식

• Room DB(= 앱 DB)에 사진만 Bitmap 말고 URI로 저장하고 사진 자체는 앱 폴더에 저장하자.
  • 진환님 아이디어 좋아요.
  • Bitmap을 Room DB에 저장해보고 무슨 차이점 있는지 확인 후 앱 폴더에 저장하여 URI로 관리하기.
• Bitmap으로 RoomDB에 저장하는 경우
  • 날짜, 위치 등 따로 RoomDB에 저장 필요
• 일단 Bitmap으로 저장해보고 이후에 판단하기

4️⃣ Firebase

• 익명 회원 관련
  • 익명 회원으로 SNS 인증 하지 않고 Friebase 사용 가능하다.
  • 실제 계정으로 전환 가능
  • 추가 조사 필요
  • 만약 쓴다고 하면 비회원도 Room을 덜 쓰고 서버에 저장할 수 있지 않을까? ⇒ 추후 생각

5️⃣ 로그인 관련

• 로그인을 줄이는 것이 어떤가 라는 피드백과 id-pw로 간단히 구현하는 것이 어떤가 라는 피드백을 받았다. 이에 대해서 어떻게 생각하는가?
  • id-pw 자체적으로 만든다면 UI 구성 및 FLOW 구성이 추가적으로 필요하게 된다.
  • SNS로그인이 많기는 하다.

결론

• 구글 SNS 로그인만 남겨두고 나머지 제거

💡프로젝트 생성 필요

1️⃣ 라벨, 마일스톤

• 에픽과 동일한 이름으로 마일스톤 생성. 추후 에픽 속성 삭제
• 라벨(기본으로 있는 것 그대로 + 스토리 추가하여 사용)

  • 기본 라벨

    

  • 스토리

  • refactor

  • document

2️⃣ 버전

• app ⇒ gradle

kotlinOptions {
	  jvmTarget = "1.8"
}

• lib.versions.toml

[versions]
kotlin = "2.0.0"

💡주간 백로그 작성

1차 릴리즈 목표 (0.0.1) - 최소 단위 기능

• 비회원 동작
• 앱 내부 DB(Room)에 저장
• 사용자가 라벨, 사진, 설명 추가 및 수정
• 도감 구성 (+ 크롭)

💡업무 관심

겹치면 페어프로그래밍 하면 됨

• 도윤 → 라벨

• 정호 → 그리드 + 권한

• 진환 → 카메라 찍고 사진 저장

• 형준 → Room DB

• 유진 → 사진 크롭해서 보여주기 + 카메라

• 프로젝트 생성 및 테마 저장 commit ⇒ 정호 (테마 장인)