L'optimisation des distractions (DO) est fournie comme un outil permettant de réduire l'interaction du conducteur avec l'application Paramètres pendant qu'une voiture roule. Certains paramètres devront peut-être être modifiés pendant la conduite afin que l'application ne soit pas complètement bloquée. Cependant, par défaut, la plupart des préférences sont désactivées et seules les préférences clés et facilement mises à jour sont activées.
Figure 1. Applications activées pendant la conduite
Des activités entières peuvent également être bloquées si elles ne sont pas optimisées pour les distractions, comme indiqué ci-dessous. Cette méthode est actuellement utilisée principalement pour la recherche de paramètres.
Figure 2. Toutes les activités bloquées
Des personnalisations de base des performances de DO peuvent être effectuées via des superpositions de configuration. Si vous avez besoin d'une personnalisation plus fine, des modifications supplémentaires peuvent être apportées via le code.
Personnalisation de haut niveau
Lorsqu'une préférence est désactivée pendant la conduite, appuyer dessus affiche un message toast indiquant que la préférence n'est pas disponible pendant la conduite, à condition qu'un contrôleur de préférence soit associé à la préférence. Le message utilise la chaîne restricted_while_driving , qui peut être personnalisée avec une superposition (à condition que la chaîne soit inférieure à la limite de 60 caractères).
Figure 3. Superposition personnalisée
L'ensemble du framework DO peut être désactivé en utilisant config_always_ignore_ux_restrictions . Définir cela sur true signifie que le pilote peut interagir avec tous les aspects de l'application Paramètres.
<bool name="config_always_ignore_ux_restrictions">true</bool>
Si la configuration ci-dessus est définie sur false, l'application Paramètres revient à config_ignore_ux_restrictions pour déterminer quelles préférences doivent être activées pendant la conduite. Les chaînes fournies ici doivent pointer vers les chaînes définies dans preference_keys.xml.
Exemple
Pour montrer comment activer un paramètre profondément imbriqué pendant la conduite, cet exemple montre comment activer les paramètres de sortie Text-to-Speech (TTS). Pour que cela fonctionne, ajoutez tous les paramètres de la hiérarchie à config_ignore_ux_restrictions . Cela inclut le système, les langues et la saisie, ainsi que les préférences TTS pour la configuration, puisque notre hiérarchie est Système-> Langues et saisie-> Sortie de synthèse vocale. Cependant, les préférences dans le fragment de synthèse vocale sont toujours désactivées. Pour les activer, nous devons ajouter les clés des préférences que nous souhaitons rendre accessibles. Dans cet exemple, nous souhaitons activer les préférences de lecture mais pas les préférences du moteur, nous ajoutons donc pk_tts_playback_group à notre configuration.
<string-array name="config_ignore_ux_restrictions">
[...]
<item>@string/pk_system_settings_entry</item>
<item>@string/pk_languages_and_input_settings</item>
<item>@string/pk_tts_settings_entry</item>
<item>@string/pk_tts_playback_group</item>
</string-array>
Personnalisation détaillée
Certaines préférences peuvent nécessiter un comportement plus personnalisé que la simple activation/désactivation d'une préférence basée sur l'état de conduite. Par exemple, Bluetooth et Wi-Fi ont déjà été modifiés pour afficher les appareils Bluetooth enregistrés ou les points d'accès Wi-Fi pendant la conduite.
Il n’existe actuellement aucune solution basée sur la configuration pour effectuer ce type d’ajustements. Au lieu de cela, vous pouvez créer une classe personnalisée qui étend PreferenceController et remplace onApplyUxRestrictions() pour apporter les modifications souhaitées.
Lorsqu'un contrôleur de préférences personnalisé est créé, vous pouvez superposer le fichier XML approprié pour remplacer le contrôleur de préférences par défaut par votre propre implémentation.
Exemples
Dans CarSettings, certaines préférences ont ce comportement plus personnalisé, qui peut être utilisé comme exemple pour une personnalisation supplémentaire. Par exemple, dans la liste des points d'accès Wi-Fi , le comportement souhaité est d'afficher uniquement les points d'accès enregistrés pendant la conduite (et de masquer le reste). Pour y parvenir, procédez comme suit :
mAccessPoints = CarUxRestrictionsHelper.isNoSetup(getUxRestrictions())
? getCarWifiManager().getSavedAccessPoints()
: getCarWifiManager().getAllAccessPoints();
Étant donné que les points d'accès qui apparaissent ici sont déjà restreints, vous ne souhaitez pas appliquer UxRestrictions supplémentaires à ces préférences. Par conséquent, remplacez onApplyUxRestrictions et effectuez une opération intentionnelle :
@Override
protected void onApplyUxRestrictions(CarUxRestrictions uxRestrictions) {
// Since the list dynamically changes based on the UX restrictions, we
// enable this fragment regardless of the restriction. Intentional no-op.
}
Un autre exemple est fourni dans les appareils liés à Bluetooth . Continuer à permettre la connexion et la déconnexion des appareils Bluetooth, mais je souhaitais désactiver la possibilité d'accéder à des paramètres supplémentaires pour ces appareils. Pour y parvenir, nous remplaçons à nouveau onApplyUxRestrictions mais cette fois, si la restriction NO_SETUP est active, nous masquons l'action secondaire sur la préférence.
@Override
protected void onApplyUxRestrictions(CarUxRestrictions uxRestrictions) {
super.onApplyUxRestrictions(uxRestrictions);
if (CarUxRestrictionsHelper.isNoSetup(uxRestrictions)) {
updateActionVisibility(getPreference(), /* isActionVisible= */ false);
}
}