Cita:
Empezado por mamcx
El problema donald, es que separara la vista del codigo es, primeramente, la opcion correcta, y segundo, es practicamente inevitable cuando hay dos plataformas con 2 UI toolkits que son diferentes y que se comportan diferentes y tienen tamaños diferentes y formas de interactuar diferentes y flujos diferentes... y asi por el estilo.
Asi que lo que pasa es que uno se ciñe al "estilo" de un toolkit alienigena (ej: firemonkey) e intenta seguir esa linea (lo cual se rompe cuando integras cosas del OS o de terceros) con los problemas intrinsecos que presentan, o hace 2 interfaces y la app se ve y comporta correctamente.
El problema es que eso no es un problema cuando se hace un demo rápido, con controles "normales", sino que se siente el golpe una vez empieza el trabajo en serio.
|
Consulta, has probado XE5?
Yo creo que , por lo que comentan, pocos de aquí lo han hecho...
Justamente, en XE5 vos diseñas tu aplicación para iOS y tienes el look and feel de iOS, luego cambias un COMBOBOX
, rebuild y ya tienes el look and feel de Android.... Así de sencillo. Quien puede superar eso? Obviamente si hay alguna llamada a la API de iOS tendrás que poner un condicional para acceder a la api de android. Pero seguramente el día de mañana crearan componentes de alto nivel que encapsulen dicha decisión.
Como puede ser esto una desventaja? Si entiendo que puedan mencionar que el comportamiento se vuelva mas lento, aunque la verdad en la aplicación que he probado de mediana complejidad no lo he notado para nada, y eso que es beta, pero mencionar esto como una desventaja ...
Yo creo que es una ventaja, y si siguen mejorando el tema de dibujo y performance puede ser imbatible.
Por otro lado, como dije siempre, esta herramienta es para ayudar al mundo delphi a desarrollar aplicaciones para mobiles. Si tu aplicación requiere una excelente performance (casi todas las que he visto que así sea son juegos) tendrás que trabajar con xcode.
Para aplicaciones de oficina, delphi cumple la meta 100%.