IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Android SDK

Pre-requisits

Instal·lació Java

Usuari:Andrescorazon/Java#Instal.C2.B7laci.C3.B3

Instal·lació

Ens baixem el paquet de la pàgina web oficial i després el descomprimim amb la següent comanda:

$ sudo tar -xvzf android-sdk_r20.0.3-linux.tgz

Podem comprovar que ens hem baixat el paquet correcte amb la comanda md5sum:

$ md5sum android-sdk_r20.0.3-linux.tgz

Tindrem un resultat paregut al següent (depenent de la versió que hem baixat):

0d53c2c31d6b5d0cf7385bccd0b06c27  android-sdk_r20.0.3-linux.tgz

Explorant

SDK Tools

Android SDK Manager

$ ./tools/android
Andrescorazon androidSDKmanager.png


Andrescorazon newAVD.png


Andrescorazon AVDManager.png
$ ./tools/emulator-arm -avd prova
Andrescorazon emuladorprovafuncionant.png

Provant les aplicacions al mòbil

Configurem el mòbil de la següent manera. Primer que tot anem a:

Settings > Applications / Ajustes > Aplicaciones

I activem:

Unknown sources / Orígenes desconocidos

Després anem a:

Settings > Applications > Development / Ajustes > Aplicaciones > Desarrollo

I activem:

USB debugging / Depuración USB

Mirem si amb l'eina adb detecta el dispositiu:

$ cd android-sdks/platform-tools
$ ./adb devices
List of devices attached
????????????	no permissions
emulator-5554	device

Si no tenim permisos, observem la ID del fabricant amb la comanda lsusb, la qual utilitzarem per indicar els permisos a udev:

$ lsusb
...
Bus 001 Device 005: ID 1004:618e LG Electronics, Inc. Ally/Optimus One/Vortex (debug mode)

Creem el següent fitxer i afegim el següent:

$ sudo geany /etc/udev/rules.d/51-android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="1004", MODE="0666", GROUP="plugdev"

Donem els següents permisos al fitxer

$ sudo chmod a+r /etc/udev/rules.d/51-android.rules

Ara, si tornem a connectar el nostre dispositiu, ja el veurem:

$ ./adb devices
List of devices attached
80A358688045431558	device
emulator-5554	device

Amb la comanda adb també podem copiar fitxer o instal·lar paquets a un dispositiu.

Primer que tot ens hem de connectar al dispositiu amb la següent comanda:

$ ./adb connect <ip>

NOTA: Si volem mirar la ip del dispositiu virtual podem usar la comanda netcfg amb el terminal emulator.

Per a instal·lar una aplicació podem usar la següent comanda:

$ ./adb install <path_to_apk>

Per a copiar un arxiu o directori des de l'emulador o el dispositiu podem usar la comanda:

$ ./adb pull <remot> <local>

Aquí tenim un exemple (amb el paràmetre -s triem un dispositiu especific de la llista):

$ ./adb -s 192.168.202.108:5555 pull /sdcard/Download/Term.apk ~/
3545 KB/s (314540 bytes in 0.086s)

Per a copiar un arxiu o directori a l'emulador o el dispositiu podem usar la comanda:

$ ./adb push <local> <remot>

També ens podem connectar al dispositiu per a utilitzar la línia de comandes del dispositiu:

$ ./adb -s <serialNumber> shell

Workflow

Introducció

Els processos de desenvolupament per a les aplicacions de Android.

Andrescorazon workflowintroduction.png
  • Setup. Durant aquesta fase s'instal·la i es configura l'entorn de desenvolupament. També es creen les AVDs i connectem els dispositius on instal·larem les aplicacions.
  • Development. Configurem i desenvolupem el nostre projecte de Android, que conté el codi font i els fitxers de recursos per a les aplicacions.
Com a fase opcional, podem ficar el projecte en un entorn de versions.
  • Debugging and Testing. En aquesta part, generem el projecte en un paquet .apk per a instal·lar-lo i executar-lo en un emulador o en el nostre dispositiu.
A continuació, es depura l'aplicació utilitzant un depurador JDWP compatible amb les eines de el SDK de Android.
Finalment, es prova l'aplicació utilitzant diverses eines de proves del Android SDK.
  • Publishing. Es configura i es construeix l'aplicació per a publicar-la i distribuir-la als usuaris.

App Resources

Una bona aplicació Android és més que només codi. Els recursos d'una aplicació Android (Android App Resources) són els fitxers addicionals que representen el contingut estàtic que el codi utilitzarà (bitmaps, definicions de layouts, strings de la interfície, etc.).

