Sådan logger du mere effektivt med Timber

Logning er et af de mest anvendte værktøjer i Android- rammen. Det er virkelig nyttigt at debugge din kode, når fejlretning efter break-point bare ikke fungerer.

Det er generelt en god praksis at placere Log-udsagn i din kode. Disse udsagn hjælper dig med at holde styr på flowkontrol i din applikation. Tilsvarende anbefales det ikke at have log-sætninger i din frigivelseskode, da disse log-sætninger kan læses af alle, der forbinder deres telefon til en pc. Så når du frigiver din applikation til playbutikken, anbefales det at fjerne alle logsætningerne fra din kode.

Men dette kan være en reel smerte. Der er så mange logopgørelser over hele din kode. Nu skal du finde hver enkelt og fjerne den fra din kode til frigivelsesversionen.

Et andet problem med standardlogningsmekanismen er, at du skal videregive TAG'en hver gang du skriver en logerklæring.

Ville det ikke være dejligt, hvis logopgørelserne automatisk ville deaktivere sig selv, når de var i produktion? Ville det ikke være godt, hvis Log-udsagnene automatisk hentede TAG / klassenavn under logning, og du bare kunne fokusere på at skrive bedre kode?

Nå, problemer som disse og mange flere løses ved et bedre logningsbibliotek i Android, kaldet Timber (af Jake Wharton).

Det er et let, let at bruge bibliotek. Det tager sig af det meste af vedligeholdelsen, du skal udføre under logning, så du kan fokusere mere på at skrive god kode og mindre på vedligeholdelses ting.

Lad os gå videre og oprette en prøveapplikation for at se, hvordan du kan inkludere tømmer i din Android-applikation og gøre dit logningsliv lettere.

Kom godt i gang

Vi opretter en simpel Android-applikation med 4 knapper. Hver knap udskriver forskellige prioritetslogsætninger på konsollen.

Opret et nyt projekt i Android og tilføj en afhængighed af Timber i din app. build.gradle-fil. På tidspunktet for denne skrivning er dette den seneste afhængighedsversion for tømmer:

implementation 'com.jakewharton.timber:timber:4.7.1'

Initialisering af tømmer

Med den downloadede afhængighed er det nu tid til at initialisere tømmerbiblioteket. Det bedste sted at initialisere tømmer er i applikationsklassen, som vil være aktiv i hele applikationens levetid. Så lad os oprette en brugerdefineret applikationsklasse og initialisere vores tømmerbibliotek i den:

class MainApplication : Application() { override fun onCreate() { super.onCreate() if(BuildConfig.DEBUG){ Timber.plant(Timber.DebugTree()) } }}

Oprettelse af MainActivity

Lad os nu oprette vores MainActivity ved at tilføje 4 knapper og indstille kliklytterne til hver af dem. Her er min activity_main.xml-fil. Jeg bruger ConstraintLayout som mit rodlayout og inkluderer 4 knapper hver til forskellige logningsniveauer.

Nu er det tid til at indstille kliklytterne til disse knapper og udskrive en logerklæring hver gang der klikkes på en knap. Jeg bruger kotlins syntetiske bindinger i stedet for regelmæssige findViewById-opkald eller Butterknife. Her er min MainActivity.kt- fil:

class MainActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main)
 btn_error.setOnClickListener { onClickedError() }
 btn_info.setOnClickListener { onInfoClicked() }
 btn_debug.setOnClickListener { onDebugClicked() }
 btn_verbose.setOnClickListener { onVerboseClicked() } }
 private fun onVerboseClicked() { Timber.v("On Verbose Clicked") }
 private fun onDebugClicked() { Timber.d("On Debug Clicked.") }
 private fun onInfoClicked() { Timber.i("On Info clicked.") }
 private fun onClickedError() { Timber.e("On Error Clicked.") }
}

Bemærk hvordan vi ikke behøvede at initialisere nogen TAG-variabler i vores klasse, Timber gør det automatisk for dig.

