Does categories allow to use dot syntax when accessing chained methods?

Question

I need to attach a method to all my UIViewControllers. The method just returns a pointer to my main app delegate class object. However, xcode 4 throws an error "parse issue expected a type" in header file at the declaration of output parameter type MyAppDelegate. If I change it to the other type, for example id, then the error goes away. But I'm using a dot syntax to access main app delegate properties and if I will change the type to id then xcode4 not recognize my main app delegate properties. I have included the definition file of category to those UIViewController class files where I'm accessing this method. Here is definition of my category:

#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#import "MyAppDelegate.h"

@interface UIViewController (MyCategory)

-(MyAppDelegate *) appDelegate; // xcode 4 complains about MyAppDelegate type, though it autocompletes it and show even in green color.

@end

Here is an implementation:

#import "MyCategory.h"

@implementation UIViewController (MyCategory) 

-(MyAppDelegate *)appDelegate{
  MyAppDelegate *delegate = (MyAppDelegate *)[[UIApplication sharedApplication] delegate]; 
  return delegate;
}

EDIT: The reason why I'm implementing this category is that I need to have handy shortcut for accessing my main app delegate from any place of the code (in my case from UIViewControler objects):

// handy shortcut :)
self.appDelegate.someMethod;

//not so handy shortcut :(
MyAppDelegate *delegate = (MyAppDelegate *)[[UIApplication sharedApplication] delegate];

@interface MyAppDelegate : NSObject . It's just implementing UIApplicationDelegate protocol. — Centurion, Aug 08 '11 at 13:30
If your view controllers are commonly accessing your application delegate, you have design problems. This makes it very difficult to reuse your view controllers. If you need access to configuration data, put it in `NSUserDefaults`. If you need access to common objects, make them shared singletons; don't access them through your application delegate. The application delegate is the delegate for the `UIApplication`. It should handle application startup, state-changes and shutdown. It is not a dumping ground for globals. — Rob Napier, Aug 08 '11 at 15:15
Recently, I have posted a question about architecture and how to implement communication between different MVCs (http://stackoverflow.com/questions/6974301/how-to-design-code-architecture-when-overlapping-objects-exist). If you have any other solution, please share. — Centurion, Aug 08 '11 at 15:53

score 1 · Answer 1 · edited Mar 04 '13 at 15:05

1

-(id)appDelegate{
  return [[UIApplication sharedApplication] delegate]; 
} 

//Calling code
MyAppDelegate* delegate = (MyAppDelegate*)[self appDelegate];

edited Mar 04 '13 at 15:05

answered Aug 08 '11 at 13:36

Akshay

5,747
3
23
35

+1 for clean design. It would be even better if you pointed out why its a bad idea to include such a localized method signature on a high level framework class. – Perception Aug 08 '11 at 13:58
The thing I'm putting it into a category because I would like to have a handy shortcut instead of long line of code. The shortcut I'm trying to have would behave like a property, but it would be just a method. In my case, I would like to access my main app delegate like self.appDelegate.someProperty. – Centurion Aug 08 '11 at 14:14
@Perception: How is it clean design to have to put a type cast in? – JeremyP Aug 08 '11 at 15:10
Can you do it without casting? You would have to cast somewhere. – Akshay Aug 08 '11 at 15:24
@JeremyP - No inclusion of app specific header files in a foundation class. No dependencies on the app delegate implementation class. Promotes reuses. Cleaner. – Perception Aug 08 '11 at 15:53
@Perception: No compile time type checking. I also don't understand your comment about putting an app specific header in a foundation class. He's not, he's putting an app specific header in an app specific category. He is of course adding an extra layer of message sending as well. – JeremyP Aug 09 '11 at 07:30

score 1 · Accepted Answer · answered Aug 08 '11 at 15:10

I think you have a dependency cycle in your header files. If MyAppDelegate.h imports MyCategory.h either directly or indirectly, the first time the category declaration is compiled the compiler won't know what a MyAppDelegate is. You should remove the import of MyAppDelegate.h from the MyCategory.h header and replace it with a forward class declaration:

#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>

@class MyAppDelegate

@interface UIViewController (MyCategory)

-(MyAppDelegate *) appDelegate; 

@end

Then put the import in the .m file instead. This is actually a good general principle. Where possible, use forward class declarations in the headers and put imports in the implementation file.

score 0 · Answer 3 · answered Aug 08 '11 at 13:51

0

Add @class MyAppDelegate; to the top of your category header to let the compiler know that this class exists or #import its header.

Generally, it might be a better idea to have a class method in MyAppDelegate that does the same thing. Conceptually, appDelegate is not a property of an individual view controller which your method implies.

answered Aug 08 '11 at 13:51

omz

53,243
5
129
141

I'm trying to improve my architecture. My app has 6 UIViewController screens and every MVC performs popping/pushing other MVCs on screen. I need to have pointers to all MVCs for each UIViewController. But I didn't like pointer solution. I also didn't like the thought about using notifications. Then I got an advice to have all necessary pointers to my screens in main app delegate class and access them using sharedApplication. But the access code is quite long so I would like to have a shortcut, like self.appDelegate.someMyUIViewController. But was unable to get it working with category. – Centurion Aug 08 '11 at 14:12

Does categories allow to use dot syntax when accessing chained methods?

3 Answers3