I'm reading the book IOS Programming The Big Nerd Ranch Guide 4th Edition.
I have come to the section where I should make a outlet connection.
I have the following code:
#interface BNRQuizViewController ()
#property (nonatomic, weak) IBOutlet UILabel *questionLabel;
#property (nonatomic, weak) IBOutlet UILabel *answerLabel;
#end
#implementation BNRQuizViewController
#end
In the book it says:
I only get this in my xcode:
Anyone who can help me?
You probably didn't set the custom class on your xib, in the right sidebar:
However, you should refrain from creating the view controllers and xibs separately, I suggest you use storyboards, or create a xib along with your header and implementation files by selecting the proper checkmark to avoid having xibs with a different name and deattached from your view controller.
Related
This is a "how-to" for related question:
cocoa windowDidEnterFullScreen not being called
Using the Xcode (9.1) macOS "game" template -
I would like to create a simple NSWindowDelegate using the AppDelegate class. However I can't seem to connect the given NSWindow outlet to anything.
// AppDelegate.h
#import <Cocoa/Cocoa.h>
#interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate>
#property (assign) IBOutlet NSWindow *window; // won't connect
#end
I assume I'm supposed to connect to a "Window" within the storyboard. This is what happens when I try to connect - the inspector does not show up.
What am I missing here?
Note: I'm just playing around so I don't care if AppDelegate is the right place or not, I just want something to work.
EDIT 1
Using suggestion from answer, I've tried connecting the 'TestFullscreen' window to the AppDelegate object, but it still won't connect, either from the AppDelegate inspector or the property declaration in the code.
You should have a Delegate object and that is what should hook up to your window.
It looks like you are currently attempting to connect the window to itself. Also it doesn't appear you have a view for the window either, so you'll need to add that for the window content.
A workaround is to simply create non-Workspace project.
Editing the XIB allows you to connect the Window delegate outlet to the AppDelegate, after it has NSWindowDelegate protocol specified.
I am using XCTestKit for unit testing in my app using Objective-C.
I need to test the default values of textfields on my screen but the IBOutlets are declared under .m file.
Is there any way to access those variables, or any other approach to test the values in UnitTest classes.
Let's say your .m file has something like
#interface MyClass ()
#property (nonatomic, strong) IBOutlet UILabel *myLabel;
#end
One approach is to expose this in your test file like this by copying and pasting to your test file, but giving the category a name:
#interface MyClass (Testing)
#property (nonatomic, strong) IBOutlet UILabel *myLabel;
#end
The advantage of this approach is it keeps the outlet hidden from your -public interface.
The disadvantage is that the duplication means if you change anything about the property declaration, you have to remember to repeat it in your test file.
Another approach is to move your outlet from your .m to your .h.
The advantage of this approach is that it acknowledges that testing is a valid client of your API, and avoids duplication.
The disadvantage of this approach is that you will have more in your API than you want all clients to know.
I prefer the second approach. What I do then is soften the disadvantage by not treating the class interface as the "interface for everybody". Instead, I split things off into protocols, exposing only what particular clients need for their interactions alone.
I often heard, that it is not good to organize classes the way every class knows every other class.
So I try to let the classes that are as a property in other classes not know about their parents. But with UIView I can't make it happen.
The question comes from a more generic background, because the problem occurs not only on UIViews.
If I have a car as object with 4 wheels as 4 instance variables and when the left front wheel bursts. The left rear wheel should get a message. How should I design the system in a good way?
An example with UIView in Objective-C:
I have an custom UIView filling the whole screen. managing all the layout. Let's say only 2 subviews keep it simple.
#interface BackgroundView : UIControllerView {
CustomViewA *buttonA;
CustomViewB *buttonB;
}
#end
#interface CustomViewA : UIButton
#interface CustomViewB : UIButton
Now if someone presses button A, button B should do something (e.g. turn red).
There are several options I see:
Set the delegate of button A to button B, so all event of A goes to implementation file of B. Problem if not all events have to do with button B.
Create a singleton of BackgroundView and let button A get the property of button B or call a method in BackgroundView that does forward my call to button B. Problem if I want more than one Background, could create a even higher class to have the two BackgroundViews (doesn't sound nice).
Call parent implemented for UIViews and then like 2. call a method or change it directly. Problem when not using UIView, copy the functionality to other 'parent' classes ?
Is there a better way of solving such a problem? Or can I optimize one method greatly?
#Odrakir mentions Model-View-Controller here, and they're right -- that should be your first stop. In case it helps, here's how you might apply that pattern to your example:
You have a model class with a property color. In a document-based application, the document typically is the model. In a non-document-based application, it's common to hang the model off of the application delegate instance. For simplicity's sake, let's say we're in the latter case. You might have the following classes:
// "Model"
#interface MyModel : NSObject
#property (nonatomic, readwrite, copy) UIColor* color;
#end
// AppDelegate
#interface MyAppDelegate : UIResponder <UIApplicationDelegate>
#property (nonatomic, readonly, retain) MyModel* model;
#end
// "View"
#interface CustomViewA : UIButton
#end
#interface CustomViewB : UIButton
#end
// "Controller"
#interface MyViewController : UIViewController
#property (nonatomic, readwrite, assign) IBOutlet UIView* buttonA;
#property (nonatomic, readwrite, assign) IBOutlet UIView* buttonB;
- (IBAction)doActionA: (id)sender;
- (IBAction)doActionB: (id)sender;
#end
The basic pattern is this: Actions from the view trigger model-modifying actions by the controller (the target/action pattern). To achieve this, you would hook them up by connecting the action of button A to -doActionA: on the controller ("File's Owner" in IB) and (likewise for B). Then the action methods on the controller, when triggered, should modify the model, and invalidate any views that would need to be redrawn as a result of the model change. You might do this by plugging the views into IBOutlets on the controller and having the controller call [self.buttonA setNeedsDisplay]. Then, when your view draws, it should read, from the model, any state that it needs to draw correctly.
It's worth mentioning that on MacOS, you can eliminate the manual invalidation step by using bindings to link the view to the model. In that case, changes to the model will automatically invalidate the view. iOS/UIKit doesn't have bindings, so you have to do this invalidation by hand.
Probably all that logic belongs in a ViewController who knows everything about the views he controlls but the views don't know anything about the view controller or about each other.
Views should communicate with the view controller through delegation (or target-action) and is the view controller the one that should make decisions and maybe, forward messages to other views.
By the way, take a look at Stanford courses in iTunes University. I think it's the first or second class where they talk about MVC (Model View Controller). It's going to help a lot: https://itunes.apple.com/us/course/coding-together-developing/id593208016
Some background: I'm making a Obj-C project for some numerical analysis, and want to add a graph. I found core-plot, and had no problem adding the framework and QuartzCore frameworks to my project.
My question now is how to actually utilise it - I have a project with an interface through Interface Builder (MainMenu.xib), an AppDelegate and another class used for modelling the mathematics. I have searched the internet and can only find tutorials for its use within iOS, which isn't what I'm doing - and I don't understand how to convert that to OSX.
I had assumed that I would add a custom view to the MainMenu.xib and link that to a new property using someting along the lines of
#property (assign) IBOutlet NSView *graph;
Although now that I look at it, putting a NSView object inside a NSObject interface seems silly.
Thanks in advance for your help!
Update 1: So I changed my code to
#property (assign) IBOutlet CPTGraphHostingView *graph;
And changed the property of the custom view to the same, CPTGraphHostingView. The two are now linked, and I have an outlet called "graph" to play with. The challenge is now putting a graph into that space.
Thanks again!
sorry If am I being too picky on this one but I am learning iOS programming now and I've seem some people who declare the IBOutlet like this:
IBOutlet attached to property
#import <UIKit/UIKit.h>
#import "CustomCell.h"
#interface CustomTableViewController : UITableViewController {
CustomCell *customCell;
}
#property (nonatomic, retain) IBOutlet CustomCell *customCell;
#end
And some declaring like this:
IBOutlet attached to the declaration inside the interface
#import <UIKit/UIKit.h>
#import "CustomCell.h"
#interface CustomTableViewController : UITableViewController {
IBOutlet CustomCell *customCell;
}
#property (nonatomic, retain) CustomCell *customCell;
#end
which one is the proper way to declare it? Are any differences between them?
If someone know to explain why do they put it on different places it would be awesome to learn.
Thanks a lot :)
Both of those are still "inside the interface" so your title it a bit confusing but I see what you are asking.
In many cases the result of either approach will be the same but they are different. An IBOutlet property will call the property's setter method which gives you an opportunity to override that setter if setting that property should have some side effect.
I prefer to use outlets on properties because I think it makes the memory management of the objects loaded from the nib much clearer. Take a look at memory management of nib objects and I think you will see what I mean.
Objects in the nib file are created with a retain count of 1 and then autoreleased. As it rebuilds the object hierarchy, UIKit reestablishes connections between the objects using setValue:forKey:, which uses the available setter method or retains the object by default if no setter method is available. This means that (assuming you follow the pattern shown in “Outlets”) any object for which you have an outlet remains valid. If there are any top-level objects you do not store in outlets, however, you must retain either the array returned by the loadNibNamed:owner:options: method or the objects inside the array to prevent those objects from being released prematurely.
IBOutlet ivars will call setters for those ivars if they exists and directly retain the object loaded from the nib if no setter is found.
Advertising the property as the IBOutlet at least makes it clear that the property's setter will always be used and follow whatever memory management rule has been set for that property.
Finally I argue that IBOutlets are part of the public interface of a class and it is therefore better to expose methods (via a property) for working with them eager than using -setValue:forKey: to manipulate the backing ivars which should be an implementation detail.
The two styles are interchangeable, there is no difference in the generated code or the way objects will be loaded from a nib. Really.
However, both styles have a redundant line. Simply leave out the ivar declaration. Just the line
#property (nonatomic, retain) IBOutlet CustomCell *customCell;
is sufficient in the modern runtime.
If you have a complex project, I suggest moving all the outlets out of the public interface into a separate header file. Most outlets are private interface, the only reason to have them in a header is so Interface Builder can find them.
You can declare both ways, there is no difference actually.
But, here is the thing:
If you need your class to have some ivar with a special behavior or it has to be accessed from outside, etc, and it has to be a property, then I will say you have 2 options to choose from (attached to the property and inside the class interface).
If that is not your case, don't create a property, is not necessary, just do it inside your class interface.
Hope it helps ;)