Okay, I've moved my app into the next stage of development - putting it on my device. But, I've noticed something problematic. When I first install the app on the device, it loads the config.txt file that is included in the app build file, and doesn't fetch the one on the cloud server. Even if I close the app and restart it, it doesn't refresh because it thinks it has the most up to date version. The only way to force a refresh and download the most recent config.txt data is to change something (via control panel, etc) to force a change to the "report to cloud url" file. That could become a big problem. Here's why: Let's say I have made several significant changes to the app since my initial build. Anyone who downloads the app from the app store would be getting an outdated version of the app, and would have no way to update to the latest version unless I push through another update, which might be a while if I'm satisfied with my product. Am I doing something wrong? Has anyone else come across this issue?

I also noticed this. I am using Buzz 2.0 apps and Using Tabbed layout. I only get one tab. But If i change it to Menu Layout it works fine. It also did not have the refresh option available. I tried copying the current BT_config from the site to the my build but no luck.

This topic has been discussed for many times. There is no actual solution for this but you can either have a splash screen with instructions asking users to refresh the app in order to get the latest contents. Another way is to add a note in about section of your app. Similarly in your app page of the store or play store you can give a note asking the users to refresh the app after they download it.

But how do they refresh the app?

Right. there is no option to refresh the app for this error. Thanks Sandeep

In case of ios there is a refresh button on the home screen and in case of android the users will have to press menu button and select refresh the app button.

So I have to have a navbar to show a refresh button? That will really make the app look ugly.

Yes the navbar in ios has a refresh button on left side. I dont think that it looks ugly, in fact it is necessary that you display it if you want your users should be able to refresh the contents of your app. You can change the color of the nav bar to make it look good though.

Having a navbar at all takes away from the design of my app. I hope BuzzTouch is working on a solution to this - it seems like a very big bug/problem indeed.

Well for the time being its the only option.

Actually, you don't need a navbar in Android to do the refreshes. As Sandeep pointed out, you can use the hardware/software Menu button to do the refresh for the app or screen. iOS is a bit different in that there is a refresh button in the top nav bar, but the ability to refresh does exist in Android without that in-app button. I guess you could throw up a splash screen, like I've seen other apps do, that give a hint on how to refresh the app. Or, set the screen to Force Refresh if that's an option? Mark

Okay - I haven't gotten to Android testing yet, but here's what I came up with for iOS: In my initial BT_config.txt file, I have a navbar included with a refresh button. The navbar text is set to "Please Refresh". When the user clicks the refresh button, it will download the latest config.txt from the server, which removes the navbar for good for that user. So, the next question is how does the 'refresh' button work? Is it possible to force this kind of refresh automatically via a screen? That way I could build the app with a single screen that contains the auto-refresh code, and upon initial launch and auto-refresh, the app would download the updated config.txt file. If that's not possible right now, it would make for a good plugin to work around this issue.

Okay - I theoretically have a cross-platform solution that doesn't require a refresh button. I still need to test it out, but here's the idea: There will be 2 Report to Cloud URL's. The first one contains the current date stamp (as in today), and is the URL that is displayed in the config.txt that comes with the app. The second contains the date stamp of the latest 'save'. The server-side config.txt will point to the second URL. When the app is loaded initially, it will grab the date from the first URL, which will be the current date. The next time the app is loaded, it will grab the date again, which will be a little greater (by the amount of time that has passed since the app was previously loaded). This will trigger a refresh, which will pull in the server-side config.txt and update the cloud reporting url with the second one, which provides a new date only when changes have been made. Obviously this requires hosting a small php file on a webserver to output the current date. The second url can still be the buzztouch cloud reporting url. Users will still have to wait until the second time they open the app to get the updates, but it's better than the alternatives in my opinion.

Here is sample php code for the first file. I'll let you know my results when I have time to test. <?php $today = date("D, j M Y H:i:s O"); $updateString = '{"lastModifiedUTC":"' . $today . '"}'; echo $updateString; ?>

