Hoy os voy a contar cómo ser conscientes (y aprovechar) que no es lo mismo un Nokia 520 con su pantalla de 800×480 y un 1520 con otra de 1080×1920. Aunque Microsoft hace un buen trabajo para abstraernos de las múltiples resoluciones y densidad de píxeles, hay veces que necesitamos más, y es cuando falla la documentación oficial.

Por ejemplo, esta es la página en la que Microsoft nos explica cómo tenemos que manejar dichas resoluciones en nuestro código. En ella tenemos la tabla que presentamos justo abajo:

En base a esa tabla, más abajo ponen un código para determinar bajo qué pantalla se está ejecutando tu aplicación y, a partir de ahí te puedes ajustar a ella. El código obtiene el valor de la propiedad “App.Current.Host.Content.ScaleFactor” que puede valor 100 para los teléfonos originales, 160 para las pantallas de 720p y 150 para las FullHD.

Lo cierto es que Windows Phone hace un buen trabajo para ajustarse a todas las resoluciones, y en general el programador solo tiene que ofrecer tamaños de letra que sean adecuados para todos los tamaños y/o dar la oportunidad al usuario para que elija uno con el que se sienta cómodo.

Podríamos decir que si uno utiliza los tamaños predefinidos de coordenadas, y los estilos de fuente ya definidos por la plataforma (léase o ), no tenemos que hacer nada y todo se verá prácticamente perfecto. Pero si queremos que los usuarios ajusten el tamaño del texto (por poner un ejemplo), tenemos que tener en cuenta que, pese al escalado automático, un tamaño fijo de texto que en un 520 puede ser útil a alguien con presbicia, ese mismo tamaño en un 1520… bueno, digamos que podríamos ver los quarks que forman cada pixel de la pantalla.

Por lo tanto tenemos que ser conscientes y permitir tamaños de letra muy pequeños (para los terminales con pantalla grande) y muy grandes (para los de pantalla diminuta). Siempre, claro, como ya hemos dicho, no usemos los valores estándar. El ejemplo típico de aplicación de esto es la de chat, la de recopilador de noticias o de leer.

Como punto jocoso, no os podéis ni imaginar cómo se veían las versiones antiguas de WhatsApp o de KakaoTalk en mi 1520 cuando lo compré. Podías leer los mensajes desde dos metros de distancia. Ahora no, ahora por lo menos el primero se ajusta bastante bien, aunque me gustaría que permitiera algo más de personalización en ese aspecto.

—

Vale. ¿Entonces para qué sirve esta entrada?

A ver, no nos estresemos. Se puede dar el caso que queramos hacer ajustes finos respecto a la resolución. Un ejemplo típico es ajustar el alto de nuestra ventana cuando se despliega el teclado para reducir el contenido visible en lugar de que la ventana se nos oculte por arriba, dejando siempre visible la cabecera. Para complicar la cosa no hay ninguna forma para saber la altura del teclado desplegado.

Otra situación la tenemos cuando estamos pintando imágenes (es un decir, porque pintar, lo que se dice pintar, no se puede a no ser que usemos DirectX) y queremos ver cuánto sitio nos queda, sabiendo la resolución real de lo que estamos manejando.

Para saber la resolución real de la pantalla, tenemos acceso al objeto System.Windows.Interop.Content, que ya hemos usado antes y que tiene alguna propiedad más:

A partir de la GDR3 de Windows Phone 8, existe una nueva propiedad insertada dinámicamente que llama ActualScaleFactor y que sólo se puede acceder a ella mediante reflexión. No vamos a entrar en detalles sobre cómo hacerlo.

Los valores que nos interesan son los dos primeros y el último. Teniendo acceso a los emuladores, vamos a construir una nueva tabla con los valores reales:

Esos son los valores obtenidos con lo descrito arriba y en base a la documentación que nos ofrece Microsoft. La pregunta, en mi forma de escribir que tan poco le gusta a la gente es: ¿cómo cojones distingo los terminales de 6”, 5,5” y 4.7”, si todos sus valores son idénticos?

Antes de seguir, y respondiendo a la pregunta no formulada: sí, hay diferencias reales que se notan dependiendo en qué terminal estemos ejecutando nuestro programa, sobre todo si no utilizamos los estilos predefinidos.

Podríamos basarnos en ActualScaleFactor, que tendríamos que obtener mediante reflexión, y que vamos a rellenar ahora:

¿WTF? Los dos dispositivos Full HD tienen el mismo factor de escala distinto, y como sus pantallas son diferentes… seguimos con el problema, ya que aunque hay poca diferencia de tamaño, os aseguro que la cosa se sigue notando.

—

Ya os lo habréis imaginado por dónde viene la solución: las dos columnas vacías. Pero ¿cómo las llenamos? Pues así:

objecttemp;

var screenResolution = newSize(0, 0);

var dpi = 0.0;

if (DeviceExtendedProperties.TryGetValue(«PhysicalScreenResolution», outtemp))

screenResolution = (Size)temp;

if (DeviceExtendedProperties.TryGetValue(«RawDpiX», outtemp))

dpi = (double) temp;

Ahora sí, ahora sí que podemos rellenar la tabla por completo:

Ahora sí, ahora ya podemos basarnos en los DPI para distinguir entre los valores que son iguales. Los valores “sin medir” están así porque simplemente no he tenido ganas de ejecutar el código en los respectivos emuladores.

También podemos observar otra cosa: Microsoft (y Windows Phone) tiene dispositivos con más de 400 DPI, lo que ahora están sacando otros fabricantes (léase Samsung).

Y con esto y un bizcocho, hasta mañana a las ocho.