Concetti fondamentali dell'applicazione

Le app Android possono essere scritte utilizzando Kotlin, il linguaggio di programmazione Java e i linguaggi C++. Gli strumenti SDK Android compilano il codice insieme a eventuali file di dati e risorse in un APK o un Android App Bundle.

Un pacchetto Android, ossia un file di archivio con suffisso .apk, include i contenuti di un'app Android richiesta in runtime ed è il file utilizzato dai dispositivi Android per installare l'app.

Un Android App Bundle, ossia un file di archivio con un suffisso .aab, include i contenuti di un progetto di app Android, inclusi alcuni metadati aggiuntivi che non sono necessari in fase di runtime. Un AAB è un formato di pubblicazione e non può essere installato sui dispositivi Android. Rimanda la generazione degli APK e la firma a una fase successiva.

Ad esempio, se distribuisci la tua app tramite Google Play, i server di Google Play generano APK ottimizzati contenenti solo le risorse e il codice richiesti dal dispositivo specifico che richiede l'installazione dell'app.

Ogni app Android si trova nella propria sandbox per la sicurezza, protetta dalle seguenti funzionalità di sicurezza Android:

  • Il sistema operativo Android è un sistema Linux multiutente in cui ogni app è un utente diverso.
  • Per impostazione predefinita, il sistema assegna a ogni app un ID utente Linux univoco, che viene utilizzato solo dal sistema e sconosciuto all'app. Il sistema imposta le autorizzazioni per tutti i file in un'app in modo che solo l'ID utente assegnato all'app possa accedervi.
  • Ogni processo ha la propria macchina virtuale (VM), quindi il codice di un'app viene eseguito in modo isolato da altre app.
  • Per impostazione predefinita, ogni app viene eseguita nel proprio processo Linux. Il sistema Android avvia il processo quando è necessario eseguire uno qualsiasi dei componenti dell'app, quindi arresta il processo quando non è più necessario o quando il sistema deve recuperare memoria per altre app.

Il sistema Android implementa il principio del privilegio minimo. In altre parole, ogni app, per impostazione predefinita, ha accesso solo ai componenti necessari per svolgere il proprio lavoro e niente altro. Ciò crea un ambiente molto sicuro in cui un'app non può accedere a parti del sistema per cui non ha l'autorizzazione.

Tuttavia, un'app ha diversi modi per condividere dati con altre app e per un'app per accedere ai servizi di sistema:

  • È possibile fare in modo che due app condividano lo stesso ID utente Linux, nel qual caso saranno in grado di accedere reciproche ai file. Per risparmiare risorse di sistema, le app con lo stesso ID utente possono anche essere in grado di essere eseguite nello stesso processo Linux e condividere la stessa VM. Anche le app devono essere firmate con lo stesso certificato.
  • Un'app può chiedere l'autorizzazione ad accedere a dati del dispositivo quali la posizione, la fotocamera e la connessione Bluetooth del dispositivo. L'utente deve concedere esplicitamente queste autorizzazioni. Per ulteriori informazioni sulle autorizzazioni, vedi Autorizzazioni su Android.

Il resto del documento introduce i seguenti concetti:

  • I componenti principali del framework che definiscono l'app.
  • Il file manifest in cui dichiari i componenti e le funzionalità del dispositivo necessarie per la tua app.
  • Risorse separate dal codice dell'app e che consentono all'app di ottimizzare il suo comportamento per una varietà di configurazioni di dispositivi.

Componenti dell'app

I componenti delle app sono i componenti di base essenziali di un'app Android. Ogni componente è un punto di ingresso tramite il quale il sistema o un utente può accedere all'app. Alcuni componenti dipendono da altri.

Esistono quattro tipi di componenti dell'app:

  • Attività
  • Servizi
  • Ricevitori di trasmissioni
  • Fornitori di contenuti

Ogni tipo ha uno scopo distinto e ha un ciclo di vita distinto che definisce le modalità di creazione ed eliminazione di un componente. Le sezioni seguenti descrivono i quattro tipi di componenti dell'app.

