Mobile Roadmap - Actualizado

[[egostar]]

Empezado por mamcx

.......El problema es que en mobiles, llegar primero es importante, y el saber llegar esta por verse........

Me parece que no hay que perder de vista algo importante al menos desde mi perspectiva.

Delphi es Windows Nativo y ahora con la posibilidad de complementar tus desarrollos para Windows con aplicaciones en otros sistemas operativos. Tal vez no es la mejor herramienta para desarrollar en móviles, pero sí es la mejor opción que tiene un desarrollador para ello, y esto porque no se tiene que aprender otros lenguajes para el deploy de aplicaciones multiplataforma, algo que muchos desearían tener pero que sin remedio tienen que utilizar diferentes herramientas, aprender diferentes lenguajes y perder tiempo en la creación de aplicaciones individuales.

Yo insisto en mi "slogan"

"Mismo código base, mismos componentes, diferente plataforma"

No sabes lo genial que es copiar, pegar y compilar y obtener diferentes aplicaciones, aún cuando se diga que es tarde, iOS, OSX, Android aún no son mi mercado principal, mi mercado principal es Windows y como valor agregado aplicaciones en otras plataformas, cosa que me vendrá muy bien con algunos clientes y por ende a mi bolsillo.

Empezado por MAXIUM

Si Delphi se hubiese concentrado en Android en vez de .NET o en vez de Firemonkey, las ventas habrian por fin despegado.

Nah, los que más se quejan siguen con Delphi6 y Delphi7 y ahora Lazarus porque es gratis, nunca van a pintar en las ventas, eso que argumentas es una falacia.

Saludos

[donald shimoda]

Empezado por egostar

Tal vez no es la mejor herramienta para desarrollar en móviles, pero sí es la mejor opción que tiene un desarrollador para ello, y esto porque no se tiene que aprender otros lenguajes para el deploy de aplicaciones multiplataforma, algo que muchos desearían tener pero que sin remedio tienen que utilizar diferentes herramientas, aprender diferentes lenguajes y perder tiempo en la creación de aplicaciones individuales.

Exacto. Mi visión es que si necesitas complementar tus aplicaciones empresariales dandoles acceso al mercado de móviles , es una excelente opción. 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.

Ahora, si tu idea es hacer un juego para iphone, pues aprende Objetive C, ni siquiera Oxygene es la mejor opción en eso. Lo mismo para android.

La única "pega", como se dice, es que RemObjects no soporte delphi para móviles. Es inadmisible, pero Marc esta entroncado con su es socio (EMB) y nos ha dejado colgados de la medianera a todos. Flor de garca (si se me disculpa la expresión)...

Así que si vas a utilizar delphi para móviles tendrás que migrar al menos una parte de tu servidor a datasnap.


Saludos.

[DarkDudae]

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.

[MAXIUM]

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

[[egostar]]

Empezado por DarkDudae

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

Zaz!!!!!

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

[mamcx]

Empezado por egostar

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.

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.

[[poliburro]]

Empezado por egostar

Zaz!!!!!

Bueno, bueno, pero tampoco iba a publicar un ERP a modo de ejemplo

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

Empezado por DarkDudae

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.

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á

[DarkDudae]

Empezado por egostar

Zaz!!!!!

Bueno, bueno, pero tampoco iba a publicar un ERP a modo de ejemplo

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.

Empezado por egostar

Si pretendes adquirir Delphi para desarrollar únicamente para iOS - OSX, pues estás apuntando al lado equivocado, para eso hay herramientas esclusivas.

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.

Empezado por poliburro

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á

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

[donald shimoda]

Empezado por DarkDudae

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

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.

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

[DarkDudae]

Empezado por donald shimoda

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.

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

[[egostar]]

Empezado por DarkDudae

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.

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:

DELTA View is a software system that enables a dentist to receive "informed consent" by presenting medical information to a patient. DELTA View is a Presentation Image Viewer used by dentists to display X-ray images. The Windows version was adopted by more than 400 dental clinics within six months of its release in 2012. The iPad version was developed in response to dentists who also wanted to use the app on tablets. Delphi XE4 (released April 2013), which can be used for iOS app development, enabled the release of the iPad version in a short amount of time.

Development of the iPad version commenced in March 2013 with the evaluation of the Delphi XE4 beta. By utilizing existing code from the Windows version, it was possible to get the app up and running on the iPad in just one month. After some fine-tuning and adjustments, the app was submitted to Apple and passed its review. In total, it took only three months of actual development time to complete the app.

Because Delphi XE4 enables development for both Windows and iPad devices, the same code can be used for both devices, while at the same time enabling the ability to fine tune the code to each device. This means the number of man-hours and the costs required for multi-device app development can be reduced significantly.

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

[donald shimoda]

Empezado por egostar

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.

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

[[nlsgarcia]]

egostar,



Nelson.

[DarkDudae]

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

[donald shimoda]

Empezado por DarkDudae

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

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

[DarkDudae]

Empezado por donald shimoda

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

http://sourceforge.net/projects/dpfdelphiios/