Can I reduce the resolution of image files?

General Discussion
#21

Thanks a lot, TIM.
Now I know what happened:
Web .GotFile fileName gives you the full path on the device storage up to the file name.
That's good for Image .Picture to show the photo (because it requires the full path).
But, according to your advice, I have to give File . Delete the file name I ordered to convert, preceded by a forward slash.
I compiled it and it works: It uploads to the cloud the converted file, and deletes it from ASD.

But another problem arised: It works perfectly in a tablet with Android11, but in other tablet wit an older Android version it gives an Error 1104: Unable to complete the given request with the file....with the specified URL....

Its strange for me because, despite the error, the converted file is uploaded, and then deleted from device.
And there is no such an error displayed on the device with Android11

1 Like
#22

Which android version is failing, and which request is returning the 1104 code ?

#23

The old tablet that gives the error has 4.2.2 Android version.

The request returning the 1104 code is WebStorage .PostFile (when called by my procedure SubeLowRes).

It’s just a temporary black window displaying this message that appears, but doesn’t prevent the execution of the next block (File1 . Delete).

But it prevents the normal display of "reemplazado selfie low res" message at EtiqResultados label that should happen when WebStorage .GotText event triggers when the 200 code is received from FireBaseStorage as a reply to the PostFile request.

I'm not sure if I set correctly the RequestHeaders for a file upload (which in fact replaces a file with the same name in FireBase Storage). The result is the file is replaced ok in the cloud. But may be the answer is not the expected one?

The extrange thing is it works well in the other tablet with Android11.

In case it can help, I found a similar issue in this post: Can't POST file: Error 1104

#24

I don't know what happens.
I compiled the app again, installed also on a third tablet with Android 4.1.1 and it works fine (no 1104 error in 2 tablets, but it keeps apearing in one of them).

In fact, is not a big problem:
I could simply ignore the black window with the 1104 error, and program the rest of the code for not waiting the response to the .PostFile (asumming the upload always is succesfull).

#25

I use lower case for the content-type in the request headers, and also set this above the web url block.

You could use a File.Exists block to test the validity of your file path

#26

On Android below 4.4 (API 19, KitKat) storage permissions (READ / WRITE) are required also for the ASD.

1 Like
#27

See e.g. here:

grafik
grafik1051×603 70.3 KB

#28

Thanks Anke.
I don't know if I need to request permissions on my own, or if some of the blocks I already use, request the permissions for me.
Those images are shown at installation of the app in both older tablets.

Permisos Android 4.2.2
Permisos Android 4.2.21600×1200 362 KB

Permisos Android 4.1.1
Permisos Android 4.1.11200×1600 128 KB
.

If I try to do it, setting up the block Screen1 . AskForPermission WriteExternalStorage at Screen1 .Initialize, then Android11 tells me on start that permision is not granted.

#29

You will need to setup a conditional statement to test for android version, before asking for the read/write permission. Android 11 does not accept WRITE permission requests. As @Anke said, the read/write permissions are only required in < 4.4.2

#30

Sure you are right.

But with or without permision, in all three cases, it looks like the app has no problems for accesing the ASD path on the device (or equivalent, in Android versions <10, when this concep of ASD didn't exist):

The app first downloads the file from cloud to the device, then converts the image to 200x200 pixels and overwrites the file in the same place of the device, then takes the converted file from device and uploads it to the cloud, and finally deletes the file from the device (just to make room for new files).
I can see on FireBase Storage console that the size of the orignal file has been reduced. and I can see with file managers that no file remains on the device.

Maybe I need to request permision conditionally to avoid the 1104 error in my tablet with Android4.2.2. But for me it's clear that in this app, I don't need to specifically request permission to access the file. Neither in Android 4.1.1, 4.2.2, nor 11.

#31

The simple question is: Does the Android 4.1.x device request storage permissions? Yes or no?

(Uninstall & reinstall the app and check.)

#32

Of course, on Android < 23 permissions are requested and granted at install-time and not at runtime. So check if storage permissions are granted in the app Settings (or if they are declared in the Manifest).

#33

Thanks Anke.
Yes. At least the last 2 times, I uninstalled an reinstalled the app again (this is when I took the photos atached to former post).
Sorry. I don't know how to read a manifest.
When looking at the app's permissions (in the Apps Manager of the device), I can see the same ones mentioned at installation time.
I supose the File component, or the Web component that are present in the app, automatically includes the request of such permissions for me.
I supose what we are looking for is "Probar acceso al almacenamiento protegido".

By the way... The issue is in the device with Android 4.2.2.
Not in 4.1.1 nor 11

#34

Thanks Tim
I modified to lower case and switched the positions of the request headers and web url.
Still the same results.

#35

Let me check the APK. Upload it to Google Drive and post the link.

#36

I think I found the reason for the 1104 issue!
It looks that I was deleting the file from local storage too soon: Just after requesting it's upload to the cloud (which takes some time).
I didn't discover it up to now, because in all three tablets Firebase console told me that the file was there (even with it's smaller size).
But today I discovered that, in the file uploaded with the tablet that gives the 1104 error, I can see only the upper part of the image.
I should have waited for the .GotText 200 confirmation of the upload, before deleting the file from ASD.
Thanks a lot to you all for your help.

#37

Hi TIM
I'm uploading to the cloud the converted file, just after converting it to smaller size with the .Resize block of your extension.
Now I think may be the RunTime Error I got with old tablets and big files, were not due to hitting the limits of memory of the tablet, but due to not having finished the conversion yet, when I ordered the upload.
To avoid timing issues when converting files of big sizes ¿do you recommend me to wait some time in between?

#38

That seems a sensible thing to do. When I get a moment, I will look to adding some "after conversion" / "after resizing" event blocks to the extension, so that you can be sure the conversion/resize is finished before continuing with the workflow.

What you could also try is to use the if File exists block to test for the existence of your output file...

1 Like
#39

Nice patch: Change the name of the converted file, and test if it's there before going on.

#40

An after resizing event block will be really wellcome.

Checking if the converted file exist, is easier to tell than to do:
First your need to handle a double file name (and file path), to diferentiate the original from the converted.
If you check, and the converted file still is not there, you need to set a timer to recheck. ¿How often, and how many times?
If there is a chance that you are converting asinchronously more than one file, you'll also need to handle a list of files pending to be converted.

It would be much easier if there was an after resizing block, that tells you the name (better the full path) of the file just resized.