Those methods are called automatically by the system. You never call them directly.
What you should do, well that depends on your goal. If you just want to "simulate" touches, just have helper methods. Then, have touchesXXXX call those directly.
We do not get an API to create UITouch objects, so you have to mirror them if you want to keep their information around. Something like...
@interface MyTouch : NSObject {
UITouchPhase phase
NSUInteger tapCount
NSTimeInterval timestamp
UIView *view
UIWindow *window
CGPoint locationInView;
CGPoint locationInWindow;
@end
Then, you could have a method like this...
- (void)handleTouches:(NSSet*)touches {
}
Where touches was a set of MyTouch objects.
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
// For UITouch in touches, create a MyTouch, and add it to your own
// collection of touches.
[self handleTouches:myTouches];
}
If you did this for each touchesXXXX method, each one of them pass off handling to your own method.
Now, by doing this, you have control over creating your own touch objects. You can make them be configured for any view, or pattern you want. Then, in any other piece of code, you can create a collection of MyTouch objects, and call handleTouches: with them.
As long as the touchesXXXX methods just create your special objects, and pass them on to your method, you can have the exact same behavior whether the system generates the touches, or you simulate them.
Now, what you DO NOT get is automatic generation of system events.
If you are getting killed by the performance of that, there are simple ways to avoid the creation of the extra set and objects, but that's not your question.
touchesXXX:withEvent:
. – Sergey Kalinichenko