Repository navigation
상세·수신 흐름 6개 화면이 재진입 시 미갱신 — 수정 후 복귀해도 옛 값 표시 #701
Description
2026-09-21 완료 판정
현재 develop f69332d995a2e9890605b3c8075c427b2dd0cc8c에서 원래 문제였던 수정 후 복귀, 화면 왕복, 앱 백그라운드 복귀 시 갱신 경로를 확인했습니다. 기존 구현으로 해결되어 새 코드를 추가하지 않습니다.
| 대상 | 현재 동작과 근거 |
|---|---|
| 애프터노트 상세 | ON_RESUME에서 refreshOnReturn 호출 |
| 수신 애프터노트 상세 | ON_RESUME에서 refreshOnReturn 호출 |
| 수신 추억 플레이리스트 | ON_RESUME에서 refreshOnReturn 호출 |
| 발신자 상세 | ON_RESUME에서 refreshOnReturn 호출 |
| 수신자 홈 | ON_RESUME에서 refreshOnReturn 호출 |
| 받은 기록함 | SenderRegistry의 StateFlow를 그대로 노출하고 화면에서 lifecycle에 맞춰 구독 |
상세 4화면은 #1374, 수신자 홈은 #1666으로 병합됐고, 결선 소실 가드는 #1638로 병합됐습니다. 모두 위 develop에 포함됩니다.
받은 기록함에 대한 종전 판정을 정정합니다. 현재 목록은 한 번 조회한 결과를 보관하는 구조가 아닙니다. 발신자 등록, 신원 결합, 인증 상태 변경이 같은 singleton의 StateFlow를 갱신하고 화면은 그 Flow를 계속 받습니다. 등록 화면도 등록 후 기존 기록함으로 복귀합니다. init 조회 함수가 없다는 사실은 여기서 재진입 미갱신의 증거가 아니었습니다.
당겨서 새로고침 판단
두 화면에 새 제스처를 추가하지 않습니다.
- 받은 기록함은 현재 로컬 변경을 즉시 구독하므로 다시 요청할 원격 소스가 없습니다. 제스처를 붙여도 데이터 갱신 동작이 생기지 않습니다.
- 수신자 홈은 재진입 자동 갱신과 기존 오류 화면의 재시도가 연결돼 있습니다. 이 이슈가 지목한 복귀 시 옛 값 유지 문제는 그 계약으로 해결됩니다. 정상 화면에 머무는 동안의 수동 갱신 UX를 새로 도입하는 것으로 범위를 늘리지 않습니다.
#607의 서버 목록 미연동, 접근 자격, 목록 범위에 관한 발견 결함은 별도로 남습니다. 그러나 아직 확정되지 않은 서버 목록 전환과 그 뒤의 refresh 구현을 이 이슈의 미완료 조건으로 예약하지 않습니다. 원래 문제를 줄여서 제외하는 것이 아니라, 현행 목록의 실제 갱신 구조가 최초 진단과 달랐음을 반영합니다. 이에 현재 완료 조건을 막지 않는 blocked_by #607 관계를 제거합니다.
검증
- 현재 소스에서 위 6개 경로와 실제 등록·신원·인증 상태 변경 소비를 대조했습니다. 받은 기록함의 재진입 검증을 신규 기기 실행으로 보고하지 않습니다.
- 기존 최신 실행 산출물에서 관련 ViewModel 5종 42 tests와
RefreshOnReturnWiringKonsistTest1 test, 합계 43 tests가 실패·오류 없이 통과했습니다. 이 실행은 #2133의ed0cd5bf2e6444f4c7721c6de89dbd05c4d8307c기준이며, 해당 프로덕션·테스트 소스가 위 develop과 동일함을 확인했습니다. 같은 커밋의 원격 Unit Test 성공도 확인했습니다. - 새 코드·테스트 추가나 반복 실행 없이 기존 구현과 검증 결과로 완료합니다.
2026-08-03 최초 진단과 당시 작업 항목, 현재 상태는 위 완료 판정 참고
📜 Overview (Required)
애프터노트·수신자 흐름의 상세/목록 화면이 한 번 로드한 뒤로 갱신 통로가 없다. ViewModel init 에서 1회 로드하고 재로드 진입점을 두지 않아, 화면이 백스택에 살아 있는 동안(수정 후 복귀, 탭 왕복) 옛 값이 그대로 남는다.
실측 (2026-08-03, develop): 갱신 통로 0인 화면
| 화면 | ViewModel | 상태 |
|---|---|---|
| 애프터노트 상세 (갤러리·추억·계정) | AfternoteDetailViewModel |
init 1회 로드, 재로드 진입점 없음 |
| 수신 애프터노트 상세 | ReceivedAfternoteDetailViewModel |
〃 |
| 수신 추억 플레이리스트 | ReceiverMemorialPlaylistViewModel |
〃 |
| 발신자 상세 | SenderDetailViewModel |
〃 |
| 받은 기록함 | ReceivedRecordsViewModel |
init·재로드 진입점 모두 없음 |
| 수신자 홈 | ReceiverHomeViewModel |
init 1회 로드, 재로드 진입점 없음 |
가장 확실한 피해 경로: 애프터노트 상세에서 수정 화면으로 들어가 저장하고 뒤로 돌아오면, 상세는 수정 전 값을 그대로 보여준다.
대조군: 전 앱에서 갱신이 실제로 결선된 화면은 6곳뿐이다.
- 홈 탭:
app/.../navigation/AppNavigation.kt:110-114LifecycleEventEffect(ON_RESUME)→refreshOnReturn(), 여기에 당겨서 새로고침까지 - 애프터노트 홈: 당겨서 새로고침 (Paging3 SSOT)
- 설정 메인:
SettingScreen.kt:69 - 마인드레코드 홈:
HomeScreen.kt:82-84카테고리별refreshOnReturn() - 타임레터 목록:
TimeletterScreen.kt:60-61repeatOnLifecycle(STARTED) - 애프터노트 에디터 수신자:
AfternoteNavGraphEditor.kt:169
당겨서 새로고침(PullToRefreshBox)은 전 앱 62개 화면 중 홈 탭·애프터노트 홈 2곳에만 있다.
해야 할 일
- 상세 화면에 재진입 갱신 결선: 홈 탭의
LifecycleEventEffect(ON_RESUME)패턴을 재사용한다 - 목록성 화면(받은 기록함·수신자 홈)에 당겨서 새로고침을 둘지 결정
📌 Child Issue(Optional)
No response
📍 Note (Optional)
같은 계열을 담당별로 나눠 등록했다: 애프터노트·수신자 흐름 #701, 마인드레코드 #702, 타임레터·설정 #703, 설정 수신자 목록 #579.
받은 기록함은 #607(서버 목록 API 미연동, 로컬 stub) 이 선행이라 그 이슈가 해소된 뒤 갱신 결선이 의미를 갖는다. 수신자 홈 요약 카운트는 #610 이 별건으로 다룬다.
Activity
OnlyReadOneBook commentedon Aug 25, 2026
축 하나 추가 — 프로세스 백그라운드 복귀 시에도 재조회가 없다
본 이슈는 "화면 재진입(수정 후 복귀·탭 왕복)" 을 다루는데, 실측에서 앱 프로세스가 백그라운드에 있다 돌아올 때도 같은 공백이 있었습니다.
실측 (develop
4e0a648eb)"서버가 잠깐 죽었다 살아나는" 상황에서 사용자가 앱을 다시 열었을 때 화면이 계속 옛 실패를 보여주는 셈입니다. 마음의 기록은 재시도 버튼도 없어(#716) 빠져나갈 수단이 없습니다.
화면 재진입과 프로세스 복귀 중 어느 범위까지 이 이슈에서 다룰지 정해 두면 좋겠습니다. 별도 추적이 낫다면 분리하겠습니다.
docs(qa): 서버 복구 후 2차 실측 결과를 현황에 추가한다
[-]fix(afternote): 상세·수신 흐름 6개 화면이 재진입 시 미갱신 — 수정 후 복귀해도 옛 값 표시[/-][+]상세·수신 흐름 6개 화면이 재진입 시 미갱신 — 수정 후 복귀해도 옛 값 표시[/+]OnlyReadOneBook commentedon Aug 28, 2026
6개 화면 중 5개(애프터노트 상세·수신 상세·수신 플레이리스트·발신자 상세·수신자 홈)의 재진입 갱신 결선은 PR #1374 로 반영됐다. 받은 기록함(ReceivedRecordsViewModel)은 #607(서버 목록 API 연동) 해소 후 결선한다.
fix(afternote): 첫 진입 resume 의 자동 재조회를 차단한다 (#701)
fix(receiver): 첫 진입 resume 의 자동 재조회를 차단한다 (#701)
fix(receiver): 수신자 홈 재진입 갱신을 범위에서 뺀다
OnlyReadOneBook commentedon Aug 29, 2026
수신자 홈 몫은 #1452 로 이관 (2026-08-29)
수신자 홈 담당이 이관되면서 PR #1374 에서
ReceiverHomeEntry·ReceiverHomeViewModel의 재진입 갱신을 도려냈습니다(커밋f01529dc1).handover/receiver-home-reentry-refresh(develop 기준, 테스트 9건 통과)ReceivedRecordsViewModel): 종전대로 받은 기록함이 서버 목록 API 를 쓰지 않고 로컬 stub 으로 동작 — record-boxes 미연동 #607 선행 대기따라서 이 이슈는 PR #1374 머지만으로는 완결되지 않고, #1452 까지 끝나야 «6개 화면» 이 채워집니다.
OnlyReadOneBook commentedon Sep 2, 2026
결선 소실 회귀 가드(konsist)와
ReceiverNavGraph이동 잔재 정리를 #1725 로 분리했고 PR #1638 이 그 이슈를 Closes 합니다.본문 6화면 중 5화면(상세 4 + 수신자 홈)은 PR #1374·#1666 으로 develop 에 결선돼 있습니다. 08-29 코멘트의 «#1452 까지 끝나야» 조건은 09-01 에 충족됐습니다.
이 이슈에 남는 것은 받은 기록함(
ReceivedRecordsViewModel) 결선과 «목록성 화면(받은 기록함·수신자 홈)에 당겨서 새로고침을 둘지» 결정 둘입니다. 받은 기록함은 #607 이 서버 목록을 연결해야 갱신할 대상이 생기므로blocked_by는 유지합니다.fix(setting,timeletter): 상세·하위 화면 재진입 갱신을 컴포지션이 아닌 ViewModel 수명에 묶는다
OnlyReadOneBook commentedon Sep 13, 2026
실측 기록 (2026-09-13, origin/develop
7d87aa3f4)지금 이 이슈에서 코드로 뗄 독립 범위가 없어 PR 대신 기록만 남긴다. 본문 표가 2026-08-03 실측 그대로라 다음 착수자가 6화면 전부 미결선으로 읽고 중복 착수하기 쉽다.
1. 본문 표 6행 중 5행은 develop 에 이미 결선돼 있다
08-28·09-02 코멘트가 밝힌 사실이지만 파일과 줄이 어디에도 없어 확인할 때마다 다시 찾게 된다.
LifecycleEventEffect(Lifecycle.Event.ON_RESUME)에서 갱신을 부르는 자리는 이렇다.AfternoteDetailRoute.kt:160-161AfternoteDetailViewModel.kt:133ReceivedAfternoteDetailRoute.kt:45-46ReceivedAfternoteDetailViewModel.kt:76ReceivedAfternoteNavHost.kt:80-81ReceiverMemorialPlaylistViewModel.kt:71SenderDetailScreen.kt:69-70SenderDetailViewModel.kt:76ReceiverHomeEntry.kt:25-26ReceiverHomeViewModel.kt:77짝이 풀리면
konsist/src/test/kotlin/com/afternote/konsist/RefreshOnReturnWiringKonsistTest.kt가 막는다.2. 남은 한 행은 결선할 대상 자체가 없다
feature/receiver/presentation/.../recordsbox/ReceivedRecordsViewModel.kt는 21줄짜리로SenderRegistry.sendersStateFlow 하나만 흘린다. 로드 함수가 없으니 다시 부를 것이 없다.blocked_by #607유지가 맞고, 그 #607 자체가 지금 #1949(OPEN)와 Afternote-BE#93(OPEN)에 다시 막혀 있어 이 이슈에서 앞당길 수 없다.3. 본문이 develop 실태와 어긋나는 곳
9f893a9f3, 2026-09-02 19:44 KST)로feature:receiver에서feature:home으로 옮겨졌다. 09-02 21:01 코멘트는 이 이동보다 뒤에 쓰였는데도 둘을 묶은 채로 남아 있다. 받은 기록함 몫은 받은 기록함이 서버 목록 API 를 쓰지 않고 로컬 stub 으로 동작 — record-boxes 미연동 #607 뒤라 지금 결정할 수 없으니 두 화면을 한 문항으로 함께 결정하는 것은 성립하지 않는다. 두 몫 모두 이 이슈가 그대로 들고 있다. 모듈이 갈린 만큼 별도 이슈로 뗄 수도 있지만 아직 만들지 않았다.refreshOnReturn()결선부만 세도 12곳이다(appAppNavigation.kt:148포함). 본문이 인용한AppNavigation.kt:110-114는 지금 143-150 이다.PullToRefreshBox는HomeTabScreen.kt:139·AfternoteHomeScreen.kt:114뿐이다.본문은 고치지 않았다. 표와 수치를 지우면 2026-08-03 실측 기록이 사라지고, 완료 조건을 좁히는 편집도 아니라서다.
4. 다음 착수자 주의: 진행 중 PR 이 호출 형태를 바꾼다
#2021(afternote 3종)과 #2039(발신자 상세)이
viewModel.refreshOnReturn()을viewModel.onIntent(XIntent.RefreshOnReturn)로 바꾸고 VM 의refreshOnReturn을private으로 내린다. 결선 자리 파일도 움직인다. 플레이리스트는ReceivedAfternoteNavHost에서 새 파일ReceiverMemorialPlaylistRoute.kt:17-19로 빠지고, 발신자 상세는SenderDetailScreen.kt:40-41이다.가드는 두 PR 이 서로 다른 판을 들고 있다. #2021 스택은 Intent 형태를 매칭하는
hasRefreshCall을 이미 넣어 뒀고, #2039 는 develop 판 가드를 그대로 들고 있어SenderDetailScreen이 주석에 남은refreshOnReturn()텍스트로만 통과한다. 받은 기록함 결선을 #607 뒤에 붙일 때는 그 시점 develop 의 호출 형태와 가드 버전을 먼저 확인할 것.5. 프로세스 백그라운드 복귀 축은 닫는다
2026-08-25 코멘트가 "이 이슈에서 다룰지 정해 두자" 로 열어 둔 축이다. 이 이슈에서 따로 다룰 것이 없다.
ON_RESUME은 홈 버튼 복귀에서도 발화하므로 위 5화면이 그 경로까지 덮고(AfternoteDetailRoute.kt:157-158주석), 당시 재현 화면이던 마인드레코드 주간리포트는WeeklyReportScreen.kt:56에 결선됐다.OnlyReadOneBook commentedon Sep 20, 2026
2026-09-20 develop
f69332d995a2e9890605b3c8075c427b2dd0cc8c와 PR #2021b13a7026e312c037edfd223b089b50817faee640을 대조했습니다.애프터노트 상세, 수신 애프터노트 상세, 수신 추억 플레이리스트, 발신자 상세, 수신자 홈의 5종은 이미 ON_RESUME 갱신이 연결돼 있습니다. #2021은 애프터노트 3종의 기존 동작을 RefreshOnReturn Intent 소비로 옮기며, 여기서 다시 직접 ViewModel 호출을 추가할 필요가 없습니다.
남은 ReceivedRecordsViewModel은 현재도 SenderRegistry의 in-memory StateFlow만 노출합니다. 새로 서버에서 조회할 source가 없으므로 resume 호출만 추가해도 목록 미갱신이 해결되지 않습니다. 실제 blocked_by인 #607의 접근·목록 계약이 먼저 정해져야 합니다. 당겨서 새로고침 도입을 별도 미확정 구현으로 예약하지 않습니다.
따라서 새 독립 코드 범위는 없으며, 본문 최초 6종 중 이미 해소된 5종과 #607에 종속된 1종을 구분합니다. #607의 현재 판단도 2026-09-20 근거로 갱신했습니다.