L'utilizzo di strumenti di ispezione del codice come lint può aiutarti a individuare
risolvere problemi e migliorare il codice, ma gli strumenti di ispezione possono dedurre solo molto. ID risorsa Android,
ad esempio, utilizza int
per identificare stringhe, grafica, colori e altri tipi di risorse,
in modo che gli strumenti di ispezione non siano in grado di capire quando hai specificato una risorsa stringa in cui
ha specificato un colore. Ciò significa che l'app potrebbe non essere visualizzata correttamente o non essere eseguita.
anche se usi l'ispezione del codice.
Le annotazioni consentono di fornire suggerimenti agli strumenti di ispezione del codice, come lint, per contribuire a rilevare questi più sottili problemi di codice. Le annotazioni vengono aggiunte come tag di metadati che attribuisci alle variabili, e restituiscono valori per controllare i valori restituiti dal metodo, i parametri trasmessi, le variabili locali e campi. Se utilizzate in combinazione con gli strumenti di ispezione del codice, le annotazioni possono aiutarti a rilevare problemi quali con eccezioni e conflitti tra i tipi di risorsa e null.
Android supporta una serie di annotazioni tramite
Raccolta di annotazioni Jetpack.
Puoi accedere alla libreria tramite
androidx.annotation
pacchetto.
Nota: se un modulo ha una dipendenza da un processore di annotazione,
devi utilizzare la configurazione delle dipendenze kapt
o ksp
per Kotlin
o la configurazione delle dipendenze annotationProcessor
per Java per aggiungerlo
la dipendenza.
Aggiungi annotazioni al progetto
Per attivare le annotazioni nel tuo progetto, aggiungi androidx.annotation:annotation
alla libreria o all'app. Tutte le annotazioni che aggiungi vengono controllate quando esegui un codice
l'ispezione o l'attività lint
.
Aggiungi la dipendenza dalla libreria di annotazioni Jetpack
La raccolta di annotazioni Jetpack è pubblicata su
Repository Maven di Google.
Per aggiungere la libreria Jetpack Anotations al tuo progetto, includi quanto segue
riga nel blocco dependencies
di build.gradle
o
File build.gradle.kts
:
Kotlin
dependencies { implementation("androidx.annotation:annotation:1.8.2") }
Alla moda
dependencies { implementation 'androidx.annotation:annotation:1.8.2' }
Se utilizzi le annotazioni nel tuo modulo della biblioteca, queste verranno incluse come parte del
Artefatto Android Archive (AAR) in formato XML nel file annotations.zip
. L'aggiunta del parametro
La dipendenza androidx.annotation
non introduce una dipendenza per nessun utente downstream
della tua raccolta.
Nota: se utilizzi altre librerie Jetpack,
potrebbe non essere necessario aggiungere la dipendenza androidx.annotation
. Perché molti altri
Le librerie Jetpack dipendono dalla libreria delle annotazioni, potresti avere già accesso ai
annotazioni.
Per un elenco completo delle annotazioni incluse nel repository Jetpack, vedi
Libreria di annotazioni Jetpack
riferimento oppure utilizza la funzionalità di completamento automatico per visualizzare le opzioni disponibili
Informativa import androidx.annotation.
.
Esegui ispezioni del codice
Per avviare un'ispezione del codice da Android Studio, che include la convalida di annotazioni e controllo automatico lint, seleziona Analizza > Ispeziona il codice dalla o dal menu Fogli Google. Android Studio mostra messaggi di conflitto per segnalare potenziali problemi nei punti in cui il codice sono in conflitto con le annotazioni e suggerendo possibili risoluzioni.
Puoi anche applicare le annotazioni eseguendo il comando
lint
utilizzando la riga di comando. Questo potrebbe essere utile per segnalare problemi
con un server di integrazione continua, l'attività lint
non applica il valore nullo
annotazioni (descritte nella sezione seguente); solo Android Studio. Per ulteriori informazioni
informazioni sull'abilitazione e l'esecuzione del lint
ispezioni, consulta Migliorare il codice con lint
controlli.
Sebbene i conflitti di annotazioni generino avvisi, questi avvisi non impediscono alla tua app la compilazione.
Annotazioni nullità
Le annotazioni di nullità possono essere utili nel codice Java per stabilire se i valori possono essere nulli. Sono meno utili nel codice Kotlin, in quanto Kotlin ha delle regole incorporate nei valori null che vengono applicate durante la compilazione.Aggiungi @Nullable
e
@NonNull
annotazioni
per verificare la nullità di una determinata variabile, parametro o valore restituito. @Nullable
L'annotazione indica una variabile, un parametro o un valore restituito che può essere nullo.
@NonNull
indica una variabile, un parametro o un valore restituito che non può essere nullo.
Ad esempio, se una variabile locale contenente un valore nullo viene passata come parametro a un metodo
con l'annotazione @NonNull
associata a tale parametro, la creazione del codice genera
che indica un conflitto diverso da null. Inoltre, il tentativo di fare riferimento al risultato di
contrassegnato da @Nullable
senza prima verificare se il risultato è nullo genera
con un avviso di nullità. Utilizza solo @Nullable
sul valore restituito di un metodo
se ogni utilizzo del metodo deve essere sottoposto a controllo esplicito di null.
L'esempio seguente mostra l'uso di valori null in azione. Il codice di esempio Kotlin non sfrutta
l'annotazione @NonNull
perché viene aggiunta automaticamente al bytecode generato
quando viene specificato un tipo che non supporta i valori null. L'esempio Java utilizza l'annotazione @NonNull
sui parametri context
e attrs
per verificare che i valori dei parametri passati
non sono nulli. Controlla inoltre che il metodo onCreateView()
stesso non restituisca null:
Kotlin
... /** Annotation not used because of the safe-call operator(?)**/ override fun onCreateView( name: String?, context: Context, attrs: AttributeSet ): View? { ... } ...
Java
import androidx.annotation.NonNull; ... /** Add support for inflating the <fragment> tag. **/ @NonNull @Override public View onCreateView(String name, @NonNull Context context, @NonNull AttributeSet attrs) { ... } ...
Analisi di nullità
Android Studio supporta l'esecuzione di un'analisi dei valori NULL per l'inferenza automatica e inserisci annotazioni di nullità nel codice. Un'analisi dei dati con supporto nullo i contratti in tutte le gerarchie di metodi nel codice per rilevare:
- Metodi di chiamata che possono restituire un valore nullo.
- Metodi che non devono restituire un valore nullo.
- Variabili come campi, variabili locali e parametri, che possono essere null.
- Variabili, ad esempio campi, variabili locali e parametri, che non possono con un valore nullo.
L'analisi inserisce quindi automaticamente le annotazioni null appropriate le località rilevate.
Per eseguire un'analisi dei valori null in Android Studio, seleziona Analyze >
Deduci nullità. Android Studio inserisce le annotazioni @Nullable
e @NonNull
di Android
posizioni rilevate nel codice. Dopo aver eseguito un'analisi dei valori null, è buona norma verificare
annotazioni inserite.
Nota: quando aggiungi annotazioni di nullità, il completamento automatico potrebbe
suggerisci l'IntelliJ
@Nullable
e
@NotNull
annotazioni anziché annotazioni null Android
e importare automaticamente la libreria corrispondente. Tuttavia, Android Studio
La funzionalità di controllo pelucchi cerca solo le annotazioni null Android. Durante la verifica del
, verifica che il tuo progetto utilizzi le annotazioni Android null in modo che
lo strumento di controllo pelucchi può avvisarti in modo adeguato durante l'ispezione del codice.
Annotazioni per le risorse
La convalida dei tipi di risorse può essere utile perché i riferimenti Android alle risorse, ad esempio le risorse drawable e string, vengono passati come numeri interi.
Codice che prevede che un parametro faccia riferimento a un tipo specifico di risorsa, ad esempio String
,
può essere passato al tipo di riferimento previsto di int
, ma in realtà fa riferimento a un altro
e un tipo di risorsa, ad esempio una risorsa R.string
.
Ad esempio, aggiungi annotazioni @StringRes
a
verifica se un parametro risorsa contiene un riferimento R.string
, come mostrato qui:
Kotlin
abstract fun setTitle(@StringRes resId: Int)
Java
public abstract void setTitle(@StringRes int resId)
Durante l'ispezione del codice, l'annotazione genera un avviso se un riferimento R.string
non viene passato nel parametro.
È possibile aggiungere annotazioni per altri tipi di risorse, ad esempio @DrawableRes
, @DimenRes
, @ColorRes
e @InterpolatorRes
vengono aggiunti utilizzando lo stesso formato di annotazione ed eseguiti durante l'ispezione del codice.
Se il tuo parametro
supporta più tipi di risorse, puoi inserire più di un'annotazione del tipo di risorsa
. Usa @AnyRes
per indicare che il parametro annotato può essere qualsiasi tipo di risorsa R
.
Sebbene sia possibile usare @ColorRes
per specificare che
deve essere una risorsa colore, un numero intero colore (nei valori RRGGBB
o
AARRGGBB
) non è riconosciuto come risorsa di colore. Utilizza invece l'annotazione @ColorInt
per
indicano che un parametro deve essere un numero intero di colore. Gli strumenti di creazione contrassegneranno
il codice errato che
trasmette un ID risorsa colore come android.R.color.black
, anziché un numero intero colore,
ai metodi annotati.
Annotazioni dei thread
Le annotazioni dei thread controllano se un metodo viene chiamato da un tipo specifico di thread. Il seguente thread le annotazioni sono supportate:
Gli strumenti di creazione trattano @MainThread
@UiThread
annotazioni intercambiabili, quindi puoi chiamare @UiThread
dei metodi @MainThread
e viceversa. Tuttavia, è possibile che una UI
il thread sia diverso dal thread principale nel caso di app di sistema con più visualizzazioni
su diversi thread. Di conseguenza, devi annotare i metodi associati alla gerarchia delle visualizzazioni di un'app
con @UiThread
e annota solo i metodi associati al ciclo di vita di un'app con
@MainThread
.
Se tutti i metodi in una classe condividono lo stesso requisito di organizzazione dei thread, puoi aggiungere un singolo thread un'annotazione per la classe per verificare che tutti i metodi nella classe siano chiamati dallo stesso tipo di .
Un uso comune delle annotazioni nei thread è quello di convalidare metodi o classi annotati con
@WorkerThread
vengono chiamati solo da un thread appropriato in background.
Annotazioni dei vincoli di valore
Usa @IntRange
,
@FloatRange
e
@Size
annotazioni in
convalidare i valori dei parametri trasmessi. Sia @IntRange
che @FloatRange
sono più utili quando vengono applicati a parametri per i quali è probabile che l'intervallo sia errato.
L'annotazione @IntRange
convalida che un parametro intero o lungo
è compreso in un intervallo specificato. L'esempio seguente indica che alpha
deve contenere un valore intero compreso tra 0 e 255:
Kotlin
fun setAlpha(@IntRange(from = 0, to = 255) alpha: Int) { ... }
Java
public void setAlpha(@IntRange(from=0,to=255) int alpha) { ... }
L'annotazione @FloatRange
verifica se è presente un parametro in virgola mobile o doppio
rientra in un intervallo specificato di valori con rappresentazione in virgola mobile. L'esempio seguente indica che
Il parametro alpha
deve contenere un valore in virgola mobile compreso tra 0,0 e 1,0:
Kotlin
fun setAlpha(@FloatRange(from = 0.0, to = 1.0) alpha: Float) {...}
Java
public void setAlpha(@FloatRange(from=0.0, to=1.0) float alpha) {...}
L'annotazione @Size
controlla le dimensioni di una raccolta o
o la lunghezza di una stringa. L'annotazione @Size
può essere utilizzata per verificare
le seguenti qualità:
- Dimensioni minime, ad esempio
@Size(min=2)
- Dimensioni massime, ad esempio
@Size(max=2)
- Dimensioni esatte, ad esempio
@Size(2)
- Un numero di cui la dimensione deve essere un multiplo, ad esempio
@Size(multiple=2)
Ad esempio, @Size(min=1)
controlla se una raccolta non è vuota e @Size(3)
verifica che un array contenga esattamente tre valori.
L'esempio seguente indica che
L'array location
deve contenere almeno un elemento:
Kotlin
fun getLocation(button: View, @Size(min=1) location: IntArray) { button.getLocationOnScreen(location) }
Java
void getLocation(View button, @Size(min=1) int[] location) { button.getLocationOnScreen(location); }
Annotazioni relative alle autorizzazioni
Usa @RequiresPermission
per convalidare le autorizzazioni del chiamante per un metodo. Per verificare la presenza di una singola autorizzazione
da un elenco di autorizzazioni valide, usa l'attributo anyOf
. Per verificare l'esistenza di un insieme di
autorizzazioni, usa l'attributo allOf
. L'esempio seguente annota le
setWallpaper()
per indicare che il chiamante del metodo deve avere il metodo
Autorizzazione permission.SET_WALLPAPERS
:
Kotlin
@RequiresPermission(Manifest.permission.SET_WALLPAPER) @Throws(IOException::class) abstract fun setWallpaper(bitmap: Bitmap)
Java
@RequiresPermission(Manifest.permission.SET_WALLPAPER) public abstract void setWallpaper(Bitmap bitmap) throws IOException;
L'esempio seguente richiede il chiamante del metodo copyImageFile()
avere accesso in lettura alla memoria esterna e in lettura alla posizione
metadati nell'immagine copiata:
Kotlin
@RequiresPermission(allOf = [ Manifest.permission.READ_EXTERNAL_STORAGE, Manifest.permission.ACCESS_MEDIA_LOCATION ]) fun copyImageFile(dest: String, source: String) { ... }
Java
@RequiresPermission(allOf = { Manifest.permission.READ_EXTERNAL_STORAGE, Manifest.permission.ACCESS_MEDIA_LOCATION}) public static final void copyImageFile(String dest, String source) { //... }
Per le autorizzazioni per gli intent, inserisci il requisito di autorizzazione nel campo stringa che definisce la nome azione intent:
Kotlin
@RequiresPermission(android.Manifest.permission.BLUETOOTH) const val ACTION_REQUEST_DISCOVERABLE = "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE"
Java
@RequiresPermission(android.Manifest.permission.BLUETOOTH) public static final String ACTION_REQUEST_DISCOVERABLE = "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE";
Per le autorizzazioni per i fornitori di contenuti che richiedono autorizzazioni separate per la lettura e la scrittura
l'accesso, racchiudi ogni requisito di autorizzazione in una @RequiresPermission.Read
o @RequiresPermission.Write
annotazione:
Kotlin
@RequiresPermission.Read(RequiresPermission(READ_HISTORY_BOOKMARKS)) @RequiresPermission.Write(RequiresPermission(WRITE_HISTORY_BOOKMARKS)) val BOOKMARKS_URI = Uri.parse("content://browser/bookmarks")
Java
@RequiresPermission.Read(@RequiresPermission(READ_HISTORY_BOOKMARKS)) @RequiresPermission.Write(@RequiresPermission(WRITE_HISTORY_BOOKMARKS)) public static final Uri BOOKMARKS_URI = Uri.parse("content://browser/bookmarks");
Autorizzazioni indirette
Quando un'autorizzazione dipende dal valore specifico fornito al parametro di un metodo, utilizza
@RequiresPermission
sul parametro stesso senza elencare le autorizzazioni specifiche.
Ad esempio, startActivity(Intent)
utilizza un'autorizzazione indiretta per l'intent passato al metodo:
Kotlin
abstract fun startActivity(@RequiresPermission intent: Intent, bundle: Bundle?)
Java
public abstract void startActivity(@RequiresPermission Intent intent, @Nullable Bundle)
Quando utilizzi le autorizzazioni indirette, gli strumenti di creazione eseguono l'analisi del flusso di dati per verificare se
l'argomento passato nel metodo ha annotazioni @RequiresPermission
. Quindi
applicare in modo forzato le annotazioni esistenti dal parametro sul metodo stesso. Nella
startActivity(Intent)
esempio, le annotazioni nella classe Intent
causano gli avvisi risultanti
sugli utilizzi non validi di startActivity(Intent)
quando un intent senza l'appropriata
autorizzazioni vengono passate al metodo, come mostrato nella figura 1.
![](https://developer.android.google.cn/static/studio/images/write/indirect-permissions-warning_2-2_2x.png?authuser=8&hl=it)
Figura 1. L'avviso generato da una risposta indiretta
annotazione relativa alle autorizzazioni sul metodo startActivity(Intent)
.
Gli strumenti di creazione generano l'avviso su startActivity(Intent)
dall'annotazione
sul nome dell'azione per intent corrispondente nella classe Intent
:
Kotlin
@RequiresPermission(Manifest.permission.CALL_PHONE) const val ACTION_CALL = "android.intent.action.CALL"
Java
@RequiresPermission(Manifest.permission.CALL_PHONE) public static final String ACTION_CALL = "android.intent.action.CALL";
Se necessario, puoi sostituire @RequiresPermission
con
@RequiresPermission.Read
o @RequiresPermission.Write
durante l'annotazione
parametro di un metodo. Tuttavia, per le autorizzazioni indirette @RequiresPermission
deve
non può essere utilizzato insieme alle annotazioni delle autorizzazioni di lettura o di scrittura.
Annotazioni per i valori restituiti
Utilizza l'annotazione @CheckResult
per
verificare che il risultato o il valore restituito di un metodo sia effettivamente utilizzato. Invece di annotare ogni
non void con @CheckResult
, aggiungi l'annotazione per chiarire i risultati di
metodi che potrebbero generare confusione.
Ad esempio, i nuovi sviluppatori Java spesso pensano erroneamente che
<String>.trim()
rimuove gli spazi vuoti dalla stringa originale. Annotazione
il metodo con flag @CheckResult
utilizza di <String>.trim()
in cui il chiamante non fa nulla con il valore restituito del metodo.
L'esempio seguente annota checkPermissions()
per verificare se il valore restituito del metodo è
a cui viene fatto riferimento. Denomina anche enforcePermission()
quale metodo da suggerire allo sviluppatore in sostituzione:
Kotlin
@CheckResult(suggest = "#enforcePermission(String,int,int,String)") abstract fun checkPermission(permission: String, pid: Int, uid: Int): Int
Java
@CheckResult(suggest="#enforcePermission(String,int,int,String)") public abstract int checkPermission(@NonNull String permission, int pid, int uid);
Annotazioni CallSuper
Utilizza l'annotazione @CallSuper
per
verificare che un metodo di override chiami la super-implementazione del metodo.
Le seguenti
esempio annota il metodo onCreate()
per garantire che qualsiasi metodo di override
le implementazioni richiamano super.onCreate()
:
Kotlin
@CallSuper override fun onCreate(savedInstanceState: Bundle?) { }
Java
@CallSuper protected void onCreate(Bundle savedInstanceState) { }
Annotazioni Typedef
Le annotazioni Typedef controllano se un particolare parametro, un valore restituito o un campo fa riferimento a un insieme specifico di costanti. Consentono inoltre al completamento del codice che offrano le costanti consentite.
Utilizza @IntDef
e
@StringDef
annotazioni per creare annotazioni enumerate di set di numeri interi e stringhe per convalidare altre
tipi di riferimenti al codice.
Le annotazioni Typedef utilizzano @interface
per dichiarare il nuovo tipo di annotazione enumerata.
Le annotazioni @IntDef
e @StringDef
, insieme a
@Retention
, annotano la nuova annotazione e sono necessari per definire la
enumerato. L'annotazione @Retention(RetentionPolicy.SOURCE)
indica al compilatore
non archiviare i dati delle annotazioni enumerate nel file .class
.
L'esempio seguente mostra i passaggi per creare un'annotazione che verifica se un valore è stato passato come metodo, il parametro fa riferimento a una delle costanti definite:
Kotlin
import androidx.annotation.IntDef //... // Define the list of accepted constants and declare the NavigationMode annotation. @Retention(AnnotationRetention.SOURCE) @IntDef(NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS) annotation class NavigationMode // Declare the constants. const val NAVIGATION_MODE_STANDARD = 0 const val NAVIGATION_MODE_LIST = 1 const val NAVIGATION_MODE_TABS = 2 abstract class ActionBar { // Decorate the target methods with the annotation. // Attach the annotation. @get:NavigationMode @setparam:NavigationMode abstract var navigationMode: Int }
Java
import androidx.annotation.IntDef; //... public abstract class ActionBar { //... // Define the list of accepted constants and declare the NavigationMode annotation. @Retention(RetentionPolicy.SOURCE) @IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS}) public @interface NavigationMode {} // Declare the constants. public static final int NAVIGATION_MODE_STANDARD = 0; public static final int NAVIGATION_MODE_LIST = 1; public static final int NAVIGATION_MODE_TABS = 2; // Decorate the target methods with the annotation. @NavigationMode public abstract int getNavigationMode(); // Attach the annotation. public abstract void setNavigationMode(@NavigationMode int mode); }
Quando crei questo codice, viene generato un avviso se il parametro mode
non corrisponde
fare riferimento a una delle costanti definite (NAVIGATION_MODE_STANDARD
,
NAVIGATION_MODE_LIST
o NAVIGATION_MODE_TABS
).
Combina @IntDef
e @IntRange
per indicare che un
un numero intero può essere un insieme dato di costanti o un valore all'interno di un intervallo.
Attiva la combinazione di costanti e flag
Se gli utenti possono combinare le costanti consentite con un flag (ad esempio |
,
&
, ^
e così via), puoi definire un'annotazione con un
flag
per verificare se un parametro o un valore restituito fa riferimento a un pattern valido.
L'esempio seguente crea l'annotazione DisplayOptions
con un elenco di valori validi
Costanti DISPLAY_
:
Kotlin
import androidx.annotation.IntDef ... @IntDef(flag = true, value = [ DISPLAY_USE_LOGO, DISPLAY_SHOW_HOME, DISPLAY_HOME_AS_UP, DISPLAY_SHOW_TITLE, DISPLAY_SHOW_CUSTOM ]) @Retention(AnnotationRetention.SOURCE) annotation class DisplayOptions ...
Java
import androidx.annotation.IntDef; ... @IntDef(flag=true, value={ DISPLAY_USE_LOGO, DISPLAY_SHOW_HOME, DISPLAY_HOME_AS_UP, DISPLAY_SHOW_TITLE, DISPLAY_SHOW_CUSTOM }) @Retention(RetentionPolicy.SOURCE) public @interface DisplayOptions {} ...
Quando crei un codice con un flag di annotazione, viene generato un avviso se il parametro decorato o il valore restituito non fa riferimento a un pattern valido.
Mantieni annotazione
@Keep
annotazione garantisce che una classe o un metodo annotato non venga rimosso quando il codice
viene minimizzato al momento della creazione. Questa annotazione è in genere
a metodi e classi a cui si accede attraverso la riflessione per impedire al compilatore
trattando il codice come inutilizzato.
Attenzione : le classi e i metodi a cui aggiungi annotazioni
che utilizzano @Keep
vengono sempre visualizzati nell'APK dell'app, anche se non
fare riferimento a queste classi e a questi metodi nella logica della tua app.
Per contenere le dimensioni dell'app, valuta se è necessario mantenere
ogni annotazione @Keep
nella tua app. Se usi la riflessione per
per accedere a una classe o a un metodo annotati, utilizza
condizionale -if
nelle regole di ProGuard, specificando la classe
che genera il richiamo della riflessione.
Per ulteriori informazioni su come minimizzare il codice e specificare quale codice non deve essere rimosso, consulta Ridurre, offuscare e ottimizzare l'app.
Annotazioni sulla visibilità del codice
Utilizza le seguenti annotazioni per indicare la visibilità di parti specifiche del codice, come metodi, classi, campi o pacchetti.
Rendi visibile il codice per i test
La
@VisibleForTesting
l'annotazione indica che un metodo annotato è più visibile del solito necessario per
testabile. Questa annotazione ha un argomento facoltativo otherwise
che ti consente
indicare la visibilità del metodo se non per la necessità di renderlo visibile
per i test. Lint utilizza l'argomento otherwise
per applicare la visibilità prevista.
Nell'esempio seguente, myMethod()
è solitamente private
, ma è
package-private
per i test. Con VisibleForTesting.PRIVATE
designazione, lint visualizza un messaggio se questo metodo viene chiamato dall'esterno
contesto consentito dall'accesso private
, ad esempio da un'unità di compilazione diversa.
Kotlin
@VisibleForTesting(otherwise = VisibleForTesting.PRIVATE) fun myMethod() { ... }
Java
@VisibleForTesting(otherwise = VisibleForTesting.PRIVATE) void myMethod() { ... }
Puoi anche specificare @VisibleForTesting(otherwise = VisibleForTesting.NONE)
per indicare che un metodo esiste solo per i test. Questo modulo equivale all'utilizzo
@RestrictTo(TESTS)
. Entrambi eseguono lo stesso controllo del lint.
Limita un'API
@RestrictTo
l'annotazione indica che l'accesso all'API annotata (pacchetto, classe o metodo) è limitato,
come segue:
Sottoclassi
Utilizza il modulo di annotazione @RestrictTo(RestrictTo.Scope.SUBCLASSES)
per limitare
Accesso API solo alle sottoclassi.
Solo le classi che estendono la classe annotata possono accedere a questa API. Java
Il modificatore protected
non è abbastanza restrittivo perché consente l'accesso
da classi non correlate all'interno dello stesso pacchetto. Inoltre, ci sono casi in cui vuoi abbandonare una
metodo public
per flessibilità futura, perché non sarà mai possibile
protected
e il metodo di cui è stato eseguito l'override public
, ma vuoi fornire un valore
suggerisce che la classe è destinata solo agli utilizzi all'interno della classe o solo dalle sottoclassi.
Biblioteche
Utilizza il modulo di annotazione @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP_PREFIX)
per
limitare l'accesso API solo alle tue librerie.
Solo il tuo codice libreria può accedere all'API annotata. Questo ti consente non solo di organizzare il codice
nella gerarchia di pacchetti desiderata, ma anche condividere
il codice in un gruppo di librerie correlate. Questa opzione è già disponibile per il Jetpack
contenenti una grande quantità di codice di implementazione che non è destinato all'uso esterno, ma che
deve essere public
per condividerlo tra le varie librerie Jetpack complementari.
Test
Utilizza il modulo di annotazione @RestrictTo(RestrictTo.Scope.TESTS)
per impedire ad altri
agli sviluppatori di accedere alle API di test.
Solo il codice di test può accedere all'API annotata. Questo impedisce ad altri sviluppatori di non utilizzare le API per lo sviluppo contenuto solo a scopo di test.