0

I'm trying to separate debug and release functionality in my app. For instance I'm using Stetho and Mortar libraries. They both require overridden Application class. But I would like Stetho to be accessible only in debug build. There are at least two approaches:

Have MyApplication class in release and debug flavors with different code. But in this case code which should be user in release build is duplicated.

MyDebugApplication extends MyApplication and contains only debug related stuff. In this case two Manifest files are required and merged some how.

So I'm wondering which approach is more efficient ?

Gabriele Mariotti
  • 320,139
  • 94
  • 887
  • 841
oleg.semen
  • 2,901
  • 2
  • 28
  • 56

2 Answers2

1

I have taken a different approach. I use config to determine what is turned on.. here is a simple version:

   if (BuildConfig.DEBUG) {
      Stetho.initialize(Stetho.newInitializerBuilder(app)
              .enableDumpapp(Stetho.defaultDumperPluginsProvider(app))
              .enableWebKitInspector(Stetho.defaultInspectorModulesProvider(app))
              .build());
      Timber.d("Stetho configured");
    }

But imagine instead of just BuildConfig.DEBUG you use a boolean resource:

app.getResources().getBoolean(R.bool.stetho_enabled)

with:

<bool name="wallet_production">true</bool>

in a settings.xml resource file, or something... you can even get fancier and have this backed by an Optimizely live variable or the like.

I prefer this because then if I need to turn on Stetho or logging or something else in a release build, it's as easy as changing an xml file.

danb
  • 10,239
  • 14
  • 60
  • 76
  • 1
    This approach keeps library in in production build. In case you use lib only in debug builds your final apk file is smaller. – oleg.semen May 07 '15 at 13:50
  • fair enough, if that is a concern for you. In our case it's worth the little bit of extra size for the flexibility and reduced complexity – danb May 07 '15 at 16:04
0

You totally should use two base MyBaseApplication classes in the release and debug flavor and then extend the MyApplication class on your main scope.

This way the logic woun't be duplicated, and you'll have two different behaviours on debug and release.

ArieDov
  • 624
  • 6
  • 12
  • 1
    small note: you have to put the MyApplication classes in the same package so you can use only one manifest file :) – Patrick Dorn Mar 05 '15 at 15:10