Testeando XE2 (aplicación FireMonkey…)
Hace unas semanas comencé a “trastear» con XE2, con FireMonkey, con los liveBindings, estilos y algunas características más… Estuve posteando aquí las primeras impresiones y los resultados de esas primeras pruebas.
En esas entradas he realizado un primer acercamiento a estas tecnologías, he dado un repaso y he testeado por encima algunas de sus características. La idea ahora, es ir un poco más allá.
He leído en algunos foros opiniones sobre que FireMonkey está «a medias» o «incompleto». Respeto esas opiniones, pero personalmente no estoy de acuerdo. Creo (y aquí es donde puede estar el error ) que se compara a FireMonkey con la VCL y las características que posee esta. Desde ese punto de vista sí puede parecer que «le faltan cosas» y eso puede dar una sensación de que es una tecnología inacabada.
Pienso que el objetivo final de FireMokey no es, llegar a conseguir todas las características con las que cuenta la VCL. Es algo totalmente nuevo que avanza en una dirección paralela, algunas cosas tendrá sentido «adoptarlas» y otras no, pero a mi entender eso es «añadir» no «completar».
Hace tiempo publiqué en el blog un pequeño ejemplo de cómo cargar ficheros GPX (alternativa generando KML) procedentes de dispositivos GPS y visualizar esos tracks o rutas en una Aplicación Delphi. Me he decidido por intentar realizar esta pequeña aplicación utilizando FireMonkey.
TActionList, ¿dónde está?
Lo primero que me he encontrado, aunque en realidad ya lo había visto en las primeras pruebas, es que no puedo utilizar un TActionList. Este componente no está en la paleta donde debería estar o donde uno esperaría encontrarlo. Una cosa que sorprende es que los componentes estandard de FireMonkey sí poseen la propiedad Action para poder asignar un elemento. No es que sea imprescindible, pero es muy cómodo.
Lo siguiente que me planteo es la importación de datos desde un fichero GPX. En su día la hice utilizando el XMLmapper, pues los ficheros GPX son en realidad ficheros XML. Me propongo utilizar el mismo modelo utilizado anteriormente; Importar el fichero GPX a un TClientDataset para getionarlo después de forma local.
TXMLTransformProvider, ¿dónde está?
Al igual que me ha pasado anteriormente, coloco un TClientDataset y cuando voy a colocar el TXMLTransformProvider no está donde esperaba encontrarlo.
He realizado un par de pruebas y lo más curioso es que creando y configurando el componente «a mano» funciona perfectamente. Con un código como este y configurando los campos apropiados en diseño el componente funciona perfectamente, importa los datos e incluso se pueden configurar LiveBindings para mostrar el resultado en un Grid.
XMLTransform := TXMLTransformProvider.Create(nil); XMLTransform.TransformRead.TransformationFile := 'd:\Ficheros GPX\GPX_To_DP.xtr'; XMLTransform.XMLDataFile := 'd:\Ficheros GPX\Ruta3.gpx'; ClientDataSet1.SetProvider(XMLTransform); ClientDataSet1.Active := True; |
Una vez activado el componente la importación se realiza sin problemas.
He dejado de lado esta cuestión por ahora; Tal vez más adelante me detenga para probar más cosas, pero para seguir adelante he realizado la importación de datos «manualmente», de forma que una vez conseguidos los datos en el TClientDataSet y puedo continuar a tratarlos.
El siguiente paso es colocar los elementos en el formulario, tal como van a ir distribuidos. Una cosa a la que hay que acostumbrarse es que los componentes de FireMonkey no poseen la propiedad
Anchors, que tan útil nos es utilizando componentes de la VCL. A cambio podemos ver que la propiedad Align posee una cantidad de valores superior que nos permite realizar más cosas. En este caso utilizamos la propiedad Align y la propiedad Padding para ir fijando los controles al formulario tal y como deseamos.
Se trata de conseguir lo mismo, pero por un camino diferente…
Una vez que los componentes básicos ya están colocados necesito plasmar en pantalla una serie de coordenadas. Para ello he escogido el componente TPath. La idea es que permite representar una serie de puntos que forman una línea o camino.
La potencia y la velocidad llaman la atención, pero también la sencillez.
Basta con soltar el componente en pantalla y utilizando la propiedad Data, colocar lo siguiente para conseguir una imagen (o path) como el que veis más abajo (se puede hacer en diseño utilizando un pequeño formulario de edición):
M 0,2 L 1,2 L 1,5 L 2,5 L 2,2 L 3,2 L 1.5 0 L 0,2
Si lo pensáis un poco, no son más que coordenadas precedidas por el tipo de «unión» o «elemento» que queremos utilizar entre ellas; la Primera M se refiere a MOVER, las L se refieren a LINEA.
Es así de sencillo y así de potente.
Un código como este, os podéis imaginar lo que dará como resultado:
for I := -360 to 360 do begin n := DegToRad(i); res := Sin(n); //res := Sin(n) * Sin(n); //res := Tan(n); if (Str = '') then begin Str := 'M ' + FloatToStrF(n, ffFixed, 35, 10) + ' ' + FloatToStrF(res, ffFixed, 35, 10); end else begin Str := Str + ',' + 'L ' + FloatToStrF(n, ffFixed, 35, 10) + ' ' + FloatToStrF(res, ffFixed, 35, 10); end; end; Path1.Data.Data := Str; |
Con esto más o menos ya está todo completo. Los componente básicos ya están escogidos.
He utilizado LiveBindings para poder mostrar los datos en de las coordenadas en un TStringGrid; También he aplicado un estilo visual a la aplicación y por último una par de animaciones para dar más vistosidad a la visualización del track.
La conclusión que saco, es que sí se pueden hacer aplicaciones con FireMonkey, lo que pasa que tal vez en algunos aspectos debamos pensar las cosas con otro enfoque o hacerlas de otra manera. Seguramente está en los planes de Embarcadero (eso espero) ampliar sus funcionalidades y el número de componentes.
Por último comentar que me he quedado con la ganas de poder compilar la aplicación y generarla para iOS, pero por ahora, no dispongo de los medios para hacerlo. Sobre todo me queda la duda de qué hubiera pasado con una aplicación, de un programador como yo con «visión de Windows», al compilarla en MAC.
¿Algun error? ¿Algun problema? ¿Warinigs? ¿Algun elemento que no puedo utilizar? ¿?¿?¿?
Si alguien se anima a hacerlo, le agradecería que nos comunicara el resultado y me enviara alguna pantallita. ;-)
Os dejo los enlaces al código fuente y al ejecutable (este último comprimido con UPX) junto con algunos ficheros GPX que podéis usar para las pruebas.
[wpfilebase tag=file id=1 /]
[wpfilebase tag=file id=2 /]
NOTA: Acabo de corregir un par de errores en el código y añadida la DLL (midas.dll) porque quien no la tenga no podrá ejecutar la demo (gracias Rafa).
Como siempre los comentarios, sugerencias, críticas y demás son bienvenidos.
Un saludo y hasta la próxima.
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Gracias por el artículo. Sí que promete FireMonkey, sí. Lamento no poder ayudare con lo de iOS Germán.
@David
Hola David.
Gracias.
No hay problema. Me hacía gracia probarlo por saber el resultado y qué podría pasar.
Un saludo.
Claro, si está muy bien. Así a simple vista parecería que, no utilizando el API de Windows, ni accediendo al sistema «como si fuese Windows», no debería haber ningún problema, ¿verdad?
Sin embargo, tú mismo has encontrado «cosas escondidas», de manera que no estaría nada mal poberlo probar para ver si realmente todo va como se espera. Una lástima no tener un iMac (¿se dice así?).
Que tal Neftalí, como siempre un artículo muy bueno e interesante, en lo único en lo que si discrepo es sobre la madures de firemonkey, porque sí que dijiste completamente la verdad con respecto a que hay que pensar de una manera mucho más diferente con esta plataforma, dios los estilos son (en mi opinión la piedra angular de firemonkey), tienen un gran potencial, y la nueva forma en que se maquetan las interfaces sumado al número de animaciones y formas que se pueden hacer con gran facilidad, pues no me deja más que decir, es justo lo que necesitaba, ya que no solo hace una aplicación más bonita, sino también más usable. Sin embargo, yo si considero que firemonkey está aún inmaduro y/o incompleto, no porque no se pueda hacer todo de forma similar a la VCL, sino porque tiene errores de funcionamiento (hasta ahora solo he encontrado un par, con el memo y la forma en que se pintan los formularios cuando se elige que sean transparentes), errores que sí que limitan un poco la creatividad, yo sí que espero que la siguiente versión del compilador, nos deje con una plataforma que bien sino esta completamente madura, que al menos no tenga errorcillos escondidos por ahí. Lamento no poder subir ningún ejemplillo de lo que he probado (lo que pasa es que los componentes que uso para mis pruebas están protegidos), pero qué más da si subo un par de ejecutables simples y ya compilados (a ver qué tal les parece).
1 Sirve para limpiar las carpetas de los proyectos y generar un rar con la clave “[1EstaEsMiClave121]”
Y 2 es un simple programa que da información de colores (por cierto el gotero no sirve en xp).
http://www.megaupload.com/?d=DKI2P1XJ
Hola Aion, gracias por el comentario.
Cierto que FireMonkey tiene algunos bugs, ¿pero qué paquete no los tienes? ;-)
Yo he programado en OGRE (mac, windows, linux, Open Source, gratuito, soportando OpenGL y DirectX) y puedo decir que FireMonkey no es ni 3D ni ná… y para Widgets hay muchos sabores Open source ahí fuera.
FireMonkey es un intento, nada más. Lo simple lo hace simple, lo complicado imposible, esperemos que mejore como los buenos vinos, pero hoy por hoy solo sirve para demos cutres (perdona por mi sinceridad), pero en la entrevista con un creador de FireMonkey lo dice él mismo, «es la versión 1.0 y se nota.»
hola me parece muy buenas tus observaciones, solamente ampliando un poquito he observado que un simple formulario FMX sin componentes tal y como lo ejecuto al abrir un nuevo proyecto FMX cuando lo corro y observo el tamaño en memoria del administrador de tareas observo unos sorprendentes 24 MB! con debug o sin el.
comparado a VCL que me roba 1 MB….
reconosco que de momento me entristecio por que segui el ejercicio de Francisco Charte de su guia de delphi y al termino del ejercicio del capitulo 2 (por cierto muy bueno el libro) termine por los 60 Mb y 70 Mb…
digo me entristeció pero reconozco que la apuesta es muy positiva por parte de embarcadero en esta nueva visión…. tal vez FMX este un poco Verde todavia pero esperare una etapa de maduración en una segunda o tercera version de firemonkey para ver como se comporta este tema… espero que existan mejoras y una mejor administracion de memoria…. de momento continuo con la VCL..
te mando un saludo desde mexico y como algunos por acá seguimos testeando el FMX…
Hola Alex.
Ante todo gracias por los comentarios.
Es cierto que los proyectos FMX «agrandan» el EXE en comparación con la VCL, aun así 24 MB me parece demasiado. He comprobado con una aplicación de ejemplo que tengo (para la próxima entrada) y con la información me ocupa 16MB, al extraerla, se queda en 5 MB, que aun siendo más que algo similar de la VCL ya me parece más correcto.
Tal vez estás dejando alguna opción sin desmarcar.
Hay que revisar también los recursos que se añaden a los formularios, los temas y/o estilos,… ya que eso agranda el tamaños de los formularios.
Dicho todo esto, coincido contigo en que FMX puede y debe mejorar; Es una gran apuesta y creo que es un gran producto. Embarcadero está trabajando en él y me consta que para próximas versiones viene ampliado y mejorado.
Un saludo.
estaré probando lo que me comentas y posteriormente posteando… bueno ya pronto se viene el XE3, ya como ansias al respecto : -)…. tarde un poco en responder , creo , me acorde que en algún rinconcito escribí algo y lo encontré… un saludo y buena suerte.