IOS CS193p - Why was the IBAction connection dragged to .m file and not to .h? - 【StackMirror】|iphone|objective-c|ios|cs193p

I noticed that in the calculator demo of Stanford CS193p course, the IBOutlet connection was dragged from the label to header file. However, the IBAction connection was directly created in the .m file. I tried reading through the documentation and searched on Google but couldn't find the reason behind this.

I would argue that IBAction digitPressed method should be declared in the header file as well (shouldn't it be part of the interface?).

I am obviously fairly new to Objective C (mostly worked in Java) so I am sure I am missing something basic.

Can anyone please explain?

2012-04-04 00:28
by Rahul

Declaring things in a class's header file makes them part of the public interface. This includes outlets and actions defined on a view controller.

Whether something ought to be made public is a design question. A good principal is: only if it has to be. With ViewControllers outlets and actions, more often than not, they don't have to be - and therefore shouldn't be - public.

What usually happens is that you make some guesses up front about what the public interface should contain, then (if you're a tidy developer) you take a look again when the implementation is matured and remove anything inessential.

2012-04-04 02:47
by danh

Being able to declare the IBOutlets in the .m file and link them in IB is fairly new. Demos and tutorials haven't all caught up. It is definitely the better solution, and avoids very bad practices like modifying another object's IBOutlets (which you should never do) - Rob Napier 2012-04-04 02:58

@danh, can you explain why outlets and actions don't have to be public ? How does the View access these in the controller if these are not public - Rahul 2012-04-09 02:08

ViewController can be a confusing name if you've been schooled in MVC. It's not, as you might think, a pairing of two peers in that acronym. It's better to think of it as the thing that controls a view. In that sense, it makes more sense to keep one's view private. This isn't a rule, or course, just a common practice. View is a property of view controller, and subclasses you create often have additional subviews that they control. That control is usually fairly absolute, in that they don't share that control with others. Let me google a bit for a good reference, and I'll post it here - danh 2012-04-09 02:35

http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007457 was the best thing i could find with a quick google - danh 2012-04-09 02:41

@Rahul I'm new to objective c but as I understand it, methods defined only in your .m file can technically be called by any client without error, it's just that the client shouldn't expect those "private" methods to implement the same interface over time. So, the concept of public/private in objective c is used to capture and communicate the "intended use" of any given method, not "enforce" its use. If somebody knows this to be untrue, please elaborate - John Erck 2012-07-12 02:49