#interface in objective c - iphone

In the following code what is the function of -(IBAction)setLabelPushed:(id)sender;
#import <UIKit/UIKit.h>
#interface BasicIPhoneAppViewController : UIViewController
{
IBOutlet UILabel *myLabel;
IBOutlet UITextField *myTextField;
}
-(IBAction)setLabelPushed:(id)sender;
#end

Actually it is a non-static method. IBAction means that it can be used as a event handler in Interface Builder (it can be linked to some action). You should provide more details, for example the body of setLabelPushed function.

get the value from textfield and show it in the label .I think so......

It is a method you can bind from within the Interface Builder...
http://mobile.tutsplus.com/tutorials/iphone/iphone-sdk-interface-builder-basic-training/

IBAction resolves to "void" and IBOutlet resolves to nothing, but they signify to Xcode and Interface builder that these variables and methods can be used in Interface builder to link UI elements to your code.
If you're not going to be used Interface Builder at all, then you don't need them in your code, but if you are going to use it, then you need to specify IBAction for methods that will be used in IB and IBOutlet for objects that will be used in IB. IBOutlet and IBAction

Related

IBAction and IBOutlet Clarification

I am new to Xcode and I am wondering, what does IBAction and IBOutlet do? I've tried doing simple task like 'hello world' but it seems I stuff it up. I am making app that involves a questionnaire that links to a database.
IBAction is used for Methods which performs as a result of any Action for example Button Press.
-(IBAction) buttonPress : (id) sender;
IBOutlet is used for UI related objects like Button,label, View etc.
IBOutlet UILabel *nameLabel;
Note: If you are using XIB for development, you should make use of IBAction and IBOutlet. Otherwise you will not able to map objects and methods on XIB. If you are developing everything by coding then IBAction and IBOutlet are optional.
As mentioned in the answer linked above: "IBAction and IBOutlet are macros defined to denote variables and methods that can be referred to in Interface Builder."
However in layman's terms and a simple way to think of them -
IBActions mark the methods that will be called when an event (e.g. touch down) is triggered on one of your interface builder controls (e.g. button, switch etc).
IBOutlets mark the variable references for your interface builder controls.
Outlets allow you to programatically interact with controls you layout on interface builder.

What does IB mean in IBAction, IBOutlet, etc..?

I am very new to iPhone development. I often encounter IBAction, IBOutlet and so on when reading Objective-C and Swift code. What does IB stand for?
"Interface Builder".
Before Xcode 4, the interface files (XIBs and NIBs) were edited in a separate program called Interface Builder, hence the prefix.
IBAction is defined to void, and IBOutlet to nothing. They are just clues to Interface Builder when parsing files to make them available for connections.
Just to add the reference, inside AppKit/NSNibDeclarations.h you'll find these:
#ifndef IBOutlet
#define IBOutlet
#endif
#ifndef IBAction
#define IBAction void
#endif
So, actually, code like this:
#interface ...
{
IBOutlet NSTextField *label;
}
- (IBAction)buttonPressed:(id)sender;
#end
Will be transformed into:
#interface ...
{
NSTextField *label;
}
- (void)buttonPressed:(id)sender;
#end
By the preprocessor, even before the compiler sees it. Those keywords were acting just as clues to Interface Builder.
IB stands for interface builder, as you connect objects via the interface builder .
IBAction and IBOutlet are interface Builder Constants
IBOutlet:A Controller class can refer to the object in the nib file using a special constant called IBOutlet.
IBActions:Interface objects in the nib file can be set to trigger specific methods in controller class using IBAction as return type of the method.

Connect one view to another in seperate NIBs using Interface Builder

I have a custom UIWindow class that has an IBOutlet
#interface MyWindow
IBOutlet UIView * someView;
id <MyWindowDelegate> delegate;
// to inform a controller something happened to view
#end
#interface MyControllerThatContainsSomeView
IBOutlet UIWebView * theConcreteView;
#end
I have changed my Window in MainWindow.xib to MyWindow. Is there a way, through interface builder, in which I can reference someView from MyControllerThatContainsSomeView.xib
so, MainWindow.MyWindow.someView -> MyControllerThatContainsSomeView.theConcreteView
You can refer to it in a binding path but that's about it. Usually when you find that you need to refer from one view to another, it's time to rethink your design. Views should refer instead to model objects which provide data to the views.

Do IBOutlets always require an instance variable in the .h file?

Sometimes I see the following code into two different formats:
Format 1:
#import <UIKit/UIKit.h>
#interface MyViewController : UIViewController {
IBOutlet UILabel *myText;
}
#property (retain, nonatomic) UILabel *myText;
-(IBAction)buttonPressed:(id)sender;
#end
Format 2:
#import <UIKit/UIKit.h>
#interface MyViewController : UIViewController {
}
#property (retain, nonatomic) IBOutlet UILabel *myText;
-(IBAction)buttonPressed:(id)sender;
#end
which is the correct format? Why?
To clarify what Hack Saw said, and more directly answer your question, it does not matter whether you put IBOutlet in your property declaration or your instance variable declaration.
What Hack Saw was trying to say is that IBOutlet and IBAction both mean nothing to the compiler (IBAction gets compiled into void). The only reason they are there is for Interface Builder to parse the file and make a list of all objects and methods that you the developer says it should care about.
IBOutlet is a marker for interface builder to find your declarations, and make them available in the drop downs in IB.
They are strictly only required if you want to have IB connect an IB object to a reference in your code, for instance, connecting a button to a UIButton * declaration.
So, the basic idea here is that Interface Builder has a list of objects it knows how to make. You could make those objects in code, but a lot of the time, you don't need more capability than what IB offers, which is actually quite a lot.
In those cases, IB takes care of that object entirely. It allocates it, and sets the various parameters, and takes care of displaying it.
However, you obviously need to be able to talk to it, as well, most of the time. In order to do this, your declare a pointer to the object, like UIButton *mybutton, but in order to let IB know you want to connect up with it, you add IBOutlet to the declaration.
IB lists the variable, you connect the button up to something in File's Owner, or sometimes firstresponder, and then IB saves that connection data, and sets everything up when the nib gets loaded.

Setting UITextField Delegate Using Interface Builder and Not Updating the Header File

I am stepping into the deep waters of IPhone development. I have the following header file.
//
// FirstProjectViewController.h
// FirstProject
//
// Created by Mohammad Azam on 6/25/10.
// Copyright HighOnCoding 2010. All rights reserved.
//
#import <UIKit/UIKit.h>
#interface FirstProjectViewController : UIViewController<UITextFieldDelegate> {
IBOutlet UITextField *number1TextField;
IBOutlet UITextField *number2TextField;
IBOutlet UILabel *resultLabel;
}
- (IBAction) add: (id) sender;
#end
I want to hide the virtual keyboard when the user clicks the "Return" key. For this my controller implements the UITextFieldDelegate. I also went to the interface builder and hooked up the UITextField delegate to the File Owner using connections. But my header file is never updated. Should it not updated and add a method called textFieldShouldReturn.
I have implemented textFieldShouldReturn method in my implementation file (.m) and it works fine but if the header file never updates with the definition of the textFieldShouldReturn method then how should I ever know that my implementation file needs to implement textFieldShouldReturn method.
Thanks,
If you don't want to share the function with other accessors outside the class, there is no need to add the function to the header file. The delegate protocol of UITextField declares which methods are required to implement and which are optional
regards