Embed Pdf from Google drive with webview

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.

3 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.

1 Like

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.

5 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?

Got it. Turns out the URL must end in .pdf
Thanks … @Jeff_Hager

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:

  1. 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.
  2. 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.
  3. Unlike the “Preview”, the way you still maintain the “zoom tool” still exists when opened from the iPhone.
  4. While I don’t find the problem that says “having to back up and reopen the webview” with the gadget I have.
  5. 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:

  1. https://drive.google.com/file/d/{ID}
  2. https://drive.google.com/open?id={ID}
  3. 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.