Domanda Casi di utilizzo appropriati per Android UserManager.isUserAGoat ()?


Stavo guardando le nuove API introdotte in Android 4.2. Mentre guardi il UserManager classe ho trovato il seguente metodo:

 public boolean isUserAGoat()

Utilizzato per determinare se l'utente che effettua questa chiamata è soggetto a teletrasporto.

Restituisce se l'utente che effettua questa chiamata è una capra.

Come e quando dovrebbe essere usato?


3140
2017-11-14 08:34


origine


risposte:


Da loro fonte, il metodo utilizzato per tornare false fino a quando non è stato modificato in API 21.

/**
 * Used to determine whether the user making this call is subject to
 * teleportations.
 * @return whether the user making this call is a goat 
 */
public boolean isUserAGoat() {
    return false;
}

Sembra che il metodo non abbia reale utilità per noi come sviluppatori. Qualcuno ha precedentemente affermato che potrebbe essere un uovo di Pasqua.

Nell'API 21 l'implementazione è stata modificata per verificare se è presente un'app installata con il pacchetto com.coffeestainstudios.goatsimulator

/**
 * Used to determine whether the user making this call is subject to
 * teleportations.
 *
 * <p>As of {@link android.os.Build.VERSION_CODES#LOLLIPOP}, this method can
 * now automatically identify goats using advanced goat recognition technology.</p>
 *
 * @return Returns true if the user making this call is a goat.
 */
public boolean isUserAGoat() {
    return mContext.getPackageManager()
            .isPackageAvailable("com.coffeestainstudios.goatsimulator");
}

Ecco il link sorgente


1512
2017-11-14 08:40



Non so se questo era "il" caso d'uso ufficiale, ma il seguente produce un avvertimento in Java (che può produrre ulteriori errori di compilazione se mescolato con return dichiarazioni, che portano a codice non raggiungibile):

while (1 == 2) { // Note that "if" is treated differently
    System.out.println("Unreachable code");
}

Tuttavia questo è legale:

while (isUserAGoat()) {
    System.out.println("Unreachable but determined at runtime, not at compile time");
}

Così spesso mi trovo a scrivere un metodo di utilità stupido per il modo più veloce di svuotare un blocco di codice, quindi nel completare il debug trovare tutte le chiamate ad esso, quindi a condizione che l'implementazione non cambi questo può essere usato per quello.

JLS sottolinea if (false) non innesca un "codice irraggiungibile" per il motivo specifico che ciò interromperà il supporto per i flag di debug, ovvero, in pratica, questo caso d'uso (h / t @auselen). (static final boolean DEBUG = false; per esempio).

Ho sostituito while per if, producendo un caso d'uso più oscuro. io credere puoi scattare il tuo IDE, come Eclipse, con questo comportamento, ma questa modifica è di 4 anni nel futuro, e non ho un ambiente Eclipse con cui giocare.


916
2017-11-14 14:47



Questo sembra essere uno scherzo di Google. È anche presente nel task manager di Google Chrome. Non ha uno scopo, a parte alcuni ingegneri che lo trovano divertente. Che è uno scopo di per sé, se vuoi.

  1. In Chrome, apri il Task Manager con Cambio+Esc.
  2. Fare clic con il tasto destro per aggiungere il Goats Teleported colonna.
  3. Meravigliarsi.

C'è anche un enorme bug bug su Chromium troppe capre teletrasportate.

chrome 

Il seguente Chromium snippet di codice sorgente è rubato dal HN Commenti.

int TaskManagerModel::GetGoatsTeleported(int index) const {
  int seed = goat_salt_ * (index + 1);
  return (seed >> 16) & 255;
}

706
2017-11-14 09:03



Complementare a @djechlin risposta (buona risposta a proposito!), questa chiamata di funzione potrebbe essere anche utilizzato come codice fittizio per contenere un punto di interruzione in un IDE quando si desidera interrompere in qualche iterazione specifica o una chiamata ricorsiva particolare, ad esempio:

enter image description here

