incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: IOS6 LocalStorage filesystem target location.
Date Fri, 19 Oct 2012 18:52:22 GMT
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 <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