Я не знаю, когда мне следует использовать методы log.d () и log.w () в Android

Question

Map<String, Object> city = new HashMap<>();
city.put("name", "Los Angeles");
city.put("state", "CA");
city.put("country", "USA");

db.collection("cities").document("LA")
        .set(city)
        .addOnSuccessListener(new OnSuccessListener<Void>() {
            @Override
            public void onSuccess(Void aVoid) {
                Log.d(TAG, "DocumentSnapshot successfully written!");
            }
        })
        .addOnFailureListener(new OnFailureListener() {
            @Override
            public void onFailure(@NonNull Exception e) {
                Log.w(TAG, "Error writing document", e);
            }
        });

Это простой код ввода данных FirebaseFirestore.но когда я смотрю на методы onSuccess() и onFailure(), у каждого из них есть свой метод класса Log.и я не знаю, почему этот код использует их по-разному в этих методах переопределения (onSuccess() и onFailure()).

Answer 1

Почему этот конкретный код использовал один над другим?Потому что человек, который написал, решил.Вместо этого они могли бы использовать i (информация) и e (ошибка).

Короткий ответ - использовать все, что вы хотите, потому что в конечном итоге это не имеет значения: в конце дня ваше сообщение отправляетсяв выходной поток LogCat, который вы можете посмотреть.

Более длинный ответ заключается в том, что вы хотите войти в определенный «поток» в зависимости от типа информации, которую вы регистрируете.У вас есть выбор из 5 основных «потоков» ведения журналов, перечисленных здесь в порядке их вероятности использования, от минимального до большинства: Error, Warn, Info, Debug и Verbose.

Опять же, вы можете войти в систему в зависимости от того, что пожелает ваше сердце, но обычно говоря:

1. Войдите в ERROR (Log.e()) при обнаружении допустимого состояния ошибки или исключения, которое фактически мешает вашему приложению работать правильно.Например, если вы думаете, что обрабатываете каждый случай оператора switch, вы можете добавить журнал ошибок в случае default, который не должен происходить.Это те случаи, о которых вы, как разработчик, хотите знать и исправлять, даже если они не ломают ваше приложение.Вы можете сообщить о них как о «нефатальных» исключениях в Crashlytics.

2. Войдите в WARN (Log.w()) для непредвиденных, но некритических ошибок, которые происходят.Они должны привлечь внимание к тому, что что-то пошло не так, но приложение продолжало работать как можно лучше.В опубликованном вами примере «прослушиватель сбоев» может использовать WARN, потому что этот сбой является допустимым случаем, и вы хотите знать о сбоях, но известно, что сбой возможен, поэтому приложение должно обрабатывать его изящно ивозможность продолжить.

3. Войдите на INFO (Log.i()) для получения информации, которую вы всегда найдете полезной, но при этом не слишком шумной.Это будут вещи, которые помогут вам отследить ошибки в отчете о сбое.В качестве примера можно привести события жизненного цикла активности.

4. Войдите в систему DEBUG (Log.d()) для получения информации, которую вы временно найдете в процессе разработки, чтобы помочь вам решить конкретную проблему илипытаясь отследить конкретную ошибку.Например, если ваше приложение дает сбой в определенном месте, вы можете добавить вызов Log.d непосредственно перед этим местом и записать состояние локальных переменных или что-то в этом роде, чтобы помочь вам выяснить причину сбоя.Вы, вероятно, удалите их, как только эта проблема или ошибка будут устранены.

5. Войдите в VERBOSE (Log.v()), когда вам понадобится еще больше информации, чем вы можете получить с помощью DEBUG.Как следует из названия, это должно быть многословно .Он будет изливать много текста в LogCat, делая его настолько шумным, что его невозможно будет использовать.Например, вы можете записывать каждую итерацию длинного цикла в VERBOSE.

После входа в какой-либо конкретный поток вы можете отфильтровать журналы LogCat, чтобы помочь в нахождении определенногоСообщения.Например, если что-то не так с библиотекой, которую вы используете в своем приложении, вы можете отфильтровать до WARN, чтобы сузить размер журналов LogCat и найти все предупреждения, о которых могла сообщить библиотека.

Вы фильтруете в Android Studio, выбирая выпадающий на вкладке LogCat.Android Studio также окрашивает каждый поток (который вы можете настроить в настройках), чтобы помочь различать сообщения журнала).

Надеюсь, это поможет!

Answer 2

Они вызывают другой метод : d означает debug и w для warning.

Предупреждение используется при сбое действия, отладка при всехХорошо, просто чтобы сказать вам ...