2015-05-11 5 views
46

Ich weiß, dass ich debugCompile verwenden kann, um nur eine dependency für die debug build ziehen. Gibt es einen guten, stromlinienförmigen Weg, um das code initialization zu tun, das auch benötigt wird? Ohne die Abhängigkeiten können die anderen Varianten nicht kompiliert werden.Include Stetho nur in der Debug-Build-Variante

+0

es ist ein bisschen komplex, weil Sie/starten Stetho als Ihre App starten und b/konfigurieren Sie Ihren HTTP-Client auf Stehto zu übertragen. Sie können das tun, indem Sie bestimmte Versionen Ihrer Klassen in den Debug- und Release-Quellordnern haben, ich finde das nicht ideal, aber es funktioniert – njzk2

+3

Aus dem Stegreif, in der 'debug' Quellgruppe, erstellen Sie eine benutzerdefinierte 'Application' Klasse entweder erweitert "Application" (wenn Sie es nicht woanders erweitern) oder erweitert Ihre benutzerdefinierte "Application" (wenn Sie eine in Ihrem Hauptcode verwenden. Registrieren Sie diese 'Application' in' android: name' von '' in der 'debug' Manifest Für den Fall, dass Sie normalerweise eine benutzerdefinierte' Anwendung' verwenden, benötigen Sie wahrscheinlich auch das Attribut 'tools: replaceNode', um dem' debug'-Quellsatz mitzuteilen, dass er ersetzt, was im 'main' Quellcode enthalten ist Manifest. Habe das noch nicht ausprobiert. – CommonsWare

Antwort

48

Sie haben ein paar Optionen.

Option 1: Fügen Sie STETH für alle Versionen (compile statt debugCompile verwenden) und initialisieren es nur in Ihrem Application Klasse für Debug-Builds.

Dies ist ziemlich einfach zu tun. In Ihrer Application Klasse, überprüfen BuildConfig.DEBUG wie so:

if (BuildConfig.DEBUG) { 
    Stetho.initialize(
      Stetho.newInitializerBuilder(this) 
        .enableDumpapp(Stetho.defaultDumperPluginsProvider(this)) 
        .enableWebKitInspector(Stetho.defaultInspectorModulesProvider(this)) 
        .build() 
    ); 
} 

Option 2: Nur STETH sind für Debugbuilds und erstellen verschiedene Application Klassen für Debug- und Release-Builds.

Dank Gradle können Anwendungen unterschiedliche Quellsätze für verschiedene Build-Varianten haben. Standardmäßig haben Sie Release und Debug-Build-Typen, so dass Sie drei verschiedene Quellsätze haben:

  • Debug für Code, den Sie nur in debuggen baut
  • Release für Code möchten, dass Sie nur in Release baut
  • Haupt für Code, den Sie in alle wollen baut

Ihr Anwendungscode in derwahrscheinlich alle derzeitQuellensatz. Sie können einfach einen neuen Ordner namens debug neben dem Ordner main in Ihrer Anwendung erstellen und die Struktur Ihres Ordners main für alles, was Sie für Debug-Builds hinzufügen möchten, spiegeln.

In diesem Fall möchten Sie eine Application Klasse in Ihrer main Quelle festlegen, die nicht auf Stetho verweist.

Dann möchten Sie eine Application Klasse in Ihrem debug Source-Set, die Stetho initialisiert wie Sie normalerweise würden.

Sie können ein Beispiel für diese Einrichtung in der Stetho sample sehen. Genauer gesagt, here's the main Application class und here's the debug Application class. Beachten Sie auch, dass in jeder Quellengruppe Manifeste eingerichtet werden, die auswählen, welche Anwendungsklasse verwendet werden soll.

+3

AFAIK, der erste Ansatz wird nicht mit 'debugCompile' funktionieren, da dieser Code in' main' wäre und die Abhängigkeit nicht in 'main' existiert. – CommonsWare

+1

Sie sind richtig - deshalb habe ich gesagt "Include Stetho für alle bu ilds - "Ich hätte deutlicher machen sollen, dass dies bedeutet,' compile' anstelle von 'debugCompile' zu ​​verwenden. Vielen Dank! –

+1

Ich persönlich bevorzuge die zweite Methode, weil Ihr Stetcho-Code möglicherweise nicht gerade erst aktiviert wird. Vielleicht möchten Sie dumpapps verwenden, eine Netzwerkbindung, und Sie möchten keinen ungeprüften/Debug-Code bei der Produktion liefern. –

66

Überprüfen Sie die Antwort von @Tanis.

Sie können auch so etwas wie folgt verwenden:

die Bibliothek hinzufügen nur auf Debug-Version.

dependencies { 
    debugCompile 'com.facebook.stetho:stetho:1.1.1  
} 

in Ihrer Anwendung können Sie tun:

public class ExampleApplication extends Application { 

    @Override public void onCreate() { 
    super.onCreate(); 
    StethoUtils.install(this); 
    } 
} 

Dann können Sie verschiedene StethoUtils Klasse in der Debug/Release-Version erstellen.

In src/debug/java/

public class StethoUtils{ 

    public static void install(Application application){ 
     Stetho.initialize(
      Stetho.newInitializerBuilder(application) 
      .enableDumpapp(Stetho.defaultDumperPluginsProvider(application)) 
      .enableWebKitInspector(Stetho.defaultInspectorModulesProvider(application)) 
      .build()); 

    } 
} 

In src/release/java/

public class StethoUtils{ 

    public static void install(Application application){ 
     // do nothing 
    } 
} 
+1

Dies sollte der angebotene Ansatz sein. –

+0

Hinweis: Wenn Sie benutzerdefinierte Build-Typen deklarieren, müssen Sie auch eine StethoUtils-Klasse dafür erstellen. Z.B. src//java/ – bmul

+1

Das bedeutet, dass Sie auch Debug/Release-Versionen Ihres OkHttp-Interceptor-Codes einbinden müssen. – miguel

0

java Reflexion verwenden, kann eine perferct Idee:

private void initStetho() { 
      if (BuildConfig.DEBUG) { 
       try { 
        Class<?> stethoClazz = Class.forName("com.facebook.stetho.Stetho"); 
        Method method = stethoClazz.getMethod("initializeWithDefaults",Context.class); 
        method.invoke(null, this); 
       } catch (ClassNotFoundException e) { 
        e.printStackTrace(); 
       } catch (NoSuchMethodException e) { 
        e.printStackTrace(); 
       } catch (IllegalAccessException e) { 
        e.printStackTrace(); 
       } catch (InvocationTargetException e) { 
        e.printStackTrace(); 
       } 
      } 
     } 

dann können wir STETH kompilieren debuggen:

debugCompile 'com.facebook.stetho:stetho:1.5.0' 
+0

Wahrscheinlich möchten nicht alle diese Ausnahmen abfangen oder eine Klasse mit einer Zeichenfolge laden (Paketname könnte sich ändern). Eine viel sauberere Lösung besteht darin, Gradle zu verwenden und bei Bedarf eine Debug-Variante zu injizieren. – Aceofspadez44

+0

Ich glaube, die Reflektionsmethode ist die einfachste und garantiert, dass kein Stetho-Code in einem Release-Build enthalten ist, ohne Code um die Kirche herum zu schreiben – for3st