I encounter a small problem after the submission of an application. After all my tests I change the way I put the Live Mode, but when I go to see my buzztouch administration every download of the application are not in Live mode, there are in Design mode ... is that it's a bug or I that configures something wrong ? Is there a solution ?

Live/Design mode does not work anymore since over a year. Maybe David will fix it, maybe not, nobody knows ;-)

All download packages contain a BT_Config.txt file that is in Design mode. That is by design. Before you publish your app, you need to change the line in the file to Live, otherwise everybody will see changes as you test them. As far as I know, Design/Live mode still works from the control panel. But I'll check into it. Mark

Come on Mark, we had this conversation in at least 4 topics. It is not working, please believe that. David knows, everybody knows, nobody seems to care :(

Definitely not working

I thought Chris Ruddel posted a snippet at one point that makes it work on iOS???

I have the snippet in my newest project. It still does not work. It's really no a show stopper though. Just a minor inconvience. I'm sure it will get worked out eventually. Dave

Sorry Mark, have to agree with everyone else, this stopped working a loooooong time ago, LOL! mrDavid

So what exactly are we talking about here? That an app with a config file in Live mode doesn't get updated when you hit Publish in the control panel? Just making sure I understand. Guess you can tell how many "Live" apps I have published! Mark

Basically live mode does not work. It's always in design mode. If the app is set to live and you make changes, the changes show in the app without hitting publish Dave

Cool...that's what I experienced last night in my testing on my self-hosted server. I have pinged David Book about it...maybe we'll get a fresh look. Mark

Ok, back on this. And before I continue, and without starting an argument. I DO CARE. ALL OF US CARE. No apologies needed and no worries about the previous remarks on this thread, I realize we're all passionate about this stuff but I can assure you LOTS of people care - me especially. On to the bigger issue... I'm testing this on three different machines. Mine (self hosted). BT hosted, and @GoNorthWest's self hosted. All three demonstrate the exact same behavior. This is good. The behavior (the discussion here gets complicated, no other way around it)...: When I download a project, it's set to "Design" in the config.txt file. This not something we change in the control panel, it's in the JSON data in the Xcode project. While the JSON in the Xcode project is in Design mode, pressing "Save" in the control panel prompts the user to refresh on the device. Every save triggers this. The device prompts in a few circumstances. Generally speaking it's when the app is pushed to the background and brought again to the foreground. I think we all understand this. So far so good. Using the Publish option in the control pane has NO EFFECT on this behaviour. This is because the app is in Design mode (because it reads Design in the JSON data compiled in the Xcode project. We need to discuss how this is working - technically. When Save is pressed in the control panel the Modified Date is updated. You can see this on the app's landing screen. It shows you the date-time of the last time it was modified. Nearly every save button in the control panel updates this date-time. So, Save updates the modified date-time. So far so good. Note: Timezones and regional / localization informaiton has no bearing on this. Consider the date-time value just a value, nothing more. It's not important literally what it reads, but instead what IS IMPORTANT IS THE DIFFERENCE BETWEEN THE MODIFIED DATE-TIME AND THE PUBLISHED DATE-TIME. When you Publish, these two values match, until which time something else is Saved. In which case they no longer match. So far so good...Publish - they match. Save - they do not. On to the app. The app uses it's reportToCloud method to do two things. First, it sends some device variables to the backend for save keeping, tracking, some other stuff. Note: Some developers are doing some interesting things with these variables. I'll stay off that tangent...second, and most speciic to this issue, it DOWNLOADS the last PUBLISHED value from the backend. The value returned to the device when it runs the reportToCloud method looks something like: {"lastModifiedUTC":"Thu, 05 Feb 2015 09:04:01 -0800"} A simple JSON structure with a date-time value. To repeat, the format / locale of the date-time value is not important. What is important is whether or not it changed since the last time the device checked. Pressing Save in the control panel a zillion times will not change this value. Go ahead and try it. How to: a) Run an app in Xcode. b) Look at the console, copy the URL it shows when it runs the reportToCloud method. It does this alot but for sure when the app is brought to the foreground. Be sure to copy the URL "after the merge" - it will show you the URL before it merges any device variables and again after, use the one after the merge. Search for: "reporting to cloud at" in the console. c) Paste that URL in your browser's address bar. Hit enter. You'll see the value returned. It will look like the json I pasted above. d) Press Save somewhere in the control panel. Refresh your browser, nothing will change. This is because the reportToCloud value on the server is NOT related to the modified date, it's related to the Published date. e) Press Publish. Refresh your browser. You'll get a new value. If you don't something is wrong or you've customized your server somehow. f) Push the app to the background, then bring it to the foreground...it will prompt for a refresh. It prompts for a refresh because the value returned from the server is DIFFERENT than the last time it checked. With that out of the way, lets try to find what I, we, all of us are missing. We've beat ouselves up over this for quit sometime and it's not entirely clear what's happening. Here are some ideas... --The app in the App Store did not have "Live" set in the config data in the Xcode project before compiling and submitting. It is permanently in "Design" mode. In this case every change in the control panel would be noticed by the app, as expected. --The app in the App Store has "Live" in the config data, it was compiled this way and the reportToCloud results are not a proper JSON structure. Unlikely but possible. I can only imagine this happening if a develper is using a different / customized reportToCloud URL that returns an arbitrary value. There are cases when this could be useful but for sure it would interfere with the built in reportToCloudLogic. --The app in the App Store has "Live" set in the config data, the reportToCloud URL is returning a proper JSON structure with a new value evertime the app launches. Doubtful again but no clue as to why this could be happening? This is even more unlikely that the previous idea. --The app in the App Store has "Live" set in the config data, the reportToCloud URL is returning the same value everytime (it's has not been published since the last save) but the device is NOT able to save this value to it's cache / file system. Another hard one to imagine but it's possible I guess. The device needs to have a tiny bit of space available on it's internal storage to save this ultra tiny data structure. If it cannot, it will assume it needs to refresh. Stretching here but possible. --The app in the App Store has "Live" set in the config data but the reportToCloud URL is somehow invalid, screwy, messed up and NOT appending Live or Design to the end of it. Have a look at the reportToCloud method itself, it's in the app's delegate. Starts around line 711. You'll see where it does a simpe append (concatenation) to the end of the reportToCloudURL to add Live or Design to it. Pretty simple. If this isn't happening then you should also be able to see the URL in the console WITHOUT this value on the end. Thinking as I type that this is more likely (a screwy URL) than some of the other ideas I've posted). --The app in the App Store has "Live" set in the config data, the URL is OK. the results of the reportToCloud download are OK and I've lost my mind. It's OK if this is the case, I lose my mind alot. I can't for the life of me determine what else could be causing this. I know a long time ago there were some issues with the way the Live / Design value were getting appeneded to the end of the URL but that was ironed out and fixed when I was like 15 or so (I'm much older now). In fact, if my old-man memory serves me right, @Chris1 helped slueth that out. Dudes a ninja. Last thought on this (for tonight): --I'm not convinced that a "fix" is necessary and something else will be discovered in this conversation. --I'm not convinced that the Live / Design mode was a good idea in the first place. I'll elaborate on that later. --I'm not convinced that the way the Live / Design mode "works" is the best way. If we keep this around there must surely be a less confusing way to implement it. --I am convinced that there's a solution that's eluding me. I'm not adverse to fixing things, I'm just adverse to arbitrarily fixing things I / we / lots of folks don't understand. Ultimately it's a matter of balancing all sorts of priorities, and unfortunately, this one is pretty far down the list. I realize it's important for some of us, mostly some of our closest colleagues and friends, but the reality is, almost nobody cares too much about this feature and it rarely comes up - compared to all the other broken-ness-that-need-attention-improvment. Ha. Hoping your're giggling with me and confident that you understand this perspective. I'll ponder this once again as I drift asleep and leave you with some more fun news. BuzzCon related news. Lets just say keep your eyes open over the next few days for a post pinned on the forum landing page. We'll be asking for nominations for a few different "best of" categories and will be giving some neato awards out in Chicago. I hope you can join us. I hope Live / Design is ironed out by then. I hope a million other things are ironed out by then. Cheers...

