I recently developed a way of publishing html pages directly from excel at the click of a button using macros. which does not use the Buzztouch control panel, so the app doesn't know when these pages have changed. I have been trying to figure out a way to make my app refresh when I publish those html pages and I have come up with two idea's: 1) Option 1 - to find a way of 'poking' the control panel by writing a file to somewhere to make the control panel update the report to cloud url timestamp. I see this as simulating the change of an app plugin page on the control panel, but without manually doing so. When the app checks the report to cloud URL, it does a standard refresh. The idea is this would work with the control panel, for the app there would be no changes. I don't know if this is possible or how to do it due to my lack of coding skills. 2) Option 2 - when I update my html, I could create a separate text file with a single timestamp line in it and publish it to a specific location on a server. When the app does a report to cloud URL, it would also do a check of this file at the server location and if it sees the timestamp is later than the one in the app config.txt, the app would do refresh. This idea does not affect the control panel, but requires does some work to be done in the app. I think this is may be more feasible but again, not sure how to do this as I am rubbish at coding. I'd be really keen to hear from anyone who has done something like this or has some idea on how it could be achieved please. Thanks in advance, Alan

I would take control of the report to cloud time stamp by putting the time stamp in a new file and sticking it on your server. Whenever you publish a new HTML file, this time stamp file should be updated as well. Your app should point to this file in the bt_config.txt file. A more complicated solution is to write a php file that checks the time stamps of each HTML file to see if they've been updated, and if so then update the report to cloud stamp.

Hi Chris. Here is what I did - I worked out a way of generating a one line text file out of excel, with the timestamp in exactly the same format as the core. I called it rtc.txt and saved it on my server. I then pointed the control panel entry for my app to the URL for. I can then update the text file by FTP whenever I want. I then made the entry in my config.txt as you suggested. I started my app, closed it, loaded something else, repeated different combinations many times, but at no time did my app prompt for a refresh. My conclusion was that perhaps a timestamp in a text file isn't enough and it needs to be a php file doing something extra. Am I wrong ?

Text file is fine - the app doesn't know the difference. It's probably looking at the old URL because the config file is saved in cache. Make sure to update the cloud URL on the control panel (core settings) also

Thanks Chris, appreciate the re-assurance that the text file should be enough, I'll try again. NB - the text file content is : {"lastModifiedUTC":"Tue, 24 Jun 2014 12:36:03 -0700"} Alan

What about using the customURL instead of the customHTML? But that would refresh every time and not just look for a date stamp.

Hi Susan. Actually, I am using custom url, this is where I started, on ios it seems to both cache and not always refresh https://www.buzztouch.com/forum/thread.php?tid=D9E4071F54AD770FCDA1827&currentPage=4

Hi Chris, gone through everything again today and I am sure that is definitely not picking up the text file that I created. I am also sure it is not caching the standard control panel time-stamp - updating anything in the control panel does not trigger a refresh. NB - the text file I am using is called tstamp.txt and the content is : {"lastModifiedUTC":"Tue, 24 Jun 2014 12:36:03 -0700"} I feel I am close, any thoughts? Alan

To summarise, If I change anything in my control panel now, I don't see a refresh, which proves the change of location of my report to cloud URL has been picked up. If I update the text file with a time-stamp (on my server), my app does not refresh, which proves that my report to cloud text file is not being picked up by my app. I am sure the config.txt is correct in the app, I have cleared the app from memory, rebuilt it from scratch and repeated everything several times. I am a bit stuck. I am clutching at straws here, but I am wondering if this changing of the report to cloud url approach still works with BT 3.0?

I have some debug. 2014-06-27 16:39:28.920 mytestapp2016[634:60b] mytestapp2016_appDelegate: supportedInterfaceOrientationsForWindow 2014-06-27 16:39:32.736 mytestapp2016[634:60b] mytestapp2016_appDelegate: applicationWillResignActive 2014-06-27 16:39:32.737 mytestapp2016[634:60b] mytestapp2016_appDelegate: applicationDidEnterBackground 2014-06-27 16:39:36.326 mytestapp2016[634:60b] mytestapp2016_appDelegate: applicationWillEnterForeground 2014-06-27 16:39:36.331 mytestapp2016[634:60b] mytestapp2016_appDelegate: applicationDidBecomeActive 2014-06-27 16:39:36.332 mytestapp2016[634:60b] mytestapp2016_appDelegate: reportToCloud 2014-06-27 16:39:36.334 mytestapp2016[634:60b] BT_fileManager: File does not exist in cached directory: "appModified.txt" 2014-06-27 16:39:36.335 mytestapp2016[634:60b] BT_fileManager: saveTextFileToCacheWithEncoding: "appModified.txt" encodingFlag: -1 2014-06-27 16:39:36.340 mytestapp2016[634:60b] mytestapp2016_appDelegate: Is reporting to cloud, reportToCloudURL 2014-06-27 16:39:36.341 mytestapp2016[634:60b] mytestapp2016_appDelegate: reporting to cloud at : http://www.myserver.com/appfiles/RTC/TimeStamp.txt&currentMode=Design 2014-06-27 16:39:36.342 mytestapp2016[634:60b] BT_strings: mergeBTVariablesInString (before): http://www.myserver.com/appfiles/RTC/TimeStamp.txt&currentMode=Design 2014-06-27 16:39:36.343 mytestapp2016[634:60b] BT_strings: mergeBTVariablesInString (after merge): http://www.myserver.com/appfiles/RTC/TimeStamp.txt&currentMode=Design 2014-06-27 16:39:36.419 mytestapp2016[634:60b] BT_fileManager: File does exist in cached directory: "appModified.txt" 2014-06-27 16:39:36.420 mytestapp2016[634:60b] BT_fileManager: readTextFileFromCacheWithEncoding: "appModified.txt" encoding: -1 2014-06-27 16:39:36.421 mytestapp2016[634:60b] BT_fileManager: saveTextFileToCacheWithEncoding: "appModified.txt" encodingFlag: -1 2014-06-27 16:39:36.426 mytestapp2016[634:60b] mytestapp2016_appDelegate: appModified.txt does not exist in the cache. Not checking for updates. 2014-06-27 16:39:43.582 mytestapp2016[634:60b] mytestapp2016_appDelegate: supportedInterfaceOrientationsForWindow

I notice the app is adding &currentMode=Design to the URL - could that be it? What is the significance of appModified.txt ?

From checking the live config.txt json from the control panel after an update, I have also noticed that the time from the buzztouch servers is 5 minutes fast. So I think if my test of report to cloud URL were working, I think I would have to wait at least 5 minutes before my refresh could work?

Hi Alan, It seems to me that they way you are doing things should be correct. I would imagine that a refresh should occur. If what you are doing is changing HTML files that you host remotely, you shouldn't actually have to worry about an app refresh in general. If you reference the HTML file from a URL, and have the properties of that page set to Always Refresh, then each time the user accesses that screen in the app, it should automatically pull down the latest version. I don't use the Custom URL screen...I use the HTML doc plugin, and this all works as expected. Perhaps try that instead of the Custom URL plugin? The " &currentMode=Design" line says that it's looking for a config file where the Mode = Design. If your app is running with a Design = Live mode config file, which it should be, then it won't pick up any changes. Mark

Thanks Mark, your feedback helped me dig a little deeper. Being a test app, I am using design mode, the config file matches there. I started thinking a bit more about the URL. As a test, I tried dropping http://www.myserver.com/appfiles/RTC/TimeStamp.txt&currentMode=Design into a browser and guess what - it didn't resolve. That construct passes extra parameters in the url and I think maybe a php script can deal with that, but a simple txt file does not. To prove my theory, I then tried http://www.myserver.com/appfiles/RTC/TimeStamp.html&currentMode=Design thinking browser and server would understand an html file better, but that didn't work either. My next idea was to rename the text file to TimeStamp.txt&currentMode=Design (yes, with the verbose extension). I FTP'd that to my server and guess what - my app prompted me for a refresh for the first time - whoohoo! My thinking now is that the app is always going to pass parameters in the URL to the report to cloud destination URL and any alternative location needs to handle that. My fix is a bit crude, but it proves a concept. I don't know for sure, but if I added push, the parameter would be on that URL too. I think a better solution would be to place a php script on my server, that picks up a timestamp text file that can also be placed there. The script would handle any parameters passed in the URL (even by ignoring them), and always be able return the timestamp value in the file. If you guys agree with my conclusions please let me know, that would be great - my next problem will be the php!

