-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dynamic_color: Add a method to check whether the platform supports dynamic theming #390
Comments
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. |
@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 It'd be nice to have a method (ideally synchronous) that would only check without generating anything. |
To resolve that I think you can use a state management solution like, for instance, 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());
}
This should be possible using the above naive solution as base since you can now access synchronously your notifier instance.
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.
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. |
@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 |
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! 🎉 |
I have the exact same issue and would love a simple method to check if dynamic colors are available. |
I agree as well, that would be great. |
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.
The text was updated successfully, but these errors were encountered: