Other platforms don't have the equivalent of iCloud, I don't think. Native apps on iOS backup the contents of their non-Caches directory to iCloud by default. I don't think being browser-based should change that.
On Fri, Oct 19, 2012 at 1:35 PM, Michal Mocny <mmo...@chromium.org> wrote: > Its have already been different since the ios5.1 release. We are just > going to add a (non-default) option to opt out. > > We could change the default to be opt-out of backup, like the ios > default, but that may be a breaking change. > > Also, while other platforms dont backup to cloud, they probably also > persist locally, so the default behaviour of other cordova platforms > already differs from the webview default on ios. > > What a mess! > > On Fri, Oct 19, 2012 at 1:28 PM, Brian LeRoux <b...@brian.io> wrote: > > Hey guys, I'm a little concerned that our default being different than > > that of The Browser, and the other Cordova platforms. =/ > > > > On Fri, Oct 19, 2012 at 8:01 AM, Michal Mocny <mmo...@chromium.org> > wrote: > >> Also, I really hate using a magic number here. Is there a canonical > >> way to implement "enum" type in plist file? A few google searches do > >> not yield anything sane. > >> > >> Would it be more descriptive to use a string setting with values such > >> as "none", "local", "cloud"? > >> > >> On Fri, Oct 19, 2012 at 10:35 AM, Michal Mocny <mmo...@chromium.org> > wrote: > >>> Yes, thats the conclusion I've made now, too. I figure the app > >>> developer can decide how he wants to take his changes with the review > >>> process, and at least one user was very vocal to have this feature. > >>> > >>> Locally, I created a second setting instead of changing the format of > >>> the current one, but I guess I'm fine with changing it in place as you > >>> suggest, especially since I suspect no-one changed the default of the > >>> current one (why would you?). > >>> > >>> There is one more potential combination that may be needed, but I am > >>> not sure if it is worth the effort: backup to iCloud on ios6 only. > >>> > >>> Potentially apple will reject backing up a copy of webstorage to > >>> icloud on ios5.1, while at the same time we may still want to disable > >>> CDVLocalStorage plugin on ios6, thus backing up to cloud on ios6 but > >>> not 5.1. Should I account for that, or leave it all-or-nothing and > >>> punt for future releases if it becomes a problem? > >>> > >>> On Fri, Oct 19, 2012 at 10:10 AM, Andrew Grieve <agri...@chromium.org> > wrote: > >>>> I don't think we should read too much into the app rejection related > to > >>>> this. These things are often app-specific and not a result of a rule > >>>> cordova itself doing something wrong. > >>>> > >>>> Proposal: > >>>> We already have a setting for this in cordova.plist, as described > here: > >>>> > https://github.com/apache/incubator-cordova-docs/blob/master/docs/en/edge/guide/project-settings/ios/index.md > >>>> > >>>> Right now, it's a BOOL, how about we change it to an int and have: > >>>> 0 - Do not back up - Users should use this only when their > DB/LocalStorage > >>>> is a cache > >>>> 1 - Backup to iCloud (by setting the NSUserDefaults key) > >>>> 2 - Backup to Device only (and ensure to set the > >>>> NSURLIsExcludedFromBackupKey) > >>>> > >>>> Option 2 would probably not be used much, but may be useful to have > in case > >>>> of app rejections. > >>>> I think #1 should be the default. It's better to have things safe by > >>>> default, and have apps get rejected than to have them get through the > >>>> app-store and have their users hate them when data loss happens. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Thu, Oct 18, 2012 at 2:57 PM, Michal Mocny <mmo...@chromium.org> > wrote: > >>>> > >>>>> Andrew: Yes, I was also thinking of advising to use FileSystem API > for > >>>>> things they want to backup to iCloud. > >>>>> > >>>>> On Thu, Oct 18, 2012 at 1:55 PM, Shazron <shaz...@gmail.com> wrote: > >>>>> > To recap: > >>>>> > > >>>>> > iOS 6 indeed does solve this problem with the NSUserDefaults key > >>>>> > "WebKitStoreWebDataForBackup" - which I think the web data is > stored > >>>>> > in Library/Caches as changed by iOS 5.1. > >>>>> > >>>>> What do you mean by "ios6 does solve this problem"? > >>>>> > >>>>> The WebKitStoreWebDataForBackup flag changes the LocalStorage > location > >>>>> from /Library/Caches to /Library/WebKit/LocalStorage (ie, back to > >>>>> where it was before ios5.1 moved it to Cache folder). Setting this > >>>>> flag means LocalStorage persists (great) but also backs up to iCloud > >>>>> (may not be desired -- and arguably should never be desired). > >>>>> > >>>>> > > >>>>> > iOS 5.1 it is stored in Library/Caches thus it is not backed up - > >>>>> > that's why we backed it up to the Documents/Backups folder (and > backed > >>>>> > up/restore to /Library/Caches). We do _not_ set the > >>>>> > NSURLIsExcludedFromBackupKey on the Documents/Backups folder, if > the > >>>>> > dev wanted to, they can do so using the File API's > >>>>> > FileEntry.setMetadata function. > >>>>> > >>>>> Correct -- and I did not know that we can use FileEntry.setMetadata > >>>>> for this. I'll look into it, thanks! > >>>>> > >>>>> > > >>>>> > CB-1561 (Apple rejection) could be solved by them setting the > metadata > >>>>> > bit. But if they want it to be backed up by iCloud they shouldn't > do > >>>>> > set that bit - but then if they _don't_ set that bit -- rejection. > >>>>> > >>>>> If not setting that bit causes rejection, then seems we should just > >>>>> set it by default. Somehow apps have managed to sneak by the review > >>>>> process until now (perhaps the changes to ios6 have changed the > review > >>>>> process?). > >>>>> > >>>>> > > >>>>> > Upgrading from iOS 5.1 to 6 shouldn't be a problem since ultimately > >>>>> > the database locations are still in Library/Caches -- we just need > to > >>>>> > set the NSUserDefaults key. > >>>>> > >>>>> If we set the NSUserDefaults key, the database location does change. > >>>>> Possibly this migration is provided by default (otherwise all webview > >>>>> apps would lose old data with manual restore), but we still need to > >>>>> restore our custom ios5.1 backup for first-launch-after-upgrade case. > >>>>> This has been implemented already in 2.1, though there were some > >>>>> issues+bugfixes. > >>>>> > >>>>> > > >>>>> > This is solved by iOS 6, but we don't have a clear answer for iOS > 5.1 > >>>>> > (besides upgrading to iOS 6) -- our original fix is not tenable > >>>>> > anymore ( > >>>>> > http://phonegap.com/2012/04/18/ios-5-1-and-the-embedded-uiwebview-with-cordova/ > >>>>> ) > >>>>> > >>>>> While I don't yet see the point of backing up LocalStorage to the > >>>>> cloud, I will concede that it may be a lesser evil compared to > forever > >>>>> using the LocalStorage Plugin/hack, which is necessary for ios5.1. > >>>>> > >>>>> For additional context: we already used the UserDefault setting for > >>>>> 2.1 release, yet I've reverted back to using the Plugin in current > git > >>>>> version, since I thought iCloud backup was a mistake. > >>>>> > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> Summarizing: > >>>>> - I think we should flag any backups we make with > >>>>> NSURLIsExcludedFromBackupKey *by default* (ios5.1 must do this, ios6 > >>>>> depends on decision to use NSUserDefaults). > >>>>> - ios6 we have a choice (to cloud or not to cloud). Possibly the > >>>>> choice should be up to the app developer. I now again think we > should > >>>>> backup to iCloud, if only to not need use our plugin, and to not > >>>>> change behavior from 2.1 (again). > >>>>> > >>>>> Additionally: > >>>>> - The current location of our local backups (Documents folder) is > >>>>> incorrect. Apple hasn't rejected any apps for this, but it should be > >>>>> in /Library/Application Support (fixed). > >>>>> - I've tested restoring localstorage with various upgrade paths, but > I > >>>>> may have just uncovered a bug with restoring websql. > >>>>> - We should probably document some of this for the 2.2 release. > >>>>> > >>>>> > > >>>>> > On Thu, Oct 18, 2012 at 8:06 AM, Michal Mocny <mmo...@chromium.org > > > >>>>> wrote: > >>>>> >> So there has been a lot of back and forth recently about where > and how > >>>>> >> to backup localstorage (see: > >>>>> >> https://issues.apache.org/jira/browse/CB-1561) > >>>>> >> > >>>>> >> At least one users wants these to backup to iCloud -- and while I > >>>>> >> don't see how that makes real sense, the fact that apple added a > flag > >>>>> >> to allow this in ios6 maybe signals we should allow the option. > >>>>> >> > >>>>> >> Given that this cannot work on versions less than 5.1, may not be > >>>>> >> enabled on ios6, and may not work the way developers expect > anyway, is > >>>>> >> there a point? > >>>>> >> > >>>>> >> Shaz, would appreciate your opinion here, if you are around. > >>>>> >> > >>>>> >> -Michal > >>>>> >> > >>>>> >> On Fri, Oct 5, 2012 at 2:23 PM, Michal Mocny <mmo...@chromium.org > > > >>>>> wrote: > >>>>> >>> Done. > >>>>> >>> > >>>>> >>> > >>>>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=6e170879aa37d33701739fc3c28ed9f78156bf1f > >>>>> >>> > >>>>> >>> As of today we backup to a different location so as not to upset > the > >>>>> apple > >>>>> >>> app review overlords, and we do not backup to icloud on ios6 any > more. > >>>>> >>> > >>>>> >>> I've added support for loading all the various old database > locations > >>>>> the > >>>>> >>> first time you run an upgraded app, but if there are only issues > >>>>> reported > >>>>> >>> about this, send them my way! > >>>>> >>> > >>>>> >>> -Michal > >>>>> >>> > >>>>> >>> > >>>>> >>> On Wed, Oct 3, 2012 at 4:43 PM, Dave Johnson < > dave.c.john...@gmail.com > >>>>> > > >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> I agree backing up to iCloud seems like a bad idea. Let alone > the > >>>>> >>>> Apple policy issues. > >>>>> >>>> > >>>>> >>>> -d > >>>>> >>>> > >>>>> >>>> On Wed, Oct 3, 2012 at 10:31 PM, Michal Mocny < > mmo...@google.com> > >>>>> wrote: > >>>>> >>>> > === Background === > >>>>> >>>> > > >>>>> >>>> > In IOS5.1 moved these files from the "documents" folder to a > "cache" > >>>>> >>>> > folder, which meant they may get purged when the system > decided > >>>>> memory > >>>>> >>>> > was > >>>>> >>>> > geting tight. To get around this, we implemented a manual > >>>>> >>>> > backup/restore > >>>>> >>>> > plugin (CDVLocalStorage). (I was not here for this work, > piecing > >>>>> >>>> > history > >>>>> >>>> > together.) > >>>>> >>>> > > >>>>> >>>> > With IOS6, Apply added a new UserDefaults option > >>>>> >>>> > (WebKitStoreWebDataForBackup) to backup these files onto > iCloud, > >>>>> with > >>>>> >>>> > the > >>>>> >>>> > side effect of having persistant local storage without the > need for > >>>>> our > >>>>> >>>> > backup hacks/plugin. > >>>>> >>>> > > >>>>> >>>> > ======== > >>>>> >>>> > > >>>>> >>>> > Initially I used this new IOS6 feature as a means to get > persistant > >>>>> >>>> > localstorage (there was a bug to add that when I started > >>>>> contributing). > >>>>> >>>> > > >>>>> >>>> > However, its actually been against apple policy to store these > >>>>> files in > >>>>> >>>> > the > >>>>> >>>> > documents folder, and user apps are being rejected from app > store, > >>>>> see: > >>>>> >>>> > https://issues.apache.org/jira/browse/CB-1561. > >>>>> >>>> > > >>>>> >>>> > More importantly, I don't think we should want to backup these > >>>>> files to > >>>>> >>>> > a > >>>>> >>>> > users' iCloud just to get persistant storage. > >>>>> >>>> > > >>>>> >>>> > I think we should re-enable the plugin used for ios5.1 on > ios6 and > >>>>> not > >>>>> >>>> > backup to iCloud. This may have perf implications but no > more-so > >>>>> than > >>>>> >>>> > we > >>>>> >>>> > have already been dealing with until now (and which I haven't > >>>>> >>>> > benchmarked). > >>>>> >>>> > > >>>>> >>>> > What do others think? There are other means to fix the > current > >>>>> issues > >>>>> >>>> > and > >>>>> >>>> > continue to use the next setting, so we do have options here. > >>>>> >>> > >>>>> >>> > >>>>> >
