Intent Filter: vad det är, hur det fungerar och används i utveckling

Vad är Intent Filter?

Intent Filter är ett konfigurationselement i Android-applikationen som informerar systemet om en komponents förmåga att hantera specifika typer av implicita avsikter. Till skillnad från explicita Intent som anger en specifik klass, innehåller implicita Intent endast en beskrivning av den önskade åtgärden och systemet hittar själv en lämplig komponent baserat på registrerade filter.

Filter deklareras inuti komponenten — Activity, Service eller BroadcastReceiver — i filen AndroidManifest.xml. Varje filter kan innehålla flera element av action, category och data. En komponent kan ha ett obegränsat antal Intent Filter, där varje filter beskriver ett separat bearbetningsscenario.

Roll i Android-arkitekturen

Intent Filter implementerar principen om lös koppling mellan applikationskomponenter. Applikation A behöver inte känna till existensen av applikation B — den skickar bara ett Intent med en beskrivning av åtgärden och systemet dirigerar det baserat på filtren. Denna mekanism ligger till grund för Share Sheet, webbläsarval och hantering av deep link.

Typer av Intent: explicita och implicita

Explicita Intent anger en specifik klass av komponenten för start. De används för intern navigering inom en applikation när utvecklaren vet exakt vilket Activity som ska öppnas. Implicita Intent innehåller endast en beskrivning av åtgärden och komponenten bestäms dynamiskt av systemet.

Intent Filter arbetar uteslutande med implicita Intent. Om en specifik klass anges i Intent ignorerar systemet alla filter och startar den angivna komponenten direkt. Filter kontrolleras endast vid upplösning av implicita anrop, vilket gör dem till en nyckelelement för kommunikation mellan applikationer.

Jämförelse av explicita och implicita Intent

Struktur för Intent Filter i manifestet

Varje Intent Filter består av tre grupper av element — action, category och data — vars kombination avgör vilka Intent komponenten kommer att ta emot. Filtret anses vara uppfyllt om Intent matchar minst ett element från varje grupp.

Action beskriver den åtgärd som utförs — visning, redigering, sändning. Category lägger till ytterligare bearbetningskontext — till exempel möjlighet att startas från webbläsaren. Data definierar formatet på den information som bearbetas via URI eller MIME-typ.

Element i intent-filter-taggen

Exempel på Intent Filter för ett Activity som öppnar länkar till användarprofiler. Filtret inkluderar alla tre grupper av element för exakt dirigering.

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

Observera den obligatoriska angivelsen av category DEFAULT — utan den kommer systemet inte att vidarebefordra implicita Intent till komponenten. Kategorin BROWSABLE läggs till om länken ska bearbetas från webbläsaren.

Intent Filter för deep link

Deep link på Android konfigureras via Intent Filter med action VIEW och en data-tagg som innehåller schema, host och sökväg. När man navigerar till en länk av typen myapp://profile/42 hittar systemet Activity med matchande filter och startar det med det överförda URI:t. Det är viktigt att korrekt konfigurera pathPrefix, pathPattern eller path för exakt matchning.

Från och med Android 6 (API 23) finns stöd för App Links — verifierade deep links via HTTPS. För App Links används samma Intent Filter, men med ytterligare domänverifiering via Digital Asset Links. Efter verifiering öppnar systemet automatiskt applikationen utan urvalsdialog.

Data-tagg för URL

Exempel på filter för App Link med verifiering via HTTPS-länk. I detta fall är schemat alltid https och hosten motsvarar domänen som anges i 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>

Attributet autoVerify instruerar systemet att kontrollera Digital Asset Links vid installation av applikationen. Om verifieringen lyckas blir applikationen automatiskt standardhanterare för den angivna domänen och sökvägarna.

Hantera Intent i applikationskomponenter

Efter att systemet har valt en komponent för att bearbeta Intent måste utvecklaren extrahera data från den inkommande avsikten inuti målkomponenten. För Activity används metoden getIntent() i onCreate(), för BroadcastReceiver metoden onReceive(), där Intent skickas som en parameter.

Dataextraktion inkluderar att hämta action för att bestämma operationstyp, data för URI och extra-parametrar för ytterligare information. Var och en av dessa element kan saknas, därför krävs null-kontroll före användning.

Bearbetningskod i Activity

Exempel på bearbetning av inkommande deep link i Activity i Kotlin. Koden extraherar URI från Intent och baserat på host och sökväg fattar den navigeringsbeslut.

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

Det rekommenderas att använda safe call-operatorn för att kontrollera intent och data för null, eftersom aktiviteten kan startas utan inkommande deep link. Man bör också kontrollera host och pathSegment för null innan de används i navigeringen.

Prioritet och konfliktlösning

Om flera applikationer har registrerat ett Intent Filter som matchar samma implicita Intent visar systemet en urvalsdialog för användaren. Användaren kan välja en applikation för engångsbruk eller ställa in en standardhanterare. Från och med Android 10 visas urvalsdialogen endast vid första anropet, därefter kommer systemet ihåg användarens val.

För prioritetshantering används attributet android:priority i intent-filter-taggen. Ju högre värde, desto högre prioritet har komponenten vid konfliktlösning. Prioritet fungerar dock inte för filter från olika applikationer — i detta fall visas alltid en urvalsdialog om ingen applikation är inställd som standard.

Urvalsdialog för applikation

Utvecklaren kan programmatiskt anropa urvalsdialogen via Intent.createChooser() genom att skicka det önskade Intent och en titel. Detta är användbart när applikationen vill uttryckligen föreslå att användaren väljer en hanterare, även om en standardapplikation är inställd. Till exempel vid sändning av bilder till sociala nätverk via ACTION_SEND garanterar createChooser att dialogen visas oavsett standardinställningar.

Vanliga misstag vid konfiguration av Intent Filter

Ett av de vanligaste misstagen är avsaknaden av kategorin DEFAULT i Intent Filter. Utvecklare kopierar konfigurationen från exempel men glömmer att lägga till denna kategori, vilket resulterar i att Activity inte tar emot implicita Intent. Systemet ser helt enkelt inte filtret för implicita anrop, även om explicita Intent fortfarande fungerar.

Det andra vanliga misstaget är felaktig angivelse av scheme i data-taggen utan fullständigt URI. Om endast schemat anges men inte hosten, kommer filtret att acceptera alla länkar med detta schema från vilken källa som helst, vilket kan leda till oönskade anrop från overifierade källor. Det rekommenderas att alltid ange åtminstone schema och host.

Det tredje misstaget är avsaknaden av kontroll av intent.data för null i Activity-koden. Om Activity startas inte via deep link utan på standardsätt från startprogrammet, innehåller Intent inget URI. Åtkomst till intent.data utan kontroll orsakar NullPointerException och applikationskrasch. Använd alltid intent?.data?.toString() med safe call-operatorn.