Quand on programme une interface graphique, pour la plupart des langages, un élément de l'interface est une "vue".
Rassurez-vous, vous les connaissez déjà !
Dans notre projet créé au chapitre précédent, cliquez sur Main.storyboard dans le volet de gauche. Laissez-lui le temps de charger, vous devriez arriver sur la même image que moi.
Les vues peuvent être de différentes formes : dans vos applis, vous verrez des boutons, des champs de texte, des images, des fenêtres de dialogue… Tous ces éléments sont des vues.
Mais alors, où sont placées les vues? Il doit bien y avoir un conteneur pour tous ces éléments…
Et bien oui ! Et ce conteneur, c'est … une vue aussi ! Les vues peuvent être placées les unes dans les autres. Cette vue "mère", celle qui contient toutes les autres est attachée à un "controller". Pour faire simple, dans une application bien construite, les controller sont les différentes pages de l'appli. Ce n'est pas toujours le cas, c'est le développeur qui choisit comment structurer son appli.
Un gros avantage avec Xcode : l'interface builder qui nous permet de visualiser l'aspect de notre application avant même de la lancer. Il permet aussi de disposer les vues précisément sur l'écran.
Vous vous rappelez de ce cadre, au milieu, que l'on a vu au chapitre précédent ? Maintenant regardez dans le volet de droite, tout en bas. Vous voyez la barre de recherche, tapez "button", faites un glisser déposer... et bingo, votre application contient un bouton ! Si vous ne me croyez pas, cliquez sur ce bouton pour lancer l'appli.
Les propriétés d'une UIView
Vous avez suivi le cours d'initiation à Swift donc vous savez ce qu'est l'héritage. Toutes les vues que nous allons voir héritent de la vue de base "UIView". Sélectionnez le bouton et regardez le volet de droite. Cliquez sur le 4e onglet en partant de la gauche (attributes inspector). Vous observez les attributs du bouton. Descendez, vous voyez les attributs de "Control" (de la classe UIControl) et enfin, les attributs de "View" (de la classe UIView). Sans même regarder la doc, vous savez déjà que la classe UIButton
hérite de UIControl
qui hérite de UIView
.
On peut donc changer les attributs de base comme le fond, l'opacité, la visibilité mais également des attributs spécifiques aux boutons, la police et même des images (une pour le fond et une alignée avec le texte).
Plus de vues…
Retournez en bas à droite et tapez "label", qui permet de créer un élément pour afficher du texte. Comme les autres, la classe UILabel
hérite de UIView
(vous pouvez également le voir dans l'attributes inspector).
Ajoutez ensuite :
Un autre label qui donne la consigne, ici : "4 + 4 ="
Un text field qui permettra à l'utilisateur d'entrer le résultat qu'il souhaite.
Un bouton qui affichera : "Did I win?"
Et voilà une application qui propose un exercice à l'utilisateur. Bien sûr, on écrira notre code par la suite pour vérifier la solution entrée par l'utilisateur.
Les controller
Un petit mot sur les controller : on les utilise souvent pour gérer les différentes pages de notre application. Effacez votre texte dans la recherche en bas à droite, et faites un glisser-déposer du premier élément de la liste.
Les controllers ne sont pas des vues. Leur classe est UIViewController et par défaut, une vue leur est attachée. C'est cette vue qui va contenir toutes les autres (comme par exemple les éléments que nous avons ajoutés juste avant).
Un controller est souvent attribué à une classe particulière. Si vous cliquez sur notre premier controller, puis sur le 3e onglet dans le volet de droite , vous remarquez que la classe lui a été attribuée automatiquement par Xcode à la création du projet. Ce controller est de classe ViewController
(Attention, pas de classe UIViewController
).
Dans le volet de gauche, on voit le fichier "ViewController.swift". Ce n'est pas une coïncidence, Xcode a déjà créé notre premier controller et lui a attribué une classe particulière (ViewController) pour nous éviter de créer les différents éléments nous-mêmes.
Par contre, notre fichier swift s'appelle toujours "ViewController.swift". En général, on préfère avoir un fichier par classe ; le nom de ce fichier est le nom de la classe qu'il contient. On va donc le renommer "Exercice.swift". Cela permet d'avoir un code découpé, et donc beaucoup plus clair à la lecture.
Parlons maintenant de design.