Skip to content

refactor(core): 추모 영상 실행 가드가 발신자·수신자 2벌 — 37줄 문자 단위 동일본을 core:common 으로 승격 #1436

Closed

Description

@OnlyReadOneBook

작업 유형

refactor — 동작 변경 없는 구조·책임·경계 개선

주 담당 모듈

core — 코어

개요

추모 영상 URL 을 외부 앱으로 여는 실행 가드가 같은 코드 2벌로 존재한다.

모듈 함수 도입
feature/afternote/presentation (author/navigation/AfternoteNavGraphDetail.kt) launchMemorialVideo PR #1336 (#463)
feature/receiver/presentation (detail/MemorialReceivedDetailScreen.kt) launchReceivedMemorialVideo PR #1395 (#1394)

도입 당시엔 함수명만 통일해 diff 하면 본문 37줄이 문자 단위로 동일했다 (차이 0줄, 2026-08-29 실측).

2026-08-29 갱신 — 두 판은 이미 갈라졌다. PR #1395 가 안내 콜백을 원인별로 분리했다(onRejected = URL 불합격 / onUnavailable = 실행 거부). 작성자 판은 여전히 단일 onUnavailable 이라 URL 이 막힌 경우에도 feature_afternote_memorial_video_no_app(«재생할 앱이 없습니다») 이 뜨는 거짓 안내가 develop 에 남아 있다. 작성자 화면은 #1394 범위 밖이라 그 PR 이 0줄 유지했고, 해소는 이 승격이 맡는다.

왜 중복을 두면 안 되나 — 이건 스타일 중복이 아니라 보안 가드다. 허용 스킴(http/https)·host 검증 규칙이 두 곳에 흩어져 있으면 한쪽만 고칠 때 다른 쪽이 뚫린다. 그리고 이미 갈라지기 시작했다 — 거부 케이스 테스트 목록이 #1395 쪽에만 intent:·tel: 2건 더 많다 (#1336 6건 / #1395 8건).

승격 위치는 core:common — 이 함수는 Compose 비의존이고 Intent/Uri 만 쓰며, 두 소비 모듈이 모두 projects.core.common 에 의존한다. feature:afternote:presentation 의 internal 을 풀어 receiver 가 직접 참조하는 방향(모듈 의존 자체는 feature/receiver/presentation/build.gradle.kts 에 이미 있다)은 화면 유틸을 feature 모듈끼리 노출하게 되므로 택하지 않는다.

완료 조건

  • core:common 에 가드 함수를 1벌 신설한다 (공백 검사 + http/https(ignoreCase) 스킴 + host 비어있지 않음, startActivity 직접 시도 + ActivityNotFoundException·SecurityException·IllegalArgumentException 폴백).
  • launchMemorialVideo·launchReceivedMemorialVideo 두 정의를 제거하고 호출처 2곳을 승격본으로 치환한다.
  • 단위 테스트도 1벌로 통합한다 — 거부 목록은 두 판의 합집합(intent:·tel: 포함)을 기준으로. MemorialVideoLauncherTest·ReceivedMemorialVideoLauncherTest 는 제거한다.
  • 안내 콜백 계약은 PR fix(receiver): 수신 추억 노트 상세 영상 실행에 http/https 스킴 가드 이식 (#1394) #1395 에서 이미 확정된 onRejected / onUnavailable 2콜백을 그대로 쓴다. 승격과 함께 작성자 호출처도 두 갈래로 갈라 거짓 안내를 없애고, 작성자 쪽 문구 리소스도 URL 불합격용 1건을 추가한다(현재 feature_afternote_memorial_video_no_app 하나뿐).

자식 이슈

No response

참고

Activity

  1. added
    refactor동작 변경 없이 코드 구조·책임·경계를 개선하는 작업
    area:core공용 코어·네트워크 기능 영역
    on Aug 29, 2026
  2. added
    pr-open이 이슈를 구현하는 PR 이 열려 있다 — base 가 기본 브랜치가 아니어도 드러낸다
    on Aug 29, 2026
  3. removed
    pr-open이 이슈를 구현하는 PR 이 열려 있다 — base 가 기본 브랜치가 아니어도 드러낸다
    on Aug 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area:core공용 코어·네트워크 기능 영역refactor동작 변경 없이 코드 구조·책임·경계를 개선하는 작업

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions