How to change the colour of a UITextField's placeholder text for iOS7

Working with UITextFields is generally quite easy, you can customise most attributes apart from the placeholder text, while you can obviously change the text you can't change the colour of the text or it's position. This was a problem we had on a recent project, our design required us to have UITextFields with black backgrounds, the placeholder text colour is dark grey which is almost invisible in our app and Apple provides no easy way to change this.

We solved this by subclassing UITextField and overriding drawPlaceholderInRect: method to draw our own placeholder text. This is fairly straight forward in iOS6 but did not work as expected in iOS 7.

- (void)drawPlaceholderInRect:(CGRect)rect

{  

 UIColor *colour = [UIColor lightGrayColor]

if ([self.placeholder respondsToSelector:@selector(drawInRect:withAttributes:)]

{

     // iOS7 and later

     NSDictionary *attributes = @{NSForegroundColorAttributeName: colour, 

     NSFontAttributeName: self.font};

     CGRect boundingRect = [self.placeholder boundingRectWithSize:rect.size 

     options:0 attributes:attributes context:nil];  

             [self.placeholder drawAtPoint:CGPointMake(0, (rect.size.height/2)

      -boundingRect.size.height/2) withAttributes:attributes];
    }else{
                     // iOS 6
        [colour setFill];
         [self.placeholder drawInRect:rect withFont:self.font
        lineBreakMode:NSLineBreakByTruncatingTail 
               alignment:self.textAlignment]: 
       } 
} 

 

Atomic vs Nonatomic

In this post I will discuss the difference between (atomic) and (nonatomic).

Atomic

@property (strong) NSMutableArray *myArray;

@property (strong) NSMutableArray *myArray;

Atomic is the default behaviour for a property; by not explicitly setting the above property as nonatomic, it will be atomic.
An atomic property adds a level of thread safety when getting or setting values. That is, the getter and setter for the property will always be fully completed regardless of what other threads are doing. The trade-off is that these properties will be a little slower to access than a nonatomic equivalent.

Nonatomic

@property (nonatomic, strong) NSMutableArray *myArray;

@property (nonatomic, strong) NSMutableArray *myArray;

Nonatomic properties are not thread safe, and will return their properties directly. This will be faster than atomic properties, but obviously carries some risk if precautions aren’t made.

When is it Appropriate to Use Nonatomic?

One thing I’ve noticed while following Objective-C tutorials and articles is that nonatomic is used most of the time. So if nonatomic is so risky, why is it used so often?
It’s all about performance. An atomic property’s getter and setter, conceptually, looks something like this:

-(NSString *) myString {     @synchronized(self) {         return myString;     } } -(void) setMyString: (NSString *) newString {     @synchronized(self)  {          myString = newString;     } }

-(NSString *) myString {     @synchronized(self) {         return myString;     } } -(void) setMyString: (NSString *) newString {     @synchronized(self)  {          myString = newString;     } }

Whereas a nonatomic property getter and setter looks something like this:

-(NSString *) myString {     return myString; } -(void) setMyString: (NSString *) newString {    myString = newString; }

-(NSString *) myString {     return myString; } -(void) setMyString: (NSString *) newString {    myString = newString; }

It’s easy to see how the nonatomic implementation is going to be more light weight, but it does mean you have a responsibility to ensure problems don’t arise. Some articles I’ve read recommend keeping things atomic until performance becomes a problem, while others recommend the opposite.
In any event, if you decide to create a nonatomic property, here are some tips for keeping things thread safe:

• Use immutable objects where possible. For example, rather than creating an NSMutableArray, create an immutable NSArray. Whenever you need to add an object to it, create a mutable copy first and do what you need to do, then replace the entire property in one hit rather than tacking on another value to the end.
• You can wrap potentially problematic sections of code with @synchronized.
• UI code can always be nonatomic because UI code always happens on the main thread of the application.