Ok, I've spent a few hours perfecting my HTML docs so they appear the way I want them to on both the iPhone & iPad in both Portrait and Landscape. But, now I find that the screen using the HTML Doc is not refreshing. I did not change any of th code, only the HTML docs. I've tried the following: - copy/paste the URL's from the Buzztouch control panel into Safari and the new content shows up no problem. - tried hitting the REFRESH button on top left of the app. - tried closing the app and re-opening it on both iPhone & iPad. - tried setting FORCE REFRESH to ON for the HTML Doc screens in the Buzztouch control panel. So, anyone know what's going on and how to fix this? BTW, the way this HTML Doc should work in my opinion is that it should detect if there is a newer version if the HTML Doc and download it....from a user perspective, you cannot ask them to hit the REFRESH button :-) I'm almost finally done with this 1st app using Buzztouch...so close, and yet so far away :-) LOL

Hi Steve, The best way to debug this is to watch the Debug Console or LogCat and see what it says when you're loading that screen. It'll tell you if it's loading the file from cache, or if it's downloading it fresh from the Internet. Once you know what it's actually doing, we can debug from there. And the way you think it should work is the way it's actually supposed to work! Mark

Thanks Mark. Will check out the console messages in the simulator. I'm testing on real devices, ie iPhone4 & iPad3, since I want to make sure the user experience is good. Cheers

Cool. You can connect your device and still test while having output go to the debug consoles...that's very helpful info.

Yep - that debug info can usually tell us a lot. If you can't make heads or tails of it, paste it here for us to take a look.

You can also try the following anytime you start noticing weird behavior in the simulator... -Do a "Clean" and "Build" in Xcode -Delete the app from the simulator (long press on the icon, and answer YES) -Completely close Xcode and re-launch it

Thanks Stobe. The problem is in the app on the devices...but will test again in simulator and try your suggestions...cheers

I have seen this too - on iOS, but ok on android. I found the refresh worked after a long period of time all on its own. Why, I can't say. Alan

@AlanMac. Ok, so it's not just me! These little bugs are driving me nuts :-) @chris1, @stobe, @GoNorthWest. So, this is getting weirder and weirder. It works in the simulator but not on the devices (iPhone4/iPad3). So, my guess is that the app is caching the old version of the HTML Doc and not getting a new version.

When I noticed it, I was running an Android and IOS verson of the same app. Android updated, IOS didn't. The fact that they were both pointing to the same page is what convinced me it I didn't need to see a doctor. Next day, all was good. I suspected some kind of network timeout that was shorter on IOS, nothing was ever proved though.

@BuzzingSteve: Did you try a complete delete from the device as well, then re-build? And I wouldn't consider these "bugs". You're just experiencing some of the nuances of caching that can affect any type of platform (desktop browser, etc).

@Stobe. I do a complete delete and rebuild of the app on the device every time I install it on the physical devices. I tend to disagree in terms of whether this is a "bug". This is such a simple function: grab the latest version of the HTML Doc, and display it. If the code is not checking that there is a newer version of the HTML Doc then I would consider that a bug. Also, from an end-user point of view, they should not have to go through hoops to make things work. If this is not an issue with the code, then what solution would be best? Imagine having your app installed on 1000's of devices, you update an HTML Doc, and people never see the update. How would you even know this was happening? Even if you found out that this was happening, what solution would you recommend? Tell 1000's of people to reinstall the app? Every time you "happen to notice" that the content was not updating? I like find solutions that require very little interaction from the end user. At this point, even if I somehow get this working by uninstalling and re-installing the app on the device, this is not a permanent solution :-) I'm open to any ideas for that. Thanks!

Until we see what's happening in the debug data, it's all speculation. The default for that screen is to grab the latest file each time it's requested, unless a network connection is not available. Then it grabs from cache. Debug data will tell us what's going in for sure.

@GoNorthWest. Will get the debug Window info very soon. Cheers

OK, here is the output from the Xcode console from different scenarios. Let me if I should try any other scenario. I've deleted the last part of full URL, but it is correct (if anyone really wants to see that I can PM it). Cheers -------- Initial State. Before HTML Doc Updated. Cached HTML Doc Data Shown in App 2013-06-01 11:40:11.411 myapp[96197:c07]myapp BT_screen_htmlDoc: url to load:file:///Users/steveatwal/Library/Application%20Support/iPhone%20Simulator/6.1/Applications/114A1295-8E66-4853-85D4-775562FF7F64/myapp.app/ 2013-06-01 11:40:11.411 myapp[96197:c07] BT_screen_htmlDoc: url scheme: file 2013-06-01 11:40:11.412 myapp[96197:c07] BT_screen_htmlDoc: webViewDidStartLoad 2013-06-01 11:40:11.412 myapp[96197:c07] BT_screen_htmlDoc: showProgress 2013-06-01 11:40:11.412 myapp[96197:c07] BT_viewUtilities: getProgressView 2013-06-01 11:40:11.459 myapp[96197:c07] BT_screen_htmlDoc: webViewDidFinishLoad 2013-06-01 11:40:11.460 myapp[96197:c07] BT_screen_htmlDoc: hideProgress Start App in Simulator. Update HTML Doc. Stop & Start App in Simulator (Old Data Shown) BT_screen_htmlDoc: url to load:file:///Users/steveatwal/Library/Application%20Support/iPhone%20Simulator/6.1/Applications/19AB3A87-484E-42D6-82DF-6CB559878FA5/myapp.app/ 2013-06-01 12:20:54.888 myapp[96552:c07] BT_screen_htmlDoc: url scheme: file 2013-06-01 12:20:54.889 myapp[96552:c07] BT_screen_htmlDoc: webViewDidStartLoad 2013-06-01 12:20:54.889 myapp[96552:c07] BT_screen_htmlDoc: showProgress 2013-06-01 12:20:54.889 myapp[96552:c07] BT_viewUtilities: getProgressView 2013-06-01 12:20:54.967 myapp[96552:c07] BT_screen_htmlDoc: webViewDidFinishLoad 2013-06-01 12:20:54.968 myapp[96552:c07] BT_screen_htmlDoc: hideProgress 2013-06-01 12:20:55.216 myapp[96552:c07] BT_screen_htmlDoc: viewDidAppear in BT_viewController BASE CLASS Update HTML Doc. Delete & Start App in Simulator (New Data Shown) BT_downloader: downloadFile: http://apps... (I'VE BLANKED OUT THE URL BUT IT IS CORRECT) 2013-06-01 11:50:18.682 myapp[96288:c07] BT_screen_htmlDoc: downloadFileStarted: starting download... 2013-06-01 11:50:18.683 myapp[96288:c07] myapp_appDelegate: supportedInterfaceOrientationsForWindow 2013-06-01 11:50:18.683 myapp[96288:c07] SHOULD NOT ROTATE 2013-06-01 11:50:18.684 myapp[96288:c07] BT_screen_htmlDoc: canBecomeFirstResponder in BT_viewController BASE CLASS 2013-06-01 11:50:18.902 myapp[96288:c07] BT_screen_htmlDoc: downloadFileInProgress: 100% 2013-06-01 11:50:18.903 myapp[96288:c07] BT_fileManager: saveTextFileToCacheWithEncoding: B6360A0DB898AD51347A00B_screenData.html encodingFlag: -1 2013-06-01 11:50:18.904 myapp[96288:c07] BT_screen_htmlDoc: downloadFileCompleted: Success 2013-06-01 11:50:18.904 myapp[96288:c07] BT_screen_htmlDoc: hideProgress 2013-06-01 11:50:18.905 myapp[96288:c07] BT_fileManager: File does exist in cached directory: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:50:18.905 myapp[96288:c07] BT_screen_htmlDoc: Loading file from cache: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:50:18.906 myapp[96288:c07] BT_fileManager: readTextFileFromCacheWithEncoding: B6360A0DB898AD51347A00B_screenData.html encoding: -1 2013-06-01 11:50:18.918 myapp[96288:c07] BT_screen_htmlDoc: shouldStartLoadWithRequest 2013-06-01 11:50:18.918 myapp[96288:c07] BT_screen_htmlDoc: url to load:file:///Users/steveatwal/Library/Application%20Support/iPhone%20Simulator/6.1/Applications/19AB3A87-484E-42D6-82DF-6CB559878FA5/myapp.app/ 2013-06-01 11:50:18.918 myapp[96288:c07] BT_screen_htmlDoc: url scheme: file 2013-06-01 11:50:18.919 myapp[96288:c07] BT_screen_htmlDoc: webViewDidStartLoad 2013-06-01 11:50:18.919 myapp[96288:c07] BT_screen_htmlDoc: showProgress 2013-06-01 11:50:18.919 myapp[96288:c07] BT_viewUtilities: getProgressView 2013-06-01 11:50:18.977 myapp[96288:c07] BT_screen_htmlDoc: webViewDidFinishLoad 2013-06-01 11:50:18.977 myapp[96288:c07] BT_screen_htmlDoc: hideProgress 2013-06-01 11:50:19.050 myapp[96288:c07] BT_screen_htmlDoc: viewDidAppear in BT_viewController BASE CLASS Start App. View HTML Doc Screen. Update HTML Doc. Navigate to Different screen & Back to HTML Doc Screen in Simulator or Physical (Old Data Still Shown) 2013-06-01 11:53:41.096 myapp[96288:c07] BT_screen_htmlDoc: initLoad 2013-06-01 11:53:41.096 myapp[96288:c07] BT_strings: mergeBTVariablesInString (after merge): http://apps…(I'VE BLANKED OUT THE URL BUT IT IS CORRECT) 2013-06-01 11:53:41.097 myapp[96288:c07] BT_fileManager: File does not exist in Xcode bundle: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:53:41.097 myapp[96288:c07] BT_fileManager: File does exist in cached directory: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:53:41.098 myapp[96288:c07] BT_screen_htmlDoc: Loading file from cache: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:53:41.098 myapp[96288:c07] BT_fileManager: readTextFileFromCacheWithEncoding: B6360A0DB898AD51347A00B_screenData.html encoding: -1 2013-06-01 11:53:41.099 myapp[96288:c07] myapp_appDelegate: supportedInterfaceOrientationsForWindow 2013-06-01 11:53:41.099 myapp[96288:c07] SHOULD NOT ROTATE 2013-06-01 11:53:41.099 myapp[96288:c07] BT_screen_htmlDoc: canBecomeFirstResponder in BT_viewController BASE CLASS 2013-06-01 11:53:41.105 myapp[96288:c07] BT_screen_htmlDoc: shouldStartLoadWithRequest 2013-06-01 11:53:41.106 myapp[96288:c07] BT_screen_htmlDoc: url to load:file:///Users/steveatwal/Library/Application%20Support/iPhone%20Simulator/6.1/Applications/19AB3A87-484E-42D6-82DF-6CB559878FA5/myapp.app/ 2013-06-01 11:53:41.106 myapp[96288:c07] BT_screen_htmlDoc: url scheme: file 2013-06-01 11:53:41.107 myapp[96288:c07] BT_screen_htmlDoc: webViewDidStartLoad 2013-06-01 11:53:41.107 myapp[96288:c07] BT_screen_htmlDoc: showProgress 2013-06-01 11:53:41.107 myapp[96288:c07] BT_viewUtilities: getProgressView 2013-06-01 11:53:41.173 myapp[96288:c07] BT_screen_htmlDoc: webViewDidFinishLoad 2013-06-01 11:53:41.174 myapp[96288:c07] BT_screen_htmlDoc: hideProgress 2013-06-01 11:53:41.454 myapp[96288:c07] BT_screen_htmlDoc: viewDidAppear in BT_viewController BASE CLASS Start App. Update HTML Doc. Hit Refresh in Top Left of App in Simulator (New Data Shown in Simulator But Does Not work on Physical Device) 2013-06-01 11:55:56.002 myapp[96288:c07] BT_screen_htmlDoc: initLoad 2013-06-01 11:55:56.003 myapp[96288:c07] BT_strings: mergeBTVariablesInString (after merge): http://apps…(I'VE BLANKED OUT THE URL BUT IT IS CORRECT) 2013-06-01 11:55:56.003 myapp[96288:c07] BT_fileManager: File does not exist in Xcode bundle: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:55:56.003 myapp[96288:c07] BT_fileManager: File does not exist in cached directory: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:55:56.004 myapp[96288:c07] BT_screen_htmlDoc: Downloading and caching file from URL:http://apps… (I'VE BLANKED OUT THE URL BUT IT IS CORRECT) 2013-06-01 11:55:56.004 myapp[96288:c07] BT_screen_htmlDoc: showProgress 2013-06-01 11:55:56.005 myapp[96288:c07] BT_viewUtilities: getProgressView 2013-06-01 11:55:56.005 myapp[96288:c07] BT_downloader: INIT 2013-06-01 11:55:56.006 myapp[96288:c07] BT_downloader: downloadFile: http://apps… (I'VE BLANKED OUT THE URL BUT IT IS CORRECT) 2013-06-01 11:55:56.006 myapp[96288:c07] BT_screen_htmlDoc: downloadFileStarted: starting download... 2013-06-01 11:55:56.007 myapp[96288:c07] myapp_appDelegate: supportedInterfaceOrientationsForWindow 2013-06-01 11:55:56.013 myapp[96288:c07] SHOULD NOT ROTATE 2013-06-01 11:55:56.013 myapp[96288:c07] BT_screen_htmlDoc: canBecomeFirstResponder in BT_viewController BASE CLASS 2013-06-01 11:55:56.167 myapp[96288:c07] BT_fileManager: saveTextFileToCacheWithEncoding: B6360A0DB898AD51347A00B_screenData.html encodingFlag: -1 2013-06-01 11:55:56.174 myapp[96288:c07] BT_screen_htmlDoc: downloadFileCompleted: Success 2013-06-01 11:55:56.174 myapp[96288:c07] BT_screen_htmlDoc: hideProgress 2013-06-01 11:55:56.175 myapp[96288:c07] BT_fileManager: File does exist in cached directory: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:55:56.176 myapp[96288:c07] BT_screen_htmlDoc: Loading file from cache: B6360A0DB898AD51347A00B_screenData.html 2013-06-01 11:55:56.176 myapp[96288:c07] BT_fileManager: readTextFileFromCacheWithEncoding: B6360A0DB898AD51347A00B_screenData.html encoding: -1 2013-06-01 11:55:56.238 myapp[96288:c07] BT_screen_htmlDoc: shouldStartLoadWithRequest 2013-06-01 11:55:56.239 myapp[96288:c07] BT_screen_htmlDoc: url to load:file:///Users/steveatwal/Library/Application%20Support/iPhone%20Simulator/6.1/Applications/19AB3A87-484E-42D6-82DF-6CB559878FA5/myapp.app/ 2013-06-01 11:55:56.239 myapp[96288:c07] BT_screen_htmlDoc: url scheme: file 2013-06-01 11:55:56.240 myapp[96288:c07] BT_screen_htmlDoc: webViewDidStartLoad 2013-06-01 11:55:56.240 myapp[96288:c07] BT_screen_htmlDoc: showProgress 2013-06-01 11:55:56.240 myapp[96288:c07] BT_viewUtilities: getProgressView 2013-06-01 11:55:56.263 myapp[96288:c07] BT_screen_htmlDoc: webViewDidFinishLoad 2013-06-01 11:55:56.263 myapp[96288:c07] BT_screen_htmlDoc: hideProgress 2013-06-01 11:55:56.369 myapp[96288:c07] BT_screen_htmlDoc: viewDidAppear in BT_viewController BASE CLASS

