Jetpack — cosa sono, componenti dell'architettura

Cosa sono Android Jetpack?

Android Jetpack è una raccolta di librerie, strumenti e linee guida architetturali di Google, presentata nel 2018 al Google I/O. Jetpack ha sostituito Support Library e Android Architecture Components, unificandoli in un unico ecosistema. Prima di Jetpack, ogni libreria Android veniva aggiornata indipendentemente, creando conflitti di versione. Jetpack ha sincronizzato le versioni sotto un unico identificatore AndroidX e ha introdotto un modello di versioni maggiori stabili con patch minori.

Le librerie Jetpack sono divise in quattro categorie: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Ogni categoria affronta le attività di uno specifico livello applicativo — dalla gestione dei dati all'interfaccia utente.

Filosofia di Jetpack

Google promuove tre principi di Jetpack: accelerate development (meno boilerplate, più logica di business), eliminate boilerplate (ViewModel elimina il salvataggio manuale dello stato, Room elimina la scrittura di SQLiteOpenHelper) e build with confidence (ogni libreria supera oltre 15.000 test prima del rilascio). Secondo Android Developers (2026), le app che utilizzano Jetpack hanno il 30% in meno di crash legati al ciclo di vita.

AndroidX come base

Tutte le librerie Jetpack sono distribuite sotto l'identificatore AndroidX (artefatti come androidx.*). AndroidX ha sostituito Support Library (artefatti come com.android.support.*), dividendo la libreria monolitica in artefatti modulari con versionamento indipendente. La migrazione ad AndroidX viene eseguita tramite l'opzione android.useAndroidX=true in gradle.properties — Android Studio converte automaticamente le importazioni.

Componenti dell'architettura: ViewModel, Lifecycle, LiveData

ViewModel è il componente centrale dell'architettura Jetpack che memorizza i dati dell'interfaccia utente. A differenza di un'Activity, che viene distrutta durante la rotazione dello schermo, ViewModel rimane in memoria. L'utente compila un modulo, ruota il telefono — i dati non vengono persi. ViewModel viene automaticamente cancellato quando il LifecycleOwner (Activity o Fragment) termina permanentemente il suo ciclo di vita (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Schermata avviata")
    }
}

LiveData — un contenitore di dati osservabile che rispetta il ciclo di vita. Se lo schermo non è visibile (onStop), LiveData non invia aggiornamenti — questo previene perdite di memoria e crash quando si tenta di aggiornare un'Activity inesistente. Lifecycle — una classe che memorizza lo stato corrente (CREATED, STARTED, RESUMED) e consente ad altri componenti di sottoscriversi ai cambiamenti di stato. Insieme, ViewModel, LiveData e Lifecycle costituiscono il fondamento dell'architettura reattiva di Android.

ViewModelScope e coroutine

viewModelScope — un CoroutineScope integrato legato al ciclo di vita di ViewModel. Tutte le coroutine avviate in questo ambito vengono automaticamente annullate quando ViewModel viene cancellato. Questo elimina la gestione manuale di Disposable e CompositeDisposable in ogni ViewModel. Per lavorare con viewModelScope è necessaria la dipendenza androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: lavorare con il database su Android

Room è una libreria ORM di Jetpack che fornisce uno strato astratto su SQLite. Invece di scrivere query SQL grezze e convertire manualmente Cursor in oggetti, lo sviluppatore dichiara un'Entity (tabella), DAO (Data Access Object) e Database (punto di ingresso). Room verifica le query SQL in fase di compilazione tramite l'annotazione @Query — se le tabelle o le colonne non esistono, la compilazione fallisce con un errore chiaro.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

L'Entity User descrive una tabella con tre colonne. Il DAO dichiara funzioni suspend per lavorare con le coroutine — la query viene eseguita automaticamente su un thread in background. Room supporta le migrazioni tramite l'annotazione @Migration: lo sviluppatore descrive lo script SQL di transizione tra le versioni e Room lo esegue senza perdita di dati. In assenza di migrazione, Room lancia IllegalStateException — questo protegge i progetti dalla perdita accidentale di dati durante l'aggiornamento dello schema.

TypeConverters e relazioni

Room memorizza solo i tipi primitivi e i loro wrapper. Per memorizzare liste, Date o oggetti personalizzati si usa @TypeConverter — un metodo statico che converte un tipo in String (JSON) o Long (timestamp). Le relazioni tra tabelle vengono modellate tramite oggetti annidati con l'annotazione @Relation e classi POJO helper con @Transaction per query join efficienti.

Navigation Component: grafi e argomenti

Navigation Component — una libreria Jetpack per gestire le transizioni tra schermate. Invece di chiamare manualmente FragmentTransaction, lo sviluppatore crea un grafo di navigazione (file XML con nodi di destinazione) e il sistema genera una classe Directions con metodi di transizione type-safe. Navigation Component garantisce il corretto funzionamento dello stack indietro, dei deep link e del passaggio di argomenti tra schermate.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// Nel codice del frammento:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Gli argomenti userId vengono passati nel grafo di navigazione con specifica del tipo (integer) e valore predefinito. La classe ProfileFragmentArgs viene generata automaticamente dal plugin Navigation Safe Args — contiene tutti gli argomenti con i corretti tipi Kotlin. I deep link vengono configurati nel grafo: app:deepLink="app://profile/{userId}". Navigation Component analizza l'URL e crea lo stack indietro come se l'utente avesse navigato attraverso l'interfaccia.

Bottom Navigation e navigazione condizionale

Navigation Component si integra con BottomNavigationView tramite NavController: ogni voce di menu è collegata a una destinazione nel grafo. Il cambio tra schede non ricrea il frammento — Navigation Component preserva lo stato tramite NavBackStackEntry. Per la navigazione condizionale (mostra login se non autenticato), si usa navController.navigate(condition) con un controllo in onCreate.

AndroidX: la Support Library di nuova generazione

AndroidX è un'architettura riprogettata di Support Library in cui ogni libreria ha ricevuto il proprio artefatto con versione indipendente. Invece di un singolo com.android.support:appcompat-v7:28.0.0, AndroidX offre androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 e così via. Questo ha eliminato il problema per cui diverse dipendenze tiravano versioni diverse di Support Library, causando conflitti.

La migrazione ad AndroidX viene eseguita automaticamente in Android Studio 3.2+ tramite il menu Refactor → Migrate to AndroidX. Studio sostituisce tutte le importazioni nei file Java/Kotlin, manifest e risorse. La retrocompatibilità è il principale vantaggio di AndroidX: le librerie funzionano su Android 5.0 (API 21) e superiori, coprendo il 97% dei dispositivi attivi secondo Google Play Console (2025).

Principali artefatti AndroidX

Gli artefatti più utilizzati: appcompat (tema scuro, Material Design su vecchie API), recyclerview (elenchi adattivi con ViewHolder), constraintlayout (contenitore flessibile con gerarchia piatta), cardview (schede Material Design), preference (schermata impostazioni in stile Material). Ogni artefatto ha un versionamento indipendente, accelerando la consegna delle correzioni senza aggiornare l'intero pacchetto.

Altre importanti librerie Jetpack

Oltre ad Architecture e AndroidX, Jetpack include molte librerie specializzate per attività tipiche dello sviluppo mobile. WorkManager — per attività in background con esecuzione garantita (sincronizzazione, upload di log), supporta attività periodiche e differite, nonché vincoli di rete e batteria. DataStore — un sostituto di SharedPreferences basato su coroutine, che supporta proprietà tipizzate (Preferences DataStore) e Protocol Buffers (Proto DataStore).

• Hilt — un framework DI basato su Dagger che semplifica l'iniezione delle dipendenze tramite le annotazioni @HiltViewModel, @Inject, @Module. Integrazione nativa con ViewModel e Navigation.
• Paging 3 — una libreria per il caricamento paginato di dati da rete/DB con supporto per RemoteMediator (rete + cache), StateFlow e Compose.
• CameraX — un'API per lavorare con la fotocamera, che astrae le differenze tra produttori (Samsung, Xiaomi, Honor) tramite un'interfaccia unificata CameraController.
• Security Crypto — crittografia dei dati tramite EncryptedSharedPreferences ed EncryptedFile basata su AES-256 con chiave master in Android Keystore.

Ogni libreria ha il proprio SDK minimo e artefatto. Google rilascia versioni maggiori una volta all'anno (in coincidenza con il rilascio di Android) e patch di sicurezza trimestralmente. Raccomandazione — includere solo le librerie necessarie per non aumentare le dimensioni dell'APK. L'intera raccolta Jetpack (tutti gli artefatti) pesa oltre 20 MB, ma un'app tipica utilizza 5–7 librerie, aggiungendo 3–5 MB all'APK.