I rebuilt my app thinking it would solve my refresh issue and it did for the first few hours of build and now towerds the end it no longer refreshes. I've posted many topics on this and have gone no where fast with a resolution. What can it be. I dont think it is too much info because i have other apps that are larger in content and have no problem refreshing. If someone can please help I would be totally grateful. Thanks Anthony

Hi Anthony, The issue is related to how long it takes the buzztouch control panel to create your config file, and a timeout setting. Every time you refresh your app, or view the config file from the core properties screen, buzztouch dynamically creates the config file. In some cases the screens and settings within an app take a little bit of time to build. I believe in your case you mentioned about 35 seconds for the config file in core properties to show up (build). Not a crazy long time, but long enough to trigger a timeout function that asks the user to check their internet settings. I apologize but I didn't address your other posts specifically because I saw your involvement on this post ( http://www.buzztouch.com/forum/thread.php?tid=47F18F53DBAAD032407E0CF&status=&searchInput=search...&sortColumn=FT.dateStampUTC&sortUpDown=DESC¤tPage=1&doViews=1 ) and I figured you were aware of our standing. We are working on this issue (along with building v1.5 for android and half a dozen other fixes) and will let you guys know when it is resolved. In the meantime while we're working on a fix you can: If your app ISN'T live - just download your current project file and use that when running in simulator or on device. No refresh necessary (Until you make changes to your control panel). If your app IS live - Try to resubmit your app to apple as a new updated version. If it is accepted, your end users will be prompted to download the new app. Shouldn't have any issues there. Either way you can decide if you want to change your Configuration Data URL and Report to Cloud URL settings. Check the documentation for more information on that: http://www.buzztouch.com/docs/v1.5

Hi @Parker, Thanks for this update. It applies to my forum thread that you mentioned above as well. I guess at the moment, since I'm still in test phase, that I'll have to recompile the app each time I want to test things. Not a huge deal, but I do hope you are able to fix the timeout issue! I did get a timeout regardless of using a version of BT_config.txt on my local server vs. buzztouch servers, but I guess that's because the app has to generate a new config file, compare it to the one on the server, and decide what needs to change. Thanks for all your hard work in supporting us! Mark

Thanks Parker

Parker, Is there a way to set the timeout limit to maybe 45-50 seconds? Just a thought and don't really know if it can be done. Please let us know. Thanks Anthony

Hi guys... not sure where eveyone is in the process. It sounds like these apps are 'slow' again when requesting the configuration data from the backend. This is an ongoing issue on our end (always trying to speed things up) but could be something simple? Assuming v1.5: Click the Show Configuration Data link in the core settings in the control panel. How long does this screen take to load? This amount of time should be the same when the mobile app does refreshes it's the same file the app requests. If it's slow (excessive) then there isn't anythign wrong with the mobile app and increasing it's timeout limit could help until we figure out a way to speed things up again. In this case, increasing the timeOut secons in the mobile app does make some sense. To do this, loop in BT_Objects folder > BT_downloader.m. Near the top, line 50, you'll see an entry like: [self setTimeoutSeconds:25]; Change the 25 to something larger, like 60. Another approach, may not be a good approach but could be depending on the update requirements. Use the control panel to make changes. Enter a URL in the control panel for app data URL (core properties again) to a URL on a site like DropBox or any other site. 'show the configuration data' and save the file as text file. Park that file on the DropBox or website. This may speed things up but would mean you'll need to update this file when changes are made.

Hi @David, I changed my [self setTimeoutSeconds:25] from 25 to 120, just to be super extra safe, and it's still timing out at around 25 seconds (in iPhone simulator). I did make sure I recompiled the project in Xcode to pick up the changes. Thanks, Mark (@GoNorthWest)

Same here. I set it to 90 secs and had no luck. I also tried parking the config on a different server and having the same issue. Anthony

I tried remote hosting of file a while back also, and it didn't help. The problem seems to be that the app checks for a new config file each time it's refreshed, and that is timing out before the operation can complete. If the app didn't have to generate a new one each time, and could just reference the last one created to see if new changes were made (via a time stamp or something), then it might not have to create a new one each time. But that might require the actual file to reside on the buzztouch servers, to be used in that comparison.

