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):
Fuente: blog.delphiedintorni.it
No hay comentarios:
Publicar un comentario