TFrameStand: FireMonkey TFrame a la enésima potencia

Este post está dedicado a TFrameStand: un componente FireMonkey que he desarrollado en los últimos meses (en mi tiempo libre). En primer lugar, cómo obtenerlo: el componente (y demostraciones) están disponibles en GitHub, y se pueden utilizar libremente. En el último número (45-46) de Blaise Pascal  encontrará mi artículo que explica los fundamentos y muestra de las demos incluidas actualmente en el repositorio. Nota: gran  parte del código ha sido desarrollado con XE8, últimamente estoy usando la versión 10 Seattle (por lo que no se ha probado en las versiones anteriores, aunque también debe ser compatible con XE7).



Introducción

Especialmente durante el desarrollo de aplicaciones móviles, muchos desarrolladores simplemente añaden una gran cantidad de controles al formulario principal del proyecto (que a menudo es el único form disponible). Esto conduce rápidamente a problemas de mantenimiento del proyecto, porque este enfoque no fomenta la reutilización de componentes.
El concepto de TFrame se introdujo hace mucho tiempo (incluso en el VCL) para dar al 
desarrollador la capacidad de unir algunos elementos de la interfaz de usuario (componentes) y su comportamiento (código) en una sola unidad, reutilizable. Esto es bueno porque se puede dividir su uso en porciones que se pueden diseñar de forma individual y posiblemente re-utilizarlas en otras aplicaciones!. Simplemente poniendo una instancia de un 
TFrame en un objeto contenedor (puede ser un form, una página de un TTabControl o
 cualquier otro componente visual ... FMX).
Un ejemplo típico en el que un acercamiento a TFrame puede simplificar mucho es cuando se puede dividir su aplicación móvil en un conjunto de "vistas" para mostrar al usuario en base a la situación de la solicitud. A continuación, puede implementar las funciones de aplicación de forma independiente, mostrando esto o aquello "vista" (TFrame) dependiendo del estado de la propia aplicación (como lo haría con un TTabControl, usando una 
página diferente para cada "punto de vista").

Estos "pie" se definen mediante una características de FireMonkey muy básica: 
los estilos!
Cada componente tiene una propiedad TFrameStand un manual de estilo, una referencia que puede ser utilizada para definir la colección de soporte disponible. Junto con unas simples convenciones de nomenclatura serán la base del funcionamiento del componente
 (por ejemplo, para definir el punto exacto donde usted quiere que su TFrame está incrustado en el stand se debe dar un nombre específico "contenedor" para el componente visual que debe actuar como matriz de TFrame).

TFrameStand que nace en este contexto le permite ir un poco más allá, ya que le da la oportunidad de tener un nivel intermedio entre el TFrame y el objeto contenedor. Esta capa intermedia (el"pie", de ahora en adelante) puede ser visto como la parte visual (UI) que no está estrictamente vinculada a los efectos del TFrame que está mostrando, sino más bien está ligado a la forma en que la TFrame se presenta al usuario.






Stand and TFrames


Uno de los aspectos clave de TFrameStand es lo que le permite volver a utilizar un stand con diferentes clases TFrame descendientes y también para hacer lo contrario, es decir, para mostrar la misma clase TFrame utilizando diferentes stands. En ambos casos, esto permite obtener un buen nivel de   coherencia visual en su aplicación (y / o entre diferentes aplicaciones), en beneficio de la experiencia  del usuario.


Mismo stand, varios TFrame


Por ejemplo, imagine que tiene un stand que implementa un "camino" para mostrar un TFrame, por ejemplo, con un efecto LightBox: a continuación, será capaz de mostrar diferentes contenidos (TFrame diferentes instancias) utilizando el mismo efecto visual (utilizando una "caja de luz "). Las ventajas son evidentes, por ejemplo, es necesario aplicar el efecto visual (stand / soporte) una sola vez y luego se puede volver a utilizar y, al hacerlo, cualquier cambio (mejora) en el stand afectará a todas las partes de laaplicación que lo utiliza (consistencia!).


TFrame iguales, diferentes stands


Imagine que tiene una serie de soportes que ayudan al usuario a reconocer el  contexto. Por ejemplo, usted puede tener un soporte que indica claramente que el contenido está relacionado con una notificación de error, otro soporte para situaciones de atención (advertencia) y otra acción del usuario cuando se requiere (confirmaciones, opciones , y así sucesivamente). Si, por ejemplo, usted tiene una TFrame específico para llevar a cabo ciertas tareas y tiene que mostrar los resultados al usuario, es posible que desee que se muestre al usuario el uso de diferentes significados (número de stand!).


Tenga en cuenta que, puesto una vez implementado para todas las opciones, puede  usarlos con cualquier TFrame  y se puede elegir de vez en cuando, que opción usar.

En una aplicación real, muchas situaciones caen en estas dos categorías.

Funcionalidad

Hasta ahora, hemos hablado de algunas de las ventajas de este enfoque, que son: descomponer la complejidad de una aplicación utilizando el TFrame y el uso de los componentes TFrameStand que descomponen de alguna manera la forma en que  se muestra el TFrame con respecto al contenido específico.

Hay algunos otros beneficios al utilizar TFrameStand, aquí hay una lista de los
principales:

1.  Puede trabajar en tiempo de diseño ya  que es el TFrame que el soporte;

2.  Hay un soporte integrado para la realización de una tarea en segundo plano (utilizando la biblioteca de programación en paralelo internamente) y al mismo tiempo mostrar una interfaz gráfica adecuada (stand + TFrame) al usuario; Una vez finalizada la operación, esta "forma de espera" se puede ocultar fácilmente (con un poco de programación asincrónica muy simplificada);

3.     TFrameStand es capaz de iniciar automáticamente
4.       un poco de animación (objetos TAnimation y descendientes) que      consten en la definición de base o en la instancia TFrame; Se admiten      actualmente dos eventos: OnShow y OnHide (esto significa que se puede      utilizar transiciones animadas en el proceso para mostrar y ocultar las      acciones fácilmente y sin tener que escribir código);

5.  Hay un (simple) mecanismo de inyección de dependencia que permite obtener fácilmente una referencia a objetos en su contexto, incluso en el código de la aplicación específica para cada TFrame para mostrar.


6.  No es una forma de representar comportamientos compartidos (piezas de código compartido) a través de diferentes combinaciones de soporte / TFrame.

7.  Hay una manera (altamente personalizable) para reemplazar la clase TFrame utilizada en tiempo de ejecución; Esto significa que usted puede desarrollar una clase considerando TFrame  "padre" y luego tener que ejecutar una instancia de una clase descendiente, seleccionando sobre la base de un algoritmo completamente personalizable (por ejemplo, puede decidir utilizar clases descendientes que difieren dependiendo de la Plataforma  de ejecución);
Estos

son los videos con la demo en funcionamiento (en Win32):





No hay comentarios:

Publicar un comentario