Hi guys, I'm new to buzz touch and i was having this problem. I tryed david's answer with the same result as the rest of you. So i scrolled down the code alittle bit and came across this section //start parse at URL -(void)downloadFile{ [BT_debugger showIt:self:[NSString stringWithFormat:@downloadFile: %@, urlString]]; //tell delegate download has started [self downloadFileStarted:@starting download...]; //start timer to track how long this is taking if(self.downloadTimer){ [self.downloadTimer invalidate]; } self.downloadTimer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(timerTick) userInfo:NULL repeats:YES]; //replace feed:// with http:// in urlString NSString *useURL = [urlString stringByReplacingOccurrencesOfString:@feed:// withString:@http://]; //clean-up URL, encode as UTF8 NSURL *escapedURL = [NSURL URLWithString:[useURL stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]]; //start request NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:escapedURL cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:25.0]; [theRequest setHTTPMethod:@GET]; self.remoteConn = [[NSURLConnection alloc] initWithRequest:theRequest delegate:self startImmediately:TRUE]; if(self.remoteConn){ receivedData = [[NSMutableData data] retain]; }else{ [self downloadFileCompleted:@Error - could not initialize connection.]; } I changed the cachepolicy timeoutInterval from 25.0 to 60.0 and saved it, recompiled and now it runs passed the 25 second timeout and collects the needed data and refreshes. Let me be clear i'm no programmer or anything so maybe before you try it wait for david or one of the buzztouch crew to confirm this works and wont stuff up anything else down the line.

Hi guys, there are a few threads going with the same type of discussion. Still trying to figure out each instance. So, I'm convinced that the buzztouch backend is not a problem unless the config data for an app is really really large. Like, hundreds of screens. In these edge cases, it can get slow and can cause the timeout. It's a matter of figuring out if the app is timing out and not completing the download, or, is it downloading and not able to read the data? It's hard for us to know which causing the trouble in each app because they are all different. It's best to look at the console and see if it's showing a timeout message or error. If it is, OK, we'll go down the path to fixing that on each of your apps. However, if it's not timing out, and is downloading the data but cannot read it, we'll need to take a different approach. Putting the config data file on a DropBox account all but ensures that it doens't take too long. Downloading the large file isn't the slow part, you can put a huge file on a server and the phone should download it without any trouble. The trouble with timeouts is usually on our end when CREATING a file each time. Our backend re-creates the entire config file (the slow process for huge apps) when yourr app's time-stamp / modified date changes or when you use the Refresh button on the app's home screen. This is why the DropBox test is so important. Is the slow-down in budling the file or in downloading the file...big difference. Use your console, post your results. I'll stick with this thead on a case-by-case basis until everyone's apps work as expected.

