Comments (15)
Just to chime in with an option (though it might not be the best option for the library, just tossing another idea in for inspiration).
We mark Stetho with debugCompile
, and provided for the rest of the project. Then we have three classes:
// StethoHelper interface, AKA "NetworkEventReporterImpl"
public interface StethoHelper {
void init(Context context);
void configureInterceptor(OkHttpClient httpClient);
}
public class FakeStethoHelper implements StethoHelper {
@Override
public void init(Context context) {
// Noop
}
@Override
public void configureInterceptor(OkHttpClient httpClient) {
// Noop
}
}
public class RealStethoHelper implements StethoHelper {
@Override
public void init(Context context) {
Stetho.initialize(
Stetho.newInitializerBuilder(context)
.enableDumpapp(Stetho.defaultDumperPluginsProvider(context))
.enableWebKitInspector(Stetho.defaultInspectorModulesProvider(context))
.build());
}
@Override
public void configureInterceptor(OkHttpClient httpClient) {
httpClient.networkInterceptors().add(new StethoInterceptor());
}
}
We use then these directly directly in a BuildConfig field:
debug {
...
minifyEnabled false
signingConfig signingConfigs.debug
buildConfigField 'flipboard.util.StethoHelper', 'STETHO', 'new flipboard.util.RealStethoHelper()'
}
release {
...
minifyEnabled true
shrinkResources false
signingConfig signingConfigs.release
buildConfigField 'flipboard.util.StethoHelper', 'STETHO', 'new flipboard.util.FakeStethoHelper()'
}
This way, the packaged APK only knows about the StethoHelper
interface, and the actual implementation used is set at compile time. Then, we can just do this in the code:
// In your application class's onCreate()
if (BuildConfig.DEBUG) {
BuildConfig.STETHO.init(this);
}
// In your network stack
if (BuildConfig.DEBUG) {
BuildConfig.STETHO.configureInterceptor(this.httpClient);
}
You could further abstract this in the library itself by checking if stetho is available at runtime like you suggested, but we find that this is convenient and clever solution that keeps things simple while also allowing the flexibility to easily enable it in other buildTypes
from stetho.
I needed a simple way of doing release builds without having two application subclasses, so I've implemented a very basic and minimal no-op library: https://github.com/iGenius-Srl/stetho-no-op
from stetho.
You can create a wrapper class an put it under debug and release root folders. the one under debug will contain the actual stetho implementation and the one under release will have empty stubs.
from stetho.
You may be surprised how many popular android apps use stetho in their release builds which exposes a security hole (you can execute SQL statements, monitor network traffic, edit shared preferences, etc). I fully place the blame on app developers carelesness and NOT the stetho team but I also believe you guys could help by providing a no-op version or at least have a disclaimer in README.md. Anyways thank you for this awesome library!
from stetho.
My preferred way to use stetho is to only have it in debug flavour src folders
from stetho.
Leaning toward recommending this solution: http://littlerobots.nl/blog/stetho-for-android-debug-builds-only
from stetho.
I believe we can solve the network issue with this pattern very nicely by making stetho-okhttp and stetho-urlconnection depend on stetho using a provided/optional dependency, then having them internally test for Class.forName("com.facebook.stetho.Stetho") or something. For instance, you could have:
stetho-okhttp
:
public class StethoInterceptorInstaller {
public static void installIfPossible(OkHttpClient client) {
if (isStethoPresent(...)) {
client.networkInterceptors().add(new StethoInterceptor());
}
}
}
stetho-urlconnection
:
public interface StethoURLConnectionManager {
public void preConnect();
public void postConnect();
...
}
public class StethoURLConnectionManagerFactory {
public StethoURLConnectionManager newInstance(...) {
if (isStethoPresent(...)) {
return new StethoURLConnectionManagerImpl(...);
} else {
return NoopURLConnectionManagerImpl.getInstance();
}
}
}
class StethoURLConnectionManagerImpl implements StethoURLConnectionManager {
}
class NoopURLConnectionManagerImpl implements StethoURLConnectionManager {
}
This will not necessarily be backwards compatible for stetho-urlconnection
, but I think we can find a way to make it work. Even if it involves gutting StethoURLConnectionManager
today and moving the internals somewhere else.
from stetho.
It is pretty lightweight for the project to create a Shim that is a no-op for release builds if that is what the consumer desires. Is it really worth including this work in the debug tool when there are multiple ways for the consumer to isolate itself?
from stetho.
@brennantaylor the concern is really about asking every engineer to think through the solution. The helpers (stetho-okhttp and -urlconnection) are there to just make life easier for most devs so they might as well make the removal in release builds a convenient choice as well. I'm not longer looking at a stub vs core architecture that would be hard to maintain so I think we have a good compromise with my above proposal. I agree though that if the solution takes something away in terms of convenience or performance it's clearly not worth it.
from stetho.
@hzsweers Why do you need if (BuildConfig.DEBUG) {...
if you are specifying a debug buildType in Gradle anyway??
from stetho.
You don't, more of just an extra precaution :P. We have other things in
that block too, just seemed sensible to keep it there.
On Wed, Mar 18, 2015 at 4:40 AM Igor Ganapolsky [email protected]
wrote:
Why do you need if (BuildConfig.DEBUG) {... if you are specifying a
debug buildType in Gradle anyway??—
Reply to this email directly or view it on GitHub
#16 (comment).
from stetho.
@hzsweers Very thanks,it's useful for me.Thanks again.
from stetho.
Thanks @gotev for making that, I was about to do the same. Don't know why FB devs are so against it. The "optimal" app is ridiculous.
from stetho.
I needed a simple way of doing release builds without having two application subclasses, so I've implemented a very basic and minimal no-op library: https://github.com/iGenius-Srl/stetho-no-op
This library works brilliantly and is very easy to integrate.
from stetho.
We mark Stetho with
debugCompile
, and provided for the rest of the project. Then we have three classes:
Hi! @ZacSweers You still have to remove the Debug implementation from the sourceSets in release build right?
from stetho.
Related Issues (20)
- A potential null pointer dereference bug. Please confirm, much appreicated! HOT 1
- Database Inspection Loading Blank Page HOT 1
- dumpapp commands are failing when more than 1 device is connected HOT 2
- 看不见包名 HOT 1
- Unreleased Resource: Streams
- Double-Checked Locking
- it seems Facebook is collecting device data even it is initialised in debug mode
- Stetho protobufs - Documentation request HOT 1
- How to user Discover network targets mode inspect app
- DevTools inspect window doesn't render properly HOT 52
- Windows cannot be displayed after chrome update HOT 10
- github says version 1.6.0 is released but I couldn't find it HOT 3
- How fix this? HOT 5
- Chrome debugging not showing network api responce
- Stetho doesn't capture network in network inspector HOT 2
- Feature request to view datastore data
- NoSuchMethodError issue
- Usage of weak crypto algorithms like SHA-1 in Stetho HOT 1
- Inspect Devices UI is distorted HOT 3
- Question: How does Stetho Draw OkHttp Requests in Network Tab? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stetho.