降Compose十八掌之『密云不雨』| Navigation

公众号「稀有猿诉」        原文链接 降Compose十八掌之『密云不雨』| Navigation

除了一些玩具性的Demo以外,相信任何一个应用程序不可能只有一个页面,最为极简的应用也至少会有两个页面,一个主页和一个设置页。对于传统的View系统来说对于导航这块没有专门的API,一般都是自己写逻辑跳Activity,或者跳到Fragment,然后再反向的Back,所以有了很多三方的各种Router类库(如大阿里的ARouter,货拉拉的TheRouter)。其实谷歌已经提供了解决方案,在Jetpack中提供了Navigation组件,专门用于解决应用内部各种页面之间跳转的问题。

banner

对于Jetpack Compose来说,因为是全新的框架,在设计之初就考虑到了导航的问题,但也不是重新开发了一套新库,而是把Jetpack中的组件Navigation深度的结合了进来。换句话说,在Jetpack Compose中可以直接使用Navigation组件来进行页面之间的跳转,并且有非常符合Compose的粘合API,使用起来非常的丝滑顺手。

基本概念

在深入之前有必要先澄清Navigation中的一些概念,了解了一些基本的概念和术语之后,会有助于理解组件的设计理念,也会更容易上手使用。

术语用途具体的Composable
Host包含了当前导航页面的容器。应该把它理解成为导航的容器,包含着当前的页面, 以及一个NavController。NavHost
Graph静态的数组结构,定义着一个应用中的所有页面,以及它们之间应该如何跳转。NavGraph
Controller页面之间导航的核心管理者。它封装着如何在页面之间跳转的方法,处理链接的方法,以及返回堆栈的方法。NavController
Destination在Graph中的一个节点。当跳转到这个节点时,Host中就包含并展示它的页面。在实际项目中,往往是一个Fragment或者一个Composable,也就是一个页面。NavDestination
RouteDestination的全局唯一标识,包括其所需要的参数。大部分时候,特别是在Compose中,这就是一坨类似于Uri一样的String

还需要说明一下的就是导航的基本的操作对象是一个页面,一个页面可以理解为一个全屏的,逻辑上内聚,内容上互相关联,自成一家的一个UI页面,比如说一个应用的主页是一个页面,文章列表是一个页面,文章详情是一个页面,设置是一个页面,用户页又是一个页面。当然,这里全屏并不是直观的全屏,意思是说(特别是对于Compose)一个页面的大小是受系统控制的,并不能像普通的Composable那样随意设置大小,对于手机就是全屏的,对于平板可能会一个占据三分之一(列表页),一个占据三分之二(详情页)。

使用Navigation

Jetpack Compose是声明式UI,是函数式编程,每一个Composable都是一个函数,所以在Compose中使用Navigation略微的有点不一样。核心原理和核心的规则肯定与Navigation是一样一样的,只是使用上的API略不一样,其实是更简单更方便了(这是声明式UI带来的收益)。

添加依赖

在使用之前先要添加Navigation库作为项目的依赖:

dependencies {
    val navVersion = "2.7.7"
    implementation("androidx.navigation:navigation-runtime-ktx:$navVersion")
    implementation("androidx.navigation:navigation-compose:$navVersion")
}

使用Navigation的方法

可以通过以下步骤来使用Navigation:

  • 创建NavHost,并设置为应用的入口,通过Composable函数NavHost
  • 创建NavController,可以直接创建,但推荐的方式是使用Compose提供的状态构造函数rememberNavController,它的好处在于当前导航会提升为一个状态。
  • 定义Destination和Route,其实对于Compose来说都是用类似于Uri的String来作为Destination,每一个Destition唯一对应着一个页面。
  • 添加页面,通过函数NavHost的尾部lambda,它实际上是一个NavGraphBuilder的扩展函数,这里调用函数composable来添加页面。
  • 配置跳转,通过前面创建的navController来实现跳转,用navController.navigate来跳转到指定的Destination,用navController.popBackStack来返回到前一个页面。而触发的入口肯定是在具体的页面之中,所以页面要把其跳转函数作为参数,在NavGraphBuilder时,再用NavController去实现,这样所有的跳转逻辑就都在NavGraph中,便于管理。

具体实例

说了那么多貌似挺烦杂的,让我们看一个实例就会瞬间明白。

一个简单的应用有4个页面,先定义Destinations:

object Destinations {
    const val APP_URI = "http://toughcoder.net/chronos"
    const val HOME_ROUTE = "home" // 主页
    const val HISTORY_ROUTE = "history" // 历史记录页面
    const val SETTINGS = "settings" // 设置页
    const val ARTICLES = "articles" // 文章页
}

那么就可以如此配置Navigation:

@Composable
fun ChronosNavGraph(
    modifier: Modifier = Modifier,
    navController: NavHostController = rememberNavController(),
    start: String = Destinations.HOME_ROUTE // 默认的初始页面为主页
) {
    NavHost(
        modifier = modifier,
        navController = navController,
        startDestination = start
    ) {
        composable(
            route = Destinations.HOME_ROUTE,
            deepLinks = listOf(
                navDeepLink { uriPattern = "${Destinations.APP_URI}/${Destinations.HOME_ROUTE}" }
            )
        ) {
            ChronosScreen(
                gotoSettings = { navController.navigate(Destinations.SETTINGS) },
                gotoHistory = { navController.navigate(Destinations.HISTORY_ROUTE) },
                gotoArticles = { navController.navigate(Destinations.ARTICLES) }
            )
        }

        composable(
            route = Destinations.HISTORY_ROUTE,
            deepLinks = listOf(
                navDeepLink { uriPattern = "${Destinations.APP_URI}/${Destinations.HISTORY_ROUTE}" }
            )
        ) {
            HistoryScreen(
                viewModel = viewModel()
            ) {
                navController.popBackStack()
            }
        }

        composable(
            route = Destinations.SETTINGS,
            deepLinks = listOf(
                navDeepLink { uriPattern = "${Destinations.APP_URI}/${Destinations.SETTINGS}" }
            )
        ) {
            SettingsScreen(
                viewModel = viewModel()
            ) {
                navController.popBackStack()
            }
        }

        composable(
            route = Destinations.ARTICLES,
            deepLinks = listOf(
                navDeepLink { uriPattern = "${Destinations.APP_URI}/${Destinations.ARTICLES}" }
            )
        ) {
            ArticlesScreen(
                viewModel = viewModel()
            ) {
                navController.popBackStack()
            }
        }
    }
}

可以看到每一个composable函数用以创建一个导航页面,里面有其Route,具体的页面,以及跳转的入口函数。deepLinks是每个页面的Uri式的链接,后面会详细的讲解。

最后就是把这个NavGraph作为应用的入口页面:

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            ChronosTheme {
                Surface(
                    modifier = Modifier.fillMaxSize(),
                    color = MaterialTheme.colorScheme.background
                ) {
                    ChronosNavGraph()
                }
            }
        }
    }

在页面之间传递参数

页面跳转还必然会涉及参数的传递,比如具有递进关系的两个页面,核心参数肯定要由前一个页传递过去,最为典型的场景就是列表类页面到详情页面的跳转,比如文章列表要把文章的Id传给详情页,这样详情页才知道去展示哪个文章,用户列表要把用户Id传给详情页,详情页才知道展示哪个用户。

Navigation提供了传递参数的方法,在创建导航页面时传入的Route可以加入占位符形参,然后在跳转navController.navigate时可以传入实参,只不过参数的类型有限制,只能是基础数据类型如字串或者数字。目标页面使用时通过backStackEntry.arguments来获得参数。来具体看一下,比如说传递用户Id的场景:

