My question is regarding SwiftUI's DocumentGroup: using a simple, template-based project in Xcode (using the new multi-platform, document-based app template), I can create new documents, edit them, etc. Also, "outside" the app, I can manipulate the document file as such - move it around, copy it, rename it, etc.
As by default, all new documents are initialised with "Untitled" name; in the main app point of entry, I can access the file's URL:
var body: some Scene {
DocumentGroup(newDocument: ShowPLAYrDocument()) { file in
// For example, this gives back the actual doc file URL:
let theURL = file.fileURL
ContentView(document: file.$document)
}
}
First question: How can I edit/change the actual file name once the document is "open", i.e., when the code is running on the scope of ContentView? The lack of documentation for SwiftUI is making looking for answers to problems like this very hard - I think I've scourged the entire Internet but it seems no one is having these kinds of issues, and if they do, their posted questions have no answers - I have posted a couple of questions myself on other issues, and haven't got any comments even, let alone answers.
I have another question, that I think is somewhat related: I have seen in the Files app, for example, that some file types, when selected, can display additional extended information under the "INFORMATION" pane for that file (for example: video files show dimensions in pixels, duration and codec info); my app's documents contain a couple of values (within the saved data) that I would like the user to be able to "glance" in the document picker without having to open the file per se, in a similar fashion as described for the Files app.
My second question is then: is this possible to do, and if so, where can I at least start looking for answers? My guess is this is not "possible" with SwiftUI as such right now, so it would have to be an integration with "regular" Swift?
Thanks in advance for any guidance.
The issues experienced with the above "solution" were related to a (confirmed) bug with the .fileImporter modifier - so, this "works", hacky as it is.