SPEAKER NOTES:
Welcome to Week 7! Today we connect two essentials for the Hope Foundation golf app: grid layouts for quick selection and navigation for multi‑screen flows.
SPEAKER NOTES:
We’ll start with grids for layout and end with screen‑to‑screen navigation. Quiz reminder at the end.
SPEAKER NOTES:
Grids are perfect for quick, visual selection in the golf app: hole numbers, teams, or score actions.
SPEAKER NOTES:
Let’s reason about when grid layouts make sense.
SPEAKER NOTES:
Example: selecting a hole number or quick actions.
SPEAKER NOTES:
Phones are narrow, but grids help us use width for faster scanning.
SPEAKER NOTES:
Users can scan a 3x6 grid of holes faster than a 18‑row list.
SPEAKER NOTES:
Think of a “Tournament Hub” screen with quick actions.
SPEAKER NOTES:
Fixed columns are predictable: 3 columns across on phones for 18 holes.
SPEAKER NOTES:
Adaptive columns let the device size decide how many columns fit.
SPEAKER NOTES:
Use a dedicated tile composable for reuse and clean grid code.
SPEAKER NOTES:
Spacing creates visual rhythm. Without it, tiles look cramped and hard to tap.
SPEAKER NOTES:
Let’s avoid the most common issues that make grids feel broken or slow.
SPEAKER NOTES:
Keys prevent state leaks when the list changes.
SPEAKER NOTES:
Aim for at least 48dp touch targets.
SPEAKER NOTES:
Avoid decoding images or doing complex calculations inside each tile.
SPEAKER NOTES:
Use `Scaffold` padding or `WindowInsets` so content isn’t hidden behind bars.
SPEAKER NOTES:
Now we connect screens: dashboard → hole detail → team summary.
SPEAKER NOTES:
A single screen can’t handle the entire tournament workflow.
SPEAKER NOTES:
Each screen does one job well.
SPEAKER NOTES:
Users expect Android back to work across the app.
SPEAKER NOTES:
We can navigate straight to “Hole 7” from a notification.
SPEAKER NOTES:
Each screen owns the state it needs.
SPEAKER NOTES:
There are four core concepts you must know.
SPEAKER NOTES:
The controller performs navigation actions.
SPEAKER NOTES:
The host displays the current destination.
SPEAKER NOTES:
The graph defines all destinations and routes.
SPEAKER NOTES:
Each destination is a composable function.
SPEAKER NOTES:
This is the minimal setup: controller + host + routes.
SPEAKER NOTES:
Arguments let us navigate to a specific hole detail screen.
SPEAKER NOTES:
Build the route string using the argument value.
SPEAKER NOTES:
The string-based routes we just saw work, but they're error-prone. Type-safe navigation using serializable data classes gives us compile-time safety.
SPEAKER NOTES:
Let's understand the benefits of the modern navigation approach.
SPEAKER NOTES:
No more typos in route strings causing runtime crashes.
SPEAKER NOTES:
Arguments are part of the data class, so you can't pass the wrong type.
SPEAKER NOTES:
All routes live in one sealed class, making them easy to find and refactor.
SPEAKER NOTES:
Your IDE can help you navigate correctly with autocomplete on route names.
SPEAKER NOTES:
Each route is a serializable data class or object. Arguments become properties.
SPEAKER NOTES:
Notice we use Routes.Home directly instead of a string. Type-safe at the start destination.
SPEAKER NOTES:
The toRoute() extension extracts our typed route object. No manual parsing of arguments!
SPEAKER NOTES:
Creating the route is just creating a data class instance. The compiler ensures you provide all required arguments.
SPEAKER NOTES:
Here's a complete example for a pet adoption app. Three screens with type-safe routes.
SPEAKER NOTES:
The list screen navigates to detail, passing the pet ID in a type-safe way.
SPEAKER NOTES:
Extract the route, use its properties, and navigate forward to adoption or back to list.
SPEAKER NOTES:
Same pattern: extract typed route, use the arguments. Clean and type-safe throughout.
SPEAKER NOTES:
For small apps, strings work. For production apps with many screens, type-safe navigation prevents bugs.
SPEAKER NOTES:
Don't forget to add the serialization plugin and dependency for type-safe navigation to work.
SPEAKER NOTES:
Use this for back actions on app bars or buttons. Works the same for both navigation approaches.
SPEAKER NOTES:
Compose doesn’t handle back automatically for custom app bars. We wire it.
SPEAKER NOTES:
Navigation issues are often subtle. Watch for these.
SPEAKER NOTES:
A mismatch between "hole/{id}" and "holes/{id}" will crash.
SPEAKER NOTES:
If a route expects an argument, the navigation call must include it.
SPEAKER NOTES:
Keep a single controller at the app root.
SPEAKER NOTES:
Use ViewModels for heavy loading and preserve state.
SPEAKER NOTES:
Close with the connection to the Hope Foundation app and preview the demo.