Android для netbeans ide

Разработка под Android в NetBeans IDE без плагинов. Часть 1

Обычно у разработчика есть свой любимый инструмент, которым ему пользоваться удобнее, чем другими. Однако бывает так, что платформа заставляет разработчиков брать в руки инструмент, который не так удобен, как ему хотелось бы, или просто чем-то не устраивает. Так получилось, что традиционно приложения под Android пишут при помощи Eclipse, поскольку Google приняли решение о том, что будут разрабатывать официальный плагин, ADT, именно для этого редактора. В результате тем разработчикам, которые им не пользовались, волей-неволей пришлось его освоить.

К счастью, Google также предоставляют систему сборки, которая работает независимо от имеющейся в наличии IDE. А это означает, что можно настроить любой редактор для работы с приложениями Android. Лично я предпочитаю писать код на Java в NetBeans IDE и хочу поведать о том, как его можно настроить для этого. Есть такие плагины, как nbandroid, но разрабатывается он нерегулярно, энтузиастами, так что есть смысл воспользоваться гибкостью NetBeans и задействовать официальную систему сборки напрямую из редактора.

Создание нового проекта

При создании нового проекта, к сожалению, придётся сделать больше действий, чем можно было бы сделать в Eclipse, но это нужно сделать всего лишь один раз. Создание проекта делается в три шага:

1. Создание файлов для сборки из командной строки;
2. Создание проекта в IDE;
3. Добавление дополнительных команд (по вкусу).

Создание файлов для сборки

Прежде всего, необходимо создать новый проект через командную строку. Я буду исходить из предположения, что в PATH уже затесалась папка /tools . Проект создаётся следующей командой:

android create project -n -t android- -p -k -a

На всякий случай поясню, что уровень API — это тот самый, с помощью которого мы будем компилировать проект. То есть если проект в целом рассчитан на уровень API 10, но есть некоторые возможности, которые используются только на аппаратах с уровнем 15 и выше, то нужно именно 15 и выставить. В AndroidManifest.xml , кстати, эта 15 не засветится, там будет только 10 как минимально необходимый уровень API.

Предположим, что наш проект создаётся для Android 4.0.3 (это уровень 15) и называется KillerApp. Тогда нужно будет ввести следующее:

android create project -n KillerApp -t android-15 -p KillerApp -k com.damageinc.killerapp -a MainActivity

После этой команды в папке проекта завелись все нужные нам файлы: конфигурационные файлы и, самое главное, файл сборки. На этом работа с командной строкой закончена, и мы больше её не увидим. Теперь осталось поколдовать в IDE.

Создание проекта в IDE

На экране создания нового проекта в NetBeans понадобится пункт Java Free-Form Project, с помощью которого мы растолкуем IDE, где брать файл сборки.

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

А вот теперь надо правильно прописать задания сборки, чтобы IDE знала, что запускать, когда мы заходим собрать проект. Сборка в системе осуществляется заданием debug. Это немного странно выглядит, но причина такого названия очень простая: это задание создаёт сборку для отладки, подписанную соответствующим сертификатом. Соответственно, есть задание release, до которого мы ещё доберёмся. Запуск проекта в нашем случае означает сборку и установку, что означает выполнение задания install после сборки. Там ещё приписано задание launch , которого в стандартной системе нет, но мы его сделаем и сами. Очистка — это, вполне ожидаемо, clean, а тестировать в Android нужно через отдельный, тестовый проект, поэтому то, что находится в том поле, можно смело стирать.

На следующем экране нужно добавить папку gen к папкам исходников, потому что именно в этой папке будет находится файл R.java .

Теперь настраиваем подсказки по коду. Прежде всего, важно снять флажок разделения папок с исходниками, иначе IDE будет думать, что файл R не должен упоминаться в коде нашей программы, поскольку лежит в отдельной папке. Также нужно добавить правильную платформу Android в список библиотек, в нашем случае это /platforms/android-15/android.jar .

И, наконец, последний шаг, добавляем папку bin/classes , чтобы IDE знала, где искать скомпилированный код. В принципе, этот шаг не обязателен, и на него можно смело наплевать. Но для полноты картины я сделаю и его, чтобы NetBeans показывал, какие файлы были недавно изменены и ещё не скомпилированы.

Добавление дополнительных команд

Эти три задания нам позволяют делать кое-какие весьма полезные вещи. rebuild-resources позволяет сгенерировать файл R (который в Eclipse, кстати, нередко куда-то исчезает или не обновляется вовремя). launch даст нам возможность запускать приложения, а release-and-save позаботится о том, чтобы при сборке финальной версии она сохранилась в отдельной папке под соответствующим именем вместе с картой методов ProGuard. Ещё я люблю добавлять такие строчки, чтобы после сборки проигрывалось уведомление:

Разумеется, этот конкретный вариант звука годится только для Windows, для других ОС стоит выбрать другой файл. Теперь осталось добавить эти задания в контекстное меню в NetBeans. В свойствах проекта на вкладке Build and Run мы уже заранее доработали пункт Run Project заданием launch в конце. В пользовательские элементы контекстного меню я добавил остальные только что сделанные задания:

Теперь в конекстном меню проекта весь букет необходимых нам команд. Можно запустить эмулятор или подключить смартфон, запустить Run и смотреть, как всё собирается и само запускается. Осталось сделать последние штрихи и включить обфускацию при сборке финальной версии, раскомментировав строчку в файле project.properties :

Также в ant.properties стоит прописать строчки для подписи финальных сборок:

Вот теперь у нас проект готов к работе.

Как работает система сборки в Android

На самом деле, системы сборки в Android на данный момент сейчас уже две: одна основана на ant, а другая — на Gradle. В данном конкретном случае мы пользуемся системой ant. Система с Gradle разрабатывается параллельно с новым редактором, идущим на замену Eclipse — Android Studio. Эта система сборки, думаю, пригодится для отдельной статьи.

Возвращаясь к ant, в папке проекта лежат следующие файлы:

• ant.properties
• build.xml
• local.properties
• proguard-project.txt
• project.properties

Самый важный файл здесь — это, разумеется, build.xml . На самом деле, это лишь маленький хвостик основной системы, и всё, что он делает — это загрузка свойств из файлов с расширением properties и вызов основной системы, располагающейся в самом SDK.

local.properties содержит всего лишь одно свойство: расположение папки с SDK. Этот файл нужно занести в список исключений системы контроля версий, потому что он содержит настройки, специфические для отдельной машины. Например, у меня под Windows этот файл содержит строчку

На самом деле, можно создать переменную окружения ANDROID_HOME с содержимым переменной из этого файла и благополучно отправить файл в мусорку. Главное, не забудьте после этого перезапустить NetBeans.

С ant.properties мы уже познакомились, там хранятся вспомогательные переменные вроде расположения хранилища ключей. Также есть файл project.properties . После действий, описанных в создании проекта, там есть только строчки об уровне API Android, для которого собирается проект, и о том, где искать файл конфигурации ProGuard. Когда мы будем добавлять в проект библиотеки, строчки о них окажутся там же.

Наконец, файл proguard-project.txt , который, как следует из названия, содержит указания ProGuard. Он изначально пуст, но это вовсе не значит, что ProGuard будет работать вхолостую, поскольку в папке SDK уже есть заранее записанная конфигурация (помните раскомментированную строчку о ProGuard?), а здесь мы можем её конкретизировать. Например, я лично люблю, помимо прочих, добавлять строчки

-renamesourcefileattribute MyProject
-keepattributes SourceFile,LineNumberTable

Они в дальнейшем помогают собирать отчёты об ошибках, поскольку теперь есть точные данные о том, какая строчка кода в проекте вызывает падение или исключение.

Также build.xml загружает файл custom_rules.xml , если он есть, в котором мы и добавили все необходимые нам задания. Стоит взглянуть на задания ещё раз.

Эти строчки взяты просто из системы сборки SDK. К сожалению, там они не вынесены в отдельное задание, поэтому пришлось делать это самостоятельно. Интереснее взглянуть на другие два задания:

С помощью XPath здесь достаются параметры версии и дальше с их помощью генерируются имена файлов. В обычном ant поддержки XPath нет, так откуда же он тут взялся? В Android SDK Google добавили свои собственные инструменты для того, чтобы работать с приложениями было удобнее. Многие из их инструментов сводятся к запуску определённых файлов из SDK, но есть и те, которые облегчают написание файлов сборки, такие как xpath . Ещё одним полезным инструментом, например, является if , делающий именно то, что делает соответствующая конструкция в языках программирования: выполнение того или иного задания в зависимости от условия.

Второе задание тоже использует xpath , на этот раз задача немного сложнее:

Необходимо найти активность, которая определяет в своем фильтре намерений категорию android.intent.category.LAUNCHER — именно так в Android определяются активности, которые должны показываться в меню. Их может быть и несколько (хотя это бывает редко), поэтому задание берёт первую из них.

Есть и ещё одна загвоздка. Активности декларируются в AndroidManifest.xml либо записью с полным именем, либо только именем класса с точкой впереди, если активность лежит в главном пакете. По крайней мере, так говорит документация. Только вот проблема в том, что Eclipse и прочий инструментарий позволяет точку опускать и просто писать имя активности, когда она находится в главном пакете. Android-то такое попустительство терпит, а вот команда, запускающая приложения, уже нет. Приходится добавлять точку, когда её не хватает. Вот тут нам и поможет задание if , недавно мной упомянутое, и регулярные выражения.

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

• -pre-build
• -pre-compile
• -post-compile
• -post-package
• -post-build
• -pre-clean

Хуки отражают этапы, через которые проходит сборка программы: компиляция библиотек, генерирование кода (RenderScript, aidl, R, BuildConfig), компиляция проекта, упаковка APK, подпись и zipalign. Соответственно, -pre-build вызывается прежде, чем начнутся все эти действия, -pre-compile непосредственно перед компиляцией самого проекта, -post-compile — между компиляцией и упаковкой, -post-build — после упаковки, но до подписи, и -post-build вызывается в самом конце. Ну а когда вызывается -pre-clean , думаю, понятно из названия.

Источник

Разработка под Android в NetBeans IDE без плагинов. Часть 1

Обычно у разработчика есть свой любимый инструмент, которым ему пользоваться удобнее, чем другими. Однако бывает так, что платформа заставляет разработчиков брать в руки инструмент, который не так удобен, как ему хотелось бы, или просто чем-то не устраивает. Так получилось, что традиционно приложения под Android пишут при помощи Eclipse, поскольку Google приняли решение о том, что будут разрабатывать официальный плагин, ADT, именно для этого редактора. В результате тем разработчикам, которые им не пользовались, волей-неволей пришлось его освоить.

К счастью, Google также предоставляют систему сборки, которая работает независимо от имеющейся в наличии IDE. А это означает, что можно настроить любой редактор для работы с приложениями Android. Лично я предпочитаю писать код на Java в NetBeans IDE и хочу поведать о том, как его можно настроить для этого. Есть такие плагины, как nbandroid, но разрабатывается он нерегулярно, энтузиастами, так что есть смысл воспользоваться гибкостью NetBeans и задействовать официальную систему сборки напрямую из редактора.

Создание нового проекта

При создании нового проекта, к сожалению, придётся сделать больше действий, чем можно было бы сделать в Eclipse, но это нужно сделать всего лишь один раз. Создание проекта делается в три шага:

1. Создание файлов для сборки из командной строки;
2. Создание проекта в IDE;
3. Добавление дополнительных команд (по вкусу).

Создание файлов для сборки

Прежде всего, необходимо создать новый проект через командную строку. Я буду исходить из предположения, что в PATH уже затесалась папка /tools . Проект создаётся следующей командой:

android create project -n -t android- -p -k -a

На всякий случай поясню, что уровень API — это тот самый, с помощью которого мы будем компилировать проект. То есть если проект в целом рассчитан на уровень API 10, но есть некоторые возможности, которые используются только на аппаратах с уровнем 15 и выше, то нужно именно 15 и выставить. В AndroidManifest.xml , кстати, эта 15 не засветится, там будет только 10 как минимально необходимый уровень API.

Предположим, что наш проект создаётся для Android 4.0.3 (это уровень 15) и называется KillerApp. Тогда нужно будет ввести следующее:

android create project -n KillerApp -t android-15 -p KillerApp -k com.damageinc.killerapp -a MainActivity

После этой команды в папке проекта завелись все нужные нам файлы: конфигурационные файлы и, самое главное, файл сборки. На этом работа с командной строкой закончена, и мы больше её не увидим. Теперь осталось поколдовать в IDE.

Создание проекта в IDE

На экране создания нового проекта в NetBeans понадобится пункт Java Free-Form Project, с помощью которого мы растолкуем IDE, где брать файл сборки.

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

А вот теперь надо правильно прописать задания сборки, чтобы IDE знала, что запускать, когда мы заходим собрать проект. Сборка в системе осуществляется заданием debug. Это немного странно выглядит, но причина такого названия очень простая: это задание создаёт сборку для отладки, подписанную соответствующим сертификатом. Соответственно, есть задание release, до которого мы ещё доберёмся. Запуск проекта в нашем случае означает сборку и установку, что означает выполнение задания install после сборки. Там ещё приписано задание launch , которого в стандартной системе нет, но мы его сделаем и сами. Очистка — это, вполне ожидаемо, clean, а тестировать в Android нужно через отдельный, тестовый проект, поэтому то, что находится в том поле, можно смело стирать.

На следующем экране нужно добавить папку gen к папкам исходников, потому что именно в этой папке будет находится файл R.java .

Теперь настраиваем подсказки по коду. Прежде всего, важно снять флажок разделения папок с исходниками, иначе IDE будет думать, что файл R не должен упоминаться в коде нашей программы, поскольку лежит в отдельной папке. Также нужно добавить правильную платформу Android в список библиотек, в нашем случае это /platforms/android-15/android.jar .

И, наконец, последний шаг, добавляем папку bin/classes , чтобы IDE знала, где искать скомпилированный код. В принципе, этот шаг не обязателен, и на него можно смело наплевать. Но для полноты картины я сделаю и его, чтобы NetBeans показывал, какие файлы были недавно изменены и ещё не скомпилированы.

Добавление дополнительных команд

Эти три задания нам позволяют делать кое-какие весьма полезные вещи. rebuild-resources позволяет сгенерировать файл R (который в Eclipse, кстати, нередко куда-то исчезает или не обновляется вовремя). launch даст нам возможность запускать приложения, а release-and-save позаботится о том, чтобы при сборке финальной версии она сохранилась в отдельной папке под соответствующим именем вместе с картой методов ProGuard. Ещё я люблю добавлять такие строчки, чтобы после сборки проигрывалось уведомление:

Разумеется, этот конкретный вариант звука годится только для Windows, для других ОС стоит выбрать другой файл. Теперь осталось добавить эти задания в контекстное меню в NetBeans. В свойствах проекта на вкладке Build and Run мы уже заранее доработали пункт Run Project заданием launch в конце. В пользовательские элементы контекстного меню я добавил остальные только что сделанные задания:

Теперь в конекстном меню проекта весь букет необходимых нам команд. Можно запустить эмулятор или подключить смартфон, запустить Run и смотреть, как всё собирается и само запускается. Осталось сделать последние штрихи и включить обфускацию при сборке финальной версии, раскомментировав строчку в файле project.properties :

Также в ant.properties стоит прописать строчки для подписи финальных сборок:

Вот теперь у нас проект готов к работе.

Как работает система сборки в Android

На самом деле, системы сборки в Android на данный момент сейчас уже две: одна основана на ant, а другая — на Gradle. В данном конкретном случае мы пользуемся системой ant. Система с Gradle разрабатывается параллельно с новым редактором, идущим на замену Eclipse — Android Studio. Эта система сборки, думаю, пригодится для отдельной статьи.

Возвращаясь к ant, в папке проекта лежат следующие файлы:

• ant.properties
• build.xml
• local.properties
• proguard-project.txt
• project.properties

Самый важный файл здесь — это, разумеется, build.xml . На самом деле, это лишь маленький хвостик основной системы, и всё, что он делает — это загрузка свойств из файлов с расширением properties и вызов основной системы, располагающейся в самом SDK.

local.properties содержит всего лишь одно свойство: расположение папки с SDK. Этот файл нужно занести в список исключений системы контроля версий, потому что он содержит настройки, специфические для отдельной машины. Например, у меня под Windows этот файл содержит строчку

На самом деле, можно создать переменную окружения ANDROID_HOME с содержимым переменной из этого файла и благополучно отправить файл в мусорку. Главное, не забудьте после этого перезапустить NetBeans.

С ant.properties мы уже познакомились, там хранятся вспомогательные переменные вроде расположения хранилища ключей. Также есть файл project.properties . После действий, описанных в создании проекта, там есть только строчки об уровне API Android, для которого собирается проект, и о том, где искать файл конфигурации ProGuard. Когда мы будем добавлять в проект библиотеки, строчки о них окажутся там же.

Наконец, файл proguard-project.txt , который, как следует из названия, содержит указания ProGuard. Он изначально пуст, но это вовсе не значит, что ProGuard будет работать вхолостую, поскольку в папке SDK уже есть заранее записанная конфигурация (помните раскомментированную строчку о ProGuard?), а здесь мы можем её конкретизировать. Например, я лично люблю, помимо прочих, добавлять строчки

-renamesourcefileattribute MyProject
-keepattributes SourceFile,LineNumberTable

Они в дальнейшем помогают собирать отчёты об ошибках, поскольку теперь есть точные данные о том, какая строчка кода в проекте вызывает падение или исключение.

Также build.xml загружает файл custom_rules.xml , если он есть, в котором мы и добавили все необходимые нам задания. Стоит взглянуть на задания ещё раз.

Эти строчки взяты просто из системы сборки SDK. К сожалению, там они не вынесены в отдельное задание, поэтому пришлось делать это самостоятельно. Интереснее взглянуть на другие два задания:

С помощью XPath здесь достаются параметры версии и дальше с их помощью генерируются имена файлов. В обычном ant поддержки XPath нет, так откуда же он тут взялся? В Android SDK Google добавили свои собственные инструменты для того, чтобы работать с приложениями было удобнее. Многие из их инструментов сводятся к запуску определённых файлов из SDK, но есть и те, которые облегчают написание файлов сборки, такие как xpath . Ещё одним полезным инструментом, например, является if , делающий именно то, что делает соответствующая конструкция в языках программирования: выполнение того или иного задания в зависимости от условия.

Второе задание тоже использует xpath , на этот раз задача немного сложнее:

Необходимо найти активность, которая определяет в своем фильтре намерений категорию android.intent.category.LAUNCHER — именно так в Android определяются активности, которые должны показываться в меню. Их может быть и несколько (хотя это бывает редко), поэтому задание берёт первую из них.

Есть и ещё одна загвоздка. Активности декларируются в AndroidManifest.xml либо записью с полным именем, либо только именем класса с точкой впереди, если активность лежит в главном пакете. По крайней мере, так говорит документация. Только вот проблема в том, что Eclipse и прочий инструментарий позволяет точку опускать и просто писать имя активности, когда она находится в главном пакете. Android-то такое попустительство терпит, а вот команда, запускающая приложения, уже нет. Приходится добавлять точку, когда её не хватает. Вот тут нам и поможет задание if , недавно мной упомянутое, и регулярные выражения.

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

• -pre-build
• -pre-compile
• -post-compile
• -post-package
• -post-build
• -pre-clean

Хуки отражают этапы, через которые проходит сборка программы: компиляция библиотек, генерирование кода (RenderScript, aidl, R, BuildConfig), компиляция проекта, упаковка APK, подпись и zipalign. Соответственно, -pre-build вызывается прежде, чем начнутся все эти действия, -pre-compile непосредственно перед компиляцией самого проекта, -post-compile — между компиляцией и упаковкой, -post-build — после упаковки, но до подписи, и -post-build вызывается в самом конце. Ну а когда вызывается -pre-clean , думаю, понятно из названия.

Источник