2013-10-12 3 views
1

У меня есть приложение с кучей продуктов, которые в основном представляют собой белые ярлыки одного приложения. Тем не менее, время от времени есть некоторый расхождение от основного потока в каком-то вкусе, потому что клиент хочет что-то немного другое. До сих пор мы редактировали код для этих случаев и использовали код спагетти (много ifs и elses), чтобы убедиться, что другие приложения не сломаются. Излишне говорить, что это не очень масштабируемый (или даже нормальный) способ сделать это.Android Настройка рабочего процесса для продуктов Flavors

Одним из вариантов было бы написать классы активности в источнике productFlavor папки, т.е. src/flavor1/java/AnActivity.java, src/flavor2/java/AnActivity.java и т.д. Поскольку productFlavor код не может переопределить src/main классы, это потребовало бы одни и те же классы, которые будут скопированы для каждого нового аромат, даже если нет настройки. Мне не очень нравится этот вариант. Это приводит к тому, что многие избыточные коды и имена классов заканчиваются тем, что они не так описательны, поскольку все они должны иметь одинаковые имена, чтобы переопределить других, даже если они могут делать что-то другое.

Другим вариантом может быть использование чего-то типа Dagger для создания ObjectGraph и ввода Intents для различных реализаций. Например, если это flavor1, когда нажата кнопка X, вводится намерение для ActivityA, и если это flavor2, вводится намерение для ActivityB.

Это похоже на лучший способ сделать это, но я все еще не уверен, как реализовать классы, которые будут перекрывать привязки по умолчанию ObjectGraph.

Любые идеи по реализации или другие варианты? Я не привязан к Dagger, я только начинаю изучать вливание и тестирование зависимостей, так что другие структуры работают так же хорошо.

ответ

5

Вот что я делаю ...

В src/flavor1/java/com/myapp/Modules.java:

public class Modules { 
    public static Object[] get(Application app) { 
    return new Object[] { 
     new MyAppModule(app), 
     new Flavor1Module(app) 
    }; 
    } 
} 

src/flavor2/java/com/myapp/Modules.java В:

public class Modules { 
    public static Object[] get(Application app) { 
    return new Object[] { 
     new MyAppModule(app), 
     new Flavor2Module(app) 
    }; 
    } 
} 

src/main/java/com/myapp/MyAppApplication.java В:

ObjectGraph og = ObjectGraph.create(Modules.get(this)); 

MyAppModule имеет общие зависимости. Flavor1Module и Flavor2Module могут вносить дополнительные зависимости или переопределять их от MyAppModule, если overrides=true.

+0

Booyah! Это было так ... Я начинаю влюбляться в «Кинжал» –

+0

Ох .. просто еще одна несколько связанная точка. Если существуют переопределения общих зависимостей, это влияет на любые переопределения при тестировании. Другими словами, можно ли переопределить переопределение? –

+0

На самом деле я не уверен. Я не знаю, как это обрабатывается. Я склонен сказать, что последний выигрывает модуль (с тех пор, как они заказаны), но мне пришлось бы копаться. Эксперимент локально, прежде чем полагаться на это поведение! –

Смежные вопросы