Aplicaciones modernas

Ciclo de vida de las aplicaciones para la Tienda Windows

Rachel Appel

Windows 8 está cambiando la forma y el momento en que se ejecutan las aplicaciones; nosotros queremos entender las sutilezas del nuevo ciclo de vida de las aplicaciones para crear aplicaciones que respondan como es debido, en todo momento. Las aplicaciones que son compatibles con las instrucciones para la administración del ciclo de vida de Microsoft ofrecen una experiencia mejor para el usuario, especialmente en los dispositivos pequeños, donde se garantiza la conservación de la memoria y la batería.

Diseño de la aplicación

Hay dos conceptos de diseño claves que forman la base de las aplicaciones para la Tienda Windows: las aplicaciones se pueden ejecutar en modo de pantalla completa, acoplado o relleno; y las aplicaciones deben tener una excelente capacidad de respuesta para que el usuario se pueda concentrar en el contenido que tiene a mano, sin distracciones innecesarias. Estos dos principios garantizan que la aplicación que se ejecuta en el momento recibirá todos los recursos disponibles del sistema operativo y del usuario, a diferencia de las aplicaciones de escritorio para Windows 8 o las aplicaciones en las versiones anteriores de Windows, que tenían que compartir estos recursos. 

Todas las aplicaciones para la Tienda Windows tienen cuatro estados: en ejecución, no en ejecución, suspendido y finalizado. Al iniciar una aplicación, esta se ejecuta. Luego, en función de las actividades del usuario o del sistema, la aplicación puede pasar entre los estados en ejecución y suspendido. Por ejemplo, si el usuario pasa de la aplicación A a la aplicación B, Windows suspende la aplicación A, después de un breve retraso, y la lleva a segundo plano. La aplicación A permanece suspendida (hasta que el usuario pase nuevamente a esta o Windows la finalice), mientras que la aplicación B se activa y pasa al estado en ejecución (posiblemente desde un estado suspendido, si ya se encontraba en memoria). Si el usuario vuelve a la aplicación A, Windows simplemente la despierta y, hasta donde alcanzan los conocimientos del sistema y de la aplicación A, nunca se dejó de ejecutar. Entonces, por supuesto, le toca suspenderse a la aplicación B.

Cuando una aplicación se encuentra en estado suspendido, su código no se ejecuta y la aplicación permanece en memoria, tal cual. En esencia, la aplicación se encuentra almacenada en caché y está preparada para volver a funcionar inmediatamente cuando el usuario la vuelva a activar. Sin embargo, esto no es todo: podemos ejecutar las tareas en segundo plano si seguimos los procedimientos correctos, y Windows puede terminar las aplicaciones en caso que escasee la memoria. En la Ilustración 1 vemos cómo las aplicaciones cambian entre los estados de ejecución (consulte bit.ly/TuXN9F para obtener más información).

Ilustración 1 Cambio entre los estados de ejecución de las aplicaciones para la Tienda Windows

Tal como sugiere la Ilustración 1, una aplicación puede alternar frecuentemente entre los estados en ejecución y suspendido. Las transiciones entre los estados del ciclo de vida de las aplicaciones resaltan la diferencia entre las aplicaciones para la Tienda Windows y las aplicaciones de escritorio tradicionales.

Visual Studio 2012 incluye un conjunto de sofisticadas herramientas de depuración, además de un Simulador de Windows (bit.ly/QzBy5I), que nos permiten administrar las operaciones del ciclo de vida de las aplicaciones. Esto es importante, ya que debemos reaccionar correctamente frente a los eventos del ciclo de vida de la aplicación y administrar debidamente las transiciones entre los estados, para crear una experiencia con una alta capacidad de respuesta para el usuario final: un principio clave del diseño de aplicaciones en Windows 8. Al responder en forma adecuada frente a los eventos del ciclo de vida de las aplicaciones, podemos garantizar que los usuarios tengan una experiencia coherente durante todo el ciclo de vida de la aplicación. Específicamente, esto significa que debemos guardar y restaurar el estado de la aplicación, todas las veces que haga falta. Esto puede significar que debemos llevar al usuario de vuelta al mismo lugar en el que se encontraba dentro de la aplicación (como por ejemplo un asistente) o volver a rellenar los valores de un formulario en el que este estaba trabajando o regresar al último artículo que estaba leyendo. Como el ciclo de vida de la aplicación está controlado por el desplazamiento del usuario a través de la aplicación, esta debe estar preparada para controlar su estado en cualquier momento, cada vez que reciba el evento de suspensión.

Activación de la aplicación

