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,819 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 >=
INFOlevel 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 >=
INFOlogs, you could probably just have asetLogLevelmethod and handle the value appropriately in the correspondingLog.x. Ideally, all less than relevant logging should be done at <=DEBUGlevels.Meanwhile, I would suggest taking advantage of the
BuildConfig.DEBUGfield instead, and you automatically get a managedDEBUGswitchPersonally, 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.Loglines