I've seen this done both ways, with the [super methodName]; as the first line in a method and as the last line. Is there a best way to do this?
For example:
- (void)viewDidLoad {
[super viewDidLoad];
self.intX = 1;
}
- (void)viewDidLoad {
self.intX = 1;
[super viewDidLoad];
}
- (void)dealloc {
[myControl release];
[super dealloc];
}
In general, when dealing with views you want to take into account the standard behaviour in relation to the changes that your subclass will take.
This is best illustrated with
- (void)drawRect:(NSRect)dirtyRect
Effectively you are drawing your view into the rect but the view itself is doing all of the highlighting and sub view management in there as well.
So, do you need to do something that will occur before or after the super class does it's normal behaviour?
In these cases it is best to test by moving your code before and after the super call. It may also yield some behaviour understanding by not even making the super call to see how it affects what is done.
viewDidLoad is more of an initialiser and typically is more relevant to your subclassed ivars than the actual class itself. If however your subclassed viewDidLoad is affecting the ivars or state of the subclassed view; you likely want to wait until after super so that your changes are't blown away.
In dealloc we call [super methodName]; at last, because before releasing super class you need to clean up child class objects, otherwise they will become orphans.
For example:
Just think about this example. will it make sense to you ?
You will use your dad's money for to get a good education then you will start earning (In your question, get superclass's benifits before you create your own subclass). At your bad time, first you will loose your money and slowly you may drain your dad's money too (In dealloc method, release subclass's object then super class).
Related
Any ideas why a screen saver using just a plain ScreenSaverView subclass with a CAEmitterLayer sublayer would render fine on the primary screen and choppy (as if every 2. frame renders there..) on the secondary screen..?
This is my initialization code:
- (id)initWithFrame:(NSRect)frame isPreview:(BOOL)isPreview
{
self = [super initWithFrame:frame isPreview:isPreview];
if (self)
{
CAEmitterLayer* emitterLayer = [MyEmitterFactory emitterLayer:self];
[self setWantsLayer:YES];
[self.layer addSublayer:emitterLayer];
[self setAnimationTimeInterval:1/2.0];
}
return self;
}
Everything else in this subclass is default (as provided by the Xcode template).
Funny enough, backingStoreType does sound like a good candidate to tweak in a ScreenSaverView subclass using CoreAnimation, alas all other modes except the default one are not to be used as per the docs..
(As the animation is powered by Core Animation it doesn't really matter what I put in setAnimationTimeInterval - or remove the call completely, as experiments have shown)
According to the documentation of NSView setWantsLayer:
To create a layer-hosting view, you must call setLayer: and supply your layer object before you call the setWantsLayer: method; the order of these method calls is crucial.
Furthermore: Which OS version is it? Does the choppiness also come up when the two displays are mirrored (or vice versa)?
Having discovered that awakeFromNib is begin called multiple times, I tried to implement loadView in the following way to prevent (nib loading) initialization from repeatedly occurring, with:
- (void)loadView {
[self viewWillLoad];
[super loadView];
[self viewDidLoad];
}
Looks like a good trick to allowing certain arrays and properties to be set-up in viewWillLoad, but loadView absolutely won't be called.
Why?
I've done much research about this here and through google.
You're not receiving a loadView message because you have this VC and its view in the same nib, with the VC's view outlet set to the view. Since the VC already has a view, it has no reason to go load another one.
loadView is typically not called if you are using a nib (since view is already set). But the real question is why you're trying to fight the view loading process this way. If awakeFromNib is being called multiple times, that suggests you have multiple instances of this class. Each will get a call to awakeFromNib (that is expected behavior). If this is surprising, you should dig into why you have multiple instances. But you shouldn't try to subvert the view-loading mechanism like this.
I am following Facebook's tutorial to post to a user's wall: http://developers.facebook.com/docs/howtos/publish-to-feed-ios-sdk/
and although it is made with a .xib project in mind, I have been able to do everything just fine with my storyboard project so far. However, I have come to the point where I need to put some code into the initWithNibName:bundle: method, but I cannot do this because I am using storyboard. And, since it's hard to tell when exactly the method would be called, I can't just write a method named initWithNibName:bundle: and call it from some other method. If anyone has any idea of how to solve my issue, please say so. Thanks.
I just ran into this problem myself. Storyboards appear to not use initWithNibName:bundle:, but either initWithCoder:(NSCoder *)aDecoder or initWithStyle:(UITableViewStyle)style.
The default implementations of the two methods look like:
- (id)initWithCoder:(NSCoder *)aDecoder
{
self = [super initWithCoder:aDecoder];
if (self) {
// Custom initialization
}
return self;
}
- (id)initWithStyle:(UITableViewStyle)style
{
self = [super initWithStyle:style];
if (self) {
// Custom initialization
}
return self;
}
I've yet to use the initWithStyle version myself, but I'd imagine it's called for a UITableViewController. If in doubt, you could simply add both methods to the file, along with an NSLog() call that prints the method's name (or any other unique string). You can then run it in the simulator to see which is called, and delete the other.
I'd strongly recommend against calling initWithNibName:bundle: yourself from any of the other init methods. Better to just move the code to the correct method.
OK, so Apple brought ARC to us, which is great. After refactoring my Application to ARC almost everything works fine and it is a lot easier now to develop and maintain.
There is just one problem I still can't figure out.
My job management program shows different detail information of proposals, orders and so on in their own windows. So I have a special class where WindowControllers gets allocated and initiated with initWithWindowNibName and then the window is shown with showWindow:
DetailWindowController *proposalWindowController = [[DetailWindowController alloc] initWithWindowNibName:#"ThePorposalWindow"];
[proposalWindowController showWindow:nil];
Before ARC the Instance of the WindowController did the release like shown in the documentation:
- (void)windowWillClose:(NSNotification *)notification
{
[self autorelease];
}
But now with ARC this is not possible anymore and what makes it even worse, in my special class where the WindowController is allocated and initiated, the same windowController is released by ARC because there is no pointer to the windowController.
My idea was to copy the windowController into an mutuable array:
[proposalWindowArray addObject:proposalWindowController];
[[proposalWindowArray lastObject] showWindow:nil];
And in the windowControllers delegate method windowWillClose I post a notification to my special class:
- (void)windowWillClose:(NSNotification *)notification
{
[[NSNotificationCenter defaultCenter] postNotificationName:#"ProposalWindowWillClose" object:[[self window] windowController] userInfo:nil];
}
In my special class I listen to the notification and remove the object from the array:
- (void) proposalWindowWasClosed: (NSNotification *) notification
{
[proposalWindowArray removeObjectIdenticalTo:[notification object]];
}
It works, but I still do not believe that this is the correct way.
Does anybody has the same problem or a tip to make it better?
I'd probably use a delegate approach rather than notifications. Generally it is better to have an external object that keeps track of the open windows. Self-retaining objects, like your old system, break the basic points of object ownership and make it hard to find things (such as "give me a list of open windows"). Non-Singletons that are just "floating" out there often come back to bite you in your architecture (I've had to fix this often enough).
That said, sometimes self-ownership is at least convenient, and at worst not-the-end-of-the-world. So self-own. The only difference is that you need to do it explicitly rather than matching a leak and an over-release (which is what your old code was doing).
Create a private strong property. Assign self to it. That will create a retain loop that will keep you around until you set the property to nil.
I think your alternative approach should be correct, but I don't think you need the second notification. You should be able to do:
- (void)windowWillClose:(NSNotification *)notification
{
[proposalWindowArray removeObjectIdenticalTo:self];
}
Assuming the "proposalWindowArray" is a static NSMutableArray.
Without hacks, there is no elegant way to keep an object retained other than having a strong reference to it in some other object. For example, you could keep a static NSMutableArray/NSMutableSet, add your controller there, and remove it in windowsWillClose:. This will be shorter than posting a notification. To make this reusable, create a WindowControllerRegistry singleton with an array, where you add controllers like this one, and which will automatically listen to NSWindowWillCloseNotification and remove them from its array thus releasing ownership.
As a quick workaround, you could perform retain/autorelease calls from non-ARC file:
my_retain(self);
my_autorelease(self);
// ArcDisabled.mm
void my_retain(id obj) { [obj retain]; }
void my_autorelease(id obj) { [obj autorelease]; }
I had this same issue when I switched to ARC. Your solution works, but you're making it too complicated. You can essentially do what you were doing before by having the window release itself when it closes, but in an ARC compatible manner.
The solution is to simply create a property of your class within the class itself. For your example, in DetailWindowController, you would add the following property:
#property (strong) DetailWindowController *theWindowController;
Then when you create the window with your code above, add one line like so:
DetailWindowController *proposalWindowController = [[DetailWindowController alloc] initWithWindowNibName:#"ThePorposalWindow"];
[preferenceController setTheWindowController:proposalWindowController];
[proposalWindowController showWindow:nil];
Then finally, to have ARC release the window when it is closed like you did with the autorelease pre-ARC, in the DetailWindowController class, simply do:
- (void)windowWillClose:(NSNotification *)notification
{
// Let ARC tear this down and clean it up
[self setTheWindowController:nil];
}
I have a document-based application and I have sub-classed NSDocument and provided the required methods, but my document needs some extensive clean-up (needs to run external tasks etc). Where is the best place to put this? I have tried a few different methods such as:
close
close:
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo
dealloc
If I put it in dealloc, sometimes it gets called and other times it does not (pressing Command+Q seems to bypass my document's deallocation), but it is mandatory that this code gets called without failure (unless program unexpectedly terminates).
Have each document add itself as an observer in the local notification center for NSApplicationWillTerminateNotification. In its notification method, call its clean-up method (which you should also call from dealloc or close).
The correct answer here didn't fit my use case, but the question does. Hence the extra answer.
My use case: closing a document (which may be one of several that are open) but not closing the application.
In this case (at time of writing and unless I'm just looking in the wrong place) the documentation is not as helpful as it could be.
I added a canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo: override in my NSDocument subclass and called super within it. The documentation doesn't say whether you must call super, but a bit of logging shows that the system is providing a selector and a context. This method is called just before the document is closed.
- (void) canCloseDocumentWithDelegate:(id)delegate shouldCloseSelector:(SEL)shouldCloseSelector contextInfo:(void *)contextInfo;
{
if ([self pdfController])
{
[[[self pdfController] window] close];
[self setPdfController: nil];
}
[super canCloseDocumentWithDelegate:delegate shouldCloseSelector: shouldCloseSelector contextInfo: contextInfo];
}
There is some useful discussion of this method on CocoaBuilder. If there's downsides to this approach or better ways of doing this, please comment.