Все для телефонов Sony Ericsson Мобильные клубы: Sony Ericsson, Siemens, Nokia
Телефоны |  Обзоры и тесты |  Аксессуары |  Программы |  Инструкции |  Мелодии |  Игры для Sony Ericsson |  Картинки |  Темы |  Патчи |  Эльфы | 
ГлавнаяФорум ЛучшиеКарта FAQ Правила Поиск
 [ Регистрация| Вход ]


WAP/PDA версия сайта доступна по адресу http://waping.ru

Пишем софт для телефона на UIQ3


Новая тема Написать ответ Форумы Все для телефонов Sony Ericsson » Мобильное программирование Версия для печати
Автор Сообщение
DUG
Смартфоман
<b>Смартфоман</b>
Популярность: +39 (53)

Возраст: 81
С нами с: 23.04.2007
Сообщений: 1612

1/15 СообщениеДобавлено:Пт Авг 24, 2007 14:24   Заголовок сообщения:
Цитата

UIQ 3 - "HELLO WORLD!"
Как запускать прикладную структуру.

Введение.
Это - первый официальный документ в ряду официальных документов, которые будут вести новых и старых разработчиков через самые важные особенности UIQ 3 Application Development Platform (ADP). Этот документ подразумевает, что вы немного знакомы с программированием SymbianOS, так как фундаментальные понятия не будут описаны здесь. Если Вы не, знакомымы с фундаментальными понятиями и некоторые термины будет непонятны, то рекомендую изучить общее программирование Symbian OS (в скором будущем я выложу основы программирования на Symbian).

Инсталляция SDK.
Чтобы следовать документу, Вы должны установить UIQ 3 SDK. Кроме того Вы будете должны установить Nokia x86 компилятор и произвольно, компилятор GCC-E, которые являются частью SDK. Вы можете кроме того установить одну из различных доступных интегрированных сред разработки, но здесь, мы не будем использовать их. Наборы процесса инсталляции SDK также устанавливаются в путь по умолчанию и делают UIQ 3 SDK по умолчанию device1.

Конфигурация UI.
Программная Платформа UIQ очень универсальна и может быть конфигурирована большим количеством параметров конфигурации. Один набор параметров конфигурации (так называемые Параметры Конфигурации UI) реализует стиль телефона и позволяет конфигурировать Программную Платформу UIQ относительно touch/non-touch экранов, размера экрана, использование Строки меню или использования Функциональных клавиш и т.д. Каждую комбинацию таких параметров называют Конфигурацией UI. UIQ 3.0 определяет множество стандартных конфигураций UI, которые поддержаны в UIQ 3 SDK. Две самые важные конфигурации UI показаны на рисунке:

Вы должны осуществить все примеры в обеих из конфигураций UI , даже в этом случае результат не одинаков. Поэтому рекомендуется, чтобы Вы использовали ту же самую конфигурацию UI какая описывается в примерах. Чтобы изменять на Pen Style конфигурацию UI, Вы только должны обратиться к командной строке следующие команды, до старта эмулятора:

cmd> uiqenv -ui pen

и переключать назад к Стилю Функциональных клавиш конфигурации UI, наберите:

cmd> uiqenv -ui softkey


Последний раз редактировалось: (Пт Авг 24, 2007 22:55), всего редактировалось 3 раз(а)
Вернуться к началу ПрофильЛичное
DUG
Смартфоман
<b>Смартфоман</b>
Популярность: +39 (53)

Возраст: 81
С нами с: 23.04.2007
Сообщений: 1612

2/15 СообщениеДобавлено:Пт Авг 24, 2007 14:26   Заголовок сообщения:
Цитата

ЧАСТЬ 1
Введение

В первой части документа рассмотрим краткий обзор ключевых элементов, которые являются необходимыми. Таким образом, мы создадим простой скелет приложения UIQ 3 (без реальных функциональных возможностей) на пустом месте и объясним каждый элемент. Потом Вы будете часто копировать такой скелет приложения приспосабливается это к вашим потребностям и используется как ваша отправная точка развития. Весь код примера, обеспеченный UIQ следует за определенным обозначением и соглашением структуры, за которым мы будем также следовать. Как только Вы разработаете ваш путь прочитав эту статью, Вы должны будете:

• знать стандартную структуру проекта UIQ;
• знают важные проектные файлы;
• знают, как регистриовать ваше приложение;
• имеют понимание прикладной структуры структуры;
• знают, как запустить прикладную структуру;
• знают, как создать представление;
• знают, как сделать некоторый простой рисунок в пределах представления.

Этот первый документ, однако, он не в состоянии объяснить все, и поэтому много информации будет добавлено. Итак, начнем создавать наше приложение QHelloWorld...
Вернуться к началу ПрофильЛичное
DUG
Смартфоман
<b>Смартфоман</b>
Популярность: +39 (53)

Возраст: 81
С нами с: 23.04.2007
Сообщений: 1612

3/15 СообщениеДобавлено:Пт Авг 24, 2007 18:51   Заголовок сообщения:
Цитата

Часть 2
Строение и создание файлов


2.1 Введение
Прежде, чем начинать писать приложение, мы должны сделать некоторую предварительную работу. Это включает создание build- и make-файлов. здесь мы рассмотрим создание очень, очень простого приложения, которое ничего не делает, но это позволит нам проверить строение скелета.


2.2 Структура папки.
Все приложения UIQ обычно структурируются одинаково, и поэтому очень полезно понять структуру. Кроме того, может быть очень полезно понять, какие файлы мы собираемся создавать или изменять в каждом разделе, поэтому мы, представим краткий обзор по файлам и где они расположены в пределах проектной структуры. Вы можете структурировать ваш проект, как хотите, но пример, будет сгруппирован таким образом. Поэтому если Вы хотите использовать код копией и вставкой этой структуры, Вы должны придерживаться той же самой структуры.



Папки имеют следующие задачи:
data — эта папка содержит данные, которые приложение использует. Те - большинство файлов точечных рисунков, но также могут быть звуковые файлы. Чтобы лучше сохранять краткий обзор, файлы сортированы в подпапки;
doc — эта папка содержит некоторую документацию, определенную для компонента;
group — эта папка содержит все файлы, требуемые для того, чтобы строить наше приложение. Это местоположение зависит от того, где мы выполняем все строящиеся команды;
inc — эта папка содержит все общественные файлы заголовка. Это не обязательно означает, что они экспортируются;
rsc — эта папка содержит весь ресурс и связанные с ресурсом файлы;
reg — эта папка содержит все прикладные регистрационные файлы;
src — эта папка содержит все исходные файлы.

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



Наше простое приложение QHELLOWORLD не использует эту расширенную структуру.


2.3 Файл типа "build" (bld.inf)
Для большинства разработчиков самое легкое первоначально разработать программу SymbianOS для эмулятора на Windows, и только позже собрать это для процессора ARM. Это приводит к более простому и более быстрому развитию. Единственная вещь, которую Вы будете должны сделать, должна следовать за некоторыми простыми правилами так, чтобы Вы не столкнулись с проблемами позже. Файл типа "build" (bld.inf), расположенный в нашем случае в каталоге группы, определяет то, что и для каких адресатов мы хотели бы быть строить. Чтобы запустить наше приложение QHELLOWORLD мы определяем относительный путь (относительно каталога, содержащего bld.inf файл) к makefile в разделе PRJ_MMPFILES. Так как мы только хотим строить наше приложение для OS Symbian emulator1 вызываемый командой winscw, мы определяем что ключевое слово в разделе PRJ_PLATFORMS. Таким образом, наш bld.inf файл похож на следующее:

// QHelloWorld.mmp
PRJ_MMPFILES
QHelloWorld.mmp
PRJ_PLATFORMS
winscw

Позже мы можем определить несколько субкомпонентов и сможем экспортировать файлы заголовка (общественные интерфейсы) и т.п. также сможем определить испытательные компоненты, и строить с gnumake makefile намного больше.

2.4 The makefile (QHelloWorld.mmp)
Mmp-файл - своего рода мета-makefile, из которого будет создан соответствующий makefile. Это убирает всю сложность наличия различных форматов makefile для различных компиляторов, адресатов, интегрированных сред разработки. Единственная вещь, которую Вы должны сделать — написать такой mmp-файл. Так же нуждаемся в mmp-файле для нашего Приложения, вот самая простая версия:

// QHelloWorld.mmp
TARGET QHelloWorld.exe
TARGETTYPE EXE
UID 0x100039CE 0xE1000001
SOURCEPATH ..\src
SYSTEMINCLUDE \epoc32\include
SOURCE QHelloWorldApplication.cpp
LIBRARY EUSER.LIB

TARGET определяется из название набора двух предметов, который мы создадим, TARGETTYPE определяет, из какого типа набор из двух предметов должен быть (обычно EXE или DLL]). Наше приложение должно быть EXE.

UID идентифицирует наш двоичный код. Каждый двоичный код ОС Symbian идентифицирован тремя UIDs. Первый - всегда то же самое, что и для двоичных файлов, и поэтому это не упомянуто выше. Таким образом UIDs, которые мы имеем в mmp-файле, - UID2 и UID3. UID2 указывает отчасти выполнимый, который является всегда 0x100039CE для приложения (DLLs имеют различный UID). Третий UID идентифицирует уникально наш двоичный код. Вы должны будете просить назначенный UID от Symbian. Для развития мы можем использовать один из UID развития, которые находятся в диапазоне между 0xE1000000 и 0xEFFFFFFF. Мы будем ждать с распределением правильного UID, пока мы не установим наше приложение на устройстве. Распределение правильного UID, как собирать для телефона, и как создается инсталляционный пакет, обсудится в отдельном посте.

Остальная часть mmp-файла говорит сама за себя (по значению перевода). SOURCEPATH указывает папку, где источник расположен, SYSTEMINCLUDE указывает, где мы ищем систему, SOURCE указывает, какой мы использовали код при компиляции и LIBRARY, какую библиотеку мы используем. EUSER (подобный stdlib), будучи самым основным, всегда требуется.

2.5 Точка входа
Чтобы собрать кое-что, мы нуждаемся в некотором коде. Единственная вещь, в которой мы нуждаемся, - точка входа, которую в ОС Symbian называют E32Main. Таким образом, наш код похож на следующее:

