CODEWITHSUNDEEP
androidlogging
Noder
Noder

Reputation: 323

I don't know when I should use log.d() and log.w() methods in Android

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);
            }
        });

This is FirebaseFirestore's simple data input code. but When I look into onSuccess() and onFailure() methods, each of them has a different method of Log class. and I don't know why this code use them differently in those Overriding methods(onSuccess() and onFailure()).

Upvotes: 0

Views: 347

Answers (2)

dominicoder
dominicoder

Reputation: 10155

Why did this particular code use one over the other? Because the person who wrote chose to. They could have used i (info) and e (error) instead.

The short answer is use whatever you want because it ultimately doesn't matter: at the end of the day your message goes into the LogCat output stream that you can look at.

The longer answer is that you want to log to a particular "stream" based on the type of information you're logging. You have your choice of 5 main "streams" of logging, listed here in order of how frequently you might expect to use them, from least to most: Error, Warn, Info, Debug, and Verbose.

Again, you can log to whichever your heart desires but generally speaking:

  1. Log to ERROR (Log.e()) when you detect a valid error state or exception that actually prevents your app from functioning correctly. For example, if you think you're handling every case of a switch statement, you might add an error log in the default case which shouldn't happen. These are cases that you as the developer want to know about and fix, even if they are not crashing your app. You might report these as "non-fatal" exceptions in Crashlytics.

  2. Log to WARN (Log.w()) for unexpected but non-critical errors that occur. These are to draw attention that something went wrong, but that the app continued as best as it could. In your posted example, the "failure listener" might be using WARN because that failure is a valid case to handle and you want to be aware of failures, but it's known that failure is possible so the app should handle it gracefully and be able to continue.

  3. Log to INFO (Log.i()) for information you would find generally always find useful but that doesn't get too noisy. These would be things that would help you track down bugs in a crash report. Logging Activity lifecycle events would be an example.

  4. Log to DEBUG (Log.d()) for information you would find temporarily helpful while in development to help you solve a particular problem or while trying to track down a specific bug. For example, if your app is crashing at a specific location, you might add a Log.d call just before that spot and log the state of the local variables or something to help you find out what's causing the crash. You would probably remove these once that issue or bug is resolved.

  5. Log to VERBOSE (Log.v()) when you need even more information even more frequently then you can get with DEBUG. As its name implies, this is intended to be verbose. It will spew a lot of text into LogCat making it so noisy as to be unusable. For example, you might log every iteration of a long loop to VERBOSE.

Once you're logging to any particular stream, you can filter the LogCat logs to aid in finding particular messages. For example, if something is going wrong with a library you're using in your app, you might filter to WARN to narrow the size of the LogCat logs and look for any warnings the library may have reported.

You filter in Android Studio by selecting the drop down in the LogCat tab. Android Studio also colors each stream (which you can configure in settings) to aid in differentiating the log messages).

enter image description here

Hope that helps!

Upvotes: 2

PeS
PeS

Reputation: 4039

They are calling different method: d stands for debug and w for warning.

Warning is used when the action fails, debug when all is OK just to tell you...

Upvotes: 1

Related Questions