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 14:10:16 GMT
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