Desisto

[dec]

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.

[Casimiro Notevi]

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.

[mamcx]

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.

[ginkaku]

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.

[matabyte]

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

[MAXIUM]

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

[MAXIUM]

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

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

[CSIE]

Empezado por MAXIUM

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

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

[quimeras]

Empezado por MAXIUM

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.

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.

[cocute]

Empezado por ginkaku

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.

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