Since this can influence the behavior of your app, it is crucial to have this information to interpret the logs. In addition to the previous point, also log dynamic configuration at startup and when it is changed. If you have a base Fragment inherited by all your Fragments (and you should!) use it to log these events. You should always be logging this kind of information. Lots of Android apps bugs and mis-behaviors are related to the Android lifecycle. This file can also contain other definitions for the module, such as dependency injection definitions. ++code> const val TAG = "mga.user"++/code> You can add a ++code>module.kt++/code> at the root of a feature package containing a const like You may use a pattern like ++code>.++/code>įor instance for My Good App (MGA), you would define: It can also lead to tag length greater than 23, which gets truncated in output. It also makes filtering more difficult based on this tag, because your feature will often be implemented with multiple classes. Suggestions of usage and flow rate for each log level Meaningful TaggingĪlthough it's a popular pattern to use the class name as the log tag, I suggest you don't use a class name for your tag.įirst it's leaking implementation details.
For instance, you may target this kind of pace per log level : You should try not to flood the most important log levels. Timber is a popular library which will allow you to do exactly that. This will allow you to easily disable the logs in production build, redirect them to another output, or decorate the lines if needed. Of course you can use the built-in Log class and its convenient static methods, ++code>d(),e(),i()++/code> ?Īn option is to create your own wrapper for this class and inject it into your classes. Here are some tips to do better logging on your Android App. I suggest that logs can be useful on a daily basis if done correctly.
You write tons of throwaway log lines such as ++code>"being here"++/code>, ++code>"user=23939"++/code>, etc? and delete everything as soon as you understood the root cause of the bug. Logging can sometimes be seen as the tool to be used as a last resort.
0 kommentar(er)
