Flipper: Android - How to setup dependencies when Flipper is only used in debug builds?

[ColtonIdle]

In my Application onCreate I have

if (BuildConfig.DEBUG) {
            SoLoader.init(this, false);
            if (FlipperUtils.shouldEnableFlipper(this)) {
                final FlipperClient client = AndroidFlipperClient.getInstance(this);
                client.addPlugin(new NetworkFlipperPlugin());
                client.addPlugin(new InspectorFlipperPlugin(this, DescriptorMapping.withDefaults()));
                client.addPlugin(CrashReporterPlugin.getInstance());
                client.start();
            }
        }

and in my app level build.gradle I have:

implementation 'com.facebook.flipper:flipper:0.16.2'
implementation 'com.facebook.soloader:soloader:0.5.1'

but, if my hunch is right... this means flipper is technically being shipped in release builds. How can I prevent this?

[passy]

You're looking debugImplementation. There's example setup code here: https://fbflipper.com/docs/getting-started.html#setup-your-android-app

[ColtonIdle]

@passy debugImplementation causes my release builds to fail

[passy]

The easiest way to avoid is by having an application or an app initialiser in debug/ that implements Flipper and have another one in main/ that is a no-op.

[ColtonIdle]

@passy hm. Okay. I think it's worth it to update that in the docs also since you are giving users debugImplementation which will automatically fail the first time they try to release.

Was it considered to add a no-op artifact similar to what other debug tools do (like leak canary and others)?

LeakCanary

dependencies {
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.3'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.3'
// Optional, if you use support library fragments:
debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.3'
}

[theGlenn]

@ColtonIdle @passy I came up with this as a temporary working solution until it's done in Flipper's core package.
https://github.com/theGlenn/flipper-android-no-op

dependencies {
  releaseImplementation 'com.github.theGlenn:flipper-android-no-op:0.1.0'
  debugImplementation 'com.facebook.soloader:soloader:0.6.0'
  debugImplementation 'com.facebook.flipper:flipper:0.15.0'
}

[ColtonIdle]

@theGlenn that's great. Exactly what I needed. I've never dug into the details of a no-op artifact, but I'd be curious to get the same for fb stetho since it's a debug library.

@passy does the project have any intentions on providing a no-op artifact out of the box?

[passy]

@passy hm. Okay. I think it's worth it to update that in the docs also since you are giving users debugImplementation which will automatically fail the first time they try to release.

It was my hope that people would already have a separate place to set up their debug-only singletons and whatnot. If that's not the case, we should definitely consider expanding or docs about it.

We have been thinking about creating our own no-op variant, too, but want to make sure we have tests set up to ensure we don't break it as we won't use it ourselves.

[ColtonIdle]

If a no-op variant isn't needed (or deemed the right solution) then yes, docs would be helpful. I just came across another reddit comment that said they tried flipper, didn't compile so they dropped it and haven't used it since. (Unfortunately) I feel like setup instructions should be fairly comprehensive so new and old developers have as little friction as possible.

If you recommend debugCompile, then I would at least include something about it failing in release and giving the user the 3 (?) possible options forward. Something like the below:

Note:
Flipper is intended to be used during debugging, which is why we recommend debugImplementation, but this will cause your release builds to fail. You can do one of the below to alleviate this.

1. Create separate /debug and /release Application classes. Only include the flipper code in the /debug Application class.
2. If you'd prefer to keep one application class, you can write your own class that acts as an initializer for all of your debugging tools including flipper. Then you can duplicate that class in /debug and /release while keeping a single app class.
3. You can opt for a no-op artifact that is used in release builds debugImplementation 'com....-no-op'

As far as I can tell from what I've read, it might be best to have a separate init class that I create myself as the no-op methods may still increase my method count? Not sure. Anyway, these are just my thoughts. I love flipper and would just love to make it the goto tool you include in any new app.

[ritwik-shanker]

1. Create separate /debug and /release Application classes. Only include the flipper code in the /debug Application class.

@ColtonIdle I tried doing this but now I get duplicate classes error. I copied my release Application code to debug and added flipper code to it.