NavHost() {
    composable(
          "profile/{userId}",
          arguments = listOf(navArgument("userId") { type = NavType.StringType } // 这句可以省略,因为默认类型都当成是字符串
    ) { backStackEntry ->
          Profile(navController, backStackEntry.arguments?.getString("userId"))
    }
}

上面参数类型的声明,其实可以省略,因为默认的类型都当成String来解析和处理,如果是其他类型则需要显式地声明。这样目标页面的参数就声明好了,我们在跳转的时候传入实参就可以了:

navController.navigate("profile/user1234")

大部分时候参数都是必填参数,像上面这样写userId是必填的参数。但有些时候一些非核心的参数,可能不是每次跳转都会传,这就需要页面把参数声明为可选参数。可选参数在声明的时候Uri中必须使用查询式语句,如(“?argName={argName}”),另外必须 设置默认值,或者类型是nullable的。这也意味着我们不能省略导航页面构建composable函数中的arguments参数:

composable(
    "profile?userId={userId}",
    arguments = listOf(navArgument("userId") { defaultValue = "user1234" }) // 注意这里的默认值,当调用navigate时如果不传userId就用这个默认值
) { backStackEntry ->
    Profile(navController, backStackEntry.arguments?.getString("userId"))
}

注意: 要尽可能的使用基本的数据类型,如String,Int或者Long,而不传递复杂的数据。复杂的数据通常都是业务逻辑数据,而业务逻辑数据应该使用基本的参数,再从数据源处(通常是通过ViewModel从Repo处)去主动获取,这样才能保证数据的真实有效。这是设计原则中的『单一数据源原则Single Source of Truth』。复杂数据从Repo处获取后,可能会变得过时或者失真,而且在页面之间传递会有拷贝,效率也不高,因此要避免在页面之间传递复杂数据。

处理DeepLinks

DeepLinks是Uri式的链接跳转范式,能够以字符串形式的Uri精准的定位到某个应用的具体某个页面,就犹如互联网中的Uri一样。它的好处在于形成了一个统一的标准,形式简单方便,一个字符串就能定位到一个页面。

使用导航页面构建函数composable在构建页面的时候可以传入NavDeepLink对象,更为方便的是使用其构建函数navDeepLink

val uri = "https://www.example.com"

composable(
    "profile?id={id}",
    deepLinks = listOf(navDeepLink { uriPattern = "$uri/{id}" })
) { backStackEntry ->
    Profile(navController, backStackEntry.arguments?.getString("id"))
}

从示例中可以看出Uri中还可以带有参数,形参的声明,以及参数的获取与前面提到的页面参数是一样一样的,如果实际传过来的Uri是"https://www.example.com/user123",到此页面后,就能解析出参数id为user123。

正常情况下这些DeepLinks只能在应用内部使用,如果要对应用外开放,则需要在应用的AndroidManifest文件中进行声明,声明为intent filter:

<activity >
  <intent-filter>
    ...
    <data android:scheme="https" android:host="www.example.com" />
  </intent-filter>
</activity>

页面跳转过渡动画

页面跳转可以指定具体的过渡动画,具体的可以参考前面专门讲动画的那篇文章,这里就不再重复了。

Route的类型安全

通常情况下Route都是使用Uri式的String,但这明显不够安全,因为调用navController#navigate的时候,可能会传一个不认识的页面Route,或者参数传错了(比如数字参数传了String),等等。轻则跳转失败,因为找不到Destination页面,重则会Crash。要想类型安全,就不能使用String式的Uri,需要把Ruote定义为类型(也即class),但要使用注解@Serializeable标记一下:

// 主页面,不带任何参数
@Serializable
object Home

// 用户页面,参数是用户Id,其类型是一个String
@Serializable
data class Profile(val id: String)

然后在构建导航页面的时候,函数composable其实是一个泛型函数,它可以指定Route的参数类型:

NavHost(navController, startDestination = Home) {
     composable<Home> { // 泛型函数,可以指定参数类型
         HomeScreen(onNavigateToProfile = { id ->
             navController.navigate(Profile(id)) // 跳转的时候传入的实参是一个对象,类型就是上面定义的Route
         })
     }
     composable<Profile> { backStackEntry ->
         val profile: Profile = backStackEntry.toRoute()  // 获取参数的时候,用toRoute来获得Route对象,类型就是我们定义的那个
         ProfileScreen(profile.id)
     }
}

然后在跳转的时候就可以把Route对象作为实参传进去:

navController.navigate(Profile(id = 123))

这样因为都是定义的类型,所以编译器会做编译时检查,虚拟机也会做运行时的类型检查,保证类型安全。

注意: 不要混淆,这里Route虽然是自定义类型,但并不算是在页面之间传递复杂的业务数据,因为具体的参数仍是诸如String和Int之类的基础数值。把Route定义为类型(class),而不是直接使用String,是为了让编译器帮忙我们保证类型安全,减少出错。

总结

使用Navigation可以非常轻松的把应用的各个页面组织连接起来,形成一个完整的交互闭环。谷歌也提供了相应的CodeLab可以学习一下。此外,谷歌的一些Sample app,像SunflowerJetNews也是使用Navigation来实现导航的,是非常好的学习案例。

References

subscription

欢迎搜索并关注 公众号「稀有猿诉」 获取更多的优质文章!

保护原创,请勿转载!

  • 11
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值