The displayed results are reasoned in the fact that UISlider
(among many other controls) in fact is composed of multiple subclasses which handle the drawing themselves. The results is a highly optimized display code which can not properly be overridden using drawRect:
on the UISlider
only. You would have to override several other, partially closed implementations of that composed control.
In fact, there is a much easier and much more performant solution which is providing the graphical elements you wish to customize to UISlider
. A nice introduction on that subject can be found on Apple's conceptual introduction to Sliders.
There some smaller pitfalls though - one of them is the fact that a UISlider
's thumb does not "like" to be replaced by something with a different size. Those are however covered by many tutorials - one of those would be how-to-make-a-custom-uislider.
As a rule of thumb: avoid subclassing and overriding drawRect:
when possible by any means as it will vastly degrade the performance of your UI.
Instead look at solutions that make use of the UIAppearance
protocol for controls that do not provide interfaces for customizing. UISlider
however does provide them, so go for those.
This would be my approach priority list:
- Check very carefully if the control in question does allow customizing by providing images etc.
- Check if the control in question adheres to the
UIAppearance
protocol. - Use subclassing and possibly overriding
drawRect:
- When it turns out that the control in question appears to handle
drawRect:
in a "weird" way, subclassUIView
and recreate the missing logic yourself.