Yikes. That’s really surprising. That kinda sucks. Users have been trained for years to type a file name and have the extension supplied and now they have to do it themselves? That’s backwards thinking from the Android guys. Going to be quite funny I guess: “On the following browser screen please make sure you type .xml at the end of your filename”. Then present the the chooser. Check the filename, if it doesn’t end in “.xml” say “No, really, add .xml”. Loop around until user correctly specifies extension. And these guys wonder why people thing of Android as an after thought. Hey ho.
Thanks, will give this a go tomorrow.
getFileName() works fine, thanks
I don’t mean to be pedantic, but there is a memory leak in the above code: the FileChooser at the end of the callback should get deleted. I was having similar trouble until I discovered that.
The reason I’m pointing this out is because the Documentation is misleading:
You must specify a callback which is called when the file browser is canceled or a file is selected. To abort the file selection, simply delete the FileChooser object.
You can use the ModalCallbackFunction::create method to wrap a lambda into a modal Callback object.
You must ensure that the lifetime of the callback object is longer than the lifetime of the file-chooser.
Really you always have to delete the FileChooser, just when you want to “cancel” you just do nothing in the callback, except delete the FileChooser.
Also it’s misleading in my opinion because the variable is declared as const but then we can delete its memory.
Maybe this is what was causing the sporadic crashes?
The idea is that you don’t delete the file chooser in the callback but rather keep a
ScopedPointer to the file chooser as a member variable in the parent component that created it. This way, when the parent is deleted the file chooser will be automatically canceled. As most people will also have the callback method in the parent class, this will ensure that the callback method always has a valid this pointer.
hi @fabian - should we be able to access local files from the browser on Android? Thought this was the case but I’m currently only seeing google drive and downloads folder - not able to see the SD card.
I know on iOS we have to provide a permission for accessing local storage - is there something similar for Android or do we have to provide 2 options for opening local and opening remote? thx
Also, looking at the Downloads folder on my device, this is what I see from the file browser:
and this is what I see from the JUCE browser, which has multiple entries repeated for some reason, and lots of files missing.
This is really odd as we are just launching the file chooser app (which is basically a system app). You can trigger the same app when choosing an attachment within gmail. Can you check if you get the same issue? If yes, then I dare say this may be an android bug.
Hi, i don’t have a gmail account. Any other way to test?
You can also open the file chooser by trying to select an external certificate:
Settings -> Security & Location -> Encryption & Credentials -> Install From storage
ok, thx. yes, it appears the same there so must be an Android issue on this tablet. thx
btw, did you have an answer for the other question on accessing the local SD card? thx
Yes you need to have read external storage permission for that. Enable it in the projucer and ask the user for permissions via
RuntimePermissions::request (RuntimePermissions::readExternalStorage, myCallback)
Hi, that’s what I already have. That only gives me access to the Downloads folder - I cannot see any other folders on the card.
Just want to make sure: you also requested the permission at runtime? It’s not enough to only enable it in the Projucer.
I’ve used this thread (thanks!!) to implement file load/save in my app (SpaceCraft Granular Synth just released on iOS).
Although I’ve advertised my app as not officially supporting AU that hasn’t stopped loads of people trying to use it as an AU! The problem here is that the native file chooser can’t open when my app is used as an AU inside a host GUI such as UAM, beatmaker3 etc.
Question 1. could you confirm that there is no workaround to allow native file chooser when inside the host GUI (so I don’t waste any time trying)
One option I expect would be to use the JUCE file chooser. However, I would imagine this would be a lot of work to implement, so before I go down that route…
Question 2. is it feasible to create a custom non-native file chooser within my app that can reproduce all of the functionality of the native file chooser? That is, being able to automatically detect and display the locations such as Dropbox, Audioshare, google drive etc. depending on what the user has installed on their device? In other words, being able to reproduce the native file chooser functionality.
Yes that is correct. AppExtensions cannot open any top-level windows including any panels such as file choosers.
Why do you imagine that would be a lot of work? It’s perfectly doable. You just need to make sure that you do not open the JUCE file chooser as a top-level window (as they are not supported in AUv3s). Rather, you need to add them as a child component to your editor.
Definitely sounds quite difficult. You’ll need to be writing a lot of native code for that.
Thanks Fabian, I will look into basic non-native file chooser then.
I would like to retain the Native file chooser when my app is not within a host GUI. Is there a way to detect whether or not the iOS app is within a host GUI?
Thanks a lot Fabian, that’s exactly what I needed! Now I can direct to a non-native file chooser when AU inside host (which I need to get working and looking right).