Mobile Roadmap - Actualizado

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

[donald shimoda]

Empezado por DarkDudae

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)

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

Empezado por DarkDudae

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.

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

Empezado por DarkDudae

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

[DarkDudae]

Empezado por donald shimoda

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

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?

[donald shimoda]

Empezado por DarkDudae

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

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.

Empezado por DarkDudae

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?

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*

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.

[mamcx]

Empezado por DarkDudae

De hecho, esto ahora mismo ya se podría conseguir, pero se tendría que hacer mucho trabajo de forma manual.

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

Código PHP:

- (QLabelElement *) addLabel:(NSString *)key title:(NSString *)title value:(NSString *)value;
- (QBadgeElement *) addBadge:(NSString *)key title:(NSString *)title value:(NSString *)value;

- (QEntryElement *) addText:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder;
- (QAutoEntryElement *)addCombo:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder items:(NSArray *)items;
- (QEntryElement *) addPhone:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder;
- (QEntryElement *) addPassword:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder;
- (QEntryElement *) addEmail:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder;
- (QDecimalElement *) addNumber:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder;
- (QDecimalElement *) addMoney:(NSString *)key title:(NSString *)title placeholder:(NSString *)placeholder; 


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