in my app I want to use googleAnalytics. To use it I have to extend GAITrackedViewController but the problem is I already extend GLKViewController because my view has an openGL application. So is it possible to extend the properties of both view controllers?
For a similar case, I've simply created a subclass of UIViewController (GLKViewController in your case). That subclass handles the tracking of the view. All "specific" ViewControllers extend that custom UIViewController, instead of the default one.
Then you could, for instance, track the view manually:
id<GAITracker> tracker = [[GAI sharedInstance] defaultTracker];
[tracker sendView: NSStringFromClass(self.class)];
No, there isn't multiple inheritance in Objective-C. You have write a subclass of GAITrackedViewController and a subclass of GLKViewController separately, and write a controller class that has an instance of these two classes, coordinating them.
It's not possible, objective-C doesn't support multiple inheritance. You should take a look to this question: Objective-C multiple inheritance
it is very bad to extend 2 classes even on languages that allow it,
because you can get 2 ways to your "super" and this is a way to many bugs
Related
Since I started developing my app, some of my view controllers have grown and now I have a lot of code in them. I'm just wondering if I could create some kind of subclass which would inherit instance variables, so I could move out some of the code.
I'm guessing this won't be possible, without creating a new class with properties, which I'll have to provide with values.
Is there anything neat I could do to save some time ?
This is a pretty tricky and touchy subject with Objective-C coders. In general, this type of repletion is expected. You don't have any specifics in your question, but if you're only repeating some basic view setup code, that's not really an issue.
In general, creating a "base" UIViewController subclass is not common. If you're adding logic to your view controllers that's very common, like setting up a special navigation button, then you can use a category.
Basically, in Objective-C, a category can be used to add a certain behaviour to all instances of some class. In the example I linked to, they add some functions to the string class. Take a look at what you're repeating and see if a category would be a better approach to subclassing.
In my iPhone app, I have a custom UIViewController class setup which adds some UIImageViews and things.
How can I access this class via my main UIViewController and, for example, call a method from that outside class and have it add those UIImageViews to the view?
Make property and public methods, after that you can call them in target viewcontroller.
p.s. But I never used this approach because it breaks controller's logic. Instead of I usually use some managers which has all required methods. (DBManager, NetworkManager, etc)
I am new to iphone app development. I want to add two different delegates.
I know how to add multiple delegates of same class like
UIViewController .
I want like this
#interface HelloWorld : CCLayer, UIViewController
in which one class is CCLayer of cocos2d and second one simple UIViewController.
Thanks in advance for help.
I'm not familiar with CCLayer but you can't do multiple inheritance in Obj-C (so you can't have two superclasses). What you can do is create two classes, one that subclasses UIViewController and the other subclasses CCLayer and then create a protocol/delegate pattern to allow communication between the two.
http://iosdevelopertips.com/objective-c/the-basics-of-protocols-and-delegates.html
Can any one differentiate when do we use Delegation over category and vice versa. I am clear over this.
Thanks
Category allows to add new methods or overwrite existing methods on a class, thus allows to extend a class without subclassing. Adding methods is the most useful aim, overwriting can go really wrong if you do not know exactly what the class being extended does.
It is more a language feature not a pattern, it works on each class.
Delegate is a pattern not a language feature, the class that is supposed to used must be coded for it, otherwise it won't work.
Usually a delegate will be required to implement a protocol known by the class that is going to receive the delegate. The class will then use the delegate to do stuff it was coded for, some of the most common are sending notifications, using a part of a strategy pattern, that is asking question in certain part of code to make decisions based on the concrete delegate's implementation, letting delegate execute an action or any combination of them.
For example UIApplicationDelegate is a notification (application:didFinishLaunchingWithOptions:) and action (application:openURL:sourceApplication:annotation:) protocol, UITextFieldDelegate is notification (textFieldDidBeginEditing:) and strategy (textField:shouldChangeCharactersInRange:replacementString:).
Actually I can imagine using category to implement delegating in all this cases I stated above: sending notifications, doing actions, taking part in a strategy. But it would require you to very very good know what to extended class is doing, probably to have it code, otherwise you can very easily break the class or be broken by changed class implementation. So this usage would be in my opinion highly wrong.
category: Adds methods to an existing class.
delegate: Modifies behavior of another object by allowing some other object, the delegate, to participate in the object's operation.
Say you've got an iOS application with three tables. Even though they're configured the same way, those tables each may behave differently if they have different delegates.
You can't do that with a category because a category applies equally to all instances of the class it extends. On the other hand, if you want to extend the UITableView class to add some new capability, you need a category*. Delegates are instance-specific and limited to the role envisioned for them by the designer of the delegating class.
*or a subclass, of course.
Categories are used when you need to extend the class without creating a subclass, for example when you need to add a method named isURL to the NSString you can make use of categories as follows, here we not creating a subclass, instead we are extending the implementation.
#interface NSString (Utilities)
- (BOOL) isURL;
#end
Delegates are similar to callback functions,
In my app there are numerous view controllers which have their own purposes. However, underneath they do share some need for common maintenance work that could use the same method code instead of each having its own copy of the code, literally pasted in.
Is there a way to share the code of these common methods ? I see two possibilities:
1) either one copy of code truly shared in memory as in a special maintenance object of methods
or
2) written once in a block of code but allocated many times as needed by each view.
Which of these is the correct path or what is the correct path, and HOW would it be implemented in the most simple manner ?
Kindness pls, new coder in the room.
Thanks.
-Ric
Note: This is an old question/answer reflective of Apple practices at the time, and answered for a new coder looking for a simple solution they can understand (as requested in the question). There are better and more testable ways to achieve this, using composition.
The best way to achieve what you want is to create a common parent class for your view controllers. So instead of inheriting directly from UIViewController, each of your custom classes will inherit from SomeFeatureViewController (where SomeFeature describes the common feature provided), this class inherits from UIViewController. Now, each of your actual view controllers will inherit from SomeFeatureViewController and any common methods (also any common instance variables used by these methods) can be placed in this parent class.
#interface SomeFeatureViewController : UIViewController
{
int common_iVars;
}
- (void)commonMethods;
#end
#interface ActualViewController : SomeFeatureViewController
{
int specific_iVars;
}
- (void)specificMethods;
#end
The way I see it you should do a class with all the common methods and then subclass it. Say you have MyCommonViewController : UIViewController and then for each different view controller do MySpecificVIewController : MyCommonViewController
As well stated by jhabbott, a subclass of UIViewController is one good solution.
If that's not an option (e.g. you can't change the class hierarchy), another option is to create a category on UIViewController to add the methods and properties you need. This will make your methods available on every UIViewController, including all the standard subclasses, without any extra work on your part. With this solution you cannot directly add ivars, although you can fake it up well enough using associative references.
Well, what I ended up doing was to create a Singleton object and put all my common methods there. This meant that all my View Controllers could utilize the common methods of the Singleton. Maybe this is a bit too open if the project was being developed by a team of programmers but as it is just me I know that all the controllers have similar requirements in processing. So the Singleton approach seemed to work.
It also fit the project because at the time of the question all the View Controllers had been created and to make them a subclass of a parent class seemed to be a retrofit, though I agree that if part of an initial design, it may be a better approach. I do thank the 3 who gave the time to answer.