dynamic_color: Add a method to check whether the platform supports dynamic theming

[12people]

Package

dynamic_color

Description

Is your feature request related to a problem? Please describe. I have dynamic theming as an option in my app. I would only like to show this option when dynamic themes are truly supported.

Describe the solution you'd like Add a "supportedByPlatform" method or something along those lines, to check whether dynamic theming is supported by the platform.

Describe alternatives you've considered I can write the logic myself, but then I'd have to integrate an extra plug-in just for this use case and would have to manually update that logic each and every time more platform support was added to dynamic_color.

[alexrintt]

As guidezpl pointed you can use the return value to check if it's supported or not; if the return is null, then it is not. Let me know if that helps or do you still need a specific API for this.

[12people]

@alexrintt Thanks for the tip!

In my case, my app defaults to a theme without dynamic colors, but rather with branded colors. Dynamic colors are just a setting users can choose — but only if dynamic colors are supported by the platform.

As such, it'd be nice to have a quick method to call whenever the user open settings, just to check whether dynamic colors are supported, and show the option based on that. As far as I understand, calling DynamicColorPlugin.getCorePalette not only checks for platform support, but also generates a color palette every time it's called if the platform is supported, right? It doesn't seem very efficient to generate this each time a user opens settings.

It'd be nice to have a method (ideally synchronous) that would only check without generating anything.

[alexrintt]

To resolve that I think you can use a state management solution like, for instance, ChangeNotifier:

class DynamicColorNotifier extends ChangeNotifier {
  DynamicColorNotifier();

  ColorScheme? darkColorScheme;
  ColorScheme? lightColorScheme;

  bool get isDynamicColorSupported => darkColorScheme != null && lightColorScheme != null;

  Future<void> initialize() async {
    final corePalette = await DynamicColorPlugin.getCorePalette();

    if (corePalette == null) return; // Not supported

    darkColorScheme = corePalette.toColorScheme(brightness: Brightness.dark);
    lightColorScheme = corePalette.toColorScheme(brightness: Brightness.light); 
  }
}

at the startup:

late DynamicColorNotifier dynamicColorNotifier;

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  dynamicColorNotifier = DynamicColorNotifier();
  await dynamicColorNotifier.initialize();

  // wherever you control you theme you can now access synchronously:
  // dynamicColorNotifier.isDynamicColorSupported
  // dynamicColorNotifier.darkColorScheme
  // dynamicColorNotifier.lightColorScheme

  runApp(YourApp());
}

---

As such, it'd be nice to have a quick method to call whenever the user open settings, just to check whether dynamic colors are supported, and show the option based on that.

This should be possible using the above naive solution as base since you can now access synchronously your notifier instance.

As far as I understand, calling DynamicColorPlugin.getCorePalette not only checks for platform support, but also generates a color palette every time it's called if the platform is supported, right? It doesn't seem very efficient to generate this each time a user opens settings.

That's right but I don't see any problem calling this often because the only async work is to call the native plugin. The palette generation is just a bunch of integers, multiplications and ephemeral object allocation. It's even more performance-friendly when you wrap it inside a class of yours that will run only at startup or whenever the device theme config changes.

It'd be nice to have a method (ideally synchronous) that would only check without generating anything.

I would agree, but not in the plugin class, it should only contain code to call the native implementation. The real problem we are facing is: where and when we call these async methods considering the app life-cycle? For that, the plugin could export a class that is be reactive and has a "init" and "dispose" functions to manage it.

---

Let me know if that helps, otherwise we can discuss another approach.

[12people]

@alexrintt I'm using Riverpod for state management. I understand that I can generate the palette there, but in general my issue is that I'd still be generating a palette that I wouldn't be using in most circumstances.

(Since dynamic colors aren't my app's default, most users won't see them even if they are on supported devices.)

I know that it's not a particularly complex operation, but in general I prefer to only run code that will be used in some way. I guess I don't understand why the plug-in can't just expose the DynamicColors.isDynamicColorAvailable() method that it uses itself.

[12people]

BTW, I just want to say that, no matter the resolution of this issue, I really, really appreciate the work that you're doing on this plug-in! Thank you so much!

And I hope you enjoy the holidays! 🎉

[maelchiotti]

I have the exact same issue and would love a simple method to check if dynamic colors are available.

[Henry-Hiles]

I agree as well, that would be great.