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.