As an android developer beginner, we stuck in our code and surprise with code execution. In our mind always thinks that why this is happening? So for understanding the code execution generally we are the putting the logs in each of statement of code to make sure that we reached to code as per our logic. For example, we are putting similar kind of logs as below. Log.d(TAG, message)
Somehow we got to understand that what is wrong in the code to execute our logic. But the problem is every line putting log is very obvious and not make our code modular. Generally most of the time we have faced the problem in debug mode to production mode. We do not want to see the log in the production of an app. So removing the Logs is very difficult throughout the project. In that case, I would say please use Timber library for the log.
Timber is developed by Jake Wharton and the best part of this library is that it can provide an option that log can work in debug mode and will be ignored in the production environment. It is the best-optimized library on top of an android log to read the logs data on Android Console. You can set multiple colors for different -different sections and parts to better understand and good to show on console UI.
But again my tutorial is not about to use the Timber. We are trying to understand how can we debug our code in the best way without putting any logs. Most of the developer they used the debugger and put the debug point to understand that we reached till the code without any issue and if not then they can be fined the cause of the error that what is going wrong with this.
So in this tutorial, we will try to understand what is the best approach to debug the code. We will see the best way to debug the code without using any logs and without stopping our exception at any breakpoint and we can also make sure that we reached to the code or not in console. So let us explore.
This is our first approach to use the feature of the debugger “Breakpoint Hit”. In this feature, we can make sure that we reached that statement as per logic or not and how many times it hits as per our loop. For enabling this feature is pretty simple and easy to do.
1. Right click on the breakpoint of where you want to have that printout.
2. Then uncheck the Suspend so that the breakpoint doesn’t get stops when it is reached.
Let’s see by the snap shop to a better clear picture.
Once you uncheck suspend checkbox we will find more option or just click on more option to verify that we have added the breakpoint in right statement. Ok, let’s see by another snapshot to better understand.
As so far we have set the breakpoint, now we need to verify the breakpoints that as per logic it printing the logs or not in my console and how many times we reached that statement. So what you need to attach the debugger and move your execution and at the same time, we can see the console that what is printing in the console.
Here is the snapshot for better understand that what console has printed.
This is something needed when our code is very complex and want to see the particular variable what is returning in logs by my logic. So in this case, we will use this feature. As generally, we do not need to write any log for that case, but we need to print some available return data in a log. So I meant that we can write the Log for temporary and which will not affect our code with any logs.
To enabling this breakpoint feature, the steps are almost similar as we can see above.
1. Right click on the breakpoint of where you want to have that printout.
2. Then uncheck the Suspend so that the breakpoint doesn’t get stops when it is reached
3. Click on more option and check the checkbox for Evaluate and log and insert you temporary log for checking and printing the variable return.
That is it. I hope it is very simple and easy. For making more simplicity, we can see the below snapshot.
Now to execute the temporary Log on the Logcat, we need to run the code for attaching the debugger and see the Log View on below.
If you again the code is much complicated then you can overhead to see the how many times the log count executed. In that case, we do not write any temporary log. You just see the right side of the log as an overhead panel.
Now we have a good understanding of how to debug the code without putting any logs in our project. We can see with few simple steps to do and make this feature works. In my next tutorial, we will learn a few more technical stuff and their solution and till then enjoy your healthy day.
If you are wondering to learn Android then Please Learn from Android category and wondering to lean Kotlin then Kotlin Category will help you. If you want to learn all the python article, then learn from the python category.
Please do subscribe your email to get the newsletter on this blog on below and if you like this post then do not forget to share like and comment on the below section.
Happy Coding
I am a very enthusiastic Android developer to build solid Android apps. I have a keen interest in developing for Android and have published apps to the Google Play Store. I always open to learning new technologies. For any help drop us a line anytime at contact@mobologicplus.com
Hi everyone, In this article, we are going to learn how to hide the production… Read More
Hello everyone, Today in this article, we are going to learn about localisation to support… Read More
Hello everyone, In this article, we are going to learn something to handle the callback… Read More
In this article, we are learning about the run time permissions for request permission launchers.… Read More
Hello everyone. In my last tutorial, we learned about the Jetpack Compose introduction and about applying the… Read More
Hello everyone, In this article, we are going to learn about the Jetpack Compose with… Read More