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