Autorisations des applications QML

De nombreuses fonctionnalités des appareils et systèmes d'exploitation actuels peuvent avoir des implications importantes en matière de confidentialité, de sécurité et de performances si elles sont utilisées à mauvais escient. Il est donc de plus en plus courant que les plateformes exigent le consentement explicite de l'utilisateur avant d'accéder à ces fonctionnalités.

Le Qt Qml Core module expose les fonctionnalités des autorisations d'application Qt C++ à Qml via un ensemble de types d'autorisation pouvant être utilisés pour vérifier ou demander une autorisation de 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 autorisations, 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 à l’autorisation s’afficheront en superposition si l’autorisation n’est pas accordée. L’interface utilisateur de demande pourrait par exemple 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 de refus correspondante :

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 autorisation peuvent être modifiées, même après le lancement d’une requête via l’appel de `request()`. Cela mettra à jour le statut si celui-ci change en raison des nouvelles valeurs des propriétés, mais n’entraînera pas de requête 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 plateforme réagira de l’une des trois façons suivantes :

• En accordant implicitement l’autorisation étendue, par exemple parce que la plateforme ne fait pas la distinction entre les deux modes d’accès, ce qui n’entraînera aucun changement d’état.
• En ramenant le statut à « Indéterminé », afin que l’utilisateur puisse être à nouveau consulté pour l’accès à l’autorisation désormais étendue.
• En faisant passer le statut à « Denied », par exemple si les autorisations ne peuvent pas être étendues une fois la demande initiale effectuée.

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

Interaction entre les éléments d’autorisation

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é séparément 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 ceux-ci présentent exactement les mêmes propriétés.