(musique électro entraînante)
- Bonjour et bienvenue à tous. Je m’appelle Ryan.
Je suis ingénieur logiciel dans l'équipe Firebase
et je travaille sur les SDK Apple dans notre bureau de Waterloo, au Canada.
- Et je m’appelle Chen.
Je suis ingénieur logiciel dans l’équipe Firebase
et je travaille aussi sur les SDK Apple. Mon bureau est à Sunnyvale, en Californie.
- La mission de Firebase est d’aider les développeurs
en facilitant la création d’applications et leur fonctionnement.
- Firebase est une boîte à outils de développement mobile multiplateforme
compatible avec iOS, Android, Web, CIMA + et Unity.
Mais enfin, nous savons pourquoi vous êtes ici.
Si vous partagez mon enthousiasme, vous verrez que l’écosystème d’Apple
a facilité le développement d’applications multiplateformes,
pas seulement pour iOS et iPadOS, mais aussi pour macOS, WatchOS, tvOS et Catalyst.
Waouh, c’est une longue liste.
Ici, chez Firebase, nous examinons quelques cas d’usage
et nous les rendons disponibles sur les plates-formes d’Apple.
Les SDK Firebase pour les plates-formes Apple vous donnent de la flexibilité
pour déverrouiller des flux de développement iOS,
et ils le feront encore davantage à l’avenir.
- La construction et l’exécution d’applis pour iOS et les autres plates-formes Apple
ont changé au cours des dernières années.
Swift est devenu le langage de facto pour la création d’applications.
Nous verrons quelques fonctionnalités
et structures du langage Swift durant cette session.
SwiftUI, par exemple, nous permet de construire de belles interfaces
en utilisant une syntaxe simple et concise.
Swift Package Manager permet plus facilement que jamais
d’inclure des SDK Firebase dans votre projet.
Async/await et Combine
sont de nouvelles façons de concevoir la programmation asynchrone.
Chez Firebase, nous surveillons ces changements de près,
et aujourd’hui, nous allons montrer comment nous approchons
ces changements dans l’écosystème.
Mais d’abord, Chen, que se passe-t-il dans le dépôt GitHub?
- Je vais te le dire, Ryan.
Depuis que Firebase a entamé l’open sourcing de nos bibliothèques clientes en 2017,
la grande majorité des SDK Firebase pour les plates-formes Apple
sont disponibles à ce jour sur GitHub.
Nous avons récemment ouvert la source du SDK de performance Firebase
à la fin de 2020. Si vous ne l’avez pas encore vue,
allez y jeter un œil et dites-nous ce que vous en pensez.
Nous continuons de montrer notre engagement pour une plus grande transparence
et pour bâtir une communauté de développeurs plus forte.
À ce jour, nous avons résolu plus de 2 000 problèmes
et généré plus de 5 000 demandes d’extraction.
Notre équipe Firebase adore interagir avec vous sur GitHub.
Nous vous encourageons à envoyer vos commentaires,
quelles que soient les demandes de fonctionnalités ou les problèmes de bug,
car vous pouvez parler directement à nos ingénieurs
qui développent les SDK, y compris Ryan et moi.
Cela facilite aussi beaucoup les conversations techniques.
Nous avons la chance d'avoir une formidable communauté de contributeurs.
Vous êtes actuellement 139
à contribuer sur les SDK Firebase pour les plates-formes Apple.
Nous assistons à des collaborations open source actives
entre les membres de la communauté et les Firebasers
travaillant ensemble sur une assistance pour Combine.
Nous tenons à tous vous remercier pour avoir amélioré nos SDK.
Être open source a rendu beaucoup de choses possibles.
Pouvoir parcourir le code et savoir exactement comment votre SDK se comporte
permet d’économiser des heures de chasse aux bugs.
Cela a également permis des fonctionnalités comme l’assistance de la communauté
pour tvOS, macOS, Catalyst et WatchOS.
Nous avons récemment ajouté l’assistance de la communauté WatchOS
pour la base de données en temps réel et la configuration à distance.
Vous pouvez désormais essayer cela dans votre application pour montre
et utiliser les discussions GitHub pour poser des questions.
Beaucoup d'entre vous ont déjà commencé à utiliser Swift Package Manager
pour gérer les dépendances.
Aujourd’hui, Firebase prend officiellement en charge Swift Package Manager.
Donc, en plus de CocoaPods, utilisez maintenant Swift Package Manager
pour ajouter des bibliothèques Firebase à votre application.
Je vais vous montrer rapidement comment faire, car c’est très facile.
Tout d’abord, vous devrez obtenir les URL à partir de la page de rapport
du SDK Firebase iOS.
Copiez-collez les URL de la page.
Cela devrait fonctionner pour la plupart des bibliothèques
hébergées ou distribuées via GitHub.
Maintenant, ouvrez votre appli dans votre code X, cliquez sur l’onglet Fichier,
et sélectionnez le package Swift.
Cliquez ensuite sur Ajouter une dépendance de package,
collez les URL et cliquez sur Suivant.
Sélectionnez la version ou la branche que vous souhaitez cibler.
Nous vous recommandons d’obtenir la dernière version de nos SDK,
pas seulement pour les nouvelles fonctionnalités,
mais surtout pour les corrections de bugs ou les améliorations.
Juste après, vous pouvez sélectionner le produit que vous souhaitez utiliser.
Ici, nous allons utiliser Analytics Auth,
et nous allons essayer les nouvelles API d’extension SwiftUI.
Il faut savoir que si vous souhaitez l’ajouter dans une cible différente,
par exemple si vous avez une cible indépendante pour la montre
et que vous souhaitez seulement installer la messagerie dans l’application de la montre,
vous pouvez choisir une cible sur le côté droit.
Quand vous avez fini, cliquez sur Terminer. Vous devriez pouvoir voir les paquets
si vous cliquez sur Projet et sélectionnez Packages Swift ici.
Si vous souhaitez ajouter d’autres SDK Firebase ultérieurement,
vous pouvez aller sur la cible que vous souhaitez éditer, cliquer sur Général,
et sous les Cadres, Bibliothèques et contenu incorporé.
Vous pouvez ajouter manuellement des SDK Firebase ou en supprimer
si vous n’en avez plus besoin.
Maintenant que nous avons créé un nouveau projet avec Swift Package Manager,
écoutons Ryan qui va nous en dire plus sur Swift et SwiftUI.
- Merci, Chen.
Bien que nos SDK soient principalement écrits en Objective-C,
nous évaluons chaque API pour voir comment elle est importée dans Swift
afin d’optimiser l’expérience.
Mais qu’en est-il des types de résultats, de l’assistance pour Codable,
des paramètres par défaut, ou des énumérations et types associés ?
Nous pouvons profiter de ces excellentes fonctionnalités Swift
lors de l’écriture en Objective-C.
Parfois, nous avons juste besoin d’écrire du code Swift.
C’est pourquoi nous avons commencé à envoyer
des extensions Swift facultatives à différents SDK.
Et certaines ont été apportées par la communauté.
Examinons quelques faits saillants. Nous allons voir beaucoup de code.
Voici un extrait où nous téléchargeons une image à partir du stockage Firebase
en utilisant le bloc de gestionnaire d'achèvement traditionnel.
Les données et l’erreur sont facultatives,
ce qui conduit à un code maladroit nous obligeant à forcer le déballage de l’erreur.
C’est quelque chose que nous préférerions éviter.
L'erreur doit toujours être renseignée lorsque les données sont nulles,
et les données doivent toujours être nulles en cas d'erreur.
Mais nous ne pouvons pas appliquer cela dans le compilateur avec le code existant.
Mais en utilisant la fonction fournie par la nouvelle extension Swift,
nous pouvons éliminer cet état gênant et le déballage forcé.
Avec une instruction switch, nous obtenons du compilateur la sécurité
de n’avoir que deux états représentés.
Ou bien nous avons des données, ou bien nous avons une erreur.
Il n’y a plus d’ambiguité dans les états.
Passons à Firestore et à l’analyse des données.
Voici un extrait de code abrégé
montrant l’analyse des données d’une version précédente
de notre démarrage rapide Firestore. Après avoir obtenu les données de Firestore,
nous voulons les convertir en un type local à partir du dictionnaire fourni.
Dans ce cas, un restaurant. Ce type de code vous semble-t-il familier ?
Cela m’attriste toujours de lire ce menu. Déballer une erreur sur les clés de chaîne,
ne pas profiter des caractéristiques de sécurité de type Swift.
C’est fragile, difficile à lire et on fait facilement des erreurs en l’écrivant.
Au lieu de cela, ajoutons une conformité Codable à notre type de restaurant.
En se conformant au protocole Codable,
nous obtenons une grande partie de cette analyse manuelle du code gratuitement,
car elle est générée par le compilateur,
et les mises à jour restent cohérentes dans le type.
Il est maintenant aussi simple de lire ces données Firestore
que d’appeler les données en tant que fonction
sur les documents, les tests d’instantané et les analyses dans le type restaurant.
Plus besoin d’analyser manuellement cet objet.
Codable le fait pour nous.
La configuration des données dans Firestore est tout aussi simple,
en passant directement dans l’instance plutôt que sa représentation par dictionnaire.
Nous venons également de publier une API similaire pour la base de données Firebase,
grâce à un contributeur externe.
Ensuite, le nouveau et formidable SwiftUI. C’est mon préféré.
Je suis ravi d’annoncer que nous avons récemment livré
des API spécifiques à SwiftUI, et d’autres sont à venir.
Lors de la WWDC 2020, nous avons découvert un nouveau cycle de vie d'application SwiftUI
qui est partagé entre les plates-formes.
Auparavant, nous vous recommandions de mettre FirebaseApp.configure
en haut de votre appli terminant
le lancement de l’appel dans votre délégué d’application.
Mais où va-t-il s’il n’y a pas de délégué d’application?
Nous remplaçons simplement la fonction init appelée au démarrage d’une application
et nous y appelons FirebaseApp.configure.
Cela s’applique même si vous devez utiliser
une application d’interface utilisateur déléguée ensuite,
pour gérer des choses comme les notifications push,
que nous verrons plus tard dans une démo de Chen.
La première nouvelle API que je voulais vous montrer
sert à la journalisation des événements manuels de vue d’écran
dans Google Analytics pour Firebase.
Leur API existante sert à enregistrer automatiquement les vues d’écran
et les classes d’écran pour le kit d’interface utilisateur,
mais comme SwiftUI n’a pas de contrôleur de vue d’interface utilisateur correspondant
sur lequel nous appuyer,
cela ne fonctionne pas avec SwiftUI.
Heureusement, l’an dernier, nous avons ajouté un événement d’affichage manuel de l’écran
afin de surveiller soigneusement le moment où ces événements ont été consignés.
Cela s’intègre lors de l’écriture du kit d’interface utilisateur.
En l’intégrant dans votre viewDid/Appear,
il reste à l’écart la plupart du temps.
Regardons à quoi cela ressemble dans SwiftUI.
Nous pouvons appeler ces API de journalisation manuelle
à chaque fois qu’une vue apparaît à l’aide du modificateur à l’apparition.
Donc, ça fonctionne, mais c’est assez verbeux et ça peut encombrer le code
et affaiblir la structure de votre vue.
Cela limite ce que nous pouvons offrir d’un point de vue API en Objective-C,
mais nous pouvons faire mieux avec Swift.
Cela semble une excellente occasion pour un modificateur de vue personnalisé,
et c’est exactement ce que nous avons construit.
Nous pouvons désormais marquer n’importe quelle vue
avec le modificateur de vue analytique
pour déclarer le nom de la vue, de la classe ou dans ce cas, de la struct,
mais nous faisons correspondre la dénomination analytique existante ici
et tous les paramètres supplémentaires que vous souhaitez enregistrer
lorsque cette vue apparaît à l'écran.
Et grâce aux arguments par défaut de Swift, vous pouvez fournir seulement le nom,
le reste est facultatif. Comme dans ce cas,
nous omettons l’argument des paramètres supplémentaires.
Nous sommes vraiment ravis de cette nouvelle façon
de marquer vos vues et d’enregistrer les événements d’affichage.
Une autre amélioration de SwiftUI que nous avons livrée consiste
à créer vos propres vues de messages dans l’application.
Dans cet exemple, nous utilisons le modificateur modalInAppMessage.
La fermeture est un générateur de vue
et les arguments sont le message, qui contient les données
configurées dans la console,
plus le délégué pour notifier le SDK de messagerie dans l'application
des interactions, comme lorsqu’on appuie sur un message ou l’ignore,
afin d’enregistrer les métriques et les impressions.
Il existe des API couvrant chaque type de message,
pouvant fournir des interfaces personnalisées
à partir de vos messages intégrés à l'application, plus facilement que jamais.
Contactez-nous dans la discussion GitHub si vous avez des idées
d’autres assistants SwiftUI que vous aimeriez voir.
La communauté est emballée par Combine et nous ne pouvons pas le lui reprocher.
Nous le sommes aussi. Nous avons reçu des contributions incroyables
des gens de la communauté
et nous avons travaillé nous-mêmes sur certains changements.
Il y a encore du travail à faire dans cet espace
mais voici un aperçu de ce à quoi vous pouvez vous attendre.
Il s’agit d’un éditeur que nous avons écrit
pour la connexion sur Auth à l’aide d’un e-mail et d’un mot de passe.
Il renvoie les caractéristiques combinées
du résultat des données Auth ou de l'erreur associée.
C'est un peu simplifié, mais dans ce pipeline,
nous extrayons l’utilisateur, en remplaçant toutes les erreurs par nul,
et nous l’attribuons à notre propriété d’utilisateur connecté
représentée dans l’interface utilisateur.
Nous avons plusieurs éditeurs dans différents STK
pour vous aider avec votre flux de données Async.
Vous pouvez suivre les progrès de l’API de Combine
en utilisant le projet GitHub que nous avons mis en place.
Combine n’est pas le seul progrès passionnant
fait sur le code de gestion Async. Nous verrons très bientôt Async/await
dans une version publiée de la chaîne d'outils Swift.
Jetons un autre œil sur la connexion avec e-mail et mot de passe,
en comparant le gestionnaire d’achèvement à Async/await.
Ici, nous utilisons des gestionnaires d’achèvement pour gérer le flux de contrôle.
Au sein de ce gestionnaire d’achèvement,
nous aimerions peut-être faire plus d’appels asynchrones,
ce qui peut conduire à la fameuse pyramide de la mort.
Comment Async/await transforme-t-il cet appel?
Au lieu de gérer entièrement l'état dans le bloc du gestionnaire d'achèvement,
cela ressemble plus à du code synchrone et c’est plus facile d’y réfléchir.
Nous pouvons continuer à faire de même pour les autres appels Async
et cela sera beaucoup plus simple de maintenir l’état
et de s’assurer que les erreurs sont traitées comme il faut.
Maintenant, j’aimerais redonner la parole à Chen pour une démo passionnante.
- Merci, Ryan.
Voyons maintenant comment vous pouvez créer
une application indépendante pour montre avec Firebase.
Supposons que vous souhaitiez suivre
votre consommation quotidienne de café sur votre montre.
Ce qui est bien avec l’application indépendante pour montre,
c’est que les utilisateurs peuvent l’utiliser sans avoir besoin
de synchroniser à partir de leurs téléphones.
Firebase facilite le développement de votre application pour montre
en connectant la montre directement au service Firebase Cloud.
Actuellement, nous avons plusieurs produits
bénéficiant d’un support communautaire pour WatchOS
afin que vous puissiez, par exemple, envoyer des notifications push
depuis la console Firebase directement vers votre application pour montre.
Synchronisez la progression de votre consommation de café
avec notre base de données en temps réel
sans téléphone compagnon.
Ou téléchargez l’image depuis le stockage cloud directement sur votre montre.
Il faut savoir que les applications que vous configurez sur la console
doivent correspondre individuellement aux applications dans Apple Store Connect.
Si l’application couvre plusieurs plates-formes,
utilisez une seule application poreuse
et le fichier plist d’informations sur les services Google
pour toutes les plates-formes sur lesquelles l’application s’exécute.
Cela s'applique également aux extensions d'application iOS.
Par exemple, si une application a une application iOS,
une application Mac et la cible du widget,
vous pouvez simplement importer le fichier d’informations plist
des serveurs Google de l’appli principale vers toutes les cibles.
Maintenant que vous avez configuré votre produit Firebase
et importé les fichiers plist dans du code X,
revenons à la méthode pour envoyer
des notifications push directement sur votre application pour montre.
Ici, nous utilisons le dernier cycle de vie SwiftUI.
Vous remarquerez donc qu'il n'y a pas de délégué d'extension disponible.
En effet, par défaut, un cycle de vie SwiftUI
n'inclut aucun délégué de type d'application ou d'extension.
Ici, vous pouvez utiliser l’adaptateur de délégué WKExtension
pour injecter le délégué dans votre application, où vous pouvez ajouter du code
pour demander les autorisations de notification push WatchOS
et gérer toutes les API des SDK Firebase
qui nécessitent l’existence d’un délégué d’application.
Dans ce cas présent, vous devez définir un apnsToken sur le SDK de messagerie.
Dans le passé, cette étape était gérée automatiquement par messagerie
lorsque le swizzling était activé.
Cependant, comme le swizzling est devenu plus fragile,
nous ne recommandons plus cette approche sur WatchOS.
Au lieu de cela, vous devez mettre en œuvre un acte enregistré
pour la méthode de notifications à distance du délégué WKExtension
afin de définir manuellement apnsToken sur la messagerie.
La même chose s’applique à l’application iOS si vous utilisez un cycle de vie SwiftUI.
Vous devez utiliser l’adaptateur délégué d’application de l’interface utilisateur
pour injecter votre propre délégué d’application
à partir du kit d’interface utilisateur.
Ensuite, vous pouvez implémenter du code nécessitant l’existence d’un délégué d’appli.
Je vais vous montrer un extrait de code pour télécharger une jolie image scintillante
directement sur votre appli pour montre. Nous utilisons ici le stockage Firebase.
Avez-vous remarqué que le même code peut aussi s’exécuter sur votre appli iOS?
Oui, car le stockage Firebase
ne nécessite pas d’API de clé de surveillance spéciale comme la messagerie.
Vous pouvez avoir un code presque identique
pour vos applications WatchOS, iOS, tvOS, macOS.
Nous avons également débloqué la prise en charge des extensions d’application
car elles sont vraiment utiles pour aider les utilisateurs
à accéder à votre application et à faire plus de choses amusantes.
Prenons le widget comme exemple.
L’extension de widget est un excellent moyen de présenter les informations de votre appli
et d’inciter davantage les utilisateurs à cliquer dessus.
Voici un extrait de code où vous pouvez tirer des images
en utilisant le stockage vers votre extension de widget.
Avec cela, vous obtenez aussi une image scintillante sur votre kit de widgets.
C’est un bon moyen de montrer aux utilisateurs des informations clés
de votre application au lieu d’une icône basique, ce qui est bien.
Voilà.
Nous espérons que vous avez aimé créer des applications Apple avec nous.
Jetez un œil à notre dépôt GitHub.
Vous y trouverez beaucoup d’informations utiles.
Faites des essais, suivez les bugs et lancez des discussions sur GitHub.
Nous avons hâte de voir ce que vous pourrez créer avec Firebase.
(musique éléctro entraînante)