[GCompris-devel] GCompris refused on iOS

roopesh shenoy shenoy.roopesh at gmail.com
Wed Feb 3 08:48:01 UTC 2016


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.


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.

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?

Do not know what Apple policy is for that - and for such grey areas, the
only way to know is to submit and then see if it goes through (and even
there it's highly subjective, depends on the approver, approver's mood on
that day, etc).



Be Awesome,

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

On Wed, Feb 3, 2016 at 1:54 PM, Holger Kaelberer <hk at elberer.de> wrote:

>
>
> On 02.02.2016 23:11, Bruno Coudoin wrote:
>
>>
>>
>> Le 02/02/2016 22:45, Karl Ove Hufthammer a écrit :
>>
>>> Bruno Coudoin skreiv 02. feb. 2016 22:07:
>>>
>>>>
>>>> For the 24.3 they don't like our web links in our about box. We already
>>>> remove them when compiled
>>>> in 'no download mode'. But I agree we Apple that it is not a good idea
>>>> to let a children 'escape'
>>>> GCompris and get on the Internet just by clicking a link in GCompris.
>>>> Even if our target links
>>>> are fine, once in a browser you don't know what will happens. I propose
>>>> to remove all web links
>>>> all together on all platforms.
>>>>
>>>
>>> I don’t agree with the proposal to remove all Web links on all
>>> platforms. It’s useful to have the
>>> Web links to Wikipedia in various activities. But it would be OK to
>>> (automatically) *disable* the
>>> links (i.e. make them non-clickable URLs) on *the iOS platform*, but
>>> leave them as normal links on
>>> other platforms.
>>>
>>
>> Hum, we have to weight the pro and cons. Starting a web browser from
>> GCompris when a teacher or a
>> parent consider the children in a walled garden is too dangerous. We
>> still display links and it is
>> not so hard to find them in most cases.
>>
>> One trade of we can do it that a link click would copy itself to the
>> clipboard with a little tooltip
>> explaining that. Then if the children has access to a browser he just
>> have to paste it. You like it?
>>
>
> Another possibility would be to make behaviour configurable. To let a
> potential teacher decide whether he does *not* want children to inform
> themselves further by following http links. And leave default to "yes, you
> can use the web to learn more".
>
> I agree with Karl that external links that serve to learn more are a good
> thing to have.
>
> In general I don't like the idea to change overall behaviour on all
> platforms just because of the policy of a commercial vendor (of apples, or
> robots). (I see your concerns in this point of course, Bruno.) If apples
> are different from the rest of the fruits make an exception for them.
>
> Regarding download location, DataLocation fits semantically imho better
> than CacheLocation for GCompris data. And if this shall be changed again
> GCompris should probably again take care to clean up the old location (as
> was done when switching from data/ to data2/) or we annoy users by wasting
> space. Why not make an exception here for apples?
>
> Holger
> _______________________________________________
> 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/09ad52ea/attachment.html>


More information about the GCompris-devel mailing list