Skip to main content

Compréhension des applications Forcedroid

Objectifs de formation

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

  • Décrire le fonctionnement global du kit de développement Mobile SDK Salesforce natif pour une application Android
  • Identifier deux classes principales d’une application forcedroid
  • Citer les tâches que l’objet SalesforceSDKManager gère pour vous

Vue d'ensemble du flux de l'application

Vous avez créé et exécuté une nouvelle application forcedroid. Vous vous demandez ce qu’il a fait fonctionner ?

Voici un diagramme qui montre une vue d’ensemble du flux de démarrage de l’application.

Flux d'application Android

Dans votre application, « Objet application » est une instance de votre classe MainApplication, et « Activité principale » représente votre classe MainActivity. La classe MainApplication crée les composants de base de votre application, puis transmet le contrôle à l’objet unique MobileSyncSDKManager. MobileSyncSDKManager- une sous-classe de SalesforceSDKManager - lance ensuite le flux de connexion de Salesforce et, si l’authentification de l’utilisateur réussit, transmet le contrôle à la classe MainActivity. MainActivity instancie et affiche tout ce qui figure sur l’écran de votre vue de liste.

Les codes secrets, la connexion, la déconnexion et la mise à jour sont des tâches gérées par le singleton MobileSyncSDKManager. Les objets de classe interne se chargent des protocoles OAuth. Comme vous pouvez le constater, la partie du code secret du flux est facultative. Elle se manifeste uniquement si votre application connectée active les codes secrets, et un administrateur Salesforce peut réexaminer cette stratégie à tout moment. Dans tous les cas, ne vous souciez pas des codes secrets. Le kit de développement Mobile SDK assure la totalité de l’implémentation en arrière-plan.

Qu’est-ce qu’une application Forcedroid ?

Une application forcedroid implémente seulement une fonctionnalité de base. L’utilisateur peut basculer entre l’affichage d’une liste de Contacts et d’une liste de Comptes, rien de plus. Cependant, l’application vous aide à explorer vos propres idées inédites. Vous pouvez améliorer votre application en :
  • Exécutant des opérations CRUD (créer, lire, mettre à jour, supprimer) sur des enregistrements Salesforce
  • Ajoutant des activités personnalisées
  • Appelant d’autres composants
  • Exécuter n’importe quelle autre fonction que la portée de votre projet, votre propre imagination et la technologie actuelle le permettent

Lorsque forcedroid crée une application native, il fait une copie d’un projet modèle du kit de développement Mobile SDK et le personnalise pour correspondre à votre entrée de ligne de commande. Examinons quelques éléments standard produits :

Chaque application forcedroid définit deux classes Android publiques :
  • Une classe d'application qui étend android.app.Application. Cette classe sert de point d’entrée de l’application. Dans votre application, cette classe est nommée MainApplication.
  • Une classe d’activité principale qui étend android.app.Activity. Cette classe définit un écran et contient la majeure partie de la logique personnalisée de l’application. Dans les applications forcedroid, cette classe est nommée MainActivity. Elle étend SalesforceActivity, qui étend à son tour android.app.Activity.

Comme avec n’importe quelle application Android, le fichier AndroidManifest.xml indique la configuration de l’application, en spécifiant la classe d’application et toutes les classes d’activité.

La classe d’application

Votre classe d’application effectue deux tâches principales :

  • Remplace la méthode Android Application.onCreate ().
  • Dans le remplacement de onCreate () :
    • appelle la méthode de la super-classe onCreate ().
    • Initialise le kit de développement mobile Salesforce en appelant initNative () sur l’objet de gestionnaire du kit de développement (MobileSyncSDKManager).
    • fournit du code commenté facultatif que vous pouvez rétablir pour utiliser votre application en tant que fournisseur d’identité Salesforce ;
    • fournit du code commenté facultatif que vous pouvez rétablir pour prendre en charge les notifications automatiques.
Examinons rapidement le code.
  1. Dans l’écran de bienvenue d’Android Studio, sélectionnez Import project (Eclipse ADT, Gradle, etc.). Si Android Studio est déjà ouvert, vous avez également la possibilité de cliquer sur File (Fichier) | Open… (Ouvrir…).
  2. Accédez au répertoire cible que vous avez spécifié à l’invite de commande forcedroid, puis sélectionnez-le (astuce : le répertoire cible est « TrailAndroidApps », si toutefois vous avez respecté les règles).
  3. Cliquez sur Choose.
  4. Lorsque la fenêtre d’édition d’Android Studio s’affiche, ouvrez la vue de projet (View (Afficher) Tool Windows (Outil Windows) Project (Projet)).
  5. Dans la fenêtre Project (Projet), développez app | java | com.mytrail.android, puis double-cliquez sur MainApplication.

La classe MainApplication est très simple. Elle définit un remplacement d’une méthode de classe de base unique, onCreate(). Quelles sont les autres fonctions du remplacement ? Il appelle la méthode OnCreate() de la super classe, puis initialise l’objet singleton MobileSyncSDKManager.

/**
 * Application class for our application.
 */
public class MainApplication extends Application {