Attività
Un'attività è il punto di contatto per interagire con l'utente. Rappresenta una singola schermata con un'interfaccia utente. Ad esempio, un'app email potrebbe avere un'attività che mostra un elenco di nuove email, un'altra attività per scrivere un'email e un'altra attività per la lettura delle email. Sebbene le attività funzionino insieme per creare un'esperienza utente coerente nell'app email, ognuna è indipendente dalle altre.

Un'altra app può avviare una qualsiasi di queste attività, se l'app email lo consente. Ad esempio, un'app fotocamera potrebbe avviare l'attività nell'app email per scrivere una nuova email e consentire all'utente di condividere una foto.

Un'attività favorisce le seguenti interazioni chiave tra il sistema e l'app:

  • Tenere traccia di ciò che interessa attualmente all'utente, ovvero ciò che viene visualizzato sullo schermo, in modo che il sistema continui a eseguire il processo che ospita l'attività.
  • Sapere quali processi utilizzati in precedenza contengono attività interrotte a cui l'utente potrebbe tornare e assegnare una priorità maggiore a questi processi per mantenerli disponibili.
  • Aiuta l'app a gestire l'interruzione del processo in modo che l'utente possa tornare alle attività ripristinando lo stato precedente.
  • Offre alle app un modo per implementare i flussi utente tra loro e al sistema di coordinarli. L'esempio principale è la condivisione.

Implementi un'attività come sottoclasse della classe Activity. Per maggiori informazioni sul corso Activity, consulta Introduzione alle attività.

Servizi
Un servizio è un punto di contatto generico che consente di mantenere un'app in esecuzione in background per tutti i tipi di motivi. È un componente che viene eseguito in background per eseguire operazioni a lunga esecuzione o per lavorare per processi remoti. Un servizio non fornisce un'interfaccia utente.

Ad esempio, un servizio potrebbe riprodurre musica in background mentre l'utente si trova in un'altra app oppure recuperare dati tramite la rete senza bloccare l'interazione dell'utente con un'attività. Un altro componente, ad esempio un'attività, può avviare il servizio e lasciarne l'esecuzione o l'associazione per interagirvi.

Esistono due tipi di servizi che indicano al sistema come gestire un'app: i servizi avviati e i servizi associati.

I servizi avviati indicano al sistema di mantenerli in esecuzione fino al completamento del lavoro. Potrebbe essere necessario sincronizzare alcuni dati in background o riprodurre musica anche dopo che l'utente è uscito dall'app. La sincronizzazione dei dati in background o la riproduzione di musica rappresentano diversi tipi di servizi avviati, che il sistema gestisce in modo diverso:

  • La riproduzione di musica è qualcosa di cui l'utente è direttamente a conoscenza e l'app comunica ciò al sistema indicando che vuole essere in primo piano, con una notifica per comunicare all'utente che è in esecuzione. In questo caso, il sistema dà la priorità a mantenere il processo del servizio in esecuzione, perché l'utente ha un'esperienza negativa se scompare.
  • L'utente non è a conoscenza direttamente di un normale servizio in background, pertanto il sistema ha maggiore libertà nella gestione del processo. Potrebbe essere interrotto, riavviando il servizio in un secondo momento, se ha bisogno di RAM per attività di interesse più immediato per l'utente.

I servizi associati vengono eseguiti perché un'altra app (o il sistema) ha dichiarato di voler utilizzare il servizio. Un servizio associato fornisce un'API a un altro processo e il sistema sa che esiste una dipendenza tra questi processi. Quindi, se il processo A è associato a un servizio nel processo B, il sistema sa che deve mantenere il processo B e il suo servizio in esecuzione per A. Inoltre, se l'utente è interessato al processo A, sa che deve trattare il processo B come un aspetto che interessa anche all'utente.

Grazie alla loro flessibilità, i servizi sono componenti di base utili per tutti i concetti di sistema generale. Sfondi animati, ascoltatori delle notifiche, salvaschermi, metodi di immissione, servizi di accessibilità e molte altre funzioni principali del sistema sono tutti creati come servizi che le applicazioni implementano e a cui il sistema si associa quando vengono eseguite.

Un servizio viene implementato come sottoclasse di Service. Per ulteriori informazioni sulla classe Service, consulta la panoramica dei servizi.

Nota: se la tua app ha come target Android 5.0 (livello API 21) o versioni successive, utilizza la classe JobScheduler per pianificare le azioni. JobScheduler ha il vantaggio di risparmiare batteria pianificando in modo ottimale i job per ridurre il consumo di energia e lavorando con l'API Doze. Per ulteriori informazioni sull'utilizzo di questa classe, consulta la documentazione di riferimento di JobScheduler.

Ricevitori di trasmissioni
Un ricevitore di trasmissione è un componente che consente al sistema di inviare eventi all'app al di fuori del normale flusso di utenti, in modo che l'app possa rispondere agli annunci di trasmissione a livello di sistema. Poiché i ricevitori sono un altro strumento ben definito per l'app, il sistema può inviare trasmissioni anche ad app non attualmente in esecuzione.

Ad esempio, un'app può programmare una sveglia per pubblicare una notifica e informare l'utente di un evento imminente. Poiché la sveglia viene inviata a un numero BroadcastReceiver nell'app, non è necessario che l'app rimanga in esecuzione fino a quando l'allarme non suona.

Molte trasmissioni provengono dal sistema, ad esempio un annuncio che annuncia che lo schermo è spento, che la batteria è in esaurimento o che viene acquisita una foto. Le app possono anche avviare trasmissioni, ad esempio per comunicare ad altre app che alcuni dati vengono scaricati sul dispositivo e possono essere utilizzati.

Anche se i ricevitori non mostrano un'interfaccia utente, possono creare una notifica nella barra di stato per avvisare l'utente quando si verifica un evento di trasmissione. Tuttavia, più comunemente, un ricevitore di trasmissione è solo un gateway per altri componenti ed è progettato per svolgere un lavoro minimo.

Ad esempio, un ricevitore di trasmissione potrebbe programmare un JobService per eseguire alcune operazioni in base a un evento utilizzando JobScheduler. I ricevitori di trasmissioni spesso coinvolgono le app che interagiscono tra loro, quindi è importante essere consapevoli delle implicazioni di sicurezza durante la loro configurazione.

Un ricevitore di trasmissione è implementato come una sottoclasse di BroadcastReceiver e ogni trasmissione viene pubblicata come oggetto Intent. Per ulteriori informazioni, consulta il corso BroadcastReceiver.

Fornitori di contenuti
Un fornitore di contenuti gestisce un set condiviso di dati dell'app che puoi archiviare nel file system, in un database SQLite, sul web o in qualsiasi altra posizione di archiviazione permanente a cui può accedere la tua app. Tramite il fornitore di contenuti, altre app possono interrogare o modificare i dati, se il fornitore di contenuti lo consente.

Ad esempio, il sistema Android fornisce un fornitore di contenuti che gestisce le informazioni di contatto dell'utente. Qualsiasi app dotata delle autorizzazioni appropriate può eseguire query sul fornitore di contenuti, ad esempio utilizzando ContactsContract.Data, per leggere e scrivere informazioni su una determinata persona.

Si è tentati di pensare a un provider di contenuti come a un'astrazione su un database, perché nel caso comune sono presenti molte API e supporto integrato. Tuttavia, hanno uno scopo principale diverso dal punto di vista della progettazione del sistema.