Seguint els típics i aconsellables paradigmes de disseny, és altament recomanable externalitzar els recursos com les imatges o els textos del codi font. Això té múltiples avantatges, per exemple:

  • Suportar diferents configuracions. Per exemple, diferents idiomes o mides de pantalla.
  • Tot això sense haver de fer modificacions del codi per tal d'adaptar l'aplicació a nous possibles dispositius o configuracions fet molt important per que contínuament surten nous dispositius amb noves característiques.

Qualsevol tipus de recurs pot classificar en un dels següents grups:

  • Recursos per defecte (default resources): Són els recursos que s'utilitzaran per defecte independentment de la configuració del dispositiu o quan no s'especifiquen recursos alternatius per a la configuració actual.
  • Recursos alternatius (Alternative resources): són els que es dissenyen per a una configuració específica. Per especificar que un conjunt de recursos són per a una configuració especifica, s'afegeix un sufix al nom de la carpeta on estan els recursos. Aquest sufix es coneix com a configuration qualifier.
Dos dispositius diferents, utilitzant els dos el layout per defecte (la aplicació no té layouts alternatius).
Dos dispositius diferents, utilitzant cadascun un layout diferent per a diferents mides de pantalla.

Com s'explica a l'apartat Estructura d'una aplicació Android, els recursos es guarden a la carpeta res. Vegem un exemple de configuration qualifier:

El layous de la interfície gràfica (layout UI) per defecte es guarda a la carpeta:

res/layout

Però es poden especificar altres layouts per a altres tipus de pantalles, o per exemple per a una orientació horitzontal (landscape):

res/layout-land/

Android automàticament aplica els recursos adequats.

La següents és una taula de les carpetes (segons el tipus de recurs) que us podeu trobar a dins de la carpeta res:

Directory Resource Type
animator/ Fitxers XML que defineixen propietats de lees animacions.
anim/ Fitxers XML que defineixen tween animations.
color/ XML files that define a state list of colors.
drawable/ Bitmap files (.png, .9.png, .jpg, .gif) or XML files that are compiled into the following drawable resource subtypes:
  • Bitmap files
  • Nine-Patches (re-sizable bitmaps)
  • State lists
  • Shapes
  • Animation drawables
  • Other drawables
  • Drawable Resources
layout/ Fitxers XML que defineixen layouts de la interfície gràfica.
menu/ Fitxers XML que defineixen menús d'aplicaciones, com els menús Options Menu, Context Menu, o Sub Menu.
raw/ Aquest és un directori tipus calix de sastre, que permet guardar qualsevol tipus de recurs en cru (raw). Es poden obrir aquests recursos amb com a InputStream, utilitzant Resources.openRawResource() i passant com a paràmetre el resource ID, que és R.raw.filename.
values/ Conté fitxers XML que contenen valors simples, com strings, enters o colors. A diferencia de les altres carpetes on cada fitxers descriu un recurs, aquí s'utilitza un sol fitxers per a tots els recursos del mateix tipus. Es poden posar els noms que es vulguin però es recomana:
  • arrays.xml: per definir vectors de recursos (aka typed arrays).
  • colors.xml: per valors de colors
  • dimens.xml: pre valors de dimensions
  • strings.xml: per a valors de text.
  • styles.xml: per a definir Android styles.
xml/ Permet guardar fixers XML de qualsevol tipus. En temps d'execución aquests fitxers estan disponibles amb Resources.getXML(). Serveix per exemple per guardar fitxers de configuració XML.

Tipus de recursos

Els recursos es poden classificar en recursos compilats i recursos no compilats:

  • Recursos compilats: la majoria de recursos XML de la carpeta res/ es compilen. Per exemple els layouts, els recursos simples de tipus text o el fitxer Manifest són compilats. Al compilar-los en temps d'execució es té un major rendiment al utilitzar-los.
  • Recursos no compilats: En canvi per exemple els fitxers de la carpeta res/raw no es compilen, i cal utilitzar l'API de Streams per a llegir aquests fitxers.

L'eina que compila és Android Asset Packaging Tool (AAPT). Els recursos compilats es posen als fitxers .apk.

Accedint als recursos des del codi

La clase clau per a la gestió de recursos és:

Resources -> http://developer.android.com/reference/android/content/res/Resources.html

Normalment s'obté una implementació d'aquesta clase amb el mètode:

getResources() -> http://developer.android.com/reference/android/content/Context.html#getResources%28%29

Que és de la clase Context, de la que són pare totes les activitats.

El paràmetre més important d'un recurs és el seu Resource ID (identificador del recurs). L'aplicació:

