Custom Swift UIColors
Back in Swift 2, or even earlier, UIColors were class functions, called via UIColor.blackColor()
, UIColor.redColor()
, etc.
Naturally, creating a custom colour would look something like
extension UIColor {
class func facebookBlue() -> UIColor {
return UIColor(red: 59/255, green: 89/255, blue: 152/255, alpha: 1)
}
and would be called via UIColor.facebookBlue()
.
In Swift 3, default UIColors
were modified to be class properties, called via UIColor.blue
(or, if the type is already determined, simply .blue
)
I’ve noticed a lot of people (myself included) are still creating custom UIColors
the pre-Swift 3 way. But I ask, why would you, when you can write them like so:
extension UIColor {
class var facebookBlue: UIColor {
return UIColor(red: 59/255, green: 89/255, blue: 152/255, alpha: 1)
}
called via UIColor.facebookBlue
or .facebookBlue
where appropriate.
So much better right?
For the more curious: the keyword class
means that the method/property is called upon the class, not an object of the class. This is very similar to static
, which may sound more familiar if you’ve used C++ or Java before.
static
is in fact also available in Swift and can be used in place of class
, so I was interested to determine the differences. If you use class
, the method/property can be overridden in a subclass, while static
cannot.
This is a pretty minute detail in this case of creating custom UIColors
, but a little more knowledge never hurt!
For people who are still reading: While we’re inside a UIColor
extension… Here’s a convenience init
I like to use to simplify custom UIColor
initialization
convenience init(r: CGFloat, g: CGFloat, b: CGFloat, a: CGFloat {return UIColor(red: r/255, green: g/255, blue: b/255, alpha: a)}
//called via
class var facebookBlue: UIColor {return UIColor(r: 59, g: 89, b: 152, a: 1)}
Hoped you enjoyed!