Ok. sorry I'm confused. Is this correct? browser/desktop: localStorage persists to the device browser/ios: localStorage might not persist to device cordova/ios: localStorage persists to the device cordova/android: localStorage persists to the device
On Fri, Oct 19, 2012 at 11:20 AM, Andrew Grieve <agri...@chromium.org> wrote: > 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. >> >>>>> >>> >> >>>>> >>> >> >>>>> > >
