Store setThemeData value in the shared preferences.

[hupo376787]

As when changing the brightness with setBrightness, it is additionally stored in the shared preferences.

So I think it's necessary to do the same for setThemeData

[sjmcdowall]

Why? Themedata is (should be) generated (and regenerated) when the Brightness is set. Generally via a function call in the "data:" option. So I don't see how this is needed?

[Aqluse]

@sjmcdowall You're right, but there could be more than 2 themes, so better to be able to handle this case

[sjmcdowall]

I am not sure what you mean -- how can there be more than 2 themes? And in any event -- the logic (whatever it is) in the data: function should / needs to be able to regenerate the theme given the input.

[Aqluse]

@sjmcdowall I mean in-app themes, I already saw apps that have more than 2 themes though

Google limit theme diversity for some reason, required MaterialColor in ThemeData and applience of all of these values is some hell of a magic

[hupo376787]

Hi， some apps may have several color themes for users to select.

[Norbert515]

IMO having more than just the brightness saved to shared preferences makes sense.
One questions that need to be addressed is:

• How is storage managed/ what is stored?

[sjmcdowall]

@Norbert515 -- Excellent questions ... and I don't think easy to answer .. without opening up a "can of worms" as to the interface into DynamicTheme as to what to save .. the how? Probably some JSON string of the other theme elements that are desired to be saved.. but this isn't needed for everyone so it somehow needs to be optional. For example, in our app we can easily (because there aren't any options besides Dark/Light) re-create our entire ThemeData in our Theme generator function just based on the Dark/Light flag. We actually wouldn't want anything to be saved since if we wanted to change the theme logic -- we would want it to be dynamic with next download/launch and not be saved..

But -- for more complex Themes that need additional input .. I would somehow thing about storing the minimum "flags" needed to be able to recreate the ThemeData from a function instead of trying to save the actual ThemeData itself?

[Norbert515]

What I also noticed - a lot of people come up with their own theme-management system because the MaterialTheme doesn't provide the flexibility/ ease of use.

I thought about making a package which helps set up a custom theme system (managing the InhertitedWidget, lerping and accessing it) a couple of weeks ago (maybe via code generation or something else).

I think having something like that combined with this dynamic theme package would make a lot of sense because you'd be able to specifically choose which properties should be changeable/ saved.