El proceso WWAHost.exe es un host de aplicaciones que ejecuta las aplicaciones en JavaScript para la Tienda Windows. Las aplicaciones XAML escritas en cualquier lenguaje (por ejemplo C#, Visual Basic o C++) ejecutan el archivo ejecutable correspondiente de la aplicación. En cualquier caso, todas las aplicaciones pasan por la activación, que tiene diferentes catalizadores:

• El usuario inicia la aplicación desde un mosaico.
• El usuario activa una aplicación suspendida.
• Windows inicia la aplicación a través de un contrato para buscar o un contrato para contenido compartido.
• Windows invoca una asociación de protocolo (esquema URI) (bit.ly/QyzX04) o inicia una aplicación debido a una asociación de archivos.
• Windows invoca una extensión como, por ejemplo, el contrato del Selector de archivos para abrir o del Selector de contactos.

La forma en que se produce la activación determina el código que se debe ejecutar. Los inicios desde un mosaico, contrato o protocolo provocan que las aplicaciones de Biblioteca de Windows para JavaScript (WinJS) desencadenen un evento activado y que las aplicaciones XAML desencadenen un evento OnLaunched. Durante estos eventos, se revisa el estado anterior de la aplicación para tomar las medidas pertinentes. 

Si la aplicación pasa de un estado de no en ejecución a un estado en ejecución, debemos cargar los datos actualizados, ya que esta transición indica que el inicio de la aplicación provino de un mosaico, acceso, protocolo o extensión. Si la aplicación vuelve de un estado suspendido, generalmente no debemos hacer nada; el usuario simplemente puede retomarla donde mismo la dejó. Si la aplicación pasa de un estado finalizado a uno en ejecución, debemos volver a cargar los datos y navegar al último lugar dentro de la aplicación donde se encontraba el usuario (a menos que hayan pasado tres meses dese la última vez que se usó). El código para procesar la activación en JavaScript se muestra en la Ilustración 2 y el de C# en la Ilustración 3. Como se aprecia en el ejemplo, podemos detectar el estado de ejecución anterior y también la forma en que Windows inició la aplicación, ya que la API de Windows cuenta con un conjunto conveniente de enumeraciones para ambos casos. Una vez que tenemos la información, podemos volver a rellenar los datos necesarios.

Tanto los eventos activados en JavaScript como los OnLaunched de XAML contienen un argumento args que podemos consultar para determinar el estado en el que se encontraba la aplicación antes de la activación. En la Ilustración 2 y la Ilustración 3 vemos ejemplos del evento activated.

Ilustración 2 Código para la activación de una aplicación en JavaScript

var app = WinJS.Application;
var activation = Windows.ApplicationModel.Activation;
var nav = WinJS.Navigation;
app.addEventListener("activated", function (args) {
  if (args.detail.kind === activation.ActivationKind.launch) {
    if (args.detail.previousExecutionState !==
      activation.ApplicationExecutionState.terminated) {
      // TODO: This application has been newly launched.
      // Initialize your application here.
    } else {
      // TODO: This application has been reactivated from suspension.
      // Restore application state here.
    }
    if (app.sessionState.history) {
        nav.history = app.sessionState.history;
    }
    args.setPromise(WinJS.UI.processAll().then(function () {
      if (nav.location) {
          nav.history.current.initialPlaceholder = true;
          return nav.navigate(nav.location, nav.state);
      } else {
        return nav.navigate(Application.navigator.home);
      }
    }));
  }
});

Ilustración 3 Código para la activación de una aplicación en C#

async protected override void OnLaunched(LaunchActivatedEventArgs args)
  {
// Check whether the session data should be restored.
    if (args.PreviousExecutionState == 
      ApplicationExecutionState.Terminated)
    {
      // Here we've created a SuspensionManager class that
      // handles restoring session data from a file and
      // then gives access to that data through a Dictionary.
      await SuspensionManager.RestoreAsync();
// Retrieve the data for restore.                 
data = SuspensionManager.SessionState["savedData"];
    }
    // If not, use the app's default values
    else
            {
data = "Welcome";
    }
    Window.Current.Activate();
}

El código que se ejecuta durante la activación se debe ejecutar en 15 segundos o, de lo contrario, Windows terminará la aplicación. Aunque esto puede parecer excesivamente estricto, las aplicaciones que impiden que el usuario interactúe con la interfaz de usuario durante tanto tiempo no responden como es debido. De acuerdo con un estudio de UseIt.com sobre los usuarios y los tiempos de respuesta (bit.ly/NWSumy), la mayoría de los usuarios dejan de usar los sitios web que tardan más de 10 segundos en cargarse. De hecho, los usuarios se frustran cuando las páginas tardan más de 1 o 2 segundos en cargarse, y muchos se retiran significativamente antes de los 10 segundos. Es importante que sepa esto sobre los usuarios, especialmente si quiere vender su aplicación en la Tienda Windows, ya que los usuarios frustrados publican reseñas negativas de la aplicación; sin mencionar que si la aplicación tiene un mal rendimiento posiblemente ni siquiera apruebe la certificación para la tienda. (Consulte bit.ly/OxuEfu para obtener más información sobre cómo enviar una aplicación.) Es muy importante evaluar cuidadosamente qué datos se van a cargar y en qué momento. Afortunadamente, las bibliotecas de Windows en tiempo de ejecución (WinRT) permiten cargar los datos en forma rápida y progresiva, gracias a un modelo de programación asincrónica de primera clase (bit.ly/NCx6gE).

El objeto Windows.ApplicationModel.Activation forma parte de la API de Windows y está accesible a todas las aplicaciones de la Tienda Windows, independientemente del lenguaje. El objeto Activation contiene la enumeración activationKind con los siguientes valores:

• Launch: el usuario inició la aplicación o pulsó un mosaico secundario.
• Search: el usuario desea realizar una búsqueda con la aplicación.
• ShareTarget: la aplicación se activó como destino para una operación de uso compartido.
• File: una aplicación inició un archivo cuyo tipo de archivos está registrado a nombre de esta aplicación.
• Protocol: una aplicación inició un protocolo cuyo tipo de protocolo está registrado a nombre de esta aplicación.
• FileOpenPicker: el usuario desea seleccionar archivos o carpetas proporcionados por la aplicación.
• FileSavePicker: el usuario desea guardar un archivo y seleccionó la aplicación como la ubicación.
• CachedFileUpdater: el usuario desea guardar un archivo para la cual la aplicación proporciona la administración del contenido.
• ContactPicker: el usuario desea seleccionar contactos.
• Device: la aplicación controla AutoPlay.
• PrintTaskSettings: la aplicación controla las tareas de impresión.
• CameraSettings: la aplicación captura fotos o vídeo desde una cámara adjunta.

Como la aplicación podría admitir diferentes características, como compartir y buscar, la enumeración activationKind nos permite ver la intención del usuario para iniciar la aplicación y, luego, ejecutar el código correspondiente.

Administración de la suspensión, finalización y reanudación

Cuando un usuario pasa a otra aplicación o el dispositivo entra en modo de hibernación o se suspende, Windows detiene la ejecución del código de la aplicación, pero conserva la aplicación en la memoria. La razón para esta suspensión es minimizar el impacto en la batería y el rendimiento de las aplicaciones que el usuario no está aprovechando en forma activa. Cuando Windows se reactiva de la suspensión o de una finalización corta, el usuario debería sentir que la aplicación jamás se dejó de ejecutar. El control apropiado de los eventos del ciclo garantiza un diseño con una capacidad de respuesta adecuada.

Para iniciar el proceso de suspensión, Windows genera un evento oncheckpoint de WinJS o un evento OnSuspending en XAML, lo que nos permite guardar los datos y la información del usuario, antes de que la aplicación pase al modo suspendido. Cualquier código que ejecutemos en estos eventos debe finalizar dentro de 10 segundos o, de lo contrario, Windows detendrá la aplicación por completo. Igual que en el caso del proceso de activación, esta regla permite mantener estable el estado general del sistema operativo y habilita un cambio rápido. Para enlazar con el evento oncheckpoint necesitamos una definición de función sencilla:

app.oncheckpoint = function (args) {
  // Save app data in case of termination.
};

En XAML, empleamos un evento Application.Suspending:

async void Suspending(Object sender,
  Windows.ApplicationModel.SuspendingEventArgs e) {
  // Save app data in case of termination.
}

Durante la suspensión, debemos guardar la ubicación o posición de desplazamiento del usuario en la aplicación, liberar los identificadores y las conexiones de los archivos y marcar los datos con fecha y hora. Puede lograr esto con los objetos WinJS.Application.sessionState o SuspensionManager de XAML integrados. Siempre debe guardar la información del usuario y los datos de la aplicación en el evento de suspensión, ya que Windows no modifica las aplicaciones antes de terminarlas. Esto es importante, ya que la finalización puede ocurrir bajo diferentes circunstancias como, por ejemplo, cuando Windows tiene que desocupar memoria o el dispositivo (la batería) está descargado.

Por lo tanto, debe programar a la defensiva y dar por hecho que la aplicación se va a finalizar. Esto significa que siempre debe guardar los datos de la aplicación en sessionState. Si Windows finaliza la aplicación, los datos están guardados, listos para ser usados nuevamente.

La reanudación se produce cuando Windows reactiva una aplicación en suspensión. La mayoría de las veces, Windows simplemente reanudará la aplicación cuando el usuario vuelve a esta o la vuelve a iniciar; y en el código no debemos hacer nada. Durante la suspensión, la aplicación simplemente se encuentra en la memoria, sin tocar; así que el contenido de la aplicación no se altera y no hay que hacer nada.

Mientras que la mayoría de las aplicaciones no requieren de ningún tipo de trabajo al reactivarlas del estado en suspensión, las aplicaciones que contienen datos que cambian con cierta frecuencia como, por ejemplo, fuentes RSS, valores o redes sociales, son candidatos viables para emplear el evento resuming. Como el evento resuming se presta para estas pocas situaciones específicas, se encuentra en el objeto Windows.UI.WebUI.WebUIApplication en vez del objeto WinJS.Application más común, junto con otros eventos semejantes como oncheckpoint y onactivated, entre otros:

Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", function () {
  // Repopulate data from sessionState.
});

