Trouver les actions possibles grâce à l’introspection

Trouver les actions possibles grâce à l’introspection

Préférez-vous le menu ?

Un autre moyen d’autoriser l’utilisateur à effectuer des actions sur un contenu, sans savoir à l’avance quelles sont les actions possibles, consiste à injecter un ensemble de choix dans le menu de l’application, en appelant addIntentOptions(). Cette méthode prend en paramètre une intention et remplit un ensemble de choix de l’instance Menu sur laquelle elle est appelée, chacun de ces choix représentant une action possible. Sélectionner l’un de ces choix lancera l’activité associée. Dans l’exemple précédent, le contenu, dont nous ne savions rien, provenait d’une autre application Android. Ceci dit, nous pouvons aussi savoir parfaitement quel est ce contenu, lorsque c’est le nôtre. Cependant, les applications Android étant tout à fait capables d’ajouter de nouvelles actions à des types de contenus existants, les utilisateurs auront peut-être d’autres possibilités que l’on ne connaît pas encore, même si l’on écrit une application en s’attendant à un certain traitement du contenu. Revenons, par exemple, au sous-système de marquage évoqué au début de ce chapitre. Il serait très ennuyeux pour les utilisateurs de devoir faire appel à un outil de marquage séparé pour choisir un marqueur, puis revenir au contenu sur lequel ils travaillaient afin de lui associer le marqueur choisi. Ils préféreraient sûrement disposer d’une option dans le menu « Home » de l’activité leur permettant d’indiquer qu’ils veulent effectuer un marquage, ce qui les mènerait à une activité de configuration du marqueur, qui saurait déjà le contenu qui doit être marqué. Pour ce faire, le sous-système de marquage doit configurer un filtre d’intention supportant n’importe quel contenu avec sa propre action (ACTION_TAG, par exemple) et avec la catégorie CATEGORY_ALTERNATIVE, ce qui est la convention lorsqu’une application ajoute des actions au contenu d’une autre. Pour écrire des activités qui seront prévenues des ajouts possibles, comme le marquage, faites appel à addIntentOptions() pour ajouter les actions de ces ajouts à votre menu, comme ici : Intent intent = new Intent(null, monUri); intent.addCategory(Intent.ALTERNATIVE_CATEGORY); menu.addIntentOptions(Menu.ALTERNATIVE, 0, new ComponentName(this, MonActivite.class), null, intent, 0, null); Ici, monUri est une Uri décrivant le contenu qui sera affiché par l’utilisateur dans cette activité. MonActivite est le nom de la classe de l’activité et menu, le menu à modifier. Dans notre cas, l’intention que l’on utilise pour choisir les actions exige que les récepteurs d’intention appropriés reconnaissent la catégorie CATEGORY_ALTERNATIVE. Puis nous d ajoutons les options au menu avec la méthode addIntentOptions(), à laquelle nous passons les paramètres suivants : ● La position de tri pour cet ensemble de choix. Cette valeur est généralement 0 (pour que l’ensemble apparaisse dans l’ordre où il est ajouté au menu) ou ALTERNATIVE (pour qu’il apparaisse après les autres choix du menu). ● Un nombre unique pour cet ensemble de choix ou 0 si l’on n’a pas besoin de ce nombre. ● Une instance de ComponentName représentant l’activité qui remplit son menu – elle sert à filtrer les propres actions de l’activité, afin qu’elle puisse les traiter comme elle le souhaite. ● Un tableau d’instances d’Intent, contenant les correspondances « spécifiques » – toutes les actions correspondant à ces Intent s’afficheront dans le menu avant les autres actions possibles. ● L’intention pour laquelle vous voulez les actions disponibles. ● Un ensemble d’indicateurs. Le seul réellement pertinent est représenté par MATCH_DEFAULT_ONLY, qui indique que les actions qui correspondent doivent également implémenter la catégorie DEFAULT_CATEGORY. Si l’on n’a pas besoin de cette information, il suffit d’utiliser la valeur 0 pour ces indicateurs. ● Un tableau de Menu.Items qui contiendra les éléments de menu qui correspondent au tableau des instances Intent spécifiques fourni en quatrième paramètre, ou null si l’on n’utilise pas ces éléments.

Demander à l’entourage

Les familles ActivityAdapter et addIntentOptions() utilisent toutes les deux la méthode queryIntentActivityOptions() pour rechercher les actions possibles. queryIntentActivityOptions() est implémentée dans PackageManager : pour obtenir une instance de cette classe, servez-vous de la méthode getPackageManager(). La méthode queryIntentActivityOptions() prend certains des paramètres d’addIntentOptions(), notamment le ComponentName de l’appelant, le tableau des instances d’Intent « spécifiques », l’Intent générale représentant les actions que vous recherchez et l’ensemble des indicateurs. Elle renvoie une liste d’instances d’Intent correspondant aux critères indiqués, les Intent spécifiques en premier. Pour offrir des actions alternatives aux utilisateurs par un autre moyen qu’addIntentOptions(), vous pouvez appeler queryIntentActivityOptions(), obtenir les instances d’Intent et les utiliser pour remplir une autre interface utilisateur (une barre d’outils, par exemple).  Gestion de la rotation Certains terminaux Android, comme le G1 de T-Mobile, disposent d’un clavier « à tiroir » qui, lorsqu’il est sorti, provoque le passage de l’écran du mode portrait au mode paysage. D’autres, comme l’iPhone, utilisent des accéléromètres pour déterminer l’orientation de l’écran. Android fournit plusieurs moyens de gérer la rotation de l’écran afin que vos applications puissent elles-mêmes traiter correctement les deux orientations. Ces outils vous aident simplement à détecter et à gérer le processus de rotation – c’est à vous de vérifier que vos interfaces utilisateurs apparaîtront correctement dans les deux orientations. Philosophie de la destruction Par défaut, lorsqu’une modification dans la configuration du téléphone risque d’affecter la sélection des ressources, Android supprimera et recréera toutes les activités en cours d’exécution ou en pause la prochaine fois qu’elles seront affichées. Bien que ce phénomène puisse avoir lieu pour un grand nombre de modifications de configuration (changement de la langue, par exemple), il interviendra surtout dans le cas des rotations, car un pivotement de l’écran force le chargement d’un nouvel ensemble de ressources (les fichiers de description, notamment). Il faut bien comprendre qu’il s’agit du comportement par défaut : il peut être le plus adapté à l’une ou l’autre de vos activités, mais vous pouvez le contrôler et adapter la réponse de vos activités aux changements d’orientation ou de configuration. Tout est pareil, juste différent Comme, par défaut, Android détruit et récrée votre activité lorsque l’orientation change, il suffit d’utiliser la méthode onSaveInstanceState(), qui est appelée à chaque fois que l’activité est supprimée quelle qu’en soit la raison (tel un manque de mémoire). Implémentez cette méthode dans votre activité afin de stocker dans le Bundle fourni suffisamment d’informations pour pouvoir revenir à l’état courant. Puis, dans onCreate() (ou onRestore-InstanceState(), si vous préférez), restaurez les données du Bundle et utilisez-les pour remettre l’activité dans son état antérieur. Le projet Rotation/RotationOne, par exemple, utilise deux fichiers layout main.xml pour les modes portrait et paysage. Ces fichiers se trouvent respectivement dans les répertoires res/layout/ et res/layout-land/. Voici la disposition du mode portrait : Voici celle du mode paysage : Chapitre 26 Gestion de la rotation 267 android:layout_height= »fill_parent » >