Why should I declare local variables as 'static' inside a method? Like:
static NSString *cellIdentifier = @"Cell";
Is it a performance advantage? (I know what 'static' does; in C context)What does this syntax mean?
[someObj release], someObj = nil;
Two statements? Why should I assign nil again? Is not 'release' enough? Should I do it for all objects I allocate/own? Or for just view objects?Why does everyone copy NSString, but retains other objects (in property declaration)? Yes, NSStrings can be changed, but other objects can be changed also, right? Then why 'copy' for just NSString, not for all? Is it just a defensive convention?
Shouldn't I release constant NSString? Like here:
NSString *CellIdentifier = @"Cell";
Why not? Does the compiler allocate/deallocate it for me?In some tutorial application I observed these (Built with IB): Properties(IBOutlet, with same ivar name):
window, someLabel, someTextField, etc etc...
In the dealloc method, although开发者_如何转开发 thewindow
ivar was released, others were not. My question is: WHY? Shouldn't I release other ivars(labels, textField) as well? Why not?Say, I have 3 cascaded drop-down lists. I mean, based on what is selected on the first list, 2nd list is populated and based on what is selected on the second list, 3rd list is populated. What UI components can reflect this best? How is drop-down list presented in iPhone UI? Tableview with UIPicker? When should I update the 2nd, 3rd list? Or just three labels which have touch events?
Can you give me some good example tutorials about Core-Data? (Not just simple data fetching and storing on 2/3 tables with 1/2 relationship)
How can I know whether my app is leaking memory? Any tools?
Why should I declare local variables as 'static' inside a method? Like: static NSString *cellIdentifier = @"Cell"; Is it a performance advantage? (I know what 'static' does; in C context)
static is exaclt y the same in Objective-C as in normal C.
What does this syntax mean?[someObj release], someObj = nil; Two statements? Why should I assign nil again? Is not 'release' enough? Should I do it for all objects I allocate/own? Or for just view objects?
It depends on the context. It stops there being any chance of over-releasing the object because subsequent release messages will be sent to nil instead.
Why does everyone copy NSString, but retains other objects (in property declaration)? Yes, NSStrings can be changed, but other objects can be changed also, right? Then why 'copy' for just NSString, not for all? Is it just a defensive convention?
NSStrings can't be changed, but NSMutableStrings (a subclass) can. Yes, it's a defensive convention.
Shouldn't I release constant NSString? Like here:NSString *CellIdentifier = @"Cell"; Why not? Does the compiler allocate/deallocate it for me?
Read the Cocoa Memory Management Rules. Did you obtain the constant string by alloc, copy or new? No you didn't. Therefore, don't release it unless you first retain it. Retaining constant strings does no harm.
In some tutorial application I observed these (Built with IB): Properties(IBOutlet, with same ivar name): window, someLabel, someTextField, etc etc... In the dealloc method, although the window ivar was released, others were not. My question is: WHY? Shouldn't I release other ivars(labels, textField) as well? Why not?
Again, the memory management guidelines will help. If the object has retained the ivar (or created it with alloc, copy etc) it needs to be released.
Say, I have 3 cascaded drop-down lists. I mean, based on what is selected on the first list, 2nd list is populated and based on what is selected on the second list, 3rd list is populated. What UI components can reflect this best? How is drop-down list presented in iPhone UI? Tableview with UIPicker? When should I update the 2nd, 3rd list? Or just three labels which have touch events?
Pass. I don't do UI programming on the iPhone.
Can you give me some good example tutorials about Core-Data? (Not just simple data fetching and storing on 2/3 tables with 1/2 relationship)
Apple'as Core Data Programming docs are a good place to start.
How can I know whether my app is leaking memory? Any tools?
Try http://developer.apple.com/iphone/library/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html
2. What does this syntax mean?[someObj release], someObj = nil; Two statements? Why should I assign nil again? Is not 'release' enough? Should I do it for all objects I allocate/own? Or for just view objects?
If you just release an object, then it will become freed object. And if you try to perform any sort of operation on freed object then your app crashes. To avoid such accidents, it is always preferred "assign your object to nil after releasing it". Because we all know any operations performed on nil will not be executed :)
4.Shouldn't I release constant NSString? Like here:NSString *CellIdentifier = @"Cell"; Why not? Does the compiler allocate/deallocate it for me?
Object ownership comes into picture here.The first basic step we must learn in obj-C is Object ownership. If you alloc,retain,copy then you must release.
NSString *CellIdentifier = @"Cell"; here you are not at all allocating it then why re you thinking of releasing it?
6. Say, I have 3 cascaded drop-down lists. I mean, based on what is selected on the first list, 2nd list is populated and based on what is selected on the second list, 3rd list is populated. What UI components can reflect this best? How is drop-down list presented in iPhone UI? Tableview with UIPicker? When should I update the 2nd, 3rd list? Or just three labels which have touch events?
Navigation controller is ment for such kind of requiremtns. Isn't it?
8. How can I know whether my app is leaking memory? Any tools?
Leaks
5 . Shouldn't I release other ivars(labels, textField) as well?
Can you show the complete declaration? You know, when you declare a property, you specify if it should be an assignment with or without retain (assign vs retain). If it's a assignment without a retain, then it would be wrong to release.
@property (retain) IBOutlet NSWindow window; //<--- must release
@property (assign) IBOutlet NSWindow window; //<--- must not release
If you assign without retain, the object could be released without you knowing.
6 . 3 cascaded drop-down lists
The picker-view can handle multilevel selection. Checkout
- (NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView
to tell how many components you need, and then use
- (void)pickerView:(UIPickerView *)pickerView didSelectRow:(NSInteger)row inComponent:(NSInteger)component
to change whats shown in second component based on what got selected in first.
- As Toon said, use as with C.
- I usually just
release
, I think setting to nil is more a style issue. Particularly if you're indealloc
, there's not that much chance of accidental reuse. - NSStrings could be instances of NSMutableString - a copy is usually safer. You would use copy for other classes, where they're conceptually 'value objects' and implement NSCopying.
@""
NSString literals are in memory for the duration of your process - you shouldn't retain or release them.- Check out the Apple documentation here.
- Sounds like multiple UITableViews. Is there a requirement to have them all on screen at once?
- I've found the best way to learn Core Data is to write an application with it.
精彩评论