Eso mismo le iba a comentar al compañero. Al final es una muestra de lo que pude conseguirse.

Esto me parece muy importante y agradezco que lo comentes compañero. Esos componentes están a la venta? hay algún demo? El dato sobre el rendimeinto seguro a ma´s de uno interesará

Eso esta bien, siempre un toolkit gráfico que sea multiplataforma implica un resultado "promedio".

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.

Perdón, no quería menospreciar tus tutoriales ni mucho menos, pues me parecen fabulosos y una prueba de concepto estupenda. Lo único que pretendía decir es que a la que haces un proyecto medianamente complejo, el rendimiento de firemonkey deja de ser - al menos para mí - suficiente para comercializar una aplicación. Una aplicación que va mal en Windows, MAC OSX, iOS y Android, es una aplicación que va a vender poco por muy multiplataforma que sea y por muy código único y base que tenga.

Está claro, pero a mi me encanta el concepto de "Programa una vez - compila en varios dispositivos usando prácticamente el mismo código". Hasta ahí estamos de acuerdo. Sólo mostraba mi queja de que Embarcadero no ha tomado - en mi opinión - el camino correcto, que sería el de usar los controles nativos de plataforma internamente:

Código Delphi [-]
{IFDEF ANDROID}
   //Llamada al dibujado/propiedad/procedimiento/función de Android
{ENDIF}

{IFDEF IOS}
   //Llamada al dibujado/propiedad/procedimiento/función de IOS
{ENDIF}

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.

Son componentes de código abierto y totalmente gratuitos.

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

El problema es que tienes que separar por completo la vista del código, es decir, deberías tener dos formularios, uno para android , y otro para iOS. Esa es la desventaja.

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.

Efectivamente. Y ahí viene mi queja hacia el planteamiento "multiplataforma" de firemonkey.

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....

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 :D , 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 ... :rolleyes:

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%.

Pero si esto es así ahora mismo en XE5...:confused:

Esto si no se maneja de esta forma ahora, el dibujo lo maneja firemonkey, no nativo.

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 :)

Te voy a dar un baldao de agua fría: Solo existen 2 IDES (que conozco) donde el diseño de formularios es como debe ser: Visual FoxPro, Delphi. (Y acces, también).

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í:

Y eso se encarga de armar los formularios, junto con otras facilidades, y de tener un diseño estandar para todo, y facilitar la traduccion y otras cosas que terminan siendo mejores cuando se hace por código.

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í?

Exacto, y no he dicho lo contrario. El talón de aquiles de firemonkey, es el dibujado, que es lentísimo. No he probado XE5 así que no sé hasta qué punto este "problema" se ha mejorado. Hablo de XE4, que es el único que he podido probar.

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?

Ok, pero en el caso de que todo pase por el dibujo lo veo solucionable, quizás no en XE5 y habrá que esperar un poco. XE5 abre la puerta a Android y luego de esto deberían venir las optimizaciones.

Esto es normal, dado que iOS v 7 aun ni esta en la calle, sino betas. Claro que vas a tener que pagar un update cada vez a EMB, eso ya es sabido, es su *política de ingresos* :rolleyes:

De todos modos sigo creyendo que es una opción muy viable contra las demás del mercado, solo resta ingeniarselas, o usar XCODE, el camino mas largo y de seguro el mejor, pero a costo de una curva de aprendizaje enorme. Nunca usaría Oxygene, me parece una pérdida de tiempo terminar usando VS solo para escribir en pascal.

Tratando de concordar con alguién... odio los framework. Nada corre mejor y rápido que una aplicación compilada nativamente. Por eso amo Delphi :)

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.

No puedo contestarte eso, porque no instalo betas de iOS7. :D

Pero todo lo demás que comentas, ayudaría que conozcas XE5 antes de comentar, no te parece?

Para terminar, para algunos es un problema, y para otros no lo será. lo importante es que en cualquier caso si es por el aspecto, siempre puedes usar los componentes nativos, tienes opciones gratis y de pago, asi que no veo rollo ahí. :rolleyes:

Está claro... pero en este mundo, quien no llora no mama. A Embarcadero hay que reconocerle sus cosas buenas... pero sin olvidarnos de las malas y recordárselas de vez en cuando!

¡Soy de los que piensan que el cliente que se queja es el que hace que "mi aplicación" sea cada vez mejor!

Por mi parte, me parece una excelente noticia, creo que ahora se ha logrado un producto bastante bueno y solo restará hacerle mejoras propias de cada sistema, por ahora estamos centrados en el asunto de los móviles y todas esas novedades... pero ya me imagino haciendo después un programa para Android que "corra" en todo lado... por ejemplo... en las Google Glass (Que supongo que vienen con Android ¿no?). Que bueno es.

