Comments 13
1 — а зачем создавать оба инстанса UIColor, если будет использован только один?
2 — касательно проекта-примера на гитхабе. Имхо, я бы не использовал глобальные константы, а добавил екстеншен к 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()
+1
Насчет второго пункта – согласен, красивый путь, понравился!
А первый не вполне понял. Это о struct ButtonAppearanceLight и struct ButtonAppearanceDark?
А первый не вполне понял. Это о struct ButtonAppearanceLight и struct ButtonAppearanceDark?
0
SchemeColor хранит в себе 2 UIColor.
+1
А как предлагаете сделать? SchemeColor в данном случае же и предназначен, чтобы принимать в себя возможные цвета определенного элемента и возвращать нужный в зависиомсти от используемой цветовой схемы.
0
если сильно заморочится, то будет как-то так
далее в ините можно сетапить нужную тему, тогда и Option не надо.
а если смущает правило 3 точек, то тогда уже theme можно сделать fileprivate
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
}
}
+1
Жаль, что вас не смущает дублирование кода в структурах ButtonAppearanceLight
и ButtonAppearanceDark
. По хорошему вам нужна одна структура ButtonAppearance
и в ней свойства должны быть не static-ами. А в энуме ColorSchemeOption
к кейсам (которые, кстати, Apple рекомендует называть НЕ капсом) добавить associatied value типа ButtonAppearance
(внезапно, да?) Чтоб получилось что-то типа такого:
enum ColorSchemeOption {
case dark(buttonAppearance: ButtonAppearance)
case light(buttonAppearance: ButtonAppearance)
}
+2
Я использую http://classykit.github.io/Classy/
0
Как быть, если один и тот же цвет назначается на разные элементы в разных экранах? К примеру есть ГлавныйЦветКнопкиОтмена и этот же цвет используется для других контролов. Если дублировать цвета под разными названиями может образоваться очень много переменных с одинаковым цветом и при большом количестве экранов превратится в адский ад
0
Как справляетесь с этим? Лично я для себя ничего лучше, чем долгое я мучительное раздумье по поводу названия цветовых констант не придумал: делить элементы на группы, подгруппы и т.д. и называть их в духе materialized path.
0
А и не надо пытаться все стандартизировать, это путь в никуда. Полностью согласен с Tereks.
Я для себя решил, один цвет — одна константа. А дальше уже на уровне контролов разруливаешь какой цвет использовать. Когда приходится перекрасить все приложение, всплывает куча приколов от дизайнеров, что в темной теме у нас тут так, а в светлой сяк, и ты как ни разбивай, все равно без костылей или овердублирования не обойтись.
А так, проходишься по всем классам контролов, и если надо по некоторым вьюконтроллерам, меняешь где надо ручками с одной цветовой константы на другую. Супер гибко, кода минимум, и на приложении с полусотней экранов и парой десятков ячеек занимает максимум день.
Я для себя решил, один цвет — одна константа. А дальше уже на уровне контролов разруливаешь какой цвет использовать. Когда приходится перекрасить все приложение, всплывает куча приколов от дизайнеров, что в темной теме у нас тут так, а в светлой сяк, и ты как ни разбивай, все равно без костылей или овердублирования не обойтись.
А так, проходишься по всем классам контролов, и если надо по некоторым вьюконтроллерам, меняешь где надо ручками с одной цветовой константы на другую. Супер гибко, кода минимум, и на приложении с полусотней экранов и парой десятков ячеек занимает максимум день.
0
про UIApperance ни слова :(
-1
А как наиболее оптимально реализовать изменение цвета, например, UILabel в зависимости от темы — Светлая или Темная? Если используется цвет не по умолчанию.
0
Sign up to leave a comment.
Способ управления цветовыми схемами «Swift» «iOS»-приложения