aapt

és l'eina encarregada de crear la classe R (consulteu l'apartat Building & Running). Quan l'aplicació es construida per Eclipse (o manualment o per exemple utilitzant Ant), aapt genera la clase R que conté els identificadors de recursos de tots els recursos de la carpeta res. Per cada recurs hi ha una subclase R (per exemple R.drawable és una subclase amb tots els recursos de tipus R). Per a cada recurs hi ha un static integer que l'identifica, per exemple:

R.drawable.icon

Aquest integer (icon al exemple) és el resource ID.

Tot i que la classe R és on estan tots els IDs especificats, no cal mirar al seu interior per conèixer els IDs, ja que sempre es composen de la següent forma:

  • El tipus de recurs: tots els recursos estan dins d'un tipus com string, drawable o layout.
  • El nom de recurs: sempre coincideix amb el nom del fitxer sense tenir en compte la extensión o en el cas dels values el atribut XML android:name si el recurs és un valor simple.

Hi ha dos formes d'accedir als recursos:

  • Accedir des del codi font: S'utilitza l'especificat anteriorment. Els detalls els trobeu en aquest mateix apartat. Per exemple: R.string.hello és un exemple clar de com obtenir el Resource ID d'un recurs.
  • Accedir des de fitxers XML: s'utilitza una sintaxi especial que s'explica al següent apartat.

Un exemple de com obtenir una recurs de tipus imatge:

ImageView imageView = (ImageView) findViewById(R.id.myimageview);
imageView.setImageResource(R.drawable.myimage);

El pàrametre és de tipus resource ID, tal i com podeu veure a la documentació API:

http://developer.android.com/reference/android/widget/ImageView.html
void 	setImageResource(int resId)
Sets a drawable as the content of this ImageView.

Un altre exemple molt comú és el següent codi:

@Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
  }

Accedir als fitxers originals

Accedint als recursos des de fitxers XML

Dins d'un fitxer XML es poden definir valors XML a els atributs i elements XML fent referencia a recursos Android existents. Per exemple als fitxers de layout XML (que per ells mateixos són també un recurs Android) es típic fer referencia a recursos Android de tipus valor de text (Strings). Un exemple:

<Button
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="@string/submit" />

Aquest extracte d'un fitxer XML de Layout representa un Botó, el text del qual pren el valor del recurs de text @string/submit.

La sintaxi és la següent:

@[<package_name>:]<resource_type>/<resource_name>

On:

  • <package_name>: és un valor opcional que indica el nom del paquet a on es troba el recurs. No cal posar-ho quan s'utilitzant recursos del mateix paquet.
  • <resource_type>: és la subclase de la classe R, o el que coneixem com a tipus de recurs.
  • <resource_name>: és o el nom del fitxer sense la extensió del fitxer que conté el recurs, o en el cas de recursos del tipus valor simple el valor de l'atribut android:name.

Localització

IMPORTANT: Recordem que la localització és molt més que la traducció a diferents llengues d'una aplicació. Per a més informació, consultar l10n i i18n.

Traduir és proveir d'un recurs alternatiu de tipus String.

Sempre és una bona idea separar els textos (Strings) de la interfície gràfica de l'aplicació del codi, mantenint estos textos en fitxers específics de forma que es faciliti la traducció.

Els Recursos Android i concretament els recursos de tipus string facilitant la tasca de la localització.

Dispositius

Screen Densities

Segurament la millor forma d'entendre el concepte de densitat de pantalla és comparar-ho amb la resol·lució s'indica com el nombre de píxels totals que hi ha a una pantalla (per exemple 1024x800). En canvi, la densitat és quan píxels apareixen per a una unitat constant d'espai.

Si s'incrementa la resol·lució i la densitat al mateix temps la mida es manté. Aquesta és la raó per la que un G1 amb una pantalla de 320x480 i una pantalla de 480x800 d'un Droid tenen la mateixa mida.

