This is really a few questions in one, I’m wondering what the performance cost is for these things, as I haven’t really been following a best practice of any sort for these. The answers may also be useful to other readers, if somebody knows these.
(1) If I need the core data managed object context, is it bad to use
#import "myAppDelegate.h"
//farther down in the code:
NSManagedObjectContext *context = [(myAppDelegate.h*)[[UIApplication sharedApplication] delegate] managedObjectContext];
as opposed to leaving the warning you get if you don’t cast the delegate?
(2) What is the cheapest way to hard-code a string? I have been using
return @"myString";
on occasion in some functions where I need to pass it to a variety of places, is it better to do it this way:
static NSString *str = @"myString";
return str;
(3) How costly is it to subclass an object i wrote vs. making a new one, in general?
(4) When I am using core data and navigating through a hierarchy of some sort, is it necessary to turn things back into faults somehow after I read some info from them? or is this done automatically?
1) Casting your delegate doesn’t change anything at runtime, all it does is prevent the compiler from producing a warning. The word “costly” does not apply.
2)
@"Foo"represents a pointer to an NSString object whose contents are ‘Foo’. If there is such a string already in memory, it will be used; otherwise, a new one is created.NSString *fooStr = @"Foo";will place a pointer to the ‘Foo’ string into the variablefooStrThe
statickeyword changes the scope of the variable but otherwise has no performance effect (see this question on static variables for more info).3) “Making a new object” would mean subclassing NSObject. You can’t get away from subclassing, and the only cost difference is the memory footprint of the class you’re inheriting from.
4) You should not worry about faults. Let core data take care of it all for you. It owns the life cycle of managed objects and handles all the memory management and faulting.