IBInspectable and IBDesignable

One of the cool feature that was introduced in the Xcode 6 is enabling interface builder attributes for your custom view. i.e., the attributes that appears in the right when you click a control in the interface builder. Your custom control can have its properties right in the interface builder itself.

The closest thing you would do previously is, add your custom properties in the User defined run time attributes.

Previously, when you use a custom control, you have to do all the things by code. But now with this new feature, you can design your custom view in the interface builder itself. You can see how your custom view will appear while designing. There will be a lot of open source libraries in the future using this.

Apple have introduced two new attributes to make this happen IB_DESIGNABLE and IBInspectable. You have to prefix IB_DESIGNABLE before your custom view and add IBInspectable as the attributes to its property. So, a sample class will look like this.

The following types can be used for IBInspectable.

• Boolean (BOOL)
• Number (NSInteger)
• String (NSString)
• Localized String
• Point (CGPoint)
• Size (CGSize)
• Rect (CGRect)
• Range (NSRange)
• Color (UIColor)
• Image (UIImage)

The properties that have the IBInspectable attribute can be configured in the attributes inspector of the interface builder. And they will appear in the User defined run time attributesalso. They both can be used interchangeably.

You can write your code in the .m file with the IBInspectable properties setters or the drawrect method.

You can also debug your custom view without running. Simply open a assistant editor and put a breakpoint in your code and Choose Editor > Debug Selected Views.

IBInspectable can be used in your custom UIView/UIControl subclasses, categories, extensions. Don’t do expensive coding with the IBInspectable properties. The interface builder will try to compile the code no longer than 200ms. If it can’t compile within this period, the Xcode gives error.

In the first screenshot, I have added a custom text field which is of course a subclass of the UITextfiled.I can change the border color of the text field from the interface builder itself.

The apple docs is here and the sample source code is in the github.

Grap the code and play around yourself and make some useful controls with this. 

Key Value Coding and Key Value Observing

Key Value Coding:
Key value coding is a mechanism which helps us to access the properties of an object indirectly by name (or key, which is a string) rather than directly using the accessor method. The key value coding cannot be confused with the NSDictionary’s keys.

For e.g. the UITextField has a property called text which gives the current text displayed in it.
You normally access it by calling the following accessor method of the UITextField.

[myTextField setText:@"Hello"];
NSLog(@"%@", myTextField.text);

The above statements can be re-written by using the Key-Value coding as follows.

[myTextField setValue:@"Hello" forKey:@"text"];
NSLog(@"%@", [myTextField valueForKey:@"text"]);

The KCV can also be nested.
For e.g

[self.view setBackgroundColor:[UIColor blackColor]];

can be replaced with

[self setValue:[UIColor redColor] forKeyPath:@"view.backgroundColor"];

Key Value Observing:
Key-value observing is a mechanism that allows objects to be notified of changes to specified properties of other objects
For e.g. The UITextfield has delegate whenever it’s text changes, but it doesn’t have the delegates to inform about it’s colour changes. You can observe those with the “Key Value Observing”.
When you add an object as an observer for a textfield for it’s text property, whenever the text value of the textfield changes, the observer method of the object is called with the arguments.

    [myTextField addObserver:self forKeyPath:@"text" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:NULL];

-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context{
    NSLog(@"%@ \t %@ \t %@", keyPath, object, change);
}

The KVC can be used for our custom objects by default. You don’t have to do anything separately to support the KVC i.e

[myObject setValue:@"Hello" forKey:@“foo”];

will work if the myObject have a property called foo.
But to support KVO for your custom objects you have to make use of the following methods inside object's class.

[self willChangeValueForKey: @"foo"];
[self didChangeValueForKey: @"foo"];

KVC and NSArray:

NSArray has some amusing functions with KVC's. You can see them in the following screenshot.

ScreenShot:

KVC in Xib:

     You can use the KVC directly in the Xib also. See the following screenshot. I have changed the corner radious of a view directly in the Xib itself. No coding needed. You can do the same for your own custom objects too.

Notes:

    If the object doesn't have the key you passed, the setValue:forKey: will raise an exception. 

    The keys are case sensitive.

    The KVC is little slower.

References:




StackOverFlow

Key-Value Observing Programming Guide

Key-Value Coding Programming Guide

#warning pragma in XCode

#pragma's are one of the interesting part of the XCode, which helps to organise your code.
When your .m file contains thousands of line and hundreds of methods, the file becomes clumsy.

You can avoid this by structuring the code by grouping methods with pragma marks. When you give pragma directive over a method, all the methods under this pragma are grouped together in the document items. You can see that in the following screenshot.

But the fun part doesn't end here.

Have you ever hard-coded something in your code for testing something, and you forget that completely. Well, that happens a lot. What if something reminds you to fix this when you finish your work?

XCode have a pragma directive particularly for this. It is the #warning pragma. Whenever you give a warning pragma anywhere in your code, the XCode compiler gives a real warning (yellow triangle that appears near the line number). You can see the compiler warning in the line navigator, Issue navigator like the other XCode warnings.

But this doesn't stop your code from executing, you can use the #error pragma if you want to stop the code from execution.

You can also make use of some comments that start with the following keywords.
// FIXME:, // ???,  // !!!, // MARK

The comment you enter after these will appear in the document items (Option + 6).