Главная » Разработка для Android » ОРГАНИЗАЦИЯ ИСХОДНОГО КОДА JAVA – Android

0

 

Была изложена базовая информация о комплекте для разработки ПО под Android (Android SDK). Мы сузили фокус проблемы, подробно рассмотрев один из наиболее популярных инструментов для разработки под Android – интегрированную среду разработки Eclipse. Сделаем еще один шаг и изучим, как в проекте организуется код.

Еще раз подчеркнем, что проект – это рабочее пространство, выделенное для создания целостного развертываемого артефакта. В широком смысле в мире Java артефакт может представлять собой всего лишь библиотеку (файл JAR, который не может запускаться сам по себе, но реализует определенный специфический функционал). С другой стороны, артефакт может быть развертываемым веб-приложением или приложением для ПК, которое вызывается двойным щелчком на ярлыке на Рабочем столе.

В контексте Android артефакт – это, как правило, одиночная служба, которую можно запустить: ContentProvider, Service или Activity. Поставщик содержимого, используемый отдельной активностью, определенно может начинать свой жизненный цикл как часть проекта активности. Если возникнет ситуация, в которой им должна будет воспользоваться другая активность, то, возможно, потребуется произвести рефакторинг и выделить этот поставщик содержимого в собственный проект.

Как правило, компилятор Java ожидает, что деревья каталогов будут содержать файлы с исходным кодом Java (JAVA), к которым компилятор применяет синтаксический разбор, и двоичные файлы (CLASS), выдаваемые в качестве вывода. Хотя это и не необходимо, но управлять проектом становится гораздо проще, если у деревьев, содержащих файлы первого и второго вида, будут разные корни, в качестве которых обычно выступают каталоги, называемые соответственно src и bin.

В проекте Android присутствуют еще два очень важных дерева каталогов — res и gen. В res содержатся определения статических ресурсов: цветов, константных строк, компоновки и т. д. Инструменты Android выполняют предварительную обработку этих определений, преобразуя их в значительно оптимизированные представления и исходный код Java, через который код приложения ссылается на эти представления. Автоматически сгенерированный код, а также код, созданный для объектов AIDL помещается в каталоге gen. Система компилирует содержимое обоих каталогов, и полученный в результате материал помещает в bin.

Исходный код вашего приложения находится в каталоге src. Как было указано, нужно поместить весь код в пакет, имя которого является производным от доменного имени владельца кода. Предположим, например, что вы – разработчик в огромной фирме, сайт которой называется awesome-android.net. И вот вам поручено написать для voracious-carrier.com программу, которая выдавала бы прогноз погоды. Вероятно, вы поместите весь ваш код в пакет com. voraci ouscarri er. weatherprediction или, например, com.voracious_carrier.weather_prediction. Хотя символ – вполне можно использовать в доменных именах службы DNS, он не допускается в названиях пакетов Java. Пользовательский интерфейс для этого грандиозного приложения может находиться в пакете com.voraciouscarrier. weatherpredi ction. ui, а модель приложения – в com. voraci ouscarri er. weatherpredi ction. futureweather.

Заглянув в каталог src проекта, вы обнаружите в нем подкаталог, который называется com. Он, в свою очередь, содержит каталог voraciouscarrier и т. д. Дерево исходных каталогов структурно отражает дерево пакетов. Компилятор Java ожидает, что каталоги будут выстроены именно таким образом, и, возможно, не сможет скомпилировать ваш код, если он имеет иную структуру.

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

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

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

Источник: Android. Программирование на Java для нового поколения мобильных устройств

По теме:

  • Комментарии