Skip to content

Conversation

@codebidoof
Copy link

@codebidoof codebidoof commented Nov 16, 2025

📌 몇 주차 워크북인가요?

  • Week08

✨ 이번 주에 작업한 내용

  • 회원 가입 페이지(SignUpAcitvity) UI 제작
  • 로그인 페이지(LoginActivity) UI 제작
  • 회원가입 및 로그인 로직 구현
  • 좋아요 앨범 기능 구현
  • 둘러보기 화면 UI 제작

🙋 리뷰 요청/확인 받고 싶은 부분

  • 리팩토링을 하는 과정에서 AlbumTable에서 강사가 @PrimaryKey(autoGenerate = false) var id: Int = 0 로 지정하고 메인액티비티에서 더미 앨범 데이터를 삽입할 때 id를 0부터 시작하여 삽입하길래 그대로 하였는데, 그러다보니 디버깅 과정에서 앨범프래그먼트로 전환할 때 앨범에 대한 수록곡 목록이 하나씩 밀려서 나오는 현상이 생겼습니다. 이를 고치기 위하여 AlbumVPAdapter에서
    val bundle = Bundle().apply {putInt("albumId", albumId+1) }과 같은 식으로 각 뷰페이저에 해당하는 프래그먼트에 앨범id에 1을 더해 전달하는 식으로 구현하였는데, 이게 맞는 방식인지(개선 여지가 있다면 피드백 부탁드립니다!), 그리고 autoGenerate를 true로 하지 않고 false로 하는 의도가 정확히 무엇인지 궁금합니다!
  • 다음 주에 너디너리 해커톤에 참여하게 되는데, 미션을 수행할 때 시간관계상 firebase를 공부하여 사용하는 것은 하지 못했습니다. 해커톤에 나가게 된다면 백엔드 개발자분들과 협업을 하게 될 텐데, 그 전에 firebase나 Retrofit과 같은 것을 공부해야 하는지, 한다면 어디까지 해야 하는지 궁금합니다!!

✅ 체크리스트

  • weekN/ 폴더 안에 과제 정리 완료
  • PR 생성 시 base = 조직 내 본인 브랜치, compare = 내 Fork main 브랜치로 설정했는지 확인
  • PR 제목에 [WeekN] 닉네임/이름 미션 제출 규칙 맞게 작성

@eldeoddt
Copy link

eldeoddt commented Nov 21, 2025

8주차 피드백 완료 ✅
수고하셨습니다 🙂 👍

🙋 리뷰 요청 / 확인 받고 싶은 부분

  • AlbumTable-autoGenerate=false:
    강의 의도상 ID를 직접 관리하기 위해서 임의로 지정한것으로 보임
    실무에서는autoGenerate=true 사용이 일반적임
    현재는 학습용이라 그대로 가도 괜찮을 것 같아요

  • 해커톤 준비 관련:
    retrofit은 알아두는게 좋음.
    firebase는 선택,
    서버 연동 기본 흐름(요청–응답–에러 핸들링)은 익숙해져야 협업 시 빠르게 맞출 수 있음
    해커톤에서는 viewmodel 사용을 권장함


<SignUpActivity>

👍 회원가입 예외 처리와 DB 저장 구조 잘 구현됨
💙 Coroutine으로 insert 처리 시 UI 프리즈 방지 가능 (room db 사용 시만)
💙 이메일 중복 검증용 getUserByEmail() 쿼리 추가 시 명확함

<LoginActivity>

👍 SharedPreferences 활용 로그인 상태 저장 구조 명확
💙 로그인 성공 후 finish()로 뒤로가기 방지
💙 Intent.FLAG_ACTIVITY_CLEAR_TASK 설정으로 로그인 화면 스택 제거 권장
💙 Toast 메시지가 중복으로 뜨는 부분은 return 추가로 정리 가능

<AlbumFragment>

👍 좋아요 기능(isLikedAlbum, likeAlbum, disLikedAlbum) 구조 구현
💙 협업 시에 DB 직접 접근 대신 Repository–ViewModel 구조로 분리하면 유지보수성과 테스트 용이성 향상
💙 좋아요 상태 변경 후 LiveData 옵저버 활용 시 UI 자동 갱신 가능
💙 commitAllowingStateLoss() 대신 commit() 권장 (ui 안정성 향상)

<Like>

👍 기본 구조 구현
💙 userId + albumId 복합 PK 지정 시 중복 좋아요 방지 가능

<User> / <UserDao>

👍 Room 구조 명확
💙 onConflict = REPLACE 옵션 추가 시 동일 이메일 중복 저장 방지
💙 이메일 기준 조회 쿼리(getUserByEmail) 추가로 중복 체크 로직 개선 가능

@codebidoof
Copy link
Author

전에 확인했었는데 코멘트를 이제야 다네용 ㅎㅎ 덕분에 해커톤 때 큰 도움이 되었던 것 같아요! 카피바라님 고생 많으셨습니다!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants