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 15:01:15 GMT
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