สีแบบไดนามิกและธีมสว่าง/มืดแบบปรับตามบริบท

Material 3 introduced dynamic color: an app's palette can be derived from the user's wallpaper (Android 12+) so your UI feels personal and native to the device.

• On supported devices, the system exposes a ColorScheme sourced from the wallpaper.
• On older devices or other platforms, you fall back to a brand seed color.
• The same logic must produce both a light and a dark scheme.

In this lesson you'll wire up dynamic color, build adaptive light/dark themes, and let the system decide which one to show.

Even with dynamic color, you always need a fallback. Material 3's ColorScheme.fromSeed generates a full, accessible palette from a single seed color.

• Pass brightness to get the matching light or dark variant.
• The generated scheme guarantees correct contrast between roles like primary and onPrimary.

A ThemeData wraps a ColorScheme plus typography and component styles. With Material 3 you set useMaterial3: true and feed in the scheme.

• Create one ThemeData per brightness.
• Keep them consistent by deriving both from the same seed.

MaterialApp accepts both a theme (light) and a darkTheme. The themeMode property decides which is active.

• ThemeMode.system follows the OS setting automatically.
• ThemeMode.light / ThemeMode.dark force a mode (useful for an in-app toggle).

With ThemeMode.system, Flutter switches seamlessly when the user flips dark mode in their device settings.

The dynamic_color package exposes the wallpaper-based palette via the DynamicColorBuilder widget. Its builder gives you optional light and dark ColorSchemes.

• If the device supports dynamic color, both schemes are non-null.
• If not, they are null and you fall back to your seed.

When you blend dynamic wallpaper colors with your brand color, the two can clash. The harmonize helpers shift a custom color toward the dynamic primary so accents feel cohesive.

• Use harmonizeWith on a Color against the scheme's primary.
• This keeps custom semantic colors (success, warning) on-brand with the wallpaper.

For themes to adapt, widgets must read semantic roles from Theme.of(context).colorScheme instead of hard-coded colors.

• scheme.primary with scheme.onPrimary for prominent actions.
• scheme.surface with scheme.onSurface for backgrounds and text.
• scheme.surfaceContainerHighest for subtle cards.

Because these roles flip with brightness, your widgets become light/dark agnostic automatically.

The decision logic for which scheme to use is plain Dart. Here is a tiny, runnable model of the fallback rule: prefer the dynamic scheme, otherwise use the seed-derived one.

• This mirrors the lightDynamic ?? lightScheme pattern.
• No Flutter widgets needed — just the selection rule.

Users often want to override the system. Store a ThemeMode in state and pass it to MaterialApp. A ValueNotifier is a lightweight way to rebuild on change.

• Default to ThemeMode.system so wallpaper/dark-mode still apply.
• Let the toggle pick light, dark, or back to system.

Inside widgets you sometimes need to know which mode is actually rendering (for example, to pick a different illustration). Read it from the active theme, not from the device, because an in-app toggle may override the system.

• Theme.of(context).brightness reflects the resolved theme.
• Avoid MediaQuery.platformBrightnessOf when a toggle can override it.

Always verify your UI in both schemes before shipping. Two practical habits:

• Toggle dark mode in the device/emulator settings to confirm ThemeMode.system reacts.
• Temporarily force themeMode: ThemeMode.dark to catch hard-coded colors and low-contrast text.

Common bugs: a hard-coded Colors.black text that vanishes on a dark surface, or a custom accent that never harmonized with the dynamic palette.

You want your app to automatically match the user's wallpaper-based dynamic colors AND follow their OS light/dark setting, while still allowing an optional in-app override later. What is the right baseline configuration?

You built a palette that adapts to both wallpaper and brightness:

• Seed fallback: ColorScheme.fromSeed for light and dark when dynamic color is unavailable.
• Dynamic color: DynamicColorBuilder supplies wallpaper schemes, with ?? seedScheme fallback.
• Harmonization: blend brand and custom colors toward the dynamic primary.
• Semantic roles: read colorScheme roles instead of hard-coded hex so widgets flip automatically.
• Mode control: themeMode: ThemeMode.system by default, with an optional ValueNotifier toggle.

Adapt to the user, fall back gracefully, and never hard-code a color you could read from the scheme.