Suivez votre progression
Accueil Trailhead
Accueil Trailhead

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 le contrôleur d'affichage racine oriente le flux d'exécution

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 SDK n’est qu’une application iOS classique. Vous pouvez résumer son architecture avec les termes Modèle-Vue-Contrôleur :

  • Modèle correspond au schéma de la base de données Lightning Platform.
  • 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 de contrôleur du kit de développement Mobile SDK Salesforce et de classes de contrôleur personnalisées dans votre application.

Comme toutes les applications iOS, les applications natives du kit de développement Mobile SDK commence par un module principal standard qui définit 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 12.4 définissent également trois classes que vous pouvez personnaliser.

AppDelegate
Gère l’initialisation et l’authentification des utilisateurs du kit de développement Mobile SDK. Si l’authentification réussit, il passe le contrôle à RootViewController.
InitialViewController
Conteneur de l’écran de connexion de Salesforce
RootViewController
Point d’entrée de votre application

AppDelegate s’en remet à un objet partagé gestionnaire de kit de développement pour coordonner les tâches de code secret et d’authentification Salesforce. Le diagramme suivant illustre le flux de démarrage d’une application native utilisant le gestionnaire de kit de développement le plus simple, SalesforceManager.

Diagramme du flux de l'application

Par défaut, les applications natives forceios utilisent MobileSyncSDKManager comme classe de gestionnaire de kit de développement. 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. Ces événements peuvent inclure :

  • Application de la configuration de votre application
  • Validation d’un code secret d’application (facultatif)
  • Exécution de la connexion et de l’authentification à Salesforce
  • Lancement du kit de développement Mobile SDK Salesforce et 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. Les applications natives du kit de développement mobile utilisent une sous-classe spécialisée de la classe Swift SalesforceManager.

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

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

Ici, vous pouvez constater que l’application initialise le kit de développement mobile. Par exemple, dans une application Swift, vous appelez initializeSDK() sur l’objet MobileSyncSDKManager. En interne, l’application configure des gestionnaires pour les événements de lancement, tels que l’authentification de l’utilisateur, les échecs de saisie du code PIN et d’autres états d’erreur. Sauf dans des cas extrêmes, vous n’êtes jamais impliqué directement dans ces événements.

Une fois le kit de développement mobile initialisé, la méthode init appelle une classe d’aide à l’authentification pour configurer ce qui se produit lorsque l’utilisateur actuel se déconnecte. Les fonctions principales de la classe d’assistance sont la réinitialisation de l’affichage et le redémarrage de l’application.

Le reste de la classe AppDelegate met en œuvre des 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 la marche à suivre pour le cas d’utilisation prévu. Vous pouvez par exemple :

Personnaliser la barre de navigation
Suivez les instructions commentées dans la méthode application(_:didFinishLaunchingWithOptions:).
Inscrire votre application aux notifications automatiques
Suivez les instructions commentées dans la méthode application(_:didFinishLaunchingWithOptions:).
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, les tentatives de l’application pour s’inscrire aux notifications automatiques échouent. 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 comme fournisseur d’identité pour vos autres applications du kit de développement mobile ? Vous pouvez activer la fourniture d’identité en suivant les instructions commentées de 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.

Classes AppDelegate et RootViewController

La classe AppDelegate est comparable au centre de contrôle Kit de développement mobile de l’application, ou au moins à sa plate-forme de lancement. Elle gère l’initialisation et la connexion de l’application, puis passe le contrôle de l’exécution à une vue racine. Examinons le code source pour déterminer comment l’application affiche ses vues.

  1. Dans Xcode, ouvrez le fichier AppDelegate.swift.
  2. Recherchez « initializeAppViewState ».
    L’implémentation de la méthode d’instance est affichée ? Examiner l’avant-dernière ligne de la méthode :
    self.window!.rootViewController = InitialViewController(nibName: nil, bundle: nil)

    Ce code définit la propriété self.window.rootViewController sur un objet InitialViewController qui vient d’être créé. La classe InitialViewController est définie dans votre application, elle est plutôt rare et sans intérêt. Cette vue, la première affichée, sert de conteneur pour les écrans de connexion de Salesforce. Voilà tout ce que vous devez savoir.

  3. Recherchez « setupRootViewController ».
    Si vous vous rendez sur tous les résultats, vous constatez que :
    • Il est appelé dans la méthode init de AppDelegate.
    • Il est implémenté comme suit :
      func setupRootViewController()
      {
          let rootVC = RootViewController(nibName: nil, bundle: nil)
          let navVC = UINavigationController(rootViewController: rootVC)
          self.window?.rootViewController = navVC
      }

Dans la méthode d’instance setupRootViewController, AppDelegate il crée une instance RootViewController en tant que première vue réelle de l’application. RootViewController est une classe personnalisée définie par ce modèle de Kit de développement mobile. Vous avez remarqué l’intérêt du nom « RootViewController » ? Il ressemble à la propriété rootViewController de la fenêtre de l’application. Coïncidence ? Probablement pas, mais ce nommage est pratique, même s’il n’est pas obligatoire. En effet, si vous n'aimez pas le nom de la classe, vous pouvez utiliser l’outil de refactorisation de Xcode pour le renommer dans cette application.

Votre contrôleur de vue racine est le point de départ de l’interface utilisateur de votre application. Avant de l’attribuer à la propriété rootViewController, il est emballé dans un objet UINavigationController. Ce wrapper gère une pile de vues et vous permet de naviguer entre elles. UINavigationController a été initialisé avec RootViewController. Par conséquent, RootViewController reste toujours en bas de la pile de l’interface utilisateur. Vous pouvez facilement ajouter d’autres vues au-dessus de RootViewcontroller avec la méthode pushViewController(_:animated:) de UINavigationController.

Quelles sont les autres fonctions de la classe RootViewController ? Elle configure une vue de tableau, opération standard pour une classe qui hérite de UITableViewController. RootViewController utilise également l’instance partagée SalesforceRestAPI pour traiter les réponses et les requêtes de l’API REST Salesforce. Pour commencer, examinons le comportement de UITableViewController.

La classe UITableViewController

Une fois que la classe RootViewController est devenue votre contrôleur de vue racine, elle affiche l’écran principal de votre application. Examinons comment cette classe personnalise la vue principale de l’application.

RootViewController hérite de la classe UITableViewController, ce qui signifie qu’elle affiche automatiquement un tableau de données. RootViewController apporte quelques personnalisations mineures à des détails de l’interface utilisateur et, à l’exécution, charge les données Salesforce dans sa propriété tableView. UITableViewController présente en réalité la vue personnalisée.

Pour observer comment RootViewController personnalise la présentation du tableau :
  1. Dans Xcode, ouvrez RootViewController.swift.
  2. Faites défiler jusqu’à la méthode UITableViewController remplacée suivante :
    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell
L’extrait le plus intéressant du code de cette méthode est cette séquence de deux lignes :
// Configure the cell to show the data.
let obj = dataRows[indexPath.row]
cell.textLabel?.text = obj["Name"] as? String
Ce code affiche un nom d'un dictionnaire dans une cellule de tableau. Le dictionnaire (obj) a été extrait du tableau dataRows. Vous vous demandez probablement : Qu’est-ce que le tableau dataRows et quand est-il apparu ? Dans la prochaine unité, nous allons découvrir que la classe RootViewController gère également les requêtes et les réponses REST. Par exemple, elle définit que dataRows contient les enregistrements Salesforce obtenus à partir d’une réponse REST. Ainsi, cet exemple de code définit l’étiquette de texte de la cellule sur une valeur Nom à partir d’un enregistrement Salesforce. Pour établir une correspondance un-à-un, le code utilise le numéro de ligne de la cellule actuelle, indexPath.row, en tant qu’index dans le tableau.