Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Comprender las aplicaciones forcedroid

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Describir el flujo general de una aplicación de Salesforce Mobile SDK para Android.
  • Identificar dos clases principales de una aplicación forcedroid.
  • Indicar las tareas que el objeto SalesforceSDKManager controla por usted.

Descripción general del flujo de aplicación

Ha creado y ejecutado una aplicación forcedroid nativa. ¿Se pregunta cómo funciona?

En el siguiente diagrama se incluye una descripción de alto nivel del funcionamiento del flujo de inicio de la aplicación.

Flujo de aplicación Android

En la aplicación, el “objeto de aplicación” es una instancia de la clase MainApplication y la “actividad principal” representa la clase MainActivity. La clase MainApplication crea los componentes básicos de la aplicación y, a continuación, pasa el control al objeto de singleton MobileSyncSDKManager. MobileSyncSDKManager, una subclase de SalesforceSDKManager inicia el flujo de inicio de sesión de Salesforce y, si la autenticación de usuario es correcta, transfiere el control a la clase MainActivity. MainActivity crea una instancia y muestra todo cuanto aparece en la pantalla de vista de lista.

Los códigos de aprobación, el inicio de sesión, el cierre de sesión y la limpieza son tareas que gestiona el singleton MobileSyncSDKManager. Los objetos de clase interna se ocupan de los protocolos OAuth. Como puede ver, la parte del código de aprobación del flujo es opcional. Solo se usa si la aplicación conectada permite códigos de aprobación y un administrador de Salesforce puede revertir esta política en cualquier momento. En cualquier caso, no tiene por qué preocuparse por los códigos de aprobación. Mobile SDK permite una implementación completa en segundo plano.

¿Qué se incluye en una aplicación forcedroid?

Una aplicación forcedroid nativa implementa solo la funcionalidad básica. El usuario puede cambiar entre la visualización de una lista de contactos o una lista de cuentas y eso es todo. Sin embargo, la aplicación es un trampolín para explorar sus increíbles ideas. Puede mejor la aplicación mediante lo siguiente:
  • Realización de operaciones CRUD (crear, leer, actualizar y eliminar) en registros de Salesforce
  • Adición de actividades personalizadas
  • Llamada a otros componentes
  • Realización de cualquier otra operación si lo permiten el ámbito del proyecto, su imaginación y la tecnología actual

Cuando forcedroid crea una aplicación nativa, hace una copia de un proyecto de plantilla de Mobile SDK y la personaliza para que coincida con su entrada de línea de comandos. Vamos a ver algunos de los elementos estándar que crea este molde.

Cada aplicación forcedroid define dos clases Android públicas:
  • Una clase de aplicación que extiende android.app.Application. Esta clase es el punto de entrada de la aplicación. En su aplicación, esta clase se llama MainApplication.
  • Una clase de actividad principal que extiende android.app.Activity. Esta clase define una pantalla y contiene la mayor parte de la lógica personalizada de la aplicación. En las aplicaciones forcedroid, esta clase se llama MainActivity. Extiende SalesforceActivity, que a su vez extiende android.app.Activity.

Como en el caso de cualquier otra aplicación Android, el archivo AndroidManifest.xml designa la configuración de la aplicación, donde se especifican la clase de aplicación y todas las clases de actividad.

Clase de aplicación

Su clase de aplicación realiza dos tareas principales:

  • Sustituye el método Application.onCreate() de Android.
  • En su onCreate() sustituye:
    • Llamadas al método onCreate() de superclase.
    • Inicializa Salesforce Mobile SDK llamando a initNative() en el gestor de objetos del SDK (MobileSyncSDKManager).
    • Proporciona el código comentado opcional que puede reutilizar para emplear su aplicación como un proveedor de identidad de Salesforce.
    • Proporciona código comentado opcional que puede reutilizar para admitir notificaciones distribuidas.
Echemos un vistazo rápido al código.
  1. En la pantalla de bienvenida de Android Studio, seleccione Import project (Eclipse ADT, Gradle, etc.) (Importar proyecto [Eclipse ADT, Gradle, etc.]). O bien, si Android Studio ya está abierto, haga clic en File | Open... (Archivo | Abrir...).
  2. Busque el directorio de destino especificado en el símbolo del sistema de forcedroid y selecciónelo. (Una pista: El directorio de destino es “TrailAndroidApps”, a menos que incumpla las reglas).
  3. Haga clic en Choose (Seleccionar).
  4. Cuando se muestre la ventana de modificación de Android Studio, abra la vista de proyecto (View | Tool Windows | Project [Ver | Ventanas de herramientas | Proyecto]).
  5. En la ventana de proyecto, expanda app | java | com.mytrail.android, y, a continuación, haga doble clic en MainApplication.

