incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: IOS6 LocalStorage filesystem target location.
Date Fri, 19 Oct 2012 18:20:40 GMT
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 <mmocny@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 <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.
> >>>>> >>>
> >>>>> >>>
> >>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message