Generation du code UI Android. Partie 2

Transcription

1 Objectifs Generation du code UI Android Partie 2 Author : Cedric Dumoulin Date : 22 nov Rev : 7 Nov Nous voulons générer le code de la UI Android. Dans ce TP nous allons améliorer le métamodèle et la génération de code développé dans la partie 1. Dans la première partie, vous avez proposé un langage (métamodèle) pour construire des UI Android, et vous avez développé le générateur de code permettant au moins de générer le fichier layout.xml correspondant. La solution proposée dans la partie 1 présente des inconvénients : Le métamodèle (langage) proposé est souvent une pâle copie du langage proposé en XML et Java La génération de code ne génère pas les classes Activity associé au Layout. Dans ce TP, nous allons essayer de proposer un langage de plus haut niveau, offrant plus de possibilité que le langage Android. De plus, nous allons générer les classes Activity associé à une page. Améliorer le langage proposé Le langage proposé doit offrir plus de possibilité que le langage xml de Android. Ce ne doit pas être une simple transcription du langage proposé par Android. Voici quelques améliorations que l'on peut apporter : Séparation clair entre la définition de la UI, du contrôleur (Activity), et de l'association UI<->contrôleur Pour une UI, séparation clair entre son contenu, et le layout Une UI peut se définir par assemblage de "morceaux de UIs" Un morceau de UI peut être utilisé dans différents assemblages Une UI peut être réutilisé dans différents contrôleurs Association simple entre un élément de la UI (ex: EditText) et la propriété de la classe du domaine (ex: Person.name) qui doit être rendu par l'élément. Les améliorations suivantes, plus complexes à mettre en œuvre, peuvent aussi être envisagées : Permettre l'héritage dans la définition des UI ou des contrôleurs Association entre une collection du domaine (ex: une collection d'adresses) et la UI permettant d'afficher un élément de la collection. Générer les différentes variantes (en taille et orientation) des UI

2 ... Séparation UI, Contrôleur, Association Notre langage doit permettre de modéliser à l'aide de concepts clairement séparé (mais dans le même MM): La UI - Ici on ne modélise que le contenu de la UI et son layout. Le Contrôleur - Il correspond aux Activity Android. Il permet de spécifier: o la UI associé, o des méthodes existantes dans le contrôleur o les associations avec la UI L'association UI<->Contrôleur - une association représente un lien entre le contrôleur et un élément graphique de la UI, ou entre un élement graphique et un élément du domaine. Ce sont par exemple: o l'association entre un évenement pouvant survenir dans la UI et son handler dans le controleur o l'association entre un élément graphique et la propriété du domaine dont la valeur est rendu par l'élément graphique o... Pour pouvoir facilement réutiliser la UI, la couche UI ne doit pas connaitre la couche contrôleur. Séparation contenu UI et Layout Cela ce fait facilement en utilisant le pattern décorateur. Un élément de la UI à une propriété 'Layout'. Ainsi, l'élément UI se définit séparément de son Layout. De plus, on peut facilement changer le type de Layout. Notez toutefois qu'un élément de UI contient deux informations de Layout différentes:

3 l'information de Layout indiquant comment ses enfants sont placés. Cette information n'est nécessaire que dans les élément acceptant des enfants. l'information de Layout indiquant comment cet élément est rendu dans son parent Il semble préférable de séparer clairement ces deux informations (deux propriétés différentes dans l'élément UI). Construction de UI par assemblage Pour pouvoir construire une UI par assemblage, il faut savoir comment "décomposer" une UI. Une UI est composé de composants qui sont assemblé dans des groupes. Un composant peut être un composant élémentaire (bouton, text,...) ou un groupe de composants. Réutilisation de composants UI Pour pouvoir réutiliser des composants, il faut pouvoir séparer la déclaration du composant et son utilisation. Vous pouvez faire le parallèle avec la déclaration d'une classe Java, et son utilisation pour déclarer une propriété. Nous voulons faire quelque chose de similaire: pouvoir déclarer un composant UI, et pouvoir l'utiliser pour construire d'autre UI. Il faut donc être capable de : déclarer plusieurs composants UI indépendants utiliser ces composants pour construire des composants plus complexe.

4 Utilisation d'une UI dans différent contrôleur Cela se fait simplement en permettant de spécifier dans le contrôleur la UI utilisée. Association UI-contrôleur Nous avons d'un coté les déclaration de UI, et de l'autre des contrôleurs. Il faut être capable d'associer les deux, et de faire des liens entre les éléments de la UI et les méthodes du contrôleur ou les propriétés des classes du domaine. Le métamodèle/langage doit permettre de déclarer ces différentes associations. Pour des raisons de simplification, la déclaration des associations peut se faire dans le contrôleur. Modifier le métamodèle Il faut modifier le métamodèle de notre langage afin de prendre en compte les nouvelles possibilités. Attention, les solutions proposées ne sont que des ébauches de solution. Elles doivent être adaptées au but. Générer le code Le fichier xml contient : l'ensemble des éléments graphique à afficher Le layout de ces éléments graphiques Chaque élément peut spécifier quelle méthode doit être appelée quand un événement particulier se produit (onclick) autre... (voir doc) Une activity contient : La déclaration du fichier xml associé Les méthodes appelées par les éléments graphique Handlers sur les événements survenant dans la UI

5 Il faut planifier les règles de génération. Une règle de génération explique ce qui doit être généré à partir de quels éléments du métamodèle. Commencer par identifier et expliquer vos règles de génération, puis implémentez-les dans les templates. Générer plusieurs fichiers dans un projet Acceleo permet facilement de générer plusieurs fichiers dans un même projet Eclipse. Votre template main utilise plusieurs instructions [file], chacune générant son propre fichier. Lorsque vous spécifiez le nom du fichier, vous pouvez le préfixer par le nom du repertoire. Une bonne pratique est de préfixer le nom du fichier par le répertoire exacte dans lequel il doit être géneré par rapport au projet. Ainsi, vous pourrez générer vos fichiers aux emplacement requis en spécifiant seulement la racine du projet dans lequel ils doivent être généré.