I'd like to offer a slight refinement to this strategy. See this stackoverflow question:
Overriding isHighlighted still changes UIControlState - why?
It turns out that Apple's state
implementation is actually a computed property based off the other properties, isSelected
, isHighlighted
, isEnabled
, etc.
So there is actually no need for a custom state bit mask on top of UIControlState (well, it's not that there is no need, it's just that it's adding complexity where there need/ought not be).
If you wanted to be congruent with Apple's implementation, you would just override the state property and check your custom states in the getter.
extension UIControlState {
static let myState = UIControlState(rawValue: 1 << 16)
}
class MyControl: UIControl {
override var state: UIControlState {
var state = super.state
if self.isMyCustomState {
state.insert(UIControlState.myState)
}
return state
}
var isMyCustomState: Bool = false
}
It's actually a smart way to go; as per the link above, if you override the property and don't change the state you will get inconsistent results. Making state always a computed property ensures consistency between the properties that state
represents.