Desisto
 

Hola a todos....

Creo que por el momento voy a desistir de la idea de Android con Delphi....

Tiene varias cosas que no logro encontrarle la vuelta... por ejemplo el tamaño... creo que ni mis aplicaciones de escritorio llegan a pesar lo que pesa el APK para un Movil....

El soporte para Firebird es otra cosa, aunque no tan importante pero suma...

La lentitud para probar las aplicaciones es otro gran punto... cuando estas en un punto donde las cosas las haces con prueba y error... esta lentitud te mata....

Espero que pronto podamos tener noticias de algunas mejoras...


Saludos...

Hola,

Ayer leí en los foros de Embarcadero que acaso tengan que mirar lo que hace el "debugger" de Delphi con el emulador de Android para que vaya tan lento. Sin embargo, lo cierto es que si uno ha probado Android Studio, sabe que probar las aplicaciones con el emulador tampoco es que sea rápido que digamos: más bien al contrario, es bastante lento también. La solución que parece se recomienda es depurar y probar las aplicaciones con un dispositivo "real", puesto que, en efecto, en ambos entornos, la cosa cambia bastante a mejor.

No he probado delphi con android ni creo que lo haga, de momento, pero la mayoría de los problemas que indicas de velocidad, depuración, etc. son del "emulador" de android, no tiene nada que ver con delphi, es lento usando cualquier otro lenguaje o entorno de desarrollo.
Es lento ese emulador y además falla bastante.

Ese es uno de los puntos fuertes de iOS. Cuando trabaje con Windows Mobile tambien era horrible el emulador y odiaba cada minuto que trabaje en ese entorno.

En iOS es al contrario: Corres con la velocidad de tu PC (de hecho, lo lento es probar en el equipo!).

Una forma de darle la vuelta, es trabajar usando unit testing y toda la logica de negocios con un cliente PC.

Una cosa que hice hace un tiempo es hacer una app de consola, que invoca una libreria donde esta todo el nucleo de la aplicacion.

Luego, hice la GUI aparte cuando todo estaba dando forma y luego el pulimiento. Eso fue con .NET, que es lento tambien la parte de la GUI.

Hola, Yo lo que hago es programar normalmente, jalando los componentes que necesite y para hacer pruebas me voy a "Target Plataforms" y elijo "32-bits Windows", asi mi proyecto se ejecuta como un .exe(de hecho lo crea)esto es totalmente veloz y cuando estoy satisfecho con todo recien cambio en "Target Plataforms" a "Android sdk" y le doy Deployment.
De esta manera me llevo el .apk a mi dispositivo sabiendo de antemano que el codigo esta bien.
Obviamente por el momento elegiria a Eclipce+skd pero el EX5 tiene armas con que defenderse jejeje.

Efectivamente, el emulador va lento si no tienes un sistema "potente", ya sea android o iphone, uses eclipse o xcode.

Yo te recomiendo lo que siempre uso, un dispositivo físico, lo pruebas y lo debugeueas con algo físico y va rápido.

Lo de firebird, ni idea, no lo uso. Lo que si creo que tienen que arreglar (y supongo que saldrá algún update1 pronto) es lo del tamaño del APK.

Yo tampoco usaría el XE5 para proyectos grande todavía, ya que no hay soporte para publicidad adwords y compras en google play y apple store a través de la aplicación.

Si me arreglan esas 3 cosillas de na, uso XE5 y se lo hago usar a todo el departamento de desarrollo de la empresa :D

Eso de que demore o sea lento en cargar una aplicación para depurarla es lo de menos. Uno debe concentrarse en el código y luego depurar, no depurar para concentrarse en código. En la antigüedad, cuando se usaban tarjetas perforadas, se debía estar seguro que todo estaba bien antes de compilar, ya que de lo contrario, tendrías que pasarte horas o días en espera del uso del computador que compilaría y eso tomaría otras horas más.

Lo que me incomoda, es eso del tamaño que es exageradamente grande. Una aplicación comprimida en APK creada con XE5, no baja de 5MB, sin embargo al usar VB con Oxygene, me creo lo mismo en 40KB...

Mientras no salga una mejora, voy a intentar con HTLM5 para crear los APK.

http://programadorygeek.blogspot.com...nativa-de.html

Voy a tener que ver por ese lado....

Estaba intentando con Raudus.. pero estoy llegando a un punto muerto y me preocupa....

Saludos...

¿No será que es compilación nativa e incluye la parte runtime en el APK? Si lo que usamos para hacer apps es java, el SO ya lleva todo lo que necesita, es fácil crear APKs pequeños.

Si piensas desde el punto de vista Delphi (RTL/VCL): ¿dónde está la RTL/Firemonkey para Android/iOS?

Eso es como salir de mal a otro mal.

Las opciones tipo HTML5 tienden a ser lentas desde el punto de vista del usuario. Son aun mas difíciles de optimizar y dependen de la eficacia del runtime de navegador (el cual no controlas, en Android es regular y peor aun dependiendo del equipo).

Hay maneras de darle vuelta, pero es mas difícil. Por ejemplo, puedes usar algo como https://github.com/phoboslab/Ejecta (no conozco alternativa para android) pero igual estas batallando contra la realidad: HTML NO ES Android, ni IOS, es una cosa diferente. No actúa, no desempeña, no se ve, como lo nativo. Y el usuario estándar de un lenguaje cualquiera no tiende a ser poliglota ni meterse en cosas opuestas al tipo de lenguaje que tiene (JS es toda una bestia diferente a Delphi).

Lo tristes es que como me esperaba, tanta fanfarria con lo de android y fijo sacan algo mediocre*, en un momento que no da para eso, a un precio carísimo. Era obvio: Pa iOS tampoco es que tuvieran algo competitivo. En vez de pulir lo que hay, sacan cosas por sacar.


El asunto es que al final, usar HTML5 tal cual solo es para hacer apps mediocres en experiencia de usuario. No hay casos de éxito notorios.

* No me refiero al emulador. Que las herramientas de android pa desarrolladores son mediocres es algo sabido. No es chiste cuando se dice que sale mas caro programar pa android que para iOS. Lo cual es raro, ya que Google es competente como desarrollador de software, y cosas como el lenguaje GO están jodidamente bien pensadas...

Realmente? Ya instale ENT XE5 pero aun no lo he mirado (si mire la beta y funcionaba bien). Pero da ejemplos concretos de que tamaños hablamos?

Es lo que siempre comentamos, creo que XE5 esta mas orientado a de manera muy rapida llevar aplicaciones con un target de empresas que ya tengan otro producto propio, hacerles un cliente android o iOS. En m caso cierra perfecto el modelo, y el tamaño no es un tema relevante. Entiendo que para los que quieran salir al mercado Android no aplique este modelo.


El soporte para Firebird es otra cosa, aunque no tan importante pero suma...

Perdón por la insistencia, con el driver de IBASE no conecta?

Esto si es de Android, olvidate. Tenes que probar en dispositivo real y hay una alternativa que es un drrver para que el simulador use Atom/intel, lo vi en los foros de las betas pero no le puse cuidado porque siempre use una tablet real que cuesta 70 usd. :P Es mucho mas practico a mi entender.

En cuanto a lo que dices del soporte para Firebird... bueno, es que Firebird no tiene una edición para dispositivos Android, por otro lado si necesitas acceder a un server, para eso existe DataSnap.

+1, creo que es la mejor solución, siempre y cuando no tengas que usar controles con sensores del móvil.....

Esto se puede hacer con una plataforma que dominas previamente, pero con un producto tan joven como XE5 hay que probar y probar código constantemente por que no siempre funciona como te lo esperabas y la verdad es que es muy frustrante no poder hacer pruebas con agilidad.
Y en cuanto a lo de las tarjetas perforadas, en aquellos tiempos se podía hacer lo que dices por que eran lenguajes de programación muy basicos que tenian cuatro instrucciones, pero eso en los tiempos que corren ya no es posible, por ejemplo un producto como XE5 soporta un montón de tecnologías que yo pienso que casi nadie domina en su totalidad y dominarlas requiere el uso continuo del método de la prueba y el error.

Sólo agregaría que se requiere de un cambio de mentalidad, hacer aplicaciones móviles no es para nada lo mismo que para aplicaciones de escritorio tal y como hemos estado acostumbrados a desarrollar hasta ahora, se requiere algo más que un par de días para entender el concepto y las diferentes propiedades de los componentes.

Saludos

Pero esto no tiene que ver con saber o no la herramienta, sino mas bien, si la herramienta se desempeña de forma correcta y justifica su precio.

Y hacer un hello world es lo mas minimo posible que existe. Que hay que saber para hacerlo? Escribir unas cuantas lineas y darle play.

Si eso no funciona, como justificar el precio? Quien se aguanta una herramienta lenta e ineficiente? Y en móviles, donde es AUN mas importante esa eficiencia?

Si, tienes razón. :rolleyes:

Saludos

Xe5 = Kaka
 

Vaya truño de depurador para Android ... Malo, muy malo .... Ya me estoy pasando las librerias a Basic4Android (B4A) ... Ke tampoco es una maravilla pero se deja kerer .... Y con una comunidad muy activa.

Y del precio ni te cuento. Da risa $50 frente al XE5 !!!!

No he conseguido que funcione de forma correcta nada de nada ... Cuesta mas configurarlo que programar 2+2 ...

Triste.:cool:

Pues el depuerador de B4A tiene fama de ser una "birria" inservible.