Compréhension des applications natives Forceios

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

Comprendre le fonctionnement général d'une application native Salesforce iOS
Comprendre la suite d'événements se produisant au cours du lancement de l'application
Comprendre comment AppDelegate et SceneDelegate gèrent le flux d’exécution

Vidéo de démonstration Trail Together

Vous souhaitez être guidé pas à pas par un expert pendant que vous travaillez sur cette étape ? Regardez cette vidéo qui fait partie de la série Trail Together.

(Ce clip commence à 14 min 49 s, au cas où vous voudriez revenir en arrière et regarder à nouveau le début de l’étape.)

Vue d'ensemble du flux de l'application

Examinons de plus près les applications iOS natives.

À première vue, une application native du kit de développement mobile n’est qu’une application iOS classique. Vous pouvez résumer son architecture avec les termes Modèle-Vue-Contrôleur :

Le modèle correspond au schéma de la base de données de la plate-forme Salesforce.
Vue provient des fichiers nib et d'implémentation de votre projet.
La fonctionnalité Contrôleur se présente sous la forme de classes iOS Cocoa Touch, de classes du kit de développement Mobile SDK Salesforce et de classes personnalisées dans votre application.

Comme toutes les applications iOS, les applications natives du kit de développement mobile sont tout d’abord constituées d’un module principal standard définissant la boucle d’événements principale. Xcode génère ce fichier, que la plupart des personnes n’ont aucune raison de toucher.

Les applications modèle du kit de développement mobile pour iOS 13 définissent également les classes suivantes, que vous pouvez personnaliser.

La classe AppDelegate gère l’initialisation du kit de développement mobile.
La classe SceneDelegate gère les événements du cycle de vie des scènes et l’authentification des utilisateurs. Elle fait appel à un objet gestionnaire partagé du kit de développement pour coordonner les tâches Salesforce relatives aux codes secrets et à l’authentification. Si l’authentification aboutit, le contrôle est transmis au contrôleur de vue racine de votre application.
La classe InitialViewController est le conteneur de la page de connexion à Salesforce.
Le contrôleur de vue racine est une classe personnalisée qui lance le contenu de votre application.

Le diagramme suivant illustre le flux de démarrage d’une application native utilisant le gestionnaire de kit de développement le plus complet, MobileSyncSDKManager. Ce gestionnaire active l’authentification et inclut les fonctionnalités hors ligne du kit de développement mobile.

Par défaut, les applications natives forceios utilisent MobileSyncSDKManager, une sous-classe spécialisée de SalesforceManager, pour initialiser le kit de développement mobile. Cette classe donne accès à l’ensemble des fonctionnalités du kit de développement mobile.

Flux de lancement de l'application

Lorsqu’un client ouvre votre application, une séquence relativement complexe d’événements se produit. Il peut notamment s’agir des événements suivants :

La mise en œuvre de la configuration de votre application.
L’initialisation du kit de développement mobile Salesforce.
La validation d’un code secret d’application (facultatif)
L’exécution de la connexion et de l’authentification à Salesforce.
Le lancement de votre application.

Une marge de manœuvre raisonnable (par exemple, la possibilité de reporter la connexion à Salesforce après le démarrage) complique la gestion de ces événements. Heureusement, le kit de développement Mobile SDK vous aide à ne pas vous emmêler les pinceaux en vous fournissant l’objet de gestion du kit. Cet objet applique la séquence d’amorçage appropriée. Ainsi, vous n’avez pas à vous soucier de la plupart des événements de démarrage.

La manière dont vous initialiserez le kit de développement mobile dépend du langage dans lequel vous développez.

La plupart du code utilisant le gestionnaire du kit de développement existe dans une nouvelle application forceios. Examinons ce code.

Dans Xcode, ouvrez le fichier AppDelegate.swift.
Accédez à la méthode init.

Ici, vous pouvez constater que l’objet MobileSyncSDKManager initialise le kit de développement mobile en appelant initializeSDK().

override init() {
    super.init()
    MobileSyncSDKManager.initializeSDK()
}

En interne, cette méthode transmet le nom de la classe MobileSyncSDKManager à la classe « super » (ou parent), c’est-à-dire SalesforceManager. En arrière-plan, SalesforceManager configure des observateurs pour les événements relatifs au lancement de l’application et à son cycle de vie, tels que l’authentification de l’utilisateur, les échecs de saisie du code PIN et l’état de premier plan. Sauf dans des cas extrêmes, vous n’êtes jamais impliqué directement dans ces événements.

