- Buy another, different plugin for Apple
- Put a test for operating system in my code, using system.getInfo()
- Call the appropriate plugin
Jan 27 2017 10:49 AM
Hello again externalStorage fans,
I can now report that after working on this all day, on and off, it now works. Strangely, the code that now works is the same code I started with this morning.
I did notice that during the day, the externalStorage plugin got updated, but it didn’t observe that the function had worked until this evening. In fact, I saw the first success this evening sometime after an Android system update (7.0 to 8.1) was pushed to my phone. Probably an unrelated event – or maybe they were chasing this bug too.
Anyway, it has now worked the last 3 times I tried it with 3 different test files.
I’m going to bed now. I’ll look at it some more tomorrow and try it with the actual files I want to use, instead of test files.
Hello again. Here’s some info from my day of experiments with externalStorage plug-in, and externalStorage.copyFile, yesterday.
Path does seem to be important, or at least interesting, in this matter.
The original path I supplied for the destination file (on the Android phone) was:
That path did not work yesterday morning but did work yesterday evening. By “work” I mean: “caused the externalStorage plugin to write a test file that could be seen using the Android app called Downloads/Files on Android phone.” One note on this definition is that during my day of testing yesterday (2018-11-09), my Android phone updated itself from 7 to 8.1.0 After the update, the “Downloads” app had been replaced by the “Files” app.
At one point I used the plugin-method externalStorage.getExternalFilesDir(type) as follows: externalStorage.getExternalFilesDir( “Download” ). That returned the following string:
At first, I thought that was an Ah ha moment, but using that path and then using either the externalStorage plug-in or, later in the day, the SSK library, did not “work.” Both caused the following runtime error message which might be of use to someone that knows the Android world:
Attempt to invoke interface method ‘boolean java.nio.channels.WritableByteChannel.isOpen()’ on a null object reference
After the Android update, I saw the first evidence that any of my experiments had caused a test file to be written to the phone. If I believe the file date stamp reported by the new Files application, one of the days earliest attempts, before I wrote to this forum, had worked – I could view the file “hello123.txt”
I had to try it a few more times, backing out different changes and trying different files, but eventually I got the original code to work multiple times. I skipped a few numbers in my file numbering, but I can now see the file hello999.text. When I view it with Chrome, the path shown n the URL edit box is:
BTW %3A is the colon character ( : )
So, one thing I know is that the path to the Download directory that is needed by externalStorage plug-in is not the same as the one reported by Chrome, or even by the externalStorage plug-in itself.
That’s it for now.
>> So "externalStorage.getExternalFilesDir( “Download” )" [is] returning the right path now?
In my experiments, externalStorage.getExternalFilesDir(type) returns a string that is the end of the long path for that file (as eventually shown by Chrome in its URL box). It’s not clear to me how anyone can use the result of getExternalFilesDir.
For my application, all I want is the ability to copy a file to the device’s Download folder. When using the externalStorage.copyFile method, the path of “/Download/” was what I needed to make things work. Apparently Scott’s software expands “/Download/ “ to the longer path. It does that for a phone running Android 8.1 anyway.
For me, that leads to questions like: What version of Android is required for the externalStorage plugin?
Scott’s build instructions have a comment “Android > 6” However, on the phone I was using, Android 7 did not show the file that had been copied. It wasn’t until my phone received an update to Android 8.1 that the phone began showing files copied to “/Download/”
Should Scott now say that the externalStorage plugin requires Android 8.1 or greater, or do we think that’s only true for the phone I was experimenting with, a Motorola G5 plus?
To be more precise, should Scott now say the user must have Android 8.1 or greater to use the copyFile method of the the externalStorage plugin?