Per il sistema, un fornitore di contenuti è un punto di ingresso in un'app per la pubblicazione di elementi di dati denominati, identificati da uno schema URI. Pertanto, un'app può decidere come mappare i dati che contiene a uno spazio dei nomi URI, distribuendo gli URI ad altre entità che a loro volta possono utilizzarli per accedere ai dati. Il sistema può gestire un'app in diversi modi:

  • L'assegnazione di un URI non richiede che l'app rimanga in esecuzione, quindi gli URI possono restare inalterati dopo l'uscita delle app proprietarie. Il sistema deve solo assicurarsi che un'app proprietaria sia ancora in esecuzione quando recupera i dati dell'app dall'URI corrispondente.
  • Questi URI forniscono anche un importante modello di sicurezza granulare. Ad esempio, un'app può inserire l'URI di un'immagine che ha negli appunti, ma lasciare bloccato il fornitore di contenuti in modo che altre app non possano accedervi liberamente. Quando una seconda app tenta di accedere all'URI negli appunti, il sistema può consentire all'app di accedere ai dati utilizzando una concessione di autorizzazioni URI temporanea, in modo da accedere ai dati solo dietro quell'URI e nient'altro nella seconda app.

I fornitori di contenuti sono utili anche per leggere e scrivere dati privati per la tua app e non condivisi.

Un fornitore di contenuti è implementato come una sottoclasse di ContentProvider e deve implementare un set standard di API che consentano ad altre app di eseguire transazioni. Per ulteriori informazioni, consulta la guida per gli sviluppatori relativa ai fornitori di contenuti.

Un aspetto unico della progettazione del sistema Android è che ogni app può avviare il componente di un'altra app. Ad esempio, se vuoi che l'utente scatti una foto con la fotocamera del dispositivo, probabilmente esiste un'altra app che lo fa e la tua app può utilizzarla invece di sviluppare un'attività per scattare la foto in prima persona. Non devi incorporare o persino collegare il codice dall'app Fotocamera. Puoi invece avviare l'attività nell'app della fotocamera che acquisisce una foto. Una volta completata, la foto viene persino restituita all'app per poterla utilizzare. All'utente sembra che la fotocamera faccia effettivamente parte della vostra app.

Quando il sistema avvia un componente, avvia il processo per quell'app, se non è già in esecuzione, e crea un'istanza delle classi necessarie per il componente. Ad esempio, se l'app avvia l'attività nell'app Fotocamera che scatta una foto, l'attività viene eseguita nel processo appartenente all'app Fotocamera, non nel processo dell'app. Di conseguenza, a differenza delle app sulla maggior parte degli altri sistemi, le app Android non hanno un singolo entry point: non esiste una funzione main().

Poiché il sistema esegue ogni app in un processo separato con autorizzazioni dei file che limitano l'accesso ad altre app, l'app non può attivare direttamente un componente da un'altra app, ma il sistema Android può farlo. Per attivare un componente in un'altra app, devi inviare al sistema un messaggio che specifica il tuo intent per avviare un determinato componente. Il sistema attiva il componente per te.

Attiva componenti

Un messaggio asincrono chiamato intent attiva tre dei quattro tipi di componenti: attività, servizi e ricevitori di trasmissione. Gli intent associano tra loro singoli componenti in fase di runtime. Possono essere considerati come i messaggeri che richiedono un'azione da altri componenti, indipendentemente dal fatto che il componente appartenga alla tua app o a un'altra.

Un intent viene creato con un oggetto Intent, che definisce un messaggio per attivare un componente specifico (un intent esplicito) o un tipo specifico di componente (un intent implicito).

Per attività e servizi, un intent definisce l'azione da eseguire, ad esempio visualizzare o inviare qualcosa, e potrebbe specificare l'URI dei dati su cui agire, tra le altre cose che il componente avviato potrebbe dover essere a conoscenza.

Ad esempio, un intent potrebbe trasmettere una richiesta di un'attività per mostrare un'immagine o aprire una pagina web. In alcuni casi, puoi avviare un'attività per ricevere un risultato. In questo caso l'attività restituisce anche il risultato in un Intent. Puoi anche emettere un intent per consentire all'utente di scegliere un contatto personale e di restituirlo. L'intent di ritorno include un URI che rimanda al contatto scelto.

