views:

495

answers:

2

Is the NSSearchPathForDirectoriesInDomains function still the best way to get the path of the iPhone Documents directory? I ask because most topics I see on this are dated last year, and it still seems like a pretty cumbersome way of getting to a directory that is used commonly on iPhones. You'd think that there'd be a convenience method for this by now, similar to NSBundle's bundlePath, executablePath, etc.

Just to be clear, this means calling "NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES)" and getting back an array with the Documents path at index 0.

A: 

This works for me, pretty short and sweet

   #define kDOCSFOLDER [NSHomeDirectory() stringByAppendingPathComponent:@"Documents"]

Cheers!

Jordan
Isn't the problem with this that it isn't guaranteed to be device-universal if Apple makes framework changes in the future?
iPhoneToucher
+1  A: 

The Core Data-based application template in Xcode provides this method:

- (NSString *)applicationDocumentsDirectory {

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *basePath = ([paths count] > 0) ? [paths objectAtIndex:0] : nil;
return basePath;
}

So it would seem that Apple continues to endorse getting the documents directory that way. You could put it into a category, I suppose, but I have found it is enough to include that method in the small handful of classes in a given app that need to do work in the documents directory. If you're doing a lot of file stuff all over the place, you might consider refactoring your code a bit to confine those tasks to one or two manager classes.

For me, at least, the third or fourth time I said "Hey, getting the docs directory is a pain in the neck" was the point where I realized some opportunities to shift the file juggling into a dedicated class.

Danilo Campos