한 화면에서 가로모드를 맞춘 경험이 생겨 다른 화면도 비슷하게 바꾸면 될 줄 알았다. 목록 화면, 차트 화면, 주문 화면은 같은 방향 전환을 겪지만 중요한 정보와 입력 방식이 달랐다. 공통 스크립트에 화면 이름별 조건이 빠르게 늘어났다.
가로모드는 세로 화면을 옆으로 늘리는 작업이 아니라 제한된 높이에서 정보 우선순위를 다시 정하는 일이었다.
공통으로 계산할 값부터 뽑았다
방향, 안전 영역, 화면 비율처럼 모든 화면이 필요한 값은 하나의 레이아웃 문맥으로 만들었다.
public readonly record struct LayoutContext(
bool IsLandscape,
Rect SafeArea,
float AspectRatio,
LayoutSize Size);
각 화면은 이 문맥을 받아 자신의 배치를 결정했다. 전역 코드가 특정 버튼이나 패널 이름을 알지 않게 했다.
화면별로 숨길 정보가 달랐다
목록은 열 수를 줄이고 상세 패널을 옆으로 보낼 수 있었다. 차트는 가로 공간을 최대한 쓰되 도구 버튼의 터치 영역을 유지해야 했다. 주문 화면은 입력 항목을 숨기기보다 스크롤을 허용하는 편이 안전했다.
목록 화면: 요약 열 우선, 상세는 선택 시 표시
차트 화면: 차트 영역 우선, 도구는 접을 수 있게
주문 화면: 필수 입력 유지, 보조 설명 축소
공통 규칙은 최소 여백과 안전 영역까지였고 정보 선택은 화면 책임으로 남겼다.
회전 중간 상태도 있었다
해상도 변경 이벤트가 한 번만 오는 게 아니어서 레이아웃을 연속으로 다시 만들면 흔들렸다. 프레임 끝에서 마지막 크기를 기준으로 한 번 적용하고, 실제 값이 바뀌었을 때만 갱신했다.
팝업이 열린 상태, 키보드가 올라온 상태, 차트 드래그 중 회전하는 경우도 따로 확인했다. 방향만 바꾸고 선택 상태나 입력 값은 유지해야 했다.
검증할 때는 기기 이름을 늘어놓기보다 작은 가로 화면, 넓은 가로 화면, 안전 영역이 있는 화면처럼 조건을 나눴다. 각 조건에서 잘림, 최소 터치 영역, 스크롤 가능 여부를 확인하니 새 기기가 추가돼도 같은 기준을 재사용할 수 있었다.
공통화는 정책을 빼앗지 않아야 했다
처음에는 한 스크립트로 모든 가로모드를 처리하는 게 깔끔하다고 생각했다. 화면마다 조건문이 늘어나는 걸 보고 공통화할 대상은 환경 계산이고, 화면의 정보 우선순위는 각 화면이 결정해야 한다는 걸 알았다.
여러 화면을 대응하며 반응형 UI를 좌표 문제가 아닌 정책 문제로 보게 됐다. 같은 기기 방향에서도 사용자가 하려는 일이 다르면 레이아웃의 답도 달랐다.