Empezando con Windows Phone 7.1 (y VII) – Pequeño problema con Code Analysis

Este post será breve (y poco satisfactorio, me temo).

Pensando en la gestión de literales en el código – échale un vistazo a la entrada Empezando con Windows Phone 7.1 (y V) – Soportando varios idiomas – y en cómo podría evitar olvidarme de meter algún literal en el correspondiente fichero de recursos, decidí activar las reglas de “Code Analysis”.

Para quien no lo sepa, estas reglas realizan análisis estático del código. Es decir, aplican un número sorprendentemente alto de reglas para garantizar que el código escrito (y no en ejecución) cumple con una serie de requisitos mínimos de calidad. Definir un conjunto razonable de reglas que todo equipo de programación debe de superar es un buen hábito que recomiendo que incorpores a tu lista (si no lo has hecho ya).

Ayuda a localizar cosas tan evidentes como buenas prácticas en la nomenclatura de tus clases, métodos y miembros (tanto públicos como privados) hasta cosas igual de evidentes, pero mucho más críticas cuando se trata de poner una aplicación en un entorno de producción, como que un objeto que implemente la interfaz IDisposable, efectivamente es liberado cuando deja de utilizarse (a todos aquellos que penséis que, por tener un recolector de basura os podéis olvidar de los recursos del sistema os recomiendo ochenta flexiones en penitencia y volvéroslo a pensar).

Pues bien, alguna de las cosas que Code Analysis puede ayudarte a encontrar son literales que no están incluidos dentro de ficheros de recursos (herramientas como Resharper también ayudan en esto).

Pues ahí que te va: Habilité el análisis de código para mi solución y limité el número de reglas que quería aplicar (no me gusta mucho ver docenas de advertencias /warnings en mi código y el número de reglas a habilitar puede ser muy elevado, así que empecé por un conjunto mínimo).

Revisando la salida de compilación de mi código me encontré con esta advertencia.

Warning 1 CA0060 : The indirectly-referenced assembly ‘Microsoft.Phone.Data.Internal, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e’ could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. This assembly was referenced by: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\System.Data.Linq.dll.  Jdmveira.MisSitiosFavoritos

Bonito. ¿Eh?

¿Qué significa?

Esencialmente, que hay un assembly (Microsoft.Phone.Data.Internal) referenciado desde otro que ya está incluido en tu solución (System.Data.Linq.dll) que no está incluido en tu solución y que, en consecuencia, Code Analysis no puede revisar y, potencialmente, te puede dar un análisis incompleto.

El siguiente paso que uno puede pensar es. ¡Eh, no hay problema! ¡Lo añado a mi solución y listo!

Pues bien, me temo que va a ser que no.

Como todos sabéis existen una serie de APIs de Windows Phone que no están accesibles para el común de los mortales. Estas APIs se encuentran en tu emulador o en tu teléfono, pero tú, oh pobre programador. ¡No puedes acceder a ellas! Reviando un poquitín por ahí, puedes encontrar esta referencia aquí. Y una referncia al tipo de advertencia CA0060 de Code Analysis aquí (donde te dice que si añades la referencia a la DLL que no encuentra, solucionarás la advertencia).

¿Qué nos queda hacer? Pues bien. Si perteneces a un equipo donde tienes establecidas reglas de calidad que no te van a dejar promocionar o entregar el código a tu servidor de código fuente si hay un simple warning de Code Analysis, entonces lo tienes complicado. Porque no vas a poder.

Si, como yo, tener una advertencia (warning) te provoca un leve escozor. Déjalo estar y esperemos a que a los chicos de Microsoft se les ocurra cómo solucionarlo.

¿Quién sabe? Igual en un futuro liberan todas las APIs a todos los desarrolladores.

Soñar es gratis.

Empezando con Windows Phone 7.1 (y V) – Soportando varios idiomas

Uno de los primeros pasos que he realizado ha sido dotar a la aplicación de infraestructura necesaria para dar soporte a múltiples idiomas. Esto no significa que la aplicación salga inicialmente soportando varios idiomas, significa que, cuando haya que hacerlo, los cambios que tendré que llevar a cabo serán mínimos.

Imaginad que comenzáis creando una aplicación sin tener esto en cuenta. Cada uno de los literales que introduzcas en tu código (y no me limito únicamente a los que aparecen en la capa de presentación) estarán mejor o peor organizados, pero probablemente dispersos por todo tu código.

Cuando llegue el momento de dar soporte a varios idiomas, tendrás que empezar a buscar estos literales por toooodo tu código, sacarlos a ficheros de recursos y, una vez ahí, comenzar con el proceso de prueba /error hasta que estés seguro de que lo has contemplado todo. A partir de este punto, podrás comenzar a añadir más ficheros de rescursos que den soporte a diferentes idiomas.

Mi aproximación es diferente. He creado la infraestructura necesaria para dar este soporte desde el comienzo. Ahora lo que hay que contar es con la disciplina suficiente como, cada vez que necesites crear un nuevo literal, hacerlo en el fichero de recursos en vez de directamente en tu código.

Ficheros de Recursos en el Proyecto

Varios ficheros de recursos añadidos al Proyecto

A continuación he configurado el idioma neutral del proyecto para que sea el español (de España).

Idioma Neutral por defecto

Configuración del Idioma Neutral para que sea español (España)

Una cosa que me ha llamado la atención es la siguiente: Para indicar qué idiomas soporta la aplicación, es necesario editar el fichero .csproj para indicar dentro del tag <SupportedCultures/> qué idiomas soporta la aplicación. Este fichero tiene un formato XML, sin embargo, abrir el XML en vez del proyecto no es tarea fácil dentro de Visual Studio. Así que he abierto mi fichero con Notepad++ y he introducido dentro de dicho tag (de momento) sólo el español. He guardado, recargado el proyecto en Visual Studio y… Ya está, mi aplicación dice que soporta el español. Para el inglés queda un poquito (tendré que acordarme de separar los idiomas con puntos y comas).

SupportedCultures en el proyecto

Elemento <SupportedCultures/> en el proyecto

En relación a la inclusión de ficheros de recursos, la idea es buena, pero las prisas, el cansancio o la inexperiencia pueden hacer que olvides incluir literales en tus ficheros y sigas metiéndolos en código. ¿Qué hacer en este caso? Pues habrá que mirar Code Analysis. Eso haré y os tendré al tanto.