Okay I just did an initial test on iOS using the above setting and it worked just as expected.

Hi @chris1, Are you hosting the config file at a different place than bt.com (or your self-hosted server)? Like DropBox or something? Mark

Mark, I'm hosting the config.txt file on my website for a few different reasons. However, I don't think it matters for my solution above. The config.txt file could be hosted on BT, as long as the "first" cloud url is hosted on a site that supports php. (The second cloud url can be the BT-hosted one). Here's what would need to happen for someone using BT for pretty much everything: 1) Write your app in BuzzTouch as much as possible, or completely if applicable. 2) Download your source code into XCode and Eclipse. 3) Open the BT_config.txt file in XCode and Eclipse (I know this works for XCode, I'll get to Eclipse soon). In Xcode, this can be found in the BT_Config folder in the Project Navigator. 4) Find the place where the property "reportToCloudURL" is defined in the BT_config.txt file (should be near the top). 5) Change the url link to the self-hosted one. 6) Build the app and distribute as normal. It should be that easy. When the user installs the app, it will use the self-hosted cloud url php file. This will return the current date stamp. The next time the user opens the app, it will do the same. Since the date stamp has updated, it will force a refresh. Now, you haven't done anything with the dataURL property where the config.txt is stored (either on BT or not). So, when the app refreshes, it will pull config data from the dataURL, which will contain the regular cloud url. Then everything will behave as normal. Does that make sense?

Hi Chris, I've read through this thread a bit more closely, and I have some thoughts and observations that may or may not be helpful! * A best practice here is to sync your current configuration file from your control panel with the one you're going to build the "final" version of your app with prior to submitting it to the store. That way the reviewers have the most up-to-date copy of the app. And, and this is important, if you haven't made ANY changes in your control panel for that app after you synced things, then when the reviewer opens up the app, they won't be prompted for a refresh because the last updated dates will be the same. That's an important point to give a great first impression to the reviewer. However, if you've made a single save in the control panel, the dates will be out of sync, and a refresh will be prompted. * If a user downloads your app and opens it for the first time, and if there have been any changes at all in the control panel, they will be prompted for a refresh. If they open if for the first time and the dates are the same, they won't be prompted for an update. If you have a URL in the reportToCloud field, each time the user either opens the app, or brings it to the foreground, the app will check the dates, and if there is a difference, a refresh will be prompted. * To summarize the above two points, and to sorta address your original post, if a user downloads the app, and there are URLs in the reportToCloud and dataURL fields, and there is a difference in the dates, the user will be prompted for a refresh. * If you don't have a value in the dataURL field, there will be no Refresh button in the navigation bar. That's the field that toggles it on or off. * If you publish an app without a dataURL specified, the only way you can provide an update to the app is by publishing an update to the store. Such an app would be considered offline from a configuration file perspective. * The method you are proposing above makes sense to me! Mark

Mark, Thanks for the thoughts. I have a question about your second point. You say "If a user downloads your app and opens it for the first time, and if there have been any changes at all in the control panel, they will be prompted for a refresh." I don't think that's correct, and it's the reason why I came up with my workaround using 2 dataURL's. If a user downloads the app and opens it for the first time, they won't be prompted for a refresh, no matter how many changes have been made since the app was sent to the app store. The only way they will get a refresh message is if there's another change made to the app after they download it and run it. The reason for this is that when the app is first run, it goes to the dataURL and gets the current date stamp. It doesn't see if a refresh is needed; it just assumes it already has the latest copy. Every time thereafter, it will check the dataURL and find the same date stamp, unless a new change is issued. At least, that's how I understand the process after looking through the related threads on this issue. It still presents a problem with the app review process, though. If seeing an app refresh message creates the possibility that the reviewer will fail the project, then my method breaks down. But on the same note, having a refresh button on a navbar could cause the reviewer to have the same reaction. Since I'm running things from my website, I can think of a way to get around this, but it's not very extendable to the majority of Buzztouch users. I could use the same method I described above, with 2 dataURL's. But instead of the first one issuing the current date stamp, it would issue a static datestamp. Then, once the app gets past the reviewer, the php file issuing the date stamp changes to show the current date stamp. That way, the reviewer doesn't see a refresh, but users will when they open the app. It feels kind of dirty, but perhaps it's as much an issue of the Apple reviewers needing to be educated about Buzztouch than anything else.

