세로 화면에서 잘 동작하던 내역과 미니차트를 가로모드에도 맞추는 작업을 했다. 처음에는 부모 RectTransform의 크기와 Anchor만 바꾸면 될 줄 알았다. 화면은 넓어졌지만 높이가 줄면서 버튼이 겹치고 목록은 몇 줄 보이지 않았다.
세로 레이아웃을 옆으로 늘리는 것과 가로 화면을 설계하는 건 달랐다. 무엇을 한 줄에 놓을지, 어떤 정보는 접을지 다시 정해야 했다.
공간이 넓어져도 모두 보여 줄 수는 없었다
가로모드는 폭이 넓지만 높이가 짧다. 세로에서 아래로 쌓던 헤더, 필터, 목록과 차트를 그대로 유지하면 실제 내용 영역이 거의 남지 않았다.
그래서 정보를 세 그룹으로 나눴다.
- 항상 보여야 하는 값
- 선택했을 때만 보여도 되는 상세 값
- 가로모드에서 다른 위치로 옮길 수 있는 조작 버튼
레이아웃 수정이 디자인 파일의 위치를 복사하는 일이 아니라 정보 우선순위를 코드와 프리팹에 반영하는 일이었다.
방향 전환 중간에도 이벤트가 왔다
화면 방향이 바뀌면 여러 프레임에 걸쳐 RectTransform 크기가 달라졌다. 너무 일찍 높이를 읽으면 이전 값으로 아이템 수를 계산했다. 목록 리사이즈와 데이터 응답이 같은 시점에 오면 위치가 튀기도 했다.
IEnumerator RebuildAfterOrientationChanged()
{
yield return null;
Canvas.ForceUpdateCanvases();
RebuildLayout();
}
항상 한 프레임 기다리는 게 정답이라는 뜻은 아니다. 프로젝트의 레이아웃 갱신 시점을 확인하고 확정된 크기에서 계산해야 한다는 점이 중요했다.
두 프리팹과 한 프리팹 사이에서 고민했다
세로·가로를 완전히 다른 프리팹으로 나누면 각 레이아웃은 단순해지지만 데이터 연결과 이벤트 코드가 중복될 수 있었다. 하나의 프리팹에서 모든 배치를 바꾸면 공통 로직은 유지되지만 조건이 복잡해졌다.
당시 화면은 같은 정보와 기능을 공유하는 부분이 많아 공통 스크립트를 두고 레이아웃 그룹과 일부 오브젝트만 방향에 따라 전환했다. 완전히 다른 화면이 필요해지면 분리하는 편이 나을 수 있다는 경계도 함께 배웠다.
반응형은 사용 흐름을 유지하는 일이었다
가로 화면에서 버튼 크기만 맞는다고 끝이 아니었다. 방향을 바꾸기 전 선택한 항목과 스크롤 위치가 유지되는지, 열려 있던 상세가 어떻게 배치되는지, 손가락으로 누르기 충분한 영역인지 확인했다.
이후 반응형 작업을 할 때 해상도 목록부터 맞추지 않는다. 작은 높이, 긴 문구, 키보드가 열린 상태처럼 사용 공간을 줄이는 조건을 먼저 본다. 가로모드는 세로 화면의 회전판이 아니라 같은 기능을 다른 공간에서 이어 쓰게 만드는 별도 경험이었다.