Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Grundlegendes zu nativen Forceios-Anwendungen

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

  • Erläutern des Gesamt-Flows einer nativen iOS Salesforce-Anwendung
  • Erklären des Ereignis-Flows beim Start eine Anwendung
  • Erklären der Steuerung des Ausführungs-Flows durch das Stammansichtssteuerfeld

Übersicht über den Anwendungs-Flow

In diesem Abschnitt wollen wir uns native iOS-Anwendungen näher ansehen.

An der Oberfläche sieht eine native Mobile SDK-Anwendung wie eine gewöhnliche iOS-Anwendung aus. Ihre Architektur können Sie sich nach dem MVC-Prinzip (Model-View-Controller) vorstellen:

  • "Model" bezieht sich auf das Lightning Plattform-Datenbankschema.
  • Die Ansichten ("Views") kommen aus den NIB- und Implementierungsdateien in Ihrem Projekt.
  • Die "Controller"-Funktion beinhaltet iOS Cocoa Touch-Klassen, Salesforce Mobile SDK-Steuerfeld-Klassen und benutzerdefinierte Steuerfeld-Klassen in Ihrer Anwendung.

Wie alle iOS-Anwendungen beginnen native Mobile SDK-Anwendungen mit einem Baustein-Hauptmodul, das die Hauptereignisschleife einrichtet. Xcode erzeugt diese Datei, und die meisten Menschen werden sie auch nie anfassen. Mobile SDK-Vorlagenanwendungen für iOS 12.4 definieren zudem drei Klassen, die Sie anpassen können.

AppDelegate
Verarbeitet die Initialisierung und Benutzerauthentifizierung von Mobile SDK. Bei einer erfolgreichen Authentifizierung übergibt die Klasse die Steuerung an RootViewController.
InitialViewController
Container für den Salesforce-Anmeldebildschirm
RootViewController
Einstiegspunkt für Ihre Anwendung

AppDelegate greift auf das gemeinsam verwendete SDK-Manager-Objekt zurück, um Zugangscode- und Authentifizierungsaufgaben in Salesforce zu koordinieren. Das folgende Diagramm veranschaulicht den Flow beim Hochfahren für eine native Anwendung mit dem einfachsten SDK-Manager SalesforceManager.

Anwendungs-Flow-Diagramm

Native forceios-Anwendungen verwenden standardmäßig MobileSyncSDKManager als SDK-Managerklasse. Diese Klasse stellt die gesamte Palette von Mobile SDK-Funktionen zur Verfügung.

Anwendungsstart-Flow

Wenn ein Kunde Ihre Anwendung öffnet, tritt eine ziemlich komplexe Folge von Ereignissen ein. Das können u. A. folgende Ereignisse sein:

  • Übernahme der Konfiguration Ihrer Anwendung
  • Prüfung eines Anwendungszugangscodes (optional)
  • Ausführung der Anmeldung und Authentifizierung in Salesforce
  • Starten von Salesforce Mobile SDK und Ihrer Anwendung
Ein guter Teil dieses "Spielraums" (z. B. kann selbst die Anmeldung bei Salesforce nach dem Hochfahren abgelehnt werden) macht die Verarbeitung dieser Ereignisse zu einer kniffligen Angelegenheit. Glücklicherweise erspart Ihnen das Mobile SDK dank des SDK-Manager-Objekts größere Unannehmlichkeiten. Dieses Objekt erzwingt die richtige Bootstrap-Reihenfolge, sodass Sie sich um die meisten Startereignisse nicht kümmern müssen.

Wie Sie das Mobile SDK initialisieren, hängt von Ihrer Entwicklungssprache ab. Native Mobile SDK-Anwendungen verwenden MobileSyncSDKManager, eine spezielle Unterklasse der Swift-Klasse SalesforceManager.

Der größte Teil des Codes, der den SDK-Manager verwendet, ist in einer neuen forceios-Anwendung vorhanden. Lassen Sie uns diesen Code näher betrachten.

  1. Öffnen Sie in Xcode die Datei AppDelegate.swift.
  2. Blättern Sie zur init-Methode.

