Cómo optimizar el software para Windows y Tablets

Es evidente que el futuro de Windows tiene que ver con las tablets y pantallas táctiles. Pero, ¿cómo escribir software que aproveche al máximo la variedad de dispositivos en que Windows se ejecuta? La clave para esto, es trabajar con los fundamentos construidos en Windows.

software-windows-tables

Uno de los puntos fuertes de Windows a menudo pasado por alto es la compatibilidad hacia atrás. Es tan fácil siempre tener en cuenta el hardware más reciente, mientras que te olvidas del hardware existente y la necesidad de encontrar formas de escribir software que puede funcionar en ambos.

Windows tiene una larga historia basada en la compatibilidad hacia atrás que puede permitir a los desarrolladores de software escribir software que se puede ejecutar en hardware actual, así como en hardware heredado. La clave para esto es la API Win32 de Windows sobre la cual fue construido.

Win32API

Mucho se ha escrito acerca de cómo usar las pantallas táctiles en tablets es tan diferente a usar el teclado y el ratón de una computadora de escritorio. En lugar de obligar a los usuarios a tener que elegir una u otra, ¿por qué no puedes el software escribirse dinámicamente y que vaya a cambiar dependiendo del hardware sobre el que se utiliza?. Aunque la mayoría de los programadores de hoy en día dependen de marcos de software complejos, pocos pueden apreciar el poder del bajo nivel de la API de Windows. Esta API fue diseñada para ser dinámica. Uno de los problemas que se enfrentan es cómo construir software que pueda tomar ventaja de las características que se encuentran en una nueva versión de Windows, sin dejar de apoyar las versiones anteriores de Windows. La solución es fácil y ha existido en Windows desde Windows 95. Hay APIs que permiten que al software comprobar si existe una API o no, y entonces, si lo hace, es llamar a través de un puntero y si no lo hace, se utiliza una solución alternativa. Además, Windows proporciona una gran cantidad de información acerca de las especificaciones actuales del equipo de ejecutarlo, lo que el software puede ser escrito a implementar características nuevas cuando estén disponibles y transformarse a sí mismo a ese hardware.

Otro problema con las diferentes versiones de Windows es que las interfaces de usuario seguirán cambiando. El aspecto y la sensación pueden ser diferentes, entre diferentes versiones de Windows. Una vez más, la API de Windows viene al rescate. En lugar de depender de la apariencia por defecto y sentir por los elementos de la interfaz de usuario, la API de Windows, desde Windows 95, ha ofrecido una variedad de medios para personalizar la apariencia de una aplicación. Cosas como OwnerDraw, customdraw, subclases (para cambiar el comportamiento por defecto), superclassing (construir nuevas clases de control sobre los ya existentes) e incluso clases de escritura de ventana personalizadas desde cero, todas ofrecen maneras de escribir aplicaciones que pueden parecer y actuar de manera muy similar en varias versiones de Windows. Lo sorprendente es que estas características han estado en Windows desde el principio, desde Windows 95.

Incluso cuando se trata de gráficos, no es totalmente dependiente de lo último en hardware de DirectX y la última versión de Windows. Desde Windows 95, El soporte de DIB está en la API de bajo nivel (mapas de bits independientes del dispositivo), ha sido la piedra angular sobre la cual las tecnologías posteriores (por ejemplo, vídeo) se han construido. Cuando necesites una solución para la animación gráfica, puedes construir tu propio control lienzo personalizado utilizando la API de DIB y crear tu propio motor de sprites 2D en la parte superior del mismo. La belleza de esto es que ese control gráfico no dependerá de una versión específica de Windows ni requerir DirectX (sin necesidad de hardware especial o drivers). Si bien algunas de las características gráficas más avanzadas pueden requerir cosas más avanzadas, ese motor sprites 2D se ejecutará en Windows 95 hasta Windows 8. También es sorprendente lo poco que ha cambiado en el bajo nivel de la API de Win32 y cómo es compatible con versiones anteriores a Windows 8 inclusive (modo escritorio por supuesto).

El punto es que el software puede ofrecer características que han estado en Windows desde hace más de 15 años. Ahora, al añadir características dinámicas a dicho software que pueden cambiar dependiendo de la versión de Windows que se ejecute en el hardware y lo hará, entonces realmente tienes una herramienta poderosa para el desarrollo de software. No hay necesidad de preocuparse por la versión de .NET que esté en el equipo. No hay necesidad de preocuparse por la versión de DirectX que esté en un equipo. No hay necesidad de preocuparse por el tamaño de la pantalla o si se basa en dispositivos táctiles o no (cambia dinámicamente la interfaz de usuario en función de qué tipo de dispositivo está ejecutándose).

Imagínate software, que cuando se ejecute en una computadora de escritorio lo sabe y aprovecha al máximo todo el espacio disponible de la pantalla para los elementos de la interfaz de usuario? Sin embargo, cuando se ejecute en un dispositivo más pequeño, como una netbook, de forma dinámica cambie para utilizar mejor el espacio limitado de la pantalla. Y aún más, cuando se ejecute en un dispositivo táctil (es decir, tablets), cambia el diseño de usuario por completo para compensar la necesidad de elementos de interfaz de usuario más grandes para el tacto. La construcción de software dinámico es lo que se necesita ahora. En lugar de quejarse cómo el software funciona bien en una tablet, pero desperdicia espacio y funciona mal en un escritorio, ¿por qué no podemos tener las dos cosas? ¿Por qué no puede ser el software dinámico?

Otro problema con tratar de escribir software dinámico es que diferentes ordenadores pueden tener diferencias en el rendimiento. Un humilde CPU ATOM en una tableta de Windows no va a rendir lo mismo que si se ejecuta el software en una computadora de escritorio con la última CPU. La clave aquí es escribir software para el denominador más bajo, la CPU ATOM. Esto requiere software más pequeño, más rápido. La mejor manera de hacer esto es escribir software usando un compilador de código nativo que produzca ejecutables pequeños y software rápido.

El objetivo es escribir software que se pueda ejecutar en un equipo legado de 10 años con hardware mínimo. El software puede ser escrito para que alcance en un disquete pasado de moda y también sea verdaderamente transportable (lo que significa que puede copiar y ejecutar). El software debe ser transportable hoy. Debe ser capaz de ser simplemente copiados a una unidad y pasar de un equipo a otro o incluso ejecutarse directamente desde una unidad en cualquier ordenador. Esto requiere de software con una huella mínima y ninguna pesada dependencia del sistema.

Mediante el uso de un compilador de código nativo y la API de Win32 para construir software dinámico, los programadores pueden construir mejor software que puede aprovechar cualquier ordenador con Windows.

La verdadera pregunta es si, ¿puede esto realmente hacerse? La respuesta es definitivamente sí. ¿Pero lo haremos como desarrolladores de software?

0 comentarios: