반성 식탁

이 글이 위치한 시리즈의 이름은 '반성 식탁'일 것이다.이번에 출시를 하게 된 앱의 이름이 '반성 식탁'이기 때문이다.배포까지 앱 개발 기간은 3주 남짓이었다. 기간이 짧았다.업데이트 및 서비스 운영 경험을 위해, 그리고 학업을 병행 중이기 때문에 빠른 앱 출시를 감행

초보 전용

필자는 프로젝트를 기획하면서 다음과 같은 기능 구현이 필요해졌다.로그인유저 정보 저장피드 글 작성등등즉, 필자에겐 데이터를 저장, 관리할 서버가 필요해졌다는 것이다.개인 서버 구축 방법을 찾아보자.서버를 구축할 필요가 없다. GCP의 Firestore를 사용하면되기 때

일전에 Coroutine에 대해 글을 작성했다.그럼에도 불구해도 이번에 글을 다시 쓰게 된 계기가 있다.Coroutine을 두리뭉술하겐 알았으나 구체적인 사용법을 몰라서 삽을 좀 팠다.하여간, 이번 프로젝트에서 Coroutine을 많이 사용했다. ViewModel 클래

협업해요

현재 '반성 식탁' 시리즈를 통해 프로젝트를 진행한 후기들을 작성 중이다. MVVM, Firebase, Coroutine, Github, 프로젝트에 있어 비중이 높은 파트들이었다. 다음으로 어떤 글을 작성할까 고민을 해봤는데, 자잘한 개발 요소들을 글로 다시 담아내봤자

궁금했던 것 2편이다. 오늘은 궁금했던 것들 1편 - View Binding의 성능 향상 글의 연장선상에 있는 이야기를 하려고 한다. View Binding에 관련된 얘기다. View Binding에 대한 설명은 위의 글에서 설명해놓았으니 궁금하다면 보고 오자.View

이번엔 MVVM의 ViewModel에 관한 궁금증을 해결해 볼 예정이다. MVVM에 관한 사항은 해당 글에서 설명한 바가 있다. 잘 모른다면 한 번 읽어보는 것도 좋겠다. MVVM을 안드로이드 문서에서는 Clean Architecture라는 이름으로 소개하고 있다. 그

Memory Leak에 관한 이야기를 해보려 한다. 저번에 작성한 궁금했던 것들 2편 - 바인딩 클래스와 생명 주기에서 '프래그먼트에서 바인딩 클래스 인스턴스를 정리해줘야 하는 이유'에 대해서 공부했다. 문서를 보며 개발을 진행하지만, 해당 이유를 알기 전까진 인스턴스

현재 앱에서 Memory Leak이 발생하는 상황이나 기준에 대해 알기 위해 궁금했던 것들 4편(1) - Garbage Collection에서 JVM Garbage Collection에 대해 다뤘다. 필자는 왜 GC를 다뤘을까?우선, 불필요한 메모리가 해제되지 않아 성

지금까지 앱 출시를 위해 열심히 달려왔다면 출시 시점에 직면할 것이다.필자도 그러하다. 물론 결과물은 그닥 퀄리티가 좋은 편은 아니었지만, 프로토 타입 수준까진 도달했다고 생각했다. 이렇게 앱 출시에 있어 다사다난한 여정이 시작됐다. 그 여정은으로부터 시작된다. &lt

근 한 달 간을 프로젝트에 매달려 보냈다. 결과물은 어떨까. 생각했던만큼 양적으로 풍성한 결과가 나오진 않았다. 노트에 필기를 정리할 때를 생각해보자. 초반에는 별다른 생각이 들지 않는다. 하지만 시간이 지날 수록 현재 필기의 전체적인 형태가 눈에 들어오고 아쉬운 부분

인앱 리뷰 기능을 구현하기 위해 문서를 기웃거리다가 인앱 리뷰 테스트라는 공식 문서를 발견했다. 인앱 리뷰와 같은 경우 실제 플레이스토어에 리뷰가 달리는 과정이기 때문에, 해당 코드가 잘 실행되는지 확실히 알 길이 없었다. 따라서 해당 글은 나에게 도움이 되었다. 인앱

이전에 인앱 리뷰 기능 테스트를 위해 내부 테스트 트랙 출시를 진행했다. 이후 플레이 콘솔의 대시보드에서 한 알림을 발견했다.사전 출시 보고서에서 앱 문제 발견됨파이어베이스 또는 플레이 콘솔에서 앱에 문제가 있으면 알려주는 것은 익히 알고 있었다. 플레이 콘솔의 경우