La clase MainApplication es bastante sencilla. Define una sustitución de un método de clase de base única, en este caso onCreate(). ¿Qué hace la sustitución? Llama al método de superclase OnCreate() y, a continuación, inicializa el objeto de 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);
	}
}
Una vez inicializado el objeto MobileSyncSDKManager, se excluye y no volvemos a ver la clase MainApplication. Observe que MobileSyncSDKManager requiere dos elementos para inicializarse:
  • Un contexto de aplicación para saber dónde buscar la configuración de su aplicación.
  • Una referencia a la clase de actividad principal (MainActivity.class) que MobileSyncSDKManager usa al final del flujo de inicio de sesión para iniciar la lógica personalizada de la aplicación.
Con esta pequeña cantidad de código abierto, su aplicación obtiene el código de aprobación, el inicio y cierre de sesión, y el cifrado de los datos de usuario. ¿No está nada mal, verdad?

Clase de actividad principal

Por suerte, forcedroid es lo bastante inteligente para que la clase MainActivity extienda SalesforceActivity. Esta buena suerte significa que puede lograr cosas increíbles de forma gratuita. Por ejemplo, SalesforceActivity controla automáticamente la pausa y reanudación de eventos, lo que incluye volver a ingresar el código de aprobación necesario. Si en lugar de esto, hubiera usado una clase base de actividad no proporcionada por Salesforce (lo cual no es un método prohibido, aunque no se recomienda), tendría que escribir el código. Puede definir tantas clases de actividad como requiera la aplicación. No obstante, es una buena idea para cada actividad extender una clase base de Mobile SDK, como SalesforceActivity o SalesforceListActivity.

La clase MainActivity está ocupada con el envío de una solicitud REST a Salesforce y el procesamiento de la respuesta. Usa los registros que recibe de Salesforce para completar una vista de lista. Además, proporciona dos botones que permiten al usuario elegir entre la consulta de cuentas o contactos además de un botón para borrar la pantalla de registros y otro botón para cerrar sesión.

Veremos los detalles de la interacción con REST más adelante. De momento, vamos a ver cómo y dónde se configuran estos botones de la interfaz de usuario.
  1. En la ventana del proyecto de Android Studio, expanda MyTrailNative res layout y, a continuación, haga doble clic en main.xml.
  2. En la parte inferior de la ventana del editor, seleccione la ficha Text (Texto).
La ficha Text (Texto) le permite usar una ventana dividida con un diseñador visual a la derecha y el archivo de configuración XML de la vista a la izquierda. Al hacer clic en cualquier área del diseñador visual, se resalta la configuración XML del área. Si hace clic en el botón FETCH CONTACTS (Obtener contactos), por ejemplo, el editor resalta un nodo <LinearLayout>/<Button>. Los atributos del nodo especifican las características del botón, como el aspecto, la identificación y el comportamiento. Consulte la documentación para desarrolladores de Android para obtener más información sobre los detalles de la configuración de la interfaz de usuario.
Si hace clic dentro del encabezado de vista (por ejemplo, en el botón Logout), el editor resalta un nodo <include>:
<include layout="@layout/header" />
Este nodo le indica que el encabezado se define en otro archivo XML. A juzgar por el atributo layout, puede encontrar fácilmente header.xml en la misma ruta que main.xml. ¡Es bastante fácil!

Manifiesto de la aplicación

El archivo AndroidManifest.xml del proyecto revela la configuración más básica de la aplicación, como nombre, icono, actividad principal, versiones mínimas y de destino de la API de Android, etc. ¡Compruébelo por sí mismo!
  1. En la ventana del proyecto de Android Studio, expanda app.
  2. Haga doble clic en AndroidManifest.xml.
En el nodo <manifest> raíz, justo después de la declaración de espacio de nombres, verá el nombre del paquete de la aplicación declarado:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.mytrail.android"
    android:versionCode="1"
    android:versionName="1.0"
    android:installLocation="internalOnly">
El elemento raíz <manifest> contiene un nodo <application> que establece la configuración básica de la aplicación. En el nivel superior, este nodo establece el atributo que indica a Android que controle el nombre de la clase de inicio de la aplicación forcedroid.
<application android:icon="@drawable/sf__icon"
    android:label="MyTrailNative"
    android:name=".MainApplication"
    ...
El prefijo “.” indica a Android que anteponga el nombre del paquete de la aplicación (com.mytrail.android) a esta ruta de clase.

Además, se asigna una descripción a cada actividad definida por usted o forcedroid. Por ejemplo, tan solo el nodo application/activity en este caso representa la primera actividad que se muestra después del inicio de sesión. Como puede ver, la propiedad android:name de la actividad hace referencia al nombre de clase de su actividad principal. Este es el fragmento XML de application/activity de un archivo AndroidManifest.xml de 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>

Aparte de esto, todo lo que vea en el archivo de manifiesto predeterminado es la configuración de Android estándar. Al igual que con cualquier aplicación Android, puede agregar los componentes propios de su aplicación al nodo <application>, como actividades, servicios y receptores.

Ahora que ya sabe lo que incluye una aplicación forcedroid, vamos a continuar con la información que estaba esperando: cómo acceder a los datos de Salesforce.

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantaría saber más sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

Más información Continuar a Compartir comentarios