3

Given that iOS SDK 6.1 is used in Xcode 4.6.3 , does it make a difference to declare the method signature of IBAction in a header file or not?

Without putting the method declaration in the header file, the app is still able to compile and run without problems. However, the method cannot be seen in a storyboard.

Are there any hidden issues of not declaring the method in the header file? Is there a memory consumption difference?

jscs
  • 63,694
  • 13
  • 151
  • 195
Raptor
  • 53,206
  • 45
  • 230
  • 366
  • 1
    It's for supporting encapsulation(oop) from what i can tell. you can hide the method from the public interface and link it from code to the outlet. By doing this you hide the implementation from the interface oop compliant. But i hink if you declare the method in a category @interface classname() you can see the method in the interface builder. – Radu Jul 25 '13 at 08:07

3 Answers3

1

Only declare it in the .h file if you want to connect it in your storyboard/interfaz builder or you want to make it public for other classes to call it.

If you just want to make it private and only use it inside your class, there's no need of declaring it in the header file.

There's no memory or performance difference.

Alexander Abakumov
  • 13,617
  • 16
  • 88
  • 129
Antonio MG
  • 20,382
  • 3
  • 43
  • 62
1

The entire point of an IBAction method is to be a public connection point in Interface Builder (using Storyboards or not).

The word IBAction itself is #defined as void. Its only purpose (and the same is true of IBOutlet) is to allow Xcode to scan your code and find these points where your controller needs to be wired up views via IB. You don't need the IBAction part of the declaration if you're programmatically connecting a control to that method.

There's no performance difference, but semantically, putting an IBAction in your implementation file doesn't really make sense. Having an IBAction means the controller is communicating to an outside object via that method, and that's exactly what header/public @interface declarations are for.

jscs
  • 63,694
  • 13
  • 151
  • 195
  • 5
    I don't know if I really agree with this. Why does it need to be public? I use `IBAction` methods to perform internal logic all the time. On principal of encapsulation, wouldn't I want to only expose it via the public interface if I genuinely needed it? Seems like Apple may have realized this and that's why they added support for dragging actions directly to implementation files a couple Xcode versions back. Please correct me where I'm wrong though, I'd love to settle on a best practice for this. – Kyle Clegg Nov 26 '13 at 23:47
  • I'm not sure I can put it any more clearly than I did in my answer. A button that's connected to an `IBAction` in your object _isn't_ internal. It's outside your object -- it's part of the view heirarchy; it has relationships with its surrounding views. `IBAction`s and `IBOutlet`s are coupling points by definition. – jscs Nov 27 '13 at 08:36
  • 3
    I've just read through the developer docs on `IBAction`s and `IBOutlet`s and can't find any requirements or mention of it being public. Where did you get your definition of `IBAction` as a "public connection point" from? Couldn't private connection point also suffice? For example, say I have a login screen with a loginButtonAction hooked up. I don't want to expose that functionality to any classes external to my login view controller, so why would I put the IBAction in the header/public `@interface`? – Kyle Clegg Nov 28 '13 at 00:36
  • See also this answer and associated comments http://stackoverflow.com/a/10004301/654870 – Kyle Clegg Dec 02 '13 at 08:13
0

Even if you plan to hook it up to the interface builder, it still doesn't have be in the header file. I personally just place them straight into the implementation file.

Da49
  • 107
  • 2
  • 10