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!