SalesforceManager effectue également deux autres actions importantes :

il crée une instance partagée de lui-même, qui est conservée pendant le reste du cycle de vie de l’application ;
il se configure pour que l’application obtienne toujours une instance de MobileSyncSDKManager afin d’effectuer les tâches relatives au gestionnaire du kit de développement qui lui incombent.

Par conséquent, si votre application appelle les méthodes du gestionnaire du kit de développement, MobileSyncSDKManager a la possibilité de personnaliser leurs actions.

Ces modifications ont-elles un impact sur votre code ? Oui ! Votre code doit toujours appeler les méthodes du gestionnaire du kit de développement sur l’instance partagée suivante :

MobileSyncSDKManager.shared

Nous observerons un exemple de ceci sous peu, mais commençons par examiner de plus près la classe AppDelegate de votre nouvelle application.

AppDelegate Class

Une fois le kit de développement mobile initialisé, le reste de la classe AppDelegate implémente les méthodes de protocole UIApplicationDelegate, que vous pouvez personnaliser selon vos besoins. Chacune de ces méthodes contient des instructions commentées vous indiquant exactement ce que vous pouvez faire dans le cadre du cas d’utilisation prévu. Ainsi, vous pouvez par exemple réaliser les actions suivantes :

Personnaliser une nouvelle session de scène. Pour spécifier votre propre configuration de session de scène, personnalisez la valeur renvoyée par la méthode application(_:configurationForConnecting:options:).
Nettoyer les ressources lorsque le client ignore une session de scène. Utilisez la méthode application(_:didDiscardSceneSessions:) pour libérer les ressources personnalisées ajoutées par votre application aux scènes ignorées.
Inscrire votre application aux notifications automatiques. Suivez les instructions commentées dans la méthode application(_:didFinishLaunchingWithOptions:). Les notifications automatiques du kit de développement mobile dans iOS requièrent une extension pour gérer le déchiffrement. Si vous souhaitez voir un exemple, consultez iOSNativeSwiftEncryptedNotificationsTemplate dans le référentiel GitHub Modèles SalesforceMobileSDK.
Inscrire l’appareil du client aux notifications automatiques. Si vous avez réalisé l’inscription aux notifications automatiques, la méthode de rappel application(_:didRegisterForRemoteNotificationsWithDeviceToken:) vous transmet un jeton d’appareil. Pour enregistrer ce jeton d’appareil dans le kit de développement mobile et le gestionnaire de notifications automatiques Salesforce, suivez les instructions commentées.
Être informé de l’échec de l’inscription aux notifications automatiques. Parfois, une tentative de l’application pour s’inscrire aux notifications automatiques échoue. Dans ce cas, vous recevez alors un message d’erreur dans la méthode application (_:didFailToRegisterForRemoteNotificationsWithError :) et pouvez prendre les mesures que vous souhaitez.
Activer un fournisseur d’identité. Vous envisagez d’utiliser cette application en tant que fournisseur d’identité pour vos autres applications issues du kit de développement mobile ? Dans ce cas, suivez tout d’abord les instructions commentées figurant dans la méthode application(openURL:options:). Pour mettre pleinement en œuvre cette fonctionnalité, configurez vos applications comme décrit dans le Guide de développement du kit de développement mobile.

Classe SceneDelegate

La classe SceneDelegate est comme une plate-forme de lancement pour votre application. Elle initie la connexion à Salesforce et transmet le contrôle à votre contenu personnalisé, mais ce n’est pas tout.

Dans les applications Swift pour iOS 13 et versions ultérieures, la classe SceneDelegate occupe une place centrale en tant que gestionnaire des vues SwiftUI. SceneDelegate traite les événements du cycle de vie d’une scène, tels que :

la connexion à l’application ;
l’accès au premier plan ou à l’arrière-plan ;
la gestion de l’activation ou de la désactivation ;
le redimensionnement.

Vous pouvez personnaliser votre classe SceneDelegate en déterminant vous-même la manière dont ces événements sont gérés. L’application modèle vous facilite même la tâche : elle fournit des commentaires dans les principaux gestionnaires d’événements qui vous indiquent comment procéder.

