I am facing some difficulties figuring out what this function in the Apple tutorials stands for:
[[MyViewController alloc] initWithNibName:#"MyViewController" bundle:[NSBundle mainBundle]]
My questions are: what does the "#" stand for before MyViewController?
Addionally, as I am following this tutorial, I was wondering: There are to nibs in my project: the automatically generated MainWindow.xib and MyViewController.xib – I was wondering: why do I have two if I only need one?
Thanks in advance!
The #-sign before a string literal means that the string is an instance of NSString.
#"Hello" <-- NSString object
"Hello" <-- Null-terminated char array (C-string)
You can even send messages to it:
[#"Hello" stringByAppendingString:#" World!"]
You will use NSString objects more often than C-strings.
If you want to convert a C-string to an NSString object (if you are using C libraries that return such strings for example), you could use this:
char *myCstring = "Hello, World!";
NSString *myString = [NSString stringWithUTF8String:myCstring];
About the two nibs: actually you don't need any nibs at all, but Apple likes to decrease performance by using a nib that only has one window. I don't know why they do it, but you can create a window in code with only one line, which compiles and runs much faster.
In your applicationDidFinishLaunching: method:
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
self.window.rootViewController = [[[MyViewController alloc] initWithNibName:#"MyViewController" bundle:nil] autorelease];
// now you can remove the MainWindow.xib nib.
Personally I prefer to use no nibs at all, but that's one's own choice.
Related
I have a thread that needs information from the GUI before starting. What I mistakenly tried to do at first was create pointers to the NSTextFields like so:
NSString *info = [gui_field stringValue];
//launch thread
[self performSelectorInBackground:#selector(myMethod:) withObject:info];
This caused problems when I tried to manipulate "info" from within the thread. I assume this is the case because technically, it was still pointing to the string representation of the NSTextField outside the thread.
This fixed the problem:
NSString *info = [[gui_field stringValue] copy];
I assume this made a copy (with its own memory space) that did not rely on the NSTextField at all. I also assume this should be thread-safe.
Is this the appropriate way to do this? I suppose I could have done this:
NSString *info = [[NSString alloc] initWithString:[gui_field stringValue]];
Are the two producing the same result? And do I have to explicitly call release on the string when using "copy" or is it autoreleased by default?
Update: or, perhaps I could just send a pointer to the thread, and copy the string with "autorelease," adding it to the thread's autorelease pool:
NSString *info = [gui_field stringValue];
//launch thread
[self performSelectorInBackground:#selector(myMethod:) withObject:info];
-(void)myMethod:(NSString*)info
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *copied_str = [[info copy] autorelease];
//do stuff
[pool drain];
//copied_str should now be history
}
This way, I don't have to worry about explicitly releasing copied_str. It will be gone once the thread ends.
No need to rely on luck :)
alloc, copy, new and mutableCopy mean you own the object. Both of those will give you a retained object. If you're managing memory, you need to release it.
By convention, other methods will give you an autoreleased object.
As an example, if you want an autoreleased object, you can call:
NSString *str = [NSString stringWithString:yourString];
See the memory management guide:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
Specifically the four rules here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
You own any object you create
You create an object using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy).
Finally, both will copy the string.
from the NSString docs:
initWithString:
Returns an NSString object initialized by copying the characters from another given string.
copy is from NSObject. It defines copy as:
Return Value
The object returned by the NSCopying protocol method copyWithZone:, where the zone is nil.
NSString implements the NSCopying protocol so copy will return a copy of the string.
There is one exception where the string isn't copied by initWithString - if you pass a string literal it will wrap the pointer to the constant and ignore retain/release. See here if you're curious: Difference between NSString literals
NSString *info = [[gui_field stringValue] copy];
NSString *info = [[NSString alloc] initWithString:[gui_field stringValue]];
Those do pretty much the exact same thing.
[self performSelectorInBackground:#selector(myMethod:) withObject:info];
-(void)myMethod:(NSString*)info
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *copied_str = [[info copy] autorelease];
No, you can't do that. Even accessing the GUI string object just to copy it could be enough for a crash.
I think this is a case where the usually recommended patterns for memory management really don't provide a great solution, so you can go outside them.
NSString *info = [[gui_field stringValue] copy];
//launch thread
//pass ownership to callee
[self performSelectorInBackground:#selector(myMethod:) withObject:info];
// myMethod owns info!
-(void)myMethod:(NSString*)info
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[info autorelease];
Another option is retain infoCopy as an instance variable somewhere. That would let you use normal memory management patterns, but it doesn't fit semantically. It's really not an instance variable, it's an argument.
"I asked for an argument."
"This is abuse."
How should I set a retained property when creating an object using alloc and init? (Without using autorelease)
With this line in the header (and the corresponding #synthesize line in the implementation):
#property(retain)UIWebView *webView;
These are the three options I have (I think):
UIWebView *tempWebView = [[UIWebView alloc] init];
[tempWebView setDelegate:self];
tempWebView.hidden = YES;
self.webView = tempWebView;
[tempWebView release];
(This one seems the best concerning memory management but it's more lines of code and involves a stupid variable name, so a decrease in readability)
self.webView = [[UIWebView alloc] init];
[self.webView release];
[self.webView setDelegate:self];
self.webView.hidden = YES;
(This one it's more obvious whats happening but the memory management doesn't seem that great, also Xcode's Analyser doesn't like it)
webView = [[UIWebView alloc] init];
[self.webView setDelegate:self];
self.webView.hidden = YES;
(This one is the shortest, it's more obvious than the first example whats happening. But it bypasses the setter, so should a custom implementation of the setter be implemented later it won't work in this case)
So which example should be used, or is there a better way?
The best option, IMO, is the one you don't like, i.e. using autorelease:
self.webView = [[[UIWebView alloc] init] autorelease];
If you do not want to and want a one-liner initialization, the only option is your third one:
webView = [[UIWebView alloc] init];
since all the others requires an explicit line to do an extra release.
I don't see it as bad, especially when it belongs to the init method and you don't reassign it elsewhere without using the property, and I myself use it when it seems reasonable to me.
What works really well with retained properties are convenience constructors like:
self.image = [UIImage imageWithContentsOfFile:xxxxxxx];
So, possibly if you really find that none of the options you listed is fine with you, you might add a category to UIWebView and a convenience constructor doing the autorelease job for you:
self.webView = [UIWebView webViewWith......];
I often do something like:
CoolViewController *coolViewController = [[CoolViewController alloc] init];
[self.navigationController pushViewController:coolViewController animated:YES];
[coolViewController release];
How would I, in a category of UINavigationController, override forwardInvocation: so that I could just instead do:
[self.navigationController pushCoolViewControllerAnimated:YES];
Please include the relevant code in your answer, not just an explanation. Thank you!
Feel free to comment on whether this is good practice. I'm also asking this for educational purposes, but it seems to me that in this case, the simplification in code may outweight the unnoticeable (correct?) cost in processing time & memory usage. Also, I come from a Ruby background and love to use dynamic programming to simplify things, e.g., dynamic finders (e.g., find_by_name) in Rails.
Bonus points if you could implement pushCoolViewControllerAnimated:withBlock and invoke the block after initializing the view controller, allowing me to set certain instance variables on the view controller created.
UPDATE: I just remembered that ARC is coming soon. So this specific example may not be so helpful then, but still a great exercise/example that could be used in other cases, e.g., dynamic finders for Core Data & passing a block to configure the NSFetchRequest.
Use the dynamic method resolution mechanism described in the Objective-C Runtime Programming Guide, specifically, +[NSObject resolveInstanceMethod:]:
#implementation UINavigationController (FWD)
+ (BOOL)resolveInstanceMethod:(SEL)sel
{
NSString *name = NSStringFromSelector(sel);
NSString *prefix = #"push";
NSString *suffix = #"Animated:";
if ([name hasPrefix:prefix] && [name hasSuffix:suffix]) {
NSRange classNameRange = {[prefix length],
[name length] - [prefix length] - [suffix length]}
NSString *className = [name substringWithRange:classNameRange];
Class cls = NSClassFromString(className);
if (cls) {
IMP imp = imp_implementationWithBlock(
^(id me, BOOL animated) {
id vc = [[cls alloc] init];
[me pushViewController:vc animated:animated];
[vc release];
});
class_addMethod(cls, sel, imp, "v#:c");
return YES;
}
}
return [super resolveInstanceMethod:sel];
}
#end
Of course, if UINavigationController already uses +resolveInstanceMethod:, you've now broken it. Doing this in a subclass of UINavigationController, or using method swizzling to enable invoking the original implementation, would solve that problem.
The version accepting a post-creation block is a straightforward extension (change the block parameters, change the type encoding, change the selector name pattern and how you extract the intended class name).
I have a simple design question. This code is in my appDelegate. I use it to load all images in a NSDictionary categories. Successively I pass the dictionary to the init method of the main NavigationViewController. Successively I pass the dictionary through all viewControllers pushed by the NavigationViewController, because I'm using the same icons everywhere.
I was wondering if this is the correct approach, or am I just wasting memory. In other terms, should I pass the dictionary through viewControllers, or should I use a singleton.. or what ? The reason I'm currently adopting this approach is that I don't have any reference from viewControllers to the app delegate.
//load categories pictures
NSArray *categoriesKeys = [[NSArray alloc] initWithObjects:
#"comedy",
#"commercial",
#"education",
#"family",
#"media",
#"music",
#"performing",
#"sport",
nil];
categories = [[NSMutableDictionary alloc] init];
for (NSString *categKey in categoriesKeys) {
UIImage * categImage = [UIImage imageNamed:[[#"icons/" stringByAppendingString:categKey] stringByAppendingString:#".png"]];
[categories setObject:categImage forKey:categKey];
}
Update:
viewController init method
FlickrAppDelegate* appDelegate = [UIApplication sharedApplication].delegate;
categories = appDelegate.categories;
categKeys = appDelegate.categoriesKeys;
I would probably create a Singleton. A lot of people like placing shared code in the AppDelegate, but then that file gets cluttered and it becomes unclear what is going on throughout the file. Having a Singleton dedicated to this logic separates the code and makes it easier to change.
put all the code in your appDelegate in a function and call that function in applicationDidFinishLaunching method . Access dictionary anywhere in the application like this
appNameDelegate* appDelegate = [UIApplication sharedApplication].delegate;
[appdelegate.categories objectForKey:#"WhatEver"];
I'm programming an iPhone app and I had a question about memory management in one of my methods. I'm still a little new to managing memory manually, so I'm sorry if this question seems elementary.
Below is a method designed to allow a number pad to place buttons in a label based on their tag, this way I don't need to make a method for each button. The method works fine, I'm just wondering if I'm responsible for releasing any of the variables I make in the function.
The application crashes if I try to release any of the variables, so I'm a little confused about my responsibility regarding memory.
Here's the method:
FYI the variable firstValue is my label, it's the only variable not declared in the method.
-(IBAction)inputNumbersFromButtons:(id)sender {
UIButton *placeHolderButton = [[UIButton alloc] init];
placeHolderButton = sender;
NSString *placeHolderString = [[NSString alloc] init];
placeHolderString = [placeHolderString stringByAppendingString:firstValue.text];
NSString *addThisNumber = [[NSString alloc] init];
int i = placeHolderButton.tag;
addThisNumber = [NSString stringWithFormat:#"%i", i];
NSString *newLabelText = [[NSString alloc] init];
newLabelText = [placeHolderString stringByAppendingString:addThisNumber];
[firstValue setText:newLabelText];
//[placeHolderButton release];
//[placeHolderString release];
//[addThisNumber release];
//[newLabelText release];
}
The application works fine with those last four lines commented out, but it seems to me like I should be releasing these variables here. If I'm wrong about that I'd welcome a quick explanation about when it's necessary to release variables declared in functions and when it's not. Thanks.
Yes, you need to release them, but you need them just a little longer than beyond the end of your function.
The solution is called autorelease. Just replace release with autorelease and the objects stay around until the program gets back to the runloop.
When the program gets back there, everybody interested in one of the objects should have sent a retain message to it, so the object will not be deallocated when released by the NSAutoreleasePool.
edit actually, looking at your code, there's a lot more wrong with it. E.g. this:
UIButton *placeHolderButton = [[UIButton alloc] init];
placeHolderButton = sender;
doesn't make sense. First you allocate an object, then assign (a pointer to) it to variable placeHolderButton. That's fine.
Then you assign sender to that same variable. The reference to the object you just created is now lost.
Not sure if I get what you want, but this would be better:
-(IBAction)inputNumbersFromButtons:(id)sender {
UIButton *placeHolderButton = sender; // this is still a little useless, but ok
int i = placeHolderButton.tag;
NSString *addThisNumber = [NSString stringWithFormat:#"%i", i];
NSString *placeHolderString = firstValue.text;
NSString *newLabelText = [placeHolderString stringByAppendingString:addThisNumber];
[firstValue setText:newLabelText];
}
No allocs, so no releases necessary. The strings returned by those functions are already added to the autoreleasepool, so they will be deallocated automatically (if needed).
Well. Release them when you are done with them. The sooner the better. Some objects are tricky if you are new to memory management.
Release them in the dealloc method then.
The auto release pool can be handy, some people might disagree according to the performance issues.
you need to release anything containing the word new, alloc/init or copy.
also, you don't need to alloc/init this:
UIButton *placeHolderButton = [[UIButton alloc] init];
placeHolderButton = sender;
another way of doing this is:
UIButton *placeHolderButton = (UIButton *)sender;
in your version, it is allocating an instance with a retain count of +1, but you are immediately replacing the reference, so there is no way of releasing the memory later.
you are creating a lot of instances with alloc/init, and then replacing their references with autoreleased instances.
you could use
NSString *placeHolderString = [placeHolderString stringByAppendingString:firstValue.text];
instead of
NSString *placeHolderString = [[NSString alloc] init];
placeHolderString = [placeHolderString stringByAppendingString:firstValue.text];
which is again replacing a manually managed instance created on the first line, with an autoreleased instance on the second.
infact you could replace every alloc/init in this with the factory method and not have to deal with memory at all in it as they would be autoreleased instances.
-(IBAction)inputNumbersFromButtons:(id)sender {
//cast sender as a UIButton to suppress compiler warning, and allow us to reference it as placeholder button
UIButton *placeHolderButton = (UIButton *) sender;
int i = placeHolderButton.tag;
NSString *addThisNumber = [NSString stringWithFormat:#"%i", i];
[firstValue setText:[firstValue.text stringByAppendingString:addThisNumber]];
}
If you look at the class docs for NSString, any method with a + next to it(ie +stringWithString:(NSString *)string) is a class method, don't use these methods on a reference after you have called alloc/init on it.
I find it puzzling that you use alloc/init on a UIButton.
I always use the factory methods, e.g.
UIButton* aButton = [UIButton buttonWithType:UIButtonTypeCustom];
This returns an autoreleased button which I immediately add to its intended parent view.
Can't confirm it right now, but it looks as if the SDK caches UIButton instances and performs some optimizations behind the scenes. Every time I tried to retain a UIButton ivar, performance has degraded (especially when there is many sub views on screen)