I have been following the dropbox tutorial for the iOS platform. And i came across this line of code to load a file.
[[self restClient] loadFile:dropboxPath intoPath:localPath]
below this line, it has a little description box describing the code above, which states:
Here, srcPath is the path in the user's Dropbox (you probably got this from a metadata object), and destPath is the location on the local device you want the file to be put after it has been downloaded. To find out when the file download either succeeds or fails implement the following DBRestClientDelegate methods:
1) First off, there is no srcPath nor is there a destPath. So the either the code or the description of the code is outdated/incorrect.
2) Secondly, what is dropboxPath? I am assuming it is the file i want to load from dropbox. If so, how do i specify which file i want?
3) If i am loading a .sqlite file from dropbox, where exactly do i want to load that file into?
Any help would be very appreciated!
1) DropboxPath is the online path where your file is stored in respective Dropbox Account.
2) The source path will be DropboxPath and the destination path will be the path on ur mobile i.e. Document Directory. All the files should be downloaded to either document directory or inside other directory of document directory.
3) Your .sqlite file should be loaded in document directory only. But the project code should use this file using its NSPath.
Have a happy Coding.!! Enjoy.!!
The dropboxPath will indicate where within your application's Dropbox directory the file is. For instance, if your app is called APP01, then the users's Dropbox login will have an APP01 directory. To get a file from that you would specify it as #"/theFile.txt" and the Dropbox API should get APP01/theFile.txt from the user's account. Dropbox will sandbox your access to the user account when you create your development IDs to connect to them.
The localPath should be in your app's sandbox, which you can get using something like
+ (NSString*) GetDocumentDirectory
{
NSArray *paths =
NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
return ((paths != nil) && ([paths count] > 0)) ? [paths objectAtIndex:0] : nil;
}
You can append your local filename to what's returned from GetDocumentDirectory.
Related
I've got an iOS app that imported files from an email attachment.
I've noticed that once i'm finished with it it places the imported file into Documents/Inbox.
Should my app be deleting these files or does the OS eventually get around to clearing them out?
if so, how? i've tried:
[[NSFileManager defaultManager] removeItemAtPath:[self.url path] error:nil];
However it doesn't seem to reference the file in the inbox, even though self.url is the correct path to my import file.
System does not clear imported files, so you should clear them manually when it is necessary, but not to delete the Documents directory.
How to clear the NSDocumentsDirectory you can find here
If you want to delete files from the inbox use the same code adding
...
NSString *path = [NSString stringWithFormat:#"%#/Inbox", documentsDirectory ];
NSArray *directoryContents = [fileMgr contentsOfDirectoryAtPath:error:&error];
...
Read the reference
From apple doc:
Use this directory to access files that your app was asked to open by
outside entities. Specifically, the Mail program places email
attachments associated with your app in this directory; document
interaction controllers may also place files in it.
Your app can read and delete files in this directory but cannot create new files or write to existing files. If the user tries to edit
a file in this directory, your app must silently move it out of the
directory before making any changes.
The contents of this directory are backed up by iTunes.
To get to my application documents folder, I use this code:
[NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject];
I want to access this folder, however:
~/Library/Mobile Documents
How can i easily access this as a path value? Can I do this in a similar way?
The benefit of using the constants to access system provided directories is that if Apple decide to change the structure, your application will still work. Hardcoding in something like ~/Library/Mobile Documents is brittle.
However, you can access the Library directory with the same NSSearchPathForDirectoriesInDomain with the NSLibraryDirectory constant. Then, you should just append the Mobile Documents directory path.
// Set the NO to YES to get the full path, not the ~ version.
NSString *path = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, NO) lastObject];
path = [path stringByAppendingPathComponent:#"Mobile Documents"];
Looking at the constant values in http://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Constants/Reference/reference.html#//apple_ref/doc/c_ref/NSSearchPathDirectory, it appears there is no specific constant for the Mobile Documents directory, so the hardcoding approach might be your only option.
Mobile Documents are iCloud documents. So you want to store documents in iCloud.
On OS X they are definitely in ~/Library/Mobile Documents (10.7 and 10.8), but on iOS you should not look.
"All documents of an application are stored either in the local sandbox or in an iCloud container directory."...
"A user should not be able to select individual documents for storage in iCloud. "
http://developer.apple.com/library/ios/#documentation/DataManagement/Conceptual/DocumentBasedAppPGiOS/ManageDocumentLifeCycle/ManageDocumentLifeCycle.html
So if your user picks iCloud then you should use iCloud.
How long the iCloud document model will last is anyones guess, but that's the way it works today. The whole thing seems a masterpiece of poor UI design, as this direct answer to your question shows:
-(NSURL*)ubiquitousContainerURL {
return [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];
}
In my recent macOS app I had the same need: how to gain access to the root folder of your iCloud directory.
IMPORTANT!
This is written for an unsandboxed version, since the app is only intended for myself. If you plan to release an app on the Mac App Store, do not turn off sandboxed version.
I turn off sandbox in the app's entitlements file.
This code will access your iCloud root folder:
let pathToiCloudFolder = NSString(string: "com~apple~CloudDocs").expandingTildeInPath
let backUpFolderUrl = FileManager.default.urls(for: .libraryDirectory, in:.userDomainMask).first!
let backupUrl = backUpFolderUrl.appendingPathComponent("Mobile Documents/" + pathToiCloudFolder)
print("Backup Folder:", backupUrl)
I am downloading some mp3 files through my application using NSURLConnection. Actually where can I save the downloaded file. Someone says that saving in to NSDocumentDirectory will lead to app rejection.
Can I save the file to NSCacheDictionary and retrieve this from itunes?
I used this bit of code to save files to NSCacheDictionary
NSString *cachesPath = [NSSearchPathForDirectoriesInDomains(
NSCachesDirectory, NSUserDomainMask, YES)
objectAtIndex: 0];
NSString *documentsDirectoryPath = [cachesPath stringByAppendingPathComponent:#"music.mp3"];
[receivedData writeToFile:documentsDirectoryPath atomically:YES];
Can I use like this?
If you save the files to NSCacheDictionary you will not be able to retrieve them from itunes.
Edit:
You can store the mp3 files to NSDocumentDirectory and set "do not backup" flag
for setting the flag you can check the Technical Q&A QA1719.
For additional information you can check the docs.
specifically:
Use this attribute with data that can be recreated but needs to
persist even in low storage situations for proper functioning of your
app or because customers expect it to be available during offline use.
This attribute works on marked files regardless of what directory they
are in, including the Documents directory.
What is the correct/best way to store files on the iphone?
I would like to save a file in some directory on the iphone. I have read that filing the users home directory isnt good practice.
Where should the files be stored and how can an URL for these files be saved as well? So that after saving a number of files to the users phone, the urls can be stored so that the files can be managed at a later stage.
I would like to store files, keep a handle to the file and store these handles in a data structure as well as retrieve the files later using URLs in the data structure so that the files can be accessed and deleted.
What would be the correct/optimal way to do this?
Files are stored in Documents folder of the App.
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
[paths lastObject];
will get you the Document path.
I would then use NSKeyedArchiver and NSKeyedUnarchiver to store the URLS, and also put that into the Documents.
To see what's in the Documents Directory just use NSFileManager contentsOfDirectoryAtPath:error: method, which returns a handy NSArray. Call lastObject and there you go.
Update:
NSURL must be encoded and decoded with NSKeyedArchiver and NSKeyedUnarchiver, as they are not a basic object of plists. Although you could could convert them to strings, which are, then you could use [array writeToFile:file atomically:YES]. The other option is CoreData but that might be a bit much.
It would be best to store all URLs in one file and just overwrite and with changes when urls are being removed and added.
You are not filling the user's Document directory, you are filling the app's document directory. The documents folder is where you but files that the user has generated. In the future you may decide to open up the Document directory to iTunes so the user can add and remove files that way. Things that just relate the app should be stored in the Library folder.
I hope this explains what the hell I was on about a little better. I seemed to got the impression that you wanted to just store URLs as individual files and store the handles. You could get the handles but just knowing the directory you stored everything in. Get an array of the files in that folder and just load them up by using an unarchiver or initWithFileContents: from NSDictionary or NSArray.
I display text and images in a UIWebView. Content isn't always the same. I access images within the content using the bundle path. For an inbetween versions update of content, I'd like to allows users the ability to download new content (text & images). This new content will also display in a UIWebView. The problem is I will have to use a disk path rather than my common pattern of using the bundle path. Unless there is a way to repackage the image at runtime into the bundle.
Once the next app store update for the app is availble, all of the previously downloaded images will be in the app bundle. On this update, I'll write overwrite the previous content and use the bundle path for images. Content will be exactly the same minus the image path.
Can anyone give some insight into how this might work or a better approach?
So far as I know you cannot repackage the bundles on the iPhone once your app has been released to the App Store. So go the other way, and put the data from the bundle on the filesystem so you can change it at runtime.
My usual technique for this stuff is:
bundle up the initial data
have a routine that checks for the presence of a versioned file on the iPhone's filesystem at startup
if that routine doesn't find the current version of the file, copy all the data into the iPhone's filesystem
reference the data from the filesystem in my app, rather than using the bundle path
So, essentially your bundle is just a delivery mechanism, a way to preload the filesystem with the stuff you are going to need. Once it's on the filesystem you can change anything you wish.
Agree with Benjamin - you cannot change your bundle contents.
Instead you can (and should) save your downloaded contents to Documents folder of your application sandbox. You can get the path to it this way:
// Look in Documents for an existing plist file
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
Moreover contents of this folder persists during updates so it may be not necessary to put downloadable optional contents to the application bundle.