_2nd.png&blockId=9df03bbd-ef30-4207-938b-bc84094584bc)
질문
1. 실시간 채팅 기능이 있는 쇼핑몰 앱을 프로젝트로 진행 중인데 MVVM 패턴으로 진행을 해야할 때 Firebase Realtime Database와 Cloud Firestore를 혼용해서 사용해야 할 지(위 링크를 보면 Realtime Database는 실시간 채팅에 적합, Cloud Firestore는 쇼핑몰 앱에 적합) , 둘 중 하나만 사용해야 될 지 잘 모르겠습니다. 혹시나 추천할 만한 DB가 있다면 알려주시면 감사하겠습니다.
2. PR을 squash로 진행 중인데 PR 후에 개인 브랜치에 이전 커밋이 계속 남아있는데 커밋이 계속 남아있는 이유 와 rebase와의 차이점이 궁금합니다.
화면캡쳐(예시)
위 질문에 해당하는 질문의 링크나 스크린샷을 여기에 추가해 멘토분들이 참고할 수 있도록 하세요.
프로젝트 주소
위 질문에 해당하는 질문의 링크나 스크린샷을 여기에 추가해 멘토분들이 참고할 수 있도록 하세요.
멘토 답변
실시간 채팅 기능이 있는 쇼핑몰 앱을 프로젝트로 진행 중인데 MVVM 패턴으로 진행을 해야할 때 Firebase Realtime Database와 Cloud Firestore를 혼용해서 사용해야 할 지(위 링크를 보면 Realtime Database는 실시간 채팅에 적합, Cloud Firestore는 쇼핑몰 앱에 적합) , 둘 중 하나만 사용해야 될 지 잘 모르겠습니다. 혹시나 추천할 만한 DB가 있다면 알려주시면 감사하겠습니다. cc. 참고
•
Firebase Realtime, Cloud Firestore 모두 실시간 채팅에 적합하다는 것을 알려드리며, 두 데이터베이스의 차이점을 알아보았습니다.
◦
확장성
◦
복잡한 쿼리
•
결론적으로 데이터가 대용량이 아니라면 두 데이터베이스의 큰 차이점은 없으며, 개인의 선호에 따라 선택하면 됨을 설명드렸습니다.
PR을 squash로 진행 중인데 PR 후에 개인 브랜치에 이전 커밋이 계속 남아있는데 커밋이 계속 남아있는 이유 와 rebase와의 차이점이 궁금합니다.
GitHub PR merge는 base 브랜치에 머지되면서 적용됨을 알려드리며 따라서 개인 브랜치에 영향은 가지 않음을 설명드렸습니다.
또 rebase 했을 때 차이점을 설명드리기 위해 실제 깃허브 실습을 빠르게 보여드렸습니다.
https://github.com/jaeryo2357/Github_Sample/pull/11
+ 추가 질문
브랜치를 삭제하지 않고 작업하는 경우, 개인 브랜치에 작업 이력이 계속 남아 스쿼시 머지를 할 경우 계속 중복 커밋이 쌓인다는 현상
- 개인 브랜치를 머지 시 지우지 않고 유지해서 작업을 이어가는 경우, base 브랜치와 동화 작업을 꼭 해줘야 함을 설명드렸습니다. —force pull
- 좀 더 쉽게 관리할 수 있는 방법으로 브랜치를 머지 시 제거하고, base 브랜치에서 브랜치를 새로 생성해 작업을 이어나가는 방법을 설명드렸습니다.
추가질문
Coroutine 공부할 수 있는 교재, 방법 추천
안드로이드 공식 사이트의 Kotlin Coroutine 문서
- ViewModel, Room 등 Jetpack 관련된 내용이 포함되어 있어 고려하면 좋다.
fragment onCreateView, onViewCreate 차이
onCreateView
1.
뷰를 만드는 라이프사이클
최대한 빨리 뷰를 반환하는 것을 구글에서 권장함을 알려드리며, 기본적인 뷰 초기화 정도는 가능하다고 설명드렸습니다.
onViewCreated
1.
뷰를 제어하는 라이프사이클
생성된 뷰를 제어하기 위한 최적화된 라이프 사이클임을 설명드리며 저또한 이 라이프사이클에서 뷰 초기화, 뷰제어를 한다고 설명드렸습니다.
예제 코드로 BaseFragment를 예시로 들며, onCreateView는 DataBinding 객체를 반환만 하고 onViewCreated 에서 binding 객체를 제어함을 보여드렸습니다.
fragment에서 Binding 객체를 nullable로 하는 이유
null을 해주지 않고 binding 객체를 계속 들고 있어도 큰 문제는 없지만 Fragment 상태 동기화를 완벽하게 해주기 위함임을 설명드렸습니다.
fragmentA 에서 fragmentB로 전환될 때, fragmentA의 뷰는 소멸되고 Fragment 객체는 BackStack에 있는 상황입니다.
이때 뷰는 Fragment에 분리된(소멸) 상태이기 때문에 백그라운드 뷰 업데이트는 비효율적. 그래서 nullable binding 변수로 관리하면 불필요한 뷰 업데이트를 방지해서 좀 더 효율적으로 관리할 수 있다.
Kotlin
복사
