7. [Surveasy] MainActivity 에서 하는 일
아래의 게시물에 이어지는 개발 과정 기록입니다.
6. [Surveasy] room db 이용하기
아래의 게시물에 이어지는 개발 과정 기록입니다. 5. [Surveasy] Register & Login 아래의 게시물에 이어지는 개발 과정 기록입니다. 4. [Surveasy] 어플의 시작화면, Splash 아래의 게시물에 이어지는 개발 과
self-motivated-developer.tistory.com
우리의 어플은 mainActivity 위에 homeFragment, listFragment, myViewFragment로 메인 화면이 구성되어 있다. 이번 게시물에서는 그 중 mainActivity 에서 어떤 기능이 이루어지는지에 대해서 기록하겠다.
💡 로그인한 유저의 정보를 불러와서 viewModel 에 저장한다.
💡 유저의 정보를 확인하고 조건에 맞는 설문을 최신순으로 불러와 저장한다.
💡 홈화면에 들어가는 컨텐츠 (ex. 간단한 투표 질문, 베너 이미지 등) 을 한번에 불러와 저장한다.
일반적으로 mainActivity 에 모든 코드를 넣어서 작성하는 방식은 권장되지 않는다. 현재 이와 같이 작성된 코드를 리팩토링 중에 있다.
firebase firestore 에서 필요한 정보 불러오기
mainActivity 에서는 주로 필요한 정보를 불러온다. 설문조사에 참여한다는 어플의 본래 목적의 특성상 실시간으로 설문 정보가 반영되고 참여 여부가 반영되는 것이 바람직하다. 하지만 당시 우리는 실시간으로 정보를 반영하는 방법에 대한 고민이 부족했고, 인터넷 뉴스나 커뮤니티 어플처럼 설문이 끊임없이 올라오는 것이 아니었기 때문에 어플을 새로 시작했을 때 설문을 불러오는 방법을 선택했다.
이러한 방식의 가장 큰 문제점은 설문에 참여한 유저가 다시 메인 화면으로 돌아왔을 때 참여했다는 정보가 반영되지 않아서 중복으로 설문 참여가 가능하다는 점이었다. 비효율적인 방법이었지만, 이를 해결하기 위해 설문 참여의 마지막 화면에서 mainActivity 를 destroy 하고 다시 main 화면을 start 하는 방법을 사용했다. 또 하나의 문제는 어플을 실행했을 당시에는 마감되지 않은 설문이 유저가 어플 내에 있는 동안 마감되는 경우 실시간 반영이 불가능하다는 점이었다. 이를 해결하기 위해 우리는 설문 화면에 들어갔을 때 마감 여부를 다시 한번 체크하게 했다.
처음에는 정식 서버가 아닌 firebase 를 사용하는 이상 실시간 fetch 가 불가능하다는 생각을 했었는데, 결국 데이터를 fetch 하는 어플 패턴 숙지의 부족함이었고, 다른 방법을 통해서 계속 개선해 나가는 중이다.
fetch한 데이터를 viewModel 에 저장
activity 와 fragment 간의 데이터 공유를 효율적으로 하기 위해 AAC viewModel 를 도입하여 필요한 정보를 저장했다. 이후 저장된 데이터는 위에서 언급한 세 개의 fragment 에서 주로 사용되었다.
그 예로 유저 데이터의 경우는 한번 저장되어 홈화면의 안내 문구, 마이페이지의 정산 금액 표시 등에 사용되었다. AAC viewModel 을 이용했기 때문에 화면 전환 등에도 데이터가 저장되는 장점을 누릴 수 있었다.
mainActivity 의 문제점
앞에서도 계속 언급했듯 변화되는 데이터 반영이 어플을 재시작 하는 것 외에는 불가능하다는 치명적인 단점이 존재했다. 뿐만 아니라 mainActivity 가 너무 무겁게 돌아가다 보니 mainActivity 에서 많은 비정상 종료가 발견되었고 에러를 찾아 유지보수 하는 일이 정말 어려웠다. 그래서 리팩토링을 시작했고 mainActivity 를 가볍게 만들기 위해 공부 중에 있다.