// QHelloWorldApplication.cpp
#include <e32std.h>
TInt E32Main()
{
return KErrNone;
}

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

2.6 Первая компиляция.
Теперь мы готовы собрать наше "приложение" для начала. Компиляция делается в 2 шага. Первый шаг должен генерировать необходимые файлы типа "build". Мы должны делать редко, только когда необходимо изменить наш bld.inf файл. И поскольку это маленький проект создать один раз на весь проект достаточно. Этот первый шаг создаст abld.bat, небольшую пакетную команду, которую мы будем использовать в нашем втором шаге, когда мы собираем наше приложение. Чтобы выполнять те шаги, запустите окно командной строки, измените текущий каталог, на каталог, который содержит bld.inf файл (команда CD) и введите следующие команды:

cmd> bldmake bldfiles
cmd> abld build winscw udeb

Это - все, что Вы должны сделать. Инструмент Abld очень подобен инструменту создания, и позволяет нам делать много вещей. Но мы только интересуемся созданием нашего приложения, и поэтому мы вызываем "build ". Строение состоит из нескольких шагов, но инструмент делает их все. Следующий параметр мог бы выглядеть знакомым, так как мы обсуждали это уже прежде. Это указывает, для какой целевой платформы мы хотели бы строить. Здесь мы можем определить одного из адресатов, которых мы добавили в нашем bld.inf файле. И так как мы только определили winscw, он является те параметром, который мы должны использовать. Последний параметр определяет, хотели ли бы мы строить отладку или выпускаемую версию нашего двоичного кода. Обычно Мы хотим строить наш двоичный код как отладку (udeb) версии для эмулятора ОС Symbian, и выпуска (urel) для реального устройства.

Во время создания Вы могли бы видеть несколько строк "mwldsym2.exe: warning: ...", но все должно работать прекрасно и Вы можете безопасно игнорировать их.
Вернуться к началу ПрофильЛичное
DUG
Смартфоман
<b>Смартфоман</b>
Популярность: +39 (53)

Возраст: 81
С нами с: 23.04.2007
Сообщений: 1612

4/15 СообщениеДобавлено:Сб Авг 25, 2007 12:03   Заголовок сообщения:
Цитата

Часть 3 Прикладные Регистрационные Файлы (AIF)

3.1 Введение.


Прикладной регистрационный файл — это файл ресурса, который регистрирует приложение в системе. Только после того, как приложение зарегистрируется в системе – пользователь сможет его использовать. Регистрация заставляет также в списке "Инструменты" выводить новое приложение. Для полной регистрации требуется не только регистрационный файл, но и следующие файлы:
1. Один регистрационный файл (_reg);
2. По крайней мере один файл (_loc) локализации, один для каждого языка;
3. По крайней мере один мультифайл точечной графики (mbm) содержащий несколько точечных рисунков;



_ref-файл - корень, и все другие файлы прямо или косвенно достигнуты через тот корень. Позже мы рассмотрим, как точно создать эти отношения. Эти отношения между различными файлами иллюстрированы на рисунке



Могло бы казаться странным, что мы создаем сначала AI, прежде, чем мы запускаем любое реальное программирование/кодирование, но так как мы не можем запустить приложение без AIF, его мы делаем первым.

3.2 Структура папки



Файл bld.inf не нуждается ни в каких бы то нибыло изменениях, и поэтому не перечислен в диаграмме выше.

3.3 Регистрационный файл (_reg).
Регистрационный файл – файл ресурса (rss) файл, и похож на следующую структуру:

// QHelloWorld_reg.rss
#include <AppInfo.rh>
UID2 KUidAppRegistrationResourceFile
UID3 0xE1000001
RESOURCE APP_REGISTRATION_INFO
{
// filename of application binary (minus extension)
app_file = "QHelloWorld";
}


Файл AppInfo.rh содержит важные определения структуры для этого типа файла ресурса, и поэтому мы должны включить его. UID2 требует KUidAppRegistrationResourceFile, и UID3 должен соответствовать нашему приложению UID, тот, который мы получили от Symbian. APP_REGISTRATION_INFO - структура ресурса, которая определяет, как наше приложение выглядит и ведет себя, и описывает его обслуживание. Единственная интересная вещь для нас в настоящее время должна создать связь между регистрационным файлом и нашим выполнимым. Поэтому мы только определяем структуру app_file, и используем для всех других элементов значения по умолчанию, определенные в AppInfo.rh.

3.4 Компиляция _reg-файла.
Все файлы ресурса должны быть собраны в более компактный формат, и регистрационный файл не исключение. Следующие строки нужно добавить к mmp-файлу:


// QHelloWorld.mmp
SOURCEPATH ..\reg
START RESOURCE QHelloWorld_reg.rss
TARGETPATH \private\10003a3f\apps
END


SOURCEPATH указывает, где можно найти файл ресурса, а TARGETPATH указывает, где файл ресурса расположен. Для регистрации приложения это всегда должен быть каталог \private\10003a3f\apps.

Теперь всегда, когда мы изменяем что-либо в нашем приложении, мы должны собрать его, набрав:

