¿Por qué un botón no es simplemente un botón?

A continuación encontrarás traducida al español el artículo publicado originalmente en el blog de Xojo y escrito por Geoff Perlman, Fundador y CEO de Xojo.

Nuestra visión de Xojo siempre ha sido la de permitir que cualquier persona pueda crear aplicaciones, con independencia de sus habilidades de programación. La principal forma de lograrlo es mantener lo más similar posible el proceso de crear apps para Desktop, Web y Mobile.

Si utilizas Xojo para crear proyectos para más que sólo una de estas plataformas, entonces probablemente habrás observado que los controles son muy similares entre los diferentes tipos de proyecto. Un botón funciona del mismo modo en una app Web a cómo lo hace en Desktop o en una app Mobile. Si bien existen algunas diferencias, los controles comparten la mayoría de sus eventos, propiedades y métodos. Dicho esto, quizá te estés preguntando por qué un botón no es un botón. Hay razones tanto desde la perspectiva técnica como histórica de por qué Xojo tiene clases DesktopButton (el nuevo reemplazo para PushButton), WebButton y MobileButton.

Cuando Xojo se desarrolló inicialmente a mediados de 1990, pensábamos en multiplataforma sólo desde la perspectiva del escritorio. Si bien comenzamos con Mac, también habíamos previsto el soporte de Windows y, en algún momento, de Linux. Por aquél entonces era ilógico tener un MacButton, WindowsButton y LinuxButton, dado que queríamos que eligieses el sistema operativo que quisieras soportar y simplemente pulsases Build. Pero en aquél entonces no estábamos considerando Web, y mucho menos las apps Mobile. Por tanto, el framework subyacente y el IDE de Xojo se diseñaron dando por hecho de que las clases de control serían sólo para Desktop.

En 2011 introdujimos la capacidad de crear apps para la Web. En aquél momento podríamos haber añadido simplemente la funcionalidad Web a las clases control de Desktop ya existentes. Diseñar y crear el framework Web fue de hecho una tarea tremenda que se habría convertido en un esfuerzo aún mayor si hubiésemos decidido diseñarla en torno al conjunto existente de clases para Desktop. Esto también habría requerido de la realización de cambios masivos en el IDE de Xojo, dado que también asumía que todos los controles eran controles desktop. Fijo que habríamos logrado algunos beneficios por aquél entonces de haberlo hecho así. Ocasionalmente, cuando tienes que escribir código que ha de funcionar con algo específico de una clase de control concreta, como es el MacButtonStyle de PushButton, lo haces referenciando el nombre de la clase del control. También tienes que tomarlo en cuenta cuando escribes código que pasa los controles como parámetros de forma genérica y luego utilizas el casting para convertirlo de nuevo al tipo de control específico. Este último caso es el que se da sobretodo para usuarios muy avanzados y, afortunadamente, pueden escribir el código en una forma que sea útil para otros usuarios abstrayendo todos los detalles de cómo está hecho. Afortunadamente muchos de vosotros no trabajáis directamente con las clases de los controles. En vez de ello escribís el código que funciona con las instancias de los controles (Button1, TextField2, etc.) utilizando para ello los nombres de los controles en vez del nombre de las clases.

Seguimos con este mismo diseño cuando añadimos soporte para iOS y luego al framework Mobile. Los controles proporcionaban una API tan similar como podíamos al tiempo que eran clases separadas. Los controles Web cuentan con el prefijo Web. Los controles Mobile tienen el prefijo Mobile. Hemos diseñado el framework Mobile de modo que su API pueda compartirse tanto por las apps iOS como en Android.