I'm going to take a stab at something... May help. If I'm following you correctly, you are using a HTML Doc screen, but using a URL, not a file included in the compiled app, correct? If that's the case (and this is why I may not have fully understood the problem before), then I think you may have 2 options to fix the "bug". 1. Use a new HTML doc with a new file name each time you revise it. And of course change the file name in the control panel to match. This will force the user's device to fetch something new without pressing a refresh button. Reason: I don't think the plugin has any way to verify the "versioning" of the html doc. It might simply check to see if there is a file in the cache with the same name that it's looking for. If this is the case, then it will always find the cached version. 2. Use an actual Custom URL plugin and actual hosted content, rather than a HTML doc. This way it will always fetch the most recent content. In my opinion, the only reason to use a HTML doc plugin is when you have HTML documents that you wish to include in the compiled app, therefore never requiring internet connection or hosting for the file. (i.e. Including static, "offline" html-formatted content). If you're going to use a URL for a html doc, then just go ahead and host the html doc. No one points a browser to a html doc as a static file. They point a browser to a living web page/web site. I hope this makes sense, and helps in some way. -Chris

Stobe - I think you're right on here. In the debug data is this line: 2013-06-01 11:55:56.176 bctech[96288:c07] BT_fileManager: readTextFileFromCacheWithEncoding: B6360A0DB898AD51347A00B_screenData.html encoding: -1 That says to me "there's already a HTML doc in the cache, so use that one". If you're really using an online doc, the custom URL is the way to go. (Or, you could use my HTML Pro plugin and give yourself the option of linking to other screens in your app ... sorry, shameless plug!)

@Stobe. I totally understand what you are saying, but here's the thing. Firstly, let's look at the description for the HTML Doc plugin...I've capitalized the parts that are relevant to what I'm discussing in this forum thread: "This displays an HTML document that is either compiled in the Xcode or Android project or loaded from a URL. If the document is loaded from a URL the device will cache it for offline use. IF THE DOCUMENT IS COMPILED IN THE APP (AND NOT LOADED FROM A URL) IT WILL DISPLAY FASTER BUT YOU WILL NOT BE ABLE TO CHANGE THE DOCUMENT WITHOUT RE-COMPILING THE APP. Deciding which approach is best is sometimes difficult. IT'S USUALLY BEST TO LOAD A DOCUMENT FROM A URL SO THE APPLICATION IS LIGHTER, MORE FLEXIBLE, AND UPDATEABLE..." The emphasis here is the last word above "updateable". Now, maybe I'm misinterpreting the description of the plugin, but (having worked in IT for a long time, and done the whole gamut of user requirements gathering, non-iOS programming, lots of QA & testing, and repeating the whole process), it does seem to me that the point of having the doc load from a URL is so that the developer can UPDATE it later without having to recompile the app. Now, let's take a look at the Custom URL plugin description…again, I've capitalized the relevant part: "Loads a URL into a custom web-view. Useful for displaying online content. CONTENT IS NOT AVAILABLE OFFLINE, IT'S DESIGNED TO REFRESH WHEN THE SCREEN LOADS." So, there is NO offline caching with this plugin. To point out what I am trying to do, and I am hoping that I have not misunderstood the description of the HTML Doc plugin, is: "I would like to have the HTML doc cached onto the local device for offline use (because even in this day and age, not everyone is always online, and also to speed up access to the content) the first time it is accessed. But, I would like the ability to have new content downloaded and cached onto the device when the HTML doc is updated." So, now let's look at some of the suggestions. And, please please understand I'm being very objective here and trying to address what I consider something that would help not only me but also others (from some of the feedback it seems I'm not the only one). Whether we call it a "bug" or a "feature inconsistency" or my misinterpretation of the HTML Doc plugin description. Maybe someone can come up with a better term for it :-) And I really appreciate any suggestions put forth here for discussion. "Use a new HTML doc with a new file name each time you revise it. And of course change the file name in the control panel to match. This will force the user's device to fetch something new without pressing a refresh button. Reason: I don't think the plugin has any way to verify the "versioning" of the html doc. It might simply check to see if there is a file in the cache with the same name that it's looking for. If this is the case, then it will always find the cached version." Yes, this will probably work. But, and there are 2 Big Buts here (LOL): first, I think the user WILL get a refresh alert since the URL has changed (and the JSON/settings change needs to be pushed out to the app - maybe I'm wrong on this as I'm not totally up to speed on JSON); second, is this the way that the HTML Doc is supposed to be used? It just seems convoluted to me :-) And, from my understanding of what I've read so far, developers should not be messing too much with the control panel settings after the app is released. If you're right about the HTML Doc not being able to check the "versioning" of the HTML Doc, why even have the ability to load an HTML Doc from a URL? If you add a HTML Doc plugin to a new test app, take a look at the settings for the plugin…you will see right at the top it says "If you don't need to change the document after the app has been compiled, use a File Name and add it to the project. If you do need to change it, use a URL so you can update or replace the document after the app has been compiled and released." Hmmm….is it just me, or does that sound like you should be able to UPDATE the HTML Doc later? LOL. I'm just asking questions here, trying to understand how this is all supposed to work. Maybe I'm misinterpreting things. But, the key thing is: if the functionality I'm looking for is not there, perhaps update the description to indicate that, and it would save me (and anyone else scratching their heads) from trying to put a square peg into a round hole :-) Buzztouch is an awesome product, and I can't emphasize that enough, but as I've said in other posts, (other than the great community) the plugins are what makes your app Buzz :-) And we need to be very clear about functionality: either it's there or it's not. "Use an actual Custom URL plugin and actual hosted content, rather than a HTML doc. This way it will always fetch the most recent content." Yes, I know this, but as I mentioned above, this does not give the ability to cache the content offline, so the user MUST be online to use the screens that use this plugin. Not what I was hoping for, and hence my reason for using the HTML Doc plugin. "In my opinion, the only reason to use a HTML doc plugin is when you have HTML documents that you wish to include in the compiled app, therefore never requiring internet connection or hosting for the file. (i.e. Including static, "offline" html-formatted content). If you're going to use a URL for a html doc, then just go ahead and host the html doc. No one points a browser to a html doc as a static file. They point a browser to a living web page/web site." LOL. So, why have the functionality to use a URL for an HTML doc in the HTML Doc plugin (other than to organize your content in one central location)? The plugin is a browser, and there is lots of static useful content online (which you might want to update infrequently, e.g. updates to an eBook). Just playing devil's advocate here :-) And yes, I have tried the Word Doc and PDF Doc plugins, but I want a Web browser so that when I have static content (which I might update sometimes with new information), I want people to be able to click on links and browse those. @chris1. LOL. Plug away. If, after reading all of the above, you think your plugin is able to do what I'm hoping to do, I'd be more than happy to use it. Heck, I was thinking of getting it anyways to help support the great developers on here! So, I really appreciate all the helpful feedback as it keeps the conversation going until we find a resolution (whatever that might be). Maybe I am barking up the wrong tree, or trying to fit a square peg in a round hole, or <insert your favourite analogy here>, but if someone can tell me definitively if I can or cannot do what I'm trying to do, and best way, that would be awesome! I'm so close to finishing this app, I can see the finish line…just need a little push for the last few yards :-) Steve

First of all, apologies guys, my earlier contribution was talking about the custom html /text plugin, I misread the first post. BUT, I think I understand now and I am beginning to think this is not a bug, it is a feature. This is my understanding based on how I use the html doc plugin. There are two specific control panel settings that affect this scenario :- 1) Setting to force refresh (or not) and 2) Whether the file is local (ie in your project xcode build) or external. If you always want the html page to be available, regardless of the internet status or if this page has been retreived before or not, it has to go into your xcode build. But then you cannot update it without a rebuild (could this explain why it works in simulator?). If you host the html page externally and set the force refresh to be off, the page can be available offline after it has been retreived once. This allows you to do updates to the html content, but it does not trigger a refresh, as I believe the app does not know the html has been changed. You can trigger a refresh for the whole app by using the manual refresh button on the home page or by changing anything for any plugin in the CP. My theory is that Buzztouch doesn't know that you have made updates to this external page, as you did not modify it through the control panel. The BT refresh trigger is only controlled by updates in the json config.txt - this is the key. Alan

Steve - the current caching mechanism is on filename. If I understand you correctly, you want it to be based on content. That's not hard to do, but does require dowoading the HTML doc anew every time the user accesses the screen (if online). That can be done in the background of course, but the caching feature of the plugin is designed to reduce web calls. Note that HTML caching on your desktop browser doesn't work this way either though.