Hi David, Thanks for hanging in there with us! I posted a problem about this in my thread as well (http://www.buzztouch.com/forum/thread.php?tid=47F18F53DBAAD032407E0CF&status=&searchInput=search...&sortColumn=FT.dateStampUTC&sortUpDown=DESC¤tPage=2&doViews=1), but I'll continue in this thread until it is resolved. For my app, I believe the problem is with the time it takes to generate the config file. I currently have 700+ screens and counting in my app. I will do the DropBox test tomorrow, and let you know the results, so we can determine the exact problem one way or another. Thanks! Mark (GoNorthWest)

@stuxll,@David, @mark Thanks for your posts an replies. You are all a great help. So I took everyone advice, implemented stuxlls recommendations and I am refreshing. I changed both the timeout seconds and timeout interval to both 60 seconds and it worked. I think we must change both components to achieve success. Thanks again for the advice.

My App still wont download the data. there was a problem downloading some data. Check your internet connection and try again. That message appears seconds after I hit refresh.

So, I did some experimenting today, and here are my results. Current number of screens : 700+ (and growing...likely to be a couple thousand in the future) Time to generate config file from control panel using my laptop at work : 95 seconds Time to generate config file from control panel using my Mac Mini at home : 97 seconds Changing setTimeOutSeconds and timeInterval to 120s in BT_downloader.m allows the app to refresh with no issues. So, it WORKS! Putting BT_config.txt file on DropBox public folder allows app to refresh with no issues. So, it WORKS! Now comes the issue. Do I up the timeout timers to 120s and make my users wait, all so I can update the app from buzztouch (which is where I prefer to update it from), or do I host the BT_config.txt file elsewhere, and make it faster? And, as I enter the several hundred more screens I anticipate there being in the app, how will the time to generate the config file increase...exponentially? Logarithmically? Are we looking at multiple minutes in the near future? So, @David, do you have any thoughts or suggestions? Is there any way to speed up the time it takes to generate the config file on the backend, or perhaps cache it so it doesn't have to be generated each time? I know there are security risks with hosting the config file elsewhere...is the tradeoff worth it? Thanks! Mark

Hi Mark, building Google eh' - awesome. So..sounds like we have the sitch figured out, time. A few thoughts here. Short term, I think you'll be best served using the DropBox file for speeds sake. There isn't much were going to be able to do to speed up the creation time for an app with boatloads of screens. Awesome. Long term, I would do this...if you have the skill and / or patience to learn. a) Create an app with ONLY menus for each home screen or tab (lists or buttons) in your control panel. b) Use dataURL's for each menu. c) Create a file on your backend (DropBox is fine) with the items for each menu. This means you'll have about 5 or 6 screens in your control panel, all menus. This will load super fast from the backend when Refresh is tapped. But...were is the content? d) Next, for each menu, which is controlled by the file on DropBox (one file for each menu), create screens dynamically using the loadScreenObject property as shown in the documentation. This is the exact reason for this feature. There are a few apps 'out there' that literally have thousands of screens but the BT_config.txt file for the app only contains the root menus. All the other menus and sub-screens come from a backend, individually. It's hard to explain this process unless you kinda understand the idea already. Formally, this is called 'Lazy Loading' - only load the screens and menus as the user navigates to them. This approach is simimilar to other apps like iTunes, the App Store and other things native to you phone that potentially have millions of things to 'find.' If this doesn't make any sense, or it's just too complex, you may need to engineer a different approach. Not sure what that approach will be...but...Rome wasn't built in a day either ;-)

Hi David, Not building Google...just improving on it! I'm sure you've loaded up my app and taken a look...our aim is to provide direct access to gluten free menus when you need them the most...when you're hungry! So, for the moment, I guess we'll go with the remote server config file option. Not optimal, but a good workaround for the moment. It'll at least help get the app into the store where it can be of use to people. Subsequent versions can utilize a new method. I am TOTALLY up for learning the loadScreenObject and Lazy Loading method. My original intent with this app, before I was introduced to the goodness of buzztouch, was to create a sqlite database with the information I wanted to display. That would have been my first choice, but a quick read on the Lazy Loading method sounds even better. Keep a lookout for a forum post as I undoubtedly struggle with how to implement the concept in buzztouch! I cannot thank you and Parker enough for all the help you have given me and the other members of the forum. We know this is a labor of love for you, and you have paying day jobs, but I an extremely appreciative of all you do in providing this free service to us. You have truly brought app development to the masses! Thanks! Mark (GoNorthWest)

One question as I think about this...what are the security concerns, as related to my app, of having these dataURL files on the backend?

I guess it depends on what you consider 'secure' There are a few ways to look at it. If the app contains top-secret stuff, then your dataURL / config files will too, meaning you should secure them. However, if your app is public, free, available to anyone, it's likely that your config files don't contain anything special or worth securing. Example: I click a link in your app to load a screen...it's a URL that opens a web page (just an example). If you include an 'open in native browser' or somethign I'll see the URL. This means it's no longer secure - right? For sure there are lots of ways to look at this. To secure your backend files, you could easily use a .PHP script to produce them, or to protect them. You could do this by appending a value to the URL's and checking that this value exists in the URL before returning the data. Thats one idea of many. Security is a long and drawn out thing. For sure you should consider it but also realize that NOTHING is totally secure and you're reasonable measures are probably good enough. If somebody, like, say, me (LOL) wanted to find your config data info after downloading your app from the app store...um...I could ;-)