Seminar Week 5 Summary
本页目录· 98 条
- 本周在课程中的位置
- 这周真正解决的问题
- Navigation 是什么,为什么重要
- 基本定义
- 为什么导航是核心 UX 组件
- 复习时要抓住的一句话
- Material Design 3 中的导航思路
- 课程这周聚焦什么
- Material 3 推荐的导航类型
- 设计建议:不同窗口大小对应什么导航
- 课堂强调的实际结论
- Material Design Expressive:不只是“能用”,还要“自然、吸引人”
- 它是什么
- 可以这样理解
- 图示真正想表达什么
- Navigation Bar 与 Navigation Rail
- 导航栏(Navigation Bar)
- 它是什么
- 关键特点
- 设计含义
- 当前页面如何被标识
- 导航轨(Navigation Rail)
- 它是什么
- 关键特点
- 两种形态
- 重点区别
- 本周最重要的实现框架:Compose Navigation 三件套
- 总览
- Compose 前后有什么变化
- 1. NavController:导航的大脑
- 它负责什么
- back stack 要怎么理解
- 为什么它是“有状态”的
- 如何获取 NavController
- 这行代码意味着什么
- 如何拿到当前页面
- 这两步在做什么
- 复习重点
- navigate():真正发起跳转的地方
- 这段配置在解决什么问题
- 为什么这里看起来不像普通 Kotlin 调用
- 本节一句话总结
- 2. NavHost:所有 screen 的容器
- 它是什么
- 可以这样理解
- NavHost 需要哪些核心参数
- 核心参数解释
- composable(route) { ... } 在做什么
- 本节一句话总结
- 3. Navigation Graph:应用的“地图”
- 它是什么
- 它出现在哪里
- 为什么 destination 常常用固定结构表示
- 复习时最该记住的点
- Scaffold + NavigationBar:手机导航最常见的实现骨架
- 整体结构
- 这说明了什么
- NavigationBarItem 的关键参数
- 最常见的实现流程
- 简化版骨架示例
- 这段结构最值得背下来的原因
- 多屏之间的数据共享:为什么要用 ViewModel
- 问题从哪里来
- ViewModel 的作用
- 课件中的示例
- 这表示什么
- 多屏共享状态的典型方式
- 数据录入页
- 数据展示页
- 可以这样理解
- ViewModel 和 remember 的区别
- 本周要特别分清的一点
- 协程(Coroutines)与可展开导航轨:本周只做轻量接触
- 为什么会提到协程
- DrawerState 的创建方式
- 为什么需要 rememberCoroutineScope()
- 常见写法
- 这一块的学习重点
- 从设计到实现:本周建议你这样组织脑子里的知识
- 一条完整链路
- 第一步:先想“有哪些顶层 destination”
- 第二步:确定手机上用什么导航模式
- 第三步:定义 destination 结构
- 第四步:创建 NavController
- 第五步:在 Scaffold 中放入 NavigationBar
- 第六步:用 NavHost 注册所有 screen
- 第七步:如果多屏共享数据,再引入 ViewModel
- 本周最容易混淆的点
- 1. Navigation Bar 不是随便放几个按钮
- 2. NavController 和 NavHost 不是一回事
- 3. Navigation Graph 也不是单独页面
- 4. launchSingleTop = true 很重要
- 5. ViewModel 不是数据库
- 6. Drawer/Navigation Drawer 相关老资料要谨慎看
- 对作业和实验的实际启发
- 这周内容会直接影响什么
- 课堂上反复暗示的设计标准
- Summary
ChatGPT 说
本周在课程中的位置
- 前几周的 Jetpack Compose 学习,重点更偏向单一屏幕(single screen)里的组件摆放、状态更新和基础交互。
- 本周开始,课程从“单页 UI”进入“多屏幕应用结构”:
- 不只是把组件画出来;
- 而是要思考不同 screen 之间怎么连接;
- 用户如何在功能之间移动;
- 页面之间的数据怎么共享。
- 这也是后续内容的桥梁:
- 下一阶段会继续结合 Material Design 3(M3) 的设计原则;
- 后面还会接上 ViewModel、协程(Coroutines)、Room 数据库、Retrofit/API,把导航、状态、数据持久化和网络访问串成完整 App 架构。
这周真正解决的问题
- 一个 App 不可能永远只有一个页面,所以必须回答:
- 用户现在在哪?
- 用户可以去哪?
- 用户怎么返回?