Le 18 mai 2017 02:11, "Aleix Pol" <aleix...@kde.org> a écrit :
On Wed, May 17, 2017 at 9:57 PM, Matthieu Gallien <gallien.matth...@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
