Handling UIDocument.State editingDisabled

Question

DiGiTaLFX OP

Created Nov ’19

Replies 2

Boosts 0

Views 1k

Participants 3

Hi

Having made an app that allows users to save documents to iCloud Drive, I'm left with questions regarding the .editingDisabled state. My app calls open on the document and if the completion handler returns as a success I present the document. Initially the documentState property is always .normal however sometimes after a couple of seconds, it changes to .editingDisabled for half a second and then changes back to .normal. So my questions are as follows:

a) Is there anywhere that explains what .editingDisabled actually means - e.g. why is it disabled?

b) Is there a way to detect whether a document will switch to .editingDisabled at the point when the open completion handler returns? I'd quite like to disable editing on the document before it appears rather than presenting it, and then suddenly disabling edits.

c) Is my document state ever going to change to .editingDisabled once it's been open and the user has been working on it for a while? If so, I'd be interested in the best approach for handling this state (disable the document, make edits elsewhere and merge them later?)

Thanks very much 🙂

Boost

Answer 1

knutknatter2 OP

Feb ’21

Have you ever figured this out? Experiencing the same issue. Also, cannot determine when this happens. Does not happen always. I did notice however that .progressAvailable is not called when this happens.

0

Answer 2

rgrant@mac.com OP

Mar ’21

I'm sure you saw this in the docs?

UIDocumentStateEditingDisabled
The document is busy and it is not currently safe for user edits. This state is set just before UIDocument calls the disableEditing method. It calls enableEditing when it becomes safe to edit again. UIDocument also sets this state when an error prevents the reverting of a document.

So it's some internal state when things are getting sync'd up with iCloud (there's quite a lot of moving parts) and the system would prefer you not make any data changes.

This going to happen, at least, after opening and saving (including autosave), when it checks to see if there are conflicts. I imagine Apple doesn't want to delay opening the file (for user responsiveness) so defers the conflict check, but then needs a moment to make that check, I'm surprised you're seeing .5 seconds though, is it because of a slow network or big file?

0