Hola,
yo he estado haciendo mis pruebas con Android Studio. La verdad es que me mola muchísimo más (IntelliJ) que Eclipse. Da muchas comodidades a la hora de programar y creo que migraré a Android Studio tan pronto como tenga todo resuelto para mi caso de uso. Os explico.
En mi empresa me encargo de mantener un template de app, que consiste en una app de android que lleva todo configurado: dependencias de las librerías que solemos usar, una pequeña implementación básica, y todo el setup de androidannotations, libs, javadocs, etc etc ya hecho. Luego, con un script bash puedes generar otro proyecto a partir del template especificando la configuración que tú quieres para tu proyecto: nombre de proyecto, package name, app name, facebook id, bugsense id, analytics id, repositorio git, librerías que vas a usar, etc. Igual si le quito las librerías propias de la empresa lo puedo compartir en github si a alguno le interesa.
Este proyecto tiene bastantes cosas que lo hacen tener un setup muy completo que cubre muchas cosas y por tanto una pesadilla de configurar tanto en Eclipse como en Android studio:
- Es multiproyecto, es decir, está el proyecto de la app, el proyecto de los integration tests, el proyecto java del daogenerator (para GreenDao), y los proyectos de librería (Android Library) de los que depende (en este caso, google play services, facebook sdk y volley).
- Lleva también dependecias de librerías Jar, todas ellas con su correspondiente javadoc y sources para que los vea el IDE
- Lleva incluido el annotation processor de AndroidAnnotations. Es decir, que tengo las activities anotadas con @EActivity y demás.
- Es compatible con ambos IDEs (se puede abrir con Eclipse y con Android Studio)
- Es compilable en línea de comandos con ambos build systems (ant y gradle)
En mi afán de hacerlo compatible con Android Studio he conseguido configurarlo para estas situaciones especiales para que compile por gradle (línea de comandos) y Android Studio (cuando le das al botón de Play), aunque en el último update de Android Studio darle al play es lo mismo que compilar con gradle (en la primera versión usaba otro compilador):
- Para que coja bien las dependencias de proyectos de librería (facebook sdk, google play services, ...)
- Para que coja bien dependencias de archivos jar (los metidos en la carpeta libs)
- Para que coja bien dependencias de maven (antes las tenías que meter en el build.gradle pero también ir a mano a meterlas en el IDE porque no las detectaba, con el último update de Android Studio, si añades una dependencia de maven en el build.gradle te la detecta en el IDE a la hora de editar los .java)
- Para que compile bien con las AndroidAnnotations (menudo percal era)
Pero antes de cambiarme a Android Studio, y aquí lanzo las preguntas también a Fernando (¿hablaréis de esto en la charla?), necesito que me funcionen aún algunas cosas para que sea perfecto:
- Todavía no he conseguido que las dependencias de maven declaradas en el build.gradle, se me bajen también los javadoc y sources para poder acceder a ellos desde el Android Studio.
- Todavía no he conseguido (igual con el último update lo han arreglado) que la config de build.gradle que he hecho para que me funcionen los AndroidAnnotations me la coja directamente el IDE, ahora tengo que ir a la config del proyecto desde Android Studio y añadirlo. Hacer dos veces el mismo trabajo no mola.
- El sistema de build gradle tiene cosas tan chulas como poder cambiar para una configuración (debug o release), el sufijo del package name. Así, por ejemplo en la config de debug, puedo hacer que se le añada ".dev" al package name, algo que me viene de lujo en mi empresa. Esto me genera ahora dos problemas que aún no he visto resueltos:
- Por un lado hace que pete el build con AndroidAnnotations, cuando cambia el package name, las clases autogeneradas por androidannotations que importan com.mycompany.myapp.R petan, porque en ellas no se llega a cambiar por com.mycompany.myapp.dev.R.
- Por otro lado, uso GCM para pushes, y al renombrar el package name el sistema de build, no lo renombra en los permisos (en GCM hay que añadir unos permisos que precisamente llevan incluido el package name de la app, el gradle no los cambia ahí, con lo que GCM deja de chutar en el build con .dev de sufijo, esto los de android lo saben y dicen que lo arreglarán, creo que alguien lo preguntó en su keynote)
Si se resuelven estos 3 problemillas que tengo definitivamente me pasaré a Android Studio y le darán por c*** a Eclipse y ant.
Un saludo!