Steve, This is a great conversation so far. Hopefully many people can learn from this discussion for years to come. (My only concern is how so many of your thread topic names contain the word "bug" or "broken", lol). There is some great discussion in this thread about user experience and general good practice. Thank you for explaining your concerns with my above suggestions. I more fully understand your choice of using the HTML Doc plugin in your scenario now. After looking at the source code for the plugin, it looks like you were on the right track for using the forceRefresh option in the control panel. If this option is selected, the plugin will delete all cache for the screen before it goes through it's normal logic of looking for and downloading the content (doc, in this case). I know you said you tried that in your first post, but I didn't see the usage in your debugger output. Maybe it was tried, but at the time there was something else messing up the result? Perhaps try it again after a gool ol' clean and run. But to further explore the different options for displaying HTML content (for the sake of others reading). I'll address a few more things.... First, I understand why you don't want (expect) the user of your app to Tap a refresh button. I agree, that should never be a requirement. But do you also want to hide the refresh dialog which gets displayed if there is a change in the control panel? If so, I would search the forums for any of the numerous threads to hide that dialog. (to address your concern of updating the filename of a remote HTML doc). Search for force refresh app, etc. It's worth noting that although Buzztouch give it's users (us) some capabilities to make our apps dynamic, and change some stuff around through an online control panel, that may not always go along with the intentions of Apple. We (Buzztouch) have always said that our intentions are not to avoid or circumvent the Apple update (resubmission) process. On the contrary. We embrace that very process, and have listed several times the benefits (to the developer and the end-user) for going through that process. (Look up a video by David called "Change is Good".) That being said, some generalizations of what content should be better suited for dynamic changes can be made. I would say (and this is just my opinion - but don't overlook the experience behind the opinion, lol) that some of the plugins that use JSON to update the overall content/information displayed by that screen would be better suited than a screen/plugin that contains more "static" content. example: A Map screen vs a PDF screen. The Map plugin uses the JSON information (whether contained in the control panel or hosted elsewhere) to display a bunch of locations. If I were displaying for example the locations of this years ComicCONs, I could add, subtract, edit the locations at any time, and the screen uses the most recent contents of that JSON to create the map. as opposed to a PDF doc, Word Doc (HTML Doc), etc. I can use the control panel to point to a new/different document. But editing an existing document is probably better suited to doing an app update. To go back to your project. Here are a few more options to explore... 1. Try the force refresh again, and see if that works the way the code says it should. 2. Depending on how often the document will change, you could use my original option of changing the file name (forcing the app to download something new) and simply hide the refresh dialog. 3. You also have the option of using the "Custom HTML/Text" plugin to copy/paste the contents of your HTML doc into. This plugin will display HTML AND it will cache it for offline use. Since it "Lives" in the control panel, it is easy to update, but this again will trigger the "Would you like to update.." dialog. (which can be hidden). 4. Again, depending on how often you're going to make changes to the document... You could build the app with a page containing a HTML doc which is included in the build. Then if you have to make changes, you can make a new page using a hosted HTML doc, and simply re-point the menu choice in your app to the new page. This will again force the app to grab the new content, but will again require the normal app update dialog. Let us know how it goes, and what you decide on using. We're all excited to see your first app. -Chris