	@Override
	public void onCreate() {
		super.onCreate();
		MobileSyncSDKManager.initNative(getApplicationContext(), MainActivity.class);

              /*
               * Uncomment the following line to enable IDP login flow. This will allow the user to
               * either authenticate using the current app or use a designated IDP app for login.
               * Replace 'idpAppURIScheme' with the URI scheme of the IDP app meant to be used.
               */
		// MobileSyncSDKManager.getInstance().setIDPAppURIScheme(idpAppURIScheme);

		/*
		 * Un-comment the line below to enable push notifications in this app.
		 * Replace 'pnInterface' with your implementation of 'PushNotificationInterface'.
		 * Add your Google package ID in 'bootonfig.xml', as the value
		 * for the key 'androidPushNotificationClientId'.
		 */
		// SalesforceSDKManager.getInstance().setPushNotificationReceiver(pnInterface);
	}
}
Une fois l’objet MobileSyncSDKManager initialisé, il disparaît et vous ne revoyez plus la classe MainApplication. Notez que MobileSyncSDKManager nécessite deux éléments pour s’initialiser :
  • Un contexte d’application, car il doit trouver la configuration de votre application.
  • Une référence à la classe d’activité principale, MainActivity.class, que MobileSyncSDKManager utilise à la fin du flux de connexion pour déclencher la logique personnalisée de votre application.
Avec cette petite quantité de code gratuit, votre application obtient le code secret, la connexion et la déconnexion, OAuth et le cryptage des données de l’utilisateur. Une bonne affaire, n’est-ce pas ?

La classe Activité principale

Fort heureusement, forcedroid est suffisamment intelligente, votre classe MainActivity peut étendre SalesforceActivity. C’est une chance, car de nombreuses actions sont ainsi automatiquement exécutées pour vous. Par exemple, SalesforceActivity interrompt et reprend automatiquement les événements, y compris les nouvelles saisies de code secret si nécessaire. Si vous aviez utilisé à la place la classe de base d’activité non-Salesforce (stratégie pas interdite, mais pas non plus recommandée), vous auriez dû écrire le code vous-même. Vous pouvez définir autant de classes d’activité que votre application l’exige. Cependant, pour chaque activité, il est préférable d’étendre une classe de base du kit de développement Mobile SDK, telle que SalesforceActivity ou SalesforceListActivity.

La classe MainActivity se charge d’envoyer une requête REST à Salesforce, puis de traiter la réponse. Elle utilise les enregistrements qu’elle reçoit de Salesforce pour renseigner une vue de liste. Elle fournit également deux boutons qui permettent à l’utilisateur d’interroger les Comptes ou bien les Contacts, un bouton pour effacer l’affichage de l’enregistrement et un autre pour se déconnecter.

Nous verrons plus en détail l’interaction REST ultérieurement. Pour le moment, examinons où et comment ces boutons d’interface utilisateur sont configurés.
  1. Dans la fenêtre du projet Android Studio, développez MyTrailNative | res | layout, puis double-cliquez sur main.xml.
  2. En bas de la fenêtre de l’éditeur, sélectionnez l’onglet Text.
L’onglet Text affiche une fenêtre composée à droite d’un concepteur visuel et à gauche du fichier de configuration XML de la vue. Un clic sur la zone du concepteur visuel sélectionne sa configuration XML à gauche. Si vous cliquez par exemple sur le bouton FETCH CONTACTS, l’éditeur sélectionne le nœud <LinearLayout>/<Button>. Les attributs du noeud spécifient les caractéristiques du bouton, l’apparence, identification et le comportement. Pour plus d’informations sur la configuration de l’interface utilisateur, consultez la documentation des développeurs Android.
Si vous cliquez sur l’en-tête de la vue, par exemple sur le bouton Logout, l’éditeur sélectionne un nœud <include> :
<include layout="@layout/header" />
Ce nœud indique que l’en-tête est défini avec un autre fichier XML. D’après l’attribut layout, vous pouvez trouver header.xml dans le même chemin que main.xml. Plutôt simple !

Le fichier Manifest de l’application

Le fichier AndroidManifest.xml de votre projet indique la configuration de base de l’application : son nom, son icône, l’activité principale, les versions d’API Android minimales et cibles, etc. Examinez-le !
  1. Dans la fenêtre Android Studio Project, agrandissez application.
  2. Double-cliquez sur AndroidManifest.xml.
Dans le nœud racine <manifest>, juste après la déclaration de l’espace de noms, le nom de package de votre application est déclaré :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.mytrail.android"
    android:versionCode="1"
    android:versionName="1.0"
    android:installLocation="internalOnly">
L’élément racine <manifest> contient un nœud <application> qui définit la configuration de base de votre application. Au niveau supérieur, ce nœud définit l’attribut qui indique à Android le nom de la classe de démarrage de l’application forcedroid.
<application android:icon="@drawable/sf__icon"
    android:label="MyTrailNative"
    android:name=".MainApplication"
    ...
Le préfixe « . » indique à Android d’ajouter le nom de package de l’application, com.mytrail.android, au chemin de cette classe.

De plus, chaque activité que vous ou forcedroid définissez a une description ici. Par exemple, ici le nœud unique application/activity représente la première activité qui s’affiche après la connexion. Comme vous pouvez le constater, la propriété android:name de l’activité référence le nom de classe de votre activité principale. Voici le fragment XML application/activity d’un fichier AndroidManifest.xml forcedroid.

<!-- Launcher screen -->
<activity android:name=".MainActivity"
    android:label="@string/app_name"
	android:theme="@android:style/Theme.NoTitleBar.Fullscreen">
	<intent-filter>
		<action android:name="android.intent.action.MAIN" />
		<category android:name="android.intent.category.LAUNCHER" />
	</intent-filter>
</activity>

Toutes les autres informations du fichier manifest par défaut correspondent à la configuration Android standard. Comme avec n’importe quelle application Android, vous pouvez ajouter les propres composants de votre application au nœud <application>, notamment les activités personnalisées, les services et les récepteurs.

Vous avez découvert ce que contient une application forcedroid. Examinons maintenant les informations que vous êtes impatient de connaître : comment accéder aux données Salesforce.

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires