Ich benutze Aproach, um Module zu liefern, die Dagger als Antwort auf diese Frage beschrieben Android Customize Workflow für Produkt-Flavors
Unser Ansatz ist ein bisschen anders - wir haben Modules in debug Buildtyp in src/debug/java und in release Buildtyp in src/release/java . Unser Hauptmodul heißt ApplicationModule und schließt alle anderen ein.
Modules in src/debug/java bietet benutzerdefiniertes Verhalten zum Debuggen, Protokollieren usw. und überschreibt ApplcationModule .
Jetzt müssen wir ein benutzerdefiniertes Verhalten basierend auf dem Anwendungsstil haben.
Was wäre der richtige Ansatz dafür?
Zum Beispiel sollten die Geschmacksrichtungen A bis C benutzerdefiniertes Verhalten bieten, während die Geschmacksrichtungen D bis F ein grundlegendes Standardverhalten bieten sollten.
Bisher habe ich solche gefunden.
src/flavorX/java/com.application.FlavorModule
src/main/java
Gibt es einen besseren Weg, um ein solches Ergebnis zu erzielen? Weil ich nicht gerne src/flavorX/java/com.application.FlavorModule mag und keine Code-Duplizierung mag ...
Etwas kompliziert, aber so habe ich es gemacht:
Erstellen Sie eine Schnittstelle MainComponent und behalten Sie es in src / main, das sollte alles enthalten, was nicht geschmacksspezifisch ist
%Vor%}
Erstellen Sie in jedem Flavor eine Schnittstelle, die von der obigen erbt
%Vor%Erstellen Sie in Debug / Beta / Release die eigentliche Komponente und erweitern Sie die FlavorComponent (mit allen geschmackspezifischen Feinheiten).
%Vor%Beachten Sie, dass Sie auch ein geschmacksspezifisches FlavorModule einfügen können, das in jedem Geschmack anders sein kann oder nicht in Release enthalten ist, während es in die Beta-Version aufgenommen wird.
Fügen Sie auch eine ComponentFactory innerhalb von Debug / Beta / Release ein und geben Sie die gemeinsame Flavour Component Interface
zurück %Vor%und schließlich von Ihrem Application-Klassenaufruf:
%Vor%Die Komponentenfactory gibt die Buildtyp-Komponente zurück, die die Flavor-Komponente erweitert.