On Jun 28, 2009, at 3:00 PM, William Squires wrote:
A few suggestions:
// Configure the cell.
HighScoreSamplerAppDelegate *appDelegate =
(HighScoreSamplerAppDelegate *)[[UIApplication sharedApplication]
delegate];
This particular situation may be a debatable case, but to make a point
for other circumstances: in general you are discouraged from creating
dependencies between your view controllers and other parts of your
application. You are typically encouraged, at the point at which you
create it, to pass to a view controller any data that it will need.
NSDictionary *row = [[appDelegate highScores]
objectAtIndex:indexPath.row]; // Problem here
[...]
Looking in the debugger, I can see the argument "indexPath" is not
nil, but there's no "row" property shown by the debugger when I
expand it. Why didn't I get an exception for "indexPath does not
respond to selector 'row'"? And what is the name of the property I
need here?
This suggests a misunderstanding of "property" -- unfortunately an
overloaded term -- and possibly of the dot syntax.
It is important to appreciate that a "property" -- in both the
abstract sense of a feature of an instance, and in the sense of a
declared @property -- is not required to be "backed" by an actual
instance variable.
The canonical example is probably the "fullName" property of a Person.
Typically "fullName" is a concatenation of "firstName" and "lastName"
-- a derived property. You would usually declare an accessor method
or an @property for "fullName" and yet there would be no "fullName"
instance variable. Similarly for "row" -- there is no instance
variable for "row" in NSIndexPath, it is a derived property (actually
simply the second item in the index path -- the first being the
section)..
Just in case: You may be confusing the dot operator with direct access
of fields of a structure. The dot operator is syntactic sugar for an
accessor method -- see <http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/ObjectiveC/Articles/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-SW17
>.
NSString *full_name = [row objectForKey:@"full-name"];
NSString *score = [row objectForKey:@"score"];
In general (particularly for iPhone), you are encouraged to use custom
classes rather than dictionaries. Dictionaries are much less
efficient than custom classes. (You will also, of course, gain
compiler support for checking method names so you don't accidentally
ask for objectForKey:@"full_name" instead of "@full-name". On a
tangent to which, Cocoa convention is to use camelCase rather than
using separators.)
cell.text = [NSString stringWithFormat:@"%@ - %@", full_name, score];
Again in general you are strongly encouraged to avoid using
autoreleased objects.
I appreciate it is longer-winded to write:
NSString *textString = [[NSString alloc] initWithFormat:@"%@ - %@",
full_name, score];
cell.textLabel.text = textString;
[textString release];
however doing so will ensure that resources are reclaimed as soon as
possible -- it's a good habit to get into.
Using iPhone 3.0 SDK (I hope this post isn't still under NDA since
iPhone OS 3.0 is now out in the wilds...)
The 3.0 SDK is now public.
mmalc
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
