La semaine dernière, j'ai vu que la communauté essayait de transférer des modèles de développement éprouvés d'UIKit vers SwiftUI. Mais je suis sûr que la meilleure façon d'écrire du code efficace à l'aide de SwiftUI est d'oublier tout sur UIKit et de changer complètement votre état d'esprit en termes de développement d'interface utilisateur. Cette semaine, je parlerai des principales différences entre le développement utilisant UIKit et SwiftUI.
Définition des différences
UIKit est un cadre événementiel impératif pour créer des interfaces utilisateur pour la plate-forme iOS. Cela signifie que vous devez gérer tous les changements d'état lors d'événements tels que le chargement d'une vue, un clic sur un bouton, etc. Un gros inconvénient de cette approche est la difficulté de synchroniser l'interface utilisateur avec son état. Dès que l'état change, vous devez ajouter / supprimer / afficher / masquer manuellement les vues et les synchroniser avec l'état actuel de l'application.
SwiftUI est un cadre déclaratif pour créer des interfaces utilisateur pour toutes les plateformes Apple. Le mot clé dans ce cas est déclaratif. Déclaratif signifie que le développeur doit déclarer ce qu'il veut réaliser, et le framework s'en chargera. Le framework connaît la meilleure façon de rendre l'interface utilisateur.
UI = f(state)
Dans SwiftUI, l'interface utilisateur est fonction de son état. Cela signifie que chaque fois que l'état d'une vue change, il raconte sa propriété de corps et génère une nouvelle vue. Prenons l'exemple suivant.
struct ContentView: View { @ObservedObject var store: Store var body: some View { Group { if store.isLoading { Text("Loading...") .font(.subheadline) } else { Image("photo") .font(.largeTitle) } } } }
Dans l'exemple ci-dessus, il y a une vue qui affiche le texte «Loading ...» et affiche des images à la fin du téléchargement.
ObserverObject est l'état de cette vue, et dès qu'il change, SwiftUI recalcule la propriété body et attribue une nouvelle vue. Lors du développement avec UIKit, il est nécessaire de masquer / afficher manuellement les éléments de la hiérarchie de présentation, mais dans SwiftUI il n'est pas nécessaire d'ajouter / supprimer un indicateur de chargement. Il y a plusieurs façons dans SwiftUI de décrire l'état d'une vue, pour en savoir plus à leur sujet, jetez un œil à «
Property Wrappers in SwiftUI ».
Nous allons maintenant examiner de plus près ce qui se passe lorsque l'état d'affichage change. SwiftUI a une empreinte de la hiérarchie actuelle des vues et, dès que son état change, il calcule une nouvelle vue. SwiftUI applique des algorithmes de comparaison pour comprendre les différences et ajouter / supprimer / mettre à jour automatiquement les vues nécessaires. Par défaut, SwiftUI utilise l'image de transition d'entrée / sortie standard pour afficher / masquer les vues, mais il est également possible de modifier manuellement la transition vers n'importe quelle autre animation. Pour en savoir plus sur la transition et les animations dans SwiftUI, consultez mon article «
Animations dans SwiftUI ».
Hiérarchie des présentations
Parlons de la hiérarchie des vues et de la façon dont SwiftUI affiche réellement la structure des vues. La toute première chose que je veux mentionner est que SwiftUI n'affiche pas la structure de la vue par mappage un à un. Il est possible d'utiliser autant de conteneurs de vues que vous le souhaitez, mais au final, SwiftUI n'affiche que les vues qui ont un sens pour le rendu. Cela signifie que vous pouvez extraire leur logique en petites représentations, puis les composer et les réutiliser dans l'application. Ne vous inquiétez pas, les performances de l'application dans ce cas ne souffriront pas. Pour en savoir plus sur la création de vues dans SwiftUI, consultez
cet article .
La meilleure façon de comprendre la hiérarchie des représentations complexes dans SwiftUI est d'afficher son type. SwiftUI utilise un système de type statique pour déterminer la différence assez rapidement. Tout d'abord, il vérifie le type de vue, puis vérifie les valeurs des composants de la vue. Je ne suis pas fan de l'utilisation des réflexions dans le code de travail, mais c'est très utile dans le processus d'apprentissage.
print(Mirror(reflecting: ContentView(store: .init()).body))
À l'aide de la structure miroir, vous pouvez afficher le type réel du corps ContentView et découvrir comment SwiftUI fonctionne.
Conclusions
Cette semaine, nous avons appris la principale différence entre UIKit et SwiftUI et examiné en détail l'algorithme de comparaison dans SwiftUI. J'espère que l'article vous a plu. Merci d'avoir lu et à la semaine prochaine!