KFileMetaData and API level requirement

[Matthieu Gallien]

Le 18 mai 2017 02:11, "Aleix Pol" <aleixpol at kde.org> a écrit :

On Wed, May 17, 2017 at 9:57 PM, Matthieu Gallien
<gallien.matthieu at gmail.com> wrote:
> Hello,
>
> As a follow up of a discussion on android list, I would like to gather
some
> comments or point of views about the following dilemma.
> Currently, the mandatory parts of KFileMetaData compile for Android using
API
> level 21 (Android 5.0). The class UserMetaData is relying on extended
> attributes supported ony starting with API level 21.
> My own phone is Android 4.4 (API level 20). I am wondering if making the
class
> UserMetaData be optional (currently part of the ABI) is a good idea. I
could
> ensure it is only optional on Android as a way to not break the ABI.
>
> According to Google (https://developer.android.com/about/dashboards/
> index.html) its still 18.8 % of the phones.
>
> Any advice, comments, ... ?
>
> Thanks in advance
>
> Best regards

Hi Matthieu,
At the moment we don't have a global KDE policy WRT which Android API
level our frameworks and applications are going to require. I'd say
that it's fine that an application can require N because a framework
requires N.

The fact that you have a phone that doesn't support the framework you
want to use is unfortunate, although it seems a bit odd to leave a
whole class out because of that. I'd say that it's a positive feature
that if an application is ported to Android, the same features are
still available.


Yes, I agree in general. In this case, I am not sure. For example, the
ratings will not be interoperable on Windows if they are stored in the
current way (an extended attribute called user.baloo.rating).
In a sense, we pretend it is working even though a rating made in Windows
explorer will not be read by the library. The opposite is also not working.

I should maybe just improve the documentation with respect to that.


A compromise could be to introduce a dummy implementation of the class
in case the feature we require currently isn't available.

HTH,
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170518/a6268f28/attachment.html>