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. > >>> > >>> >
