Я разрабатываю приложение для Android в Eclipse. Я хотел бы ориентироваться на широкий спектр устройств и версий SDK (например, я могу дополнительно поддерживать мультитач). Я понимаю рекомендуемый подход , состоящий в том, чтобы изолировать все новые функциональные возможности от отдельного класса и использовать ленивую загрузку, чтобы загружать этот класс только во время выполнения, если хост-устройство фактически поддерживает эту функцию.
Недостатком этого подхода является то, что мне приходится компилировать весь мой код с помощью SDK новейшей функции, которую я хочу использовать. Это означает, что если какая-то новая функция просочится в мой «нейтральный к версии» код, компилятор больше не сможет ее перехватить.
Мне бы хотелось, чтобы в Eclipse была возможность скомпилировать мой проект со старым Android SDK, чтобы убедиться, что мой «нейтральный к версии» код подходит. Я хотел бы избежать перемещения моей системы сборки из Eclipse, если это возможно. Я согласен, что эта старая сборка SDK немного неудобна в работе.
Я думаю, что это сводится к выполнению некоторого условного комплимента (или условного "связывания") внутри Eclipse? Например, в моем проекте при сборке с использованием SDK-1.6 я хотел бы исключить источник "MultiTouchHandler.java" из сборки. Однако я не уверен, что в Eclipse можно выразить такие «типы сборки».
Кажется, что хакерское решение заключается в том, чтобы просто вручную изменить версию SDK проекта, перестроить и просмотреть ошибки, а также игнорировать «ожидаемые» ошибки. Похоже, что решением для перерасхода является написание моих собственных скриптов ant / maven / make build.
Смежные вопросы
Этот вопрос:
Управление версиями и общие кодовые базы с Eclipse
охватывает аналогичную основу, но будет включать перемещение всех классов, зависящих от версии, в отдельные «библиотеки». (И я думаю, что в Eclipse у меня все еще будет проблема с несколькими типами сборки.)
Этот вопрос:
Сборка нескольких конфигураций проекта с помощью eclipse подразумевает, что я должен перейти на внешнюю систему сборки (например, ant или maven), но это гораздо больше, чем просто время от времени пытаться собрать сборку со старым SDK.