Pull to refresh

Comments 13

1 — а зачем создавать оба инстанса UIColor, если будет использован только один?
2 — касательно проекта-примера на гитхабе. Имхо, я бы не использовал глобальные константы, а добавил екстеншен к UIColor.
например.
extension UIColor
{
    @nonobjc class var backgroundSecondary: UIColor
    {
        return SchemeColor(classic: BACKGROUND_SECONDARY_COLOR_CLASSIC,
                           dark: BACKGROUND_SECONDARY_COLOR_DARK).color()
    }
}
navigationController?.navigationBar.barTintColor = .backgroundSecondary 

вместо
let backgroundSecondaryColor = SchemeColor(classic: BACKGROUND_SECONDARY_COLOR_CLASSIC,
                                           dark: BACKGROUND_SECONDARY_COLOR_DARK)
 navigationController?.navigationBar.barTintColor = backgroundSecondaryColor.color()
Насчет второго пункта – согласен, красивый путь, понравился!

А первый не вполне понял. Это о struct ButtonAppearanceLight и struct ButtonAppearanceDark?
А как предлагаете сделать? SchemeColor в данном случае же и предназначен, чтобы принимать в себя возможные цвета определенного элемента и возвращать нужный в зависиомсти от используемой цветовой схемы.
если сильно заморочится, то будет как-то так
protocol ColorTheme {
    var main: UIColor { get }
}

struct DarkTheme: ColorTheme {
    var main: UIColor {
        return .black
    }
}

struct ClassicTheme: ColorTheme {
    var main: UIColor {
        return .white
    }
}



final class ColorScheme {
    
    // MARK: - Properties
    static let shared = ColorScheme()
    var theme: ColorTheme
}


далее в ините можно сетапить нужную тему, тогда и Option не надо.

extension UIColor
{
    @nonobjc class var backgroundSecondary: UIColor
    {
        return ColorScheme.shared.theme.main
    }
}

а если смущает правило 3 точек, то тогда уже theme можно сделать fileprivate

extension ColorScheme: ColorTheme {
    var main: UIColor {
        return theme.main
    }
}

extension UIColor
{
    @nonobjc class var backgroundSecondary: UIColor
    {
        return ColorScheme.shared.main
    }
}

Жаль, что вас не смущает дублирование кода в структурах ButtonAppearanceLight и ButtonAppearanceDark. По хорошему вам нужна одна структура ButtonAppearance и в ней свойства должны быть не static-ами. А в энуме ColorSchemeOption к кейсам (которые, кстати, Apple рекомендует называть НЕ капсом) добавить associatied value типа ButtonAppearance (внезапно, да?) Чтоб получилось что-то типа такого:


enum ColorSchemeOption {
    case dark(buttonAppearance: ButtonAppearance)
    case light(buttonAppearance: ButtonAppearance)
}
Как быть, если один и тот же цвет назначается на разные элементы в разных экранах? К примеру есть ГлавныйЦветКнопкиОтмена и этот же цвет используется для других контролов. Если дублировать цвета под разными названиями может образоваться очень много переменных с одинаковым цветом и при большом количестве экранов превратится в адский ад
Как справляетесь с этим? Лично я для себя ничего лучше, чем долгое я мучительное раздумье по поводу названия цветовых констант не придумал: делить элементы на группы, подгруппы и т.д. и называть их в духе materialized path.
А и не надо пытаться все стандартизировать, это путь в никуда. Полностью согласен с Tereks.
Я для себя решил, один цвет — одна константа. А дальше уже на уровне контролов разруливаешь какой цвет использовать. Когда приходится перекрасить все приложение, всплывает куча приколов от дизайнеров, что в темной теме у нас тут так, а в светлой сяк, и ты как ни разбивай, все равно без костылей или овердублирования не обойтись.
А так, проходишься по всем классам контролов, и если надо по некоторым вьюконтроллерам, меняешь где надо ручками с одной цветовой константы на другую. Супер гибко, кода минимум, и на приложении с полусотней экранов и парой десятков ячеек занимает максимум день.
А как наиболее оптимально реализовать изменение цвета, например, UILabel в зависимости от темы — Светлая или Темная? Если используется цвет не по умолчанию.
Sign up to leave a comment.

Articles