PDM Creando proxecto base

De MediaWiki
Ir a la navegación Ir a la búsqueda

Creando un proxecto Base

Nota: No curso 2018-2019, o emulador Android API 28 reiníciase continuamente.

Recomendo facer as prácticas cun emulador API 27 a no ser que os problemas foran amañados.



  • En cada unidade imos crear un paquete diferente dentro o mesmo proxecto.
En cada paquete iremos poñendo as diferentes activities creadas.


  • Crea un novo proxecto:
  • Indicamos que imos desenvolver unha aplicación para móbil.
  • Escollemos unha dos padróns. No exemplo será unha pantalla en branco.
PDM Activity 17.jpg


  • Nome da aplicación: Aprendiendo.
  • Nome do paquete: cifprodolfoucha.cursoandroid.aprendiendo
  • Cartafol onde se garda o proxecto: Podemos deixar o que trae por defecto.
  • Language: Java
  • Min API Level: 19
PDM Activity 18.jpg
Prememos o botón Finish.



  • Datos do arquivo build.gradle a nivel de módulo (pode ser que teñades outras versións dependendo da versión do Android Studio instalada):
  • MinSDK: 19
  • Target_SDK: 27
  • Compile_SDK: 27
  • Build Toos: 28
Nota: Lembrade que ditas opcións poden cambiarse graficamente na ventá do 'Proyect Structure' como xa vimos anteriormente.
PDM Activity 0.jpg


  • Ao longo do curso, crearanse diferentes paquetes (ven ser como subdirectorios).
Vexamos un exemplo de como crear un novo paquete de nome tiposactivities' (é un exemplo)
Deixa a lo menos unha activity no paquete inicial, xa que se non a nivel gráfico o Android Studio o fai desaparecer.
Agora, premendo o botón dereito sobre o novo paquete podemos crear novas activities que irán nel.
En calquera momento podemos mover activities dun paquete a outro (arrastrando có rato) pero ao facelo aparecerá unha ventá na que teremos que escoller a opción Refactor.



  • Aínda que non está indicado nas diferentes activities creadas, cada vez que se cre unha activity de tipo launcher modificaremos o arquivo AndroidManifiest.xml para darlle un label a cada unha delas. O dato do label será o mesmo que o nome da activity. Isto o facemos para poder identificala dentro do emulador/dispositivo se imos á pantalla onde se ven todas as aplicacións instaladas:
1         <activity android:name=".UI.UD02_01_ConstraintLayout"
2                   android:label="UD02_01_ConstraintLayout" >
3             <intent-filter>
4                 <action android:name="android.intent.action.MAIN" />
5                 <category android:name="android.intent.category.LAUNCHER" />
6             </intent-filter>
7         </activity>
Neste caso a activity está nun paquete de nome UI, pero o nome da activity é: UD02_01_ConstraintLayout
Se executamos esta aplicación:



Nome das clases e layouts



Cartafoles nun proxecto Android

A continuación imos ver os contidos dos distintos cartafoles que compoñen un proxecto.

/app/

  • É o nome do módulo da aplicación.
  • Un módulo ven ser un conxunto de arquivos dunha aplicación (activities, layouts,...) e arquivos de configuración do Android Studio e da aplicación.
  • Un módulo pode depender doutro para a súa execución ou poden ser totalmente independentes.
  • Por defecto, cando creamos un proxecto AndroidStudio, crea un módulo de nome 'app'.

Máis información neste enlace.

/app/java

Nota: Ven ser no que en Eclipse era /src/. Veremos mais adiante que podemos cambiar a 'vista' de como se visualiza o proxecto e volver a ter o cartafol /src/.

/app/res

  • Cartafol /app/res (Resources/Recursos): almacena todos os ficheiros de recursos necesarios para a aplicación: imaxes, vídeos, ficheiros xml, animacións, ficheiros para a internacionalización, etc.
  • Importante: Todo o que se atopa dentro do cartafol /res/ ten que ter letras minúsculas e só poden conter letras, números e _ .Se se pon outro carácter o proxecto dará un erro de compilación.


PDM UD1 Estrutura 3.jpg


  • /app/res/drawble: Almacena as imaxes da aplicación en función da densidade (dpi) do dispositivo de destino. En Android veremos que podemos ter diferentes resolucións de imaxes para que a aplicación se vexa correctamente en dispositivos de tamaños e resolucións diferentes. Estas imaxes gardaríanse dentro dun cartafol de nome 'drawble-sufixo' no que o sufixo indicará con un código a que tipo de dispositivo debe cargarse as imaxes que estean dentro do cartafol. Por exemplo, o cartafol '/res/drawable-large' tería imaxes que se cargaría con dispositivo de entre 4 e 7 polgadas aproximadamente (observar imaxe).
  • /app/res/layout: Almacena os ficheiros xml onde se definen os elementos gráficos e a súa disposisición, das distintas pantallas que compoñen a aplicación. Igual que no caso anterior tamén imos poder ter diferentes sufixos para cargar layouts en función dos dispositivos. Así, por exemplo, se creamos o cartafol /app/res/layout-land cargaríamos os layouts que estean dentro deste cartafol cando teñamos o dispositivo en posición 'apaisada', é dicir, tumbado.
  • /app/res/mipmap: Almacena a icona que vai representar a aplicación cando estea instalada nun dispositivo. Ven ser a icona de lanzamento. Pódese ver na imaxe que indica que hai 5 iconas. Isto é así xa que crea unha por cada tipo de densidade. A densidade a veremos máis adiante pero ven ser o número de puntos por pulgada que ten o dispositivo. Fisicamente temos un cartafol por cada unha das densidades e dentro de cada cartafol temos o arquivo a cargar, o que pasa que AndroidStudio oculta os cartafoles. Podemos ver ese cartafoles se cambiamos a vista a 'Proyect' como veremos posteriormente.
  • /app/res/values: Almacena constantes que definen: cadeas de texto, estilos, cores, dimensións, etc.
  • dimens.xml Están declaradas as dimensións que se usaban no layout.
  • strings.xml Están declaradas cadeas de texto. A última é usada no layout, logo veremos onde se usan as demais.
  • colors.xml Están declaradas constantes que representar unha cor.
  • styles.xml Están declaradas constantes que representan estilos (como se van representar os elementos gráficos e as activities, como podan ser a combinación de cores, negrilla, cursiva, se vai ter menú,...)
  • Hai máis arquivos e cartafoles para xa o iremos vendo.

Nota: Todos son arquivos de configuración son XML que poden ser editados. Máis información neste enlace.

/assets

  • Contén o resto de ficheiros que se precisen para a aplicación: ficheiros de configuración, de datos, bases de datos,etc... Para acceder a estes recursos non se fai a a través da clase R senón que se fai a través da súa ruta no sistema.
  • No Android Studio o cartafol 'assets' non se atopa creado por defecto. Para crealo temos que ir ao módulo /app/ e premendo o botón dereito escoller a opción New => Folder => Assets Folder como se va na seguinte imaxe:
PDM UD1 Estrutura 4.jpg


Arquivo AndroidManifest.xml

  • Contén a definición das características máis importantes da aplicación: nome, versión, icona, activities, servizos, instrumentación, permisos de acceso aos recursos, etc.
PDM UD1 Estrutura 5.jpg
  • Na imaxe se pode ver entre outros datos:
  • Nome da icona a cargar (fai referencia a unha icona que se atopa en /app/res/mipmaps/
  • Nome da aplicación que está definido nunha constante no arquivo /res/values/strings.xml. Ven ser o nome que aparece asociado a icona da aplicación.
  • O aspecto que vai ter a aplicación (ven ser coma un arquivo CSS de HTML). Se atopa no arquivo /res/values/styles.xml.
  • As activities que conforman o proxecto. Inicialmente so temos unha.

Identificar o minSDK, targetSDK e buildSDK

  • Anteriormente en Eclipse, dentro do arquivo AndroidManifest.xml tamén ían as liñas que indicaban o targetSDK e minSDK.
Estes conceptos (polo menos un deles) o vimos no proceso de creación do proxecto Ola Mundo. Se vos fixaches no paso un, indicabamos o minSDK no que ía funcionar a nosa aplicación.


  • Como comentamos anteriormente, a API vai determinar a versión do S.O. no que imos desenvolver a aplicación.
Cada nova versión incorpora novos compoñentes gráficos e novas funcionalidades, pero temos que manter un equilibrio entre a versión a escoller e omercado que queiramos acaparar.
  • A API tamén vai determinar que aplicacións poden ser instaladas no dispositivo móbil, xa que unha aplicación desenvolvida para unha versión superior non pode ser instalada nun S.O. Android cunha versión inferior.
  • Á hora de determinar a API nun proxecto Android teremos que escoller o seguinte:
  • MIN SDK: Será a API mínima (versión do S.O. Android) no que a nosa aplicación poderá funcionar. Non se poderá instalar nunha versión anterior.
  • TARGET SDK: Indica que versión do S.O. Android no que está probada a nosa aplicación e sabemos que funciona correctamente. Normalmente ponse a máis alta. Podería funcionar nunha versión posterior ou inferior (sempre que sexa maior que o minSdk). O uso dun target ou outro pode influír no aspecto da nosa aplicación en tempo de execución (por exemplo, pode cambiar o theme ou aspecto por defecto, en función do target)
  • BUILD SDK ou Compile SDK: Indica a versión do SDK que utilizamos para compilar a nosa aplicación. Isto vai limitar os recursos que podamos empregar no desenvolvemento da aplicación, xa que se por exemplo, temos unha nova funcionalidade nun API por exemplo, na API 22, e nos temos marcado un BUILD_SDK de 19, non poderemos facer uso del. O build_sdk sempre terá que ser maior o igual ao min_sdk.
Normalmente se segue a regra: minSdkVersion (mínima posible) <= targetSdkVersion == compileSdkVersion (máis alta posible SDK)



Nota: Estes datos se poden definir no arquivo AndroidManifiest.xml, pero se están nos dous sitios, terá preferencia (sobreescribe) o que se atope no arquivo build.gradle.