0

Can any one help in understanding why Apple decides to uses Target Action design pattern for event handling of UIButton not Delegate Pattern?

Or, I can say why Apple choose delegation Design pattern for UITextField even same thing can be achieved by Target Action also.

halfer
  • 19,824
  • 17
  • 99
  • 186
Sudhir kumar
  • 659
  • 5
  • 21
  • https://stackoverflow.com/questions/41141828/why-uibutton-uses-target-action-design-pattern-not-delegate-pattern-and-vice-ver – Arpit Sep 19 '17 at 08:26

3 Answers3

2

There are various trade-offs to the different approaches. I think the clincher for button actions, though, is that you can add multiple target/actions to a button. (A one-to-many relationship.) Delegation is a one-to-one relationship, so having a button trigger multiple actions, possibly to different targets, would not be possible with the delegation design pattern.

I think if Apple were designing button handling now they'd use blocks/closures instead of IBActions. The control could hold an array of blocks and the events that trigger each.

Duncan C
  • 128,072
  • 22
  • 173
  • 272
1

All @IBAction functions have one of three signatures;

  • functionName() -> Void
  • functionName(sender: Any) -> Void
  • functionName(sender: Any, forEvent event: UIEvent) -> Void

An IBAction cannot accept any other arguments and does not return a value.

A delegate allows the use of functions that take different parameters and return values while actions are a standard approach across UIView subclasses.

In some classes, such as UITextField, certain action can be handled through both delegate and action methods. I guess this just gives you some choice; if you are already implementing delegate functions then you don't need to implement action handlers as well.

Paulw11
  • 108,386
  • 14
  • 159
  • 186
  • Actually, there are **THREE** valid function signatures for an IBAction: no parameters, a sender, or a sender and the triggering `UIEvent`. (`@IBAction func doSomething()`, `@IBAction func doSomething(sender: UIButton)`, and `@IBAction func doSomething(sender: UIButton, forEvent event: UIEvent)`) See listing 1 in this link: https://developer.apple.com/reference/uikit/uicontrol – Duncan C Dec 14 '16 at 15:52
  • Thanks. I have edited my answer. Interestingly Apple's documentation is incorrect; the sender may not be a UIButton – Paulw11 Dec 14 '16 at 20:02
  • The sender can indeed be a `UIButton`. I do that all the time. The `UIControl` class is the parent class of UIButton, so a UIButton *is* a `UIControl`. – Duncan C Dec 14 '16 at 20:18
  • Yes, the sender *can* be a `UIButton` but it doesn't *have* to be a `UIButton`. The signature in Objective-C is `id sender`, so in fact, the Swift signature is AnyObject/Any – Paulw11 Dec 14 '16 at 20:22
  • Yup. IB defaults to making the sender in an action `id` in Obj-C, and `Any` in Swift, which I find annoying. I almost always want it to be the specific class of the sending control. – Duncan C Dec 14 '16 at 20:38
0

This is due to Apple wanting to show different patterns in code.

Nathan Tuggy
  • 2,237
  • 27
  • 30
  • 38
Arpit
  • 1
  • 1