Hi, I've been struggling with exactly how BT_config.txt works, especially with the various ways you can change the configuration URL. So, being a visual kinda guy, I drew up this image. If the powers at Buzztouch could check it out and verify assumptions, it would help me tremendously! http://dl.dropbox.com/u/4993711/BT_Config_Explanation.png Thanks! Mark

Hiya Mark, You basically got it! So as an overview: -When apps load they always check for a cached version of the BT_Config file on the phone itself first. This cached version would (if it exists) be an updated config file downloaded after the app has been refreshed. If one is there, it is loaded. If not, the app loads the original config file that was included when the app was submitted to the market. -In either above case, if the Report to Cloud URL exists, within whatever config file is loaded, the app will check that URL to determine if there is a newer version of the Config file available. If not, the app just runs its current config file. If there is a new version, the app goes to the Configuration Data URL and downloads/saves the new Config file into cache, and then runs it. The app loads; repeat the step above this one. The two steps above are the same for either leaving the Configuration Data URL and Report to cloud URL at default settings, or changing those settings to your own URLs. However, if you change the URL settings, you then have to manually update the actual files located at those URLs. Check the Documentation as it gives formatting examples for both the Report to Cloud URL and the BT_Config file located at the Configuration Data URL. Removing the Configuration Data URL and Report to Cloud URL will take your app 'offline' as far as updates to the config file are concerned. In that case, if you want to update the config file, you will need to resubmit an update to your market of choice. It is important to note that your app can still access files from a URL - a menu can pull its list item data from a .php file on a dropbox account, for example. For you app to be truly 'offline', all of its content will have to be embedded. You'l have to weigh the pros/cons of doing this, as all changes/removal/additions of embedded content will require an app resubmission to the app store/ android market.

Ninja's - both of you - I think I'll retire ;-)

Hi @Parker, This makes loads of sense now! Thanks for the description you provided...I didn't know about the cached version of the BT_config file, and, knowing that now, everything makes much more sense now. I'll adjust my infographic with this new information and republish. One final point of clarification - the Report to Cloud URL doesn't provide any actual configuration data, just reports usage data to the designated location...is this correct? So, I could take my app offline by removing the Configuration Data URL, but still have usage data sent out if I leave the Report to Cloud URL. Is that right? @David - no retiring yet! Still lots to learn, and you've got a list of features to implement first! ;-) Thanks! Mark