Windows Phone 7

Introducción a Windows Phone y la nube

Ramon Arjona

Estoy aprendiendo a leer y escribir en español. Gracias al lugar donde vivo, puedo practicar español tratando de leer los letreros bilingües que se encuentran en diversos lugares públicos. El asunto es que a veces me atasco con una palabra en particular y no puedo entenderla, o a veces me confundo con una oración completa. También es difícil estar seguro de haber comprendido lo que leí sin tener una traducción paralela al inglés a la cual consultar. Podría andar con un diccionario de español-inglés, pero hojear todas esas páginas es demasiado analógico.

Lo que realmente deseo, porque siempre tengo el teléfono a mano, es una manera fácil de que el teléfono me ayude con la traducción. Usar el teléfono para ir a Bing y usar el Microsoft Translator basado en la nube es útil, pero es necesario presionar muchas teclas para llegar a la pantalla de la traducción. Si tan sólo existiera una forma fácil de obtener el traductor para mi teléfono. Bueno, esa forma existe con la llegada de Windows Phone 7.

Este artículo sirve como una introducción para el desarrollo de aplicaciones de Windows Phone y muestra cómo vincular dichas aplicaciones a un servicio web en la nube. Debe estar familiarizado de alguna manera con C# y Visual Studio, y sería muy útil si tuviera al menos cierta experiencia en el desarrollo de aplicaciones con el lenguaje de marcado de aplicaciones extensible (XAML), pero no es un requisito. Usé la actualización de abril de Community Technology Preview (CTP) de las herramientas de Windows Phone. Es posible que las cosas hayan cambiando al momento en que lea esto, por lo que visite developer.windowsphone.com para leer la documentación y descargar las herramientas más recientes.

Lo primero es lo primero: obtención de un AppID

Si va a interactuar con el traductor, o con cualquiera de los servicios web de Bing, el primer paso es obtener un AppID. La API de servicio lo usa para validar que una solicitud proviene de un desarrollador de aplicaciones Bing registrado.

Vaya a bing.com/developers/createapp.aspx e inicie sesión con su Windows Live ID. Rellene el formulario, donde se le pregunta el nombre y la descripción de la aplicación, además de detalles como el nombre de la empresa y la dirección de correo electrónico. Su dirección de correo electrónico se usa para notificarle cuando estas API cambian, por ejemplo, cuando se implementan versiones nuevas o cuando las versiones antiguas quedan sin conexión. En el caso particular de la API del traductor, al momento de redactar este artículo, la documentación indica que las versiones anteriores permanecerán en línea durante 90 días a contar del lanzamiento de la versión nueva.

A continuación, lea las condiciones de uso, marque la casilla para indicar que las acepta y haga clic en el botón "Aceptar". Se le dirigirá a una página en la que aparecerá su AppID recién creado. Siempre podrá volver a esta página para usarla como referencia, pero en mi caso generalmente copio y pego mi AppID en el archivo de origen de la aplicación al crearlo.

Lea siempre las condiciones de uso de cualquier servicio web que planee usar en una aplicación. En serio, resista la tentación de sólo leerlos por encima, en especial si planea distribuir su aplicación a los usuarios a través del Catálogo de soluciones. Su responsabilidad para con los clientes es comprender los objetivos a nivel de servicio y las demás condiciones definidas por los socios que proporcionan los servicios que usa su aplicación. Por lo tanto, asegúrese de leer y comprender las condiciones de uso, independientemente de si su aplicación usa un servicio de Microsoft o de cualquier otra parte.

Ahora que tiene un AppID, estamos listos para comenzar a trabajar en la aplicación del traductor móvil.

Definición del escenario

Antes de comenzar a trabajar en mi primera aplicación, eché un vistazo a algunas aplicaciones móviles exitosas existentes en el mercado. Miré aplicaciones para teléfonos Windows y otros smartphones para tratar de obtener una idea sobre lo que hace que una aplicación móvil sea realmente exitosa. Leí reseñas de productos. Entrevisté gente. Molesté a mis amigos para que me dejaran jugar con sus teléfonos.

Después de toda esta investigación, concluí que la clave para que una aplicación móvil fuese exitosa es la simplicidad. Cada aplicación popular satisface uno o dos escenarios de usuario clave, y lo hace bien. Por ejemplo, descubrí una clase completa de aplicaciones cuyo único propósito es generar ruidos groseros. En la práctica, esencialmente son una reimplementación del cojín de ventosidades en un teléfono. A la gente le parecen divertidos, al menos lo suficientemente divertidos como para pagar por cargarlos en sus teléfonos.

De manera similar, hay aplicaciones que lanzan dados simulados, recomiendan un restaurante para cenar e incluso calculan el importe de la propina para esa cena en particular. Todas estas aplicaciones se centran en un escenario de usuario y se ejecutan en dicho escenario de manera simple e intuitiva. Este enfoque no es exclusivo de ninguna marca de smartphone en particular. La idea que se refiere a que tenemos que tener una experiencia de usuario intuitiva y pulida se ve reforzada en la Guía de interacción y diseño de la UI de Windows Phone, publicada en el sitio web developer.windowsphone.com/windows-phone-7.

De esta manera, cuando comencé a trabajar en mi aplicación de traductor, fue importante centrarse exactamente en lo que deseaba que lograra la aplicación, y en nada más. Para hacerlo, primero fue necesario tener una imagen clara de lo que deseaba lograr. Una vez que tuve en mente esta imagen, pude resistir la tentación de agregar características nuevas y geniales que, a pesar de ser interesantes, no servirían para el escenario de usuario principal. Decidí que mi aplicación debía traducir entre inglés y español. Debe cambiar fácilmente los modos de traducción de español a inglés o de inglés a español, y debe trabajar con palabras aisladas o con frases simples. Además, sólo me preocupaba el español y el inglés, por lo que mi aplicación ignoraría los demás idiomas.

Creación de la aplicación

Para comenzar a crear la aplicación del traductor, abra Visual Studio Express 2010 para Windows Phone. Elija “Nuevo proyecto...” y seleccione “Aplicación de Windows Phone”. Esta acción abre el proyecto de Windows Phone predeterminado con una pantalla dividida en dos secciones: título y contenido. Estas secciones se delinean con un objeto de cuadrícula XAML, que nos permite definir una serie de filas y columnas en las que podemos ubicar elementos secundarios de la UI como botones y bloques de texto (consulte la figura 1).

Figura 1 Proyecto de Windows Phone predeterminado con vistas de visualización y código

Primero, edite el nombre de la aplicación y el título de la página seleccionando estos elementos de UI en el diseñador. Esto resalta el XAML relacionado en la ventana de la vista de código del diseñador, y muestra el elemento que necesita editar. A continuación, abra el cuadro de herramientas y arrastre algunos elementos de la UI a la cuadrícula inferior de la página, llamada ContentGrid. Seleccione un cuadro de texto, donde pondremos las palabras que deseamos traducir, y luego un bloque de texto, donde se presentará la traducción. Finalmente, agregue dos botones (consulte la figura 2).

Figura 2 Adición de los elementos de UI de cuadro de texto, bloque de texto y botón

Un botón ejecutará la traducción y el segundo alternará la dirección de la traducción de español a inglés o viceversa.

XAML: la UI moderna

El centro de la experiencia de usuario de Windows Phone 7 es el sistema de diseño con nombre en código “Metro”, y el centro de la implementación de una UI según el sistema Metro es XAML. Si anteriormente ha trabajado con Silverlight o con Windows Presentation Foundation (WPF), probablemente XAML le sea familiar. Si no lo ha hecho, en esta sección encontrará una breve introducción.

XAML es una manera de estructurar de forma declarativa la UI, lo que le da una separación estricta entre la lógica de la aplicación y su aspecto. Verá que el código de la página principal de la aplicación, por ejemplo, está contenido en Mainpage.xaml.cs, pero el diseño básico de la aplicación está contenido en Mainpage.xaml. A diferencia del desarrollo de Windows Forms tradicional, no existe una combinación de código de aplicación con el diseño de la UI de la aplicación. Cada elemento de la UI en la aplicación se modela como un elemento XML en un archivo XAML.

Ésta es una ventaja, puesto que permite que una persona trabaje de manera independiente en el aspecto de la aplicación mientra otra trabaja en la lógica de la misma. Por ejemplo, ahora que hemos perfilado la UI básica de nuestra aplicación de traductor, podríamos entregar el XAML a un experto de UI mientras seguimos trabajando con el código. El diseñador no necesitaría saber nada acerca de la implementación de mi aplicación y para mí no debiera ser necesario saber nada acerca de la paleta de colores que seleccionó.

Por supuesto que no tengo presupuesto para un diseñador de UI, pero sí tengo MSPaint, y con eso es suficiente para demostrar la facilidad con que se pueden actualizar los activos gráficos que acompañan la aplicación.

Entrega de un nuevo icono al traductor

Hago doble clic en el archivo ApplicationIcon.png predeterminado que se agregó automáticamente al proyecto cuando lo creé. Con esto se abre el software para la edición de imágenes, que es MSPaint en mi máquina. Reemplazo el icono aburrido con una letra T mayúscula, luego borro el fondo negro y lo relleno con un rosa monocromático. Probablemente no me voy a ganar ningún premio por el diseño gráfico, pero me gusta (consulte la figure 3).

Figura 3 Un nuevo icono del proyecto creado con MSPaint

Para revisar el cambio, aprieto el botón de inicio para implementar la aplicación en el emulador de Windows Phone 7. Si ha trabajado con versiones anteriores de los emuladores de Windows Phone, verá inmediatamente que la experiencia del desarrollador ha mejorado considerablemente. Trabajar con el emulador para Windows Phone 6.5 puede ser complicado e implica pasos de configuración manual para comenzar y conectar el depurador con el emulador. En el entorno de desarrollo de Windows Phone 7, todo funciona una vez que aprieto el botón de inicio de color verde. Estoy contento incluso con la rapidez con la que el emulador carga y muestra la UI principal de la aplicación (consulte la figura 4).

Figura 4 La aplicación mostrada por el emulador de Windows Phone 7

Para ver el icono de la aplicación, salgo de la UI principal y navego a la pantalla principal del emulador. El gráfico del traductor está ahí, y se ve bien (consulte la figura 5).

Figura 5 Comprobación del nuevo icono de la aplicación en el emulador

El manifiesto de la aplicación

El icono de la aplicación está definido en un archivo llamado WMAppManifest.xml, que está ubicado en la carpeta Propiedades del proyecto. Para cambiar el nombre al icono de la aplicación, cambie el nombre del archivo ApplicationIcon.png en el proyecto y luego asegúrese de reflejar aquí el cambio, en el elemento IconPath:

<IconPath IsRelative="true"
   IsResource="false">myicon.png
   </IconPath>

Si la aplicación no puede encontrar este icono, se asignará el valor predeterminado en tiempo de ejecución, que es como un círculo blanco en un fondo negro.

Otro elemento de este archivo que merece ser examinado es el elemento Capabilities, que contiene las capacidades específicas que la aplicación desea usar. Es buena idea solicitar exactamente lo que necesita la aplicación, nada más. Si examina el archivo, verá que tiene un número de capacidades que probablemente no vamos a usar en nuestra aplicación de traductor.

Por ejemplo, ID_CAP_GAMERSERVICES declara que la aplicación necesita interactuar con las API de juegos de XBox. La capacidad ID_CAP_LOCATION dice que la aplicación desea usar la capacidad de ubicación del dispositivo. Y ID_CAP_PUSH_­NOTIFICATION dice que la aplicación desea interactuar con la característica de envío de notificación de Windows Phone 7. Todas éstas son características geniales, pero no las necesitamos para nuestra aplicación, por lo que no las usaremos. De hecho, es probable que sólo necesitemos la capacidad ID_CAP_NETWORKING, que indica que nuestra aplicación desea usar la red para enviar y recibir datos.

La API de Microsoft Translator

Microsoft Translator expone tres clases de API. La API SOAP brinda al usuario un establecimiento inflexible de tipos y facilidad de uso. La API AJAX es útil principalmente para desarrolladores de páginas web que desean insertar la traducción en su UI. La API HTTP es útil cuando ni la API SOAP ni la API AJAX son adecuadas.

Vamos a seleccionar la interfaz SOAP, porque es más fácil trabajar con ella para lograr nuestros propósitos. Vaya al Explorador de soluciones y haga clic con el botón secundario en Referencias. Luego seleccione “Agregar una referencia de servicio” e ingrese el extremo para la interfaz SOAP en la API del traductor:  http://api.microsofttranslator.com/V2/Soap.svc. Nombre al extremo de servicio como TranslatorService en el cuadro de texto de espacio de nombre y haga clic en Aceptar (consulte la figura 6).

Figura 6 Adición de una referencia de servicio SOAP

Visual Studio se preocupa del resto, generando el código cliente de la interfaz SOAP para usted.

Ahora agregue algún código a la aplicación. Agregue el AppID y una referencia al cliente TranslatorService en la declaración de la clase MainPage de la aplicación:

string appID = <<your appID>>;
  TranslationService.LanguageServiceClient client = 
    new TranslationService.LanguageServiceClient();

IntelliSense nos muestra que el servicio del traductor tiene varios métodos interesantes disponibles. Lo primero que hay que notar es que todos los métodos son asincrónicos. Esto tiene sentido, puesto que no hay un buen motivo para bloquear la aplicación cliente mientras esperamos que se complete una operación de red. Significa que tenemos que registrar un delegado para cada operación específica que realizamos. En nuestro caso, sólo nos interesa el método TranslateAsync y el evento TranslateAsyncComplete expuesto que expone Language¬ServiceClient. Pero los otros métodos sí que se ven interesantes. Echémosle un vistazo y veamos si se ajustan a nuestro escenario de usuario.

Dos métodos que se destacan son GetLanguagesForTranslateAsync y GetLanguageNamesAsync. El primer método proporciona una lista de códigos de los idiomas que admite el servicio del traductor. Al llamar este método, puede ver que el código de idioma para el español es “es”. El método GetLanguageNamesAsync devuelve una lista de nombres de idiomas para un conjunto determinado de códigos de idiomas, localizados para una configuración regional determinada. Por ejemplo, si transmite “es” en este método como la configuración regional y el código de idioma, obtiene la cadena “Español”. Si estuviésemos creando un traductor multilingüe, ambos serían útiles.

Otro método interesante se llama SpeakAsync. Acepta una cadena y una configuración regional y devuelve una dirección URL a un archivo WAV que entrega la pronunciación nativa de una palabra. Es una característica impresionante. Por ejemplo, podría escribir una cadena, obtener la traducción y transmitir esta cadena al método SpeakAsync para obtener un archivo WAV que podría usar para comunicarme con otras personas en español.  O en caso de no estar seguro de la pronunciación de una palabra en particular, podría usar el método SpeakAsync para oír cómo debería sonar.

Estos métodos son muy geniales, y es difícil resistir la tentación de incluirlos en la aplicación. Sin embargo, por ahora debemos mantenernos firmes y centrarnos sólo en satisfacer el escenario de usuario que definimos al inicio. Tener clara esta imagen hace que sea más fácil lidiar con la tentación de agregar “sólo una característica más”. Estoy seguro de que algún punto terminaré usando las características ofrecidas en la API del traductor, pero no lo haré ahora mismo.

Transmitir el código para crear nuestra aplicación del traductor es fácil. Primero, registramos los delegados para TranslateCompleted:

client.TranslateCompleted += new
  EventHandler<TranslationService.TranslateCompletedEventArgs>
  
(client_TranslateCompleted);

Luego implementamos el controlador de eventos para TranslateCompleted, que define el texto de nuestro bloque de texto en el texto traducido:

void client_TranslateCompleted(object sender,
   TranslationService.TranslateCompletedEventArgs e)
 {
   TranslatedTextBlock.Text = e.Result;
 }
We wire up the button to submit the text we’ve entered for translation:
 private void TranslateButton_Click(object sender, 
   RoutedEventArgs e)
 {
   client.TranslateAsync(appID, TranslateTextBox.Text, fromLanguage,
     toLanguage);             
 }

Luego agregamos cierto código simple al segundo botón para intercambiar entre los modos de traducción, de “Español a inglés” o de “Inglés a español”. Este botón administra una variable de estado global y cambia el texto de nuestro botón de traducción para indicar ese estado.

Finalmente, implementamos la aplicación en el emulador para probarla. Ahora tenemos una aplicación de traductor completamente funcional, con sólo algunas líneas de código y una hora o algo así de tiempo de desarrollo.

Expansión de la aplicación de traductor

La aplicación de traductor simple está bien, pero podríamos llevarla más allá si expandimos nuestro escenario de usuario. Sería genial si pudiésemos vincular más de los idiomas que ofrece la API del traductor con nuestra aplicación de manera que se ajuste a las instrucciones de diseño de Metro. Y sería incluso mejor si pudiéramos eliminar el botón que administra la dirección de la traducción y, en su lugar, tener una manera más simple y más intuitiva de administrar la dirección de la traducción. Independiente de lo que hagamos, debe ser simple de usar para una persona que usa sus dedos a fin de interactuar con el dispositivo, y debe sentirse rápido y fácil.

Entonces, ¿qué hacemos? Creamos una aplicación usando el proyecto de lista predeterminado. Comience un nuevo proyecto y seleccione “Aplicación de lista de Windows Phone”. Con esto aparece una pantalla predeterminada con un control de ListBox en ContentGrid. ListBox contendrá seis idiomas a los que deseamos traducir nuestro texto, reemplazando el texto ficticio (consulte la figura 7).

Figura 7 La aplicación de lista de Windows Phone predeterminada

Editaremos el archivo MainViewModelSampleData.xaml, que está contenido en la carpeta SampleData en el proyecto. Verá algunos XML con aspecto similar al siguiente:

<local:ItemViewModel LineOne="design one" LineTwo="Maecenas praesent accumsan bibendum" LineThree="Maecenas praesent accumsan bibendum dictumst eleifend facilisi faucibus habitant inceptos interdum lobortis nascetur"/>

Al editar el XML, puede cambiar la vista en tiempo de diseño de ListBox para incluir todos los idiomas con los que deseamos trabajar: alemán, español, francés, inglés, italiano y portugués. Observe que después de guardar este archivo, la vista en tiempo de diseño reflejará los cambios. Esto se debe a que el control ListBox tiene enlace de datos con el elemento Items definido en MainViewModelSampleData.xaml. Esto lo controla el atributo ItemsSource del control ListBox.

Ahora también puede actualizar los contenidos de ListBox en tiempo de ejecución. Si mira el archivo generado por Visual Studio, verá que Observable­Collection<ItemViewCollection> se está rellenando con datos de marcador de posición similares a los contenidos en el archivo MainViewModelSample­Data.xaml. Por ejemplo, si deseara generar dinámicamente la lista de idiomas en la UI en base a los idiomas devueltos por el método GetLanguageNamesAsync, editaría el archivo MainViewmodel.cs para rellenar la colección Items. Por ahora, prefiero especificar una lista estática de idiomas y sólo editar la colección de objetos ItemViewModel directamente. Ahora cuando ejecutemos la aplicación de lista, debiéramos ver una UI similar a la figura 8.

Figura 8 La UI de la aplicación de lista

Cuando el usuario toque uno de estos botones, se le dirigirá a una página de detalles que esencialmente se ve igual a la UI de nuestro Simple­Translator. Hay un cuadro de texto donde escribir las palabras que se van a traducir, un bloque de texto para contener el texto traducido y un botón para ejecutar la traducción. Sin embargo, en lugar de agregar otro botón para administrar la dirección de la traducción, nos basaremos en la API del traductor. La traducción bidireccional de nuestra aplicación SimpleTranslator no tiene sentido en este escenario multilingüe, y agregar niveles adicionales de UI podría hacer que el inicio de la aplicación se sienta engorroso en lugar de fluido. Afortunadamente, la API del traductor brinda una manera para detectar automáticamente el idioma que se transmite.

Agregamos algún código para llamar primero al método DetectAsync del cliente traductor, pasando el texto que deseamos traducir, y luego llamamos a TranslateAsync desde el controlador de eventos DetectAsyncComplete. El controlador de eventos tiene un aspecto similar al siguiente:

void client_DetectCompleted(object sender, 
  TranslationService.DetectCompletedEventArgs e)
{
  string languageCode = e.Result;
  client.TranslateAsync(appID, TranslateTextBox.Text, fromLanguage, tolanguage);
}

Sabemos el idioma al que queremos traducir por el botón que seleccionó el usuario. Sabemos cuál es el idioma desde el que queremos traducir, porque la API del traductor lo detectó automáticamente. Podemos crear un traductor simple y multilingüe que permite que el usuario obtenga una traducción con sólo dos toques, sin contar la escritura, y menos de una hora de codificación.

Simplicidad

El centro del desarrollo para Windows Phone 7 es la simplicidad. Una aplicación debe centrarse en satisfacer un escenario de usuario, y hacerlo bien. Las herramientas que vienen con CPT del SDK de Windows Phone 7 hacen que entregar aplicaciones simples y poderosas no sólo sea posible, sino también fácil. También hemos visto que interactuar con la nube es sencillo, y que el servicio web de Microsoft Translator se puede conectar con una aplicación de Windows Phone sólo con una pequeña inversión de tiempo de un desarrollador. Al usar herramientas familiares, como Visual Studio, e instrucciones claras como Metro, Windows Phone y la nube se reúnen para abrir un mundo de oportunidades nuevas para desarrolladores y usuarios.

Ramon Arjona es jefe senior de pruebas del equipo Windows en Microsoft.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: VikramDendi y Sandor Maurice