습관만들기 Pawbit TIL 1

Django에서는 모델만 고치면 됐는데

Pawbit 개발을 시작한 첫날이었다. 습관과 잔고를 포함해 표 여섯 개로 데이터 설계(스키마, schema)를 확정했다. 회사 툴을 Django로 만들고 있어서 자꾸 거기에 빗대 보게 됐는데, 첫 차이가 여기서 나왔다. Django는 모델 파일만 고치면 끝인데, 여기는 표 정의를 고친 뒤에 build_runner를 한 번 돌려야 반영된다. build_runner는 설계를 읽어서 실제 조회 코드를 대신 써 주는 코드 생성기다. 표 정의와 조회는 Drift라는 라이브러리가 맡고, 생성된 코드는 .g.dart 파일로 따로 떨어진다.

차이는 언어의 성격에서 온다. Python은 실행하는 중에 모델을 읽고 바로 이해하는 동적 언어고, Dart는 실행 전에 모든 게 정해져 있어야 하는 정적 언어다. 그래서 설계에서 코드를 미리 만들어 두는 단계가 끼어든다. 실제 DB 표는 앱을 켤 때 Drift가 만든다.

• 판단: 스택을 고르면 고칠 때의 리듬도 같이 딸려 온다. 설계가 자주 바뀌는 초반에는 이 한 단계가 계속 붙는다.

---

조회를 따로 모아 두는 층이 왜 필요한가

Django는 Model.objects.all()처럼 모델이 조회까지 들고 있다. Drift의 모델은 표 모양만 담은 틀이라서 데이터를 넣고 빼는 일을 맡을 층을 따로 둔다. 이 층을 DAO(Data Access Object)라고 하고, Pawbit에서는 습관 관련 조회를 한 곳에 모았다.

쓸모는 규칙을 세울 때 보였다. 체크를 풀면 그 습관으로 받은 꿈 조각도 도로 빠지는데, 이미 조각을 써 버렸으면 잔고가 0 밑으로 내려간다. 그래서 잔고가 모자라면 체크 해제를 막게 했다. 조회가 한 곳에 모여 있으니 이 규칙도 거기 한 번만 세우면 됐다.

• 판단: 깨지면 안 되는 규칙이 걸린 데이터일수록 입구를 한 곳으로 모은다. 입구가 화면마다 흩어져 있으면 규칙도 그 수만큼 되풀이해야 하고, 하나만 빠져도 샌다.

---

체크를 눌렀는데 화면이 바로 안 바뀌었다

실제 기기로 돌려 보니 습관을 체크해도 화면이 바로 따라오지 않았다.

값이 바뀔 때마다 새 값을 흘려보내는 통로를 스트림(Stream)이라 하고, 화면이 그 통로를 지켜보게 붙여 주는 장치를 프로바이더(Provider)라고 한다. 상태 관리 라이브러리 Riverpod에서는 StreamProvider로 만들고 화면이 ref.watch로 지켜본다. 습관 목록과 잔고를 하나로 묶어 지켜보게 했더니 한쪽 변화를 놓쳤고, 둘에 프로바이더를 따로 달아 화면이 동시에 지켜보게 하자 바로 반응했다.

• 판단: 자동 갱신은 무엇이 바뀌었는지 구분될 때만 정확하다. 실제로 따로 움직이는 단위까지만 나누고, 늘 같이 바뀌는 것은 묶어 둔다.

---

탭을 오가도 화면이 그대로 남는 이유

하단 탭은 습관·홈·마을 셋으로 잡았다. 탭을 옮겼다 돌아와도 스크롤 위치와 입력하던 내용이 그대로 남는데, 이건 저절로 되는 게 아니다. IndexedStack을 써서다. 화면을 전부 메모리에 올려 두고 보이는 것만 바꿔치기하는 방식이라, 대신 안 보이는 화면도 계속 메모리를 차지한다.

온보딩을 한 번 본 사람에게 다시 안 띄우는 것도 같은 결이다. 최초 실행 여부를 SharedPreferences(기기에 작은 값을 오래 저장해 두는 공간)에 표시 하나로 남겨 둔다.

• 판단: 쓰기 편하다는 느낌은 대개 이런 선택이 쌓인 결과다. 탭을 자주 오가는 앱에서는 화면을 남겨 두는 쪽이 이득이 크다.

---

디슈가링이라는 말

안드로이드 빌드 설정에 디슈가링(desugaring)을 켜는 줄이 들어갔다. 처음 보는 말이라 찾아보니, 새 버전 Java의 기능을 옛 안드로이드가 알아듣는 형태로 바꿔 주는 빌드 단계였다. 이걸 켜야 구형 기기에서도 앱이 돈다.

• 판단: 어디까지 지원할지는 제품 결정처럼 들리지만, 실제로는 이런 빌드 설정 한 줄에서 갈린다.

---

Series: Today I Learn