Road to Single Activity

Over the last few years, the number of projects using Jetpack Compose is increasing. Our project at U-NEXT is one example: we previously used AndroidView to build our UI, but we recently adopted Compose and revamped our UI architecture, including the screen transition mechanism, by using Navigation Compose. However, we faced several problems afterwards. Specifically, our app uses a Navigation Bar/Rail with separate tabs (Top-level Destinations) for each major function, so the NavGraph is divided into those units. However, due to the specifications allowing each function to closely collaborate with each other, screen transitions across functions occur frequently. Furthermore, some of these screens are called by deep links, so the screen transitions are very complex. Until now, this problem was solved by sharing such screens between multiple Activities, but this required reconfiguring Local Composition and having a NavGraph for each Activity, which increased operational costs. Therefore, we decided for such cases to abandon the solution of using Activities sharing screens, and instead took another step in revamping the UI architecture by making full use of Navigation Compose, aiming for a Single Activity. In this session, based on examples from our own projects, I will introduce the following points in detail, with a focus on how to use Navigation Compose. - How to gradually migrate UI architecture from AndroidView to Compose - Examples of app development with complex screen transition specifications Keywords - Navigation Compose - Nested NavGraph - Common NavGraph - Type safe navigation - Default argument - Multi back stack management - Top-level Destination’s back stack management - Navigation Bar/Rail control with WindowInset consideration - Screen Transition by Deep links - Compose Destinations (OSS) (Translated by the DroidKaigi Committee)

• 

  yurihondo U-NEXT Co., Ltd.