Hablemos ahora de los motivos técnicos. ¿Podíamos cambiarlo? ¿Podíamos combinarlos todos (Desktop, Web y Mobile) en un único conjunto de clases de controles? Después de todo, ya lo hicimos con las clases no relacionadas con la interface de usuario. Desktop comparte las mismas clases en todos los sistemas operativos, tal y como es el caso de Web y de Mobile. Sí, ciertamente podríamos haberlo hecho. Sin embargo, eso habría sido un proyecto tremendo que probablemente habría durado dos años o más. La ventaja habría sido que el usuario pudiese utilizar siempre el mismo nombre de clase (Button en vez de PushButton, WebButton y MobileButton, por ejemplo) en las raras ocasiones en las que tuviese que escribir código para un mismo nombre de control. Dado que no es muy frecuente y que los usuarios que necesitan escribir código como este se sienten muy cómodos con su comprensión de que los nombres de clase son diferentes para cada tipo de proyecto, no nos parecía que mereciese la pena el esfuerzo y el tiempo necesario para combinarlos.

Dicho esto, si te sientes en la necesidad de crear clases que interactúan con controles y has de soportar múltiples tipos de proyecto, entonces por supuesto que puedes hacerlo. Xojo te proporciona todo lo que necesitas.

La única parte de las clases de control que no se había compartido en el pasado era el esquema correspondiente a los nombres de los eventos. Si bien las clases de control de Web y Mobile tenían eventos comunes, no era así en el caso de los controles de escritorio. Hemos rectificado esto en Xojo 2021r3, ya disponible, con un nuevo conjunto de controles Desktop. Estos controles son prácticamente idénticos a los controles Desktop originales que has estado utilizando. Una gran diferencia es que ahora tienen nombres de eventos que se corresponden con los equivalentes en Web o Mobile. Esto proporciona la mejor experiencia de usuario dado que un usuario que está aprendiendo a utilizar Xojo para crear aplicaciones para un tipo de proyecto puede utilizar prácticamente todo o parte de su experiencia en la creación de aplicaciones para otra plataforma diferente. Por consistencia y para evitar conflictos con los controles originales, los nuevos controles cuentan con el prefijo Desktop.

A lo largo de la dilatada historia de Xojo te hemos abstraído de los frecuentes cambios ocurridos en los ordenadores; desde el procesador Motorola 68000 al PowerPC, a Intel y a ARM; desde MacOS Classic a MacOS X; desde Windows 6 a Windows 10; de 32 a 64 bits, y más. Siempre ha sido nuestro objetivo que estos cambios tengan el menor impacto posible en ti. Cuando desarrollamos el Web Framework 2.0, ese continuó siendo nuestro objetivo. Sin embargo, las tecnologías web subyacentes han cambiado sobremanera en una década, haciendo que no fuese práctico combinar los frameworks 1.0 y 2.0 en un mismo proyecto. Eso ha resultado en que la transición de algunos proyectos haya supuesto un reto, y por lo que recomendábamos que hicieses la transición en proyectos existentes sólo si era necesario.

Ese no fue el caso con nuestra transición desde iOS al framework Mobile. Ambos pueden utilizarse en el mismo proyecto. Este será el caso con nuestros nuevos controles Desktop también. Podrás utilizar ambos conjuntos de controles en el mismo proyecto e incluso en la misma ventana o container. Los controles también pueden interactuar entre ellos. También proporcionaremos una herramienta simple que puedas usar para convertir con un clic un control, una ventana o todo el proyecto desde los controles Desktop clásicos a los nuevos controles Desktop. La capacidad de autocompletado continuará funcionando como siempre con los controles antiguos y también continuarán apareciendo en la Referencia del Lenguaje (aunque se marcarán como deprecados). Los controles viejos y nuevos comparten la mayor parte de la implementación subyacente. Existen algunos pequeños cambios de comportamiento aquí y allá, pero de forma genérica continuarán funcionando tal y como venías esperando de los controles que ya utilizabas. Las principales ventajas de los nuevos controles son que sus eventos coinciden con los de los otros tipos de proyecto, y que hemos podido hacer algunos pequeños cambios de comportamiento en la API sin que se vean afectados los proyectos actuales. Puedes leer más sobre este particular en la entrada Nuevos Controles Desktop.

A medida que avanzamos, continuaremos implementando nuestra visión de hacer que Xojo sea la forma más rápida y sencilla de crear aplicaciones para las plataformas que deseas. Si algo de lo escrito te despierta alguna duda, te animamos a que contactes con nostros.