Contains only KLog at present, and would be expanded with some small practical tools in the future.

Setup #

dependenceis{
    ...
    implementation ("io.github.shawxingkwok:android-util-core:1.0.1")
}

AppContext trick #

Design as below in your basic module:

Don’t forget to declare your application name which may need to begin with the package name.

In this way, your Database, DAO, NetService and some other tools could be also static, of which the profit is much more considerable than the additional resource memory.

Foreign static objects could be modified with mockk in tests.

Companion extension trick #

Declare static AppDatabase.INSTANCE based on AppContext and retrofit first, then DAO and Service could be created concisely.

Call them easily.

KLog #

Main advantages #

Tag is global and has a link.
Logs on level V and D are cancelled after the current module releases.
Light-weight. (2kb in jar)

Modify logcat view #

Extend the displayed tag length first. As for others, it’s my personal preferences.

Direct #

obj’s type is Any? and printed out with its toString.

Other levels #

KLog.wtf is not provided. In my opinion, you’d better throw an error if fatal or use KLog.e if not.

More args #

Tag prefix #

Throwable #

This is assignable only in KLog.e.

Avoid tags too long #

Make id, tagPrefix short, and avoid the file name too long, or else the link would fail.

Special types #

Useful KProperty0, common Array, and basic type arrays are specially handled, since their toString don’t tell values.

In open source android library #

Set an internal log object class.

id should be an abbreviated or short all-caps library name for being easily distinguished from other tags.

Remember to build the module if there is no directory ‘build’, or else you probably import BuildConfig from another library.

Effect

In each app submodule #

Set a log class extended from KLog.InApp. Here sets id “DB”, supposing in the database module.

Effect

tag~:APP in the logcat could exclude logs from foreign libraries.

Extend #

Source code

Take the example of overriding functions on level E.

stackTrace in log is easily disturbed. Never call log indirectly like super... or set defaults for your function parameters.

Or you could reference my concise fun log, KLog and design yourself.

Provide position when `inline` #

stackTrace is disturbed in inline functions and crossinline blocks. Specify tagPrefix with fileName in these cases. This problem also exists in links from other log libraries, and would be fixed by the kotlin standard library.

Log out