Правильные варианты использования Android UserManager.isUserAGoat ()?

Похоже, это внутренняя шутка в Google. Он также присутствует в диспетчере задач Google Chrome. У него нет никакой цели, кроме того, что некоторые инженеры находят это забавным. Что, если хотите, само по себе является целью.

1. В Chrome откройте диспетчер задач, нажав Shift + Esc .
2. Щелкните правой кнопкой мыши, чтобы добавить столбец Goats Teleported.
3. Удивляться.

Существует даже огромный отчет об ошибке Chromium о слишком большом количестве телепортированных коз.

Следующий Chromium фрагмент исходного кода украден из комментариев HN.

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

Дополняя @djechlin ответ (кстати, хороший ответ!), Этот вызов функции может быть также используется как фиктивный код для удержания точки останова в среде IDE, когда вы хотите остановиться на определенной итерации или конкретном рекурсивном вызове, например:

isUserAGoat() можно использовать вместо фиктивного объявления переменной, которое будет отображаться в среде IDE как предупреждение и, в конкретном случае Eclipse, засоряет метку точки останова, затрудняя ее включение / отключение. Если метод используется в качестве соглашения, все вызовы могут быть позже отфильтрованы каким-либо сценарием (возможно, во время фазы фиксации?).

Ребята из Google - активные пользователи Eclipse (они предоставляют несколько своих проектов в виде плагинов Eclipse: Android SDK, GAE и т. Д.), Поэтому ответ @djechlin и этот дополнительный ответ имеют большой смысл (по крайней мере, для меня).

В каждой версии Android есть забавный именованный метод / константа / что угодно.

Единственное практическое применение, которое я когда-либо видел, было на конкурсе Last Call для Google I / O, где они спросили, что это было для конкретной версии, чтобы узнать, читают ли участники отчет о различиях API для каждого выпуска. У конкурса тоже были проблемы с программированием, но, как правило, некоторые мелочи, которые можно было сначала оценить автоматически, чтобы уменьшить количество представленных работ до разумных сумм, которые было бы легче проверить.

В области распознавания речи пользователи делятся на козлы и овцы .

Например, здесь на стр. 89 :

Овцы - это люди, для которых распознавание речи работает исключительно хорошо, а козы - это люди, для которых это работает исключительно плохо. Только распознаватель голоса знает, что их разделяет. Люди не могут предсказать, чей голос будет легко узнать, а чей нет. Лучшая политика - разработать интерфейс так, чтобы он мог обрабатывать все виды голосов в любых средах.

Возможно, в будущем планируется помечать пользователей Android как козлов, чтобы иметь возможность настраивать движок распознавания речи под нужды козлов. ;-)

Как API 21 (первый Android 5.0 / Lollipop SDK), это определяет, есть ли Приложение Goat Simulator установлено:

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

Это должно дать понять, что предложение Джехлина об использовании эта стратегия без предупреждений if (false) потенциально губительна. То, что раньше возвращало false для каждого устройства, теперь возвращает кажущееся случайным значение: если это было достаточно глубоко закопано в вашем коде, может потребоваться много времени, чтобы выяснить, откуда появляются ваши новые ошибки. .

Итог: если вы не контролируете реализацию метода и решаете использовать его для целей, отличных от указанных в документации по API, вы столкнетесь с проблемами.

Google очень любит козлов и козлиных пасхальных яиц. Были даже предыдущие сообщения о переполнении стека об этом.

Как уже упоминалось в предыдущих сообщениях, он также существует в диспетчере задач Chrome (впервые появился в 2009 году):

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

А затем в версиях Chrome для Windows, Linux и Mac в начале 2010 г.). Количество "Телепортированных коз" на самом деле random:

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

Другие ссылки Google на коз включают:

• Кошение с козами
• Козы баааахк

Насколько я могу судить, самое раннее сопоставление козлов и Google относится к оригинальному сообщению в блоге «Кошение с козами».

Мы можем с уверенностью предположить, что это просто пасхальное яйцо и не имеет никакого реального использования, кроме как для возврата false.

Есть аналогичный вызов isUserAMonkey(), который возвращает истину, если инструмент MonkeyRunner используется. Объяснение SDK столь же любопытно, как и это.

Вот источник.

Я ожидаю, что это было добавлено в ожидании нового инструмента SDK, который назвал что-то с козой и будет < em> на самом деле быть работоспособным, чтобы проверить наличие этого инструмента.

Также см. Аналогичный вопрос: Странно функция в ActivityManager: isUserAMonkey. Что это значит, какова его польза? .

Веселое пасхальное яйцо.
В версии Chrome для Ubuntu в диспетчере задач ( shift + esc ), щелкнув правой кнопкой мыши, вы можете добавить научно-фантастический столбец, который в итальянской версии называется «Capre Teletrasportate». (Телепортированные козы).

Забавная теория об этом: здесь.

Это не шутка изнутри

Видимо это всего лишь программа проверки приложений для Goat Simulator - от Coffee Stain Studios

Если у вас установлен Goat Simulator, вы козел. Если он у вас не установлен, вы не козел.

Я полагаю, что это был скорее личный эксперимент одного из разработчиков, скорее всего, чтобы найти людей с общими интересами.

Я не знаю, было ли это "официальным" вариантом использования, но следующее вызывает предупреждение в Java (которое может привести к ошибкам компиляции, если они смешаны с операторами return, что приведет к недостижимому коду):

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

Однако это законно:

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

Поэтому я часто замечаю, что пишу глупый служебный метод для наиболее быстрого способа фиксации блока кода, а затем при завершении отладки найти все его вызовы, поэтому при условии, что реализация не меняет, это можно использовать для этого.

JLS указывает if (false) не запускает «недоступный код» по той конкретной причине, что это нарушит поддержку флагов отладки, то есть в основном в этом варианте использования (h / t @auselen). (Например, static final boolean DEBUG = false;).

Я заменил while на if, создав более неясный вариант использования. Я верю , что вы можете сбить с толку свою IDE, такую ​​как Eclipse, с таким поведением, но это изменение произойдет на 4 года в будущем, и у меня нет среды Eclipse, с которой можно было бы поиграть.