I'm new to MobileFirst development. I need to download a zip file from one of the adapters. I am able to do this when invoking REST API call eg using Postman. But I'm not sure how to handle this when using MFS sdk:
Here's my code to access the adapter:
var resourceRequest = new WLResourceRequest(url,
WLResourceRequest.GET
);
const resp = await resourceRequest.send()
I log the response and it's showing special characters in the responseText.
Is there a way to handle the binary response?
Thank you in advance for your help!
For any binary content, you will have to convert the content to Base 64 in your adapter and revert it back to binary in your app.
This is because the WLResourceRequest APIs are designed for handling text based data.
If your binary content is rather large, then it is best to host the file somewhere and return the link to the file from your adapter.
Related
In my node.js application I'm downloading multiple user files from AWS S3, compress them to single zip (with usage of Archiver npm library) file and send back to client. All the way I'm operating on streams, and yet I can't send files to client (so client would start download after successful http request).
const filesStreams = await this.awsService.downloadFiles(
document?.documentFiles,
);
const zipStream = await this.compressService.compressFiles(filesStreams);
// ts-ignore
response.setHeader('Content-Type', 'application/octet-stream');
response.setHeader(
'Content-Disposition',
'attachment; filename="files.zip"',
);
zipStream.pipe(response);
Where response is express response object. zipStream is created with usage of Archiver:
public async compressFiles(files: DownloadedFileType[]): Promise<Archiver> {
const zip = archiver('zip');
for (const { stream, name } of files) {
zip.append((stream as unknown) as Readable, {
name,
});
}
return zip;
And I know it is correct - because when I pipe it into WriteStream to some file in my file system it works correctly (I'm able to unzip written file and it has correct content). Probably I could temporarily write file in file system, send it back to client with usage of response.download and remove save file afterwards, but it looks like very inefficient solution. Any help will be greatly appreciated.
So I found a source of a problem - I'll post it here just for record, in case if anyone would have same problem. Source of the problem was something totally different - I was trying to initiate a download by AJAX request, which of course won't work. I changed my frontend code and instead AJAX I used HTML anchor element with src attribute set on exactly same endpoint and it worked just fine.
I had a different problem, but rather it came from the lint. I needed to read all files from the directory, and then send them to the client in one zip. Maybe someone finds it useful.
There were 2 issues:
I mismatched cwd with root; see glob doc
Because I used PassThrough as a proxy object between Archiever and an output, lint shows stream.pipe(response) and type issue... what is a mistake - it works fine.
I need to send image to API which is already uploaded to server. How can I do that?
Application is developed on Laravel Framework 5.7. For API I'm using GuzzleHTTP Client package.
Thank you in advance.
You could try to encode your file to Base64, then send it back from your API.
Assume this is your image:
$image_path = storage_path($model->image);
$image_data = \File::get($image_path);
Returning Image Encoded on Base64:
return response()->json(['image' => base64_encode($image_data)]);
Others way to make your response (with the file):
https://laravel.com/docs/5.8/responses#json-responses
https://laravel.com/docs/5.8/responses#file-downloads
I've run into the following problem when porting an app from REST API to GDAA.
The app needs to download some of (thousands of) JPEG images based on user selection. The way this is solved in the app is by downloading a thumbnail version first, using this construct of the REST API:
private static InputStream getCont(String rsid, boolean bBig){
InputStream is = null;
if (rsid != null) try {
File gFl = bBig ?
mGOOSvc.files().get(rsid).setFields("downloadUrl" ).execute():
mGOOSvc.files().get(rsid).setFields("thumbnailLink").execute();
if (gFl != null){
GenericUrl url = new GenericUrl(bBig ? gFl.getDownloadUrl() : gFl.getThumbnailLink());
is = mGOOSvc.getRequestFactory().buildGetRequest(url).execute().getContent();
}
} catch (UserRecoverableAuthIOException uraEx) {
authorize(uraEx.getIntent());
} catch (GoogleAuthIOException gauEx) {}
catch (Exception e) { }
return is;
}
It allows to get either a 'thumbnail' or 'full-blown' version of an image based on the bBig flag. User can select a thumbnail from a list and the full-blown image download follows (all of this supported by disk-base LRU cache, of course).
The problem is, that GDAA does not have an option to ask for reduced size / thumbnail version of an object (AFAIK), so I have to resort to combining both APIs, which makes the code more convoluted then I like (bottom of the page). Needles to state that the 'Resource ID' needed by the REST may not be immediately available.
So, the question is: Is there a way to ask GDAA for a 'thumbnail' version of a document?
Downloading thumbnails isn't currently available in the Drive Android API, and unfortunately I can't give a timeframe to when it will be available. Until that time, the Drive Java Client Library is the best way to get thumbnails on Android.
We'd appreciate if you go ahead and file a feature request against our issue tracker: https://code.google.com/a/google.com/p/apps-api-issues/
That gives requests more visibility to our teams internally, and issues will be marked resolved when we release updates.
Update: I had an error in the discussion of the request fields.
As Ofir says, you can't get thumbnails with the Drive Android API and you can get thumbnails with the Drive Java Client Library. This page has is a really good primer for getting started:
https://developers.google.com/drive/v3/web/quickstart/android
Oddly, I can't get the fields portion of the request to work as it is on that quick start. As I've experienced, you have to request the fields a little differently.
Since you're doing a custom field request you have to be sure to add the other fields you want as well. Here is how I've gotten it to work:
Drive.Files.List request = mService.files()
.list()
.setFields("files/thumbnailLink, files/name, files/mimeType, files/id")
.setQ("Your file param and/or mime query");
FileList files = request.execute();
files.getFiles(); //Each File in the collection will have a valid thumbnailLink
A sample query might be:
"mimeType = 'image/jpeg' or mimeType = 'video/mp4'"
Hope this helps!
I want to upload files using FormData Object(html5) in dojo and without using XmpHttpRequest.
I am using dojo.xhrPost to upload files.
Please post your ideas/thoughts and experience.
Thanks
Mathirajan S
Based on your comment I am assuming you do want to use XHR (which would make sense given that FormData is part of the XHR2 spec).
dojo/request/xhr (introduced in Dojo 1.8) supports passing a FormData object via the data property of the options object, so that may get you what you want.
request.post(url, {
data: formdataObjectHere
// and potentially other options...
}).then(...);
The legacy dojo/_base/xhr module does not explicitly support XHR2, but it does lean on dojo/request/xhr now, so it might end up working anyway, but no guarantees there.
More information on dojo/request/xhr can be found in the Reference Guide.
I'm building my latest app using nodeJS and need to be able to upload multiple files. I have chosen to use Uploadify flash based file uploader.
Unfortunately the 'scriptData' vars don't seem to be being sent. Usual method of retrieval of POST vars in node looks like var postDataValue = req.body.postDataKey; but with Uploadify the req.body object is empty.
Hope someone can help with this.
I had to send the parameters via query string in the end. Must be something to do with NodeJS.
It's not Node.js. req.body is not part of node. It's built into BodyParser and provided by Connect. Mainly used in Express.
See http://senchalabs.github.com/connect/middleware-bodyParser.html
If you don't use it, the req.body object should be empty.