Per i ricevitori, l'intent definisce l'annuncio di trasmissione. Ad esempio, un annuncio trasmesso per indicare che la batteria del dispositivo è in esaurimento, include solo una stringa di azioni nota che indica che la batteria è in esaurimento.

A differenza di attività, servizi e ricevitori di trasmissioni, i fornitori di contenuti vengono attivati quando vengono scelti come target da una richiesta di un ContentResolver. Il sistema di risoluzione dei contenuti gestisce tutte le transazioni dirette con il fornitore di contenuti e il componente che esegue le transazioni con il fornitore chiama i metodi sull'oggetto ContentResolver. Questo lascia un livello di astrazione per motivi di sicurezza tra il fornitore di contenuti e il componente che richiede le informazioni.

Esistono diversi metodi per attivare ciascun tipo di componente:

  • Puoi iniziare un'attività o impartire qualcosa di nuovo passando un Intent a startActivity() oppure, quando vuoi che l'attività restituisca un risultato, startActivityForResult().
  • Su Android 5.0 (livello API 21) e versioni successive, puoi utilizzare la classe JobScheduler per pianificare le azioni. Per le versioni precedenti di Android, puoi avviare un servizio o dare nuove istruzioni a un servizio in corso trasferendo Intent a startService(). Puoi eseguire l'associazione al servizio passando un Intent a bindService().
  • Puoi avviare una trasmissione passando un Intent a metodi quali sendBroadcast() o sendOrderedBroadcast().
  • Puoi eseguire una query a un fornitore di contenuti chiamando query() su un ContentResolver.

Per ulteriori informazioni sull'utilizzo degli intent, consulta il documento Intent e filtri di intent. I seguenti documenti forniscono ulteriori informazioni sull'attivazione di componenti specifici: Introduzione alle attività, Panoramica dei servizi, BroadcastReceiver e Fornitori di contenuti.

Il file manifest

Prima che il sistema Android possa avviare un componente dell'app, deve sapere che il componente esiste leggendo il file manifest dell'app (AndroidManifest.xml). L'app dichiara tutti i suoi componenti in questo file, che si trova nella directory principale della directory del progetto dell'app.

Il file manifest svolge una serie di cose, oltre a dichiarare i componenti dell'app, tra cui:

  • Identifica tutte le autorizzazioni utente richieste dall'app, ad esempio l'accesso a internet o l'accesso in lettura ai contatti dell'utente.
  • Dichiara il livello API minimo richiesto dall'app in base alle API utilizzate dall'app.
  • Dichiara le funzionalità hardware e software utilizzate o richieste dall'app, ad esempio una fotocamera, servizi Bluetooth o uno schermo multitouch.
  • Dichiara le librerie API a cui l'app deve essere collegata (diverse dalle API framework Android), ad esempio la libreria di Google Maps.

Dichiara i componenti

L'attività principale del file manifest è informare il sistema sui componenti dell'app. Ad esempio, un file manifest può dichiarare un'attività nel seguente modo:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

Nell'elemento <application>, l'attributo android:icon rimanda alle risorse di un'icona che identifica l'app.

Nell'elemento <activity>, l'attributo android:name specifica il nome completo della classe Activity, mentre l'attributo android:label specifica una stringa da utilizzare come etichetta visibile all'utente per l'attività.

Devi dichiarare tutti i componenti dell'app utilizzando i seguenti elementi:

Le attività, i servizi e i fornitori di contenuti che includi nell'origine ma che non dichiari nel file manifest non sono visibili al sistema e, di conseguenza, non possono mai essere eseguiti. Tuttavia, i ricevitori di trasmissione possono essere dichiarati nel manifest o creati dinamicamente nel codice come oggetti BroadcastReceiver e registrati nel sistema chiamando registerReceiver().

Per ulteriori informazioni su come strutturare il file manifest della tua app, consulta la Panoramica del file manifest dell'app.

Dichiara le funzionalità del componente

Come spiegato nella sezione Attiva componenti, puoi utilizzare Intent per avviare attività, servizi e ricevitori di annunci. A tale scopo, assegna esplicitamente un nome al componente di destinazione, utilizzando nell'intent il nome della classe del componente. Puoi anche utilizzare un intent implicito, che descrive il tipo di azione da eseguire e, facoltativamente, i dati su cui vuoi eseguire l'azione. Un intent implicito consente al sistema di trovare sul dispositivo un componente che può eseguire l'azione e avviarla. Se sono presenti più componenti in grado di eseguire l'azione descritta dall'intent, l'utente seleziona quale utilizzare.

Attenzione: se utilizzi un intent per avviare un Service, assicurati che la tua app sia sicura utilizzando un intent esplicito. L'utilizzo di un intent implicito per avviare un servizio rappresenta un rischio per la sicurezza, perché non puoi essere certo di quale servizio risponda all'intent e l'utente non possa vedere quale servizio viene avviato. A partire da Android 5.0 (livello API 21), il sistema genera un'eccezione se chiami bindService() con un intent implicito. Non dichiarare i filtri per intent per i servizi.

Il sistema identifica i componenti in grado di rispondere a un intent confrontando l'intent ricevuto con i filtri per intent forniti nel file manifest di altre app sul dispositivo.

Quando dichiari un'attività nel file manifest dell'app, puoi facoltativamente includere filtri di intent che dichiarano le funzionalità dell'attività in modo che possa rispondere agli intent di altre app. Per farlo, devi aggiungere un elemento <intent-filter> come elemento secondario dell'elemento dichiarazione del componente.

Ad esempio, se crei un'app email con un'attività per la scrittura di una nuova email, puoi dichiarare un filtro di intent per rispondere agli intent "send" e inviare una nuova email, come mostrato nell'esempio seguente:

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

Se un'altra app crea un intent con l'azione ACTION_SEND e lo passa a startActivity(), il sistema potrebbe avviare l'attività in modo che l'utente possa creare una bozza e inviare un'email.

Per saperne di più sulla creazione di filtri per intent, consulta il documento Intent e filtri di intent.

Dichiara i requisiti dell'app

Esistono diversi dispositivi con tecnologia Android e non tutti offrono le stesse caratteristiche e capacità. Per evitare che l'app venga installata su dispositivi privi delle funzionalità necessarie, è importante definire chiaramente un profilo per i tipi di dispositivi supportati dall'app dichiarando nel file manifest i requisiti per dispositivo e software.

La maggior parte di queste dichiarazioni è solo a scopo informativo. Il sistema non le legge, ma i servizi esterni come Google Play li leggono per fornire filtri agli utenti quando cercano app dal loro dispositivo.

Ad esempio, supponiamo che la tua app richieda una fotocamera e utilizzi API introdotte in Android 8.0 (livello API 26). Devi dichiarare questi requisiti. I valori per minSdkVersion e targetSdkVersion sono impostati nel file build.gradle del modulo dell'app:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

Nota: non impostare minSdkVersion e targetSdkVersion direttamente nel file manifest, poiché vengono sovrascritti da Gradle durante il processo di compilazione. Per maggiori informazioni, consulta la pagina Specificare i requisiti relativi ai livelli API.

Dichiari la funzionalità della fotocamera nel file manifest dell'app:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

Con le dichiarazioni mostrate in questi esempi, i dispositivi che non hanno una fotocamera o che hanno una versione di Android inferiore alla 8.0 non possono installare la tua app da Google Play. Tuttavia, puoi anche dichiarare che la tua app utilizza la fotocamera, ma non è richiesta. Per farlo, imposta l'attributo required su false, controlla in fase di runtime se il dispositivo è dotato di fotocamera e, se necessario, disattiva tutte le funzionalità della fotocamera.

Per ulteriori informazioni su come gestire la compatibilità dell'app con diversi dispositivi, consulta la panoramica della compatibilità dei dispositivi.

Risorse dell'app

Un'app Android non è composta solo da codice. Richiede risorse separate dal codice sorgente, come immagini, file audio e qualsiasi elemento relativo alla presentazione visiva dell'app. Ad esempio, puoi definire animazioni, menu, stili, colori e il layout delle interfacce utente delle attività con i file XML.

