Document Renaming with UIDocumentBrowserViewController
up vote
1
down vote
favorite
I am using the "new way" of storing documents (iOS 11+) using UIDocumentBrowserViewController. No need for iCloud API, Entitlements etc. -- just works (under control of the separate Document Browser process).
However, I haven't figured out how to rename (i.e. move) a document programmatically this way, at least within iCloud. The standard "url.setResourceValues()" does work just fine on the local filesystem, but renders in 513/not permitted in iCloud. Also all the former ways of doing it (using full set of iCloud capabilities & entitlements, using complex FileCoordinator orchestration etc.) don't work either when the created document actually is controlled through the document browser.
I couldn't find any reasonable documentation or example on how to use the UIDocumentBrowser to also move a document under it's (and somewhat my) control. There is the UIDocumentBrowserImportModeMove mode that might do what I need, however I have no clue how to programmatically initiate that on a given UIDocument.
Has anyone already made experiences to do it this way?
Thanks, habitoti
ios uidocument uidocumentbrowservc
asked Oct 30 at 14:43
habitoti
13214
add a comment |
up vote
1
down vote
favorite
I am using the "new way" of storing documents (iOS 11+) using UIDocumentBrowserViewController. No need for iCloud API, Entitlements etc. -- just works (under control of the separate Document Browser process).
However, I haven't figured out how to rename (i.e. move) a document programmatically this way, at least within iCloud. The standard "url.setResourceValues()" does work just fine on the local filesystem, but renders in 513/not permitted in iCloud. Also all the former ways of doing it (using full set of iCloud capabilities & entitlements, using complex FileCoordinator orchestration etc.) don't work either when the created document actually is controlled through the document browser.
I couldn't find any reasonable documentation or example on how to use the UIDocumentBrowser to also move a document under it's (and somewhat my) control. There is the UIDocumentBrowserImportModeMove mode that might do what I need, however I have no clue how to programmatically initiate that on a given UIDocument.
Has anyone already made experiences to do it this way?
Thanks, habitoti
ios uidocument uidocumentbrowservc
asked Oct 30 at 14:43
habitoti
13214
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am using the "new way" of storing documents (iOS 11+) using UIDocumentBrowserViewController. No need for iCloud API, Entitlements etc. -- just works (under control of the separate Document Browser process).
However, I haven't figured out how to rename (i.e. move) a document programmatically this way, at least within iCloud. The standard "url.setResourceValues()" does work just fine on the local filesystem, but renders in 513/not permitted in iCloud. Also all the former ways of doing it (using full set of iCloud capabilities & entitlements, using complex FileCoordinator orchestration etc.) don't work either when the created document actually is controlled through the document browser.
I couldn't find any reasonable documentation or example on how to use the UIDocumentBrowser to also move a document under it's (and somewhat my) control. There is the UIDocumentBrowserImportModeMove mode that might do what I need, however I have no clue how to programmatically initiate that on a given UIDocument.
Has anyone already made experiences to do it this way?
Thanks, habitoti
ios uidocument uidocumentbrowservc
asked Oct 30 at 14:43
habitoti
13214
I am using the "new way" of storing documents (iOS 11+) using UIDocumentBrowserViewController. No need for iCloud API, Entitlements etc. -- just works (under control of the separate Document Browser process).
However, I haven't figured out how to rename (i.e. move) a document programmatically this way, at least within iCloud. The standard "url.setResourceValues()" does work just fine on the local filesystem, but renders in 513/not permitted in iCloud. Also all the former ways of doing it (using full set of iCloud capabilities & entitlements, using complex FileCoordinator orchestration etc.) don't work either when the created document actually is controlled through the document browser.
I couldn't find any reasonable documentation or example on how to use the UIDocumentBrowser to also move a document under it's (and somewhat my) control. There is the UIDocumentBrowserImportModeMove mode that might do what I need, however I have no clue how to programmatically initiate that on a given UIDocument.
Has anyone already made experiences to do it this way?
Thanks, habitoti
ios uidocument uidocumentbrowservc
ios uidocument uidocumentbrowservc
asked Oct 30 at 14:43
habitoti
13214
asked Oct 30 at 14:43
habitoti
13214
edited Oct 30 at 14:50
asked Oct 30 at 14:43
habitoti
13214
asked Oct 30 at 14:43
habitoti
13214
asked Oct 30 at 14:43
habitoti
13214
13214
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
There is no API to move a document that was returned to you by the document browser after the user picked it. You should file a bug with Apple to get one.
If this is inside your iCloud container, you can use the iCloud entitlements and -[NSFileManager URLForUbiquityContainerIdentifier:] to get sandbox access to your container and do whatever you want inside with NSFileManager; but that won't work in iCloud outside of your container or in other file providers (Dropbox...).
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
There is no API to move a document that was returned to you by the document browser after the user picked it. You should file a bug with Apple to get one.
If this is inside your iCloud container, you can use the iCloud entitlements and -[NSFileManager URLForUbiquityContainerIdentifier:] to get sandbox access to your container and do whatever you want inside with NSFileManager; but that won't work in iCloud outside of your container or in other file providers (Dropbox...).
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
add a comment |
up vote
1
down vote
There is no API to move a document that was returned to you by the document browser after the user picked it. You should file a bug with Apple to get one.
If this is inside your iCloud container, you can use the iCloud entitlements and -[NSFileManager URLForUbiquityContainerIdentifier:] to get sandbox access to your container and do whatever you want inside with NSFileManager; but that won't work in iCloud outside of your container or in other file providers (Dropbox...).
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
add a comment |
up vote
1
down vote
up vote
1
down vote
There is no API to move a document that was returned to you by the document browser after the user picked it. You should file a bug with Apple to get one.
If this is inside your iCloud container, you can use the iCloud entitlements and -[NSFileManager URLForUbiquityContainerIdentifier:] to get sandbox access to your container and do whatever you want inside with NSFileManager; but that won't work in iCloud outside of your container or in other file providers (Dropbox...).
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
There is no API to move a document that was returned to you by the document browser after the user picked it. You should file a bug with Apple to get one.
If this is inside your iCloud container, you can use the iCloud entitlements and -[NSFileManager URLForUbiquityContainerIdentifier:] to get sandbox access to your container and do whatever you want inside with NSFileManager; but that won't work in iCloud outside of your container or in other file providers (Dropbox...).
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
answered Nov 9 at 8:59
Thomas Deniau
1,95811111
1,95811111
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
add a comment |
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
Thanks, I'll file a Radar. Using the UIDocumentBrowser, you shouldn't have the need for an explicit cloud container configuration. UIDocument together with UIDocumentBrowser's value proposition is to do all the heavy lifting around ownership and permissions for you, so setResourceValue(name) should IMHO be able to do that in cooperation with the UIDocumentBrowser process.
– habitoti
Nov 13 at 13:04
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
If the file is materialized on disk... With the new File Provider APIs, some files might not exist at all until you coordinate to read them. It's to rename files that don't exist on disk or are placeholders that new API is probably needed. For files that are downloaded, I agree NSFileManager should work in an ideal world, but the cloud provider needs to be told about the move... Anyway, yes, Apple needs to find a way to make this work in every case and a radar is the way to go.
– Thomas Deniau
Nov 14 at 14:05
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
The file is already on disk/iCloud. The orchestration also for creation is "copy local -> cloud, open from there", so when I am asked to open the UIDocument, it's already there. I want to edit the resource name of the loaded UIDocument. And it anyway doesn't work either for existing docs being opened straight from an iCloud drive.
– habitoti
Nov 15 at 15:08
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
For existing, downloaded docs in iCloud Drive, if you ask for sandbox access using URLForUbiquityContainerIdentifier (don't forget to start accessing), you should be able to use NSFileManager to move them. But this doesn't solve the general problem, agreed.
– Thomas Deniau
Nov 16 at 16:21
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53066873%2fdocument-renaming-with-uidocumentbrowserviewcontroller%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