Puede agregar el controlador de reanudación al archivo default.js, cerca del código de activación, para organizar bien el código. Permita que su aplicación responda bien: al reanudar cargue rápidamente solo la cantidad mínima de datos necesarios.

Tareas en segundo plano y aplicaciones de comunicación en tiempo real

Aunque el código de la interfaz de usuario no se ejecuta mientras la aplicación se encuentra en modo de suspensión, la aplicación puede realizar tareas en segundo plano (bit.ly/QyRvsU), transmitir archivos grandes o revisar el correo electrónico. Algunas aplicaciones de comunicación en tiempo real como, por ejemplo, los clientes de mensajería instantánea, tienen que poder notificar al usuario cuando llega un mensaje, independientemente del estado de ejecución de la aplicación.

Las tareas en segundo plano son clases ligeras que se ejecutan en forma periódica con ciertas restricciones, mientras que técnicamente la aplicación no se está ejecutando. Se ejecutan en sus propios recintos de seguridad o contenedores de aplicaciones, mientras que la aplicación sigue en un estado inactivo. Las tareas en segundo plano en JavaScript se ejecutan en un nuevo contenedor uniproceso de WWAHost.exe y las tareas en segundo plano que no están en JavaScript se ejecutan en un .dll en el proceso que se carga en su propio contenedor de subproceso dentro de la aplicación. Esta separación permite que las tareas en segundo plano se ejecuten independientemente de la interfaz de usuario de una aplicación, la cual permanece suspendida hasta que el usuario vuelva a la aplicación.

