Vistas de página en total

jueves, 20 de julio de 2017

Icono para la aplicación

Antes de desplegar una aplicación, se deben diseñar los iconos de la aplicación para las plataformas destino. Estos iconos deben diseñarse con los tamaños especificados en esta página y con el formato PNG. Además, para evitar incompatibilidades, las imágenes PNG deben exportarse como: non-interlaced y no conteniendo perfiles ICC.


Los iconos de la aplicación deben ponerse en el directorio raíz de la aplicación (no en subdirectorios).

Icono de la aplicación para iOS

Para iOS, se deben crear una serie de iconos para los dispositivos iOS que se van a soportar. Apple también recomienda un conjunto de iconos más pequeños para los resultados de las búsquedas con spotlight y para los settings de iOS.

Los iconos para iOS deben tener los siguientes nombres y tamaños:


Fichero
Versión iOS
W x H
Uso
Icon-167.png
>= 9.0
167 x 167
App icon - iPad Pro
Icon-60@3x.png
>= 8.0
180 x 180
App icon - iPhone 6 plus
Icon-Small-40@3x.png
>= 8.0
120 x 120
Search - iPhone 6 plus
Icon-Small@3x.png
>= 8.0
87 x 87
Settings - iPhone 6 plus
Icon-60.png
>= 7.0
60 x 60
App icon - iPhone
Icon-60@2x.png
>= 7.0
120 x 120
App icon - Retina iPhone
Icon-76.png
>= 7.0
76 x 76
App icon - iPad
Icon-76@2x.png
>= 7.0
152 x 152
App icon - Retina iPad
Icon-Small-40.png
>= 7.0
40 x 40
Search/Settings - all devices
Icon-Small-40@2x.png
>= 7.0
80 x 80
Search/Settings - all devices
Icon.png
<= 6.1
57 x 57
App icon - iPhone
Icon@2x.png
<= 6.1
114 x 114
App icon - Retina iPhone
Icon-72.png
<= 6.1
72 x 72
App icon - iPad
Icon-72@2x.png
<= 6.1
144 x 144
App icon - Retina iPad
Icon-Small-50.png
<= 6.1
50 x 50
Search/Settings - iPad
Icon-Small-50@2x.png
<= 6.1
100 x 100
Search/Settings - Retina iPad
Icon-Small.png
<= 6.1
29 x 29
Search/Settings - iPhone
Icon-Small@2x.png
<= 6.1
58 x 58
Search/Settings - Retina iPhone

Además, hay que especificar todos estos iconos en la tabla settings.iphone.plist.CFBundleIconFiles:

settings = {
    iphone 
= {
        plist 
= {
            CFBundleIconFiles 
= {
                
"Icon.png",
                
"Icon@2x.png",
                
"Icon-60.png",
                
"Icon-60@2x.png",
                
"Icon-60@3x.png",
                
"Icon-72.png",
                
"Icon-72@2x.png",
                
"Icon-76.png",
                
"Icon-76@2x.png",
                
"Icon-167.png",
                
"Icon-Small-40.png",
                
"Icon-Small-40@2x.png",
                
"Icon-Small-40@3x.png",
                
"Icon-Small-50.png",
                
"Icon-Small-50@2x.png",
                
"Icon-Small.png",
                
"Icon-Small@2x.png",
                
"Icon-Small@3x.png"
            
},
            UILaunchImages 
= {
            
},
        
}
    
},}

Icono de la aplicación para Android

En el caso de Android, los iconos de la aplicación se copian en el fichero APK durante la generación, si estuvieran disponibles en el directorio raíz de la aplicación Corona.
Estos iconos tienen que tener el nombre y tamaño que especifica Android:

Fichero
W x H
Icon-xxxhdpi.png
192 x 192
Icon-xxhdpi.png
144 x 144
Icon-xhdpi.png
96 x 96
Icon-hdpi.png
72 x 72
Icon-mdpi.png
48 x 48
Icon-ldpi.png
36 x 36


Automatizando el proceso

Existe una web donde podemos obtener todos los iconos necesarios para nuestra aplicación de forma automática. Este sitio está preparado para el framework Nativescript, pero nos puede valer igualmente:


En esta web podemos subir un icono de nuestra aplicación (PNG con tamaño mínimo de 1024x1024) y en unos segundos nos descargamos un zip con todas las imágenes en los tamaños necesarios para iOS y Android.

En el caso de android tendremos que renombrar los ficheros para que se adapten a lo indicado en el apartado anterior.


martes, 13 de diciembre de 2016

Opciones para el desarrollo de aplicaciones para móviles

Este post me gustaría que fuera bastante dinámico, es decir, que se fuera actualizando con el tiempo, ya que estas tecnologías que voy a tratar se actualizan con bastante frecuencia y además yo no poseo la verdad absoluta sobre estos temas, ni mucho menos.

Consideraré las dos plataformas más extendidas actualmente: iOS y Android.

Desde mi punto de vista existen cinco formas de desarrollar aplicaciones para móviles:


  • Native-Native
  • Cross compiled
  • Web based
  • Canvas
  • Runtime javascript

Cada una tiene uno o más productos/frameworks alternativos, y cada una tiene sus ventajas y por supuesto sus inconvenientes. Veamos brevemente cada una de ellas.

Native-Native

El desarrollo se realiza de forma nativa en el propio lenguaje (o lenguajes) nativos de la plataforma.
En iOS se utiliza Objective-C o bien Swift como lenguajes de programación. En Android se utiliza Java como lenguaje de programación.
Ventajas:
  • Acceso total al API de cada plataforma, sin limitaciones
  • Mucha documentación, cursos, libros, videos, etc
  • Herramientas de desarrollo muy avanzadas (XCode para iOS, Android Studio para Android)
  • Máximo rendimiento de las aplicaciones
  • Interfaz de usuario propio de cada plataforma
Inconvenientes:
  • No hay una base de código única, necesitamos una base de código para cada plataforma. Hay que mantener dos versiones de la misma aplicación
  • Es bastante complejo el aprendizaje
  • Depuración lenta en emulador o simulador, ya que necesita compilación

Cross compiled

Se desarrolla en un único lenguaje de programación que es "traducido" a la plataforma nativa.
El ejemplo más popular es Xamarin (ahora de Microsoft), que utiliza el lenguaje C#.
Ventajas:
  • Un único lenguaje de programación para todas las plataformas
Inconvenientes:
  • En cada plataforma tenemos que hacer desarrollos específicos (aunque son con el mismo lenguaje de programación y con algunas parte de código común)
  • El rendimiento no es muy bueno, comparado con el desarrollo nativo
  • Depuración lenta en emulador o simulador, ya que necesita compilación

Web based

Se desarrolla la aplicación utilizando tecnologías propias de la web: HTML, Javascript y CSS.
La aplicación se ejecuta en una web view, es decir, la propia aplicación incluye un navegador en el cual se ejecuta la aplicación.
Los exponentes más conocidos de este tipo de solución son: PhoneGap, Apache Cordova.
Ventajas:
  • Se aprovechan los conocimientos de desarrollo web
  • Se pueden utilizar frameworks js o css: angular, bootstrap
  • Se utiliza el DOM
  • Interfaz de usuario web conocido por el usuario
  • Base de código única para todas las plataformas
  • Depuración ágil, ya que no necesita compilación
Inconvenientes:
  • Bajo rendimiento
  • No hay acceso a todas las funcionalidades de cada plataforma
  • Es muy difícil realizar interacciones complejas (componentes avanzados o bien interacciones como swipe etc)

Canvas

Esta solución es la utilizada por Corona SDK, aunque también la utilizan Unity y Unreal (dos plataformas para desarrollo de juegos 3D y 2D). Consiste en dibujar directamente sobre un canvas vacío todos los objetos y widgets de la aplicación, no utilizando los widgets de la plataforma. Se utiliza OpenGL. Así por ejemplo, no se utiliza el botón propio de la plataforma, sino que se dibuja el botón en el canvas.
Ventajas:
  • Muy adecuado para el desarrollo de juegos (aunque también muy válida para desarrollo de aplicaciones)
  • Base código única para todas las plataformas
  • Mismo lenguaje de programación para todas las plataformas
Inconvenientes:
  • La interfaz de usuario no tiene el aspecto propio de cada plataforma (el aspecto es el mismo en todas las plataformas)
  • Depuración rápida en simulador

Runtime Javascript

Ésta es probablemente la tecnología más novedosa y no debe confundirse con Web based, porque a pesar de que se utiliza javascript como lenguaje de programación, no tiene nada que ver con la web.
En este caso, la aplicación incluye un motor javascript incorporado (V8 en Android y Javascript Core en iOS). El motor ejecuta el código javascript directamente y hace llamadas a la plataforma nativa cuando es necesario. No utiliza el DOM, ya que no incluye una web view.
Los frameworks más conocidos son: React Native, Appcelerator Titanium y NativeScript.
Ventajas:
  • Base de código única para todas las plataformas
  • Lenguaje de programación único, muy conocido
  • Aspecto de la interfaz de usuario propio de cada plataforma (se utilizan los widgets nativos de cada plataforma)
  • Desarrollo muy ágil debido a que se recarga el javascript (no es necesario recompilar)
Inconvenientes:
  • Rendimiento aproximadamente un 10% peor que el desarrollo nativo
  • No hay entornos de desarrollo muy avanzados para estas soluciones

jueves, 29 de septiembre de 2016

Escalado adaptativo

Antes de nada, quiero avisar que esta entrada es un tema relativamente avanzado y que puede ser de poca utilidad, ya que voy a describir un modo de escalado complejo de utilizar y que no es muy utilizado en la práctica. Si quieres, puedes saltarte este post y pasar al siguiente.

Corona soporta varios modos de escalado para pasar lo que nosotros hemos "dibujado" en la pantalla virtual a la pantalla física del dispositivo:
  • letterbox
  • zoomEven
  • zoomStretch
  • none
Ya vimos en una entrada anterior qué modos son más convenientes tanto para juegos como para aplicaciones.
No hace mucho, Corona introdujo un nuevo modo, el modo adaptive, que es adecuado para aplicaciones (este modo no tiene mucho sentido para los juegos). Vamos a verlo un poco en detalle.

Escalado simple

La forma más inmediata de hacer escalado es definir un tamaño fijo de pantalla (ancho x alto) en pixels virtuales, y situar nuestros objetos, texto e imágenes en esa pantalla virtual. Después se especifica un modo de escalado, por ejemplo "letterbox", que indica a Corona cómo rellenar la pantalla del dispositivo físico a partir del contenido de la pantalla virtual. El tamaño de la pantalla virtual lo podemos obtener con el API de Corona:
  • display.contentWidth
  • display.contentHeight
Esto es lo que ya habíamos visto en anteriores posts.

Tamaño de la pantalla virtual cambiante

El escalado simple funciona bien en muchas situaciones (por ejemplo en juegos), pero no es la solución en absolutamente todos los casos. El escalado simple tiene algunas desventajas:
  • La relación de aspecto es fija (sea cual sea el dispositivo final), lo cual provoca franjas en los lados, como ya hemos visto
  • Puede ocurrir que el escalado al dispositivo real no sea un número entero. Por ejemplo, si la pantalla virtual tiene un ancho de 320 y el dispositivo real tiene un ancho de 480, entonces cada pixel de la pantalla virtual tiene que traducirse a 1.5 pixels de la pantalla física. Esto lo hace Corona bastante bien, pero en algunas imágenes pueden notarse ciertas imperfecciones.
  • Los widgets (botones, combos, etc) se verán escalados igual que el resto de los objetos. Lo cual provocará que en dispositivos como tablets veamos botones excesivamente grandes. Lo razonable sería que el tamaño de ciertos widgets fuera similar en todos los dispositivos, que no se escalaran por igual.
Estos problemas afectan fundamentalmente a las aplicaciones (no tanto a los juegos).
Una solución a estos problemas es que el tamaño de la pantalla virtual cambie en función del dispositivo. Esto es, que el tamaño de la pantalla virtual que definimos en config.lua tenga ancho y alto en función del tamaño del dispositivo. De esta forma se puede mantener la relación de aspecto del dispositivo (no franjas laterales) y escalar los pixels de forma perfecta (sin decimales).

Escalado adaptativo

Cambiar el tamaño de la pantalla virtual en función del dispositivo físico resuelve dos de los problemas mencionados anteriormente, pero no resuelve el problema del escalado proporcional de algunos widgets. Lo ideal sería que algunos widgets tuvieran el mismo tamaño "real" en todos los dispositivos.
El modo adaptativo de escalado resuelve todos estos problemas.

Principios

Cuando se selecciona el modo "adaptive" en config.lua, Corona calcula el ancho y el alto de la pantalla virtual mediante una serie de algoritmos. Los objetivos de estos algoritmos son:
  • Debe mantenerse la relación de aspecto (sin franjas laterales)
  • El escalado de pixels debe ser un número entero, o al menos, fracciones muy simples
  • La densidad de pixels debe ser aproximadamente la misma en todos los dispositivos (la densidad de pixels mide el número de pixels que hay en cada pulgada de pantalla, si la densidad es similar, el tamaño de los widgets será el mismo en todos los dispositivos).

Desventajas

La primera (y creo que única) gran desventaja del modo adaptativo es que, como el tamaño de la pantalla virtual no es fijo, se complica bastante el desarrollo (sobre todo el posicionamiento y tamaño de los objetos en la pantalla). No podremos utilizar valores fijos para la posición y el tamaño de los objetos. Cada tamaño y posición se tendrán que calcular en función del ancho y alto de la pantalla virtual.

Escalado simple vs adaptativo

La diferencia entre el resultado entre estos dos modos se puede ver con un ejemplo sencillo. No voy a poner el código de la aplicación para evitar complicarnos la vida. Voy a poner dibujos sencillos para entender el problema.
Imaginemos una pantalla con una lista de elementos y un botón abajo:



En el escalado simple, los objetos serán más grandes (más centímetros) en un dispositivo más grande, proporcionalmente al tamaño de la pantalla (en todos los modos de escalado simple: letterbox, zoomEven, zoomStrech). Veamos esta aplicación en un iPhone4 y en un iPhone6 plus:



Se observa que el alto de cada fila es mayor (más centímetros) en el dispositivo grande. Sin embargo,tenemos el mismo número de filas en ambos dispositivos.

En el modo adaptativo los objetos tienen el mismo tamaño (aproximadamente) en todos los tamaños de dispositivo. Esto significa que en dispositivos con pantalla más grande dispondremos de más espacio para meter más elementos. Por ejemplo, se podrán visualizar más elementos en la lista.



En este caso, el alto de la fila en centímetros es el mismo en ambos dispositivos, y por tanto, se muestran más filas en el dispositivo grande.

Creo que con esta explicación se puede entender el modo de escalado adaptativo, que se puede resumir en:


  • más complejo de programar (no se pueden utilizar coordenadas absolutas, ya que el tamaño de la pantalla virtual cambia en función del dispositivo)
  • la relación de aspecto de la pantalla virtual es la misma que la del dispositivo
  • el escalado se hace con números enteros (o fracciones muy simples)
  • no hay franjas laterales
  • si especificamos el tamaño de los widgets numéricamente (width=100), entonces el tamaño en centímetros es el mismo para todos los dispositivos

Y por último, no utilicéis el modo adaptativo para juegos, no merece la pena.





lunes, 19 de septiembre de 2016

Mi solución para juegos y aplicaciones

En las últimas entradas hemos estado viendo cómo resolver el problema de los distintos tipos de pantalla en los que nuestra aplicación se puede ejecutar. Hemos visto que Corona nos ofrece una pantalla virtual donde situamos nuestros objetos (con un tamaño definido por nosotros) y después Corona se encarga de escalar ese contenido a la pantalla real del dispositivo. Hemos visto que hay varios modos de escalado. Y además, sabemos que el API de Corona, en el objeto display tiene algunas constantes muy útiles. Con todo esto, y con la alineación de la pantalla virtual (que vamos a ver ahora mismo), es posible resolver casi cualquier problema. Nos centraremos en el modo "letterbox" que es el que yo utilizo habitualmente.
Empecemos con la alineación.

Alineación de la pantalla virtual

Como vimos, en modo "letterbox", el escalado puede producir bandas laterales (o superior/inferior) si las proporciones de la pantalla virtual no coinciden con las de la pantalla real. En estos casos Corona por defecto centra la pantalla virtual en la pantalla física, es decir, deja el mismo espacio arriba y abajo, o bien el mismo espacio a izquierda y derecha.
Sin embargo, este comportamiento por defecto se puede cambiar. Para ello, recurrimos al fichero config.lua:

application = {
    content = {
        width = 320,
        height = 480, 
        scale = "letterBox",
        xAlign = "center",
        yAlign = "center",
    },
}

Hemos añadido dos nuevos miembros a la conocida tabla application.content
xAlign indica la alineación horizontal
yAlign indica la alineación vertical
Con estos dos nuevos parámetros podemos cambiar la forma en que Corona sitúa la pantalla virtual dentro de la pantalla física.
El parámetro xAlign puede tomar los siguientes valores:
  • "left"
  • "center"
  • "right"
Y el parámetro yAlign puede tomar los siguientes valores:
  • "top"
  • "center"
  • "bottom"
De esta forma podemos controlar cómo se encaja la pantalla virtual en la física. En unos momento vamos a ver la utilidad de estos dos parámetros.

Solución para los juegos

Para los juegos, yo utilizo siempre el modo letterbox, para no perder información y para no deformar. Como van a aparecer bandas laterales en muchos casos, también utilizo xAlign = "center", yAlign="center" de esta forma me aseguro que el juego propiamente dicho aparece centrado en la pantalla.
¿Qué hago con las bandas laterales? Utilizo las constantes:

display.actualContentWidth
display.actualContentHeight

para poner un rectángulo o una imagen en el fondo que encaje bien con el resto del juego. Este rectángulo no aparecerá si las proporciones del dispositivo son iguales que las de la pantalla virtual.
El juego aparecerá escalado en función de la pantalla del dispositivo sin ninguna deformación.
Esta solución es muy sencilla de implementar y funciona en todos los casos.

Solución para las aplicaciones

Paradójicamente, el caso de las aplicaciones es algo más complejo que el de los juegos (aunque dije que el desarrollo de juegos es más difícil que el de aplicaciones).
En este caso, la aplicación tiene que mostrar una serie de elementos (widgets) en la pantalla y no siempre lo mejor es que salga centrada en pantalla. Por ejemplo, una aplicación que tenga una barra superior con algunas opciones de menú tiene que salir siempre arriba del todo, no vale que salga un poco más abajo por causa de las bandas del letterbox. Igualmente, si tenemos pestañas abajo, éstas tiene que salir abajo del todo.
Mi solución en este caso, es usar de nuevo "letterbox" como modo de escalado (no quiero deformaciones ni pérdida de información), pero en este caso alineo la pantalla virtual a la parte superior. Mi fichero config.lua sería algo así como:

application = {
    content = {
        width = 320,
        height = 480, 
        scale = "letterBox",
        xAlign = "center",
        yAlign = "top",
    },
}

De esta forma consigo que el contenido se visualice a partir de la parte superior de la pantalla. El problema entonces es cómo conseguir rellenar el espacio sobrante por abajo. Lo que hago es, utilizando las constantes:

display.actualContentWidth
display.actualContentHeight

puedo situar los elementos inferiores ajustados a la parte inferior de la pantalla (en función de estas constantes). Y el espacio que sobra en el centro, lo utilizo para los elementos centrales.
Como se puede intuir, la parte central no va a tener un tamaño fijo, sino que dependerá de las proporciones del dispositivo físico.
Normalmente la parte central suele ser una lista de elementos con scroll o algo similar, con lo cual, es fácilmente adaptable a un tamaño variable.
Ya veremos ejemplos de todo esto en futuras entradas.



viernes, 16 de septiembre de 2016

Modos de escalado en Corona SDK

Para resumir las últimas entradas, vimos que si pintamos objetos en pantalla utilizando los pixels del dispositivo (pixels reales), tenemos un problema por los diversos tamaños de pantalla y resoluciones que tienen los distintos dispositivos. También vimos que Corona permite definir una pantalla virtual con un tamaño determinado y definiendo un modo de escalado. Vimos el modo "letterbox" que lo que hace es centrar la pantalla virtual en la pantalla física aprovechando al máximo el espacio y escalando los objetos proporcionalmente y sin deformarlos. Cuando ponemos los objetos en la pantalla virtual nos olvidamos del tamaño real de la pantalla del móvil, para nosotros sólo existe esa pantalla virtual que tiene un tamaño determinado en pixels virtuales. Obviamente, dependiendo de las proporciones del dispositivo destino, en algunos casos, la pantalla virtual no se adapta 100% a la pantalla física, y pueden quedar zonas (arriba y abajo, o bien, a izquierda y derecha) que no estén cubiertas por la pantalla virtual.
Las constantes:

    display.contentWidth
    display.contentHeight

nos dan el tamaño de la pantalla virtual (en pixels virtuales).

Todo esto en cuanto al modo "letterbox", pero éste no es el único modo de escalado que tiene Corona. En esta entrada vamos a tratar este tema para conocerlos todos y ver cuál se adapta mejor a las necesidades de nuestra aplicación o juego.

Escalado

En Corona, como ya he dicho varias veces, trabajamos con una pantalla virtual de un determinado tamaño fijo, y nuestro programa siempre va a trabajar con pixels en las coordenadas de esa pantalla virtual.
Cuando la aplicación se ejecuta en un dispositivo, los pixels virtuales se expanden (o se contraen) para rellenar la pantalla del dispositivo. A esto se le llama escalado.
Nuestro programa no tiene porqué conocer el tamaño real del dispositivo, simplemente trabaja sobre la pantalla virtual, y Corona se encargará de escalar el contenido a la pantalla física. Corona escalará todos los objetos gráficos, el texto, las imágenes, etc.
Es muy habitual definir una pantalla virtual de 320x480. Se suele utilizar este tamaño porque casi todos los dispositivos iOS y muchos Android tienen la misma relación de aspecto.
Los modos de escalado que ofrece Corona son:
  • letterbox
  • zoomEven
  • zoomStretch
  • none

Modo letterbox

Este es el modo más utilizado y el que se suele utilizar en caso de duda.
El modo letterbox nunca deforma ni corta los objetos. Por tanto, es el modo más fácil de utilizar.
Todo lo que se sitúe dentro de la pantalla virtual se mostrará en la pantalla del dispositivo sin deformaciones y sin que los objetos se salgan de la pantalla.
En modo letterbox hay tres casos a considerar:



En el primer caso, la relación de aspecto de la pantalla virtual coincide con la del dispositivo, con lo cual no tenemos que hacer nada y el escalado será perfecto.
En el segundo caso, el dispositivo es algo alargado, y por tanto, como la pantalla virtual no se puede deformar, quedará un espacio arriba y abajo de la pantalla real que no se pueda rellenar con la pantalla virtual.
En el tercer caso, el dispositivo es más ancho y por tanto, al encajar la pantalla virtual en el dispositivo (sin deformar), quedará espacio a izquierda y derecha sin deformar.

En la práctica, rellenaremos estas zonas fuera de la pantalla virtual con contenido que no sea relevante, por ejemplo con un fondo. No podemos poner objetos que sean importantes porque en algunos dispositivos no se va a visualizar.

Podemos saber el espacio que tenemos fuera de la pantalla virtual con las constantes:

    display.actualContentWidth
    display.actualContentHeight

que nos indican el tamaño total que disponemos, en coordenadas virtuales.
Así por ejemplo, si queremos poner un fondo que ocupe la pantalla entera:

    local bg = display.newRect( 
            display.contentCenterX, display.contentCenterY,
            display.actualContentWidth, display.actualContentHeight)
    bg:setFillColor(0.5, 0.4, 0,7)

Y podemos poner encima otro rectángulo que ocupe la pantalla virtual completamente, que es donde deberíamos situar el contenido importante de nuestra aplicación:

    local content = display.newRect( 
            display.contentCenterX, display.contentCenterY,
            display.contentWidth, display.contentHeight)
    content:setFillColor(0.6, 0.5, 0,8)


Ahora, dependiendo del dispositivo, veremos un caso u otro de los mencionados anteriormente para letterbox.
El fichero config.lau contiene lo siguiente:

application = {
    content = {
        width = 320,
        height = 480,
        scale = "letterbox",
    },
}

Modo zoomEven

Este modo es el más utilizado, después de letterbox. En este modo, la pantalla virtual se expande lo máximo posible, y si es necesario habrá partes de la pantalla virtual que quedarán fuera del dispositivo y no se verán. El escalado es proporcional, sin deformación (escala igual en un eje que en el otro, igual que letterbox). Lo bueno que tiene este modo es que no hay barras laterales sin rellenar. Pero tiene el inconveniente de que pueden quedar zonas de la pantalla que no se muestran.


Para ver el modo zoomEven en acción, escribamos el siguiente fichero de config.lua:

application = {
    content = {
        width = 320,
        height = 480,
        scale = "zoomEven",
    },
}

Y el siguiente main.lua:

local bg = display.newRect( display.contentCenterX, display.contentCenterY, display.contentWidth, display.contentHeight )
bg:setFillColor( 1, 1, 1 )

local circle = display.newCircle( display.contentCenterX, display.contentCenterY, display.contentWidth/2 )
circle:setFillColor( 0.3, 0.6, 0.3 )

En blanco vemos la pantalla virtual y en el centro de ésta un círculo verde, que no se deforma en ningún dispositivo, pero que se puede salir fuera de la pantalla y no dibujarse completamente según el tamaño del dispositivo final.
Si el dispositivo es iPhone 4, entonces veremos el círculo completo, porque la relación de aspecto del iPhone 4 es la misma que la de nuestra pantalla virtual (tamaños distintos pero misma relación de aspecto). Sin embargo en otros dispositivos como el iPhone 5, más alargado, el círculo se cortará.

zoomStretch

Este modo escala, deformando si es necesario, la pantalla virtual a la pantalla física. Es decir, puede escalar de forma distinta en el eje X y en el eje Y.
No se utiliza mucho este modo porque la deformación que produce no suele ser aceptable. No se me ocurre ninguna aplicación en la que pudiera ser útil este modo. Pero es bueno saber que existe, por si acaso es necesario.

none

Este modo es equivalente a no tener ningún modo de escalado en config.lua

Resumen

  • letterbox: no deforma, puede haber barras laterales, no recorta
  • zoomEven: no deforma, no puede haber barras laterales, puede recortar
  • zoomStretch: puede deformar, no puede haber barras laterales, no recorta
¿Cuál es la mejor opción? En mi opinión, yo uso casi siempre letterbox, con una opción de alineamiento que explicaré en la próxima entrada. Pero eso no quita para que en algunos casos sean interesantes los otros modos.

miércoles, 14 de septiembre de 2016

Múltiples tamaños de pantalla en Corona SDK

Pixels reales vs pixels virtuales

En la entrada anterior vimos claramente el problema: Si no le decimos nada a Corona, las coordenadas y tamaños que especifiquemos para los objetos de pantalla se traducen directamente a pixels en la pantalla del móvil. O sea, las coordenadas x=300,y=400 se traducen a los pixels 300,400 de la pantalla. Igualmente con los tamaños: Un rectángulo con ancho=100 y alto=200 se traduce en la pantalla a un rectángulo de 100 pixels de ancho y 200 pixels de alto. Esto que parece lógico, hemos visto que causa problemas muy importantes cuando la aplicación tiene que ejecutarse en dispositivos con tamaños distintos de pantalla.

¿Cómo soluciona Corona SDK este problema? Pues mediante un mecanismo que se denomina "content scaling" (escalado de contenido). La idea, es no trabajar con los pixels reales directamente, sino sobre lo que podríamos denominar pixels virtuales. Es decir, definimos un tamaño de pantalla, por ejemplo, 320x480, y trabajamos sobre esa pantalla siempre. Corona se encargará después de convertir las coordenadas y tamaño de los objetos en pixels reales del dispositivo.

Por ejemplo, si definimos nuestra pantalla virtual en 320x480 y queremos un rectángulo centrado verticalmente y que ocupe todo el ancho de la pantalla, lo situaremos en x=160,y=240, y le definiremos un ancho de 320. Si el dispositivo tiene una resolución de 640x960, Corona se encargará de traducir las coordenadas y tamaño a esos pixels reales del dispositivo. En nuestro ejemplo, Corona situará el objeto en x=320,y=480, y el ancho será 640. En otro dispositivo con otra resolución, hará otra conversión a pixels reales, pero siempre podemos conseguir que el rectángulo salga centrado verticalmente y que ocupe todo el ancho.

Para que Corona pueda trabajar con una pantalla virtual, tenemos que crear un fichero nuevo, en el mismo directorio que el main.lua, denominado config.lua. El contenido de este fichero será:

application = {
    content = {
        width = 320,
        height = 480,
    },
}

Este fichero tiene una tabla, llamada application, y dentro de esta tabla hay otra tabla, llamada content que define el ancho y el algo de la pantalla virtual. En nuestro caso 320x480. Como veremos más adelante en la tabla application, podremos definir otros valores de configuración de nuestra aplicación, de momento nos quedamos con el tamaño de la pantalla virtual.

Probemos otra vez con el programa anterior, main.lua:

local rect = display.newRect( 160, 240, 320, 200 )
rect:setStrokeColor( 1,0,0 )
rect.strokeWidth = 5

Si ejecutamos ahora, veremos que el resultado es siempre el mismo, independientemente del dispositivo que elijamos en el simulador.

La proporción o relación de aspecto

Aunque parezca que ya hemos resuelto el problema, realmente no es así.
Vamos a ver qué pasaría si en lugar de un rectángulo, tenemos un círculo:

local circle = display.newCircle( 160, 240, 100 )
circle:setStrokeColor( 1,0,0 )
circle.strokeWidth = 5

Probamos primero en iPhone 4:



Todo bien, sale un círculo perfectamente centrado en la pantalla. Estamos trabajando con una pantalla virtual de 320x480, colocamos el círculo en x=160,y=240 (centro de la pantalla virtual) y Corona traslada correctamente estas coordenadas al centro de la pantalla del iPhone 4.
Pero cambiemos ahora el dispositivo a Nexus One, por ejemplo. Nos encontramos con una sorpresa:


Si nos fijamos bien, esto ya no es un círculo, ¡es una elipse! ¿qué ha pasado? El problema es que nuestra pantalla virtual, 320x480, tiene una relación de aspecto (ancho/alto) de 0.66 (320/480). El iPhone 4 tiene una relación de aspecto idéntica: 640/960=0.66, con lo cual, Corona no distorsiona el círculo al escalarlo en el iPhone 4. Sin embargo, la pantalla del Nexus es 480x800, y por tanto, la relación de aspecto es: 480/800=0.6, ligeramente distinta a las anteriores. Podríamos probar con otros dispositivos y veremos que la relación de aspecto cambia en cada uno.
TRUCO: para mostrar el tamaño de la pantalla virtual y el tamaño de la pantalla real, podemos utilizar el siguiente código al principio de main.lua:

-- dimensiones de la pantalla virtual
print( display.contentWidth, display.contentHeight, display.contentWidth/display.contentHeight )

-- dimensiones de la pantalla real
print( display.pixelWidth, display.pixelHeight, display.pixelWidth/display.pixelHeight )

Si vamos cambiando el dispositivo, podemos ir comprobando las distintas relaciones de aspecto de los distintos dispositivos.

Este problema lo podemos arreglar simplemente añadiendo una línea a la tabla application de config.lua:

application = {
    content = {
        width = 320,
        height = 480,
        scale = "letterbox",
    },
}

Si ahora probamos con distintos dispositivos veremos que siempre tenemos un círculo perfecto (no una elipse) centrado perfectamente en la pantalla.
El parámetro scale dice a Corona cómo tiene que escalar los objetos cuando traduce los pixels virtuales a pixels reales del dispositivo. Después veremos los distintos modos, de momento nos quedamos con que el modo de escalado "letterbox" no deforma los objetos.

