I was playing with the JUCE demo on iOS, and noticed that iOS doesn’t have a native file browser implementation, which I confirmed by checking the source code and finding it completely empty because “//there's no such thing in iOS” (I assume this was the case whenever it was written).
iOS has had a native file browser interface since iOS 8 via UIDocumentPickerViewController. It’s not a direct interface to a view, but I think that’s kind of the point since it’s a modal interface.
No need to bump - we’ve been looking at this for about a week already.
It’s not so easy as it sounds as the native file browser returns a URL and not a file path. We will need to change the FileChooser API to also return URLs in a backward compatible way. For this, we need to make the URL class “file-aware”, for example, add methods to convert to and from local file:// URIs in a way that works with all platforms - i.e. taking care of all the strange URL escaping that goes on. Currently, the underlying internal interface for JUCE to talk to the native file chooser API uses Files as it’s return-value. This will need to be changed to URLs and this means we will need to re-test all platforms. I wouldn’t call this “real low-hanging fruit”.
I was assuming the returned the NSArray of NSURL objects could be turned into JUCE-usable paths via File([NSURL fileSystemRepresentation]) when a JUCE-implemented UIDocumentPickerDelegate received them after tossing up a UIDocumentPicker instance.
That’s what I meant by low hanging fruit - obviously the team is doing a more thorough job by supporting all URL types. Agreed, definitely no longer low hanging fruit, and likely a breaking change to be made carefully!
Thankful to hear the team is looking into it. The reason for my bump was because I wasn’t sure if I should factor patching a file browser into my project (which isn’t under any particular time or feature restrictions).
BTW: We are still working on this. While we are at it we are also adding an Android file browser and supporting asynchronous invocation of the FileBrowser dialog. Shouldn’t be all too long now…
@leehu Yes would have been good to meet you! It’s always nice meeting forum users in person.
Another update: most of the complex Android work involves translating Android content URLs into normal posix paths. This work finished last week and is already on develop. It’s quite a biggie: commit ae9ec7c.
The other file browser code is done and has past internal code review but we spotted an obscure bug which occurs when rotating your device on iOS. Somehow, occasionally, the entire GUI locks up. So we are still trying to fix this. I’ve spent far too long trying to figure this bug out so @t0m and @lukasz.k are helping out (Fabian vs. Bug: 0 - 1 ).
Hi. I know this is an old thread to resurrect and the filechooser work was completed some time ago, but wondered if anything had been done on file browsers to allow us access to cloud drives etc on iOS/Android? thx
Hi. Those changes allow you to bring up a dialog asking the user to load/save a file. But they don’t allow you to just show a native equivalent of FileBrowserComponent. If I use a FileBrowserComponent on iOS/Android then there doesn’t appear to be any access to cloud drives etc. thx
).