Большая часть читаемого способа выписать простой условный чек
Перед запуском медиапроигрывателя, пожалуйста, проверьте, чтобы один раз не был равен нулю (! = Nu)
Как показано ниже
play=findViewById(R.id.play);
mediaPlayer = MediaPlayer.create(MainPlay.this, R.raw.click);
play.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if(mediaPlayer!=null)
mediaPlayer.start();
});
Или я предлагаю инициализировать медиаплеер за пределами клика, потому что вы пытаетесь немедленный доступ к медиа-плееру может стать причиной истечения нуля
7 ответов
if (HasPassword() && HasStation() && HasUserName())
okButton.setEnabled(true);
bool HasPassword() {
return passwordField.getPassword().length > 0;
}
и т. Д.
Обратите внимание, что опция 1 не допускает короткого замыкания. Таким образом, вы вычисляете значение всех условных выражений перед оценкой результата первого.
I would modify option 1 so that you're using variable names that actually have a meaning. That is, change the name of "c2" to be something like "stationIDIsEmpty" (and move the NOT into the conditional). That way the conditional is readable without having to glance back and forth for every variable.
So my code would probably look like:
boolean enteredPassword = passwordField.getPassword().length > 0;
boolean stationIDIsEmpty = stationIDTextField.getText().trim().isEmpty();
boolean userNameIsEmpty = userNameTextField.getText().trim().isEmpty();
if (enteredPassword && !stationIDIsEmpty && !userNameIsEmpty) {
okButton.setEnabled(true);
}
Я проголосовал за ответ Криса Брандсмы.
Но я просто хотел упомянуть главную проблему, которая у меня возникла с вариантом 1, - вы теряете преимущество &&. С первым вариантом, хотя я думаю, что он более читабелен, вы обрабатываете сравнения, когда они могут не потребоваться.
Я предпочитаю следующее:
if (passwordField.getPassword().length > 0
&& ! stationIDTextField.getText().trim().isEmpty()
&& ! userNameTextField.getText().trim().isEmpty())
{
okButton.setEnabled(true);
}
С этим стилем кодирования я выполняю две вещи:
- Я легко вижу, что каждая дополнительная строка if является частью условия из-за && (или ||) в начале.
- Я легко вижу, где заканчивается оператор if из-за {на следующей строке.
Лично мне нравится второй способ, потому что я считаю, что использование этого способа может прояснить предопределение условных выражений. То есть, если этот метод выполнен правильно, вы можете сделать его условно понятным, «проверив» его (независимо от того, говорите ли вы на самом деле, это не имеет значения).
То есть со вторым вариантом становится ясно, что ваш условный перевод примерно так: «Если длина пароля больше нуля, И stationIDTextField (обрезанный) НЕ пуст, И usernameTextField (обрезанный) НЕ пустой, то ...»
Параметр 1 является основным для применения рефакторинга ' Заменить temp на Запрос ». Причина в том, что кто-то может вставить код между переменной, инициализировать и проверять и изменять поведение кода. Или проверка может быть сделана с устаревшими значениями ..