isUserAGoat() potrebbe essere usato al posto di una dichiarazione di variabile fittizia che verrà mostrata nell'IDE come avvertenza e, nel caso specifico Eclipse, ostruirà il segno di interruzione, rendendo difficile abilitarlo / disabilitarlo. Se il metodo è usato come convenzione, tutte le invocazioni potrebbero essere successivamente filtrate da qualche script (durante la fase di commit forse?).

enter image description here

I ragazzi di Google sono utenti pesanti di Eclipse (forniscono molti dei loro progetti come plugin di Eclipse: Android SDK, GAE, ecc.), Quindi la risposta di @djechlin e questa risposta complementare hanno molto senso (almeno per me).


258
2017-11-21 16:55



C'è un metodo chiamato divertente / costante / qualunque sia in ogni versione di Android.

L'unico uso pratico che abbia mai visto è stato nell'ultima richiesta di Google I / O Contest in cui hanno chiesto cosa fosse per una versione specifica, per vedere se i concorrenti leggono il rapporto diffettivo API per ogni versione. Il concorso aveva anche problemi di programmazione, ma in generale alcune banalità che potevano essere classificate automaticamente prima di ottenere il numero di sottomissioni a importi ragionevoli che sarebbero più facili da controllare.


122
2017-11-14 17:26



Nella disciplina del riconoscimento vocale, gli utenti sono divisi in capre e pecore.

Per esempio, qui a pagina 89:

Le pecore sono persone per le quali il riconoscimento vocale funziona eccezionalmente bene e le capre sono persone per le quali funziona eccezionalmente male. Solo il riconoscitore vocale sa cosa li separa. Le persone non possono prevedere la cui voce sarà riconosciuta facilmente e di chi no. La migliore politica è progettare l'interfaccia in modo che possa gestire tutti i tipi di voci in tutti i tipi di ambienti

Forse, si prevede di contrassegnare gli utenti Android come capre in futuro per poter configurare il motore di riconoscimento vocale per le esigenze delle capre. ;-)


110
2018-05-31 09:33



Google ha un grosso interesse per le capre e le capre uova di Pasqua. Ce n'è stato perfino precedenti messaggi Stack Overflow a riguardo.

Come è stato menzionato nei post precedenti, esiste anche all'interno del task manager di Chrome (è apparso per la prima volta in natura nel 2009):

<message name="IDS_TASK_MANAGER_GOATS_TELEPORTED_COLUMN" desc="The goats teleported column">
    Goats Teleported
</message>

E poi in Windows, nelle versioni Linux e Mac di Chrome all'inizio del 2010). Il numero di "Goat Teleported" è in effetti casuale:

 int TaskManagerModel::GetGoatsTeleported(int index) const {
     int seed = goat_salt_ * (index + 1);
     return (seed >> 16) & 255;
 }

Altri riferimenti di Google alle capre includono:

La prima correlazione tra le capre e Google appartiene al post sul blog originale "Falciare le capre", per quanto ne so.

Possiamo tranquillamente presumere che si tratta semplicemente di un uovo di Pasqua e non ha alcun uso reale, tranne che per il ritorno false.


104
2017-11-15 10:33



A partire da API 21 (il primo Android 5.0 / Lollipop SDK), questo rileva se il Simulatore di capra l'app è installata:

/**
 * Used to determine whether the user making this call is subject to
 * teleportations.
 *
 * <p>As of {@link android.os.Build.VERSION_CODES#LOLLIPOP}, this method can
 * now automatically identify goats using advanced goat recognition technology.</p>
 *
 * @return Returns true if the user making this call is a goat.
 */
public boolean isUserAGoat() {
    return mContext.getPackageManager()
            .isPackageAvailable("com.coffeestainstudios.goatsimulator");
}

Questo dovrebbe chiarire questo il suggerimento di djechlin di usarlo come privo di avvisi if (false) è una strategia potenzialmente disastrosa. Cosa precedentemente restituito false per ogni dispositivo ora restituisce un valore apparentemente casuale: se questo è stato sepolto abbastanza in profondità nel tuo codice potrebbe prendere un lungo tempo per capire da dove provengono i nuovi bug.

In conclusione: se non si controlla l'implementazione di un metodo e si decide di utilizzarlo per scopi diversi da quelli indicati nella documentazione dell'API, si sta andando verso i problemi.


101
2017-10-20 10:00