Joined June 2013
·
Posted to
Some Angular UI Router gotchas and how to deal with them
over 1 year
ago
@fathermerry yes, it works. I'm actually doing that myself :)
Posted to
Installing Copy.com on linux servers (headless linux) to simplify file transfer and deployment.
over 1 year
ago
Now, this defines awesomeness! cool stuff
Achievements
180 Karma
8,507 Total ProTip Views
Komodo Dragon 3
Have at least three original repos where Java is the dominant language
Forked
Have a project valued enough to be forked by someone else
Python 3
Have at least three original repos where Python is the dominant language
Python
Would you expect anything less? Have at least one original repo where Python is the dominant language
Komodo Dragon
Have at least one original repo where Java is the dominant language
Charity
Fork and commit to someone's open source project in need
It is worth noting that >=
INFO
level logs shouldn't be disabled, even in production (except of course if explicitly stated), so an all encapsulatingif (DEBUG_ON) { ... }
block might not exactly be an ideal solution.If one really wishes to disable >=
INFO
logs, you could probably just have asetLogLevel
method and handle the value appropriately in the correspondingLog.x
. Ideally, all less than relevant logging should be done at <=DEBUG
levels.Meanwhile, I would suggest taking advantage of the
BuildConfig.DEBUG
field instead, and you automatically get a managedDEBUG
switchPersonally, I would just create a wrapper class, also named
Log
, preserving the relevant signatures from the actualandroid.util.Log
. That way, the only change I will be making will be theimport android.util.Log
lines