views:

165

answers:

4
  1. 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)

  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?

  3. 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?

  4. Shouldn't I release constant NSString? Like here:NSString *CellIdentifier = @"Cell"; Why not? Does the compiler allocate/deallocate it for me?

  5. 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?

  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?

  7. 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)

  8. How can I know whether my app is leaking memory? Any tools?

+1  A: 

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

Manjunath
I can see you like even questions most... ;-)
Vegar
well, if we assign nil, may be some buggy code is gonna be safe. Aren't we making it hard to find that bug (by doing so)?
mshsayem
@Vegar: Well! I dint see it while answering! but yeah I like even questions I guess ;)
Manjunath
@mshsayem: You have asked pretty good question :) But how can you forget to check whether the object is nil before using it?
Manjunath
You don't need to, because sending a message to `nil` does nothing (which is why it's safe—doing nothing is not a crash). If you did need to, you could simply compare the pointer against `nil` using the equality or inequality operator.
Peter Hosey
mshsayem: It depends on the context where the assignment occurs. If the ivar is a cache, `nil` means you have nothing cached (nothing cached yet, or you've thrown out what was cached), so assigning `nil` clears that cache ivar. In `dealloc`, assigning `nil` is pointless and, as you say, hides bugs: By the time an object is in `dealloc`, you should already not be sending it any other messages (such as any that might require the owned object to still exist).
Peter Hosey
+1  A: 

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.

Vegar
(nonatomic, retain) both for window, n other UI objects...
mshsayem
If there is a nil assignment, the old value will be released before the nil is assigned.
Vegar
@Vegar: You are trying out odds! ;)
Manjunath
A: 
  1. As Toon said, use as with C.
  2. I usually just release, I think setting to nil is more a style issue. Particularly if you're in dealloc, there's not that much chance of accidental reuse.
  3. 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.
  4. @"" NSString literals are in memory for the duration of your process - you shouldn't retain or release them.
  5. Check out the Apple documentation here.
  6. Sounds like multiple UITableViews. Is there a requirement to have them all on screen at once?
  7. I've found the best way to learn Core Data is to write an application with it.
Sam
thanks for the apple doc; those tutorials were wrong.
mshsayem
"I usually just release, I think setting to nil is more a style issue." How can you tell like that?
Manjunath
@Manjunath: There's nothing within Apple's memory management guidelines to indicate they recommend setting to nil after releasing. AFAIK nothing in the framework will work incorrectly if you don't set to nil after releasing. Most releasing is done at the end of a local scope or in dealloc, for the rest, you'll have different failure modes in your buggy code. I consider it a style issue.
Sam
+4  A: 

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

JeremyP