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