Permissions pour les applications QML

De nombreuses fonctionnalités des appareils et systèmes d'exploitation actuels peuvent avoir des conséquences importantes sur la vie privée, la sécurité et les performances en cas d'utilisation abusive. C'est pourquoi il est de plus en plus fréquent que les plateformes exigent le consentement explicite de l'utilisateur avant d'accéder à ces fonctionnalités.

Qt Qml Le module Qt Core expose la fonctionnalité Qt C++ Application Permissions à QML par le biais d'un ensemble de types de permission qui peuvent être utilisés pour vérifier ou demander une permission d'une manière multiplateforme.

Utilisation

Pour vérifier et demander une autorisation spécifique dans votre application, incluez une instance du type d'autorisation approprié et définissez ses propriétés si nécessaire :

CalendarPermission {
    id: calendarPermission
    accessMode: CalendarPermission.ReadWrite
}

Le type peut être utilisé pour vérifier l'état actuel des permissions, par exemple pour piloter une interface utilisateur basée sur l'état :

states: [
    State {
        name: "waitingForPermission"
        when: calendarPermission.status == Qt.PermissionStatus.Undetermined
        PropertyChanges { target: permissionRequestItem; visible: true }
    },
    State {
        name: "permissionDenied"
        when: calendarPermission.status == Qt.PermissionStatus.Denied
        PropertyChanges { target: permissionDeniedItem; visible: true }
    }
]

Dans l'exemple ci-dessus, deux éléments spécifiques à la permission seront superposés si l'état de la permission n'est pas accordé. L'interface utilisateur de la demande pourrait ressembler à ceci :

Rectangle {
    id: permissionRequestItem
    anchors.fill: parent
    visible: false

    Text {
        anchors.centerIn: parent
        text: qsTr("We need your permission to access the calendar."
            + "Please tap this screen to request permission.")

    }

    MouseArea {
        anchors.fill: parent
        onClicked: calendarPermission.request()
    }
}

Avec une interface utilisateur correspondante pour les autorisations refusées :

Rectangle {
    id: permissionDeniedItem
    anchors.fill: parent
    color: "red"
    visible: false
    Text {
        anchors.centerIn: parent
        text: qsTr("We need your permission to access the calendar,"
            + "but permission was not granted. Please resolve.")
    }
}

Modification des propriétés d'une autorisation

Les propriétés d'une permission peuvent être modifiées, même après qu'une requête ait été initiée, en appelant `request()`. Cela mettra à jour le statut, s'il change suite aux nouvelles valeurs des propriétés, mais n'entraînera pas de demande automatique utilisant le nouvel ensemble de propriétés.

Par exemple, si l'on met à niveau une autorisation de calendrier déjà accordée pour le mode d'accès Qt.CalendarPermission.ReadOnly vers Qt.CalendarPermission.ReadWrite, la plate-forme répondra de trois manières différentes :

• En accordant implicitement l'autorisation étendue, par exemple parce que la plate-forme ne fait pas de distinction entre les deux modes d'accès, ce qui n'entraînera aucun changement d'état.
• En ramenant le statut à Indéterminé, de sorte que l'utilisateur puisse être consulté à nouveau pour accéder à l'autorisation désormais étendue.
• En déplaçant le statut vers Denied, par exemple si les autorisations ne peuvent pas être améliorées une fois qu'elles ont été demandées initialement.

Tous ces états doivent alors faire passer l'interface utilisateur de l'application à l'état approprié, où l'utilisateur est informé du nouvel état, avec la possibilité de demander la nouvelle autorisation si possible, ou de revenir à une autorisation moins étendue.

Interaction entre les éléments de permission

Bien que l'état des autorisations soit en fin de compte lié à l'application sous-jacente, chaque élément d'autorisation signale son propre état indépendamment de tous les autres éléments et doit être demandé indépendamment si nécessaire.

Par exemple, demander l'accès au calendrier pour un élément ne mettra pas à jour l'état d'un autre élément CalendarPermission, même si ces éléments ont exactement les mêmes propriétés.