FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Yo siento discrepar con la opinión general, pero personalmente creo que la dirección "multiplataforma" que ha adoptado Embarcadero no es la más apropiada y me explico:
-Firemonkey usa un dibujado gráfico de cada control en la aplicación. Esto hace que su lentitud sea extrema. A la que haces un proyecto medianamente complejo y en vez de usar el simulador de iPhone (con 320 puntos de resolución) usas el iPad .... verás que los desarrollos de Firemonkey van a pedales. Tal vez para una aplicación de cambio de divisas estas cosas no importen, pero siendo honestos, raramente vamos a necesitar desarrollar una aplicación tan "básica". A la que pones varios controles, varias páginas, y algunos listados como por ejemplo, una lista de países, la animación de paso entre páginas de una tabla con la animación slide demora a veces hasta 3 segundos. Se pierde todo el "feeling" de iOS. Para mi, el rendimiento de una aplicación es, junto con su estabilidad, lo más importante de un desarrollo, y a día de hoy, eso no lo puedo obtener con Firemonkey. (Y tengo miedo de qué características técnicas vamos a necesitar para mover decentemente una aplicación Firemonkey en Android.... ¿un S4?) Esto no es lo peor... en cuanto aparece una nueva versión del sistema operativo (como será iOS7), hay que cambiar los styles para que se actualicen al nuevo look... ¿hay entonces que pasar por caja otra vez? Embarcadero debería haber optado por usar los controles nativos de las plataformas pero usando propiedades comunes. Es decir, que los componentes tuviesen las mismas propiedades como el "Label" de un botón y que según la plataforma donde ejecutásemos la aplicación internamente el compilador ya usase las rutinas nativas correspondientes de cada dispositivo, pero siempre usando los componentes nativos. En menos de tres meses, una persona ha migrado casi todos los componentes nativos de iOS a Delphi XE4 (Los componentes de código abierto DPF iOS Native Controls).... que funcionan exactamente con el rendimiento de aplicaciones desarrolladas en X-Code y con su mismo aspecto. Y lo que es mejor, si los pruebas en un dispositivo con iOS7, adquieren el aspecto de los controles de iOS7 automáticamente. Me niego a creer que el equipo de ingenieros de Embarcadero no pueda lograr esto llevándolo un "pasito" más allá y encapsulando las propiedades de los controles nativos en otras genéricas que llamen a los componentes correspondientes de cada plataforma... Windows, iOS, Android o OSX. |
#2
|
||||
|
||||
Respecto a que Android trabaja sobre JAVA y no en forma nativa en sus aplicaciones, esto no es tan cierto. Además, estoy leyendo este titular Sneak Peek: Android SDK, NDK and Device Support in Delphi - See more at: http://delphi.org/2013/08/sneak-peak...port-in-delphi
Y Sneak Peek: Delphi, Android, ARM Assembler and Extra Awesomeness http://www.malcolmgroves.com/blog/?p=1427 |
#3
|
|||
|
|||
Cita:
Bueno, bueno, pero tampoco iba a publicar un ERP a modo de ejemplo Pero más allá, la serie de artículos es para comprobar que se pueden desarrollar aplicaciones con el mismo código base y los mismos componentes, además de que iOS, OSX, y en un futuro Android...., son complementos a un sistema hecho en y para Windows. Si pretendes adquirir Delphi para desarrollar únicamente para iOS - OSX, pues estás apuntando al lado equivocado, para eso hay herramientas esclusivas. Yo creo que ni todo es negro ni todo es blanco, sus limitaciones debe tener no "correr" en la plataforma donde se está generando el código. ¿Ahora si me explico? Saludos
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#4
|
||||
|
||||
Cita:
El problema es que es mas probable que sea por debajo de lo promedio, y que el resultado final termine requiriendo mas hacks que haber ido desde el principio al API de UI nativo. O al menos, si se intenta hacer una app que se haga dandole importancia a la experiencia de usuario. Aunque evidentemente, tener la lógica de negocios en un solo entorno es muy beneficioso.
__________________
El malabarista. |
#5
|
||||
|
||||
Cita:
Cita:
__________________
Conoce mi blog http://www.edgartec.com |
#6
|
|||
|
|||
Cita:
Cita:
De esa forma, seguiríamos teniendo un único código, y el compilador internamente se encargaría de usar las APIs de cada plataforma de forma automática y aprovechando el rendimiento al 100% de los controles nativos. Cita:
Aquí tienes el enlace: DPF Native iOS Components En los componentes vienen un montón con un montón de código fuente para ir "empezando". Además, en algunos aspectos incluso mejoran a los componentes originales con opciones y procedimientos que en x-code hay que escribirlos "a manita" (como por ejemplo, customizar el color de una toolbar o la fuente de la misma y cientos de cosas así) Un saludo Última edición por DarkDudae fecha: 20-08-2013 a las 22:42:26. |
#7
|
||||
|
||||
Cita:
|
#8
|
||||
|
||||
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.
__________________
El malabarista. |
#9
|
||||
|
||||
Cita:
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%. |
#10
|
||||
|
||||
XE5 no. Asi que pregunto: Si se corre una app con firemonkey en iOS 7, se ven los nuevos estilos, o los de firemonkey?
Si es asi, es el problema. Que "parezca" nativo no es igual a que sea.
__________________
El malabarista. |
#11
|
|||
|
|||
Cita:
A mi modo de ver la cosa no es tan compleja: Creo unos componentes "firechicken" (en vez de firemonkey). En Designtime, esos componentes adoptarían el aspecto de los componentes nativos que tenga seleccionado en ese momento en el compilador con un simple combobox (algo parecido a como vemos ahora en los videos del sneak peak de Embarcadero para Android). Es decir, si tengo seleccionada plataforma Android, adoptarían el aspecto de los controles de Android, y si tengo seleccionada la plataforma iOS, adoptarían el aspecto de la plataforma iOS. (Sin necesidad de crear un form para cada plataforma) Los componentes "firechicken" tendrían todos las mismas propiedades en cualquier plataforma (o prácticamente las mismas). A la hora de dibujar los componentes en pantalla, lo harían usando la API de los controles nativos de la plataforma para la que compilemos (Esto se puede conseguir fácilmente usando varios IFDEFs). A la hora de por ejemplo, programar el evento OnClick de un botón de firechicken, este haría la llamada a la API nativa del componente correspondiente, y si dicho evento no existe en el control nativo, pues se programa. Si firemonkey estuviese diseñado de esta forma, tendríamos prácticamente un único código, con un único formulario y con el rendimiento de los componentes nativos. De hecho, esto ahora mismo ya se podría conseguir, pero se tendría que hacer mucho trabajo de forma manual. Yo ahora mismo, podría hacer una unit que al ser introducida en el uses de un form firemonkey, en vez de dibujar los controles de firemonkey dibujasen controles nativos de la plataforma seleccionada. Pero claro, tendría que redirigir cada evento y cada propiedad de cada control y crear/adaptar los que no existan. Demasiado trabajo para una persona pero no para el equipo de ingenieros que probablemente tendrá Embarcadero. No sé si me he explicado.... |
#12
|
||||
|
||||
Cita:
Cita:
De nuevo, error de concepto, asi esta diseñado. De lo que vos te quejas es de que el dibujo no sea nativo, porque el resto asi funciona |
#13
|
|||
|
|||
Cita:
Y a día de hoy, y hablando de XE4, para aplicaciones de "oficina" sigo sin ver a Firemonkey como una alternativa viable. Y te voy a poner un pequeño ejemplo: Usa un tableview con dos tabs que pasen entre ellas mediante una típica animación de iOS como es el tslide. En la primera tab, pon por ejemplo, un botón de "Seleccione su país", que al ser pulsado, con la animación tslide pase al segundo tab que contendrá un TableView con un listado de países. Usa en el simulador de iPad o en un dispositivo real que no sea un iPhone 3GS o 3G (que son los que tienen menor resolución). Ahora pulsa el botón y verás que la animación va a trompicones, y que al deslizarte por el listado de países petardea que da gusto. Puedo entender que para algunos esto sea tolerable, para mí.... no. (Y no hablemos ya de rellenar listas en runtime....) Vamos, es que si queréis os puedo poner un par de demos usando controles de firemonkey y luego los nativos y veréis que no son ilusiones mías... es como cambiar de un 600 a un BMW M5... Por otro lado, no es ese el único problema... ¿habéis intentado ejecutar una aplicación de firemonkey de XE4 en iOS 7 ? Aparte de que pasa una cosa bastante extraña, y es que tienes que pulsar ligeramente sobre el control para que este responda, el aspecto adoptado de la aplicación es el de iOS6. Si usas componentes nativos el aspecto que adopta es el de la versión de iOS que el dispositivo usa. ¿Tendremos que pagar el update a XE5 para disponer del stylebook de iOS7? |
#14
|
||||
|
||||
Cita:
Lo que hay en VS, XCode, cualquiera de java, etc son cosas mas bien pobres. Asi que lo "normal" es hacer las cosas por código. De hecho lo que hago en xcode es prototipar con keynote (http://www.apple.com/es/iwork/keynote/) y/o xcode y luego hacer las pantallas por código. Eso en que importa con Delphi? Que resulta que hay mucho ejm e infraestrucura para hacer estas cosas "manualmente" de forma muy eficiente, y una vez se hace el trabajo basico, es facil de organizar. Un ejemplo: http://escoz.com/open-source/quickdialog Para mi, hacer un formulario en iOS es así: Código PHP:
Asi que si hay forma de hacer lo que dices, creo que es preferible gastarse la semana que tarda en hacer un unit que hago cosas como las que muestro, junto con los ifdefs para cada OS que sacrificar el desempeño, porque es MAS fácil solucionar un problema de layout de codigo a mano, que tratar de hackear una libreria masiva como firemonkey y corregir errores de desempeño, o sufrir por tener acceso a cosas nuevas del OS (ej: cambios en la versión) y asi por el estilo por no tener una forma visual de hacer el formulario. Y si eso queda bien? Hacer el diseñador de formularios no queda muy lejos en estos dias... P.D: Y sacando de la manga un truco que se hace por xcode, que tal parsear el DFM y armar el formulario desde allí?
__________________
El malabarista. |
#15
|
||||
|
||||
Cita:
Por otro lado yo no sé que tan complejo puede ser ésta app que ha sido lanzada por la compañia japonesa Hitachi Medical Computer Systems y que según éste artículo, eligió DelphiXE4 para desarrollar su aplicación para iPad's. Lo relevante de éste artículo y lo que yo siempre he sostenido desde que tuve la oportunidad de usar ésta versión es lo siguiente: Cita:
Cita:
Cita:
Es decir, Mismo código base = reducción de tiempo y costos de producción = mayores utilidades ($$$$) Y si a eso le agregamos la llegada de Delphi para Android en un futuro muy próximo, las posibilidades de expandir nuestro mercado es muy alentador. Saludos
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#16
|
||||
|
||||
Exacto, el fuerte de Delphi es ese, y siempre lo será. Ahora mas que nunca.
|
#17
|
||||
|
||||
egostar,
Nelson. |
#18
|
|||
|
|||
Nadie está criticando ni a Delphi ni a la multiplataforma de Delphi. De hecho estoy ansioso porque sea compatible con Android (aunque esta vez dudo que la empresa donde trabajo haga otro desembolso). He intentado hacer una crítica constructiva que creo que no ha sido muy bien comprendida por los saltos a la yugular que estoy esquivando
Aquí tenéis un vídeo donde se ve la misma aplicación primero creada con componentes de FM y luego usando componentes nativos (Ambas en XE4). Comparativa FM vs Constroles Nativos Que cada uno saque sus conclusiones. Saludos |
#19
|
||||
|
||||
Cita:
|
#20
|
|||
|
|||
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Sumar campo cuando este asi actualizado | rufo | Varios | 12 | 28-05-2010 21:17:03 |
Informe Actualizado | BlueSteel | Impresión | 3 | 05-10-2006 01:09:00 |
no me muestra un campo actualizado con triggers | pmfras | Firebird e Interbase | 0 | 05-03-2005 17:41:07 |
Administrador para MySQL actualizado | Gasper | MySQL | 0 | 01-04-2004 20:54:40 |
|