Androider

Обзор

Каждое приложение должно иметь файл AndroidManifest.xml (именно с таким именем) в его корневой папке. Манифест содержит информацию о приложении для ОС Android, эта информация необходима системе прежде чем она запустит какой-либо код на исполнение. Среди прочих вещей, манифест делает следующие вещи:

• Он содержит название пакета Java. Это имя является уникальным идентификатором для приложения.
• Он описывает компоненты приложения - activities, services, broadcast receivers, и content providers, из которых состоит приложение. Оно содержит имена для классов, которые описывают каждый компонент и описывает условия их использования (к примеру, какие сообщения интент может принимать). Эти описания предоставляют информацию ОС Android о компонентах приложения и о условиях их выполнения.
• Он определяет какие процессы будут обрабатывать компоненты приложения
• Он описывает разрешения(permissions), которые необходимы приложению для работы с защищенными частями API и с другими приложениями.
• А так же содержит разрешения(permissions), которые необходимы для связи с компонентами системы.
• Содержит списки классов, используемых для профилирования и для получения другой информации о приложении во время исполнения. Эти описания присутствуют только при разработке и тестировании. Перед публикацией они удаляются из манифеста.
• Он описывает минимальный уровень Android API, необходимый для приложения
• Он содержит список библиотек, с которыми приложение должно быть слинковано

Структура файла

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

<?xml version="1.0" encoding="utf-8"?>

<manifest>

 <uses-permission />
<permission />
<permission-tree />
<permission-group />

 <instrumentation />

 <uses-sdk />

 <application>

 <activity>
 <intent-filter>
 <action />
 <category />
 <data />
 </intent-filter>
 <meta-data />
 </activity>

 <activity-alias>
 <intent-filter> . . . </intent-filter>
 <meta-data />
 </activity-alias>

 <service>
 <intent-filter> . . . </intent-filter>
 <meta-data/>
 </service>

 <receiver>
 <intent-filter> . . . </intent-filter>
 <meta-data />
 </receiver>
<provider>
 <grant-uri-permission />
 <meta-data />
 </provider>

 <uses-library />
 <uses-configuration />  

 </application>

</manifest>

Правила для файла

• Обязательны только  <manifest> и <application> элементы
• Все параметры передаются только через атрибуты
• Только элементы - между тегов не может быть обычного текста
• Порядок элементов не важен. Единственное исключение <application-alias> должен следовать за соответствующим <application>
• Формально аттрибуты не обязательно, но многие элементы имеют обязательные параметры. Смотрите документацию
• Все, кроме <manifest>, имеют перед параметры, начинающиеся с “android:"
• Имена классов почти всегда пишутся полностью с именем пакета, ислючение - классы в пакете, который указан в манифесте - их просто можно начинать с точки
• Имена ресурсов пишутся так: @[package:]type/name, для тем - ?[package:]type/name

Возможности Манифеста

Intent Filters

Интенты - основа метода вызова компонентов приложения. Интент - это некий набор данных. Содержит себе название действия, некоторые его параметры, а так же еще некоторые инструкции.

Система получает интент, создает экземпляр объекта (если нужно), а потом передает в этот объект этот интент.

Для того, что бы компонент мог принять интент существуют intent-filters и они описываются в манифесте тегом <intent-filter>, в котором можно задать условия принятия интента.

Иконки и Текст

Некоторые элементы содержат поля icon, label и description.

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

Permissions

Permission - это способ получить доступ к закрытой части API. Эта защита существует для защиты пользователя от приложения.

Для того, что бы показать, что приложение использует Permission необходимо прописать тег. Эти Permissions показываются, к примеру, при установке приложения.

У приложения могут быть свои компоненты с разрешениями для их использования - они задаются через тег

В данный раз внешних изменений почти нет.

• Пока что выключена карта, поскольку съедает много памяти
• Отрисовка GRP-изображений была переделана - теперь есть два рендера: первый рисует, на лету преобразуя индексы цветов в массив цветов, а затем уже рисует, второй же сразу все кеширует в битмапы. Скорость отрисовки во втором случае больше в разы, но в первом случае памяти в два раза меньше потребляется
• Сделан полный рефакторинг кода. Добавлено наследование. Отказ от него из-за маленькой скорости - было глупостью, ибо она усложняла сильно код и не позволяла писать сопровождаемый код.
• Все полностью перенесено на SDK 1.5
• Добавлено управление на экране

Что дальше? необходимо по-прежнему улучшать код графической части - необходима разработка хорошего алгоритма для кеширования графики, поскольку производительность андроида оставляет желать лучшего.

Сегодня я смог добится загрузки карты старкрафта! Это еще один шажок на пути к реализации идеи)

Все идет пока что даже слишком легко… надеюсь у меня не будет проблем с AI. Насколько мне известно там простые скрипты, которые описывают каждое действие и не будет проблем и с этим)

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

На всякий случай вот пруфлинк(в мой блог не захотело аплоадится):

Здесь я сначала размещу копипаст с какого-то английского ресурса, а затем сделаю перевод.

Делаю что бы не потерялось в сети это чудо)

UPD Нашел неточности, узнал значение неизвестных байтов
» Читать полностью …

Сегодня с утра я проснулся от того, что мне позвонил друг… позвонил рано) даже очень) Но день, тем не менее не испортился. Поскольку у меня было много времени (появилось часа три-четыре) я вспомнил про мою любимую игру детства - StarCraft. Ну и соответственно, вспомнив как там все было сделано, я пришел к выводу, что это все вполне реализуемо.

И так. сейчас опишу то, чего я добился в эти три-четыре часа.

• Загрузка одного юнита, в принципе можно и других, но пока нужно формализовать движок
• Некоторая анимация - выравнивание изображения юнита по направлению движения
• Найдены соответствующие утилиты для распаковки архивов и т.д.

Если учесть, что это все я получил часа за три, то думаю, что это не плохой результат для начала и все раельно реализуемо. Единственная проблема - это очень большое множество разных юнитов, у которых разная анимация, у некоторых состоит из двух файлов, у кого-то разная анимация при движении и неподвижности, у кого-то разная и тпх. Реализовывать придется все в коде в виде виртуальных классов. Вторая проблема - написание AI. Однако, когда он уже будет необходим, то я уж смогу показать многим людям, что я сделал, и, надеюсь, найдется хотя бы один человек, что бы его завершитЬ, поскольку тут всего и так много….