인프런 커뮤니티 질문&답변
작성한 질문수
UI 자체를 DB 에 의존하는 것에 관해
해결된 질문
작성
·
236
2
확장적인 사고를 통해 UI 를 컴포넌트화 했다는 점에서 일종의.. 개발자들의 자동화 욕망을 구현해내신게 아닐까 싶었습니다! 한창 듣는 중인데 너무 부럽기도 하고, 강의 해주셔서 감사하다는 말씀을 먼저 드립니다 ㅎㅎ
(질문)
앱 클라이언트가 매우 적은 역할을 하고 서버에서 모든 것이 그때그때 정의된다면, 마치 하이브리드 앱처럼 앱 업데이트를 개발자가 (거의) 실시간 강제할 수 있는 권한이 생기는 것인가요? 극단적인 예시를 들자면 app id 101 와 102 응답이 서로 바뀌면, 사용자 입장에서는 완전히 다른 앱이 로드되는 것도 이론적으론 가능한 것 같아서요. 생각해보면 은행 앱들이 켤 때마다 새 데이터를 매번 받아오고 무결성 검사를 하는 것 같기도 하고요.. 🤔
이렇게 UI 를 lazy loading(?) 하는 부분에서 구글 쪽 정책에 제한은 없는지, 이런 아키텍처를 설계한 뒤로 느끼신 단점은 없었는지 궁금합니다! 통과는 해두고 출시 후에 완전히 다른 앱으로 바뀔 가능성이 있다면 플레이스토어에서 가만 두지 않을(?) 것 같다는 생각이 들어서요!
(앗 혹시 제가 런타임과 빌드타임 구분된 설명을 전부 런타임으로 오해한 것일까요..? 😅)
답변 1
2
안녕하세요! 좋은 질문 감사합니다.
말씀하신 대로, 제가 구현한 아키텍처에서는 서버의 DB 값만 변경하더라도 앱의 동작과 UI가 크게 달라질 수 있습니다. 예를 들어, App ID 1번으로 출시된 앱의 서버 응답 데이터를 2번과 같이 변경하면, 사용자들은 전혀 다른 앱을 경험하게 될 수 있죠.
하지만 이는 구글 플레이스토어 정책에 위배될 수 있는 부분입니다. 경험상 작은 UI 변경이나 기능 개선 정도는 허용되지만, 앱의 성격이 완전히 바뀌거나 큰 폭의 변경이 있는 경우에는 경고나 앱 삭제 조치를 받을 수 있습니다. (실제로 이런 경험이 있습니다) 그래서 저의 경우 치명적인 버그나 오류가 아닌 이상 한번 설정된 서버 데이터는 크게 수정하지 않으려고 합니다.
그리고 네, 이 아키텍처는 런타임에 해당합니다. 앱이 실행되는 시점에 서버로부터 데이터를 받아와서 UI를 그리는 방식이기 때문입니다. 빌드타임에 결정되는 것이 아니라 실행 시점에 동적으로 UI가 결정된다고 보시면 됩니다. 😄
안녕하세요 레트로봉님 ㅎㅎ 좋은 질문 감사드립니다.
자주 호출되는 메인 부분 UI의 경우에는 또는 정말 자주 호출되는 UI 데이터는 미리 Splash 화면 단계에서 받아와서 메인으로 진입하기전 내부 로컬 DB에 쌓아두고 활용하는 편이고
사용자의 액션이 발생했을때 그려지는 화면의 경우는 그때그때 서버에서 받아오도록 해요. 물론 많은 부분들이 네이티브에 모듈화 되어 필요한 껍데기는 이미 구성되어있는 경우가 많고, 서버에서 내려주는 콘텐츠에 따라 다양하게 UI가 선택되어 바뀌는 형태를 많이 띄는 편입니다.
저의 경우 한번 배포한 앱들은 전반적인 UI를 크게 변경하지 않는 편이라 자주 데이터를 변경할 일은 없지만, 만약 데이터가 변경된다고 하면 각 UI 별로 버전을 명시하여 버전별 처리를 하도록 합니다.
만약 네이티브에서 정의된 버전이 아니라면 기본 Default UI를 보여주는 형태로 방어코드를 작성하구요 🙂 도움이 되셨길 바래요!
안녕하세요 해당 질문과 비슷한 질문인데
화면을 그릴 때 해당 화면에 진입할때 마다 API 를 통해서 그려질 데이터를 서버에서 받아오시나요 ? 서버에서 UI 데이터를 가져와 디비에 저장한다고 하셨는데 데이터가 변경되거나 하면 버전을 구분해서 업데이트 하는 형태일까요 ?