** For a more recent an updated version of this tutorial go to www.MySkylla.com just search Config and it'll pop up or click on the Documentation section. Due to limitations inherent with the Forum (no HTML or images) I'll no longer update this post. * * This tutorial provides the "best" method for the use of the Config file in a Buzztouch app. This method allows you to easily update apps without wrecking the users experience. The Problem: The basic problem is that if the app is online when you make changes in the Control Panel the users will experience the changes whether you want them to or not. Imagine if you're the app user and everytime the developer makes a change your app updates and loses its functionally because all the changes haven't been finished. Some users will update their app rating to buggy, with perhaps a one or two star rating and maybe a refund request. Now imagine if the developer is doing a massive reworking of the app. Well I can imagine a very unhappy app user. Why Online won't work? You could publish the app as an "Online" app and when you wish to make a massive update take the app "Offline". But as Mark, aka "GoNorthWest" pointed out in a previous post not all app users will update their apps simultaneously. Therefore some users will be online, some offline even after you've taken the app offline. When you start making the massive changes you'll hear from the users that are still online. Some Will send nice email inquires and you can explain what the problem is and ask for their patience & understanding. Others will rate your app accordingly. Why won't Offline work? You could publish the app as an "Offline" app but fixing even a minor error requires you to publish a new binary. Making a quick change in the Control Panel is much simpler and quicker than publishing a new binary and then uploading the binary to the appropriate app store. (For iOS it requires another app review & corresponding delay.) So, what's the solution? Solution: Use a "Secondary Online Config file" (SOCF). By using a SOCF you can: a. Make minor fixes and changes using the Control Panel, b. Easily and effectively take the app Offline, c. Avoid the multiple stages of app users issue. 1. Publish app with BT_config.txt pointing to a Secondary Online Config file. Modify the BT_config.txt to point to the SOCF. Copy modified BT_config.txt file data to the SOCF. 2. Place SOCF on: a. Dropbox (if it's not there already), or b. A website (Your website), c. In the Control Panel using the File Manager (for help understanding the File Manager go to Documentation section of www.MySkylla.com). 3. When you plan to make MAJOR changes to the App, take the app "Offline" by removing the reportToCloud URL from the Secondary Online Config file. (Not the Control Panel.) Make any change to the app in the Control Panel. This will take the app "Offline" when the user updates. To take app offline: Delete the URL leaving, two quotes and a comma. "reportToCloudURL":"", 4. The user will receive one notice that the "data has changed" which will take them offline. (They actually will be using the Cache copy of the Config file. If they clear the app's cache the app will use the Config file embedded in the app. When they update the app will grab the 3rd party Config file in go offline. So, technically the app is still "online", it just won't receive any notice to update.) 5. Now the App is "Offline". 6. Put the reportToCloud URL back into the BT_Config.txt file in your project source code. Now compile your app. A. For iOS: Sign this app with the Development certificate not the Distribution certificate. Your development app is now online. This will allow you to see any changes in the control panel since the development app is now online. The published app remains offline pointing to the Secondary Online Config file. They will not see any modifications made in the Control Panel. B. For Android: create a new .apk. Upload the app to your device. You now have a online app that will display modifications to the app made in the Control Panel. When you're finished with modifications (i) update the BT_Config.txt file in the source code. Copy and paste the source from the control panel. (ii) point the Config file to the Secondary Online Config file. (iii) place copy of the updated Config file pointing to SOCF site on the secondary site. (iv) For iOS publish a new binary to iTunes using (the distribution profile), and / or (v) For Android publish app to Google Play (or appropriate market) (iv) This will take user back online with the Config file pointing to the Secondary Online Config file. Repeat as necessary. Essentially this creates two apps: a. The published app users find on the market it's either online or offline at any given point in time, but points to Secondary Online Config file, and b. The development app (it's online and points to Control Panel's Online Config file.) You could use separate source code files, but it's not necessary. Wouldn't recommend it since it adds another level of complexity (you must remember to make each an every change in both sets of source code files). But having a separate source code file to play with does allow you greater leeway to experiment without worrying that you'll make a fatal mistake. Xcode has a backup feature, use it wisely. Dropbox also has a backup feature use it wisely. For more info in the Config file go to www.MySkylla.com and click on documentation. Fred Footnote: In a previous version I used "third party online Config file" instead of Secondary Online Config File. The reason for the change of wording is that if your using the File Manager to host the SCOF it's not a "third party". Hence your SOCF can be either on a "third party" site or the Control Panel.

fred can you please take a look at this? i don't know who else to ask: http://www.buzztouch.com/forum/thread.php?tid=05CA985961903A44FBF2316&fid=BC70C36A743CD4FAD95D17F&sortColumn=FT.id&sortUpDown=DESC&currentPage=1

