IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@google.com>]

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

Re: IOS6 LocalStorage filesystem target location.

[Shazron <sh...@gmail.com>]

> On Thu, Oct 18, 2012 at 1:55 PM, Shazron <sh...@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).

Does it back up to iCloud though? I wasn't sure.

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

It might be a perception problem -- the reviewers see a bunch of .db
files that do not seem "user created" and taking up a lot of space,
and think it's app data that can be recreated. I don't recall the
actual reason why the bit wasn't set in the first place - but it
probably was my reasoning that the user should actively know what is
happening with this data and use the setMetadata function if they
_don't_ want it to be backed up (so it is backed up by default --
iCloud plus iTunes sync). That and it wasn't documented adequately by
me probably resulted in a lot of headache.

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

Brian, I think that is right, with the clarification to browser/ios is
webview/ios -- I am not certain if mobile Safari app localStorage
exhibits same behaviour.

Also, when they made that change in 5.1, it was pointed out that the
spec for localStorage actually says this is acceptable behaviour.
While I guess it is unlikely to come to desktop (storage isn't as
tight there), I could see that change potentially going to other
mobile platforms.

On Fri, Oct 19, 2012 at 2:26 PM, Brian LeRoux <b...@brian.io> wrote:
> 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 <ag...@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 <mm...@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 <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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
>>> >>>>> > <mm...@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
>>> >>>>> >> <mm...@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.johnson@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
>>> >>>>> >>>> <mm...@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.
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>>
>>
>>

Re: IOS6 LocalStorage filesystem target location.

[Brian LeRoux <b...@brian.io>]

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 <ag...@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 <mm...@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 <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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
>> >>>>> > <mm...@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
>> >>>>> >> <mm...@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.johnson@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
>> >>>>> >>>> <mm...@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.
>> >>>>> >>>
>> >>>>> >>>
>> >>>>>
>
>

Re: IOS6 LocalStorage filesystem target location.

[Andrew Grieve <ag...@chromium.org>]

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 <mm...@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 <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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 <mmocny@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 <mmocny@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.johnson@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 <
> mmocny@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.
> >>>>> >>>
> >>>>> >>>
> >>>>>
>

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

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 <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
>>>>> >>>
>>>>> >>>
>>>>>

Re: IOS6 LocalStorage filesystem target location.

[Brian LeRoux <b...@brian.io>]

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 <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
>>>> >>>
>>>> >>>
>>>>

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

Alright, these changes have landed.

@Shaz: Good point about still supporting the bool value, I've added
that, thanks.

I've tested best I could with the devices I have such that switching
between the various values for backup does persist the current
databases by moving them around the local filesystem.  And also tested
that the backup storage usage reported by iCloud settings goes down to
near 0 when app changed to not use cloud backups.

I have a minor patch or two to add (just cleanup), but wanted to get
this in for rc2, and will be in touch about what needs to be
documented and tested by more people.

-Michal

On Fri, Oct 19, 2012 at 3:29 PM, Shazron <sh...@gmail.com> wrote:
> I'd rather go with a string based value (an example - Apple uses it
> for their spinner "color" value) -- this is more clear.
> Since this is a property type change -- we should handle the case
> where the user still used the old Boolean type and appropriately map
> it to the new type, and print out a warning to the console for
> deprecation.
>
>
> On Fri, Oct 19, 2012 at 8:01 AM, Michal Mocny <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
>>>>> >>>
>>>>> >>>
>>>>>

Re: IOS6 LocalStorage filesystem target location.

[Shazron <sh...@gmail.com>]

I'd rather go with a string based value (an example - Apple uses it
for their spinner "color" value) -- this is more clear.
Since this is a property type change -- we should handle the case
where the user still used the old Boolean type and appropriately map
it to the new type, and print out a warning to the console for
deprecation.


On Fri, Oct 19, 2012 at 8:01 AM, Michal Mocny <mm...@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 <mm...@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 <ag...@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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
>>>> >>>
>>>> >>>
>>>>

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

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 <mm...@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 <ag...@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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
>>> >>>
>>> >>>
>>>

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

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 <ag...@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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
>> >>>
>> >>>
>>

