Share
UIKit est le framework que vous utiliserez le plus souvent lors du développement d'applications iOS. Il définit les principaux composants d'une application iOS, des étiquettes et des boutons aux vues de tableau et aux contrôleurs de navigation. Dans cet article, non seulement nous allons commencer notre exploration du framework UIKit, nous allons également explorer les éléments internes d'un projet iOS et les blocs de construction de base des applications iOS..
Alors que le framework Foundation définit des classes, des protocoles et des fonctions pour les développements iOS et OS X, le framework UIKit est exclusivement destiné au développement iOS. C'est l'équivalent du Kit d'application ou AppKit cadre pour le développement OS X.
Comme Foundation, UIKit définit des classes, des protocoles, des fonctions, des types de données et des constantes. Il ajoute également des fonctionnalités supplémentaires à diverses classes Foundation, telles que NSObject, NSString, et NSValue en utilisant les catégories Objective-C.
Les catégories Objective-C sont un moyen pratique d'ajouter des méthodes supplémentaires aux classes existantes sans qu'il soit nécessaire de créer des sous-classes. Lisez ce tutoriel d'Aaron Crabtree si vous voulez en savoir plus sur les catégories Objective-C.
Au lieu d'explorer les classes clés d'UIKit comme nous l'avons fait pour le framework Foundation, nous allons créer et parcourir un nouveau projet iOS et explorer les classes que nous rencontrons. En adoptant cette approche, il sera rapidement clair dans quel contexte une classe est utilisée et comment chaque classe s’intègre dans le schéma plus général d’une application iOS et quel rôle elle joue..
Lancez Xcode et créez un nouveau projet en sélectionnant Nouveau> Projet… du Fichier menu. Dans la section iOS à gauche, sélectionnez le Application Catégorie. Dans la liste des modèles de projet, choisissez le Application à vue unique modèle.
Le modèle d'application Single View contient les éléments de base d'une application iOS et constitue donc un bon point de départ pour notre aventure..
Nommez le projet UIKit et entrez un nom d'organisation et un identifiant d'entreprise. Entrez un préfixe de classe, comme je l'ai expliqué précédemment dans cette série, et définissez Dispositifs à iPhone.
Indiquez à Xcode où vous souhaitez enregistrer le nouveau projet et assurez-vous de le placer sous contrôle de version en cochant la case intitulée Créer un référentiel git sur mon Mac. Consultez cet article pour plus d'informations sur le contrôle de version et ses avantages..
Nous avons appris pas mal de nouvelles choses depuis la dernière création d'un projet iOS, c'est donc une bonne idée d'explorer les différents fichiers et dossiers de notre nouveau projet pour voir s'ils sonnent bien..
dans le Navigateur de projet, vous devriez voir trois dossiers à la racine du projet;
Jetons un coup d'œil au contenu de chacun de ces dossiers.
le Des produits dossier contient actuellement deux éléments. Le premier élément porte le nom de notre projet et a une extension de .app. Le nom du deuxième élément se termine par Des tests et a une extension de .Xctest. Je ne couvrirai pas les tests unitaires de cette série, vous pouvez donc ignorer le second élément pour l'instant..
Le dossier Products contient la ou les applications créées par le projet après la compilation du code source..
Avez-vous remarqué que UIKit.app est surligné en rouge? Chaque fois que Xcode ne parvient pas à localiser un fichier, il le met en surbrillance en rouge. Comme le projet n'a pas encore été compilé, Xcode n'a pas encore créé le produit..
le Cadres Le dossier contient les cadres auxquels votre projet est lié. Dans l'article précédent, notre projet était uniquement lié au cadre de la Fondation. Ce projet, toutefois, est basé sur un modèle d'application iOS et est donc lié à quatre frameworks, Foundation, UIKit, Core Graphics et XCTest..
Vous vous souviendrez peut-être du framework Core Graphics d’auparavant dans cette série. Le framework contient les interfaces pour l'API de dessin 2D (Quartz). Le framework XCTest est lié aux tests unitaires, que je ne couvrirai pas dans cette série..
Il existe un autre emplacement dans notre projet qui spécifie les cadres auxquels le projet est lié. Sélectionnez votre projet dans le Navigateur de projet, choisissez le seul article dans le Les cibles section à gauche et ouvrez le Phases de construction onglet en haut.
En ouvrant le Lien binaire avec les bibliothèques Dans le tiroir, la même liste de cadres que celle présentée dans le dossier Frameworks vous est présentée. Lier notre projet à un autre framework système iOS est aussi simple que de cliquer sur le bouton plus en bas de la liste et de sélectionner un framework dans la liste..
La plupart de votre temps est passé dans le dossier du projet, qui contient actuellement six fichiers et un dossier nommé Fichiers de support. Commençons par examiner le contenu du dossier Fichiers de support..
Accentsconagua
principale fonction, qui est où toute la magie commence. Même si nous ne modifierons pas main.m, c'est essentiel pour votre application iOS.Maintenant que nous savons à quoi servent les différents fichiers et dossiers de notre projet, il est temps d'explorer les différents composants d'une application iOS. En poursuivant notre cheminement, nous rencontrerons plusieurs classes appartenant à UIKit. Chaque classe appartenant au framework UIKit commence par le préfixe de classe UI. Rappelez-vous que les classes Foundation sont préfixées par NS.
Avant de commencer à explorer le framework UIKit, je voudrais parler du modèle MVC (Model-View-Controller). Le modèle MVC est l’un des modèles les plus répandus dans la programmation orientée objet. Il favorise la réutilisation des codes et entretient des liens étroits avec le concept de séparation des responsabilités ou des préoccupations. L'un des principaux objectifs du modèle MVC est la séparation de la logique métier d'une application et de la couche de présentation..
Cocoa Touch adopte le modèle MVC et il est donc important de comprendre en quoi il consiste et comment il fonctionne. En d'autres termes, en comprenant le modèle MVC, il sera beaucoup plus facile de comprendre comment les différents composants d'une application iOS fonctionnent ensemble.
Dans le modèle MVC, un modèle contrôle la logique métier d'une application. L'interaction avec une base de données, par exemple, est la responsabilité du modèle. La vue présente les données gérées par le modèle à l'utilisateur. La vue gère l'interface utilisateur et l'entrée utilisateur.
Le contrôleur est la colle entre le modèle et la vue. Tandis que le modèle et la vue ne connaissent pas l'existence de l'autre, le contrôleur connaît à la fois le modèle et la vue..
Comme le contrôleur connaît à la fois le modèle et la vue, il s’agit souvent de la partie la moins réutilisable d’une application. Moins un objet connaît son environnement et les objets avec lesquels il interagit, plus il sera réutilisable dans les projets futurs..
UIApplicationMême si le UIApplication La classe est un composant clé de chaque application iOS, vous n'interagirez pas très souvent avec elle et vous ressentirez rarement, voire jamais, le besoin de sous-classer. UIApplication.
Lorsqu'une application est lancée, un singleton de cette classe est créé. Vous souvenez-vous de ce qu'est un objet singleton? Cela signifie qu’une seule instance d’objet de la UIApplication la classe est créée pendant la durée de vie d'une application.
le UIApplication instance est le point d’entrée de l’interaction de l’utilisateur et distribue les événements aux objets cibles appropriés. La signification exacte de ceci deviendra claire dans quelques minutes lorsque nous examinerons les contrôleurs de vue..
Dans la plupart des applications iOS, le UIApplication Cette instance est associée à un objet délégué. Chaque fois que vous créez un projet iOS à l'aide de l'un des modèles fournis, Xcode crée une classe de délégué d'application pour vous. Examinez les noms des fichiers source dans le dossier du projet dans le navigateur de projet. Les deux premiers fichiers sont nommés TSPAppDelegate.
L’instance de cette classe est le délégué du UIApplication singleton. Avant de regarder de plus près le TSPAppDelegate classe, nous devons comprendre ce que le modèle de délégué est.
Ole Begemann a écrit un excellent article sur la séquence de lancement d'une application iOS typique. Dans cet article, il parle des différents composants impliqués et de leur rôle lors de la séquence de lancement de l'application. Je recommande fortement de lire cet article si vous voulez mieux comprendre le rôle du UIApplication classe ainsi que le mystérieux principale() fonctionner dans main.m.
Le modèle de délégué est largement utilisé dans Cocoa et Cocoa Touch. Dans le prochain article de cette série, dans lequel nous explorons les tenants et les aboutissants d'une vue de table, vous découvrirez que les vues de table dépendent fortement du modèle de délégué (et de source de données)..
A l'instar du modèle MVC, la délégation est courante dans la programmation orientée objet. Le modèle de délégué dans Cocoa Touch, cependant, est légèrement différent, car il utilise un protocole de délégué pour définir le comportement de l'objet délégué..
Faisons un pas en avant et jetons un coup d'oeil aux vues de table. Si vous avez passé du temps avec un iPhone ou un iPad, alors le UITableView la classe devrait vous être familière. Il présente une liste ordonnée de données à l'utilisateur et fait très bien ce travail..
Comment une vue de table sait-elle quoi faire quand une ligne est exploitée? Ce comportement est-il inclus dans le UITableView classe? Certainement pas, car ce comportement varie d'une application à l'autre. Si nous devions inclure ce comportement dans le UITableView classe, ce ne serait pas très réutilisable.
La vue de la table externaliser cette responsabilité à un objet délégué. Autrement dit les délégués cette tâche à un autre objet, un déléguer objet. Prenez un moment pour inspecter la référence de classe du UITableView classe. Il a deux propriétés nommées la source de données et déléguer. le déléguer est notifié par la vue table lorsqu'un utilisateur appuie sur une ligne. Il est de la responsabilité de l'objet délégué de répondre au tap de l'utilisateur.
La source de données de la vue table est similaire en termes de comportement. La principale différence est que la vue de table demande l'objet source de données pour quelque chose, les données qu'il doit afficher.
Déléguer et objets de source de données, tels que la vue de table déléguer et la source de données les objets, sont presque toujours des classes personnalisées, des classes que vous créez, car leur implémentation est spécifique à l'application.
Avant de jeter un oeil à la TSPAppDelegate classe, il est important de comprendre qu'un objet délégué est conforme à un protocole de délégué. Dans l'article précédent, nous avions déjà appris à propos des protocoles d'Objective-C et de la façon dont ils définissent le comportement en définissant une liste de méthodes que ses utilisateurs peuvent mettre en œuvre.
Maintenant que nous savons ce qu'est la délégation, il est temps d'explorer les TSPAppDelegate classe que Xcode a créé pour nous. Au lancement de l'application, l'application crée une instance du TSPAppDelegate classe. Généralement, vous n'avez jamais besoin d'instancier explicitement un objet délégué d'application..
Ouvrez le fichier d'en-tête du TSPAppDelegate classe (TSPAppDelegate.h) d'examiner son contenu. Si nous ignorons les commentaires en haut, la première ligne importe les fichiers d'en-tête du framework UIKit afin que nous puissions utiliser ses classes et ses protocoles..
#importation
La ligne suivante devrait être familière. C'est le début de l'interface du TSPAppDelegate classe comme indiqué par le @interface directif. Il spécifie le nom de la classe et la superclasse de la classe, UIResponder.
Entre les crochets, se trouvent les protocoles auxquels la classe se conforme. le TSPAppDelegate classe est conforme à un protocole, le UIApplicationDelegate protocole.
@interface TSPAppDelegate: UIResponder
La ligne suivante est une déclaration de propriété, qui devrait vous paraître familière. La propriété, la fenêtre, est un exemple de UIWindow, qui est une sous-classe de UIView. Les mots entre parenthèses, fort et non atomique, sont des attributs de propriété facultatifs qui spécifient la sémantique de stockage et le comportement de la propriété. Vous pouvez les ignorer pour l'instant.
@property (strong, nonatomic) UIWindow * fenêtre;
La partie la plus intéressante de l'interface du TSPAppDelegate la classe est la UIApplicationDelegate protocole. Regardez la référence de la UIApplicationDelegate protocole pour une liste complète des méthodes définies par le protocole.
Le protocole définit des dizaines de méthodes et je vous encourage à en explorer quelques unes pour vous faire une idée des fonctionnalités du protocole. La méthode qui nous intéresse le plus à ce stade est application: didFinishLaunchingWithOptions:.
Quand le UIApplication Si l’instance a fini de préparer la demande en vue du lancement, elle en informera le délégué, notre TSPAppDelegate Par exemple, le lancement de l'application est terminé, mais il n'a pas encore.
Pourquoi informe-t-il le délégué à l'application de cet événement? le UIApplication instance notifie son délégué à cet événement afin qu'il ait la possibilité de se préparer au lancement de l'application. Rendez-vous sur le fichier d'implémentation de TSPAppDelegate pour voir ce que je veux dire. La première méthode du fichier d'implémentation est application: didFinishLaunchingWithOptions: et il devrait plus ou moins ressembler à celui collé ci-dessous.
- (BOOL) application: (UIApplication *) application didFinishLaunchingWithOptions: (NSDictionary *) launchOptions return YES;
le application: didFinishLaunchingWithOptions: méthode fournit une référence à la UIApplication exemple et un dictionnaire avec des options, qui ne nous intéressent pas pour le moment. L'implémentation de la méthode est assez simple. Il ne fait que retourner OUI dire au UIApplication exemple que l'application est prête à être lancée.
Le projet Xcode contient un autre fichier intéressant, Tableau principal. Le storyboard définit à quoi ressemblera l'interface utilisateur de notre application. Par défaut, le storyboard est nommé Tableau principal. Sélectionnez le storyboard pour l'ouvrir.
Le storyboard contient actuellement une vue dans l'espace de travail central. À droite du Navigateur de projet vous pouvez voir une liste d'éléments, qui sont les objets que vous voyez dans la vue. L'élément supérieur est nommé Voir la scène du contrôleur, qui contient un élément enfant étiqueté Contrôleur de vue.
le Contrôleur de vue objet a également un certain nombre d'éléments enfants, mais il y en a un qui nous intéresse particulièrement, l'objet nommé Vue. Rappelez-vous notre discussion sur le modèle MVC. Ici, vous pouvez voir le motif MVC en action. Le modèle manque pour le moment, mais nous avons une vue, le Vue objet, et un contrôleur, le Contrôleur de vue objet.
Lorsque notre application est lancée, le storyboard est utilisé pour créer l'interface utilisateur de l'application. Le contrôleur de vue est automatiquement instancié, de même que la vue du contrôleur de vue. le Vue l'objet dans le storyboard est géré par le contrôleur de vue.
Attends une minute. Où puis-je trouver la classe du contrôleur de vue dans le storyboard? Comment puis-je changer son comportement pour créer une application unique? Sélectionnez le Contrôleur de vue objet à gauche dans le storyboard et ouvrez le Inspecteur d'identité sur la droite.
le Inspecteur d'identité vous dit tout ce que vous devez savoir. En haut, dans la section Classe personnalisée, vous pouvez voir le nom de la classe du contrôleur de vue, TSPViewController. Avez-vous remarqué que les deux fichiers dont nous n'avons pas encore parlé portent le même nom? Nous allons explorer ces fichiers dans quelques instants.
Le contrôleur de vue est instancié pour nous, car il s'agit du contrôleur de vue initial du storyboard. Ceci est indiqué dans le storyboard par la flèche pointant vers le storyboard..
UIViewControllerSi vous ouvrez TSPViewController.h, vous remarquerez que le TSPViewController classe est une sous-classe de UIViewController. Comme TSPAppDelegate, la UIViewController classe est une sous-classe de UIResponder. Les contrôleurs de vue, ou leurs sous-classes, tombent dans le manette catégorie du modèle MVC. Comme leur nom l’indique, ils contrôlent une vue, une instance du UIView classe, qui tombe dans le vue catégorie du modèle MVC.
Un contrôleur de vue gère une vue et les sous-vues de la vue, comme nous le verrons plus tard. Pour ce faire, le contrôleur de vue doit connaître la vue. En d'autres termes, il doit avoir une référence à la vue.
Le contrôleur de vue dans le storyboard a une référence à la vue. Vous pouvez le vérifier en sélectionnant le contrôleur de vue dans le storyboard et en ouvrant le Inspecteur de connexions sur la droite.
dans le Inspecteur de connexions, vous devriez voir une section nommée Prises électriques. Le terme sortie est un mot de fantaisie pour une propriété, que vous pouvez définir dans le storyboard. Passez la souris sur la sortie nommée vue et observez comment la vue dans l'espace de travail est mise en surbrillance. C’est la connexion entre le contrôleur de vue et la vue.
UIViewMême si votre application ne peut avoir qu'une seule instance de UIWindow, il peut avoir beaucoup de points de vue. le UIView La classe est un composant important du framework UIKit, car de nombreuses classes en héritent directement ou indirectement..
Revisiter Tableau principal en le sélectionnant et jetez un oeil à la Bibliothèque d'objets au bas de la Inspecteur.
Parcourir la bibliothèque d'objets et faites glisser un étiquette et un bouton à la vue dans l'espace de travail. Peu importe où vous les positionnez dans la vue tant qu'ils sont dans la vue du contrôleur de vue.
Vous aurez remarqué que deux nouveaux objets ont été ajoutés à la Objets section à gauche. À la fois l'étiquette (UILabel) et le bouton (UIButton) hériter de UIView. Avez-vous remarqué que le Étiquette et Bouton les objets sont légèrement en retrait par rapport à la Vue objet? Cela indique que le Étiquette et Bouton les objets sont des sous-vues du Vue objet. Une vue peut avoir une ou plusieurs sous-vues gérées.
Comme je l'ai mentionné plus tôt, le UIView La classe est un élément important de UIKit. Une vue gère une zone ou un cadre rectangulaire sur l'écran. Il gère le contenu de la zone, les sous-vues et toutes les interactions avec le contenu de la vue. le UIView classe est une sous-classe de UIResponder. Vous en apprendrez beaucoup plus sur les points de vue au cours de cette série..
Examinons un exemple pour illustrer la relation entre le storyboard, la vue qu'il contient et le contrôleur de vue. Ces trois composants sont importants et je veux m'assurer que vous comprenez comment ils fonctionnent ensemble.
Il y a quelques minutes, vous avez ajouté une étiquette et un bouton à la vue du contrôleur de vue. Comment le contrôleur de vue connaît-il ces objets? Pour le moment, ils n'apparaissent pas dans le Inspecteur de connexions, mais nous pouvons changer cela en disant le contrôleur de vue à leur sujet.
Ouvrez le fichier d’en-tête du contrôleur de vue (TPSViewController.h) et ajouter une propriété pour l'étiquette et pour le bouton.
@property IBOutlet UILabel * myLabel; @property IBOutlet UIButton * myButton;
En ajoutant le IBOutlet mot-clé de la déclaration de propriété, les propriétés apparaissent dans l'inspecteur de connexions du storyboard et c'est ce que nous voulons..
Retournez au story-board, sélectionnez le Contrôleur de vue objet dans le Voir la scène du contrôleur, et ouvrez le Inspecteur de connexions sur la droite. Les nouvelles propriétés sont maintenant répertoriées dans la liste des Prises électriques. Cependant, le contrôleur de vue n’a pas encore rendu la lien entre les nouvelles propriétés et les objets du storyboard.
C'est facile d'y remédier. Faites glisser depuis le cercle vide à gauche de la myLabel sortie vers l'étiquette dans l'espace de travail. Cela créera cette connexion très importante pour que le contrôleur de vue connaisse l'étiquette. Faites la même chose pour le bouton.
Même si nous pouvons modifier le texte de l'étiquette dans le storyboard, procédons ainsi dans le contrôleur de vue pour montrer que celui-ci a accès à l'étiquette et au bouton du storyboard..
Ouvrez le fichier d'implémentation du contrôleur de vue (TPSViewController.m) et cherchez le viewDidLoad méthode. Modifier le viewDidLoad méthode pour refléter la mise en œuvre ci-dessous. Les commentaires ont été omis pour plus de clarté.
- (void) viewDidLoad [super viewDidLoad]; [self.myLabel setText: @ "Ceci est une instance de UILabel."];
Nous pouvons envoyer des messages à la propriété label en demandant au contrôleur de vue, soi, pour son myLabel propriété. En envoyant le myLabel propriété un message de Définir le texte: et en passant un littéral de chaîne, nous mettons à jour le texte de l'étiquette.
Notez que Définir le texte: est un accesseur ou un passeur. Même s'il est possible d'utiliser la notation par points d'Objective-C (voir ci-dessous), j'ai utilisé la syntaxe plus traditionnelle car elle montre mieux ce qui se passe réellement..
self.myLabel.text = @ "Ceci est une instance de UILabel";
Exécutez votre application dans le simulateur iOS en cliquant sur le bouton Courir bouton en haut à gauche et remarquez que le texte de l'étiquette est bien mis à jour.
Nous avons exploré beaucoup de nouvelles choses dans cet article. Je veux terminer cette tranche en parlant d'actions. Tout comme les sorties, les actions ne sont rien de plus que des méthodes que vous pouvez voir dans le storyboard..
Voyons comment cela fonctionne. Ouvrez le fichier d’en-tête du contrôleur de vue (TPSViewController.h) et ajoutez la déclaration de méthode suivante quelque part dans le bloc d'interface du contrôleur de vue.
- (IBAction) changeColor: (id) expéditeur;
Ne soyez pas confus par le IBAction mot-clé. IBAction est identique à vide, ce qui signifie que la méthode ne renvoie aucune valeur. Si nous examinons de plus près la déclaration de la méthode, nous pouvons voir qu’il faut un argument de type identifiant, une référence à un objet Objective-C.
Comme le nom de l'argument l'indique, l'argument de la méthode ou de l'action est l'objet qui a envoyé le message au contrôleur de vue. Je vais expliquer cela plus en détail dans un peu.
Revisitez le storyboard, sélectionnez le Contrôleur de vue objet dans le Voir la scène du contrôleur, et ouvrez le Inspecteur de connexions. Une nouvelle section est parue dans le Inspecteur de connexions nommé Actions reçues et l'action que nous venons d'ajouter est répertoriée dans cette section.
Faites glisser le cercle vide à gauche de l'action vers le bouton de l'espace de travail. Une petite fenêtre avec une liste d'options devrait apparaître. La liste contient tous les événements possibles auxquels le bouton peut répondre. Celui qui nous intéresse est Retouche à l'intérieur. Cet événement est déclenché lorsqu'un utilisateur appuie sur le bouton et lève le doigt tout en restant à l'intérieur du bouton..
Générez et exécutez à nouveau votre application, puis appuyez sur le bouton. L'application s'est-elle effondrée pour vous également? Comment est-ce arrivé? Lorsque vous avez appuyé sur le bouton, il a envoyé un message de changer de couleur: au contrôleur de vue. Même si le contrôleur de vue déclare une changer de couleur: méthode, il ne met pas encore en œuvre cette méthode.
Chaque fois qu'un message est envoyé à un objet qui n'implémente pas de méthode correspondante, une exception est générée et l'application se bloque si l'exception n'est pas interceptée. Vous pouvez le vérifier en exécutant une nouvelle fois l'application, en appuyant sur le bouton et en inspectant le résultat dans la fenêtre de la console..
Pour remédier à cela, nous devons mettre en œuvre le changer de couleur: méthode. Ouvrez le fichier d'implémentation du contrôleur de vue (TPSViewController.m) et ajoutez l'implémentation de méthode suivante quelque part dans le bloc d'implémentation.
- (IBAction) changeColor: (id) expéditeur NSLog (@ "Classe d'expéditeur>% @", [classe d'expéditeur]); NSLog (@ "Superclasse d'expéditeur>% @", [superclasse d'expéditeur]); int r = arc4random ()% 255; int g = arc4random ()% 255; int b = arc4random ()% 255; UIColor * color = [UIColor colorWithRed: (r / 255.0) vert: (g / 255.0) bleu: (b / 255.0) alpha: 1.0]; [self.view setBackgroundColor: color];
La mise en œuvre de la changer de couleur: Cette méthode est identique à celle utilisée précédemment dans cette série. Cependant, j'ai ajouté deux supplémentaires NSLog appelle à sa mise en œuvre pour vous montrer que l'expéditeur du message est bien le bouton que nous avons ajouté au storyboard.
La méthode elle-même est assez simple. Nous générons trois entiers aléatoires entre 0 et 255, transmettre ces valeurs à colorWithRed: vert: bleu: alpha: pour générer une couleur aléatoire et mettre à jour la couleur d'arrière-plan de la vue du contrôleur de vue avec la couleur générée de manière aléatoire.
Notez que auto.view fait référence à la vue que le contrôleur de vue gère et que nous avons vue précédemment dans le storyboard.
Générez et exécutez votre application une fois de plus, appuyez sur le bouton et n'oubliez pas d'inspecter la sortie dans la fenêtre de la console de Xcode. Vous remarquerez que l'expéditeur est une instance de UIButton et sa super-classe est UIControl.
Dans cet article, nous avons exploré quelques classes du framework UIKit et avons examiné de près les différents composants d'une application iOS. Nous allons explorer et travailler avec le framework UIKit plus en détail dans le reste de cette série..
Si vous ne comprenez pas bien les divers concepts et schémas, je suis sûr que vous le ferez au fur et à mesure que la série avance. N'hésitez pas à laisser un commentaire si vous avez des questions sur cet article.