Además de poder ejecutar el código en segundo plano, estas aplicaciones también presentan información en la pantalla de bloqueo. La pantalla de bloqueo contiene una imagen de fondo, superimpuesta con información ligera como hora, fecha, estado de la batería y de la red. Además, las aplicaciones (puntualmente las aplicaciones que se ejecutan en segundo plano) pueden presentar información en la pantalla de bloqueo. Como es importante que la pantalla de bloqueo se asimile a simple vista, solo se puede presentar una cantidad de información limitada. En la pantalla de bloqueo se pueden mostrar las insignias hasta de siete aplicaciones y se puede mostrar el texto del mosaico de una aplicación. Para obtener más información, consulte la información general sobre la pantalla de bloqueo en bit.ly/RsE7pj.

Siga el modelo

Como desarrollador de aplicaciones para la Tienda Windows, debe ocuparse de asuntos tales como la duración de la batería, presión en la memoria, ejecución de la aplicación en una gama de dispositivos y, lo más importante, la experiencia del usuario. Verá que puede cumplir con sus objetivos más fácilmente si sigue las instrucciones prescritas para la administración del ciclo de vida. Además, aparte de las razones técnicas para una administración del ciclo de vida de la aplicación, si esta tiene una alta capacidad de respuesta y un rendimiento bueno, recibirá reseñas mejores en la Tienda Windows.

Rachel Appel es evangelizadora de desarrollo en Microsoft en la ciudad de Nueva York. Puede ubicarla en su sitio web en rachelappel.com o por correo electrónico en rachel.appel@microsoft.com. También puede seguir sus últimas actualizaciones en Twitter en twitter.com/rachelappel.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Adam Barrus, Ben Betz, Arun Kishan, Michael Krause, Hari Pulapaka, John Sheehan y Ben Srour