Jetpack — wat is het, architectuurcomponenten

Wat is Android Jetpack?

Android Jetpack — is een verzameling bibliotheken, tools en architectuuraanbevelingen van Google, gepresenteerd in 2018 op Google I/O. Jetpack verving Support Library en Android Architecture Components en verenigde ze in één ecosysteem. Vóór Jetpack werd elke Android-bibliotheek onafhankelijk bijgewerkt, wat versieconflicten veroorzaakte. Jetpack synchroniseerde versies onder één AndroidX-identificatie en introduceerde een model van stabiele hoofdversies met kleine patches.

Jetpack-bibliotheken zijn onderverdeeld in vier categorieën: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Elke categorie lost taken van een specifieke applicatielaag op — van gegevensbeheer tot gebruikersinterface.

Jetpack-filosofie

Google promoot drie Jetpack-principes: accelerate development (minder boilerplate, meer bedrijfslogica), eliminate boilerplate (ViewModel elimineert handmatig opslaan van status, Room — het schrijven van SQLiteOpenHelper) en build with confidence (elke bibliotheek doorloopt 15+ duizend tests vóór release). Volgens Android Developers (2026) hebben apps op Jetpack 30% minder crashes gerelateerd aan de levenscyclus.

AndroidX als basis

Alle Jetpack-bibliotheken worden verspreid onder de identificatie AndroidX (artefacten van de vorm androidx.*). AndroidX verving Support Library (artefacten com.android.support.*) en splitste de monolitische bibliotheek op in modulaire artefacten met onafhankelijke versiebeheer. Migratie naar AndroidX gebeurt via de optie android.useAndroidX=true in gradle.properties — Android Studio converteert automatisch imports.

Architectuurcomponenten: ViewModel, Lifecycle, LiveData

ViewModel — de centrale component van de Jetpack-architectuur die UI-gegevens opslaat. In tegenstelling tot Activity, dat wordt vernietigd bij schermrotatie, blijft ViewModel in het geheugen. De gebruiker vult een formulier in, draait de telefoon — gegevens gaan niet verloren. ViewModel wordt automatisch opgeschoond wanneer LifecycleOwner (Activity of Fragment) zijn levenscyclus definitief beëindigt (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("Scherm gestart")
    }
}

LiveData — een waarneembare container voor gegevens die rekening houdt met de levenscyclus. Als het scherm niet zichtbaar is (onStop), stuurt LiveData geen updates — dit voorkomt geheugenlekken en crashes bij het proberen bij te werken van een niet-bestaande Activity. Lifecycle — een klasse die de huidige status opslaat (CREATED, STARTED, RESUMED) en andere componenten in staat stelt te abonneren op statuswijzigingen. Samen vormen ViewModel, LiveData en Lifecycle de basis van de reactieve Android-architectuur.

ViewModelScope en coroutines

viewModelScope — een ingebouwde CoroutineScope gekoppeld aan de levenscyclus van ViewModel. Alle coroutines die in deze scope zijn gestart, worden automatisch geannuleerd bij het opschonen van ViewModel. Dit elimineert handmatig beheer van Disposable en CompositeDisposable in elke ViewModel. Voor het werken met viewModelScope is de afhankelijkheid androidx.lifecycle:lifecycle-viewmodel-ktx vereist.

Room: werken met databases op Android

Room — is een ORM-bibliotheek van Jetpack die een abstracte laag boven SQLite biedt. In plaats van ruwe SQL-query's te schrijven en handmatig Cursor naar objecten te converteren, declareert de ontwikkelaar Entity (tabel), DAO (Data Access Object) en Database (toegangspunt). Room valideert SQL-query's bij compilatie via de annotatie @Query — als tabellen of kolommen niet bestaan, mislukt de build met een duidelijke foutmelding.

@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
}

Entity User beschrijft een tabel met drie kolommen. DAO declareert suspend-functies voor het werken met coroutines — de query wordt automatisch op de achtergrond uitgevoerd. Room ondersteunt migraties via de annotatie @Migration: de ontwikkelaar beschrijft het SQL-script voor de overgang tussen versies en Room voert het uit zonder gegevensverlies. Bij afwezigheid van een migratie gooit Room IllegalStateException — zo worden projecten beschermd tegen onbedoeld gegevensverlies bij het bijwerken van het schema.

TypeConverters en relaties

Room slaat alleen primitieve typen en hun wrappers op. Voor het opslaan van lijsten, Date of aangepaste objecten wordt @TypeConverter gebruikt — een statische methode die het type converteert naar String (JSON) of Long (timestamp). Relaties tussen tabellen worden gemodelleerd via geneste objecten met de annotatie @Relation en helper POJO-klassen met @Transaction voor efficiënte join-query's.

Navigation Component: grafen en argumenten

Navigation Component — een Jetpack-bibliotheek voor het beheren van overgangen tussen schermen. In plaats van handmatig FragmentTransaction aan te roepen, maakt de ontwikkelaar een navigatiegraaf (XML-bestand met knooppunt-bestemmingen) en genereert het systeem de klasse Directions met type-safe overgangsmethoden. Navigation Component garandeert correcte werking van back stack, deep links en het doorgeven van argumenten tussen schermen.

// nav_graph.xml
// <fragment android:id="@+id/profileFragment"
//     android:name=".ProfileFragment">
//     <argument android:name="userId"
//         android:defaultValue="-1"
//         app:argType="integer" />
// </fragment>

// In de fragmentcode:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

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

De argumenten userId worden doorgegeven in de navigatiegraaf met specificatie van het type (integer) en de standaardwaarde. De klasse ProfileFragmentArgs wordt automatisch gegenereerd door de Navigation Safe Args-plug-in — deze bevat alle argumenten met de juiste Kotlin-typen. Diepe links worden geconfigureerd in de graaf: app:deepLink="app://profile/{userId}". Navigation Component parseert zelf de URL en maakt de back stack alsof de gebruiker door de interface heeft genavigeerd.

Bottom Navigation en Conditional Navigation

Navigation Component integreert met BottomNavigationView via NavController: elk menu-item wordt gekoppeld aan een bestemming in de graaf. Overgang tussen tabs maakt het fragment niet opnieuw aan — Navigation Component bewaart de status via NavBackStackEntry. Voor voorwaardelijke navigatie (weergeven van login indien niet geautoriseerd) wordt navController.navigate(condition) gebruikt met controle in onCreate.

AndroidX: Support Library van de nieuwe generatie

AndroidX — is een herontworpen architectuur van Support Library, waarin elke bibliotheek zijn eigen artefact met onafhankelijke versie kreeg. In plaats van een enkele com.android.support:appcompat-v7:28.0.0 biedt AndroidX androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 enzovoort. Dit loste het probleem op waarbij verschillende afhankelijkheden verschillende versies van Support Library trokken, wat conflicten veroorzaakte.

Migratie naar AndroidX wordt automatisch uitgevoerd in Android Studio 3.2+ via het menu Refactor → Migrate to AndroidX. Studio vervangt alle imports in Java/Kotlin-bestanden, manifesten en bronnen. Achterwaartse compatibiliteit — het belangrijkste voordeel van AndroidX: bibliotheken werken op Android 5.0 (API 21) en hoger en dekken 97% van de actieve apparaten volgens Google Play Console (2025).

Belangrijkste AndroidX-artefacten

De meest gebruikte artefacten: appcompat (donker thema, Material Design op oude API's), recyclerview (adaptieve lijsten met ViewHolder), constraintlayout (flexibele container met platte hiërarchie), cardview (Material Design-kaarten), preference (instellingenscherm in Material-stijl). Elk artefact wordt onafhankelijk geversioneerd, wat het ontvangen van fixes versnelt zonder het hele pakket bij te werken.

Andere belangrijke Jetpack-bibliotheken

Naast Architecture en AndroidX bevat Jetpack vele gespecialiseerde bibliotheken voor typische mobiele ontwikkelingstaken. WorkManager — voor achtergrondtaken met gegarandeerde uitvoering (synchronisatie, uploaden van logs), ondersteunt periodieke en uitgestelde taken, evenals netwerk- en batterijbeperkingen. DataStore — vervanging voor SharedPreferences op basis van coroutines, ondersteunt getypeerde eigenschappen (Preferences DataStore) en Protocol Buffers (Proto DataStore).

• Hilt — een DI-framework op basis van Dagger, dat het injecteren van afhankelijkheden vereenvoudigt via annotaties @HiltViewModel, @Inject, @Module. Ingebouwde integratie met ViewModel en Navigation.
• Paging 3 — een bibliotheek voor het pagineren van gegevens uit netwerk/DB met ondersteuning voor RemoteMediator (netwerk + cache), StateFlow en Compose.
• CameraX — API voor het werken met de camera, die verschillen tussen fabrikanten (Samsung, Xiaomi, Honor) abstraheert via een uniforme CameraController-interface.
• Security Crypto — gegevensversleuteling via EncryptedSharedPreferences en EncryptedFile op basis van AES-256 met een hoofdsleutel in Android Keystore.

Elke bibliotheek heeft zijn eigen minimale SDK en artefact. Google brengt hoofdversies één keer per jaar uit (samenvallend met de Android-release) en beveiligingspatches — per kwartaal. Aanbeveling — alleen de benodigde bibliotheken aansluiten om de APK-grootte niet te vergroten. Jetpack in zijn geheel (alle artefacten) weegt meer dan 20 MB, maar een typische app gebruikt 5-7 bibliotheken en voegt 3-5 MB toe aan de APK.