Parece que ya hemos llegado al final del problema, y que con esto ya podemos hacer aplicaciones que funcionen en todo tipo de dispositivos. Pero, por desgracia, no es así. Estamos cerca de la solución, pero todavía queda algo. Parece que este problema no acaba nunca, y es que realmente estamos ante un problema que trae de cabeza a muchos desarrolladores de aplicaciones para múltiples dispositivos.

Letterbox y las bandas

Vamos a dibujar un rectángulo de color azul en nuestra aplicación. Ese rectángulo debería hacer de fondo de la aplicación y cubrir toda la pantalla. Añadamos estas líneas en main.lua justo antes de crear el círculo:

local background = display.newRect( 160, 240, 320, 480 )
background:setFillColor( 0,0,1 )

Probamos con iPhone 4.



Todo perfecto, el rectángulo azul cubre todo el fondo.
Ahora como siempre, cambiemos a otro dispositivo con otra relación de aspecto, por ejemplo el Nexus:



Aunque podría pasar desapercibido, han aparecido dos bandas negras, una arriba y otra abajo. Realmente no ha aparecido ninguna banda. El problema es que la pantalla virtual, en modo de escalado "letterbox" (que no deforma), no puede cubrir completamente la pantalla del Nexus, porque la relación de aspecto es distinta. Es decir, en modo "letterbox" la pantalla virtual sólo puede cubrir completamente la pantalla real si la relación de aspecto es la misma (como ocurre en el iPhone 4).

Hagamos números: En el iPhone 4, para convertir de pixels virtuales a pixels reales, Corona multiplica por 2 tanto el ancho como el alto (como estamos en modo "letterbox" se multiplican ambas dimensiones por el mismo valor, para no deformar). Al multiplicar por 2, el rectángulo de 320x480 se convierte en 640x960 pixels reales, y cubre la pantalla completa del iPhone 4.
En el caso del Nexus, Corona busca un factor multiplicativo para convertir de 320x480 a 480x800. Como no puede deformar, el valor es el mismo en ambas dimensiones. En este caso, 1.5, que hace que el ancho se ajuste completamente, ya que 320 multiplicado por 1.5 es  480. Sin embargo, al multiplicar 480 por 1.5 tenemos 720, que es ligeramente inferior a los 800 pixels reales del alto de pantalla del Nexus. De ahí que Corona deja sin rellenar una parte por arriba y por abajo.

¿De dónde sale es valor de 1.5 para el Nexus? No es complicado. Es el valor que permite rellenar completamente una de las dos dimensiones, ancho o alto, sin pasarse en la otra dimensión. Así, para el caso del Nexus:

    valor para rellenar el ancho: 480 / 320 = 1.5
    valor para rellenar el alto: 800 / 480 = 1.66

Se coge el valor más pequeño, o sea, 1.5
En el caso del iPhone 4, ambos valores salen 2, y por tanto, la pantalla virtual se corresponde exactamente con la pantalla real.

Todo esto, como he dicho, es para el modo de escalado "letterbox". En la siguiente entrada hablaré de otros modos de escalado.

Podríamos conseguir que las bandas laterales salgan a la izquierda y a la derecha si definimos una pantalla virtual muy "estilizada", por ejemplo:

application = {
    content = {
        width = 160,
        height = 480,
        scale = "letterbox",
    },
}

Y el main:

local background = display.newRect( 80, 240, 160, 480 )
background:setFillColor( 0,0,1 )


Cómo quitar las bandas

Hemos visto que el modo de escalado "letterbox" no deforma al escalar desde la pantalla virtual a la pantalla real. Además, si sobra espacio al escalar, deja el mismo espacio por arriba y por abajo (o bien por la izquierda y derecha en caso de que la dimensión "perjudicada" sea el ancho).

Para resolver este y otros problemas relacionados con los tamaños, es conveniente conocer una serie de constantes que nos proporciona Corona SDK a través de su API:

  • display.contentWidth y display.contentHeight: ancho y alto de la pantalla virtual
  • display.pixelWidth y display.pixelHeight: ancho y alto de la pantalla real
  • display.actualContentWidth y display.actualContentHeight: ancho y alto real de la pantalla, pero en pixels virtuales. Esto merece una explicación. En el caso de bandas arriba y abajo, display.actualContentWidth va a ser igual a display.contentWidth, sin embargo, display.actualContentHeight va a ser superior a display.contentHeight
Con estas constantes, ya podemos definir fácilmente un rectángulo que cubra toda la pantalla en cualquier dispositivo:

local background = display.newRect( display.contentWidth/2, display.contentHeight/2, display.actualContentWidth, display.actualContentHeight )

background:setFillColor( 0,0,1 )

Existen otras constantes en el API de Corona que nos ayudarán en el futuro:

  • display.contentCenterX y display.contentCenterY: coordenadas del centro de la pantalla en pixels virtuales
En la siguiente entrada, seguiré hablando de los modos de escalado y de otras técnicas para hacer aplicaciones multidispositivo.






El problema de múltiples pantallas y proporciones

El problema

Este tema de hoy es quizás unos de los más peliagudos y difíciles de entender en la programación de aplicaciones para móviles. En la siguiente entrada veremos cómo resolverlo en Corona SDK.