Hi Chris, Well, my understanding of how things work led to my second bullet, but it's possible I'm wrong! The whole thing can be a bit confusing, so I'm going to bring this thread to the attention of @David and have him weigh in. Since he designed the system, he'd be the definitive answer for sure! I don't think having a refresh button on the nav bar causes any problem at all. Many of the apps I use on a daily basis have refresh buttons, or the ability to pull down the screen and cause a refresh. I think such a button is actually a plus, because it indicates dynamic content that the user is capable of forcing a refresh of. That's got to be a good thing in my book! Mark

100% agree that this is confusing! LOL. It's for sure something we're balancing all the time - the best approach for this is hard to know without knowing more about each individual app's design, goal, etc. Most of the design decisions we make are focussed on the most "common" situations. The biggest downside of the current setup is the fact that the config.txt file compiled in the app should match the config.txt file in the control panel while the app is being reviewed. @GoNorthwest explains this well. However, as we all know, this also means that end users that download the app for the first time will have a "stale" version until they refresh. This is not usually a problem but in cases where there are significant changes in the control panel, after publishing, the newest app users will not get these changes right away. As far as the nav bar on the home screen. Yes, if it's missing / hidden there will be NO refresh button on the home screen. This means that if you want to have a refresh button in the app, your home screen (tab 1 in the case of tabbed apps) will need to somehow add a refresh routine. This could be a custom button on the home screen, a programmatically created solution (custom code to force refresh) or some other idea. Regarding the "force refresh" when the app is first installed: I think the best way to handle this is (in the core code)... a) App launches and checks for an internet connection. b) If an internet connection is available, it downloads latest data WIHOUT prompting user to refresh. Behind the scenes kinda thing. If an internet connection is NOT available, it uses the config.txt file in the compiled project. Comments are welcome about this idea. We are also planning a new setting in the Core Settings (a new property in the config.txt file) that allows apps owners to decide if users are prompted or not when app data has changed. YES would behave like it does now. NO would download the latest config data without prompting...behind the scenes. Both cases are appropriate - depending on the app's audience / goal / objectives.

Well, I would have bet money that a user was prompted for an refresh when they launched the app for the first time! That's always been my experience when installing an app for the first time in the simulator. Weird. I think the change to the core settings you are proposing would be awesome and very well received! Mark

Looking forward to see a solution for this problem! My homepage has changed since I submited my app to Apple Store (and it will keep changing) so everytime a new user download it he/she not only gets an out-of-date information but also gets a homepage screen that doesn't work. This is a really bad user experience and clicking the Refresh button to load the new data is not something that many users do. I guess I will have to add this "tip" in the description of Apple Store. BTW, you can check my app at http://bit.ly/TnzriO. Hope you like it.

"Regarding the "force refresh" when the app is first installed: I think the best way to handle this is (in the core code)... a) App launches and checks for an internet connection. b) If an internet connection is available, it downloads latest data WIHOUT prompting user to refresh. Behind the scenes kinda thing. If an internet connection is NOT available, it uses the config.txt file in the compiled project. " @David, Wouldn't this approach require a new download every time the app is launched, even if it is not needed? "We are also planning a new setting in the Core Settings..." Did you get around to making the enhancement to Core Settings like you mentioned?

@jasonr - this thread takes me back! Can't believe how far I've come in the last 5 months. :) The changes David was referring to was the design/live mode that is now implemented in all projects. For my apps that need to have a way of making sure the first installs are the most up-to-date, I add in a navbar on the homescreen that says "please refresh". This is added in only on the local config.txt file, not on the online one connected to a control panel. That way, when the user first installs the app, they will see the message until they click the refresh button. From that time forward, they will be on the most recent version available.