I have an html page in my app, which I display using the custom url plugin. As I update this page a couple of times a day, I would like the app to always pick up the latest version. The app does not know the content has been updated because it is an html page that is not managed in the control panel, so I have set the plugin document behaviour to Force Refresh. I am finding that when the user clicks the refresh button on the home page, the app does not always refresh this html page. If put my phone in airplane mode, the page is still retrieveable. I can even hit refresh in airplane mode and the page is retreived. All this points to the html being cached. If I remove the app from memory, then run the app again, it clears the cache and the app will pick up the latest version of the page, but I can't expect users to do this. Can anyone suggest a way to overcome this please?

Forget my post - was for Android sorry!

Is your findings such that a Refresh does not retrieve the latest HTML? Just making sure I heard you correctly. -- Niraj

Have you tried the auto-refresh trick documented in the outdated how-to by Thomas Boyd?

Hi Niraj. Yes a refresh does not always retrieve the latest html. And yes, I have implemented Thomas's mod, but it isn't going to fix this problem as the app does not know the content has been updated because it is an html page that is not managed in the control panel Any idea's Niraj?

Strange. In the Control Panel, it specifies the HTML contents are always fetched from the WYSIWYG Editor because it's a file on the server hard drive. I remember asking David if the CustomURL content is cached, he said "yes", at which I got happy. When things are cached, then that means a Refresh should purge the entire cache. I am not with my Mac, when will BuzzTouch be loadable onto an iPad?! Look for "cache" within the BuzzTouch code please? Also, look at the customURL plugin to see how it names the file that gets cached -- I think it prefixes the screenID onto the filename. This is strange -- research and experiments are essential. ( Is everything fresh and updated and you are using BuzzTouch.com control panel ? ) -- Niraj

My app is on my self hosted setup. The html that the URL is hosted on an external server. This issue doesn't happen every time, but when it does, I need to remove the app from the device memory to fix it. Ther eis definaltely some caching going on somewhere. What David told you may hold good for BT 2.0, but BT 3.0 seems to have some oddities. I don't know if the core team has a list of core things that need attention (I do), and if so, is this on it? As for looking at the code, good advice, sadly I am not a coder. I'll give it a go, but when it comes to IT, I am much better at finding things than being able to fix them myself. But then good testing is a skill too!

I don't know if this problem is on the bug list. Pester me later this week to investigate and see if I can replicate your problem. Meanwhile, I will stay on pause until you verify the same problem exists by using BuzzTouch.com Control Panel on a freshly downloaded app project. -- Niraj

It's probably not refreshing because nothing is changing in the app itself. The URL is staying the same so the app feels satisfied that all is up to date. I use the HTML Doc plugin a lot and when I update those documents on my server, I just update a fake page on my Buzztouch control panel and hit publish. This causes the app to think that there is something new and automatically refreshes. When I click on the real updated page, it retrieves it from my server updated. Dave.

Hi Dave, I'll try that and see if that makes the change to the custom url page. But, the thing is that sometimes it refreshes when I hit refresh and sometimes it gets cached and I can't understand why it is being cached at all. Niraj, I'll see if I can reproduce this problem on my BT Hosted test app - I'll slip it into there. Thanks for the idea's guys, keep em coming!

Dave's observation makes good sense. The on-device cache should only get flushed when a change to the configuration is detected. That means something was changed on the Control Panel. The two timestamps are compared (cached config file and the Control Panel configuration file). If there is a newer version in the Control Panel, then the on-device cache is cleared. The newer configuration is then downloaded and cached on the device. As each screen gets loaded, it's remote images and docs (PDF, HTML, etc) are then newly cached on the device. Try your testing with that algorithm in mind. I believe the timestamps are NOT compared between the remote URL and the cached content. An update to the remote URL's contents will not overwrite the cached content. The older content should always be displayed until the entire cache is flushed due to an update of the Control Panel. Hopefully we will soon reach ground truth with a few tests by AlanMac! :-) -- Niraj

I've looked at the config.txt and the timestamps are always one-hour behind. - e.g the timestamp says in config.txt it is 10:00am but it is really 11:00am. I have adjusted my CP time offset, which needed doing after we moved to British Summer Time. I think this is a red herring, but I thought I'd mention it anyway. I've also tested on my BT hosted Control Panel, so far the behaviour on this is identical. The theory on comparing timestamps refers specifically to the way Buzztouch refresh works in the context of control panel updates. I think perhaps it is simply that Force Refresh just doesn't do what I was hoping it should (i.e. no caching ever and checks and refreshes every time an app refresh is called from the home page top left hand corner). THis works sometimes, but not always. I think, but I'm not sure, that it did work this way in BT 2.0 and was consistent. If I need to make a change in the CP to get it to force refresh, that will be a bit of a pain; it is beginning to feel like it is all about getting that config.txt timestamp to change without being in the control panel. If I knew how to code, a script to read the config.txt, update the timestamp and write the whole config.txt back at the click of a hyperlink outside in the CP could work. Or could it?

Making a change to the control panel and publishing to force an update is really not a big deal. I have an "update" screen in my control panel. It can be any type of plugin you desire. It is not included within my app so the end user never sees it. When I want my app to update because I changed a document that does not reside in my BT control panel , I just change 1 letter in the title of the plugin and then hit publish. This forces an update in the app when the user opens it and for me, when I click on an HTML doc in my app it also updates. Dave

Dave, good idea, works for some scenario's and I'll keep it as a backstop. I suspect you don't even need to make the change to that plugin, just click save. The problem for me is that I may not know when the changes to the html are being made and I don't want to give my customer access to a control panel. Giving them a button to click anywhere else would be good though. I still cling to the possibility that Force Refresh isn't doing things as it should.

Because I don't want to scroll back to the top and wade through it all ... Call me obstinate ... Say it again what is your ideal app behavior. I suspect it might be something like "When the HTML source changes, update the cached copy on the device." -- Niraj

I'll just call you lazy (lol)

I want the Force Refresh option in the custom url plugin to prevent page caching completely

@AlanMac did you ever find a solution for this? I have the same problem and also assumed Force Refresh would ensure custom url are always retrieved. Thanks, Lee

No, sorry Lee, it just seems to be consistently inconsistent!

Ok, thanks. I'll let you know if I come up with any solutions.

A way around this is to update the viewWillAppear function in the BT_screen_customURL.m file. Simply don't allow the function to know the initLoad has been called: Change this part: //load url if(didInit == 0){ didInit = 1; [self initLoad]; } to this: //load url if(didInit == 0){ didInit = 0; [self initLoad]; } A bit of a hack and I'm sure you could probably dynamically set this didInit using the Force Refresh flag setup for the screen. Cheers, Lee