Hi,
maybe I’m missing here something.
In the following line
objectForKey has a key @“currency” I was wondering where to find other values than @“currency”.
In the documentation I found:
[quote]objectForKey:
Returns the object corresponding to the specified key.
(id)objectForKey:(id)key
The key for which to return the corresponding value. For valid values of key, see “Constants.”[/quote]
under “Constants” I found:
[quote]NSLocale Component Keys
The following constants specify keys used to retrieve components of a locale with objectForKey:.
An NSDictionary key can be of several different object types. The most common, perhaps, is NSString. @“concurrency” is an NSString literal. That is, it’s a string declared on the fly. Alternatively, we could have declared a string in advance, and called it BNRConcurrencyKey or somesuch.
Doing so would afford us an additional level of compiler help: A typo in a named variable is much more likely to be caught by the compiler than a typo inside a string literal (which won’t be caught at all).
Declaring a string in advance and using its variable as the dictionary key also gives us autocomplete on said key anytime we use it.
When doing so at a global level (such as for dictionary keys and NSNotification names), we usually declare the string pointers to be const so that they can’t be changed.
After re-reading your question, I think I didn’t actually answer it.
A key can be just about anything. It’s up to the author of a particular bit of API to define what (s)he intends to use as keys for their dictionary, so the “list of available keys” will vary greatly from one class’ functionality to another.
Think of it this way:
Imagine filling out an application form of some kind. There are fields like “name”, “birthdate”, etc. This is the form asking you for -objectForKey:@“firstname” or somesuch. You recognize the key and answer back @“Matthias”. The form field names could be anything. The side effect is that it’s also possible for a form field to be “bleglblarg”. You would see this field name and think, “I… I don’t know what that means.” and leave that field blank. Similarly, if you send a dictionary the message -objectForKey:@“bleglblarg”, and the dictionary doesn’t have anything stored under that key, the dictionary will just return nil.
This is actually an extension to a much larger underlying feature of the Foundation framework called Key-Value Coding, which we talk about later in the book.
[quote=“MikeyWard”]After re-reading your question, I think I didn’t actually answer it.
A key can be just about anything. It’s up to the author of a particular bit of API to define what (s)he intends to use as keys for their dictionary, so the “list of available keys” will vary greatly from one class’ functionality to another.
Think of it this way:
Imagine filling out an application form of some kind. There are fields like “name”, “birthdate”, etc. This is the form asking you for -objectForKey:@“firstname” or somesuch. You recognize the key and answer back @“Matthias”. The form field names could be anything. The side effect is that it’s also possible for a form field to be “bleglblarg”. You would see this field name and think, “I… I don’t know what that means.” and leave that field blank. Similarly, if you send a dictionary the message -objectForKey:@“bleglblarg”, and the dictionary doesn’t have anything stored under that key, the dictionary will just return nil.
This is actually an extension to a much larger underlying feature of the Foundation framework called Key-Value Coding, which we talk about later in the book.[/quote]
Like Aaron, your explanations are clear and easy to understand. Thanks for taking time out to help us new comers.
From the Apple documentation on the class [color=#0000BF]NSLocal[/color] its a bit unclear as to "how to find out what other keys exist, and what they represent.
From the documentation it refers to constants, and I get the logic for using them, but if I want to see what those constant variables represent, the documentation tells me they are declared in the [color=#0000BF]NSLocal.h[/color] file.
in the example for the use of the constant [color=#0000BF]NSLocaleCurrencyCode[/color] variable key, I see the declaration in the NSLocal.h file as follows.
The actual value of the string NSLocaleCurrencyCode (and most Apple-defined dictionary keys) are implementation details in the .m files for those classes. The .m files, however, have already been compiled into binary form and are parts of the Foundation and other frameworks that we use. Thus, we don’t have access to the actual value being assigned into it any more than we have access to the actual implementation of NSString’s -uppercaseString method. Which is to say, not at all.
All we can do is what I surmise you’ve done already, use NSLog() to log the string’s value at runtime.
More philosophically, from a development perspective, we shouldn’t care what the actual values of those strings are. The key is nothing more than a distinct object that we use to look up a value in the dictionary. We don’t care what the object is, just that the object is only used once in a given dictionary - it’s paired with a single value if any.
If it’s just a matter of satisfying curiosity, well, there you have it.
I thought that it was in the implementation file (.m file) and therefore not accessible.
No I didn’t discover the value (string) of NSLocaleCurrencyCode using NSLog, it was in the book and I was wondering if its not accessible then how does anyone know of it.
You gave me the answer, that is to use NSLog like this
NSLog(@"NSLocaleCurrencyCode is %@",NSLocaleCurrencyCode);
I was looking for the same “currency” definition.
So I went to the Apple Documentation and found NSLocaleCurrencySymbol and NSLocaleCurrencyCode and used them in my code … and it works, jeehoo.
But could nog found “currency”.
Mikey thanks a lot for explaining that is in de .m file.