Good tutorial Fred

What about coping the config file from one app (iPad) to create another one (iPhone)....then linking that duplicate app to a new Control Panel using a new buzztouchAppId and the buzztouchAPIKey. How do you do this one? Thanks

The control panel would need the items in it's database. If you accomplish that you don't need second control panel.

How do I do that?

Hey Fred, so this only works if one had first published the app on the App Store with the config file pointing somewhere else? How would you sugest I make test if the app was published with the config file pointing to BT CP? Being the main objective to be able to use the CP to make the changes, and not a second CP, since that would, as you mentioned, make me remember every little change I make, and replicate it. Cheers.

If the app is published pointing to the Buzztouch online Config file, the solution is to publish a update pointing to the Dropbox online Config file or taking the app offline. If the app is not offline & points to Buzztouch, every time you hit save, users will be notified that an update is available and the changes will be reflected. If the app points to the Dropbox online Config file but is online then the users are notified that an update is available but after the refresh nothing will be changed in the app. Once the Config file packaged into the app BT_Config.txt points to Dropbox you have control of the user experience: Online and be notified of changes to control panel Or Offline and will not be notified of changes. Pointing to the Dropbox online Config file gives you control of when the modifications are implemented in the app when the user updated the apps data. Until you post the new Config file to Dropbox no changes will occur. So, solution is to take app offline now if you're going to make changes. Or publish a new binary now pointing to Dropbox to prepare for when you wish to modify it test modifications in the control panel. Fred

This is all great but I wish there was a way to duplicate an app....and control its properties and methods in the control panel. Oh well this is getting me 1 step closer to full developer...

So Fred I think I understand how this works. Now comes the stupid question, there always has to be one.... I know how to change the data url poiting it to a mirror server of BT, just change the domain (www....) the rest maintains the same. But pointing it just to a file, lets say I named the file, BT_Config.txt. And now its online at www.blablabla/blabla/BT_config.txt. Do I just copy this and replace all the data in the dataURL or do I need to keep any of these keys and api.... I´m guessing not, but want to check with who knows better. Cheers.

Replace the URL entirely. You can also upload the file to the Control Panel using the "File Manager", same as using DropBox. Fred

I just put it online somewhere. Gonna change only the Data Url so it point to this new place. upload this file, include it in the app and submit the update. Once its out, I'll give it a few days, so people can update, I'll go to the config file in the new place and delete the report to cloud URL, do I delete it all or just leave it blank after "reporttocloudURL".? This will allow me to make changes in the app's control panel without affecting the users that have the app. When finished I just put the new config file online in another folder and submit new update. or if the updates are just on the control panel, I just put back the reporttocloudURL. Does this seem correct?

Edited: Delete the URL leaving, two quotes and a comma. "reportToCloudURL":"", Fred

So Im testing this before moving forward. This is what i've done and what happens. I donwloaded the app from buzz touch. Localy on my pc I changed the dataURL to a remote location different from buzztouch server. The app works fine. When i make changes to the app in the control panel the app tells me there have been changes but nothing happens. The app does not assume the changes. I only changed the data url not the cloudurl. Is this the way it should react? Thanks

It didnt make sense so I unistalled and reinstalled, and now it updates as it should with the dataurl changed. Gonna test changing the cloud url. Thanks

Gonna test changing the cloud url. What do you seek to accomplish? It's options are: a. Use it b. Don't use it. c. Write you own script Fred

I mean gonna try deleting it to see that it does get offline and that it will not update with changes in the control panel. Wanna see it work so I can better understand how it all works.

Just reworded the tutorial above, give it a read. Fred

Thanks Fred.

So I've been testing and am having the same problem again. If I install an app with only the dataURL pointing to an external site, when updates are made in the control panel, they do not appear in the app. I have not change the cloudURL. I've not made any changes to the core properties in the control panel, they are as default, pointing to buzztouch server. What can I be missing? Cheers

So I've been testing and am having the same problem again. If I install an app with only the dataURL pointing to an external site, when updates are made in the control panel, they do not appear in the app. That's exactly what should happen I have not change the cloudURL. Only remove the reportToClouldURL from the SOCF if and when you want the app to go "offline". Changes to the published app will occur a. when you copy & paste the Config file to the SOCF if the app is online, or b. you publish a new binary. (Whether the app is online or not) With the new binary you can return the app back to online if it's offline. Fred

Ok. So having the config file remotly, If I make changes to the app, that I want to have reflected in the published app, I make them in the control panel, and manually update the config file On Dropbox, copying from the control panel, but keeping the dataurl to a remote site?

Correct

Perfect. Thanks