Tilpasning af tømmer til fejlfinding og frigivelse

Nu, det er her Timber virkelig skinne s. Det, vi har gjort indtil nu, var ikke noget godt, bare at udskrive logopgørelserne på knap-klik. Men som du ved, er logning i produktion ikke en god idé. Vi skriver kode for at deaktivere logfilerne til produktion, mens vi holder dem aktiveret under fejlretningstilstand.

Vi skriver en if-blok for at kontrollere, om vores app er i fejlretningstilstand og aktivere logning af det. Hvis ikke, vil vi initialisere tømmer ved hjælp af et brugerdefineret træ.

Her er den modificerede klasse MainApplication.kt :

class MainApplication : Application() { override fun onCreate() { super.onCreate() if (BuildConfig.DEBUG) { Timber.plant(object : Timber.DebugTree() { override fun createStackElementTag(element: StackTraceElement): String? { return String.format( "Class:%s: Line: %s, Method: %s", super.createStackElementTag(element), element.lineNumber, element.methodName ) } }) } else { Timber.plant(ReleaseTree()) } }}

Som du kan se, har vi initialiseret tømmer ved hjælp af et brugerdefineret ReleaseTree, når det er i frigivelsestilstand. Lad os nu gå videre og oprette vores eget frigivelsestræ.

Oprettelse af et brugerdefineret træ

Oprettelse af et frigivelsestræ er ret simpelt. Opret en ny Kotlin-klasse og udvid den fra Timber.Tree. Implementere alle de abstrakte funktioner, så er du klar til at gå.

Her er min ReleaseTree.kt :

class ReleaseTree : @NotNull Timber.Tree() { override fun log(priority: Int, tag: String?, message: String, t: Throwable?) { if (priority == Log.ERROR || priority == Log.WARN){ //SEND ERROR REPORTS TO YOUR Crashlytics. } }
}

Som du kan se, når der er en fejl, kan vi sende loggen til en onlinetjeneste såsom Firebase CrashAnalytics eller Crashlytics og ikke logge ud på produktion.

Resultat

Fordele ved at bruge Timber vs Android Logging

Lad os se på nogle af fordelene ved at bruge Timber-biblioteket i stedet for standardlogværktøjet fra Android SDK.

  • No need to worry about TAGS: Timber generates the TAGs automatically for you so you don’t have to worry about including a global TAG in every class.
  • No need to manually remove Log statements: As already shown, it’s really easy to disable Logging for release apps. Hence, you no longer have to go through your entire code and manually remove all the logs.
  • Customized behavior on production: In production versions, you don’t want to log, although you definitely want to log any crashes that might occur. You can implement this by using a custom debug tree (as shown above) which instead of logging to the logcat, sends the logs to your crashlytics service.
  • Customized Meta-Data: You can include customized metadata with your log statements. For example, I’ve added class name, line number and method name from which the log statement is getting printed in the implementation above. Having this data at your disposal can make debugging easier.
  • Lightweight: Does not increase your app size/method count by much. Really lightweight library as it is just a wrapper over the already existing log utility.

Conclusion

For a long time I had ignored the use of log statements and printing out better logs. As my code got bigger and problems got more complex, I realized I needed to adopt better and more efficient debugging routines. Hence, using Timber is one step in the right direction.

* Vigtigt * : Jeg har oprettet et SLACK- arbejdsområde til mobile udviklere, hvor vi kan dele vores læring om alt det nyeste inden for Tech, især inden for Android-udvikling, RxJava, Kotlin, Flutter og generel mobiludvikling generelt . Klik på dette link for at deltage i det slappe arbejdsområde. Det er helt gratis! Denne artikel blev oprindeligt publiceret på //ayusch.com/timber-for-android

Kan du lide det, du læser? Glem ikke at dele dette indlæg på Facebook , Whatsapp og LinkedIn .

Du kan følge mig på LinkedIn, Quora, Twitter og Instagram, hvor jeg besvarer spørgsmål relateret til mobiludvikling , især Android og Flutter .