Hi guys. Had to deal with my daughter's grade 12 graduation yesterday, so now back... @chris1. Thanks for checking the code. @Stobe. Thanks for all your great suggestions! I will definitely look at how to resolve this issue for myself. This is the only thing right now stopping me from submitting the app to iTunesConnects :-) Regarding your comment "My only concern is how so many of your thread topic names contain the word "bug" or "broken", lol", I decided to search for all posts I initiated in the forums and this is what I found - I wanted to check for myself to make sure I'm not offending anyone by using the word "bug" too much...there might be some sensitive programmers/developers here :-) LOL - so far, up to this post, I've posted 30 new forum messages - out of the 30 posts, the following 6 are related to a "bug" or an issue. You can search for these message topics in the forums (I've listed the title of the topic, followed by my explanation). You can also search for my name here "BuzzingSteve" to look at all forum topics I've initiated as I think some of them might be useful to others. Heck follow me in your account settings so you get an alert every time I post something :-) LOL --------------------------- Rotation on iPad Causes Menu with Image to Freeze - I indicated this MAY be a bug, and got no resolution. I ended up re-downloading the app source with only the plugins I was using, and that seemed to clear things up. So, maybe it was a conflict between plugins. I still don't know. But the new features of selecting only the plugins you are using in your app (to avoid any possible conflicts between plugins) is awesome. I think others, including myself had suggested this in the past, and it's great that Buzztouch implemented this. Awesome! Remove Background Text in Weather App - fix was supplied by our coding guru @MGoBlue to remove default weather info for Sacramento when opening a screen using the Weather app. This was NOT noted as a bug but I think it will help everyone to make their screens more professional to show only the weather that was requested via the control panel. Bug in RD Simple RSS Plugin - this was acknowledged by others as a bug and a fix was put in place. Thanks to our coding guru @chris1 Just added Scringo, Gringos - pointed out a bug in Scringo, contacted Scringo who finally acknowledged it and said they will work on a fix for it...others using Scringo also acknowledged this as a bug. Home Screen Bug - home screen set to next available screen in config if you delete existing home screen. Acknowledge this is the way it is supposed to work, and not a bug. So, apologies for using the word "bug" if that offended anyone. Menu with Image Plugin Bug Fix - posted a software solution for a bug. Thanks to our coding guru @Kittsy --------------------------- So, not sure if anyone can suggest anything, but if there is an aversion to using the word "bug" I'll try to limit my useage of it. But, as you can see from this list, it's hard to know what else to call most of them :-) As a few developers have said, let's find these "bu..."...uh....I mean, "issues", and crush them, so that Buzztouch is even more awesome than it already is! :-) Cheers and thanks again for all the great suggestions! The community here is #1 :-) Steve