Intent Filter: wat is het, hoe werkt het en wordt gebruikt in ontwikkeling

Wat is Intent Filter?

Intent Filter is een configuratie-element van een Android-app dat het systeem informeert over de mogelijkheid van een component om bepaalde typen impliciete intenties te verwerken. In tegenstelling tot expliciete Intent die een specifieke klasse aangeven, bevatten impliciete Intent alleen een beschrijving van de gevraagde actie, en het systeem vindt zelf de juiste component op basis van geregistreerde filters.

Filters worden binnen het component gedeclareerd — Activity, Service of BroadcastReceiver — in het bestand AndroidManifest.xml. Elk filter kan meerdere action-, category- en data-elementen bevatten. Een component kan een onbeperkt aantal Intent Filters hebben, die elk een apart verwerkingsscenario beschrijft.

Rol in de Android-architectuur

Intent Filter implementeert het principe van losse koppeling tussen app-componenten. App A hoeft niet op de hoogte te zijn van het bestaan van app B — het stuurt gewoon een Intent met een actiebeschrijving, en het systeem routeert deze op basis van filters. Dit mechanisme ligt ten grondslag aan Share Sheet, browserkeuze en deep link-verwerking.

Typen Intent: expliciet en impliciet

Expliciete Intent verwijzen naar een specifieke klasse van het te starten component. Ze worden gebruikt voor interne navigatie binnen dezelfde app, wanneer de ontwikkelaar precies weet welke Activity moet worden geopend. Impliciete Intent bevatten alleen een beschrijving van de actie, en het component wordt dynamisch door het systeem bepaald.

Intent Filter werkt uitsluitend met impliciete Intent. Als er in de Intent een specifieke klasse is opgegeven, negeert het systeem alle filters en start het het opgegeven component direct. Filters worden alleen gecontroleerd bij het oplossen van impliciete oproepen, wat ze een sleutelelement maakt van interactie tussen apps.

Vergelijking van expliciete en impliciete Intent

Structuur van Intent Filter in het manifest

Elk Intent Filter bestaat uit drie groepen elementen — action, category en data — waarvan de combinatie bepaalt welke Intent het component zal ontvangen. Het filter wordt als geslaagd beschouwd als de Intent overeenkomt met ten minste één element van elke groep.

Action beschrijft de uitgevoerde actie — bekijken, bewerken, verzenden. Category voegt een extra verwerkingscontext toe — bijvoorbeeld de mogelijkheid om vanuit de browser te starten. Data definieert het formaat van de verwerkte informatie via URI of MIME-type.

Componenten van de intent-filter tag

Voorbeeld van Intent Filter voor een Activity die links naar gebruikersprofielen opent. Het filter bevat alle drie groepen elementen voor nauwkeurige routering.

<activity android:name=".ProfileActivity">
    <intent-filter>
        <action
            android:name="android.intent.action.VIEW" />
        <category
            android:name="android.intent.category.DEFAULT" />
        <category
            android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="profile" />
    </intent-filter>
</activity>

Let op de verplichte vermelding van category DEFAULT — zonder dit zal het systeem geen impliciete Intent aan het component doorgeven. De categorie BROWSABLE wordt toegevoegd als de link vanuit de browser moet worden verwerkt.

Intent Filter voor deep link

Deep link op Android wordt geconfigureerd via Intent Filter met action VIEW en een data-tag met schema, host en pad. Bij het klikken op een link van de vorm myapp://profile/42 vindt het systeem de Activity met het juiste filter en start deze met de doorgegeven URI. Het is belangrijk om pathPrefix, pathPattern of path correct te configureren voor exacte matching.

Sinds Android 6 (API 23) is er ondersteuning voor App Links — geverifieerde deep links via HTTPS. Voor App Links wordt dezelfde Intent Filter gebruikt, maar met extra domeinverificatie via Digital Asset Links. Na verificatie opent het systeem automatisch de app zonder keuzedialoog.

Data-tag voor URL

Voorbeeld van een filter voor App Link met verificatie via een HTTPS-link. In dit geval is het schema altijd https en komt de host overeen met het domein dat is opgegeven in Digital Asset Links.

