I'm working in a class that is a delegate of another class; this other class is in a third-party library that I'd like to avoid changing if at all possible.
The original class is handling a -touchesEnded event, and is delegating responsibility to me, but it doesn't pass the UIEvent itself to me. Is there a way to get a handle to the current event in progress? It's a double-tap handler, and all that is passed to me is the view being touched, and the point at which the touch occurred. I want to know exactly how many touches are involved in the event.
Thanks!
randy
You can subclass the original 3rd-party view and override -touchesEnded:withEvent: in that subclass.
You can also subclass UIApplication and override its -sendEvent: method to capture all (public) events.
Related
Most overloaded methods require [super theMethod] call.
(For example, [super viewDidLoad];, [super viewWillAppear]; and [super dealloc];)
I didn't think twice whether I need [super touchesBegan:withEvent:] call or not, but it seems to play a role somehow.
When do I need it and when don't I need it?
I'm trying to programmatically cancel touch events when I need to, and it seems to be related to the question I asked.
While it all depends on the expected behaviors of the object, let's point out the basic: You call the superclass implementation in an overridden method (you mean overriding, not overloading) if you want default behaviors implemented by the superclass.
So the questions you should ask are:
1) What does the superclass implementation do?
2) Do I need it for my object?
So what does touchesBegan:withEvent: etc. of your superclass do? It depends on your class hierarchy. The custom classes in your class hierarchy may already override those methods and you may want those behaviors, or not. I assume that no custom class has yet overridden those methods, so you have to check Cocoa implementations only.
touchesBegan:withEvent: is first defined in UIResponder class. Let's look at the UIResponder documentation, which says
The default implementation of this method does nothing. However immediate UIKit subclasses of UIResponder, particularly UIView, forward the message up the responder chain.
So you get a theory here. If your class directly inherits from UIResponder, you don't need to call the superclass implementation at all as it does nothing anyway. If it inherits from other UIKit subclasses such as UIView, calling the superclass implementation will enable forwarding messages up the responder chain. However, overriding touchesBegan:withEvent: perhaps means that your subclass wants to handle touch events itself, so you don't want to forward the events up the responder chain. So, I guess you don't want to call the superclass implementation here.
It really depends on the situation. Say, that you subclass a UIScrollView, and implements one of the touches... method. If you still want the view to scroll as the user drags, then you want to call the superclass implementation because it will handle scrolling for you.
To sum up, you have to be able to answer the two questions above to decide. To find out what a superclass implementation does, read about it in the Apple Documentation. In many cases, if what a superclass implementation does is essential for common expected behaviors, the guide documents give an explicit advice to call the superclass implementation.
I am developing an iPhone application with multiviews (Nav controller), but i like to receive an event if user touches in any view of the view. I understand it can be done by subclassing application delegate? If that's true how can i do it? My requirement is, i like to receive an event as soon as user touches any where in any view within my application.
Thanks for your help and time.
Your reference to subclassing UIApplication will work. Read down through the comments and it covers a somewhat quirky IMO way to implement it (by having the AppDelegate be a subclass of UIApplication). Myself, I would create a separate class to be the UIApplication subclass, rather than having the app delegate do both jobs, but I see the merit of either way.
That said, this is a very large and unusual stick and may suggest a design failure. What problem are you solving with this?
A way to do it is to use a Singleton class (which acts as an observer/mediator), which the application is an example of, in which you have viewControllers subscribe to when they are intersted in the touch events of a certain view. When the touch occurs the Singleton class is informed of the event as a result it informs all subscribers to the event of the event.
Here is an example
#interface MyEventClass
{
-(void)TouchEventDidOccur;
-(void)subscribeToTouchEvent:(id)delegate selector(selector):sel
}
Above is the singleton class
now this is an example of what the view touchesBegan method might look like
-(void)touchesBegan...
{
[[MyEventClass sharedInstance] TouchEventDidOccur];
}
and how one would subscribe to the event
[[MyEventClass sharedInstance] subscribeToTouchEvent:self selector:#selector(receiveTouchEvent:)]
hope this helps
What's wrong with using notifications? If you have disconnected classes across your application, it's trivial to have them listen for a particular notification, then have your views or view controllers post that notification when a touch event happens. All of the observers will take action on the notification.
In many situations, such as making the keyboard go away when the use clicks done, there are two options: set the text field's delegate to self, and adopt the UITextFieldDelegate protocol, and then use the method
- (BOOL)textFieldShouldReturn:(UITextField *)textField;
to resignFirstResponder and return YES. But you can also
addTarget:self
action:#selector(myMethod:)
forControlEvent:UIControlEventDidEndOnExit];
or something like that, using the did end on exit event, and then in the method, [sender resignFirstResponder]. So what is the best option in situations like these: the delegate, or the event?
The quick rule of thumb is that delegates are supposed to answer the question of "should I?" on behalf of the object they are a delegate for. Events, on the other hand, are broadcast afterward to let listeners know that something has happened.
In your case, while you could call [sender resignFirstResponder] in response to the event, you're mixing metaphors by doing this. Your delegate should have already made the decision to hide the keyboard (or not) and the event being broadcast is merely to let all the other components know that they keyboard hid.
If you are going to be paired with one other class, where the real type of that class may vary, then it makes a lot of sense to formalize that pairing into a protocol and a delegate arrangement.
If the information you want to send is targeted at a broader set of objects, then it starts to make more sense to use notifications - though now you have somewhat obscured what information is being passed by the notification as there's no central definition for what to expect.
Both are about an equal load to work with - with a delegate you have to set yourself and then remember to unset yourself before you are deallocated. You have to do the same thing with notifications, remember to start listening and then unsubscribe before you are deallocated.
Also, you should try as much as possible to make sure you send notifications out on the main thread as the notices get sent on the same thread they started from. Same goes for delegate methods, it's not very kind to call a delegate method from some other mystery thread!
The delegate makes your objects more reusable they are an adapter that lets any object interact with the defined behaviors of that object and use the object. I would say delegates should be adopted by the object responsible for keeping the state of and defining behavior to actions that will occur in the object that it is using. Events should be used for any other objects that are intersted in particular action that the object that has the protocol does (so objects not responsible for keeping the state of the object that defines the protocol).
For example: A view controller using a textfield will adopt its protocol to dismiss the keyboard and any other behaviors that can occur for a textfield, maybe another controller will do some animation when the keyboard is dismissed, so it will register to the textfield as an event in order to receieve the event of the keyboard being dismissed.
I have a pretty simple UIViewController. It's initialized with a view I've created in Interaface Builder, which contains only a UIImageView. When the user touches the screen, I want the touchesBegan message of UIViewController to get called. So, I override it and added some logging, but nothing has happened.
I haven't done anything "special" at all, as since UIViewController inherits from UIResponder, I expect this to work right out of the box. From what I understand UIImageViews have user interaction disabled by default, so I have enabled it, both via InterfaceBuilder and in my UIViewcontroller's viewDidLoad method (I have tied the UIImageView to an IBOutlet). I also am ensuring that userInteraction is enabled in the parent view in Interface Builder.
Anything else that I am forgetting here?
OK, I'm a dummy. It works fine. The problem was, I didn't realize I was sending a release message to the UIViewController without having retained it elsewhere first. So that was causing the problem.
It is hard to say what your problem is, I don't know what you mean by overriding it?
Make sure you are connecting the touchesBegan event with an IBAction in Interface Builder?
You must create a IBAction function to handle the event, and explicitly connect the even to the IBAction. It is not as simple as simply overriding a method.
Although you have the View tied to an IBOutlet, you need to connect the event using an IBAction, or else you won't get any of those events.
Please ignore the first answer. It is, in fact, as easy as overriding the method in the custom view. The most common reason for not receiving touchesBegan is the canBecomeFirstResponder method not being implemented. This is not an IB hookup, these are the standard methods for touch handling.
I would like to gain a better understanding about the delegation. Can somebody please paste a good code sample of delegation and explain how it works?
There is a pretty good example at: http://en.wikipedia.org/wiki/Delegation_pattern#Objective-C_example
In this example, MyCoolAppController creates and object of type TCScrollView, and sets the "delegate" property of the TCScrollView to self. This means that when the TCScrollView calls
[delegate scrollView:self shouldScrollToPoint:to]
it is asking the MyCoolAppController (the delegate of the TCScrollView) to perform some calculations and see if it is ok to scroll. You can say "MyCoolAppController is the delegate of TCScrollView" to describe this; TCScrollView asks MyCoolAppController to do some work on its behalf.
Do you mean .NET or Java or some other language delegate?
A delegate in .NET parlance is nothing more than a function pointer, or in other words a variable that points to a block of executable code. They can be used in may ways. One way is to use them in the context of events. Lets say you have an ASP.NET page and you are using the MVP (Model View Presenter pattern on that page). You want your presenter to be notified of the click event of the save button on the view. You can define an event on the views interface, but in order to subscribe to that event and to take action on it you need to register a method that gets fired when the event is raised. For example:
public class ClassThatRegistersForEvent
{
public void InitializeView(IView view)
{
view.SaveButtonClickedEvent += delegate{
// do stuff in here when the event is raised
}
}
}
public interface IView
{
event System.EventHandler SaveButtonClickedEvent;
}
Here's an answer I wrote explaining delegation: https://stackoverflow.com/questions/1089737#1090170
A delegate is a way to respond to events. In other languages you would probably do this by subclassing. For example, say you have a table view. You could subclass the tableview and override the tableView:didSelectRowAtIndexPath: method, but that would get messy and create an unnecessary subclass (along with the fact that its not reusable) Instead, you create a TableViewDelegate class and tell your table view about it (tableView.delegate). This way, the method will automatically get called when something happens. This is a really clean solution to event-handling.
After you write a few apps that involve delegates (table views are the big ones), you'll get the hang of it.