iOS Native File Browser


#1

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.

Any chance someone could take a look at this?


#2

Yes, please! It’s on my to-do list to add support to my app for UIDocumentPIckerViewController, but if it was built into JUCE, I’d be very happy!


#3

+1 - would be handy for one of my client projects where we want to load external samples in.


#4

bump

Any JUCE devs looked at this? This is really low hanging fruit…


#5

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”.


#6

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).


#7

We can’t really do this as the iOS file chooser doesn’t really distinguish or limiting if the file is on disk or in the cloud.


#8

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…


Support for new iOS 11 File Browser
#9

great news on the Android stuff aswell - wondered whether you’d do something like that…

btw, sorry didn’t catch up with you at ADC - wanted to thank you for all your Android help :smiley:


#10

@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 :tired_face:).


#11

OK. It’s on develop now:


#12

great. will try it out over the next couple of days, thanks!