Hogyan lehet hatékonyabban bejelentkezni a Timber alkalmazással

A naplózás az egyik leggyakrabban használt segédprogram az Android keretrendszerben. Nagyon hasznos a kód hibakeresésében, ha töréspontonkénti hibakeresés csak nem fog működni.

Általában jó gyakorlat a napló utasítások elhelyezése a kódban. Ezek az állítások segítenek nyomon követni az alkalmazás folyamatirányítását. Hasonlóképpen nem ajánlott, hogy a kiadási kész kódban legyenek naplózási utasítások, mivel ezeket a napló utasításokat mindenki elolvashatja, aki a telefonját számítógéphez csatlakoztatja. Tehát, amikor az alkalmazást kiadja a Play Áruházba, javasoljuk, hogy távolítsa el az összes napló utasítást a kódjából.

De ez igazi fájdalom lehet. Olyan sok napló utasítás van az egész kódodban. Most mindegyiket meg kell találnia, és el kell távolítania a kiadási verzió kódjából.

Az alapértelmezett naplózási mechanizmus másik problémája az, hogy minden alkalommal, amikor napló állítást ír, át kell adnia a TAG-et.

Nem lenne csodálatos, ha a napló utasítások automatikusan letiltanák magukat a gyártás során? Nem lenne jó, ha a Napló utasítások automatikusan felvennék a TAG / osztály nevét naplózás közben, és csak a jobb kód írására összpontosíthatna?

Nos, az ilyen és még sok más problémát egy jobb naplózó könyvtár oldja meg androidban, Timber néven (Jake Wharton).

Ez egy könnyű, könnyen használható könyvtár. Gondoskodik a naplózás során elvégzendő legtöbb karbantartásról, hogy jobban összpontosíthasson a nagyszerű kódok írására és kevésbé a karbantartási dolgokra.

Menjünk előre, és hozzon létre egy minta alkalmazás, hogy hogyan lehetnek Timber az android alkalmazás , és a fakitermelés életét.

Elkezdeni

Létrehozunk egy egyszerű Android alkalmazást, 4 gombbal. Minden gomb különböző prioritási napló utasításokat nyomtat ki a konzolon.

Hozzon létre egy új projektet az Android rendszerben, és adjon hozzá egy függőséget a Timber alkalmazáshoz az alkalmazás szintű build.gradle fájlban. Az írás idején ez a faanyag legújabb függőségi változata:

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

A faanyag inicializálása

A letöltött függőséggel itt az ideje, hogy inicializálja a fatáblát. A faanyag inicializálásának legjobb helye az Application osztály, amely az alkalmazás teljes élettartama alatt aktív lesz. Hozzunk létre egy egyedi alkalmazásosztályt, és inicializáljuk benne a Timber könyvtárat :

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

MainActivity létrehozása

Most hozzuk létre a MainActivity-t úgy, hogy hozzáadunk 4 gombot, és mindegyikhez beállítjuk a kattintásfigyelőket. Itt van a activity_main.xml fájlom. A ConstraintLayout-ot használom gyökérelrendezésként, és mindegyikhez 4 gombot használok a különböző naplózási szintekhez.

Itt az ideje, hogy a kattintásfigyelőket beállítsa ezekre a gombokra, és naplónyilatkozatot nyomtasson ki minden gombnyomásra. A kotlin szintetikus kötéseit használom a rendszeres findViewById hívások vagy a Butterknife helyett. Itt van a MainActivity.kt fájlom :

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.") }
}

Figyelje meg, hogy miért nem kellett inicializálnunk egyetlen TAG változót sem az osztályunkban, a Timber automatikusan elvégzi ezt az Ön számára.

A fa testreszabása a hibakereséshez és a kiadáshoz

Most itt ragyog a Timber . Amit eddig tettünk, nem volt semmi nagyszerű, csak a naplófájlokat gombnyomásra nyomtattuk. De mint tudják, a termelésben való fakitermelés nem jó ötlet. Kódot írunk a naplók gyártásának letiltásához, miközben engedélyezve tartjuk őket a hibakeresési módban.

Írunk egy if blokkot annak ellenőrzésére, hogy alkalmazásunk hibakeresési módban van-e, és engedélyezzük a naplózást ehhez. Ha nem, akkor a faanyagot inicializálni szeretnénk egy egyedi fával.

Itt van a módosított MainApplication.kt osztály:

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

Mint látható, a faanyagot inicializáltuk egy egyedi ReleaseTree használatával, amikor kiadás módban van. Most menjünk előre, és hozzunk létre saját kiadási fát.

Egyéni fa létrehozása

A kiadási fa létrehozása meglehetősen egyszerű. Hozzon létre egy új Kotlin osztályt, és bővítse ki a Timber.Tree alkalmazásból. Végezze el az összes absztrakt funkciót, és máris mehet.

Itt van a 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. } }
}

Amint láthatja, amikor hiba történik, elküldhetjük a naplót egy olyan online szolgáltatásnak, mint a Firebase CrashAnalytics vagy a Crashlytics, és nem jelentkezünk ki a termelésben.

Eredmény

A Timber vs Android Logging előnyei

Vizsgáljuk meg a Timber könyvtár használatának néhány előnyét az alapértelmezett Log segédprogram helyett az android sdk által.

  • 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.

*Important* : I’ve created a SLACK workspace for mobile developers where we can share our learnings about everything latest in Tech, especially in Android Development, RxJava, Kotlin, Flutter, and overall mobile development in general. Click on this link to join the slack workspace. It’s absolutely free! This article was originally posted at //ayusch.com/timber-for-android

Like what you read? Don’t forget to share this post on Facebook, Whatsapp, and LinkedIn.

You can follow me on LinkedIn, Quora, Twitter, and Instagram where I answer questions related to Mobile Development, especially Android and Flutter.