cmd> abld build winscw udeb


3.5 Выполнение приложения.
Теперь, когда наше приложение зерегистрировано, мы можем впервые выполнить его. Так что запускаем эмулятор в Pen Style конфигурации UI, набрав:

cmd> epoc

Как только эмулятор запустится, мы должны увидеть страницу с запускаемыми приложениями, где мы должны найти наше приложение. Наше приложение получает автоматически значок значения по умолчанию и название двоичного кода как имя приложения. Когда мы выбираем приложение к сожалению, ничто не случается, так как наше приложение ничего не делает. Чтобы видеть реакцию, изменим наше приложение, чтобы оно что-то выполняло, изменяем E32Main () функцию:

// QHelloWorldApplication.cpp
TInt E32Main()
{
// define a non-modifiable compile time allocated
// descriptor (Symbian OS string)
_LIT(KQHelloWorldString, "Hello World");
// show an indication
User::InfoPrint(KQHelloWorldString);
return KErrNone;
}

Вызов User::InfoPrint() не должен использоваться, как только мы сделаем структуру приложения и выполнение. Взамен используем функцию CEikonEnv:: InfoMsg (), так как она намного эффективнее.


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



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

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

cmd> abld reallyclean winscw udeb
cmd> abld build winscw udeb


3.6 Локализуемая часть регистрационного файла (_loc)

Регистрационный файл содержит только нелокализуемую информацию. Локализуемая информация вынесена в отдельный файл, названный _loc-файлом. Этот файл может быть ограничен как любой другой файл ресурса в системе. То, как локализация случается, - однако не часть этого официального документа. _loc-файл определяет единственную структуру LOCALISABLE_APP_INFO, который снова определяется в файле AppInfo.rh. Он содержит заголовок и информацию значка. Нужно отметить, что короткий заголовок не используется в UIQ, но может быть он будет использоваться в будущем, и поэтому нужно заполнить его. Должно быть отмечено, что _loc файл содержит только информацию относительно того, где файл точечной графики расположен.

Таким образом, наш файл QHelloWorld_loc.rss похож на следующее:

// QHelloWorld_loc.rss
#include <AppInfo.rh>
RESOURCE LOCALISABLE_APP_INFO
{
short_caption = "Hello!";
caption_and_icon =
{
CAPTION_AND_ICON_INFO
{
caption = "Hello World!";
number_of_icons = 3;
icon_file = "\\Resource\\Apps\\default_app_icon.mbm";
}
};
}


При запуске мы все еще используем значки приложения по умолчанию, но на сей раз мы ссылаемся на них явно. Number_of_icons определяет, сколько значков в пределах файла значка должно использоваться как значки приложения. Обычно Вы должны иметь три значка, но файл значка может содержать больше или меньше значков.
Теперь мы только должны удостовериться, что мы сначала добавляем новый _loc-файл к нашему mmp-файлу, так, чтобы это было скомпилировано. Добавление к mmp-файлу подобно тому как от _reg-файла, но нужно указать правильно местоположение для этого файла - \resource\apps.

Для защиты данных, это должна быть другая папка от того, где расположен _reg-файл. _reg-файл должен быть расположен в пути, данном выше, тогда как _loc-файл может быть расположен в любой глобально читаемой папке (и поэтому не может быть расположен в частной папке). Однако строго рекомендуется, чтобы использовалась папка \resource\apps, так как это обеспечивает глобальный доступ для чтения, и защищает доступ для записи.

// QHelloWorld.mmp
SOURCEPATH ..\reg
START RESOURCE QHelloWorld_loc.rss
TARGETPATH \resource\apps
END

Строки в mmp-файле могут потенциально содержать языковую спецификацию. Компилирование файла ресурса для определенного языка определяют например LANG 10 для языка, номер 10. Каждому языку определили предопределенное число в e32const.h, и в этом случае мы соберем файл ресурса для американского английского языка. Язык SC всегда используется как последнее средство когда никакой другой язык (который лучше соответствует) не может быть найден. Второе, что мы должны сделать — это добавить информацию о новом _loc-файле к нашему _reg-файлу. Чтобы сделать это, мы только должны добавить одну строку к структуре APP_REGISTRATION_INFO в нашем _reg-файле, который указывает на наш недавно созданный _loc-файл:

// QHelloWorld_reg.rss
localisable_resource_file = "\\Resource\\Apps\\QHelloWorld_loc";

3.7 Создание некоторых заказных точечных рисунков.
Согласно Руководству Стиля UIQ приложение должно обеспечить 3 различных размера точечных рисунков:
• Маленькие значки: 18*18 пикселей;
• Большие значки: 40*40 пикселей;
• Очень большие значки: 64*64 пикселя.

Итак, для начала, мы нуждаемся в 3 точечных рисунках вышеупомянутых размеров. Но это не все, так как мы также нуждаемся в точечном рисунке маски для каждого из точечных рисунков, который определяет, какая часть значка является видимой (белый) и который является прозрачными (черными). Также возможно определить полупрозрачные части с серыми значениями. Тогда мы должны собрать те отдельные точечные рисунки в единственный mbm-файл. Наш mbm-файл будет содержать 6 индивидуальных точечных рисунков (3 пары точечного рисунка/маски). Чтобы сделать это, мы должны добавить следующее к нашему mmp-файлу:

