EXT-DAY 01 | 개인 프로젝트 — 유지보수 (6) v1.1.2
수료했다고 해서 프로젝트가 끝난 건 아니다. 마저 진행해 보도록 하자.
날짜 일관성 맞추기
앱으로 데이터를 불러올 때 날짜 형식을 맞춰서 변환하는 유틸리티 함수가 있어서 기능상의 문제는 없지만 일관성을 맞춰주는 편이 좋을 것 같다. 앱에서 올리는 녀석들은 다 ISO 8601 String으로 저장되는데 createdAt 처럼 firebase에서 기록되는 녀석들은 다 Timestamp로 되어 있다. firebase 표준인 Timestamp로 맞추는 게 좋을 것 같다.
일단 다음 버전인 v1.1.2에서 firebase에 올리는 데이터를 Timestamp로 싹 바꿔놓고, v1.2.0 배포 이후 시점에 지난 데이터들을 일괄 마이그레이션 하면 될 것 같다. v1.2.0 배포 후 시점이면 많이들 v1.1.2까지 올라오지 않았을까. 마이그레이션 하기 전에 앱 버전 정책의 최소 앱 버전을 v1.1.2로 올려 놓으면 문제 없을 거다. Typescript로 마이그레이션 돌리면 되겠지.
토글 사용성 개선
출발지/경유지/도착지 중 하나를 선택해야 하는 부분이 있어 이분법적인 토글이 아니라 여러 개의 후보를 가질 수 있는 토글 라이브러릴 사용하고 있다. 한 프로젝트 내에서 토글 라이브러리를 여러 개 쓸 이유는 없을 것 같아 이걸로 하다 보니 양자택일 토글 라이브러리에 기본값으로 되어 있는 기능이 빠져 있었다. 일반적인 양자택일 토글은 탭 하는 순간 값을 반전시키면 되는데 선택지가 셋 이상이 될 수 있는 토글은 목적지가 명확해야 해서 발생한 이슈다. 이로 인해 설정 화면의 푸시 알림 토글 같은 작은 양자택일 토글은 한 번의 탭으로 가볍게 컨트롤하기 어렵고, 정밀하게 터치하거나 드래그해야만 토글이 작동되는 형태가 되어 버렸다.
삼지선다 토글 같은 데는 적용하지 않고 오직 단순한 형태의 양자택일 토글에만 탭에 대한 이벤트 처리를 넣었다. 넣는 김에 가벼운 햅틱 반응도 넣어 보았다.
상태창 메시지 지워짐
안드로이드 버전의 경우 세션 진행 중에 상태창 메시지가 뜬다. (애플은 거긴 알림이 오는 곳이지 상태를 보여주는 곳이 아니라는 관점이라 넣지 않았고 위치 추적 인디케이터만 띄웠다. 알림창이 아닌 별도의 Widget Extension으로 잠금 화면에서 현재 진행 상태를 확인할 수 있게 하는 방법도 있다는데 이건 추후에 고려할 수도 있고. 당장은 구현 안 되어 있다.) 그런데 이게 완전히 고정되지 않고 스와이프나 알림 전체 지우기로 사라져 버린다는 제보를 받았다...! 알고 보니 setOngoing 값을 true 로 지정해 주어야 알림창에서 사라지지 않고 고정되어 있는다고.
이 값을 적용하는 김에, 세션 진행 중과 자동 일시정지, 수동 일시정지 상태에 따라 텍스트가 다르게 출력되게 수정하였다. 나중에 애플 쪽에서 잠금 화면에 현재 진행 상태를 띄우는 걸로 결정을 하면 안드로이드 쪽에서도 여기에 현재 진행 상태를 포함하게 수정하던가 해야지. 일단은 이대로면 될 것 같다.
인앱 버그 리포트
현재 안드로이드 비공개 테스터들은 버그 리포트를 제출할 수 있지만 정식 배포 상태의 사용자를 위한 버그 리포트가 별도로 존재하지 않는다. 그렇게 되면 사용자가 불편을 느꼈을 때 이를 제보하고 개선되길 기다리기보다는 앱을 지우고 이탈할 확률이 높다. 스토어에 들어가서 문의 메일을 확인하고 연락할 사람은 거의 없으니 말이다. 그런 의미에서 인앱 버그 리포트가 있는 게 좋겠다.
버그 리포트는 앱 버전, 기기 모델, OS 버전을 자동으로 불러오고 사용자 피드백과 선택적인 스크린샷으로 구성된다. 앱 버전은 이전에 package_info_plus package를 넣어두어 바로 가져올 수 있지만 기기 모델 및 OS 버전을 불러오기 위해서는 device_info_plus package도 추가해야 한다.
문의/제보에 대한 응답을 받고 싶은 경우에는 이메일로 문의하고, 응답이 필요 없고 자신의 이메일 주소를 밝히고 싶지 않은 경우에는 인앱 문의/제보를 이용하도록 구현했다. 내가 누군지 드러난다는 것이 부담스러워서 이메일로 제보하길 꺼려할 수 있으니 말이다. 일단 내가 그렇고.
인앱 버그 리포트를 만드는 김에 관리자용 웹페이지에 버그와 신고를 관리하는 탭을 각각 추가했다. 아무래도 Firestore에서 살펴보는 것보다 이 편이 훨씬 편하니까.
여담: fvm
flutter SDK 버전 관리용 fvm 을 설치했다. 여러 프로젝트에서 서로 다른 flutter version을 사용할 경우 이걸 사용하는 편이 경로가 꼬이지 않게 관리하기 용이하다고 한다. fvm global x.y.z 형태로 터미널 전역에서 사용할 기본 버전을 지정할 수 있고 프로젝트 루트에서 fvm use x.y.z 형태로 해당 프로젝트에서 사용할 버전을 선택할 수 있다. fvm releases 명령어로 출시된 최신 버전 목록을 확인하고 fvm install stable 명령어로 가장 최신 안정화 버전을 설치하거나 fvm install x.y.z 형태로 특정 버전을 설치할 수 있다.
일단 우리 프로젝트는 Flutter 3.44.4 버전을 사용하고 있었으므로 충돌이 발생할 것을 방지하기 위해 사용하던 버전을 그대로 설치하고 기존에 manual로 설치해 놓은 것은 정리하도록 하겠다. global은 stable로 두고 프로젝트를 새로 생성할 때마다 그 시점의 가장 최신 버전을 fvm use 해서 쓰면 될 것 같다.
프로덕션 신청
그새 14일이 지나 Play Console의 [프로덕션 신청] 버튼이 활성화되었다.
누구를 타깃으로 한 앱이고 이 앱이 제공하는 가치는 무엇인지,테스터를 어떻게 모집했고 어떤 피드백을 받았는지, 어떤 게 반영되었고 왜 프로덕션으로 올려도 된다고 판단했는지에 대한 간단한 설문을 작성하면 프로덕션 엑세스 권한 신청이 접수된다.
승인이 되면 다음과 같이 뜨며 다음 버전부터는 프로덕션 출시로 할 수 있게 된다. 그런 의미에서 v1.1.2부터는 프로덕션으로 올리기로 했다. [테스트 및 출시] 메뉴의 [프로덕션]에서 새 버전을 만들어 출시할 수 있다. 검토 후 출시되는 데까지는 시간이 좀 걸릴 것 같지만. 듣자하니 테스트 배포는 비교적 빠르게 승인되지만 실제 출시는 훨씬 시간이 걸린다는 모양이다.
