Acerca de...
El equipo
Encuestas
WinTablets

Encuesta

Si las WINTABLETs no pudiesen ejecutar aplicaciones de escritorio, ¿las seguirías usando?

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

05
Sep 2014
Desarrollorfogdevtrucos

Cómo trabajar con las múltiples resoluciones de Windows Phone y no morir en el intento

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:

3bis

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:

ActualHeight

La altura real en pixeles

ActualWidth

La anchura real en píxeles

FullScreenOptions

Cómo se comporta en pantalla completa

IsFullScreen

Cierto si estamos en pantalla complete

ZoomFactor

El factor de zoom

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:

Dispositivo

ActualHeight

ActualWidth

ActualScaleFactor

ScaleFactor

ZoomFactor

Resolution

DPI

1080P 6”

853

480

150

1.0

1080P 5.5”

853

480

150

1.0

720P 4.7”

853

480

150

1.0

WXGA 4.5”

800

480

160

1.0

WXGA 4.0”

800

480

100

1.0

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:

Dispositivo

ActualHeight

ActualWidth

ActualScaleFactor

ScaleFactor

ZoomFactor

Resolution

DPI

1080P 6”

853

480

225

150

1.0

1080P 5.5”

853

480

225

150

1.0

720P 4.7”

853

480

150

150

1.0

WXGA 4.5”

800

480

160

160

1.0

WXGA 4.0”

800

480

100

100

1.0

¿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:

Dispositivo

ActualHeight

ActualWidth

ActualScaleFactor

ScaleFactor

ZoomFactor

Resolution

DPI

1080P 6”

853

480

225

150

1.0

1080×1920

365.76

1080P 5.5”

853

480

225

150

1.0

1080×1920

403.41

720P 4.7”

853

480

150

150

1.0

720×1280

309.97

WXGA 4.5”

800

480

160

160

1.0

768×1200

sin medir

WXGA 4.0”

800

480

100

100

1.0

800×600

sin medir

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.

Por RFOG | 1 Comentario | Enlaza esta entrada

Un Comentario

Enviado el 05/09/2014 a las 10:22 | Permalink

Nuevamente una interesante entrega.

Deja un comentario  

Tu email nunca se publica o se comparte. Los campos obligatorios están marcados con *

*
*
:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!:
Puedes usar las siguientes etiquetas y atributos HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)