Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of shazron@gmail.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEeF2TdkpcCjLHS77nBZAnYmNwCB9OgdzH5q9wq38c1U9DjEdg@mail.gmail.com>
References: 
 <CAEeF2TeUdQxmb20a_07cg_UnrSLTkAbnez7Gkc4aZK2OhS+A2A@mail.gmail.com>
 <CADq=2H4Sp9rROS2c3+Azn0vQDkdobySLLdXDL+53-72s35LgSA@mail.gmail.com>
 <CAEeF2TdHJiaaF8c7_-Qs5eErALin1EEOCAJenTgEVCu-F+gFjA@mail.gmail.com>
 <CAEeF2TeC=UeJZU6Pb4b5PNU8P-M9w3AvZBf799cCxyQ3Ua3bJg@mail.gmail.com>
 <CAE6O_-YO-1UDEtcsbg8a_5hAFzmaoKNXPskhciKaJUHmxQ8xnQ@mail.gmail.com>
 <CAEeF2TcwQdZewEA3ivnH3ODWWgmRSDsjMrFaQynmbx0S-oMvVQ@mail.gmail.com>
 <CABiQX1WZp1pjuv5eqptekzbGjoojrfkAEJUKb49qLzBORhgcCA@mail.gmail.com>
 <CAEeF2TfwvJEmx3OSRWkrmZTPJ6LusHhtcQGf7x7kBoHF23C3mw@mail.gmail.com>
 <CAEeF2TdkpcCjLHS77nBZAnYmNwCB9OgdzH5q9wq38c1U9DjEdg@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Fri, 19 Oct 2012 12:29:36 -0700
Message-ID: 
 <CAE6O_-YObUAY3eQ4K24qcQegqKnFpWzKzFisvKoUcR2tv+Obug@mail.gmail.com>
Subject: Re: IOS6 LocalStorage filesystem target location.
To: Michal Mocny <mmocny@chromium.org>
Cc: callback-dev@incubator.apache.org, Shazron Abdullah <shaz@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1

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 <mmocny@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 <mmocny@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 <agrieve@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 <mmocny@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 <shazron@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.
>>>> >>>
>>>> >>>
>>>>