Gradle - использование ароматизаторов

Question

У меня есть проект, который использует сканирование Bluetooth Low Energy в одном классе. Начиная с API 21, Android отклонил некоторые из методов, которые я использую, и хочу, чтобы я заменил их новыми. Я действительно не хочу отключать все API 19 и 20, поэтому я пытаюсь исследовать ароматы Gradle.

Что я нашел до сих пор, так это то, что для создания разных вкусов вам нужны два разных пакета для двух ароматов, которые содержат разные исходные коды.

Мой вопрос: должен ли я пытаться использовать ароматизаторы, если мне нужен только дисперсия в одном классе? Также, как я должен это делать? Я просмотрел документы Gradle, и не так много, но как объявить разные вкусы, а не то, что на самом деле.

Я нашел это в разделе для flavors,

библиотека определена с «английский» и «» французский аромат. При компиляции «французского» варианта определяется отдельный макрос, который приводит к созданию другого двоичного кода.

, но это примерно так далеко. Как я мог бы настроить двоичный файл и изменения? Благодаря!

Answer 1

Пример Gradle аромата:

android { 
    ... 
    defaultConfig { ... } 
    signingConfigs { ... } 
    buildTypes { ... } 
    productFlavors { 
     demo { 
      applicationId "com.buildsystemexample.app.demo" 
      versionName "1.0-demo" 
      buildConfigField 'Boolean', 'isDemo', 'true' 
     } 
     full { 
      applicationId "com.buildsystemexample.app.full" 
      versionName "1.0-full" 
      buildConfigField 'Boolean', 'isDemo', 'false' 
     } 
    } 
} 

Вы можете поставить различный исходный код для каждой сборки вкус.

Просто прочитайте эту страницу: https://developer.android.com/tools/building/configuring-gradle.html

Answer 2

Вы можете сделать это с помощью ароматов, но так как это только один класс, я бы рекомендовал делать что-то вроде этого, вместо:

Во-первых, сделать интерфейс:

public interface Something{ 
    //Put anything that will be common to both classes here. 
    public void doSomething(); 
} 

Создайте два класса, реализующих интерфейс. Тот, который использует новые и интересные версии:

public class SomethingWithNewStuff implements Something{ 
    @Override 
    public void doSomething(){ 
     //Go nuts and use new fancy features where you need them 
    } 
} 

Затем переопределить методы, которые нуждаются в обновлении старых версий:

public class LegacySomething implements Something{ 
    @Override 
    public void doSomething(){ 
     //do something in a legacy way. 
    } 
} 

Затем, когда вы экземпляр класса:

Something something; 

int currentapiVersion = android.os.Build.VERSION.SDK_INT; 
if (currentapiVersion >= android.os.Build.VERSION_CODES.KITKAT){ 
    something = new SomethingWithNewStuff(); 
} else{ 
    something = new LegacySomething(); 
} 

something.doSomething(); 

В зависимости что вы делаете конкретно, вы можете реализовать такие же вещи несколькими способами. В некоторых случаях может быть лучше, чтобы один класс расширил другой, вместо того, чтобы наследовать от общего интерфейса и т. Д.

В любом случае, в конце концов, это, вероятно, будет меньше работы, чем сохранение двух отдельных сборок для небольшого изменение.