- składnia:
-
<uri-relative-filter-group android:allow=["true" | "false"]> <data ... /> ... </uri-relative-filter-group>
- zawarte w:
-
<intent-filter>
- może zawierać:
-
<data>
- description:
- Tworzy precyzyjne reguły dopasowywania
Intent
, które mogą obejmować parametry zapytania i fragmenty identyfikatora URI. W zależności od atrybutuandroid:allow
reguły mogą być regułami uwzględniającymi (zezwalanie) lub regułami wykluczającymi (blokowanie). Reguły dopasowywania są określane przez atrybutypath*
,fragment*
iquery*
zawartych elementów<data>
.Dopasowywanie
Aby dopasować identyfikator URI, każdy fragment grupy filtrów względnych identyfikatorów URI musi odpowiadać części identyfikatora URI. W grupie filtrów względnych adresów URI mogą występować fragmenty adresów URI, które nie są określone w grupie. Przykład:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:query="param1=value1" /> <data android:query="param2=value2" /> </uri-relative-filter-group> ... </intent-filter>
Filtr pasuje do:
https://project.example.com/any/path/here?param1=value1¶m2=value2¶m3=value3
ponieważ wszystko określone przez grupę filtrów względnych URI jest obecne. Filtr pasuje też do wartościhttps://project.example.com/any/path/here?param2=value2¶m1=value1
, ponieważ kolejność parametrów zapytania nie ma znaczenia. Filtr nie pasuje jednak do kolumnyhttps://project.example.com/any/path/here?param1=value1
, w której brakuje kolumnyparam2=value2
.LUB i I
Tagi
<data>
spoza bloku<uri-relative-filter-group>
są łączone za pomocą operatora LUB, a tagi<data>
wewnątrz bloku<uri-relative-filter-group>
są łączone za pomocą operatora I.Rozważ ten przykład:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <data android:pathPrefix="/prefix" /> <data android:pathSuffix="suffix" /> ... </intent-filter>
Filtr pasuje do ścieżek, które zaczynają się od
/prefix
LUB kończą się nasuffix
.Natomiast w następującym przykładzie pasują ścieżki, które zaczynają się od
/prefix
i kończą nasuffix
:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group> <data android:pathPrefix="/prefix" /> <data android:pathSuffix="suffix" /> </uri-relative-filter-group> ... </intent-filter>
W rezultacie wiele atrybutów
path
w tym samym polu<uri-relative-filter-group>
nie pasuje do niczego:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group> <data android:path="/path1" /> <data android:path="/path2" /> </uri-relative-filter-group> ... </intent-filter>
Kolejność deklaracji
Rozważ ten przykład:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group> <data android:fragment="fragment" /> </uri-relative-filter-group> <uri-relative-filter-group android:allow="false"> <data android:fragmentPrefix="fragment" /> </uri-relative-filter-group> ... </intent-filter>
Filtr pasuje do fragmentu
#fragment
, ponieważ dopasowanie jest znajdowane przed zweryfikowaniem reguły wykluczenia, ale fragmenty takie jak#fragment123
nie pasują.Tagi pokrewne
Tagi
<uri-relative-filter-group>
współdziałają z tagami<data>
(czyli tagami<data>
, które znajdują się poza tagiem<uri-relative-filter-group>
, ale w tym samym<intent-filter>
). Aby działały prawidłowo, tagi<uri-relative-filter-group>
muszą mieć tagi<data>
, ponieważ atrybuty URI są na poziomie<intent-filter>
wzajemnie zależne:- Jeśli w przypadku filtra intencji nie zostanie określony parametr
scheme
, wszystkie pozostałe atrybuty URI zostaną zignorowane. - Jeśli filtr nie ma określonego atrybutu
host
, atrybutport
i wszystkie atrybutypath*
są ignorowane.
<data>
podrzędne<intent-filter>
są oceniane przed tagami<uri-relative-filter-group>
. Następnie tagi<uri-relative-filter-group>
są oceniane po kolei, na przykład:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="false"> <data android:path="/path" /> <data android:query="query" /> </uri-relative-filter-group> <data android:path="/path" /> ... </intent-filter>
Filtr akceptuje
https://project.example.com/path?query
, ponieważ pasuje do<data android:path="/path" />
, które nie jest objęte regułą wykluczenia<uri-relative-filter-group>
.Częsty przypadek użycia
Załóżmy, że masz identyfikator URI
https://project.example.com/path
, który chcesz dopasować do identyfikatoraIntent
w zależności od obecności lub wartości parametru zapytania. Aby utworzyć filtr intencji, który pasuje do wyrażeniahttps://project.example.com/path
i blokuje wyrażeniehttps://project.example.com/path?query
, możesz spróbować użyć tego wyrażenia:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:path="/path" /> </uri-relative-filter-group> ... </intent-filter>
To w ogóle nie działa. Identyfikator URI
https://project.example.com/path?query
dopasowuje się do ścieżki/path
, a tag<uri-relative-filter-group>
pozwala uwzględnić dodatkowe części podczas dopasowywania.Zmień filtr zamiaru w ten sposób:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="false"> <data android:path="/path" /> <data android:queryAdvancedPattern=".+" /> </uri-relative-filter-group> <uri-relative-filter-group android:allow="true"> <data android:path="/path" /> </uri-relative-filter-group> ... </intent-filter>
Ten filtr działa, ponieważ reguły blokowania, które zabraniają stosowania pustych parametrów zapytań, są sprawdzane jako pierwsze.
Aby uprościć kod, odwróć zachowanie, aby zezwolić na parametry zapytania i blokować identyfikatory URI bez parametrów zapytania:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:path="/path" /> <data android:queryAdvancedPattern=".+" /> </uri-relative-filter-group> ... </intent-filter>
Znaki zakodowane w identyfikatorze URI
Aby dopasować identyfikatory URI zawierające znaki zakodowane w identyfikatorze URI, w filtrze wpisz nieprzetworzone, niekodowane znaki, np.:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:query="param=value!" /> </uri-relative-filter-group> ... </intent-filter>
Filtr pasuje do
?param=value!
i?param=value%21
.Jeśli jednak w filtrze wpiszesz zakodowane znaki w ten sposób:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:query="param=value%21" /> </uri-relative-filter-group> ... </intent-filter>
Filtr nie pasuje ani do
?param=value!
, ani do?param=value%21
.Liczba elementów
W elemencie
<intent-filter>
możesz umieścić dowolną liczbę elementów<uri-relative-filter-group>
.Dodatkowe zasoby
Informacje o działaniu filtrów intencji, w tym reguły dopasowywania obiektów intencji do filtrów, znajdziesz w artykułach Intencje i filtry intencji i Filtry intencji.
Informacje o
<uri-relative-filter-group>
znajdziesz w artykułachUriRelativeFilterGroup
iUriRelativeFilter
. - Jeśli w przypadku filtra intencji nie zostanie określony parametr
- atrybuty:
-
android:allow
- Czy ta grupa filtrów względem URI jest regułą uwzględniania (zezwalania), a nie regułą wykluczania (blokowania). Wartością domyślną jest
"true"
.Wartość Opis "true"
(domyślnie)Jeśli grupa filtrów względnych identyfikatora URI pasuje, filtr intencji pasuje "false"
Jeśli grupa filtrów względnych adresów URI pasuje, filtr intencji nie pasuje
- wprowadzona w:
- Poziom API 35
- Zobacz też:
-
<intent-filter>
<data>
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2024-12-21 UTC.
[null,null,["Ostatnia aktualizacja: 2024-12-21 UTC."],[],[]]