proyecto - manual de programacion android pdf
Estructura de proyecto de Android Studio(frente a la estructura de proyecto de Eclipse) (4)
Estoy tratando de aprender el desarrollo de Android y al principio estoy confundido por las diferentes estructuras de proyecto entre Eclipse y Android Studio. Esto hace que sea difícil seguir los tutoriales diseñados para Eclipse. ¿Alguien podría decirme por qué existen estas diferencias? ¿Deberían existir?
Por ejemplo, si tuviera que ubicar el archivo R.java en los dos IDE diferentes, las rutas se verían así:
Eclipse: app / gen / com.example.app / R.java
Android Studio: app / build / source / r / debug / com.example.app / R.java
¿Por qué estos caminos son diferentes? ¿Por qué mi R.java se encuentra en una carpeta de depuración en Android Studio? Esto condujo a algunos errores desde el principio, y si alguien tiene alguna idea de estas diferencias, las agradecería.
Android Studio: app / build / source / r / debug / com.example.app / R.java
¿Por qué estos caminos son diferentes? ¿Por qué mi R.java se encuentra en una carpeta de depuración en Android Studio? Esto condujo a algunos errores desde el principio, y si alguien tiene alguna idea de estas diferencias, las agradecería.
En pocas palabras, Android Studio está configurado para construir un tipo de compilación de depuración en su sistema.
Eclipse / ADT está diseñado para admitir una única versión a la vez (según lo que puedo decir). Uno de los principales objetivos del nuevo sistema de compilación (a partir de la guía del usuario ):
Make it easy to create several variants of an application,
either for multi-apk distribution or for different flavors of an application
Entonces, como Eclipse / ADT podría generar un archivo R.java , Android Studio es compatible con múltiples. El R.java generado se encuentra en la carpeta de debug porque, de forma predeterminada, el nuevo sistema de compilación admite los tipos de compilación de debug y release del bateador. Si modificó su variante de compilación (botón, esquina inferior izquierda de AS) para liberar AS generará R.java en el directorio de release .
Esto puede no significar nada para proyectos simples, pero el soporte de Build Variants significa una simplificación drástica del proceso de construcción para muchos desarrolladores, incluido el proyecto en el que estoy trabajando.
Nuestro proyecto es compatible con 4 sabores con 2 tipos de compilación (depuración y versión), para admitir un total de 8 combinaciones diferentes de APK. Y cada una de esas combinaciones tiene configuraciones ligeramente diferentes, por lo que este sistema de compilación realmente funcionó para nosotros. Mi estudio android está instalado en una máquina diferente, pero si la memoria me sirve correctamente, el archivo R.java existe en build/source/<flavor>/r/<build type>/package/R.java . Cuando nuestro servidor CI construye los archivos APK, usa cada uno de estos archivos R.java para generar paquetes separados.
Google Suspenderá el soporte para las herramientas de desarrollo de Android (ADT) en Eclipse, según nuestro anuncio. Debería migrar sus proyectos de desarrollo de aplicaciones a Android Studio lo antes posible. Para obtener más información sobre la transición a Android Studio, consulte Migrar a Android Studio.
Lo mejor para la herramienta de desarrollo de Android para Android Studio solo para todas las aplicaciones futuras de Android M ---
El misterio: estructura de proyectos y sistema de compilación de Android Studio
No sé si esto se debe al sistema de compilación Gradle (apostaría a que sí), pero te diré lo que he entendido hasta ahora.
Actualización 4: 2014/09/11 Hoja de trucos añadida para BuildTypes , Flavors y Variants (finalmente me siento seguro de escribir esto: D)
Actualización 3: 2014/09/11 Actualizó los espacios de trabajo y los proyectos de comparación para ser precisos
Actualización 2: 2014/04/17 Se agregaron más detalles a la estructura del proyecto AS
Actualización 1: 2013/07/29 Se agregó la estructura del proyecto IntelliJ
La estructura del proyecto de IntelliJ (que se muestra al final) es para IntelliJ con el complemento de Android. El Android Studio, sin embargo, tiene una estructura de proyecto dividida así:
Estructura: Proyectos y Módulos
módulo en Android Studio es como un proyecto en Eclipse
El proyecto en Android Studio es como un espacio de trabajo en Eclipse (para ser precisos, un espacio de trabajo con proyectos interdependientes)
De la documentación (Android Studio se basa en Intellij IDEA):
Hagas lo que hagas en IntelliJ IDEA, lo haces en el contexto de un proyecto. Un proyecto es una unidad organizativa que representa una solución de software completa.
Su producto final puede descomponerse en una serie de módulos discretos y aislados, pero es una definición de proyecto que los reúne y los vincula en un todo mayor.
Para Android, significa un proyecto por aplicación y un módulo por biblioteca y por aplicación de prueba.
Hay varios problemas si intentas crear varias aplicaciones dentro del mismo proyecto. Es posible, pero si lo intentas (como hice yo), verás que casi todo está diseñado para funcionar con una sola aplicación por proyecto.
Por ejemplo, hay una opción para "reconstruir el proyecto", que no tiene sentido con múltiples aplicaciones, muchas otras configuraciones de proyectos serían inútiles, y el sistema VCS incorporado no es genial cuando tienes múltiples repositorios.
Estructura: Estructura de carpetas
Carpetas de nivel superior
1. Proyecto principal
Este sería el contexto completo del proyecto ( Eclipse Land: como su espacio de trabajo, pero limitado a lo que sea relevante para su proyecto). HelloWorldProject : HelloWorldProject si el nombre de la aplicación que proporcionó fue HelloWorld
2.idea
Aquí donde Android Studio (AS) almacena los metadatos específicos del proyecto. ( Eclipse Land: archivo project.properties )
3. Módulo de proyecto
Este es el proyecto real. ex: HelloWorld si el nombre de tu aplicación que diste fue HelloWorld
4. gradle
Aquí es donde el contenedor jar del sistema de compilación gradle, es decir, este jar, es cómo AS se comunica con gradle instalado en Windows (el sistema operativo en mi caso).
5. Bibliotecas externas
Esto no es en realidad una carpeta sino un lugar donde se muestran las Bibliotecas referenciadas ( Eclipse Land: Bibliotecas referenciadas). Aquí es donde se muestra la plataforma segmentada, etc.
[ Nota al margen: en este caso, muchos de nosotros en Eclipse Land solíamos eliminar las bibliotecas a las que se hace referencia y corregir las propiedades del proyecto para corregir los errores de referencia, ¿recuerdas?]
Carpeta del proyecto en detalle
Este es el número 3 en la lista anterior. Tiene los siguientes subdirectores
1. construir
Esto tiene todo el resultado completo del proceso make , es decir, classes.dex, clases compiladas y recursos, etc.
En la GUI de Android Studio, solo se muestran algunas carpetas. La parte importante es que su R.java se encuentra aquí en build/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
Esta es la carpeta de libs estándar que ves en eclipse también
3. src
Aquí, solo verá la carpeta java y res que corresponde a la carpeta src y la carpeta res en Eclipse Land . Esta es una simplificación muy bienvenida en mi humilde opinión.
Nota sobre los módulos:
Los módulos son como proyectos de Eclipse Land . Aquí la idea es que tenga un proyecto de aplicación (Módulo 3 en la lista anterior) y varios proyectos de biblioteca (como Módulos separados en la carpeta de proyecto global (n. ° 1 en la lista anterior)) de los que depende el proyecto de la aplicación. Cómo estos proyectos de biblioteca se pueden reutilizar en otras aplicaciones, todavía no me he enterado.
[ Nota al margen: toda la reorganización tiene algunos beneficios, como las simplificaciones en la carpeta src, pero hay tantas complicaciones. Las complicaciones se deben principalmente a MUY muy poca documentación sobre este nuevo diseño del proyecto.]
El nuevo sistema de compilación
Guía del usuario para el nuevo sistema de compilación
Explicación de sabores y buildTypes, etc. - ¿De qué se trata el alboroto?
CheatSheet para sabores y buildTypes
BuildType: debug y release son buildTypes disponibles de forma predeterminada en todos los proyectos. Son para compilar / compilar el MISMO CÓDIGO para generar diferentes APK. Por ejemplo, en los APK de release que desee ejecutar proguard (para ofuscación), fírmelo con su clave (en contra de la clave de depuración), ejecute optimizaciones (tal vez a través de proguard u otras herramientas), use packageNames ligeramente diferente (utilizamos com.company.product para release y com.company.product.debug para debug ), etc. También usamos un indicador de depuración ( BuildConfig.DEBUG ) para desactivar el registro en logcat (ya que hace que la aplicación sea lenta) en release de release . Esto permite una compilación de debug más rápida durante el desarrollo, pero también una release optimizada para poner en Play Store.
Sabor del producto: no hay sabores predeterminados disponibles (o para ser precisos, el sabor predeterminado es blanco / sin nombre). Flavors pueden ser versiones gratuitas o de pago, donde tienen un CÓDIGO DIFERENTE . Comparten el mismo Código Main pero diferentes versiones (o ninguna) de algunos archivos de código fuente o recursos.
BuildVariant: buildVariant es a lo que corresponde una APK generada. Se nombran así (en orden) Product Flavor + Build Type Build Variant = Build Variant .
Ejemplo 1: si tiene free y paid como dos sabores. Las variantes de compilación que obtendrías son:
Gratis - depuración
Liberación libre
Pagado - depuración
Pagado - lanzamiento
Entonces eso es 4 configuraciones de APK posibles. Algunas configuraciones pueden no tener sentido en un proyecto en particular, pero están disponibles.
Ejemplo 2: (para proyectos nuevos / sin sabores) Tiene 2 buildVariants o APK disponibles, ya que el sabor predeterminado es sin nombre / en blanco:
depurar
lanzamiento
Compare esto con la estructura del proyecto de Intellij si eso ayuda:
La carpeta .idea (1) contiene varias subcarpetas, principalmente con información interna de IntelliJ IDEA.
La carpeta src (2) contiene el código fuente del archivo MyActivity.java (3) que implementa la funcionalidad de su aplicación. El archivo pertenece al paquete com.example.
La carpeta res (4) contiene varios recursos visuales.
El archivo layout / main.xml (5) define la apariencia de la aplicación constituida por recursos de varios tipos.
La carpeta de valores (6) está destinada a almacenar archivos .xml que describen recursos de varios tipos. Actualmente, la carpeta contiene un archivo strings.xml con definiciones de recursos String. Como verá en la sección Agregar un color, la carpeta de diseño también puede contener, por ejemplo, un descriptor de colores.
La carpeta dibujable (7) contiene imágenes.
La carpeta gen (8) contiene el archivo R.java (9) que vincula los recursos visuales y el código fuente de Java. Como verá en las secciones a continuación, IntelliJ IDEA admite una estrecha integración entre los recursos estáticos y R.java. Tan pronto como se agreguen o eliminen recursos, las clases y los campos de clase correspondientes en R.java se generan automáticamente o se eliminan en consecuencia. El archivo R.java también pertenece al paquete com.example.
Para Android Studio 3.0.1 y todas las características seleccionadas:
- Android O más reciente
- Android Auto
- Cosas de Android
- Desgaste de Android
- Android TV
- Soporte de C ++
- Soporte de Kotlin
La estructura en la versión 3.0.1 no se parece en nada a todas las otras respuestas.
La estructura reciente se muestra en 2018, Android Studio 3.0.1 01/2018.
Newbie un poco encontró algo parecido a usable en la subcarpeta de características:
Actualice su Android Studio 3.0.1 01_2018:
Información sobre herramientas: