💡 Intro 앱을 호기롭게 업데이트 했다. 그런데 2가지 치명적인 문제가 발견되었다. 먼저, 기존에 앱을 가지고 있던 사용자가 플레이스토어에서 업데이트를 요청하는 경우 다음과 같은 화면이 발생하며 업데이트가 되지 않는 문제가 있었다.. 처음 보는 문제이고, 내가 직접 겪은 것이 아니라 사용자가 나에게 이러한 문제가 있다고 알려주어서 상당히 곤란했다. 그래도 이러한 문제가 뜨고, 다시 한 번 업데이트 요청을 했을 때는 문제없이 동작한다고 한다. 두 번째 문제는 앱이 지속적으로 비정상종료 되는 것! 정상적으로 앱을 실행하기 위해서는 기존에 존재하던 앱의 캐시와 데이터를 모두 삭제해야만 했다. 그러면 정상적으로 실행이 되었지만 과연 개발자가 아닌 일반 사용자가 앱의 캐시와 데이터를 지우는 작업을 할까? 절대..
💡Intro 2, 3단계 리뷰를 받은 뒤에 프로젝트의 구조를 대대적으로 수정하게 되었고, 생각보다 내용이 길어져 리뷰 반영에 대해서만 다루려고 한다. 레벨 1, 2와는 다르게 레벨 4는 크루들이 서로의 코드를 리뷰해준다. 좀 엉망인 코드긴 하지만 빨리 제출한 편에 속했고, 덕분에 레아가 리뷰를 해주셨다. 그래서 아마 이에 대한 반영 내용이 주가 될 것 같다. 미션에 허덕이는 것이 싫어서 더 고민하지 않고 제출했었는데, 이렇게 득이 되어 돌아와 기분이 아주 좋다. 내 딴에는 열심히 생각하고 괜찮은 것 같은데? 라고 생각하면서 완성한 구조이지만 문제가 있다는 피드백을 받아 개인적으로는 마음이 조금 아프긴 하다. 😂 (문제가 있다고 직접적으로 언급하시지는 않았지만 임시방편인 느낌이라는 부분에서 문제가 있지만 ..
💡 Intro DI 미션 1단계에 이어 2, 3단계에 대한 글이다. DI 미션 1단계는 레아가 수업에서 라이브 코딩으로 다뤄주셔서 거지 딱다구리 같은 나의 코드들을 분리수거 해버리고 수업에서 진행했던 코드들을 되새김질 하며 많이 인용했다. 아니 거의 똑같이 구현했다. 2, 3단계는 그런 것도 없다. 그래서 또 힘들었고(이 양반은 같은 미션에서도 단계마다 어렵다고 하고 있네-_-), 리뷰를 받고 반영하면서 현재 구조가 문제가 많이 있음을 깨달았고, 구조를 한 번 뒤집어 엎었다. 한 번 들어가보자. ❗️ 만들면서 배우는 DI 2단계 2단계 요구 사항은 다음과 같다. 필드 주입 ViewModel 내 필드 주입을 구현한다. Annotation 다음 문제점을 해결한다. 의존성 주입이 필요한 필드와 그렇지 않은 필..
💡 Intro 어느덧 프로젝트에 집중하던 레벨 3이 지나고 레벨 4가 시작되었다. 이 글을 작성하기 시작한 오늘(9월 19일)을 기준으로 레벨 4가 시작한지 22일이나 되었다. 그런데 이제야 첫 글을 쓴다. 왜 벌써 22일이나 지난거지? 그리고 67일이 남았다. 시작할 때만 해도 9개월 남짓의 시간을 잘 버틸 수 있을까에 대해 걱정했는데, 이제는 끝이 다가오고 있음에 걱정하고 있다. 시간은 정말 빨리 지나간다. 무튼 각설하고 세상에서 제일 어렵고 힘들었던 레벨 4의 첫 미션에 대해 기술하려고 한다. 이놈의 주인장은 뭐 맨날 세상에서 제일 어렵다고 하냐라고 할 수 있겠으나 정말 어렵다. 주제는 “만들면서 배우는 DI” 무엇이 어려웠고, 어떤 요구사항을 만족하기 위해 어떤 고민을 했었는가에 대해 최대한 자세..
💡 Intro 이전 안드로이드 위치정보 가져오기 글에서는 LocationManager에 대한 내용만 있다. 사실 LocationManager 보다는 더 정확한 위치 정보를 제공해주는 FusedLocationProviderClient를 사용하고, 이전 글에 같이 정리했었지만 계속 내용이 추가되면서 글이 자꾸 길어져서 읽기 편하게(?), 혹은 분량을 보고 뒤로가기를 클릭하지 않도록 하기 위해 분리를 했다. LocationManager가 궁금하다면 아래 링크를 따라 이동해도 된다. 안드로이드 위치정보 가져오기 - LocationManager 💡 Intro 현재 진행하고 있는 프로젝트는 위치를 기반으로 하는 프로젝트다. 때문에 필수로 위치 정보를 가져와야 한다. 네이버맵 혹은 카카오맵에서 반환되는 값으로부터 간..
💡 Intro 서버에 이미지 파일을 업로드 하는 기능은 이전에 구현해본적 있기 때문에 수월하게 잘 할 수 있을 것이라고 생각했다. 그런데 생각보다 헷갈리고 모르는 것이 많더라. 딱 한 번 쓰고 기억을 하겠다는 것도 욕심이겠지만 처음하는 것과 다름없을 정도로 기억이 안나니 당황스럽다. 그 당시에는 기능이 정상동작하면 오! 된다! 하고 지나갔었는데 아마 그래서이지 않을까? 하지만 이번에는 그 때와는 다르게, 구현하면서 얘는 왜 이렇게쓰지? 쟤는 왜 이렇게쓰지? 이놈은 되고 저놈은 왜 안되는거야😩 와 같은 궁금증들이 계속 생겼고, 이 궁금증을 해결하고 싶어 상당히 많은 시간을 투자했다. 이번에 알게된 내용이 꽤나 많아서 정리하는 시간을 갖고 나중에 봐도 단번에 기억날 수 있기를 바라며 글을 시작한다. ❓ Mu..
레벨 3에서 진행한 예외처리 적용기 💡 Intro https://krrong.tistory.com/entry/예외처리 위 글을 작성하며 프로젝트에서 예외처리를 어떻게 하면 잘 할 수 있을까 고민을 많이 했고 제이슨의 도움으로 이론적인 해결의 실마리를 찾았다. 이 krrong.tistory.com 아래 내용을 적용한 글의 내용이 궁금하다면 참고해보자. 💡 제이슨의 특급강의 ❓ 나의 질문 현재 오류처리에 대해 진행하고 있다. 서버에서 http 응답 코드 4xx대로 내려주는 응답들이 body를 가지고 있고, 이 body는 각각 서버에서 정의한 errorCode와 message를 가지고 있는 형태다. ex) { errorCode : 2xx, message : messageString } 이전에 제이슨이 말씀해주..
💡 Intro 3주차 데모데이 권장 요구사항은 Firebase 연동과 Firebase Analytics, Crashlytics 등 모니터링 환경 구축, Log 설계 이렇게 세 개가 주어졌다. 지난 글에서 Firebase 연동에 대해 정리했으니 이번 글에서는 Analytics, Crashlytics를 이용한 모니터링 환경 구축하는 방법과 Log 설계에 대해 정리하려고 한다. Analytics, Crashlytics를 이용하는 방법은 크게 어렵지 않다. 이것보다는 Log를 어떻게 설계해야 하는지가 굉장히 고민되었다. 그래서 처음부터 로그를 완벽하게 설계한다는 것은 불가능하다고 생각하기 때문에 어느정도 기반만 잡아놓고 앱을 운영하면서 필요성을 느끼면 반영하고 수정하기로 했다. ❓ 로깅 이벤트는 Firebase..