// QHelloWorld.mmp
START BITMAP qhelloworld_default_icon.mbm
TARGETPATH \resource\apps
HEADER
SOURCEPATH ..\data\appicon
SOURCE c16 QHelloWorld_small.bmp
SOURCE 8 QHelloWorld_small_mask.bmp
SOURCE c16 QHelloWorld_large.bmp
SOURCE 8 QHelloWorld_large_mask.bmp
SOURCE c16 QHelloWorld_xLarge.bmp
SOURCE 8 QHelloWorld_xLarge_mask.bmp
END

Это создает единственный mbm-файл (qhelloworld_default_icon.mbm), содержа все точечные рисунки. Кроме того, будет создан файл заголовка (поэтому ключевое слово HEADER), который позволит нам включать любой из точечных рисунков в пределах mbm файла в нашем коде. Файл будет расположен в \epoc32\include папке и будет называться qhelloworld_default_icon.mbg. В вышеупомянутом случае, прикладная структура будет включать различные точечные рисунки, и файл заголовка незначителен, но поэтому важно удостовериться, что мы определяем наших пар точечного рисунка/маски вместе.

Маски должны всегда определяться как 1 (черно-белый) или 8 (разрядная шкала яркости), чтобы правильно работать. Маски объявлены как 8bit (оттенки серого), а значки как 16 битов (цвет). Это - все, что мы должны сделать, чтобы создать mbm-файл. Так теперь мы можем начать использовать это, ссылаясь на это в нашем _loc-файле. Таким образом, мы заменяем значки по умолчанию нашими собственными иконками. Число значков - то же самое, так как количество пар точечного рисунка/маски подсчитано. Таким образом, обновленная строка теперь выглядит так:

// QHelloWorld_loc.rss
icon_file = "\\resource\\apps\\qhelloworld_default_icon.mbm";

После нормальной перекомпиляции мы должны видеть наше приложение в списке приложений с нашими собственными иконками и с нашим собственным названием. Маленькая иконка используется в представлении списка, большая и очень большая иконка используются в представлении сетки (выделенный и не выделенный).



Пока мы видели, как правильно регистрировать наше приложение, но мы все еще не имеем хорошего графического приложения. В следующем посте рассмотрим создание более привлекательного приложения, и первый шаг должен сделать прикладную структуру.
Вернуться к началу ПрофильЛичное
DUG
Смартфоман
<b>Смартфоман</b>
Популярность: +39 (53)

Возраст: 81
С нами с: 23.04.2007
Сообщений: 1612

5/15 СообщениеДобавлено:Сб Авг 25, 2007 15:37   Заголовок сообщения:
Цитата

Часть 4 Прикладная структура

4.1. Введение

Написать графическое приложение полностью на пустом месте было бы очень трудно. О всей этой работе заботится прикладная структура, которая будет:
• создавать подключение к файловому серверу;
• создавать подключение к серверу окна;
• создавать подключение к менеджеру памяти;
• делать некоторую регистрационную работу;
• удостоверяться, что мы можем обработать ошибку и ситуацию OOM («Out-of-Memory»);
• инициализирует другое прикладное обслуживание (провайдеры Шрифта, процессоры рабочей станции...);
• создают картинку экрана значения по умолчанию;
• ...
• наконец запускают Активного Планировщика (цикл случая).

Поэтому важно, что мы сначала запускаем прикладную структуру. Так как приложение сильно связано с FW (Framework), мы должны сделать некоторую работу. В следующем мы будем видеть то, что это действительно означает для нашего приложения, и что мы будем должны сделать.

4.2. Структура папки



4.3 Краткий обзор дизайна

Не то, чтобы интересно знать, как приложение FW действительно выглядит, но важно понять, какую основную структуру FW ожидает от вашего приложения. Большинство приложений состоит из по крайней мере следующих 4 основных базовых классов:
• Application (CQikApplication);
• Document (CQikDocument);
• AppUi (CQikAppUi);
• View (CQikViewBase).

" Application " - основание для приложения, работающего в пределах Прикладного FW. Основная ответственность этого класса состоит в том, чтобы создать " Document ". " Document " ответственен за данные прикладной программы. Он также создает подключения к механизмам, файлам, базам данных, и т.п.. И также ответственен за создание документа "AppUi". "AppUi" - самостоятельно неграфический класс, но это - класс, имеет большинство графических компонентов. Он включает изображение экрана, как Область Функциональной клавиши, Область заголовка приложения, и т.п.. Этот класс поэтому также ответственен, чтобы создать различные обозрения. В нашем примере мы будем только иметь единственное представление. View - первый реальный графический элемент в пределах нашего приложения. Это то, что будет действительно видеть пользователь приложения. Все остальное работает на заднем плане.

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



Прикладная структура создаст приложение после красных стрелок слева направо. Решение о том, когда все создано, обработано нижними уровнями (прикладная структура), но решение относительно того, обработано самым высоким уровнем (наше приложение).

4.4 Старт прикладной структуры.

