incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: IOS6 LocalStorage filesystem target location.
Date Fri, 19 Oct 2012 18:26:31 GMT
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 <agrieve@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 <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
View raw message