What is the best way to add a transition when changing themes?

For example, if I have a light and dark theme, and would like it to fade between the two when the ThemeManager.shared.currentTheme is changed.

I am currently doing the following:

view.use(MyTheme.self) { (view, theme) in
    UIView.animate(withDuration: 1.0, animations: {
        view.backgroundColor = theme.backgroundColor
    })
 }

but would like to avoid having UIView.animate in every screen, as I'd like this behavior on all attributes.

Firstly, thank you for this project.

I found it quite difficult to understand the usage and design of this framework, without having to go in to the code. Mostly, this was due to the framework's current naming practices.

For example, I didn't know what a "Manager" was. Was it app-dependent? View-Controller dependent? What does it "manage"?

To that end, I suggest changing the name to "ThemeManager" or "ThemesManager". And/or use a prefixing scheme.

e.g. OMYThemesManager

Similarly, the use of "theme()" is very problematic. e.g. given the following code:

theme(MyTheme.self) {
    // ...
}

Some questions I had: where did this seemingly global method come from? What does it do? Am I creating a theme? Am I setting a theme? I have to use a "Manager" at one point, but I don't use Manager to set the theme? So if I don't have to use the Manager, and I have a theme, why don't I just call myTheme.set() ? Who does "theme()" belong to? Is it local, global? Part of a framework? etc. And why am I giving it a "MyTheme.self"? What is the action that occurs? These important questions can't be answered by the current naming scheme.

Upshot: please consider renaming the API to use clearly readable nouns and verbs. The goal should be to make it crystal clear what any method/class will do.

This problem also occurs in the Read Me example. You use a type called "MyTheme". This indicated to me that it was a one-off; a particular instance of a theme. In reality, it turned out to be a general type, designed for (possible) multiple use.

It's hard to think of a good naming system for this kind of protocol adoption. The goal is to make it clear that the type itself is not the theme.

Perhaps something like a "Template", which indicates that any given struct is designed for multiple use.

e.g. given a project of name "Project":

struct OnboardingThemeTemplate: OMYTheme {
  let topImage: UIImage
  let cellColor: UIColor
  let backgroundColor: UIColor
  let name: String
  let titleFont: UIFont
  let subtitleFont: UIFont
}

struct FeedbackThemeTemplate: OMYTheme {
  let backgroundColor: UIColor
  let name: String
  let titleFont: UIFont
  let subtitleFont: UIFont
}

struct ProjectThemes {
  static let onboarding = OnboardingThemeTemplate(...)
  static let mailFeedback = FeedbackThemeTemplate(...)
  static let twitterFeedback = FeedbackThemeTemplate(...)
  static let facebookFeedback = FeedbackThemeTemplate(...)
}

Or something like that. Hopefully you get the idea; a clear separation and identification of framework naming and other code.

IMO, you should err on the side of readability, comprehension, rather than brevity and minimalism.

Thank you.

Hello, I think you remove your pod 'On'. It results in failing to run the example. Anw, I know how to use this pod without running the example. Thank you for your great effort.

I added Themes to my project and I noticed that the latest version on CocoaPods is not 2.0.0.

Do you plan on continuing supporting this project / keep CocoaPods up to date?

Lets say a user selects a dark theme. When the user exits the app and relaunches, the theme resets to whatever is in code.

Would be nice if the user's preference was persistence without the need for further implementations. I believe Themeable does this and would make a great feature.