It makes sense that the first URL wouldn't resolve, because you're trying to pass a parameter to a text file. If it were a php script, and it was set up to handle the currentMode parameter, it would work for sure. You don't need any parameters if you are just trying to grab the config file to force an update. All the parameters that you normally see when using BT.com or your self-hosted server are tied to a php file that helps decide which config file to grab. If you already know which one you want...because you generated it yourself...just point directly to it. That'll take care of it. Make sense? Mark

It almost makes sense, Mark. I'm good with para 1, but not para 2. Just to clarify, I am not changing the config.txt file, I am using the standard config.txt file mechanism. I'm only playing with the refresh from cloud URL mechanism. Your guide and @chris1 both say a simple one line text file can be used, I am learning that it isn't that simple. The passing of parameters to the Report to cloud URL is buzztouch app behaviour in BT 3.0, which I uncovered by adding a diagnostic to the code today (I'm very proud of myself for that btw as I can't code). Fact is I can't stop the app adding those parameters to the URL, which means a simple text file will never work. Does that make sense? Alan

Yes, I think that makes sense. Let me summarize: * You want to create a file that has the date time stamp of the last update to the app. * You want the app to check that file, note that an update has occurred, and then download a custom BT_Config.txt file that you provide. Is this correct? Going back to an earlier question...are the updates you are doing just updates to HTML files that you host at a particular URL? Because if that's the case, than you don't need any of the stuff above, because the app can be set to force refresh each HTML page. If that's not happening, then it's a bug that needs to be investigated. The only real reason you need the above steps would be if you're making changes to the app that alters the contents of the config file itself. Mark

Hi Mark Sort of. I think we are not quite on the same page, but getting closer. Please stick with me. * I want to create a file that has the date time stamp of the last update I made for the app (html content I use with the custom url plugin). * I want the app to check that file, note that an update has occurred, and then download the standard BT_Config.txt file that the control panel provides (I am not editing config.txt - I looked at doing that before but not now). I also want the app to refresh linked content (URL's, menu data, remote map info, etc) And about the updates to HTML files I host at a particular URL? I think Force Refresh doesn't work that way in BT 3.0, don't know why and yes, I think it could be a bug - I raised it here http://www.buzztouch.com/forum/thread.php?tid=11042C35E781C29ECB4740E&currentPage=3

Looks to me like you're missing a "?" before the first variable in the URL. The way URL variables work is that the first one should be preceded with a ?, and all others preceded with a &. Your URL looks like: http://www.myserver.com/appfiles/RTC/TimeStamp.txt&currentMode=Design It should be: http://www.myserver.com/appfiles/RTC/TimeStamp.txt?currentMode=Design

Gotcha....but I don't think you need to do it this way. If you make a change to the HTML content pointed to by the Custom URL plugin, you're not actually making a change to the app. You've not changed anything in the control panel (unless you're changing the URL or adding new content via more Custom URL plugins), so the config file won't have changed at all, and there is really nothing to refresh. The content of the HTML file may have changed, but that content is not reflected in the config file. Hopefully that makes sense. I'll contend that all you need to do to make this work is ensure that Force Refresh is designated for each of your Custom URL plugins. That way, each time the user opens the app, and tries to access that content, it'll get updated automatically. Causing a whole app refresh won't do anything...only actually trying to access the content will cause a refresh of that content. Sounds like that feature isn't working. Is that just for Android, iOS, or both? Mark

Yeah, I agree - if the only thing changing is the content of HTML files already linked to in the app, then it should be on the URL plugin to force a refresh, not the entire app. But if you're adding new HTML files to the app, then the app needs a refresh.