P.D: jejeje, siempre me divierto leyendo estas opiniones, cada que embarcadero va a lanzar algo novedoso... siempre tiene que haber alguien como con rencor... dando opiniones jejeje

+100000000

En realidad no hay nada que perdonar, de hecho estoy conciente que mis tutoriales son muy muy básicos y con muchas carencias debido a mi nivel de conocimientos, es decir, no me molesta, la crítica a mi me gusta porque sólo así me doy cuenta de mis errores :).

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:

Artículo completo

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

Exacto, el fuerte de Delphi es ese, y siempre lo será. Ahora mas que nunca. ^\||/

egostar,

^\||/ :)

Nelson.

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 :D

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

Mas que claro el punto. Los nativos que utilizaste cuales son?

Gracias.

Que bueno sería que se vean en tiempo de diseño como si se ven los FM...

De nada.

Ya se ven de hecho la mayoria de ellos en designtime al ogual que los Firemonkey. Un tal Fenistil se está encargando de ello.

Que bien, es cierto.

Abri el ejemplo de datepicker y ahora si se ven en el form, pero cuando le doy build no compila...

[DCC Error] DPF.iOS.UIDatePicker.pas(159): E2147 Property 'UserInteraction' does not exist in base class

De todas maneras seguire probandolos, son una muy buena opción. Habrá que ver cuando existan nativos para android si hay diferencia de performance o no con FM, por el lado de iOS no cabe duda que si.

Echale in vistazo al install.txt... son un poco "puñeteros" de instalar... puesto que hay que hacerles el build a win32, ios simulator e iOS Device y ademas añadir los frameworks que faltan para que funcione en dispositivos reales.

Estoy seguro de que terminaran haciendo algo parecido para Android (como ya han hecho con freepascal y lazarus). La pena es que firemonkey no use internamente el dibujado de estos controles nativos y perdamos este rendimiento extra en aras del multiplataforma. Sigo convencido de que con poco de esfuerzo extra podríamos tener lo mejor de ambos mundos.

No he tenido mucho tiempo de explorar el codigo de FM para iOS y Android. :(

Si llego a encontrar un hueco me pongo a ver

Hola

Siguiendo con el tema, ya he hecho una prueba con la aplicacioncita para convertir monedas, y fué tan simple como ésto:

1. Hice una copia del proyecto que Desarrollé para iOS.
2. Lo abrí con mi "flamante" Delphi XE5.
3. Cambio el "target" a Android.
4. Compilo y listo, ya está la app para Android.

Más fácil.......... nada.

Por cierto, me acabo de dar cuenta que me comí una letra en el título de la aplicación :D :D :D

Saludos

Me has dejado boquiabiertado amigo mio. Cada vez me emociona más la llegada de DelphiXe5. :D

Por cierto, el compañero Maximun comentó alguna vez que Lazarus lo hacia sencillo, valdría la pena que algún experto muestre una comparativa como la tuya amigo egostar.

egostar,

Excelente ^\||/

Pregunto: ¿En general como es Delphi XE5 a nivel de IDE, velocidad, ayudas, ejemplos, compatibilidad con versiones previas, etc?.

Gracias de antemano :)

Nelson.

Yo la última vez que miré el tema de configurar la plataforma Android para Lazarus desistí ante la complejidad de la configuración por falta de tiempo... a ver si alguien nos cuenta qué tal está el asunto ahora...

Es lo que estoy diciendo desde el primer post:

" Donde se ha visto a que a una aplicación iOS solo le digas que la quieres en android, recopilas y ahi la tienes? Nadie logro esto... Delphi si. "

Así es, especialmente por lo mucho que se ha traido a colación cuando se trata de comparar Delphi.

Exacto. y eso es lo que emociona aún más.

donald shimoda,

Creo que es el principio de un nuevo comienzo para Delphi: Computación Ubicua :)

Excelente Embarcadero ^\||/ v:-)v ||-|| #:-)#

Nelson.

Que tal Nelson, estoy usando la versión BETA así que lo que te pueda decir ahora no es garantía de que la versión final sea la que estoy evaluando. Sin embargo, por norma general Delphi siempre se ha movido hacia adelante y ésta no sería la excepción.

Claro, también depende de lo que cada quien piense, eso es lo que personalmente creo.

Saludos.

Hola

Mi buen amigo cadetill ha publicado un artículo de como configurar el ambiente de desarrollo del SDk y NDK para Android y ser usado por Delphi.

Saludos

egostar,

Estoy seguro que así sera :)

Nelson.

Gracias por el enlace, pero según dicho enlace hace falta Rad Studio XE5.

Saludos

Estoy más contento que perro con hueso de brontosaurio.