<uri-relative-filter-group>

<uri-relative-filter-group android:allow=["true" | "false"]>
  <data ... />
  ...
</uri-relative-filter-group>

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&param2=value2&param3=value3ponieważ 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&param1=value1, ponieważ kolejność parametrów zapytania nie ma znaczenia. Filtr nie pasuje jednak do kolumny https://project.example.com/any/path/here?param1=value1, w której brakuje kolumny param2=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ę na suffix.

Natomiast w następującym przykładzie pasują ścieżki, które zaczynają się od /prefix i kończą na suffix:

<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, atrybut port i wszystkie atrybuty path* 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 identyfikatora Intent w zależności od obecności lub wartości parametru zapytania. Aby utworzyć filtr intencji, który pasuje do wyrażenia https://project.example.com/path i blokuje wyrażenie https://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?querydopasowuje 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łach UriRelativeFilterGroup i UriRelativeFilter.

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