Code:
-(void)readFile{
NSError *error;
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); //1
NSString *documentsDirectory = [paths objectAtIndex:0]; //2
NSString *path = [documentsDirectory stringByAppendingPathComponent:@"EventAddress.plist"]; //3
NSLog(@"%@", path);
NSFileManager *fileManager = [NSFileManager defaultManager];
if ([fileManager fileExistsAtPath: path]) //4
{
NSString *bundle = [[NSBundle mainBundle] pathForResource:@"EventAddress" ofType:@"plist"]; // 5
NSLog(@"%@", bundle);
[fileManager copyItemAtPath:bundle toPath: path error:&error]; //6
NSLog(@"%@", fileManager);
}
NSString *pathss = [[NSBundle mainBundle] bundlePath];
NSLog(@"%@", pathss);
NSMutableArray *plist = [[[[NSDictionary dictionaryWithContentsOfFile:path] objectForKey:@"New Item"] mutableCopy] autorelease];
NSLog(@"%@", plist);
}
...
Is this alright?
It's not what I suggested:
3. Add a check for the existence of a file at the path given by the 'bundle' variable. That is, confirm that the file you're trying to copy from exists. Post the output.
4. You don't check the BOOL returned from copyItemAtPath:, so you have no way to tell whether it worked or it failed.
You aren't doing either of those things.
To do #3, you'd add code something like this (untested, typed in directly):
Code:
BOOL exists = [fileManager fileExistsAtPath: bundle];
NSLog(@"bundle exists: %d", (int)exists );
This should go before the copyItemAtPath:bundle.
To do #4, you'd add code something like this (also untested):
Code:
BOOL copied = [fileManager copyItemAtPath:bundle toPath: path error:&error]; //6
NSLog(@"copied: %d", (int) copied );
if ( ! copied )
{ ... do something to handle the error ... }
If the output confirms that the file exists, and is correctly copied, then you have evidence it was actually copied. If the output shows otherwise, then you have evidence it wasn't.
The NSLog of fileManager is misplaced, if you expect it to be confirmation of a non-nil NSFileManager. It should be placed before the first use of fileManager. Then you can say it confirms the object's existence before it's used. Where it's placed now, it's too late to confirm anything.
Confirmation is a step-by-step trail of evidence. It should show that what you expect to happen is actually happening. Every piece of evidence should answer a logically relevant question: What is this value at this point? Did something just complete successfully or not?
As it turns out, the problem wasn't in the file-copying, or even the loading of the file. The problem was in not using the resulting plist object correctly.
You should be able to design and write code that confirms the contents of a plist object. Knowing how to confirm things means you have to understand what things really are. If you don't really understand what things are, then you won't know what to confirm. The process of thinking about how to confirm something can lead you to a better understanding of what it is, or it can even correct a misunderstanding.
Code:
NSString *path = [[NSBundle mainBundle] pathForResource:@"EventAddress" ofType:@"plist"];
NSMutableDictionary *myDictionary = [[NSMutableDictionary alloc] initWithContentsOfFile:path];
If that code works, then it suggests your plist file isn't what you originally posted. Your original post shows an Array containing two Strings.
If you only showed part of your plist, then the lesson is to use the entire plist, not just one part, and to post complete data, not just one part.
If you changed what's in your plist, then the lesson is to show what you changed.
There could be other reasons why that code works. It's impossible to say without seeing the complete plist data.
Code:
NSArray* allmyKeys = [myDictionary allValues];
The name of the variable
allmyKeys is misleading. It actually holds all the
values from the dictionary, not all the
keys.
You should also read the reference doc on allValues, where it says "The order of the values in the array isnt defined." This means you can't rely on a particular value being at index 0 in the returned NSArray. Which means that your code relying on things being at index 0 could fail unexpectedly.
