Hi, guys,
Does this anyone already know? I accidentally discovered that a pdf file stored on google drive can be embedded into a webview component if the end of the URL is replaced with the /preview.
4 Likes
Iâve been doing something similar. Might have to try the Preview method to see if itâs any better.
I guess one advantage of wrapping the url with the Google Doc Viewer url, compared to appending /preview, is that the PDF doesnât need to be stored in Google Drive for it to work.
1 Like
Then where is the pdf file stored?
Can you provide any info if this works would be great.
It can be stored anywhere as long as itâs publicly accessible. In my case, I have some PDFâs stored in google drive, some are stored in glide, and some are just pulled directly from other websites.
Wrapping the url, forces Google to retrieve the file from wherever itâs stored, and displays it in itâs document viewer, which embeds nicely in a WebView component.
The only problem Iâve ever had is that sometimes the document wonât load. Just a simple back button and opening the document again takes care of it.
Thanks Jeff
Are you willing to try with /preview, as a comparison of the behavior?
Is this what you mean?
(https://docs.google.com/viewer?embedded=true&url={Document})
3 Likes
Yes, that is what I mean.
Iâll try it out a little later. I imagine itâs the same viewer either way.
1 Like
<iframe src="https://drive.google.com/file/d/{ID}/preview" width="640" height="480"></iframe>
I usually use this, it works very well. {ID} is the Drive documentâs ID.
6 Likes
Thank you, Thinh Dinh. Before I start to change quite a number of components in my application, Iâm still curious about Jeffâs offer, at least being able to reach pdfs from other sources. Have you ever compared the behavior of the two methods, although it is true that they open the same viewer?
Mine only works with Drive files, but I think itâs pretty reliable thus far.
Jeffâs works with any document, but if I recall right, it has an hourly quota and can break if your users âcallâ it too many times.
Iâm trying Jeffâs. Why does the text of the Html document appear?
Also, I want to extract the common URL into /preview, what is the proper regex to use?
I had to modify my app a little bit to test this, since itâs designed to use the wrapping method exclusively if the url contains âPDFâ, or âDriveâ. Ultimately, it appears to be the same viewer regardless if you wrap the url, or append the preview.
One thing I noticed is that if you use the â/Previewâ method, then you have to manipulate the URL. It seems that I got the âcannot be embeddedâ message if I directly appended â/previewâ to the end of the url, that I got from google drive when I retrieved the shared url. I had to remove the âview?usp=sharingâ part before appending â/previewâ. So, with that, it does appear to be a little more involved to clean up the url before appending â/previewâ to get it to work with a webview component.
With that said, I did run a test with the same PDF, but I used my wrapping method with a PDF stored in glide storage and compared it to a PDF stored in google drive that used the preview method.
Using the preview method did appear to be much more reliable as far as consistently opening the viewer in a webview component every single time.
Using the wrapping method, I probably get a failure for the PDF to load 1 out of every 5 tries (completely closing the app after each try). I really donât know if itâs something on my end with my old phone, or something on googles end because it has to retrieve the file from an outside source before displaying it in itâs own viewer. Iâm guessing itâs a cache issue somewhere.
As a third test, I tried using the wrapping method with the pdf stored in drive and I started getting the html text issue that you had. Not sure why. I remember dealing with that a long time ago. I think this was a solution for me at the time. I had to use a different url.
As of right now, I donât typically store files in google drive if I donât have to. I continued testing, and I did get the webview to fail once or twice with a drive stored file and using the wrapping method.
I wouldnât say that my tests are conclusive. I could probably poke at it all day with varying results depending on where the file is stored, and which method I used to display it in a web view. Keep in mind that my user base is only one or two users, so having to back up and reopen the webview is not a big deal for us. If you intend to store all of your files in google drive, then keep in mind googleâs usage limitations and the fact that itâs not truly meant to be a web host for files. But if you do, then it might be worth setting up your table to have a column with the url wrapped using the same method I use and another column that appends the preview to the end. Test both and see which one works the best.
If you intend to use the viewer with pdfâs stored in glide or any other website except google drive, then Iâm not aware of any other method that will allow you to nicely view a PDF inside of a webview component. The wrapping method was the only one that gave me the results I was happy with. If you find something else that works, I would be happy to now about it.
2 Likes
Great fun with your scientific analysis.
I try to give a resume of the comparison of the two methods:
- Itâs true that if you use the âpreviewâ method, the first âunable to embedâ splash will appear and I didnât find it your way. This is a very important positive value.
- Being able to accommodate multiple sources is a big plus, but how do you manage differences in URL structure? While in my application I rely on use with google drive, I will not rule out using other sources in the future. For info, I have Google Suite with unlimited storage and to manage assignment big files from students.
- Unlike the âPreviewâ, the way you still maintain the âzoom toolâ still exists when opened from the iPhone.
- While I donât find the problem that says âhaving to back up and reopen the webviewâ with the gadget I have.
- Regarding the quota mentioned by Thinh Dinh, it needs a longer testing time, and it will be a big problem if it happens, especially during the exam, with user behavior to access files in my environment.
In general, the way you look is very nice.
1 Like
The url structure doesnât really matter. I just wrap the url (any url that leads to a pdf) with the google docs viewer url using a template column. With the exception of text of the Html document showing instead of the PDF for PDFâs stored in google drive, using the different https://drive.google.com/uc?id={ID} url instead of https://drive.google.com/file/d/{ID} seemed to help take care of that for me.
For me, PDFâs can be uploaded through the app to glide storage, and the resulting url is wrapped in a template column and shown in a webview component. Only a couple PDFâs are stored in google drive.
1 Like
I still donât understand what you mean.
Suppose I have three different kinds of URL structures that a user might have such as:
- https://drive.google.com/file/d/{ID}
- https://drive.google.com/open?id={ID}
- Another URL ending in .pdf
then I give freedom to the user to choose all kinds of ways to upload/share files. Can this be done without extracting the ID (except no.3) to fill in the same column?
var upFile = DriveApp.getFolderById('YOUR FOLDER ID HERE').createFile(blob).setName('newFileName');
var id = upFile.getId();
var url = "https://drive.google.com/uc?export=view&id="+id;
1 Like
Shouldnât matter which url structure they have. Just wrap each PDF URL with the Google doc viewer url and hopefully it should work. It would be best to just try it and make sure it works regardless of the url structure.
No, you shouldnât have to extract the ID at all. Just take the full url that you have, regardless of where the PDF is hosted, and wrap it with the Google doc viewer url.
https://docs.google.com/viewer?embedded=true&url={PDF URL}
All Iâm saying is that Iâve had various problems with it, but not enough for it to be a concern to me. If it works for you then thatâs great, but only you can test it and know for sure if you are happy with the results.