Guys, I know this doesn't sound as if it should behave the way I describe, but I am convinced of what I see. Its funny how one issue work-around leads another issue. I have been on this for a week now, I really feel as if I am getting to the bottom of it. Mark, I can assure you that Force Refresh is designated for each of my Custom URL plugins. I started this whole journey because force refresh didn't do what I expected. For example I have seen that my page on my phone can be rendered when I put my phone into airplane mode. On BT 2.0, it would not render the page if force refresh is enabled and no network was available. This is a behaviour change that I noticed when developing my latest app (published yesterday). I have tested this and it is easy enough to reproduce. Chris, on the report cto loud url syntax with the missing a "?" before the first variable - this is extract debug output from my app running in xcode, meant to help fathom what is going on. This is the URL the app looks for. I put TimeStamp.txt in the control panel, the app appends the variables to TimeStamp.txt. I have not added anything to make it do this, that is just the way it is. The report to cloud URL may have worked on BT 2.0 with a simple text file. I am not sure when the parameters started being passed in. I do have the alternative report to cloud URL functioning with my bodge of a text file, a bit of php will be the icing on the cake. If nothing else I hope I have helped to point out a couple of core issues that need investigation.

I'd agree that the force refresh issue needs to be investigated. I'll do that, and report my finding to BT! Mark

Thanks Mark, As an example try this app https://itunes.apple.com/us/app/2014-world-footy/id884514001?ls=1&mt=8 the first two screens are custom url with force refresh. Go online, open the pages, go offline, they are still there. Stay offline, delete from memory, then open the app again, pages not available (until you go online again). PS I just double checked that I set force refresh explicitly to make sure I am not going mad. Let me know if you need the source URL's and thanks again for your input, I would not have got this far on my own. Alan

The above scenario I think is the way it's supposed to work. * Install the app. * Open it for the first time, go to a screen the gets it's content from a Custom URL. * If the app is offline, it won't be able to get the content. If the app is online, it'll grab the content (and it should cache it). * Close the app. * Open the app again, and go to the same page. The app will try to grab the page again. If the content of the page has changed, it'll be reflected. If the app is offline, it should use the page that it cached the last time it was retrieved. If you delete the entire app, reinstall, go offline, and go into the app, I wouldn't expect the content to be there. It has to be downloaded an initial time before it can be cached. So, if you install the app fresh, and are then offline when you try to retrieve the content, it'll fail until you can go online again. In any event, I'll try to do some investigating to see if this plugin is working as designed. Mark

On the actual URL that the app is looking for, I looked again at the code after Chris's point "Looks to me like you're missing a "?" before the first variable in the URL" I agree. As a simple workaround, I now call my textfile name in the control panel "TimeStamp.txt?" That works. Cheers Chris

Mark, the point you made here may the nub of my issue: "* Open the app again, and go to the same page. The app will try to grab the page again. If the content of the page has changed, it'll be reflected. If the app is offline, it should use the page that it cached the last time it was retrieved. " If the app is offline, I think it should use the page that was cached *IF* Force Refresh is set to 'off'. If the app is offline and Force Refresh set to on, I thought the app would report a network error. Am I wrong?

A related side issue - I have noticed in my app that the refresh behavior for the custom url page on the home page of my app is different than if the same page is shown elsewhere in the app. I don't understand why, does anyone know if this is this deliberate?

Good question. My assumption would be that if it's the first time you try to access the page, and there is no network connection, then it would report a network error because there is no cached page to show. I "think" if there is a cached page it'll show it instead of throwing an error. But I'd have to climb through the code to verify. Mark

The reason I started on this journey was because I have a scenario where the content is html and generated outside the control panel and shown in my app using the custom url plugin. It wasn't updating in my app when I expected it to. Interestingly, by working out how to do report to cloud, I have a work-around for the behaviour of Force Refresh of the plug-in, as triggering an app refresh will give me the end result I need, even if it could be considered as a sledgehammer to crack a walnut. However, also I agree with yours and Chris's comments above, I would have preferred not to have to do it. And thanks again guys, all your input really helped.