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




(11)

Esiste una chiamata simile, isUserAMonkey() , che restituisce true se viene utilizzato lo strumento MonkeyRunner . La spiegazione dell'SDK è altrettanto curiosa di questa.

public static boolean isUserAMonkey(){}     

Restituisce true se l'interfaccia utente viene attualmente incasinata da una scimmia.

Here la fonte.

Mi aspetto che questo sia stato aggiunto in previsione di un nuovo tool SDK chiamato qualcosa con una capra e sarà effettivamente funzionale per testare la presenza di quello strumento.

Vedi anche una domanda simile, Strana funzione in ActivityManager: isUserAMonkey. Cosa significa questo, qual è il suo uso? .

Stavo guardando le nuove API introdotte in Android 4.2 . Osservando la classe UserManager mi sono imbattuto nel 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?


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

L'unico utilizzo pratico che ho mai visto è stato nel concorso Last Call per Google I / O Contest in cui è stato chiesto che cosa fosse per una versione specifica, per verificare se i concorrenti leggessero 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.


Si prega di consultare il seguente codice sorgente:

/**
 * 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");
}

Google ha una grande passione per le uova di Pasqua di capra e capra. Ci sono stati anche precedenti messaggi su di esso .

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 supporre che si tratta semplicemente di un uovo di Pasqua e non ha alcun utilizzo nel mondo reale, tranne che per restituire false .


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

Ad 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. ;-)


Non so se questo è stato il "caso d'uso ufficiale", ma quanto segue produce un avvertimento in Java (che può produrre ulteriori errori di compilazione se combinato con dichiarazioni di return , che portano a un 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 indica if (false) non innesca un "codice irraggiungibile" per il motivo specifico che ciò interromperà il supporto per i flag di debug, cioè, in pratica, questo caso d'uso (h / t @auselen). ( static final boolean DEBUG = false; ad esempio).

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


Uovo di Pasqua divertente.
Nella versione Ubuntu di Chrome, in Task Manager ( shift + esc ), con il tasto destro puoi aggiungere una colonna fantascientifica che nella versione italiana è "Capre Teletrasportate" (Teleported Goats).

Una divertente teoria a riguardo è here .


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 Gestione attività con Shift + Esc .
  2. Fare clic con il tasto destro per aggiungere la colonna Goats Teleported .
  3. Meravigliarsi.

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

Il seguente snippet di codice sorgente Chromium viene rubato dai commenti HN .

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

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

isUserAGoat() potrebbe essere usato al posto di una dichiarazione di variabile fittizia che verrà mostrata nell'IDE come avvertenza e, nel caso particolare di 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?).

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).


A partire da API 21 (il primo Android 5.0 / Lollipop SDK) , questo rileva se l'app Goat Simulator è 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 che il suggerimento di djechlin di usarlo come privo di avvisi if (false) è una strategia potenzialmente disastrosa. Ciò che in precedenza veniva restituito come false per ogni dispositivo ora restituisce un valore apparentemente casuale: se questo è stato sepolto abbastanza in profondità nel codice, potrebbe essere necessario molto 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.


Ecco un commento dalla risposta di Steve Moseley (di ToolmakerSteve ) che mette le cose in prospettiva (in tutto onSaveInstanceState vs onPause, costi est vs saga dei costi ovest)

@VVK - Sono parzialmente in disaccordo. Alcuni modi per uscire da un'app non attivano onSaveInstanceState (oSIS). Ciò limita l'utilità di oSIS. Vale la pena supportare, per risorse OS minime, ma se un'app vuole restituire l'utente allo stato in cui si trovava, indipendentemente dall'uscita dall'app, è invece necessario utilizzare un approccio di memorizzazione permanente. Uso onCreate per verificare la presenza di bundle e, se manca, controlla la memoria permanente. Questo centralizza il processo decisionale. Posso recuperare da un arresto anomalo, uscire dal pulsante Indietro o dalla voce di menu personalizzata Esci o tornare all'utente dello schermo dopo molti giorni. - ToolmakerSteve 19 settembre 15 alle 10:38







java android usermanager