I have a PDF doc screen in one of my apps and even though I have the "Force Refresh" setting set to "No, allow caching" the PDF still downloads every time I access the screen. The PDF is rather large and will change sometimes, so I would really like it to download once and then only update when changed. I would much rather update the PDF on my server then submit and update to Apple everytime I need to change this file. Any help or advice would be great. Thanks!

Consider posting PDF on your server and linking with the Custom URL webpage screen. Or embed the PDF into the app. (That's what you said you wish to do. ) Fred

If I link to the PDF from a custom URL webpage won't it ALWAYS download a new copy of the pdf file by doing this? I do want to embed the file into the app, but I want the ability to update it from my server. As you know if I copy the file into the BT_Docs folder the only way to update it is by resubmitting the binary as an update to Apple.

If I link to the PDF from a custom URL webpage won't it ALWAYS download a new copy of the pdf file by doing this? It should be cached after first view. (but I kind of remember this may not work) I do want to embed the file into the app, but I want the ability to update it from my server. It's either online (on your server) or it's embedded (packaged into the app) As you know if I copy the file into the BT_Docs folder the only way to update it is by resubmitting the binary as an update to Apple. You can switch from embedded to online via the control panel without update to Apple. Not something you'll plan on for if you expect frequent changes, but if you use this technique you'll reduce submissions to Apple.

Fred@mySkylla com > You have made some valid points in answer my questions. Thank you for your help. I will test the custom URL webpage within the next fews days. I will post my finding here. Thanks again.

Hi @Moto110, I've had this happen as well, and I wonder if it's actually downloading the PDF from the network, or just loading it into memory and opening it up? I would expect both scenarios to give me a spinny while it's doing its thing. Keep an eye on LogCat (Android) or Console (Xcode) to see if it's actually hitting the network for the file. I would be interested to see! Mark

I have done some testing and this is what I found. I created a 14mb test PDF so that it was big enough to have a noticeable difference between opening local or downloading every time I access the screen. Just for reference I’m on a 90mb down internet connection via Wi-Fi on iPhone 4S 1. I added this PDF Document via the PDF Document screen using a URL and setting the document properties setting "Force Refresh" to "No, allow caching". I tested this multiple times by accessing the PDF document URL screen and waiting about 14 seconds each time as the document was downloaded. 2. I added the same PDF Document via a Custom HTML screen and embedded the PDF in the HTML code. This option took just as long as option one and did not produce a desirable display of the PDF. 3. I added a the same PDF Document via a third PDF Document screen using the Local “BT_Docs” folder option and the file opens within about half a second. I do see the spinning “Loading” icon for a brief moment. Now that these screens have been loaded on my device I turned on Airplane mode and accessed the PDF screens again. Here is what I found: 1. Option one displays a network connectivity error and does not load the PDF document. 2. Option two Embedding the PDF in Custom HTML does show the couple lines of HTML text I added before the PDF embed code, but does not display the embedded PDF and gaves a network error. 3. Option three storing the PDF document in the “BT_Docs” folder works as expected displaying the 14mb PDF file within a second or less. I think I know what I need to do and that is store the PDF local and hope that I don’t need to update it frequently. On a side note I found this really good website for generating code to embed PDF documents in HTML. It might help someone else on a different app project. Here is the link: http://pdfobject.com/generator.php

Try posting PDF on a website/Dropbox and access via Custom URL webpage screen. Not saying it'll be better than embedding, just an option. You can also use Launch Native App (browser) and test the result. On the sidenote: embedding images into HTML is a useful tool. Hadn't tried it with the various doc types. Plus, you could also convert the PDF to HTML. Fred

I was discussing this with David @ buzztouch, and he says grabbing data from a URL always causes a force refresh, even if you have set it to "No, allow caching." So, your scenarios above are working as designed, but I did suggest some alternate wording in the screen to let people know of this behavior. If the PDF won't change that often, I would offer it with the app, and just provide app updates. That should make for an overall better use experience anyway. Mark

If pdf is too long in size you can use google pdf viewer since it doesn't load pdf at once and it has its own mechanism of optimizing pdf to internet connection. This is also not a cache. but atleast it would reduce waiting time for user. Here is the link how to use it https://docs.google.com/viewer/?pli=1

Just tried the Google docs viewer, very nice. It does require the user to sign into google docs, which could be a limitation, but otherwise very useful. Fred

Fred.. No it doesnt require any signin. for example open this link: https://docs.google.com/viewer?url=http%3A%2F%2Fresearch.google.com%2Farchive%2Fbigtable-osdi06.pdf NOTE: -- > This is not about sharing your google DOCS --> File must on server for ex: http://example.com/example.pdf --> Now add that file name to end of the google viewer https://docs.google.com/viewer?url=http://example.com/example.pdf it will open the PDF without any signin --> its not about sharing your google DOCS. in that case it will ask you signin. This is about showing your server PDF with the help of google pdf viewer.

Just tried it and you're correct. But I went to the link you gave https://docs.google.com/viewer/?pli=1 and entered a URL to a PDF I clicked on the create a link button, nothing appeared to happen so opened a new window and pasted what was in the clipboard. A URL took me the the html view of the PDF. I copied the URL into a website which didn't show the html view until I signed into google docs. The PDF URL I used is one I grabbed from a forum post. It's a PDF someone had placed onto Dropbox. Fred

btw im working on something which will help us to create a offline cache from buzztouch URL but im still working on it. it seems its working. but need to verify with various conditions. so offline content with custom URL should work hopefully.

Perchance html manifest? Fred

yes html manifest ..!! but that does work ? i see it works sometime and then it doesnt.. it is unstable sometimes.. did u ever try it ?

Yes, been playing with it. Fred

I was really relying on this feature, and it has worked for me in the past, although briefly. I have a menu list with over 100 menu items, each menu item takes you to a different PDF (approx 45kb in size). I will change these often and was very much looking forward to both the offline caching and the ability for an easy update. Like I said, I was able to access some PDF's offline early in my development of the app. It worked great. I am now unable to get them to cache. I don't think this is, as someone mentioned, working as intended. If anyone knows a fix, please let me know.

Hi @BranX26, What sort of issues are you having? Are you accessing a screen while connected to the network, then going offline, and trying to access the same screen again? Mark

I simply don't want to have to require a constant active Internet connection for my users to view the PDF's, but I also want them to refresh for updates if desired. I will probably change a few PDF's per months. I didn't want to have to submit an app update each time I change a word or two in one of my 135 pdf's. I thought this was the point of document caching.

As of right now, my PDF is re-downloaded each time it is selected. Even though caching is turned on.

The app can't cache the document until it's retrieved for the first time. There is no way to have the app cache all documents before they have been requested by the user via a menu item tap. By default, in buzztouch, if you specify a URL for a resource, whether you have allow caching turned on or not, it is supposed to cache the resource. If you have retrieved the document once, and then turned off the network, and tried to retrieve it again, it should at least bring up the cached version. If not, then there may be a bug. Mark

It does not. There must be a bug. I'm just having the same problem as the initial poster had... It's totally fine to have to download it the first time.

It's not a bug in the sense that PDF files don't cache. It's perhaps a bug in the sense that the documentation would lead you to believe it should cache. Fred

What, then, is the purpose of the "Force Refresh: No, Allow Caching" setting? Because it says this: "Force Refresh: Documents are downloaded and cached for offline use when possible. This works especially well for PDF, Word, Excel, and PPT documents."

It seems to be working again. I just updated the BT_config.txt file and now my PDF's are caching. I'll let you know if it stops again.

@Fred - Not an error in documentation. I asked @David about this very question, and it's supposed to work as we believe it is (meaning, it'll cache the document for offline use). However, the No Caching parameter does not work for URL resources as I mention above. They all get cached...that's by design. Mark

Seems, we were both wrong. Just tested and found as follows: A. "Yes, force refresh" didn't cache. B. "No, allow caching" did cache. Didn't have to recompile, just refreshed app data (Online Config file). This was on BTv2.0 Android. I remember someone posting that PDF didn't cache, perhaps that was BTv1.5 iOS. Perhaps just bad memory. Fred

I'm using v1.5, and it caches intermittently

Duplicate post

I'm using v1.5, and it caches intermittently Perhaps the answer is in how the file is named. Just reread thread and original poster said PDF screen via URL didn't work but I find it does. Fred