<intent-filter android:autoVerify="true">
    <action
        android:name="android.intent.action.VIEW" />
    <category
        android:name="android.intent.category.DEFAULT" />
    <category
        android:name="android.intent.category.BROWSABLE" />
    <data
        android:scheme="https"
        android:host="example.com"
        android:pathPrefix="/profile" />
</intent-filter>

Het attribuut autoVerify geeft het systeem de opdracht om Digital Asset Links te controleren bij de installatie van de app. Als de verificatie slaagt, wordt de app automatisch de standaardbehandelaar voor het opgegeven domein en paden.

Intent verwerken in app-componenten

Nadat het systeem een component heeft geselecteerd om de Intent te verwerken, moet de ontwikkelaar de gegevens uit de binnenkomende intentie in het doelcomponent extraheren. Voor Activity wordt de methode getIntent() in onCreate() gebruikt, voor BroadcastReceiver — de methode onReceive(), waarbij de Intent als parameter wordt doorgegeven.

Het extraheren van gegevens omvat het ophalen van action voor het bepalen van het operatietype, data voor de URI en extra-parameters voor aanvullende informatie. Elk van deze elementen kan ontbreken, dus null-controle voor gebruik is verplicht.

Verwerkingscode in Activity

Voorbeeld van het verwerken van een binnenkomende deep link in een Activity in Kotlin. De code haalt de URI uit de Intent en neemt op basis van host en pad een navigatiebeslissing.

class ProfileActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val uri = intent?.data
        if (uri?.host == "profile") {
            val userId = uri.lastPathSegment
            loadProfile(userId)
        }
    }
}

Het wordt aanbevolen om de safe call operator te gebruiken voor het controleren van intent en data op null, omdat de activiteit kan worden gestart zonder een binnenkomende deep link. Ook moeten host en pathSegment op null worden gecontroleerd voordat ze worden gebruikt in navigatie.

Prioriteit en conflictoplossing

Als meerdere apps een Intent Filter hebben geregistreerd die overeenkomt met dezelfde impliciete Intent, toont het systeem de gebruiker een keuzedialoog. De gebruiker kan de app kiezen voor eenmalig gebruik of een standaardbehandelaar instellen. Sinds Android 10 wordt de keuzedialoog alleen bij de eerste aanroep getoond, waarna het systeem de keuze van de gebruiker onthoudt.

Voor prioriteitsbeheer wordt het attribuut android:priority in de intent-filter tag gebruikt. Hoe hoger de waarde, hoe hoger de prioriteit van het component bij conflictoplossing. Prioriteit werkt echter niet voor filters uit verschillende apps — in dit geval wordt altijd de keuzedialoog getoond, als er geen app als standaard is ingesteld.

App-keuzedialoog

De ontwikkelaar kan programmatisch de keuzedialoog aanroepen via Intent.createChooser(), waarbij de doel-Intent en een titel worden doorgegeven. Dit is handig wanneer de app de gebruiker expliciet een behandelaar wil laten kiezen, zelfs als er een standaard-app is ingesteld. Bij het verzenden van afbeeldingen naar sociale netwerken via ACTION_SEND met createChooser wordt bijvoorbeeld gegarandeerd dat de dialoog wordt getoond, ongeacht de standaardinstellingen.

Veelvoorkomende fouten bij het configureren van Intent Filter

Een van de meest voorkomende fouten is het ontbreken van de categorie DEFAULT in de Intent Filter. Ontwikkelaars kopiëren de configuratie uit voorbeelden, maar vergeten deze categorie toe te voegen, waardoor de Activity geen impliciete Intent ontvangt. Het systeem ziet het filter simpelweg niet voor impliciete oproepen, hoewel expliciete Intent blijven werken.

De tweede veelvoorkomende fout is het onjuist opgeven van scheme in de data-tag zonder volledige URI. Als alleen het schema is opgegeven maar niet de host, accepteert het filter alle links met dit schema uit elke bron, wat kan leiden tot ongewenste oproepen uit niet-geverifieerde bronnen. Het wordt aanbevolen om altijd ten minste scheme en host op te geven.

De derde fout is het ontbreken van een null-controle van intent.data in de Activity-code. Als de Activity niet via een deep link wordt gestart maar standaard vanuit de launcher, bevat de Intent geen URI. Toegang tot intent.data zonder controle veroorzaakt een NullPointerException en een crash van de app. Gebruik altijd intent?.data?.toString() met de safe call operator.