Portada
mis comunidades
otras secciones
#7:
#1 El hecho de que para Android utilizan todavía el api de 2008 Camera1 que Google ha retirado soporte debería alarmar...
Esa es la razón por la que consume demasiada batería y las fotos son de unahorrible calidad: Lo que hace la app no es usar la cámara sino esencialmente grabar por encima de lo que está recogiendo el visor. Un parche en vez de actualizar a camera2.
Pero eso sí, en iPhone va como la seda. El fundador odia Android y no invierten para nada en su desarrollo.
Esa es la razón por la que consume demasiada batería y las fotos son de unahorrible calidad: Lo que hace la app no es usar la cámara sino esencialmente grabar por encima de lo que está recogiendo el visor. Un parche en vez de actualizar a camera2.
Pero eso sí, en iPhone va como la seda. El fundador odia Android y no invierten para nada en su desarrollo.
#21:
#20 Es necesario que mate la actividad, si no no podría hacer frente a los nuevos resources ni a la nueva configuración.
iOS no lo hace y no tienes que hacer los cambalaches raros que hay que hacer en Android para mantener el estado. En iOS montas las vistas y se usan sin más. En Android tienes que preocuparte de un montón de cosas que no deberían ser necesarias desde el punto de vista del programador, y en determinadas vistas (en las vistas con scroll, por ejemplo) Android carga algunos datos mágicamente y en otras deja todo el trabajo al programador si quieres mantener el estado. Y tampoco es que facilite mucho la vida entre Activities, Fragments, Parcels y demás. Ahora parece que Intentan hacer el parche con los ViewModels, que mantienen el estado de la capa de datos, y la siguen cagando porque en determinados casos esa capa también se va a la mierda y la tienes que recrear tú.
Lo de que gaste más RAM es lógico porque tiene que servir para más dispositivos, pero no tiene nada que ver con las decisiones de desarrollo que han tomado y mi caso actual los memory leaks que estoy sufriendo porque al rotar el teléfono. algo que debería ser lo más común del mundo, el código da más vueltas que un tiovivo.
Y eso que desde la versión 4 es mucho mejor con las librerías de soporte para móviles antiguos. En la versión 1.6 y la 2.4 que fue cuando empecé a hacer cosas, ir a Android desde iOS era para ir a ver si los de Google el título de ingeniero se lo sacaron regalado con Casado.
Lo bueno es que por lo menos parece que mejoran en cada versión y no se estancan, pero algún día diremos lo bueno que es el framework de programación Android y alguien dirá que iOS, como los Simpson, lo hizo 20 años antes.
iOS no lo hace y no tienes que hacer los cambalaches raros que hay que hacer en Android para mantener el estado. En iOS montas las vistas y se usan sin más. En Android tienes que preocuparte de un montón de cosas que no deberían ser necesarias desde el punto de vista del programador, y en determinadas vistas (en las vistas con scroll, por ejemplo) Android carga algunos datos mágicamente y en otras deja todo el trabajo al programador si quieres mantener el estado. Y tampoco es que facilite mucho la vida entre Activities, Fragments, Parcels y demás. Ahora parece que Intentan hacer el parche con los ViewModels, que mantienen el estado de la capa de datos, y la siguen cagando porque en determinados casos esa capa también se va a la mierda y la tienes que recrear tú.
Lo de que gaste más RAM es lógico porque tiene que servir para más dispositivos, pero no tiene nada que ver con las decisiones de desarrollo que han tomado y mi caso actual los memory leaks que estoy sufriendo porque al rotar el teléfono. algo que debería ser lo más común del mundo, el código da más vueltas que un tiovivo.
Y eso que desde la versión 4 es mucho mejor con las librerías de soporte para móviles antiguos. En la versión 1.6 y la 2.4 que fue cuando empecé a hacer cosas, ir a Android desde iOS era para ir a ver si los de Google el título de ingeniero se lo sacaron regalado con Casado.
Lo bueno es que por lo menos parece que mejoran en cada versión y no se estancan, pero algún día diremos lo bueno que es el framework de programación Android y alguien dirá que iOS, como los Simpson, lo hizo 20 años antes.
#20:
#c-19" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/19">#19 Es necesario que mate la actividad, si no no podría hacer frente a los nuevos resources ni a la nueva configuración.
Si pasas de landscape a portrait debe adaptar su diseño, lo que lleva a cargar de nuevo los recursos. Si no lo hiciera automáticamente deberías hacerlo siempre de forma manual para evitar memory leaks.
Si los eventos que se disparan te causan problemas en la app hay varias estrategias para ignorarlos.
No es que las apps de iOS estén más pulidas, es que Android es un zampador de RAM incansable, además de apuntar a miles de diferentes dispositivos.
Yo trabajo con Swift, Kotlin y java en android, y en servidor con IIS c# y JS. Lo mejor que hay y lo más cómodo es trabajar sobre Android en Android Studio.
Aunque se programara en lenguajes mutantes como Scala / Clojure solo el IDE haría que programar en Android fuera mucho más sano y ameno que en iOS.
Si pasas de landscape a portrait debe adaptar su diseño, lo que lleva a cargar de nuevo los recursos. Si no lo hiciera automáticamente deberías hacerlo siempre de forma manual para evitar memory leaks.
Si los eventos que se disparan te causan problemas en la app hay varias estrategias para ignorarlos.
No es que las apps de iOS estén más pulidas, es que Android es un zampador de RAM incansable, además de apuntar a miles de diferentes dispositivos.
Yo trabajo con Swift, Kotlin y java en android, y en servidor con IIS c# y JS. Lo mejor que hay y lo más cómodo es trabajar sobre Android en Android Studio.
Aunque se programara en lenguajes mutantes como Scala / Clojure solo el IDE haría que programar en Android fuera mucho más sano y ameno que en iOS.
Comentarios
¿Alguien guardó una copia?
#6 Esa debería ser la pregunta más importante.
#c-19" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2992671/order/19">#19 Es necesario que mate la actividad, si no no podría hacer frente a los nuevos resources ni a la nueva configuración.
Si pasas de landscape a portrait debe adaptar su diseño, lo que lleva a cargar de nuevo los recursos. Si no lo hiciera automáticamente deberías hacerlo siempre de forma manual para evitar memory leaks.
Si los eventos que se disparan te causan problemas en la app hay varias estrategias para ignorarlos.
No es que las apps de iOS estén más pulidas, es que Android es un zampador de RAM incansable, además de apuntar a miles de diferentes dispositivos.
Yo trabajo con Swift, Kotlin y java en android, y en servidor con IIS c# y JS. Lo mejor que hay y lo más cómodo es trabajar sobre Android en Android Studio.
Aunque se programara en lenguajes mutantes como Scala / Clojure solo el IDE haría que programar en Android fuera mucho más sano y ameno que en iOS.
#20 Es necesario que mate la actividad, si no no podría hacer frente a los nuevos resources ni a la nueva configuración.
iOS no lo hace y no tienes que hacer los cambalaches raros que hay que hacer en Android para mantener el estado. En iOS montas las vistas y se usan sin más. En Android tienes que preocuparte de un montón de cosas que no deberían ser necesarias desde el punto de vista del programador, y en determinadas vistas (en las vistas con scroll, por ejemplo) Android carga algunos datos mágicamente y en otras deja todo el trabajo al programador si quieres mantener el estado. Y tampoco es que facilite mucho la vida entre Activities, Fragments, Parcels y demás. Ahora parece que Intentan hacer el parche con los ViewModels, que mantienen el estado de la capa de datos, y la siguen cagando porque en determinados casos esa capa también se va a la mierda y la tienes que recrear tú.
Lo de que gaste más RAM es lógico porque tiene que servir para más dispositivos, pero no tiene nada que ver con las decisiones de desarrollo que han tomado y mi caso actual los memory leaks que estoy sufriendo porque al rotar el teléfono. algo que debería ser lo más común del mundo, el código da más vueltas que un tiovivo.
Y eso que desde la versión 4 es mucho mejor con las librerías de soporte para móviles antiguos. En la versión 1.6 y la 2.4 que fue cuando empecé a hacer cosas, ir a Android desde iOS era para ir a ver si los de Google el título de ingeniero se lo sacaron regalado con Casado.
Lo bueno es que por lo menos parece que mejoran en cada versión y no se estancan, pero algún día diremos lo bueno que es el framework de programación Android y alguien dirá que iOS, como los Simpson, lo hizo 20 años antes.
#21 Supongo que iOS no lo hace por las peculiaridades de su "GC", le permitirá destruirlo todo y volverlo a cargar sin tener que cargar los recursos, y sin tener que borrar los recursos anteriores.
De ser así tendría que ver con ART, no con el entorno. Para mí el gran problema de la programación en Android es el sistema operativo.
Los fragments son una herramienta que puedes usar o no, son reusables y versátiles ya que añaden su propio ciclo de vida y eventos, entre otras muchas cosas. Siempre puedes usar Custom Views.
Lo mismo pasa con los activities, no hay otra forma de solucionarlo. De la misma forma que en iOS requieres ViewControllers. La "gran diferencia" es que uno hereda y el otro requiere un delegado (herencia vs composición siempre gana composición, claro).
Sinceramente tengo la suerte de no experimentar los problemas que estás experimentando. Nuestros productos funcionan en todos los móviles y tablets posibles, además de en una docena de wereables android cada uno de su padre y de su madre, y no tenemos problemas
Supongo que nos libramos porque siempre mostramos landscape, no permitimos girar, y aunque hacemos un uso intensivo de cámaras y pantallas solo trabajamos sobre dos layouts.
La verdad es que no puedo estar de acuerdo contigo. La diferencia entre XCode y Android Studio es tan gigantesca, el uso de gradle, Kotlin, la generación de distribuibles... Es otra dimensión.
#24 Android Studio es IntelliJ, a mi juicio el mejor IDE... No es mérito de Android, sino de JetBrains.
WebStorm: mejor IDE para web, frameworks javascript, Node...
PhpStorm: mejor IDE para php
IntelliJ: Tiene más competencia y... probablemente el mejor IDE para Java.
Android Studio: IntelliJ parcheado...
El resto de la suite (pyCharm, CLion... etc...) no los he usado, pero me temo que son grandes IDES, ya que todos son prácticamente iguales.
xCode es un truño comparado... pero vamos, entre xCode y Eclipse... difícil elección.
#c-29" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2992671/order/29">#29 Te falta el ReSharper para Visual Studio// C# y AppCode para iOS.
AppCode es mejor que XCode, pero no mucho mejor, me parece un skin. Un skin caro.
No estoy de acuerdo que Android Studio sea un Intellij "parcheado". Es más bien al revés, si usas Intellij para Android necesitas parchearlo para que tenga funcionalidad similar:D
Pero bueno, compartiendo lenguaje es lógico que Android Studio sea un Intellij adaptado, no van a hacer lo mismo dos veces. Y teniendo en cuenta que siguen migrando todos sus productos a Kotlin , sería una pesadilla.
De hecho Kotlin/Native no tendrá soporte en Intellij. Lo cual mata Intellij como opción para cualquier desarrollo mobile.
https://discuss.kotlinlang.org/t/will-intellij-support-kotlin-native/3535
Jetbrains es una empresa para estudiar. Con la de documentales estúpidos que sacan en Netflix y no hacen ninguno de esta empresa, que es lo que realmente me interesa
¿Qué empresa se mete a pelear en un mercado tan saturado como los de API de desarrollo Java y humilla y destroza a su competencia? Para más inri, deciden que ningún lenguaje les gusta y se ponen a hacer el suyo propio. Y ahora están haciendo que compile a nativo. Con un par.
#30 Cuando digo que AndroidStudio es un IntelliJ parcheado es porque toda la estructura y funcionalidad de IntelliJ (de toda la suite) está integrada en AndroidStudio. AndroidStudio viene de IntelliJ, no al revés. Han parcheado IntelliJ para añadir el framework de Android.
De hecho, cada IDE tiene sus particularidades, pero si aprendes a usar cualquier IDE de la suite, podrás usar todos los demás si conoces algo el lenguaje.
Cuando Kotlin nativo salga... toco madera...
#29 El mejor IDE es y será Visual Studio, todo lo demás es como conformarte con la coja a las 5 de la mañana
#40 Visual Studio es un mal ide, no se puede usar en Linux. Para que fuera un buen ide tendría que poder usarse en varios sistemas operativos.
#46 ah vale , que no tienes ni puta idea , haber empezado por ahí y me ahorraba el esfuerzo de discutir
#47 No sé si tengo puta idea o no, pues para saberlo tendríamos que definir una base a partir de la cuál se tiene "puta idea".
Pero sí sé que no hay Visual Studio para linux.
#9 Eso no es justificación para joder a tus usuarios con desarrollos mediocres. Y lo digo como usuario de iOS.
#9 Creo que te estas confundiendo, no hay mayor dolor de muelas que usar XCode después de haber utilizado Android Studio aunque sea una vez en tu vida.
#15 El IDE está bien, pero la plataforma Android sigue siendo un puto infierno. Ha mejorado bastante, pero en comparación con Apple creo que todavía le queda bastante.
Ahora mismo estoy depurando un problema de acaparación de memoria que me sucede al rotar el teléfono. Cada vez que rotas el teléfono Android mata la aplicación y te obliga a reconstruirla. Una puta salvajada que igual en las primeras versiones tenía algo de sentido, pero por lo que parece se ha quedado enraizado en el núcleo de Android y por muchas ñapas y parches que meten no lo quitan.
No me extraña que las Apps en iOS estén más pulidas, porque en Android muchas veces pierdes tiempo en pegarte con el propio entorno en vez de con problema reales de programación de tu aplicación
#15 Entonces cámbialo por dolor de bolsillo y pásate a Appcode
#18 Toda la información que quieras. Pregunta. 10 años desarrollando para ambas plataformas.
¿Fallos en iOS de difícil localización? Ya quisiera tener en android las herramientas de las que dispongo en iOS. ¿Problemas para obtener certificados en iOS? Tan sencillo como poner tu usuario y contraseña y darle al botoncito para obtenerlos automaticamente después de que te hayan metido correctamente en el equipo de desarrollo.
Oye, como siempre esto es para gustos, pero dame Xcode y quédate con android studio.
#16 no, no me confundo en absoluto.
#15 en eso tienes razón. No hay excusa.
#33 Pues eso, que si tienes más información sobre lo que comentas de que Camera2 saca mejor calidad y gasta menos batería
#34 #33 Me quedé sin tiempo de edición.
No te lo pregunto por vacilar, es que de verdad me interesa.
Certificados: no, no es tan sencillo. Desarrollo, adhoc, distribución en tienda... ¿Por qué sacar adhoc y desarrollo si sirven para lo mismo? Añade los dispositivos que quieras ¡Pero antes busca su udid! Que no es visible, debes conectar iTunes y pulsar un texto para que te lo descubra. Además no puedes distribuir tus ipa en tu servidor, para eso necesitas OTRA cuenta, diferente y que se paga aparte y te obliga a generar otra vez los certificados aparte (en una cuenta aparte, para liarte más aún) ¿Push notifications? Otro certificado nuevo. Otro para desarrollo, otro para distribución... Y si tienes cuenta enterprise otro para desarrollo y otro para distribución...
También tenemos los problemas de instalación... "pues borra los certificados instalados en el teléfono para solucionarlo" (¿¿??) El paso por la tienda ("No podemos aceptarle su aplicación porque al pedir permisos de cámara está usando el texto que viene por defecto") , la deficiente compatibilidad hacia atrás ("o actualizas la versión de iOS o no podrás programar con este sdk")
La burocracia en iOS siempre ha sido una patada en la entrepierna, incomparable con el " genero APK en un click" de Android. Y eso que hace unos años compraron e integraron la empresa que permitía distribuir builds a testers, dieron un gran paso adelante.
No conozco los problemas que te encuentras con Android, porque nunca he trabajado en sistemas UI muy intensivos en ese sistema, que es lo que te está molestando. Pero objetivamente no se puede comparar la sencillez de uno con la complejidad privativa del otro.
#35 Claro que es más complejo, pero supongo que ya estoy tan acostumbrado a iOS y sus cosillas que no m cuesta pegarme con ellos. Al final hasta agradezco su forma también rígida de hacer determinadas cosas. Me permiten abstraerme de ciertas tareas relativas a la seguridad que me resultan un dolor de muelas con android.
En el fondo me gustan ambos sistemas y cada cual tiene sus pros y sus contras, pero en general prefiero pegarme con Xcode (con swift) que con android studio.
#34 no he dicho tal cosa... hasta ahora, pero cualquier desarrollo que implique el uso de la camara es más sencillo y efectivo en iOS que en android.
Trabajo actualmente en app que hacen uso intensivo de la cámara y machine learning y en iOS es casi un placer mientras que con android es... molesto (por no decir otra cosa).
#34 y, ya que estamos, estoy buscando programatas espabilados de ambas plataforma para madrid, así que... mándame un mensaje si conoces alguno que ande buscando. Últimamente parece que hay escasez. También de back con php y MySQL.
Encantados de enseñar con tal de que sea gente despierta y con ganas. Y el ambiente de trabajo es cojonudo.
#39 Es cierto, no lo dijiste tú, lo comentaba #7
Soy de Valencia... No conozco a nadie en Madrid, lo siento
Cámaras en android... Una pesadilla. Dos apis que hacen lo mismo, errores genéricos que no explican nada, el si es muy especialito también a la hora de hacer cualquier cosa con la cámara... Un desastre
No voy a decir que me alegrue, pero, perooo, snapchat es el mal.
#1 El hecho de que para Android utilizan todavía el api de 2008 Camera1 que Google ha retirado soporte debería alarmar...
Esa es la razón por la que consume demasiada batería y las fotos son de unahorrible calidad: Lo que hace la app no es usar la cámara sino esencialmente grabar por encima de lo que está recogiendo el visor. Un parche en vez de actualizar a camera2.
Pero eso sí, en iPhone va como la seda. El fundador odia Android y no invierten para nada en su desarrollo.
#7 desarrollar para android es un dolor de muelas tras hacer la versión de iOS. No es odio. Es cansancio y frustración. Palabra de programador experimentado.
#8 Es lo que hay...en mi caso te puedo decir que al margen de lo que comentan #7 y #9 mi comentario en #1 está hecho con conocimiento de causa.
#9 Creo que te estás confundiendo, no hay mayor dolor de muelas que utilizar XCode una vez que has probado Android Studio.
#7 ¿¿¿??? La primera vez que lo oigo. No digo que no sea cierto pero me extraña mucho, ¿tienes más información?
Muchos desarrolladores seguimos con Camera1 porque necesitamos que trabaje con API < 22
Lo que aporta Camera2 es funcionalidad nueva, como hacer muchas capturas seguidas para fabricar gifs. O aplicar efectos directamente. Una funcionalidad que está bien para según qué aplicaciones pero que para el 99% da igual.
Por eso Google no la quita, aunque lleve años "deprecated"
#9 Desarrollar para Android es varias veces más sencillo que para iOS. Desde el hardware que necesitas para comenzar a trabajar, a la sencillez para obtener certificados, pasando por el lenguaje de programación (Swift - Kotlin pueden andar parejos, pero con iOS a veces terminas necesitando hacer algo en ObjectiveC que es el equivalente al infierno)
Ahora bien, trabajar con cámaras sí es más sencillo en iOS. Android es muy pejillero con el uso de estas y los errores no dan nada de información valiosa.
Una empresa de mi mismo edificio están haciendo su producto con NativeScript y los pobres hacen apuestas para ver quién mantiene el producto en iOS, saben que va a dar fallos increíbles y de muy difícil localización. Es un dolor de muelas.
#1 a veces me pregunto que tienen que ver los comentarios de la gente con la noticia, o si simplemente llegan a aportar algo.
#8 Qué bien! Gracias por compartir esto.
#26 Que bien++! Doble de gracias por dar las gracias.
#1 La alternativa es Instagram, que es el super mal.
Portada récord! En 3mins subida y votada.
No sé Nick...
#2 Estamos en agosto; el algoritmo está de vacaciones o le afecta seriamente la calor.
#2 Si la envié a las 13:23 y es portada a las 17:18
Otra cosa es que me preguntes por mi Master
#2 Fue enviada hace 4 horas y llegó a portada hace 7 minutos.
#4 eso eso. Cómo te sacaste el máster, cuentanos
El fundador fue la persona más joven en hacerse multimillonaria (billioner 1000M de dólares), le hicieron una oferta de compra desde Facebook de 3B y rechazó con 23 años.
#41 Exactamente, te permite tener un proyecto que ya tenías en java y meterle código en Kotlin, viviendo ambos lenguajes para facilitar la transición.
zzz
@onaj
musg0 gracias por la discusión 😃 hacia tiempo que no disfrutaba de una discusión técnica y razonada en Meneame. Lo echaba de menos 😃
#25 ¡Gracias a ti!
Que pasa con todo dios que babea con Kotlin? Qué tiene que lo haga tan especial?
Pregunta hecha desde un ignorante de la programación que lo único que sabe es un poco de Python (Que por cierto, a pesar de algunos defectos que he detectado en ese lenguaje, me encanta y sobre todo su sintaxis limpia)
El otro lenguaje que más o menos me gustaba su sintaxis es Pascal/Delphi.
#32 Te puedo escribir un libro, pero es que soy un friki de Kotlin y poco objetivo.
Piensa que para desarrollar en Android te quedabas en Java 7, por las denuncias entre Oracle y Google las versiones tenían que ser diferentes y el Java de Google no mejoraba.
El gran salto en java fue, seguramente, java 8 con un montón de cosas chulas. A destacar, las lambdas (aunque hace un año salieron unas cuantas características de java8 al java de Android). Eso hacia que los programadores de Android, además de sufrir lo verbose que es, se quedarán atrás en las mejoras de programación.
Cuando llega Kotlin, compilando a las máquinas virtuales de java, le añaden todo lo que le faltaba a java de Android. Y le añade más cosas como los wait-async de ¿Ecmascript7? (No lo recuerdo bien) que son la leche en tema de legibilidad y rendimiento.
Por otro lado, arregla muchos problemas históricos de java. Deja de ser verbose, te hace dto en una línea, te permite hacer clases que no tengan el mismo nombre del archivo, casting inteligente...
Además, aplica la mutabilidad de colecciones y castiga la nulabilidad de parámetros. Dicho de otra forma, siguiendo el libro (de cabecera) "Effective Java" Kotlin castiga a quien hace listas mutables o variables que pueden ser null, por ser inseguro (algo que es null puede hacer un NPR, una lista inmutable siempre tendrá el mismo estado). En definitiva, si quieres hacer código bonito debes hacer código seguro. Y si no, añade "?", "!!" y demás cosas feas
Al final tescribí un libro. Siento el tocho, en según qué cosas me "encanta escucharme".
Edito: perdona , ahora leo que no eres un programador experto, no habrás entendido nada.
Supongo que se puede resumir en que los programadores java sufrían porque el lenguaje les hacía escribir mucho texto, más del necesario, y tenía restricciones absurdas, además de que tardaba en incluir las mejoras de otros lenguajes. Kotlin coloca a los programadores java en la vanguardia y les permite hacer en un par de líneas lo que antes eran diez o quince.
#36 Si, que he entendido bastantes cosas. No soy experto, pero tengo los conceptos teóricos de bastantes cosas que has dicho.
En Python he usado alguna vez alguna función lambda básica, la verdad que muchas veces me cuestan entenderlas.
Cotillee en la Wikipedia y otra cosa que he visto que permite es crear funciones dentro de funciones. En Python eso se usa para crear decoradores, que yo no se si sabría crear un decorador, pero mas o menos entiendo el concepto.
Y si he visto que permite crear funciones fuera de una clase en Kotlin. Lo cual facilita las cosas ya que puede que quieras hacer algo rápido o simple que no necesite encapsulado.
Es decir, conclusión es un Java con baterías, mas o menos. Ya que la sintaxis es diferente pero funciona con la JVM.
Gracias por la respuesta y siempre se aprende.
Genbeta basura weblogsl y sus mierdas de blogs
#17 Cariño, no estás bien; pide ayuda. Con un poco de terapia y medicación podrías pasar por una persona casi normal.