Conceptes

  • Screen size: la mida real de la pantalla, normalment es mesura segons la diagonal de la pantalla. A Android s'agrupen les mides de pantalla en els següents conjunts: small, normal, large i extra large.
  • Screen density: Mesura la qualitat dels píxels per una unitat concreta de mesura. Normalment s'utilitza el terme dpi (dots per inch). Per exemple, una pantalla de baixa densitat té menys píxels donada un àrea concreta. Per simplicitat hi ha els següents grups: low, medium, high i extra high.
  • Orientació: l'orientació de la pantalla, des del punt de vista de l'usuari, pot ser landscape o portrait.
  • Resolution: és el número total de píxels físics a una pantalla. Quan s'afegeix suport per múltiples pantalles, les aplicacions no treballen directament amb la resol·lució, és a dir només s'han de preocupar de la mida de la pantalla i de la densitat.
  • Density-independent pixel (dp): Una unitat de píxel virtual que s'ha d'utilitzar al definir el layout de la UI per tal d'utilitzar-la a les mides de dimensions o posicions d'una forma independent a la densitat utilitzada. El dp és equivalent a un píxel en la mida base: 160 dpi screen. Tota la resta són relatives a aquesta base. En temps d'execució automàticament i de forma transparent es fa la conversió de dp virtual a píxel físic:
px = dp * (dpi / 160).

Per exemple en una pantalla de 240 dpi, 1dp equival a 1.5 pixels físics.

Els grups generals s'obtenen a partir de la següent gràfica:

Andrescorazon android screens ranges.png

El que si que hi ha és unes característiques mínimes per pertanyer a un grup o a un altre:

  • xlarge screens are at least 960dp x 720dp
  • large screens are at least 640dp x 480dp
  • normal screens are at least 470dp x 320dp
  • small screens are at least 426dp x 320dp

La següent imatge mostra les relacions entre bitmaps depenen de la densitat:

Andrescorazon android screens densities.png

La següent és una llista de les millors pràctiques a seguir:

  • Utilitzeu wrap_content, fill_parent, o unitat ens dps quan s'especifiquen les dimensions en un layout XML.
  • No utilitzar mai valors hardcoded de pixels en el codi.
  • No utilitzar mai AbsoluteLayout (deprecated).
  • Per cada imatge cal proporcionar bitmap drawables per a cada densitat de pantalla.

Building & Running

La següent gràfica mostra el procediment resumit de construcció i execució de les aplicacions Android i els components que intervenen:

Andrescorazon build android app simplified.png

El següent gràfic mostra el procés detallat:

Andrescorazon build android app.png

Durant el procés de construcció de l'aplicació, els projectes Android són compilats en fitxers .apk, que són els contenidors o paquets on s'emmagatzema el codi binari de l'aplicació Android. El paquet conté tota la informació necessària per tal d'executar l'aplicació en un dispositiu o un emulador.

Dins d'un paquet Android cal trobar:

Si s'utilitza Eclipse, el Plugin ADT construeix l'aplicació de forma incremental a mesura que es fan canvis al codi font. Eclipse crea automàticament un fitxer apk i el guarda a la carpeta bin del projecte.

Si no s'utilitza Eclipse, es pot construir el projecte amb Ant i un fitxer build.xml.

Al crear un apk s'ha de marcar com debug mode o release mode. El debug mode és el més utilitzat quan es desenvolupa però al publicar l'aplicació (per exemple Google Play) s'han de signar utilitzant una clau privada.

El procés general és:

  • L'eina Android Asset Packaging Tool (aapt) agafa els App Android Resources com per exemple el fitxer AndroidManifest.xml i la resta de fitxers XML de les activitats i les compila. També es crea la clase R.java per tal de que es pugui utilitzar al codi Java.
  • L'eina aidl converteix qualsevol interfície .aidl en interfície Java.
  • Tot el codi, incloent el propi, la classe R.java i els fitxers aidl són compilats pel compilador Java.
  • L'eina dex converteix els fitxers .class a fitxers .hex (Dalvik byte code). Totes les llibreries de tercers i fitxers .class inclosos també són convertits a .hex i empaquetats al fitxer final apk.
  • Tots els recursos no compilats (p.ex. les imatges), i també els fitxers .dex són enviats a l'eina apkbuilder per tal que crei el apk.
  • Un cop el apk s'ha creat es signa.
  • Si l'aplicació es signa en release mode, aleshores s'utilitza l'eina zipalign. Això permet disminuir el ús de memòria quan l'aplicació s'executa a un dispositiu real.

A continuació tenim com a exemple el contingut d'un paquet .apk on podem veure els tipus de fitxers anomenats anteriorment:

Andrescorazon Exemple contingut apk.png
  • La carpeta META-INF conte arxius compilats relacionats amb la signatura de l'aplicació.
  • La carpeta res tenim els recursos no complilats (les imatges per exemple).
  • El fitxer classes.dex correspon al fitxer complilat .dex (els fitxers .class de Java adaptats a la màquina virtual Dalvik).
  • El fitxer resources.arsc correspon als recursos compilats.
  • També tenim una còpia no compilada del fitxer AndroidManifest.xml.

Vegeu també

Enllaços externs