Lower level logging for debugging purposes

[pkillian]

Including Log.d() calls that include the activity's name, a brief message about what method is being called, and possible state information would be incredibly beneficial for debugging. I'll add more and more logging statements as I go along, and attribute any of them that aren't affiliated with other issues to this one.

[bishopmatthew]

Hey Patrick,

We don't necessarily want debug statements ending up in the production builds. Luckily, we can use a library called Timber. to solve that problem -- we can disable logging in production and/or reroute it through our crash reporter. As a bonus it automatically logs the name of the class doing the log call.

You can also use another library called Hugo. It can handle automatically logging the method call name, the parameters, the return value, and the elapsed time. This can be very helpful if you're not sure what a method does or when it is called.

I've already added those to the experimental branch I'm working on (v3-redesign), but I want to make sure it doesn't diverge too far from master and become difficult to merge. Maybe we should add (at least Timber) to the master branch so that you can use it for logging? Or depending on what you're working on, you could move over to v3 as well. What do you think?

[pkillian]

Ahh, I had just checked that branch out after posting this. My confusion was in knowing what methods were fired after a screen orientation change occurred. I'll check out those libs and look over the v3 branch sometime today/tomorrow.

Happy holidays!

[bishopmatthew]

Happy Holidays to you too!

And right, it's pretty easy to get confused there. This blog post gives a pretty good description of what's going on during an orientation change. Maybe that helps?