We code to RW style which in general uses guard for early exit / pre-requisite type conditions.
guard is a signal to the future reader of the code that this condition must be met before continuing where if badCondition return doesn’t give that signal quite as readily.
We also like to keep the indent level low as possible.
When I’m writing Objective-C I do use if constructs but I like guard when writing Swift.
I have a question why did you make the root view controller and vanilla class RootViewController and not just use a UIDocumentBrowserViewController as the root in the main storyboard?
For this projects immediate needs there’s no good reason to have the RootViewController as an intermediate controller. I think it made the tutorial flow well to have it there. Sometimes the demo projects go that way.
Interface Builder doesn’t have a UIDocumentBrowserViewController object yet either. Is would need to be embedded code wise in the App Delegate to completely eliminate the intermediate RootVC and that’s just horrible
RootVC’s job is to contain and route between different zones of the app. I think it does that job without knowing too much.
1.First, I open a iCloud document(test.rwmarkup) on the iPad
2.Then I change the iCloud document(test.rwmarkup) name or move in the iCloud directory of MacBook
3.Document receives a status change notification(UIDocument.stateChangedNotification) on iPad. Document status changed from normal to .editingDisabled and .savingError.
The same operation, I test Apple Keynote can be edited and saved, who knows this problem?
Looking at the final version of the tutorial code shows that I didn’t deal with the use-case you described where another iCloud client moves the document around while it’s still open on the device. Good spot.
As a rough guess you’d need to add some code to deal with the document moving. How much code that would require I’m not sure. Probably not much.
The docs seem to recommend overriding UIDocument.disableEditing() and UIDocument.enableEditing() to protect UI against edit events during the move.
Possibly also an override on func writeContents(Any, andAttributes: [AnyHashable : Any]? = nil, safelyTo: URL, for: UIDocument.SaveOperation) to watch for .editingDisabled would help too.
UIDocument and UIManagedDocument are powerful but do require a bit of code to deal with cases like you describe. The ability to see and move documents around is relatively new to iOS.
Thanks for taking the time to explore the more complex situations in a document based app.