Первый шаг должен начаться из прикладной структуры. Это просто сделать, вызвав Eik-
Start::RunApplication(), определенного в eikstart.h. Таким образом, мы изменяем нашу точку входа, чтобы получилось следующее:
// QHelloWorldApplication.cpp
#include <eikstart.h>
TInt E32Main()
{
return EikStart::RunApplication(
CQHelloWorldApplication::NewApplication);
}

Функция ожидает указатель функции к функции неоставления, которая возвращает указатель на наше приложение, то есть указатель на фабричную функцию. Мы соединяем фабричную функцию с нашим CQHelloWorldApplication-классом.

4.4.1 Класс CQHelloWorldApplication

Наш класс CQHelloWorldApplication очень прост. Мы должны унаследовать CQikApplication, и только должны осуществить фабричную функцию, которую мы упоминали выше, и эти две функции AppDllUid и CreateDocumentL. Таким образом, QHelloWorldApplication.h будет похож на следующее:

// QHelloWorldApplication.h
#include <QikApplication.h>
class CQHelloWorldApplication : public CQikApplication
{
public:
static CApaApplication* NewApplication();
private:
TUid AppDllUid() const;
CApaDocument* CreateDocumentL();
};

Теперь рассмотрим выполнение различных функций. Важно отметить, что фабричная функция - функция неоставления. Таким образом, мы должны создать объект CQHelloWorldApplication или возвратить ПУСТОЙ УКАЗАТЕЛЬ на отказе. Поэтому мы не можем использовать новый оператор (ELEAVE).

// QHelloWorldApplication.cpp
#include "QHelloWorldApplication.h"
CApaApplication* CQHelloWorldApplication::NewApplication()
{
return new CQHelloWorldApplication();
}

Другие две функции одинаково просты. Функция AppDllUid должна возвратить приложения UID. Так как приложение UID важно при других обстоятельствах, мы создадим отдельный файл заголовка с этой информацией, и назовем это QHelloWorldExternalInterface.h:
// QHelloWorldExternalInterface.h
const TUid KUidQHelloWorldApp = {0xE1000001};

Функция CreateDocumentL - только фабричная функция, чтобы создать конкретный случай нашего Документа, который мы определим через секунду:

// QHelloWorldApplication.cpp
#include "QHelloWorldExternalInterface.h"
#include "QHelloWorldDocument.h"
TUid CQHelloWorldApplication::AppDllUid() const
{
return KUidQHelloWorldApp;
}
CApaDocument* CQHelloWorldApplication::CreateDocumentL()
{
return CQHelloWorldDocument::NewL(*this);
}


4.4.2 Класс CQHelloWorldDocument

Класс CQHelloWorldDocument очень прост. Большинство функциональных возможностей уже обеспечивается базовыми классами, или неинтересно для нашего минимального приложения. Единственная вещь, которую мы действительно должны сделать, должна осуществить CreateAppUiL () функция. Так как этот класс будет держать подключение к нашим данным прикладной программы, на наши механизмы, и наши серверы, мы готовим это уже теперь, чтобы иметь все соответствующие конструкторы, и деструктор. Поэтому наш класс похож на следующее:

// QHelloWorldDocument.h
#include <QikDocument.h>
class CQikApplication;
class CQikAppUi;
class CQHelloWorldDocument : public CQikDocument
{
public:
static CQHelloWorldDocument* NewL(CQikApplication& aApp);
~CQHelloWorldDocument();
private:
CEikAppUi* CreateAppUiL();
private:
CQHelloWorldDocument(CQikApplication& aApp);
void ConstructL();
};

Единственная действительно интересная функция - CreateAppUiL (), который снова является только фабричной функцией:

// QHelloWorldDocument.cpp
#include <QikApplication.h>
#include "QHelloWorldDocument.h"
#include "QHelloWorldAppUi.h"
CEikAppUi* CQHelloWorldDocument::CreateAppUiL()
{
return new (ELeave) CQHelloWorldAppUi();
}
CQHelloWorldDocument* CQHelloWorldDocument::NewL(CQikApplication& aApp)
{
CQHelloWorldDocument* self = new(ELeave) CQHelloWorldDocument(aApp);
CleanupStack::PushL(self);
self->ConstructL();
CleanupStack::Pop(self);
return self;
}
CQHelloWorldDocument::~CQHelloWorldDocument()
{
}
CQHelloWorldDocument::CQHelloWorldDocument(CQikApplication& aApp)
: CQikDocument(aApp)
{
}
void CQHelloWorldDocument::ConstructL()
{
}

4.4.3 Класс CQHelloWorldAppUi

Мы теперь достигли конечного шага в поднимании Прикладной структуры. AppUi - последний шаг, который действительно требуется. И AppUi мог иметь пустое выполнение, но мы знаем, что мы хотим сделать еще некоторые вещи здесь, таким образом мы делаем это уже со стандартными конструкторами.

// QHelloWorldAppUi.h
#include <QikAppUi.h>
class CQHelloWorldAppUi : public CQikAppUi
{
public:
CQHelloWorldAppUi();
void ConstructL();
~CQHelloWorldAppUi();
};