Re: IOS6 LocalStorage filesystem target location.

[Andrew Grieve <ag...@chromium.org>]

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 <mm...@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 <sh...@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 <mm...@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 <mm...@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.johnson@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 <mm...@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.
> >>>
> >>>
>

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

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 <sh...@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 <mm...@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 <mm...@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 <da...@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 <mm...@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.
>>>
>>>

Re: IOS6 LocalStorage filesystem target location.

[Shazron <sh...@gmail.com>]

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.

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.

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.

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.

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/)





On Thu, Oct 18, 2012 at 8:06 AM, Michal Mocny <mm...@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 <mm...@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 <da...@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 <mm...@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.
>>
>>

Re: IOS6 LocalStorage filesystem target location.

[Andrew Grieve <ag...@chromium.org>]

You're right that there are already many ways to sync to the cloud. I think
the only thing that makes iCloud different from other options is that it
doesn't (to the best of my knowledge) have an API that you can use, at
least not in the same way that others provide.

iCloud can't really be ignored, but it's so platform specific, that I don't
think it's meaningful to write a cross-platform abstraction for it. I think
we should document that apple has added a setting that makes webview's
storage back-up to iCloud, and make sure that we don't break if this
setting is enabled. Apps can also use the FileSystem API to put files in
spots that will be iCloud backed-up.


On Thu, Oct 18, 2012 at 12:30 PM, Patrick Mueller <pm...@gmail.com> wrote:

> Seems to me this is a wider-than-just-iOS issue.  Does/will someone have a
> "cloud" for Android, like Apple does for iOS?  Or what about using Dropbox
> ET AL.
>
> I see these axes:
>
> - storage interface - localStorage, webSQL, File, IndexedDB, ET AL
> - storage persistence - "to the cloud!", "you can delete it, I'll
> repopulate from the server as need be", "pretty please, don't delete it",
> "under no circumstances delete it", ET AL
>
> Bolting stuff onto the existing interfaces to handle level of persistence
> seems wrong.  Maybe an orthogonal interface:
>
> class StorageStrategerizer {
>     typedef string Strategy;
>
>     Strategy getStorageStrategy(storageType, storageName?)
>
>     Strategy setStorageStrategy(storageType, storageName?, strategy)
> }
>
> Anything going on here in W3C, IETF, HTML5, ET AL re: this kind of thing?
>
> Maybe queue up a wiki page to strategerize on the topic?
>
> On Thu, Oct 18, 2012 at 11:06 AM, Michal Mocny <mm...@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.
> >
>
> --
> Patrick Mueller
> http://muellerware.org
>

Re: IOS6 LocalStorage filesystem target location.

[Patrick Mueller <pm...@gmail.com>]

Seems to me this is a wider-than-just-iOS issue.  Does/will someone have a
"cloud" for Android, like Apple does for iOS?  Or what about using Dropbox
ET AL.

I see these axes:

- storage interface - localStorage, webSQL, File, IndexedDB, ET AL
- storage persistence - "to the cloud!", "you can delete it, I'll
repopulate from the server as need be", "pretty please, don't delete it",
"under no circumstances delete it", ET AL

Bolting stuff onto the existing interfaces to handle level of persistence
seems wrong.  Maybe an orthogonal interface:

class StorageStrategerizer {
    typedef string Strategy;

    Strategy getStorageStrategy(storageType, storageName?)

    Strategy setStorageStrategy(storageType, storageName?, strategy)
}

Anything going on here in W3C, IETF, HTML5, ET AL re: this kind of thing?

Maybe queue up a wiki page to strategerize on the topic?

On Thu, Oct 18, 2012 at 11:06 AM, Michal Mocny <mm...@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.
>

-- 
Patrick Mueller
http://muellerware.org

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

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 <mm...@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 <da...@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 <mm...@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.
>
>

Re: IOS6 LocalStorage filesystem target location.

[Michal Mocny <mm...@chromium.org>]

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 <da...@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 <mm...@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.
>

Re: IOS6 LocalStorage filesystem target location.

[Dave Johnson <da...@gmail.com>]

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