[GCompris-devel] GCompris refused on iOS

[roopesh shenoy]

Cache would be a bad place to put it - System can delete cache files
whenever disk memory gets full, for e.g.

I don't know what AppData maps to - if it maps to "Application Support" in
iOS then yes that would be a good place to put it (and I think it will not
sync then).

About clipboard, sorry, I left that sentence half - I meant to say "Even
copy to clipboard will be cumbersome".

You're right, wikipedia is not kid friendly - it was just an example. It
could be sites controlled by GCompris project, which are definitely not
linking anywhere.

Taking a step back, what's the purpose here? When do we link out of
GCompris, outside of the normal "about us" links? Are there activities in
GCompris that rely on this?

I think having a use-case in mind might help.


Be Awesome,

Roopesh
www.makkajai.com
www.facebook.com/makkajai
www.twitter.com/makkajai

On Wed, Feb 3, 2016 at 4:19 PM, Bruno Coudoin <bruno.coudoin at gcompris.net>
wrote:

> Le 03/02/2016 09:48, roopesh shenoy a écrit :
>
> For backup, it's exactly like the link Bruno mentioned below - just
> setting an attribute after the file is saved. It works fine as we've tested
> ourselves for our own apps.
>
> //make sure this data is not backed up.NSURL* URL = [NSURL fileURLWithPath:fullPath];NSError *error = nil;BOOL success = [URL setResourceValue:@YES                              forKey: NSURLIsExcludedFromBackupKey error: &error];
>
>
> Obviously you'll need the Qt equivalent of above and probably put that in
> some iOS-specific code block. But there should not be any need to change
> location of the saved files.
>
> Hi,
>
> I saw this but as Johnny pointed it maybe that using the CacheLocation
> goes to a location that is not synced. This is easier for us than having to
> call specific Objective C Apple API.
>
> QStandardPaths::CacheLocation:
> Returns a directory location where user-specific non-essential (cached)
> data should be written. This is an application-specific directory. The
> returned path is never empty.
>
> QStandardPaths::AppDataLocation:
> Returns a directory location where persistent application data can be
> stored. This is an application-specific directory. To obtain a path to
> store data to be shared with other applications, use
> QStandardPaths::GenericDataLocation. The returned path is never empty. On
> the Windows operating system, this returns the roaming path. This enum
> value was added in Qt 5.4.
>
>
>
>
> For kids, Apple's policy is pretty clear - no links/in-app purchases
> without a parental gate. So if you want to keep the links active, they will
> need to open a parental gate every time (annoying, no doubt, but can't help
> it) before the link opens a browser.
>
> In many ways, I agree with Apple and Bruno on this - parents expect there
> to be no external links in "kids" category apps on iOS. Even copy to
> clip-board.
>
> I agree with you except on the copy to clipboard, What it the rationale
> behind it, do you have the Apple rule on it?
>
>
>
> A simpler way **might** be to have a kid-friendly web-view within the app
> - you click on these links, it opens the link within a webview or something
> that only shows white listed content; so if it's content from Wikipedia
> that is pre-whitelisted to be kid-friendly, show it - else don't?
>
> Wikipedia is by far not kid friendly. So even if the page we link is fine
> at one time it may become inappropriate in the future or it maybe for some
> language and not others. A nightmare. Having a webview is also a technical
> issue by itself.
>
> Bruno.
>
>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160203/c03a343a/attachment-0001.html>