Каждая из этих функций пуста за исключением ConstructL, который вызывает основную версию функции CQikAppUi:: ConstructL (). Эта основная конструкция должна всегда делаться как первый шаг, независимый от того, что Вы хотите сделать дальше.

// QHelloWorldAppUi.cpp
#include "QHelloWorldAppUi.h"
CQHelloWorldAppUi::CQHelloWorldAppUi() : CQikAppUi()
{
}
CQHelloWorldAppUi::~CQHelloWorldAppUi()
{
}
void CQHelloWorldAppUi::ConstructL()
{
CQikAppUi::ConstructL();
}

4.5 Создание файла ресурса приложения

Закодировав грамотно, мы имеем все, чтобы сделать прикладную структуру, но мы все еще пропускаем одну вещь: Прикладной файл ресурса. Каждое приложение имеет файл ресурса (с тем же самым названием как приложение непосредственно), который также используется прикладной структурой. В нашем случае этот файл ресурса (QHelloWorld.rss) очень прост, так как мы не определяем ничего в нем. Нам только потребуются те элементы прикладной структурой, но позже, мы будем лучше использовать этот файл:

// QHelloWorld.rss
#include <uikon.rh>
NAME HELW
RESOURCE RSS_SIGNATURE { }
RESOURCE TBUF { buf = ""; }
RESOURCE EIK_APP_INFO { }

Все вышеупомянутые структуры должны присутствовать, и должны появиться в заказе, данном выше. NAME назначает название к файлу ресурса, так, чтобы мы могли дифференцировать несколько файлов ресурса, которые мы загрузили в приложение друг от друга. Достаточно любых четырех символа для названия, но часто Вы пробуете использовать ярлык имени приложения. единственное нужно удостовериться, что название является уникальным. RSS_SIGNATURE, TBUF, и EIK_APP_INFO можно оставить пустыми пока, как показано выше.

4.6 Построение нового приложения

Теперь мы имеем все файлы и можем запускать прикладную структуру. Единственное, что мы должны обновить наш mmp-файл Сначала мы строим наш прикладной файл ресурса как делали это прежде; таким образом, мы добавляем следующее к mmp-файлу:

// QHelloWorld.mmp
SOURCEPATH ..\rsc
START RESOURCE QHelloWorld.rss
HEADER
TARGETPATH \resource\apps
END

Компилируя исходные файлы, мы добавляем их к части mmp-файла, который определяет компиляцию нашего приложения. Мы также должны добавлять USERINCLUDE так, чтобы мы нашли наши местные файлы заголовка, и мы нужно добавить некоторые дополнительные библиотеки:

// QHelloWorld.mmp
USERINCLUDE ..\inc
SOURCE QHelloWorldApplication.cpp
SOURCE QHelloWorldDocument.cpp
SOURCE QHelloWorldAppUi.cpp
LIBRARY EUSER.LIB
LIBRARY APPARC.LIB
LIBRARY CONE.LIB
LIBRARY EIKCORE.LIB
LIBRARY QIKCORE.LIB
LIBRARY QIKALLOCDLL.LIB
STATICLIBRARY QIKALLOC.LIB

Последние 2 библиотеки (QikAllocDll и QikAlloc), фактически не необходимы, но это - хорошая практика, чтобы добавить их к любому приложению (EXE), так как они удостоверятся, что ваше приложение обработает ситуации OOM лучшим способом, так как они следят, что ситуации OOM случатся редко. Только удостоверьтесь, что определили их точно тем же самым способом как упомянуто выше.

Как только мы повторно скомпилировали все, мы можем запустить наше приложение. Мы видим, что мы сделали прикладную структуру, так как мы видим Область заголовка и пустую Кнопочную панель. На следующем шаге нужно создать представление и заполнять пустоту. Чтобы избавляться от приложения закройте его, Вы можете или сам эмулятор или использовать волшебную ключевую комбинацию: Shift-Ctrl-Alt-K, которые на отладке уничтожат приложение. Если Вы перемещаетесь далеко, нажимая на клавише Application Launcher или кнопка Application Launcher (на Строке состояния) Вы только поместите приложение в фон, но приложение все еще будет и выполняться.

4.7 Создание представления

Самый легкий способ создавать ваше собственное представление состоит в том, чтобы унаследовать CQikViewBase. Таким образом, мы сделаем это. Осуществляя представление, которое наследует CQikViewBase, мы должны осуществить несколько функций. Первую — должны осуществить конструкторы и деструктор. Представление создано в стадиях пары. Это позволит осуществить быстрый запуск приложения. Полная конструкция представления получится, когда представление будет необходимо. Первую стадию нужно сделать как можно меньше. Единственная вещь, которую можно сделать с представлением в этом пункте, зарегистрировать представление с сервером представления. Мы заключим в капсулу эту часть конструкции в единственной фабричной функциии, NewLC. Регистрация с сервером представления позволит нам перемещаться от других приложений до нашего. Подробная информация на том, как это будет сделано, будет рассказана позже Следующая стадия, ViewConstructL, полностью создаст представление. Все элементы в пределах нашего взгляда должны теперь быть доступными. Последняя стадия - инициализация нашего представления, которое показано на рисунке.



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