El problema de la programación para móviles es la (inmensa) diversidad de tamaños de pantalla en los dispositivos. Tenemos móviles desde 4 pulgadas hasta 6 pulgadas, y además tenemos las tablets, que pueden ir desde 7 pulgadas hasta las casi 13 pulgadas del iPad Pro de Apple. Además, para completar el panorama, las proporciones de la pantalla también cambian. Tenemos pantallas 4x3, 5x4, y casi cualquier combinación de parejas números.
Obviamente, como buenos programadores (y como interesados en distribuir/vender muchas unidades de nuestra aplicación), queremos que nuestra aplicación se ejecute igual de bien en el número máximo de dispositivos posible. Este es uno de los problemas más importantes que se dan en la programación móvil. Y hay varias soluciones:
  • layouts: que mueven y redimensionan dinámicamente los elementos en función del tamaño de la pantalla en base a una serie de reglas del estilo: este elemento se ajusta a la izquierda, este elemento va a la izquierda de este otro, etc. Esta programación con layouts es una solución muy interesante y que funciona muy bien "la primera vez", quiero decir, para la primera versión de nuestra aplicación. Pero el gran problema es cuando el cliente o nuestro jefe nos dice: "Tenemos que meter una lista debajo de ese botón", y es entonces cuando aparecen los sudores y temblores en el programador, pensando que va a tener que volver a redefinir todas las reglas de layouts para que todo quede bien por culpa de un simple elemento. Y lo peor llega cuando rematan la frase con: "Esto es fácil, verdad? Es sólo añadir un elemento más". Se puede desprender de estas líneas que aunque es bonita la idea de los layouts, no creo que sean la mejor idea (es mi opinión absolutamente personal). En cualquier caso, Apple utiliza layouts en los desarrollos para iOS y parece que a los programadores les gusta.
  • hacer proporcionales los elementos con respecto al tamaño de la pantalla: esto es más o menos lo que hace Corona, y que veremos en esta entrada.
  • llenar el código de if's y colocar los elementos en función del tamaño y proporciones de la pantalla, asegurándose que todo cuadra en todas las posibilidades. El lector comprenderá que esta opción, un tanto primitiva, no es muy adecuada en cuanto tengamos 10 o más elementos en una misma pantalla. Pero como siempre, para gustos los colores, hay gente muy muy paciente que es capaz de rellenar el código de if's preguntando por miles de posibles valores.

Hay otras soluciones, pero realmente la que me interesa explicar con detalle es la que se utiliza en las aplicaciones con Corona.

Ejemplo

Vamos a hacer un sencillo ejemplo donde podemos ver el problema, así de paso, ya vamos viendo el mundo de las apps.
Creamos un directorio en nuestro disco duro y también creamos un fichero nuevo: main.lua, que será el punto de arranque de nuestra aplicación. El contenido del main.lua será:

    local rect = display.newRect( 320, 480, 640, 320 )

Abrimos el simulador de Corona, seleccionamos la carpeta de nuestro proyecto y lo ejecutamos. Pero atención, vamos a ir al menú View > View As > iPhone 4. En la pantalla tendremos algo como lo siguiente:


Reconozco que el programa no es gran cosa, pero no se puede pedir mucho más por una única línea de código.
Aunque creo que se entiende bien, diré que estamos creando un rectángulo en la pantalla, en las coordenadas x=320, y=480, con ancho 640, y alto 320. Como podemos ver, el cuadrado sale centrado verticalmente en la pantalla del móvil y además ocupa todo el ancho de la pantalla. En Corona, como veremos más adelante, las coordenadas x,y de los objetos. sitúan el centro del objeto, por eso el cuadrado aparece centrado en la pantalla del iPhone 4 (que tiene un tamaño de pantalla de 640x960, y el centro es 320x480). En otros entornos, las coordenadas x,y sitúan la esquina superior izquierda del objeto, pero no así en Corona (ya veremos más adelante que este comportamiento se puede cambiar).
Hasta ahora todo muy bien. Pero vamos a ver qué ocurre si visualizamos nuestro programa en otro dispositivo, por ejemplo, en un iPhone 6. Vamos al menú View > View As > iPhone 6 y veremos algo como esto:


El resultado es parecido. Pero hay unas diferencias muy importantes: Sin haber cambiado coordenadas ni tamaño en nuestro programa, resulta que ahora el rectángulo ya no sale centrado verticalmente en la pantalla. ¿Por qué? Esto es fácil de responder: el tamaño del iPhone 6 es distinto, 750x1334, por tanto, la coordenada y=480 ya no es el centro vertical de la pantalla, y por tanto, el objeto no sale centrado verticalmente. Hay otro cambio, el rectángulo no ocupa todo el ancho de la pantalla. La justificación de esto también es obvia: El ancho de pantalla del iPhone 6 es 750, y el ancho de nuestro rectángulo es 640, por tanto no va a ocupar todo el ancho de la pantalla en el iPhone 6 (aunque sí en un iPhone 4).
Vamos a visualizar nuestro programa en un Nexus One (recordemos, View > View As > Nexus One). Aquí la situación todavía es peor, ya que la pantalla de este teléfono tiene 480x800. En este caso, no sólo no tenemos un rectángulo centrado verticalmente en la pantalla, sino que además, no cabe completamente en la pantalla. Esto es todavía peor, porque podemos perder contenido. Creo que no es difícil entender el resultado.

En el caso del Nexus One, estamos perdiendo 160 pixels del rectángulo (640 que es el ancho del rectángulo, menos 480 que es el ancho de pantalla del Nexus).
Si queremos comprobarlo, pongamos un borde alrededor del rectángulo y comprobemos que el borde derecho no se visualiza en el Nexus:

    rect:setStrokeColor( 1,0,0 )
    rect.strokeWidth = 5

En resumen, tenemos un problema. Hay que hacer algo para que cuando coloquemos objetos en la pantalla, no tengamos que preocuparnos del tamaño real del dispositivo en el que se ejecutará nuestra aplicación.