Is there a way to call a method of an "owning" class? (the class that created the object).

Here's the situation: my app uses a UIScrollView. I need to process touch events, so instead of using a UIScrollView directly, I subclass it and use MyScrollView instead (so I can implement the touchesEnded: method). An instance of MyScrollView is created in my View Controller class. Here's where my question comes up: within the touchesEnded:开发者_如何学运维 method (in MyScrollView.m) I want to call a method from the View Controller class. Is there a direct way to do this? Something like:

[owner myMethod];

The way I'm doing in now is to include MyViewController.h within MyScrollView.m and create an instance of it:

MyViewController *controller;
[controller myMethod];

Doesn't seem right. Any insight?

---

After a bit more research, I realized that UIScrollView has a built-in delegate protocol. This means you shouldn't have to subclass it at all.

In your view controller header file, find this line:

@interface MyViewController : UIViewController {

And change it to:

@interface MyViewController : UIViewController <UIScrollViewDelegate> {

Assuming you're using Interface Builder, open it up and find your scroll view object. Select it, open the connections inspector, and connect the "delegate" outlet to your view controller. Go back to Xcode and open up the implementation file of your view controller. Add the method:

- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {
      NSLog(@"Here is where you do whatever it is that you're trying to do!");
}

That should be it. Let me know if you need more clarification.

Previous version of my answer:

The best way to do this is via the delegate system. Your scrollview will have a property like so:

@property(nonatomic,assign) id<MyScrollViewDelegate> delegate;

Then you can define a protocol for your delegate like so:

@protocol MyScrollViewDelegate <NSObject>
- (void)methodName;
@end

Note: you will need to put a forward-reference to the delegate before the property line, then define the methods afterwards. A forward reference for it would just be @protocol MyScrollViewDelegate;.

In your view controller's header file, make sure to import the header of the scroll view, and then change the parent class of the object from UIViewController to UIViewController <MyScrollViewDelegate>.

Then, when you create the scroll view in your view controller, set its delegate property to self (you might do this in Interface Builder if that is how you are making your UI. In that case, make sure to add the IBOutlet keyword before the id type in your @property.)

Finally, to call through from your scroll view to the view controller, you would run the following code:

[self.delegate methodName];

And that's it!

---

First of all, your 0% acceptance rate even for questions of months ago is too bad, and you should fix that ASAP to have people be more likely to answer your future questions.

Even if you didn't mention what programming language you are using, in OO paradigm there is no way to address the creator of an object, unless you do something about it.

Solution 1

If you can, make your constructor accept a creator, or parent parameter that is passed as this by the object that creates a new instance of your class. You must have full control over creator and created.

Solution 2

Maybe not suitable 100% for your case, but that's the factory pattern. In general, a factory is a singleton class, so all objects created by the factory should have means of accessing the factory's instance. You may mix it with solution 1.

Solution 3

Reflection. Depending on your programming language, when your constructor is called you may try to analyse the stack trace and try to get a reference to the object that called your method.

Solution 4

Adopt the Container pattern. If you can give up to the concept of the creator you may, at least how WinForms and WebForms do, consider a control as a container of other controls. So you have a double reference from the container object to all the contained objects and a backward reference (set after constructor with a specific setter method/*property*). So you will end up not with a reference to the object that created yours, but with a reference to the object that contains yours. Again, you should have full control over code.

I would go for solution 1 or 4 if I was you

[Edit]: when I first wrote the answer I couldn't read you are using Objective-C. I'm no expert in that, I don't know if there is any better solution but mine (maybe except 3) are feasible