java Cas d'utilisation appropriés pour Android UserManager.isUserAGoat ()?



6 Answers

Je ne sais pas s'il s'agissait "du" cas d'utilisation officiel, mais les éléments suivants produisent un avertissement en Java (pouvant générer d'autres erreurs de compilation s'il est mélangé à des instructions return , ce qui conduit à un code inaccessible):

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

Cependant c'est légal:

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

Je me retrouve donc souvent en train d'écrire une méthode utilitaire stupide pour trouver le moyen le plus rapide d'extraire un bloc de code, puis, en finissant le débogage, trouver tous les appels qui lui sont destinés.

JLS indique if (false) ne déclenche pas de "code inaccessible" pour la raison précise qui aurait pour effet de casser le support des indicateurs de débogage, c'est-à-dire, fondamentalement, ce cas d'utilisation (h / t @auselen). ( static final boolean DEBUG = false; par exemple).

J'ai remplacé while pour if , produisant un cas d'utilisation plus obscur. Je pense que vous pouvez déclencher votre comportement dans l'IDE, comme Eclipse, avec ce comportement, mais cette modification est dans 4 ans et je n'ai pas d'environnement Eclipse pour jouer.

java android usermanager

Je regardais les nouvelles API introduites dans Android 4.2 . En regardant la classe UserManager , je suis tombé sur la méthode suivante:

public boolean isUserAGoat()

Utilisé pour déterminer si l'utilisateur effectuant cet appel est sujet à des téléportations.

Indique si l'utilisateur effectuant cet appel est une chèvre.

Comment et quand cela devrait-il être utilisé?




En complément de la answer @djechlin (bonne réponse en passant!), Cet appel de fonction peut également être utilisé comme code factice pour conserver un point d'arrêt dans un environnement de développement intégré lorsque vous souhaitez vous arrêter dans une itération spécifique ou un appel récursif particulier, par exemple:

isUserAGoat() pourrait être utilisé à la place d'une déclaration de variable factice qui sera affichée dans l'EDI comme un avertissement et, dans le cas particulier d'Eclipse, obstruerait le point d'arrêt, ce qui rendrait plus difficile son activation / désactivation. Si la méthode est utilisée comme convention, toutes les invocations pourraient être filtrées ultérieurement par un script (au cours de la phase de validation?).

Les gars de Google sont de gros utilisateurs d’Eclipse (ils fournissent plusieurs de leurs projets sous forme de plug-ins Eclipse: SDK Android, GAE, etc.). La réponse @djechlin et cette réponse complémentaire ont donc beaucoup de sens (du moins pour moi).




Dans la discipline de la reconnaissance vocale, les utilisateurs sont divisés en chèvres et moutons .

Par exemple, ici à la page 89 :

Les moutons sont des personnes pour qui la reconnaissance vocale fonctionne exceptionnellement bien, et les chèvres sont des personnes pour qui cela fonctionne exceptionnellement mal. Seul le système de reconnaissance vocale sait ce qui les sépare. Les gens ne peuvent pas prédire quelle voix sera reconnue et qui ne le sera pas. La meilleure politique consiste à concevoir l'interface de manière à ce qu'elle puisse gérer toutes sortes de voix dans tous types d'environnements

Peut-être qu’il est prévu de marquer les utilisateurs d’Android comme des chèvres à l’avenir afin de pouvoir configurer le moteur de reconnaissance vocale pour les besoins des chèvres. ;-)




Dès l’API 21 (le premier SDK Android 5.0 / Lollipop) , il détecte si l’application Goat Simulator est installée:

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

Cela devrait indiquer clairement que la suggestion de djechlin de l'utiliser comme un système sans avertissement if (false) est une stratégie potentiellement désastreuse. Ce qui était précédemment renvoyé par false pour chaque périphérique renvoie maintenant une valeur apparemment aléatoire: si cela était enfoui suffisamment profondément dans votre code, il pourrait prendre beaucoup de temps pour déterminer la provenance de vos nouveaux bogues.

En bout de ligne: si vous ne contrôlez pas la mise en œuvre d'une méthode et décidez de l'utiliser à des fins autres que celles indiquées dans la documentation de l'API, vous vous dirigez vers des problèmes.




Dans les montagnes les plus reculées de la planète, se trouve une espèce de chèvre avancée qui semble être en mesure d'utiliser un téléphone, tout comme nous, les humains!

Images perdues: youtu.be/YJwZMUn7GdQ

Google doit avoir repéré cela et décidé de leur fournir un soutien, afin de rester à la pointe du progrès technologique.




S'il vous plaît voir le code source ci-dessous:

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



Related