Structure d'une application IOS

Maintenant que nous avons créé notre projet, nous arrivons sur cette page :

Nous allons donc nous concentrer sur la barre latérale gauche.

Déterminons ensemble les différents documents et les différents fichiers présents dès la création du projet.

Cette ligne est votre projet, elle contient absolument tous les documents de votre application. Peu importe sa structure, peu importe son architecture, tout le contenu de votre projet sera dans cette ligne dépliable.

Xcode permet d'arborer les fichiers nécessaires, mais en réalité, si on explorait le projet dans le finder, de très nombreux fichiers seraient présents, mais ne seraient d'aucune utilité pour nous car ils servent à la compilation ou à d'autres processus qui ne nous sont pas dédiés.

Le premier fichier que nous voyons lorsque nous lançons notre projet est l'AppDelegate.swift.

Il permet de faire la jonction entre iOS et votre application, notamment pour l'utilisation de fonctionnalités système ou autre.

Prenons la version 12 de Xcode :

La première chose à prendre en compte est l'appel des classes UIResponder et UIApplicationDelegate, qui sont deux classes permettant la communication entre une application et iOS ou un autre système d'exploitation Apple.

Nous allons rajouter la fonction :

Cette fonction aura pour but, par exemple, lors de la fermeture de l'application, d'indiquer à iOS qu'il faut rentrer cette dernière en utilisation en arrière-plan.

Toutes ces options utilisant des fonctionnalités d'iOS seront donc dans l'AppDelegate.

Lorsque vous faites une application sur iOS, elle est compatible ensuite avec iPadOS.

Une des nouveautés d'iPadOS 13 était l'arrivée des scènes.

Qu'appelle-t-on les scènes ?

Les scènes permettent de simuler deux instances lancées de la même application. Alors qu'il n'en est en réalité rien.

Sur cette capture d'écran, nous pourrions penser que 3 instances de Safari sont lancées sur iOS alors qu'il n'en existe en réalité qu'une, régie par le SceneDelegate.

Les fichiers en storyboard permettent d'éditer visuellement l'interface de votre application par l'Interface Builder.

Vous aurez la possibilité d'ajouter de nombreux éléments reprenant le design que vous aurez mis en place au préalable pendant la création de l'UX et l'UI de votre application.

Sur cette interface, vous aurez donc la possibilité d'intégrer des éléments tels que :

• Des labels ;

• Des boutons ;

• Des DatePicker ;

• Des slider ;

• Des Switch ;

• Etc.

Chaque élément sera relié sur le code et créera un @IBOutlet ou un @IBAction permettant de donner une logique à l'élément que vous avez mis en place.

Le LaunchScreen Storyboard permet l'édition de la première image aperçue lorsque vous lancez l'application.

Par exemple, regardons le Launch Screen de l'Application « Facebook » :

Voici ce que cela donnerait sur l'Interface Builder :

Au moment du lancement de mon application, cette image serait créée. Pour vous le démontrer, nous allons rajouter un label « STUDI » sur le Launch Screen.storyboard et nous capturons le lancement de l'application :

En réalité, le procédé est relativement simple car le storyboard, lors de sa transcription en code, est en XML. l'iPhone interprète alors le XML pour afficher toutes les informations souhaitées.

Et c'est à ce moment que nous comprenons aussi le passage et la révolution de SwiftUI, qui fait passer toute la gestion des interfaces utilisateur d'iOS, macOS, etc., d'une interface en XML passée en Swift.

Lorsque nous parlons de l'architecture d'une application mobile, nous faisons allusion aux Contrôleurs, aux vues, aux modèles, etc.

Dans notre cas, la ViewController est une classe, dans laquelle sont intégrés des objets, des fonctions, des variables, des constantes.

Lorsque nous sommes sur l'interface Builder par exemple, chaque vue que nous avons pu remarquer doit être liée à une classe. Nous aurons ensuite la possibilité de créer autant de vues que de classes.

Lorsque que nous arrivons sur la première ViewController.swift, voici ce qui est présenté :

Décomposons ensemble ce petit morceau de code :

Cela signifie que nous importons la librairie UIKit. Si nous avions utilisé une autre librairie telle que SwiftUI, nous aurions remplacé UIKit par SwiftUI.

Ce morceau de code donne toutes les déclarations nécessaires au bon fonctionnement de la classe. Il est composé de :

Ceci signifie que nous déclarons une classe que nous appellerons ViewController.

Ceci signifie que notre classe est de type UIViewController.

Dans cette classe, par défaut, il existe une fonction qui se nomme .

Elle permet, au moment du chargement du contrôleur effectué, de lancer du code en priorité sur toutes les autres fonctions qui seront demandées.

Le Assets.xcassets est la librairie de votre projet. C'est dans cette librairie que vous retrouverez toutes les images nécessaires à votre application.

Lorsque vous appelez un UIImageView sur votre Interface Builder par exemple, l'Interface Builder va directement chercher dans les images disponibles dans le assets.xcassets.

Dans la capture d'écran ci-dessus, vous trouverez les deux images que nous avons utilisées pour réaliser notre Launch Screen, mais vous aurez également le template pour pointer toutes les App Icon de votre projet.

Il y a autant de possibilités qu'il y a d'écrans différents sur les appareils Apple.

Quand l'écran d'un iPhone 12 aura 458 Pixels par pouce, l'iPad Air aura 264 Pixels par pouce : si nous mettions un logo sur les deux résolutions, un des deux affichages serait totalement flou.

Il faudra donc tout adapter.

Le fichier Info.Plist est un fichier contenant la quasi-totalité des informations d'identification, de compilation, de compatibilité, de disponibilité de votre projet.

Il est également au format XML et se présente sous cette forme :

Cependant, vous serez très rarement, voire jamais, amené à le modifier directement dans le code source puisqu'un éditeur simplifié est disponible sur Xcode, permettant d'afficher le fichier info.plist de cette façon :

Nous y trouverons donc de nombreuses informations sur notre application, telles que les storyboards de base, les versionnings de l'application et des modifications, etc.