// QHelloWorldView.h
#include <QikViewBase.h>
class CQHelloWorldView : public CQikViewBase
{
public:
static CQHelloWorldView* NewLC(CQikAppUi& aAppUi);
~CQHelloWorldView();
TVwsViewId ViewId()const;
protected:
void ViewConstructL();
void ViewActivatedL(const TVwsViewId &aPrevViewId,
TUid aCustomMessageId,
const TDesC8 &aCustomMessage);
private:
CQHelloWorldView(CQikAppUi& aAppUi);
void ConstructL();
};

Выполнение вышеупомянутых функций весьма просто. Функция NewLC следует за стандартной конструкцией с 2 фазами. Конструктор вызывает конструктор CQIKVIEWBASE, с соответствующими параметрами. Второй параметр важен для навигационной модели. KNullViewId. ConstructL должен вызвать BaseConstructL (), но этот параметр мы оставляем пустым. Обычно мы добавили бы некоторый код в ViewConstructL, к размещению нашего управления. В этом примере, однако мы не будем делать это, таким образом мы должны сделать следующие запросы в ViewConstructL ():

CQikCommandManager& cmdManager = CQikCommandManager::Static(*iEikonEnv);
cmdManager.CreateCommandListL(*this);

UIQ 3.0 ввёл довольно много Статических () функции. Большинство появляются в 2 различных версиях, один с параметром CEikonEnv и один без него. Строго рекомендуется, чтобы Вы использовали версию с параметром, так как это намного более эффективно. Каждое управление держит указатель на CEikonEnv/CCoeEnv, вызываемый iEikonEnv/iCoeEnv

Если вышеупомянутая функция не доступна в вашем SDK, тогда Вы работаете со старшей версией. В этом случае можно:
1. обновиться до новой версии;
2. понизить параметр.


Единственная другая функция, которую мы должны осуществить, - ViewId (). Как уже заявлено мы должны возвратить идентификатор представления. Этот идентификатор состоит из двух частей, приложения UID и представления UID. UID представления должен быть уникальным в пределах приложения. UID представления должен быть между значением 0x00000001 и 0x0FFFFFFF, или зарегистрированный UID (таким же образом как приложение UID). В нашем случае мы будем использовать 0x00000001, и добавим UID к нашему файлу QHelloWorldExternalInterface.h.

// QHelloWorldExternalInterface.h
const TUid KUidQHelloWorldView = {0x00000001};


// QHelloWorldView.cpp
#include <QikAppUi.h>
#include <QikCommand.h>
#include "QHelloWorldView.h"
#include "QHelloWorldExternalInterface.h"
CQHelloWorldView* CQHelloWorldView::NewLC(CQikAppUi& aAppUi)
{
CQHelloWorldView* self = new(ELeave) CQHelloWorldView(aAppUi);
CleanupStack::PushL(self);
self->ConstructL();
return self;
}
CQHelloWorldView::CQHelloWorldView(CQikAppUi& aAppUi)
: CQikViewBase(aAppUi, KNullViewId)
{
}
void CQHelloWorldView::ConstructL()
{
CQikViewBase::BaseConstructL();
}
CQHelloWorldView::~CQHelloWorldView()
{
}
void CQHelloWorldView::ViewConstructL()
{
CQikCommandManager& cmdManager = CQikCommandManager::Static(*iEikonEnv);
cmdManager.CreateCommandListL(*this);
}
void CQHelloWorldView::ViewActivatedL(const TVwsViewId &aPrevViewId,
TUid aCustomMessageId,
const TDesC8 &aCustomMessage)
{
}
TVwsViewId CQHelloWorldView::ViewId() const
{
return TVwsViewId(KUidQHelloWorldApp, KUidQHelloWorldView);
}

Теперь мы получили наше представление, но мы должны обновить наш класс CQHelloWorldAppUi, чтобы создать такое представление. Монопольное использование нашего представления постоянно находится с CQikAppUi, который следит, чтобы представление правильно регистрировалось с сервером представления. Таким образом, мы обновляем ConstructL,:

// QHelloWorldAppUi.cpp
#include "QHelloWorldView.h"
void CQHelloWorldAppUi::ConstructL()
{
CQikAppUi::ConstructL();
CQHelloWorldView* view = CQHelloWorldView::NewLC(*this);
AddViewL(*view);
CleanupStack::Pop();
}

Также нужно обновить наш mmp-файл, добавляя:

// QHelloWorld.mmp
SOURCE QHelloWorldView.cpp
LIBRARY eikcoctl.lib

повторно собирать и запускать наше приложение. Как только мы запустили наше приложение, мы должны отметить следующие вещи:
1. Наша «пустота» была заполнена изображением фона значенем по умолчанию. И автоматически обновлено в зависимости от используемой Темы.
2. Мы имеем кнопку возврата на нашей Кнопочной панели.
3. Нажатие на кнопку возврата вернуло нас к инструментам, но это не закрывает наше приложение. Мы не должны волноваться об этом, так как система заботится об этом, когда необходимо.
Вернуться к началу ПрофильЛичное
Перейти:  
Новая тема Написать ответ Форумы Все для телефонов Sony Ericsson » Мобильное программирование Часовой пояс: GMT + 4
Рейтинг@Mail.ru