Le risorse dell'app consentono di aggiornare facilmente le varie caratteristiche dell'app senza modificare il codice. Fornire una serie di risorse alternative ti consente di ottimizzare la tua app per varie configurazioni di dispositivi, ad esempio lingue e dimensioni dello schermo diverse.

Per ogni risorsa che includi nel tuo progetto Android, gli strumenti di creazione dell'SDK definiscono un ID intero univoco, che puoi utilizzare per fare riferimento alla risorsa dal codice dell'app o da altre risorse definite in XML. Ad esempio, se la tua app contiene un file immagine denominato logo.png (salvato nella directory res/drawable/), gli strumenti SDK generano un ID risorsa denominato R.drawable.logo. Questo ID viene mappato a un numero intero specifico dell'app, che puoi utilizzare per fare riferimento all'immagine e inserirla nell'interfaccia utente.

Uno degli aspetti più importanti della fornitura di risorse separate dal codice sorgente è la possibilità di fornire risorse alternative per diverse configurazioni dei dispositivi.

Ad esempio, se definisci le stringhe dell'interfaccia utente in XML, puoi tradurre le stringhe in altre lingue e salvarle in file separati. Quindi Android applica all'interfaccia utente le stringhe di lingua appropriate in base a un qualificatore lingua da aggiungere al nome della directory delle risorse, ad esempio res/values-fr/ per i valori delle stringhe in francese, e all'impostazione della lingua dell'utente.

Android supporta molti qualificatori per le risorse alternative. Il qualificatore è una breve stringa che includi nel nome delle directory delle risorse per definire la configurazione del dispositivo per la quale vengono utilizzate le risorse.

Ad esempio, puoi creare layout diversi per le tue attività a seconda dell'orientamento e delle dimensioni dello schermo del dispositivo. Quando lo schermo del dispositivo è con orientamento verticale (alto), ti consigliamo di utilizzare un layout con i pulsanti disposti in verticale, mentre quando lo schermo è in orientamento orizzontale (largo), i pulsanti dovrebbero essere allineati orizzontalmente. Per modificare il layout a seconda dell'orientamento, puoi definire due layout e applicare il qualificatore appropriato al nome della directory di ogni layout. Successivamente, il sistema applica automaticamente il layout appropriato in base all'orientamento corrente del dispositivo.

Per ulteriori informazioni sui diversi tipi di risorse che puoi includere nell'applicazione e su come creare risorse alternative per configurazioni di dispositivi diverse, leggi la panoramica delle risorse per le app. Per scoprire di più sulle best practice e sulla progettazione di app solide e di qualità produttiva, consulta la Guida all'architettura delle app.

Risorse aggiuntive

Per imparare a sviluppare Android utilizzando video e tutorial di codice, consulta il corso Developing Android Apps with Kotlin Udacity.

Continua a leggere informazioni su:

Intent e filtri di intent
Scopri come utilizzare le API Intent per attivare componenti dell'app, come attività e servizi, e come rendere i componenti dell'app disponibili per l'utilizzo da parte di altre app.
Introduzione alle attività
Scopri come creare un'istanza della classe Activity, che fornisce una schermata distinta nella tua applicazione con un'interfaccia utente.
Panoramica delle risorse per le app
Scopri come sono strutturate le app per Android in modo da separare le risorse dell'app dal codice dell'app e come puoi fornire risorse alternative per configurazioni di dispositivi specifiche.

Altri interessi:

Panoramica della compatibilità dei dispositivi
Scopri come funziona Android su diversi tipi di dispositivi e come puoi ottimizzare la tua app per ogni dispositivo o limitarne la disponibilità a dispositivi diversi.
Autorizzazioni su Android
Scopri in che modo Android limita l'accesso delle app a determinate API con un sistema di autorizzazioni che richiede il consenso dell'utente per l'utilizzo di queste API da parte della tua app.