Thanks David.

Good stuff! In response to "I'm not convinced that the Live / Design mode was a good idea in the first place. I'll elaborate on that later." - I actually think it's a great idea. It's the perfect way to try out new stuff in the Design version of the app before pushing it out to users. I can't think of a better way to do it that doesn't involve an actual store update. Thanks for working on this! YOU are a NINJA! Mark

thx for answer David and hey, you know me by now, always a bit to loud saying what I think, but as this is a big part of my income I am very passionate about it ;-) In my opinion and I think not too many members make more apps for clients then myself, the following 3 things are on the very top of the list that should be solved: - Live/Design mode - white loading screen - menu screen sizes cheers ;-)

Hi @LeonG, yup, agree, you're a bad-ass and rely on these features more than most - makes perfect sense. One by one..Live / Design first, staying on this until it irons out. white loading screens and menu-screen-sizes moved up the list too. In fact, was tinkering with an .xib file last night on my generic Menu plugin to get a hold of the dynamic screen size issues. May find a fix for that while we wait out additional comments on the Live / Design mode gotcha. I'll email you directly when my Menu List plugin is updated to accomodate for all the screen sizes. Guessing whatever I come up with (surely it will involve an .xib file in the plugin) will be useful / required in all the other menu type plugins others have created. LOVE THE PASSION ;-) d.

----------------- d) Press Save somewhere in the control panel. Refresh your browser, nothing will change. This is because the reportToCloud value on the server is NOT related to the modified date, it's related to the Published date. ------------------ my date changes here every single time I save something, no matter what! Does that make it more complicated? ;-) EDIT: always in Design mode though! Those reporttoCloud URL´s will not get the "Live" ending, even if my BT-config has currentMode: "Live"

changing manually to "live" in the BT_application.m like this does not change anything either: //set "currentMode" (live or design) in app's delegate... if([thisApp objectForKey:@"currentMode"]){ if([[thisApp objectForKey:@"currentMode"] length] > 0){ [appDelegate setCurrentMode:[thisApp objectForKey:@"currentMode"]]; }else{ [appDelegate setCurrentMode:@"live"]; } appDelegate.m has 2 identical code spots where we can find some code regarding Live/Design: //append currentMode ("Live" or "Design") to end of URL... useURL = [useURL stringByAppendingString:[NSString stringWithFormat:@"&currentMode=%@", [self currentMode]]]; Pfff...

@LeonG: Fantastic sluething...we're on the right track here. "my date changes here every single time I save something" Sounds like two things are hosed, not sure why / how yet but for sure. --1 The current value of Live / Design is not getting appended to the end of the reportToCloud URL. --2 The Saving / modified date changes, this is also not as expected. Can you send an email to david @ buzztouch.com with your reportToCloudURL so I can get a look.

send!

This would be awesome to get fixed. It's a big help for us managing our customers apps! Tim