Android, объединить компоненты приложения различных версий SDK

Question

Я ищу подход, как объединить компоненты разных версий SDK.

Например, у меня есть APP, который отлично работает с minSdkVersion = "8". Но я хотел бы иметь дополнительную функцию, для которой требуется minSdkVersion = "10".

Может быть, что-то вроде плагина и загружать его динамически? Если устройство android имеет minSdkVersion = "10", он будет загружать этот плагин. И в более низких версиях он просто будет работать с базовыми функциями с SdkVersion = "8".

Есть ли какой-либо подход для этого? Может быть создано два действия в разных пакетах и ​​загрузка одной активности из намерения в качестве интерфейса? есть идеи?

Answer 1

И, если вы используете библиотеки поддержки?

http://developer.android.com/training/basics/fragments/support-lib.html

Какие функции необходимы?

Answer 2

Что вы спрашиваете, очень подробный объяснен на Android Developers Официальный блог:

http://android-developers.blogspot.co.uk/2010/07/how-to-have-your-cupcake-and-eat-it-too.html

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

Answer 3

Чтобы настроить таргетинг на несколько платформ, вы указываете минимальный уровень SDK и целевой уровень SDK при создании проекта. Вы настраиваете проект для привязки к целевой SDK-сборке. VMWiki Davlik будет генерировать исключения во время выполнения, если вы выполняете вызов против метода, который отсутствует на текущей платформе. Компилятор будет генерировать предупреждения для вызовов, которые недоступны на минимальном уровне SDK. Существуют различные объявления Java @, которые подавляют эти предупреждения о классах, методах или конкретных ссылках. Нажмите клавишу F2 в Eclipse, чтобы автоматически генерировать декор Java, который подходит. Это звучит пугающе. Но на практике предупреждения позволяют кодировать относительно бесстрашно.

Таким образом, общий подход: ссылка на целевые библиотеки SDK; добавьте @ украшения в код, который использует методы из более высоких построений SDK; украсить методы или классы, специфичные для конкретной сборки; и жить и умереть с помощью правила кодирования «все предупреждения являются ошибками».

Повторное внедрение всей активности для каждого уровня API является излишним. Классовая специализация с использованием сложных методов не является счастливым способом делать подобные вещи. Сложность привязки затрудняет работу таким образом. Гораздо лучше использовать меньший вспомогательный класс или условный код.

Существуют различные соглашения о написании классов помощников - по существу отдельный класс реализации для каждого уровня API, каждый из которых реализует общий интерфейс или абстрактный базовый класс. Метод, приведенный в блоге разработчиков Android, является достаточно аккуратным способом сделать это. На шаблоне существует множество незначительных вариаций, основанных на получении экземпляра вспомогательного класса для определенного уровня API.

Другим примером этого шаблона будет интерфейс IActionBarHelper, используемый в библиотеке google ActionBarCompat. В этом случае ваши действия наследуют от ActivityCompat, а не Activity, а метод экземпляра ActivityCompat.getActionBarHelper() возвращает реализацию IActionBarHelper, которая обеспечивает соответствующую реализацию для платформы, на которой вы работаете.В этом случае реализации содержат справедливую бит состояния инициализации и состояние, связанное с активностью; поэтому имеет смысл получить реализацию из метода-члена.

Несмотря на все это, Davlik VM отлично справляется с встроенными методами, которые не имеют связи.

if (Build.Version >= 10) { 
     Call an API 10 method. 
    } 

также работает отлично. Davlik VM немного скулит через отладочные сообщения в LogCat. Поэтому, если вы будете делать это все время, может быть накладные расходы. Если вы собираетесь выполнить метод API-10 на платформе нижнего уровня, загрузчик Davlik генерирует код, который генерирует исключение во время выполнения при выполнении вместо выполнения вызова. Но коды ссылок и нагрузки прекрасны. Оператор if - это все, что вам нужно, чтобы предотвратить выполнение отсутствующего метода. В небольших дозах условный код в порядке. Если есть много кода, специфичного для платформы, возможно, лучше каким-то образом инкапсулировать платформенный функционал в класс.

Для функций, которые либо есть, либо нет, например, пример вашего NFC, лучший способ продолжить работу, вероятно, реализовать как можно больше функциональности NFC в классе; а затем условно ссылаться на этот класс из кода в вашем основном классе или деятельности. например .:

void onCreate(...) 
{ 
    if (Build.Version >= 10) 
    { 
     mNfcReceiver = new NfcReceiver(getContext()); 
    } 
} 

Шаблон класса Helper не помогает вам много, так как вы, очевидно, не собирается повторно реализовать функциональные возможности на платформах нижнего уровня.

Answer 4

Спасибо всем за ответы .. Я смог решить эту проблему, используя @ украшение в eclipse: @SuppressLint («NewApi»).

В моей родительской деятельности я просто проверил поддержку VERSION и NFC и напишу на this.supportNFC; после этого я выбрать цель, чтобы загрузить

if(this.supportNFC == KITAPP.NFC_ENABLED){ 
    intent = new Intent(this, ActivityNFC.class); 
} else { 
    intent = new Intent(this, ActivityBasic.class); 
} 
startActivityForResult(intent, 0); 

Кстати,

class ActivityNFC extends ActivityBasic{} 

так что я просто протянул NFC-класс с дополнительными функциями для NFC. Но если мобильное устройство не поддерживает NFC или имеет более низкий уровень Verion, он будет загружать основные функции.