I've been going through some tutorials to try to understand code so I can make my app a bit 'sexier'. I've created a couple of very simple screens and stuff and have managed to write a bit of code to create a splashscreen that selects random background images by creating similar .xml files with different backgrounds then add a Random command then use switch, case to randomly load a splashscreen in the Java file. Yeah it might not be the best way to do it but it works and for a complete novice I'm quite chuffed! However, with this in mind I wanted to try and create something similar for the app I created through Buzztouch but for the life of me I cant follow the structure. For instance If I have three menu screens called "menuOne", "menuTwo" & "menuThree" I would expect to see these in the manifest file as an activity & also see the java files under the same name in the src folder. However all there are are the plugin names. So ignoring the random image thing just out of curiosity (in layman's talk) how exactly does it all work?

Excellent question. Buzztouch has created a basic set of XML files that use JSON data to dynamically create the screens you see. Fred

The menus 1,2,3 will be found in the JSON data. Fred

Hey @RobK, Fred's on the right track. The BT_Config.txt file contains all the JSON descriptions for the various screen you create, and which is interpreted by the various activity files you see listed in AndroidManifest.xml. There are a set of XML files, located in res/layout, that describe the various ways the screens will be displayed. When you cracked open your AndroidManifest.xml file, you noticed not only the base BT_activity_root, which is the main activity for the app, but multiple other activities that control the various screens you present to your user. In the case of your menu example, the BT_screen_menuListSimple activity would be utilized to draw your menu list screen, using the configuration parameters (screen nickname, menu text, etc) provided by the BT_Config.txt file. I realize that is a super simple, and probably massively incomplete description of things, but hopefully that sets you in the right direction? Mark

My Buzztouch Source Code (Android) is a good read to understand the various files in an Buzztouch Android project. Find it at www.MySkylla.com Fred

OK so when I created the source code for my app the config.txt created would have been the same as configuration data in my control panel? However since then I have changed it completely as I experimented changing screens around etc, consequently the config.txt is now nothing like the confuration data. Eg the 'menuOne' background image filename doesn't appear but does in the configuration data. splashscreeen doesn't transition to the home screen without tapping and so on and so on. when you make a change in buzztouch it shows up in the emulator straightaway but how does eclipse know to use this new info rather than the raw BT_config.txt info and also when I'm happy with the buzztouch screens should I overwrite the config.txt info with the revised configuration data? Or am I missing the point completely?

Hi Rob, In the buzztouch.com/resources section of the site, check out my tutorial on Online vs. Offline apps. It will answer all those questions! Mark

When you make a change in buzztouch it shows up in the emulator straightaway but how does eclipse know to use this new info rather than the raw BT_config.txt info Eclipse uses the reportToCloud URL in the Config file. Just like a device. But to be a bit more accurate, The AVD is a device, virtual but a device, so you're actually running all of the code. (The iOS Simulator only simulates an iOS device. What's the difference, well a picture, stimulation, of an apple is not an apple.) and also when I'm happy with the buzztouch screens should I overwrite the config.txt info with the revised configuration data? Yes

Thanks guys it's beginning to click (slowly!) So essentially providing there is a DataURL & ReportToCloudURL it is irrelevant what follows in the config.txt file? and going back to my OP; The only way to customize a BT plugin by randomizing background images, each time the screen was loaded, would be to modify the config file by making it offline as that is the only place I can find that specifies the background image or is there another way to do this outside the config file without creating new screens? I'd read the offline v online previously but it never really crossed my mind I would need to go offline

Interesting concept. Have the online Config file update hourly, daily with new data (random images). Perhaps simpler solutions, but I can see this one. Fred

Thanks guys it's beginning to click (slowly!) So essentially providing there is a DataURL & ReportToCloudURL it is irrelevant what follows in the config.txt file? and going back to my OP; The only way to customize a BT plugin by randomizing background images, each time the screen was loaded, would be to modify the config file by making it offline as that is the only place I can find that specifies the background image or is there another way to do this outside the config file without creating new screens? I'd read the offline v online previously but it never really crossed my mind I would need to go offline

So essentially providing there is a DataURL & ReportToCloudURL it is irrelevant what follows in the config.txt file? Not really true. Not having a punishable BT_config.txt file can cause many issues: Problems when app is first downloaded Apple review process If app's cache is cleared And a few more. Fred

One thing to keep in mind if you take an online app offline: it can only be brought back online via a package update in whatever store you manage it through. If you change the config file for a live app to suddenly become offline...the next time it checks in, it will make the requested changes (one of which will be to stop looking for future updates), make those changes, and then continue on. So, the next time it opens up, it'll see that it's offline, and no go looking for updates...ever again! At least until you provide a new package with a new config file. Mark

I believe that only in unusual circumstances will you wish to take an app offline. I believe the better process is to use a 3rd party (Dropbox) online Config file, and (very important part) initially publish the app using Dropbox as your online Config file location. Fred

My AZ Fishing Spots app (http://itunes.apple.com/us/app/az-fishing-spots/id468548506) is offline as has been from the start. I made a conscious decision to do that because I wanted all the content available out in the wilderness where people might be using it. I didn't want to have to retrieve anything from the network. I can see many app ideas where that might be the case. Mark

By using Dropbox as the online Config location and having the BT_config.txt file up to date you accomplish same without any offline issues. While I can see that occasionally you may wish to have an offline app. In your situation there's no advantage of having the app offline vs. using Dropbox as the online Config file location, and should you need to make a minor change you must publish a new binary. So, I submit that the better method of taking a app offline is not to take it offline, but to take the Config file to Dropbox and simply not update the Config file until you need to take it back online, in which case it already is. So, offline can be more properly though as neither online vs. offline but merely how you use the online Config file. (And where you place it. ) And in understanding this process one needs to read Mark's online offline articles plus my articles. Both of us have elaborated on this issue several times and in the process our understanding has evolved. Fred

If I were to put my config file on DropBox, every time if would check for an update (even if there are none), it would time out in the wilderness where there is no network access. That's why I've completely taken mine offline. No bad user experience of having network issues! Mark

Only checks if there's a connection. Therefore no network issues. Fred