This looks really neat! As the post suggests, we also have been doing a lot of janky Log calls to debug our app's network code.
I am really impressed by a lot of the Facebook open source releases. Each new one makes me even sadder that you can't use them due to the crazy patent license they've started using:
"The license granted hereunder will terminate, automatically and without notice, for anyone that makes any claim (including by filing any lawsuit, assertion or
other action) alleging [...] that any right in any patent claim of Facebook is invalid or unenforceable."
I was going to write a rebuttal saying that it's unlikely that any of this specific Software [Stetho] is covered by patent claims, so it wouldn't matter if you lost the license to Facebook's patents.
It wouldn't matter if this was covered or not. Their license is saying that you can use their stuff as long as you don't question any of their patents.
Downvotes? Really? Github could make a stand here and disallow licenses that evil and self-serving. With this license, anybody who even uses this software can't challenge any patents of Facebook's. If Github said no, this is wrong, they would set an example for everyone else and single this out as the terrible license it is.
Downvotes because its rather impractical, and Im sure many people don't want GitHub to start arbitrarily banning projects because of a random set of beliefs they have.
And then you have people that pay money to GitHub for code hosting...
But Github here is in the position where they are the only external party that could do something about this, because the code is hosted on their site.
> ... Im sure many people don't want GitHub to start arbitrarily banning projects because of a random set of beliefs they have
It wouldn't be unprecedented and it wouldn't be arbitrary. Google Code, for instance, only allows open source projects to be hosted with them. From what I can tell about Github, they allow any license. Doesn't mean that they can't change that policy.
Sure, it's easier to do nothing. But they alone could do something. And Facebook will get the goodwill they want from this without much kickback because nobody does anything.
The biggest difference is you dont need to add debug code deploy, you just connect.
For things like the network traffic it is really hard to see request/response for a particular thing.
For the dumpers - those are basically a main method inside your program that you can run whenever. Its a nice way to change (or dump) state of the program, similar to adb shell dumpsys, but also allows a richer interface for changing state.
They've saved me a ton of time. Especially when you're using something like PhoneGap, where you're coding in JS, it's nice to have your old familiar web-based debugging console available.
I skimmed through their github page, but didn't see if they offer view hierarchy debugging. Being able to easily navigate an xml dump of the screen would be amazing using Chome Tools. Android Device Monitor is not the most elegant of interfaces.
Ah and I had just finally coughed up 50 dollars for my Charles license. Charles is a nice tool, but this seems so much nicer as I don't see anywhere that the user is required to setup a proxy manually on the phone.
This does make me wonder how their HTTP debugging works? I am assuming that data is passed over USB. Are they using ADB underneath this all?
Its not a proxy, it requires that you build hooks into your http engine (OkHttp/HttpUrlConnection) to forward events to the NetworkEventReporter interface.
Looks cool! But wait: does it mean that we have to add this instrumentation code when debugging, but when releasing to the Play Store, we have to remember to remove it?
Or does it work only when the app is not signed and you can attach the debugger?
Currently our recommendation is to use an if (DEBUG) block around your initialization and then use proguard to remove the dead code in release. We are working on a better solution which allows you to use build flavors in gradle. The proguard solution is how Facebook apps strip it out today, however.
That said, it is safe to ship the stetho engine in your release apps and it adds virtually no runtime overhead to initialize due to our deferred init design. For instance, Chrome for Android ships with the same system we have and it is always enabled even for release builds.
I am really impressed by a lot of the Facebook open source releases. Each new one makes me even sadder that you can't use them due to the crazy patent license they've started using:
https://github.com/facebook/stetho/blob/master/PATENTS
"The license granted hereunder will terminate, automatically and without notice, for anyone that makes any claim (including by filing any lawsuit, assertion or other action) alleging [...] that any right in any patent claim of Facebook is invalid or unenforceable."