KService as a platform abstraction framework?
Volker Krause
vkrause at kde.org
Sat Jul 3 09:25:12 BST 2021
Hi,
while looking at implementing a pretty straightforward KApplicationTrader/
KIO::ApplicationLauncherJob use ([1]) for Android, I found myself wondering
whether we should have an Android backend for KService.
KService conceptually matches android.content.pm.PackageManager/PackageInfo
[2, 3], ie. the platform API to list installed applications and their
respective features (essentially what's in the Android manifest XML files). In
detail it however is full of .desktop file specifics, and leaks platform
implementation details (e.g. KService inheriting from sycoca types).
KIO::ApplicationLauncherJob is also something that makes sense conceptually on
Android, implemented on top of Intents there.
Has anyone thought about/looked into using KService as platform abstraction
rather than as an functional/platform implementation framework already? I
could imagine this to also be relevant on Windows.
Is anyone aware of a current use on Android relying on the .desktop based
implementation of KService? That might be theoretically possible, unlike for
ApplicationLauncherJob.
And while retrofitting platform abstraction support into KService wont be
pretty, the alternative approaches (a new abstraction framework on top, or let
applications deal with that with platform-specific code paths) aren't exactly
convincing either.
Thoughts?
Thanks,
Volker
[1] https://invent.kde.org/plasma-mobile/qrca/-/merge_requests/35
[2] https://developer.android.com/reference/android/content/pm/PackageManager
[3] https://developer.android.com/reference/android/content/pm/PackageInfo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20210703/cbc0eb15/attachment.sig>
More information about the KDE-Android
mailing list