Xcode now generates an empty category. What for?

Question

I noticed this when using iOS6 beta 3

When I create a new subclass of UIViewContoller (no other parent classes generate the behavior I noticed), the .m file now has an empty category at the top of the file. Earlier, having learned about categories, I noticed that some people will use the same technique to designate particular methods (although not very particular ones).

Is this the intention here? Have there been any changes to making things truly private now? I also see the @private directive.

What is your face style for coding private vars and methods?

UPDATE: Since Xcode pushes us to use class extensions, I went ahead and used them for private / ivar methods for this project. However, I found a flaw. I saw that I can reuse one of my subclasses of UIViewControllers along with all of its UIButtons, UILabels, etc. I had this inheritance: UIViewController <- FirstViewController <- SecondViewController.

Well, all the private methods that I introduced into the extension of the FirstViewController class do not appear in autocomplete when I code in the SecondViewController. A little annoyance ....

Answer 1

You mean the definition of this interface:

@interface MYViewController () @end 

This is technically an extension of the class, not a category. Categories contain a string in parentheses. Class extensions are added to the class at compile time and therefore can add ivars (usually in the form of properties). Categories are added at runtime and cannot add ivars.

All that is said, your point is correct. This is used to define particular methods and properties.

In the ObjC world, “private” is a “no breaking” sign, not a wall of razor wire. Although the @private keyword exists (which adds compiler enforcement), it only applies to ivars and is not needed at all. This type of confidential information based on warning works very well in ObjC and is quite sufficient.

Put your private properties in this class extension, and external callers will receive “may not respond to selector” warnings if they try to access them (just like they could get any undefined method call). You should never allow warnings to exist in an ObjC project, so this ensures data encapsulation.

---

EDIT

If they are closed, they should not appear in your subclass. What you want is protected. There is no big scheme for protected methods in ObjC, but the general method is to put them in a category in a .h file, like MYViewController + Protected.h. I find this to happen very rarely in practice, since most of ObjC's good design is not a subclass. Instead, it uses composition and delegation.

Regarding "Why just browse the controllers." Firstly, it’s not just viewing controllers. It just looks at the controllers on iOS (well, VC, TableViewController and GLKViewController). On a Mac, these are also window controllers and floodlight importers. Take a look:

 .../Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates .../Library/Xcode/Templates 

But why? Well, these are all controllers, and they are insanely common for controllers requiring private ownership. In fact, if you do not have private properties in the controller, you are probably too much public. This is not so universal for models and classes. I suspect that I played in their decision. Perhaps they were different people who owned the templates, or that they were updated at different times. Sometimes you see small inconsistencies that smooth out over time.

You can create your own templates. See Creating custom Xcode 4 file templates .