Hier sehen sie die Anwendung, die das Mobile SDK initialisiert. In einer Swift-Anwendung rufen Sie beispielsweise initializeSDK() für das MobileSyncSDKManager-Objekt auf. Intern richtet die Anwendung Handler für Startereignisse wie die Benutzerauthentifizierung, PIN-Code-Fehler und andere Fehler ein. Außer in Extremfällen haben Sie mit diesen Ereignissen nichts zu tun.

Nach der Initialisierung des Mobile SDK ruft die init-Methode eine Authentifizierungs-Hilfsklasse auf, um zu definieren, was bei der Abmeldung des aktuellen Benutzers passiert. Im Prinzip setzt die Hilfsklasse die Ansicht zurück und startet die Anwendung neu.

Die restliche AppDelegate-Klasse implementiert UIApplicationDelegate-Protokollmethoden, die Sie nach Bedarf anpassen können. Jede dieser Methoden enthält kommentierte Anweisungen zu den notwendigen Schritten für den vorgesehenen Anwendungsfall. Beispielsweise haben Sie folgende Möglichkeiten:

Anpassen der Navigationsleiste
Befolgen Sie die kommentierten Anweisungen in der application(_:didFinishLaunchingWithOptions:)-Methode.
Registrieren Ihrer Anwendung für Push-Benachrichtigungen
Befolgen Sie die kommentierten Anweisungen in der application(_:didFinishLaunchingWithOptions:)-Methode.
Registrieren des Kundengerätes für Push-Benachrichtigungen
Wenn Sie für Push-Benachrichtigungen registriert sind, übergibt Ihnen die application(_:didRegisterForRemoteNotificationsWithDeviceToken:)-Rückmeldungsmethode ein Gerätetoken. Um dieses Gerätetoken beim Mobile SDK und dem Salesforce-Manager für Push-Benachrichtigungen zu registrieren, befolgen Sie die kommentierten Anweisungen.
Verbreiten der Nachrichten, wenn die Registrierung für Push-Benachrichtigungen fehlschlägt
Manchmal schlagen die Versuche der Anwendung, sich für Push-Benachrichtigungen zu registrieren, fehl. Sie erhalten eine Fehlermeldung in der application(_:didFailToRegisterForRemoteNotificationsWithError:)-Methode, die Sie nach Wunsch behandeln können.
Aktivieren eines Identitätsanbieter-Service
Haben Sie vor, diese Anwendung als Identitätsanbieter-Service für Ihre anderen Mobile SDK-Anwendungen einzusetzen? Zur Aktivierung des Identitätsanbieter-Service befolgen Sie die kommentierten Anweisungen in der application(openURL:options:)-Methode. Wenn Sie diese Funktion uneingeschränkt implementieren möchten, konfigurieren Sie Ihre Anwendungen wie im Mobile SDK-Entwicklungshandbuch beschrieben.

Die AppDelegate- und RootViewController-Klassen

Die AppDelegate-Klasse ist gewissermaßen das Mobile SDK-Kontrollzentrum der Anwendung – oder zumindest ihre Startrampe. Sie verarbeitet die Initialisierung und Anmeldung der Anwendung und übergibt dann die Ausführungssteuerung an eine Stammansicht. Werfen wir doch mal einen Blick auf den Quellcode, um zu sehen, wie die Anwendung ihre Ansichten darstellt.

  1. Öffnen Sie in Xcode die Datei AppDelegate.swift.
  2. Suchen Sie nach "initializeAppViewState".
    Erkennen Sie die Implementierung der Instanzmethode? Sehen Sie sich nun die nächste bis letzte Zeile der Methode an:
    self.window!.rootViewController = InitialViewController(nibName: nil, bundle: nil)

    Dieser Code setzt die Eigenschaft self.window.rootViewController auf ein neu erstelltes InitialViewController-Objekt an. Die InitialViewController-Klasse ist in ihrer Anwendung definiert, ziemlich spärlich und langweilig. Diese Ansicht – die erste, die angezeigt wird – dient als Container für die Anmeldebildschirme in Salesforce. Das ist alles, was Sie darüber wissen müssen.

  3. Suchen Sie nach "setupRootViewController".
    Wenn Sie sich alle Treffer anschauen, stellen Sie fest:
    • Sie wird in der init-Methode von AppDelegate aufgerufen.
    • Die Implementierung geschieht wie folgt:
      func setupRootViewController()
      {
          let rootVC = RootViewController(nibName: nil, bundle: nil)
          let navVC = UINavigationController(rootViewController: rootVC)
          self.window?.rootViewController = navVC
      }

