I am using cocoa http server on iPhone. Its working fine if I set a root document. But I want to list all the contents of my "Document directory". I tried setting the root document to the document's directory path
NSArray *directories = NSSearchPathForDirectoriesInDomains(NSDocumentsDirectory, NSUserDomainMask, YES);
NSString *rootDir = [directories lastObject];
[httpServer setDocumentRoot:rootDir];
(I tried getting the path programatically)
But its not working ... any idea on this or is there any opensource project that I can use to list the content of my document directory?
Update : here is link to the project (cocoa http server)
You could try Mongoose and it's Objective-C Wrapper. It seems Mongoose natively supports directory listing.
You must use;
NSArray *directories = NSSearchPathForDirectoriesInDomains(NSDocumentsDirectory, NSUserDomainMask, YES);
NSString *rootDir = [directories lastObject];
[httpServer setDocumentRoot:rootDir];
because the GUID for the app changes on every install (i.e. the number starting with 8D41 in your dir above).
Related
here i created local root for document storage but i want to implement iCloud.so i need to create iCloud Root and also i will check if iCloud available or not. if it is possible to create like Method. here i added my local root method code
- (NSURL *)localRoot {
if (_localRoot != nil) {
return _localRoot;
}
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *artdirectoryPath = [documentsDirectory stringByAppendingPathComponent:#"/Me"];
_localRoot=[[NSURL alloc]initFileURLWithPath:artdirectoryPath];
return _localRoot;
}
You find the iCloud "root" directory using:
NSURL *url = [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];
If you have only one ubiquity container for your app, you can pass nil for the argument, otherwise you must pass the container identifier.
You can also use this to check if iCloud is available to your app-- if it returns nil, you can't use iCloud. It's not the best way to check for availability though, because it can block for a while. For a quick, non-blocking check, use this:
id token = [[NSFileManager defaultManager] ubiquityIdentityToken];
And then be sure to observe NSUbiquityIdentityDidChangeNotification in case the availability changes.
However: this is nowhere near enough to start using iCloud for documents. You can't just read/write files in that directory and have iCloud do the right thing. At an absolute minimum you'll need:
NSMetadataQuery to find documents that exist on the cloud server but are not downloaded locally.
-[NSFileManager startDownloadingUbiquitousItemAtURL:error:] to tell iCloud to begin downloading documents you've found with the metadata query.
Coordinated access via NSFileCoordinator, and notifications of changes via NSFilePresenter.
Apple has a lot of documentation, and videos from WWDC that will help with this.
I hv spent quite a while but no luck on following question:
I tried to access Document directory.
Both following codes work perfectly. Could someone tell me whats the difference between
last object and objectAtIndex:0
NSArray *searchPaths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentPath = [searchPaths lastObject];
or
NSString *documentPath = [searchPaths objectAtIndex:0];
The most close question was How to get URL for application's document directory iPhone, but it didn't explain the difference between lastObject and objectAtIndex:0.
I have read thru Apple Developer Library. It only says 'The directory returned by this method may not exist. This method simply gives you the appropriate location for the requested directory. Depending on the application’s needs, it may be up to the developer to create the appropriate directory and any in between.' Someone please help, thx.
In this case, there is no difference between [searchPaths lastObject] and [searchPaths objectAtIndex:0], because searchPaths contains only one entry. The user domain only contains one document directory.
If you try this you'll get different results:
NSArray *searchPaths = NSSearchPathForDirectoriesInDomains(
NSApplicationDirectory, NSAllDomainsMask, YES);
searchPaths may contain more than one directory if you look with NSAllDomainsMask.
Since Xcode 5, best practice is:
NSString *documentPath = [searchPaths firstObject];
I have this :
NSURL *url = [NSURL fileURLWithPath:#"/Users/myusername/Library/Application Support/iPhone Simulator/4.2/Applications/5ABF1395-4A80-46C0-BD4A-419ED98CE367/Documents/DBV/v.m4v"];
Then I launch movieViewController but it always crashes.. This code doesn't work on the iPhone simulator neither on the device... How can I fix it ?
EDIT :
Before to write file path by hand, I used the correct way to select a folder.
[NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0]
Then i got this log:
file://localhost/Users/myusername/Library/Application%20Support/iPhone%20Simulator/4.2/Applications/5ABF1395-4A80-46C0-BD4A-419ED98CE367/Documents/DBV/v.m4v
Then I thought it was because of spaces in folder name , so i decided to write the full path by hand for debugging (replacing each %20 by space)
EDIT 2 : Notice : I'm trying to access a dynamically created file in Documents folder, not a file from my bundle.
For files in documents, you should be getting the path from NSSearchPathForDirectoriesInDomains.
//get list of document directories in sandbox
NSArray *documentDirectories = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
//get one and only document directory from that list
NSString *documentDirectory = [documentDirectories objectAtIndex: 0];
Then you append the file name to that.
I need to read, edit and save one xml file. In other words, I want to write again over the same file and not to create a new xml file. Reading and editing parts work, but not the saving.
The Linq-to-Xml code for saving is simply:
doc.Save(this.Path);
This works in iPhone Simulator but throws System.UnauthorizedAccessException on the device. The xml file is decorated as "content" in MonoDevelop.
Any help appreciated.
/pom
You need to save the file into one of the locations that you have write permissions on:
The /Document directory can be retrieved using:
var documents = Environment.GetFolderPath (Environment.SpecialFolder.Personal);
Our "How To Store Files" page has more details:
http://wiki.monotouch.net/HowTo/Files/HowTo:_Store_Files
You are only allowed to save into your application's document directory. You can get it like this:
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
What is the value of this.Path?
var documents = Environment.GetFolderPath (Environment.SpecialFolder.Personal);
var document = Directory.GetFiles(documents);
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.
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.
The current Core Data iOS app template in Xcode provides this method:
// Returns the URL to the application's Documents directory.
- (NSURL *)applicationDocumentsDirectory
{
return [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
}
This works for me, pretty short and sweet
#define kDOCSFOLDER [NSHomeDirectory() stringByAppendingPathComponent:#"Documents"]
Cheers!