앱에서 언어를 바꾸고 종료한 뒤 다시 실행하면 첫 로딩 화면과 로그인 화면 일부가 기본 언어로 잠깐 보였다가 저장한 언어로 바뀌었다. 설정 파일에는 마지막 선택이 정상적으로 들어 있었다. 언어를 읽는 시점이 첫 UI 생성보다 늦었다.
최종 상태만 맞으면 되는 설정과 첫 프레임부터 맞아야 하는 설정의 우선순위가 달랐다.
최소 언어 설정을 먼저 읽었다
전체 사용자 설정을 복호화하고 동기화할 때까지 기다리지 않고, 부트 화면에 필요한 언어 코드를 빠르게 확인할 작은 경로를 뒀다.
앱 시작
-> 로컬 언어 힌트 읽기
-> 초기 자산 선택
-> 전체 설정 로드·검증
-> 서버 설정 동기화
로컬 힌트가 깨졌으면 OS 언어나 기준 언어로 안전하게 시작했다.
언어 출처의 우선순위를 정했다
OS 언어, 마지막 로컬 선택, 로그인 뒤 서버 설정이 서로 다를 수 있었다. 사용자가 직접 선택한 마지막 값은 지원되는 언어라면 우선하고, 로그인 후 서버 값과 충돌할 때 제품 정책에 따라 동기화했다.
Language Resolve(Language? saved, Language system)
=> saved is { } value && supported.Contains(value)
? value
: supported.Contains(system) ? system : defaultLanguage;
지원 목록에서 제거된 언어를 저장하고 있던 경우도 기본 경로로 처리했다.
초기 화면을 두 번 만들지 않았다
기본 언어로 UI를 만들고 나중에 전체를 다시 만드는 방식은 깜빡임과 이벤트 중복을 만들었다. 언어 결정 전에는 언어 중립 로딩 표시를 사용하고, 결정된 뒤 로그인 화면을 한 번 생성했다.
이미 열린 팝업과 네이티브 SDK 화면처럼 앱 번역 시스템 밖에 있는 요소도 언어 전달 시점을 확인했다.
앱을 강제 종료한 직후 재실행, 저장 중 종료, 지원 언어 목록이 바뀐 업데이트도 확인했다. 마지막 값이 존재해도 현재 빌드에서 사용할 수 있는지 다시 검증해야 했다.
작은 설정에도 시작 우선순위가 있었다
언어 값 저장 자체는 오래전부터 됐지만 사용자가 처음 보는 순간까지 이어지는 경로는 따로 봐야 했다. 설정이 존재한다는 것과 제때 소비된다는 것은 다른 문제였다.
이후 부트 과정에서는 테마와 언어처럼 첫 화면을 결정하는 값, 로그인 뒤에 필요한 값, 나중에 불러도 되는 값을 나눈다. 초기화 순서는 기술 편의보다 사용자에게 보이는 의존성에 맞춰야 했다.