In der setupRootViewController-Instanzmethode erzeugt AppDelegate eine RootViewController-Instanz als erste echte Ansicht der Anwendung. RootViewController ist eine benutzerdefinierte Klasse, die durch diese Mobile SDK-Vorlage definiert ist. Sehen Sie, wie praktisch der Name "RootViewController" ist? Er klingt stark nach der rootViewController-Eigenschaft des Anwendungsfensters. Zufall? Nicht wirklich, aber diese Benennung ist einfach bequem – wenn auch nicht unbedingt erforderlich. Tatsächlich können Sie, wenn Ihnen dieser Klassenname nicht gefällt, das Refakturierungstool von Xcode verwenden, um den Namen in dieser Anwendung zu ändern.

Ihr Stammansichtssteuerfeld ist der Ausgangspunkt für die UI Ihrer Anwendung. Bevor dieses jedoch der rootViewController-Eigenschaft zugewiesen wird, wird es in einen UINavigationController-Objekt eingebunden. Dieser Wrapper verwaltet einen Stapel von Ansichten und ermöglicht die Navigation zwischen ihnen. Da UINavigationController mit RootViewController initialisiert wurde, bleibt RootViewController stets am unteren Ende des UI-Stapels. Mit der UINavigationController-Methode pushViewController(_:animated:) können Sie einfach weitere Ansichten oberhalb von RootViewcontroller hinzufügen.

Was macht die RootViewController-Klasse sonst noch? Sie konfiguriert eine Tabellenansicht – "Business as usual" für eine Klasse, die UITableViewController übernimmt. RootViewController nutzt zudem die freigegebene Instanz SalesforceRestAPI für die Verarbeitung von Salesforce REST-API-Anforderungen und -Antworten. Lassen Sie uns zunächst das Verhalten von UITableViewController beobachten.

Die UITableViewController-Klasse

Nachdem die RootViewController-Klasse zu Ihrem Stammansichtssteuerfeld geworden ist, zeigt sie den Hauptbildschirm Ihrer Anwendung an. Sehen wir uns an, wie diese Klasse die Hauptansicht der Anwendung anpasst.

RootViewController erbt die UITableViewController-Klasse, sodass sie automatisch eine Datentabelle anzeigt. RootViewController führt einige kleinere Anpassungen an den UI-Details durch und lädt zur Laufzeit Salesforce-Daten in ihre tableView-Eigenschaft. Tatsächlich präsentiert UITableViewController die angepasste Ansicht.

So können Sie mitverfolgen, wie RootViewController die Tabellenpräsentation anpasst:
  1. Öffnen Sie in Xcode RootViewController.swift.
  2. Blättern Sie zur folgenden überschriebenen UITableViewController-Methode:
    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell
Der interessanteste Ausschnitt aus dem Code dieser Methode ist diese zweizeilige Sequenz:
// Configure the cell to show the data.
let obj = dataRows[indexPath.row]
cell.textLabel?.text = obj["Name"] as? String
Dieser Code zeigt einen Namen aus einem Wörterbuch in einer Tabellenzelle an. Das Wörterbuch (obj) wurde aus dem Array dataRows extrahiert. Sie fragen sich vermutlich: Was ist dieses Array dataRows und seit wann ist es vorhanden? In der nächsten Lektion geht es darum, dass die RootViewController-Klasse auch REST-Anforderungen und -Antworten verarbeitet. Sie legt beispielsweise dataRows für die Aufnahme von Salesforce-Datensätzen aus einer REST-Antwort fest. Daher legt dieser Beispielcode die Textbezeichnung der Zelle auf einen Namenswert aus einem Salesforce-Datensatz fest. Um 1:1-Übereinstimmung zu erreichen, verwendet der Code die Zeilennummer der aktuellen Zelle (indexPath.row) als Index in das Array.