Dans le kit de développement mobile, la classe SceneDelegate est l’élément permettant à vos ressources personnalisées de prendre le contrôle. L’application modèle utilise SceneDelegate pour réaliser les actions suivantes :

Afficher la page de connexion à Salesforce lorsque cela est nécessaire (avant qu’un utilisateur ne se connecte ou à chaque fois qu’il se déconnecte).
Réinitialiser l’état de vue lorsque l’utilisateur actuel se déconnecte.
Importer les fichiers de configuration relatifs aux fonctionnalités hors ligne de SmartStore et Mobile Sync.
Définir la vue racine de la fenêtre sur la première vue personnalisée de l’application.

Examinons le code source pour déterminer comment l’application affiche ses vues.

Dans Xcode, ouvrez le fichier SceneDelegate.swift.
En haut de la classe, vous pouvez voir la première définition de fonction.
```
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
    self.window = UIWindow(frame: windowScene.coordinateSpace.bounds)
    self.window?.windowScene = windowScene
    AuthHelper.registerBlock(forCurrentUserChangeNotifications: {
        self.resetViewState {
            self.setupRootViewController()
        } 
    })
}
```
Cette méthode constitue la première étape par laquelle passent les scènes en cours d’initialisation. Les trois premières lignes consistent en du code standard. Elles « connectent » la scène à l’application ; en d’autres termes, elles relient la scène à une fenêtre d’application afin qu’elle puisse être affichée. L’instruction finale de cette méthode configure la classe AuthHelper du kit de développement mobile pour qu’elle traite les notifications de modification de l’utilisateur actuel. Le gestionnaire en lui-même constitue le bloc interne dans l’appel de méthode AuthHelper.registerBlock(_:). Il appelle deux méthodes privées personnalisées : resetViewState(_:) et setupRootViewController(). La méthode resetViewState(_:) restaure votre application dans un état parfait, tel qu’il était au démarrage, en supprimant tout état de vue existant, puis en restaurant la vue racine d’origine. Nous étudierons setupRootViewController() dans un instant.
Recherchez « func initializeAppViewState ». Dans cette implémentation de méthode, observez l’avant-dernière ligne :
```
self.window?.rootViewController = InitialViewController(nibName: nil, bundle: nil)
```
Ce code définit la propriété self.window?.rootViewController sur un objet InitialViewController venant d’être créé. La classe InitialViewController est définie dans votre application, elle est plutôt rare et sans intérêt. En effet, cette vue, qui est la première affichée, sert simplement de conteneur pour les écrans de connexion de Salesforce. Voilà tout ce que vous devez savoir. Cette méthode est appelée à partir du gestionnaire d’événements sceneWillEnterForeground.

Recherchez « func setupRootViewController ». Il est implémenté comme suit :

func setupRootViewController() {
    // Setup store based on config userstore.json
    MobileSyncSDKManager.shared.setupUserStoreFromDefaultConfig()
    // Setup syncs based on config usersyncs.json
    MobileSyncSDKManager.shared.setupUserSyncsFromDefaultConfig()
    self.window?.rootViewController = UIHostingController(
        rootView: AccountsListView()
    )
}

La méthode setupRootViewController() réalise plusieurs étapes de configuration importantes.

Elle charge les fichiers de configuration relatifs aux fonctionnalités hors ligne SmartStore et Mobile Sync.
Elle définit le contrôleur de vue racine de la fenêtre sur AccountsListView, une vue SwiftUI personnalisée affichant une liste des noms des comptes de l’organisation de l’utilisateur.

Votre contrôleur de vue racine constitue le point de départ du contenu de votre application. Pour indiquer cela de manière claire à iOS, setupRootViewController() crée un objet UIHostingController et initialise sa propriété rootView sur une instance de la première vue de votre application. Le contrôle de l’application est ensuite transmis à votre code personnalisé. Vous pouvez réutiliser les classes de vue et de modèle de l’application modèle ou les remplacer par vos propres solutions. Comme expliqué dans la section suivante, vous appellerez toujours les API du kit de développement mobile pour accéder aux ressources Salesforce. Toutefois, à ce stade, vous êtes désormais le seul à gérer le flux, le contenu et le rôle de l’application. Faites preuve de créativité.

Ressources