Android lezione 13 – A fondo nel manifest

Dopo qualche mese di silenzio, riprendiamo finalmente le lezioni android di italialinux. Questa volta non andremo a  vedere altro codice, ma ci concentremo sul file di Manifest, cercando di spiegare  come comprendere e modificarlo a nostro piacimento. Il file AndroidManifest.xml in realtá è una specie di biglietto da visita dell’applicazione (o forse sarebbe meglio da dire il curriculum 🙂 ), dove specifichiamo tutte le informazioni riguardanti la nostra applicazione, quali:

  • Informazioni di presentazione (quali nome package, versione, numero revisione, etc)
  • Requisiti de sistema android  dell’app
  • Informaizoni grafiche: layout, icona.
  • Informazioni permessi, ovvero a quali servizi la nostra applicazione accede
  • Informazioni riguardanti la struttura delle activity e le azioni alle quali devono rispondere.

Android logo

 

Vedremo uno ad uno, i componenti principali di questo semplice, ma essenziale file per un applicazione android. Partiamo dall struttura del file, come molti altri componenti delle applicazioni android, si tratta di un file in formato xml. Come potremo facilmente intuire la maggior parte delle informazioni relative alla nostra app si trovano all’interno del tag manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="org.italialinux.profilemanager"
    android:versionCode="1"
    android:versionName="1.0">
...</manifest>

Come attributi di questo tag, gia abbiamo alcune informazioni della nostra applicazione:

  • Il nome del package che contiene le classi della nostra applicazione
  • Il version code dell’app, questo numero ad ogni rilascio nel market deve essere incrementato di uno (ovvero non possono esistere due versioni diverse della nostra applicazione con lo stesso version code.
  • VersionName: un identificativo per la versione corrente della nostra applicazione

Ora vediamo cosa andremo a mettere all’ínterno di questo tag: Come prima cosa troviamo i requisiti della nostra appliaczione:

<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="17" />

Dove:

  • android:minSdkVersion indica la versione di android minima per essere eseguita la applicazione. Dove 8 indica la versione 2.2.x, per maggiori ifnormazioni sui numeri di versione vi rimando a questa pagina della doucmentazione ufficiale android http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels
  • Mentre android:targetSdkVersion indica la versione per il quale è stata compilata la nostra app, se omessa viene messo uguale a minSdkVersion. Questo valore può anche essere maggiore di minSdkVersion, in quanto non ne previene la compatibilitá.

La sezione successiva del manifest contiene le informazioni relativi ai permessi utilizzati dalla nostra applicazione. Il formato dei tag è simile al sseguente:

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />

Dove per ogni permesso che vogliamo abilitare inseriremo un tag uses-permission simile al precedente. Ma cosa sono queste permission? (Arrivati a questa lezione probabilmente gia lo saprete, ma cmq ve lo spiego nuovamente, in maniera molto breve). Alcune funzionalitá di android sono accessibili solo se l’utente ne garantisce l’accesso. Per questo dobbiamo dichiarare la nostra intenzione ad usarle nel manifest. Normalmente quando si installa un applicazione dallo store, questo ci avvisa (leggendolo appunto dal manifest) a quali servizi di sistema accederá la nostra app. Da notare che, la mancanza di questi tag nel manifest non causa problemi di compilazione, e l’applicazione funziona fino al momento in cui tenterá di accedere a quella risorsa, a quel punto verrá lanciata un eccezione. Per una lista delle permissions disponibili: http://developer.android.com/reference/android/Manifest.permission.html

A questo punto possiamo passare direttamente alla sezione specifica dell’applicazione, che si trova all’interno dei tags:

<application> ... </application>

All’interno di questi tag andremo ad aggiungere tutte le informazioni che riguardano la “composizione” e “struttura” specifica della nostra applicazione, ovvero:

  • Inseriremo una lista di tutte le activity che la compongono
  • Definiremo eventuali broadcast receiver che definiamo
  • Lo stesso vale per i services
  • e i provider
  • Inoltre per ogni activity/receiver andremo anche a definire degli intent filter (ovvero quali sono le action alla quale la nostra applicazione deve rispondere)
  • Infine fra gli attributi di application andremo ad inserire informazioni quali: l’icona da utilizzare per l’app, l’etichetta, il tema da utilizzare, etc.)

Vediamo ora come è strutturata la sezione dedicata alla definizione di una activity (i receiver e i services hanno una struttura molto simile)

Ogni activity della nostra applizazione ha un corrispondente nel manifest, racchiuso fra i tag <activity></activity>

        <activity
            android:name=".MainActivity"
            android:label="@string/title_activity_main" 
            android:clearTaskOnLaunch="true"
            android:finishOnTaskLaunch="true" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
 
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

Se un activity non viene dichiarata nel manifest, nel momento in cui tenteremo di invocarla dalla nostra applicazione avremo un eccezione a runtime.

La struttura di questi tag è abbastanza semplice:

  • Gli attributi del tag <activity> contengono alcune informazioni di presentazione e di comportamento di questa
  • Mentre la sezione <intent-filter>…</intent-filter> (opzionale), contiene le azioni alle quale la nostra activity dovrá rispondere.

Vediamo ora gli attributi dichiarati in questo esempio:

  • android:name Il nome della classe che rappresenta l’activity (se l’activity si trova in un sotto package, lo dobbiamo definire nel nome)
  • android:label: L’etichetta che contiene il titolo dell’activity.
  • android:clearTaskOnLaunch Si tratta di un valore booleano, Serve per specificare se un activity deve venir rimossa dal task quando passa in secondo piano.
  • android:finishOnTaskLaunch: anche in questo caso si tratta di un booleano, in questo caso indichiamo che ogni volta che l’activity viene lanciata, tutte le istanze esistenti di questa devono venir terminate.

Esistono molti altri attributi da poter specificare in un activity, per controllarne il comportamento, per una lista completa vi rimando qua: http://developer.android.com/guide/topics/manifest/activity-element.html

Mentre come accennato precedentemente, il nodo <intent-filter> serve ad indicare al sistema quali intent accetta la nostra applicazione, se le azioni delle intent non vengono specificate nell’intent-filter queste non vengono consegnate alla nostra applicazione. In questo esempio vediamo che l’azione accettata dalla nostra activity è chiamata:

android.intent.action.MAIN

Che in questo caso indica l’intent di lancio (Ovvero il punto di ingresso della nostra app dall’esterno). Quindi l’activity dell’esempio sará la “schermata principale” della nostra app. Ora si possono definire diverse action per la quale l’activity può rispondere, maggiori informazioni sulle intent le trovate qua: http://developer.android.com/reference/android/content/Intent.html

Per esempio se aveessimo voluto che la nostra activity venisse lanciata anche nel caso di ricevimento di un sms potevamo aggiungere il seguente tag:

Mentre il tag successivo, <category> indica la categoria di intent alla quale la nostra applicazione rispondera, in questo caso CATEGORY_LAUNCHER indica che l’activity sará inclusa nel launcher di sistema della applicazioni.

<action android:name="android.provider.Telephony.SMS_RECEIVED" />

Ovviamente aggiungendo anche la relativa uses-permission.

Una struttura molto simile la abbiamo per i receiver e per i services, quindi eviterò di ripetere le stesse informazioni. Per maggiori informazioni su questi tag, potete partire da qua: http://developer.android.com/guide/topics/manifest/intent-filter-element.html e navigare attraverso gli oggetti elencati nella sezione “Contained in”

Con questo finisco questa lezione, sperando che ora avrete le idee più chiare sul Manifest di una applicazione android. Alla prossima lezione… 😀

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.