<uri-relative-filter-group>

składnia:
<uri-relative-filter-group android:allow=["true" | "false"]>
  <data ... />
  ...
</uri-relative-filter-group>
zawiera się w:
<intent-filter>
Może zawierać:
<data>
description:
Tworzy precyzyjne reguły dopasowywania Intent, które mogą zawierać parametry zapytania URI i fragmenty URI. W zależności od atrybutu android:allow reguły mogą być regułami uwzględniania (zezwalającymi) lub wykluczania (blokującymi). Reguły dopasowywania są określone przez atrybuty path*, fragment* i query* elementów <data>.

Dopasowywanie

Aby dopasować identyfikator URI, każda część grupy filtrów względnych identyfikatora URI musi pasować do części identyfikatora URI. Mogą istnieć części identyfikatora URI, które nie są określone w grupie filtrów względnych identyfikatora URI. Na 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=value3 , ponieważ zawiera wszystkie elementy określone przez grupę filtrów URI względny. Filtr pasuje też do adresu URL https://project.example.com/any/path/here?param2=value2&param1=value1, ponieważ kolejność parametrów zapytania nie ma znaczenia. Filtr nie pasuje jednak do https://project.example.com/any/path/here?param1=value1, w którym brakuje param2=value2.

OR i AND

Tagi <data> poza elementem <uri-relative-filter-group> są łączone operatorem OR, a tagi <data> w elemencie <uri-relative-filter-group> są łączone operatorem AND.

Przyjrzyj się temu przykładowi: 

<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 następny przykład pasuje do ścieżek, które zaczynają się od /prefix I kończą się 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 <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

Przyjrzyj się temu przykładowi:

<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 zostało znalezione przed oceną reguły wykluczania, ale fragmenty takie jak #fragment123 nie pasują.

Tagi pokrewne

<uri-relative-filter-group>Tagi współpracują z tagami <data> (czyli tagami <data>, które znajdują się poza tagiem <uri-relative-filter-group>, ale w tym samym tagu <intent-filter>). Tagi <uri-relative-filter-group> muszą mieć tagi <data>, aby działać prawidłowo, ponieważ atrybuty URI są wzajemnie zależne na poziomie <intent-filter>:

  • Jeśli dla filtra intencji nie określono elementu scheme, wszystkie pozostałe atrybuty URI są ignorowane.
  • Jeśli dla filtra nie określono atrybutu host, atrybut port i wszystkie atrybuty path* są ignorowane.

Elementy podrzędne <data> elementu <intent-filter> są oceniane przed tagami <uri-relative-filter-group>. Następnie tagi <uri-relative-filter-group> są oceniane po kolei, np.: 

<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 wartość https://project.example.com/path?query, ponieważ pasuje ona do wzorca <data android:path="/path" />, który nie jest objęty regułą wykluczania <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 https://project.example.com/path i blokuje https://project.example.com/path?query, możesz użyć takiego kodu: 

<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 jednak nie działa. https://project.example.com/path?query URI dopasowuje ścieżkę /path, a tag <uri-relative-filter-group> umożliwia dopasowywanie dodatkowych części.

Zmodyfikuj filtr intencji 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ż najpierw są sprawdzane reguły blokowania, które zabraniają stosowania niepustych parametrów zapytania.

Aby uprościć kod, odwróć działanie, tak aby zezwalać 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 formacie URI, wpisz w filtrze nieprzetworzone, niezakodowane 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 wpiszesz w filtrze 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 <uri-relative-filter-group> możesz umieścić dowolną liczbę elementów <intent-filter>.

Dodatkowe materiały

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 oraz Filtry intencji.

Informacje o <uri-relative-filter-group> znajdziesz w sekcjach UriRelativeFilterGroup i UriRelativeFilter.

atrybuty:
android:allow
Określa, czy ta grupa filtrów względnych identyfikatorów URI jest regułą uwzględniania (zezwalającą), a nie regułą wykluczania (blokującą). Wartością domyślną jest "true".
Wartość Opis
"true" (domyślnie) Jeśli grupa filtrów względnych identyfikatorów URI pasuje, filtr intencji pasuje
"false" Jeśli grupa filtrów względnych identyfikatora URI pasuje, filtr intencji nie pasuje.
wprowadzony w:
Poziom API 35
Zobacz też:
<intent-filter>
<data>