Good morning. This is my first post. I probably wouldn’t write it if it wasn’t for the problem in thunkable, I can’t upload the file to fibase storage. I am using the web api but only the minimum capacity file is created but the file itself is not uploaded. This is a file directly from the camera, but when I tried to send the same file, the effect is the same. Maybe I have something wrong in the header. Ask for help from advanced colleagues.
When you post a question, you need to include screenshots of your blocks and/or a link to your project.
I had screenshots ready, forgot to upload them.
Hello @whiterabbitstudio202
I’ve already created an app that uses the API Block to send an image file.
I used Web Viewer and HTML code to convert the image file to base64 and then send it through the API.
This is the code for HTML:
<!DOCTYPE html>
<html>
<body style="background-color:#18A2EB;">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Convert local file to Base64</title>
<script
src="https://thunkable.github.io/webviewer-extension/thunkableWebviewerExtension.js"
type="text/javascript"></script>
<style>
.choose::-webkit-file-upload-button {
color: white;
display: inline-block;
background: #1CB6E0;
border: none;
padding: 7px 15px;
font-weight: 700;
border-radius: 3px;
white-space: nowrap;
cursor: pointer;
font-size: 10pt;
}
</style>
</head>
<body>
<input type="file" accept="image/*" class="choose" onchange="encodeImageFileAsURL(this)" />
<script>
function encodeImageFileAsURL(element) {
let file = element.files[0];
let reader = new FileReader();
reader.onloadend = function() {
ThunkableWebviewerExtension.postMessage(reader.result);
document.write('RESULT: ', reader.result);
}
reader.readAsDataURL(file);
}
</script>
</body>
</html>
You can find the project here
This method works, but it doesn’t quite send the data stream to the created file, but the file has errors and I can’t open the image.
The interesting thing is that when I use your script, @ioannis, it returns a base64 image string starting with "RESULT: ". If I manually remove that and assign the rest of the string to an image, it displays the image. But if I use a text block to remove that text, it fails to display the image.
Modified project: Thunkable
Google storage requires the following format
curl -X POST --data-binary @OBJECT_LOCATION \
-H "Authorization: Bearer OAUTH2_TOKEN" \
-H "Content-Type: OBJECT_CONTENT_TYPE" \
"https://storage.googleapis.com/upload/storage/v1/b/BUCKET_NAME/o?uploadType=media&name=OBJECT_NAME"
The screenshot is not showing all required fields.
thanks for the tips it helped me a lot
Still no base64 convert block. It’s been well over a year in the making
Hello @jared! Currently there are no plans to release the component you are inquiring about. I apologize for any disappointment this causes. Our team has decided, for now, not to pursue this release for some reasons. If anything changes and we release the component in the future, we will of course announce it.
Well how about a run JavaScript block so these janky webviewer workarounds can go out the window.
It’s just so convoluted and unnecessary. I’m truly saddneddd to see that block go away, considering an api block that can send files still doesn’t exist.
When I worked for Thunkable that block was in beta, and so close to release (there was a lot in the works at the time). What happened? Seems like a lot of time wasted and hopes raised for nothing.
Can api blocks send local files yet as that was the primary need for that block anyhow?
Yes, please!!!
+1
Hello @jared and @tatiang!
The JavaScript block is a good suggestion!
I’ll pass it on to the team.
Yes, right now there is an option on the Web API component to send local files, it is called Multipart Form Data and you can select that option on WebAPI settings
Here is an example:
I’m always glad to hear that but part of my frustration that I expressed earlier this week on the forums is that existing requests often seem to go nowhere.
This idea of a programming block that could connect Thunkable to Javascript was first proposed in 2019: [For Thunkable X] Add block "add source directly" · Issue #159 · thunkable/thunkable-issues · GitHub. So the idea is 4 years old.
A more formal feature request was made in November 2022: A feature request for blocks that can execute JavaScript - code directly · Issue #1185 · thunkable/thunkable-issues · GitHub. It’s been 6 months but there is no response from staff to that idea.
I know you have new staff; I’m not pointing fingers at any of you necessarily… it’s just a frustration that as a company there seems to be a blind spot as far as keeping track of issues that customers care about and responding to those requests.
When there are prior requests or a beta block in the works (as @jared mentioned), it can help customers when we can see a bit of the roadmap and understand that there’s a process to how changes are made to the product instead of feeling like it’s this black box and requests just get sent to the team.
Is that something that can be added as a Web API block? I stay away from form properties for components because I want to be able to see all of the settings I’m using in one place (the Blocks tab). But if there was a block to specify Multipart Form Data and file:[filename] that would be really useful.
Can you send a file chosen from the file picker? Like an image taken from within the app and then send that in the api call?
@jared @tatiang
Thank you for sharing your thoughts!
I have asked the engineers and as soon as I have an answer I will let you know.
Hello @tatiang You can set the Multipart form data using the blocks as below. If the value provided to the body is an object, it by default considers it as “Mutipart form data”, you do not need to explicitly set it.
I confirmed that, for now, unfortunately, this is not supported.
Once we will have this feature available, we will be sure to let you and all of our Thunkable community know.
So, to be explicitly clear, at this time the feature does exist to send a file over the webAPI BUT that file needs to be packaged with the app at time of app publishing. Is that correct.
I.e. I can’t snap a photo and upload it directly to my own cloud bucket in google, I’d first still need to upload to cloudinary using media blocks, return a url, then use that url to make a permanent image link in my cloud bucket from google. Is that correct?