| « Поставить закладку » « Сделать стартовой » | |||
|
|||
|
Использование J2ME. Часть 1
J2MEНесмотря на название схожее с J2EE или J2SE вряд ли Вы где-нибудь найдете JDK для J2ME [1] или что-либо подобное. Дело в том, что J2ME объединяет под своим названием множество технологий, каждая из которых решает свою конкретную задачу. А именно, спецификация J2ME определяет так называемые конфигурации (configuration). Каждая конфигурация описывает среду выполнения J2ME приложения (JVM, набор доступных классов, некоторые правила функционирования приложений). Для конфигурации в свою очередь может быть определено несколько профилей (profile), каждый из которых ‘уточняет’ среду выполнения, добавляя или запрещая использование каких-либо классов, определяя новые правила функционирования приложения. Очень точно эту концепцию отражает рис. 1.
В данной далее статье речь пойдет о конфигурации CLDC [2] (Connected, Limited Device Configuration) и одном из ее профилей - MIDP [3] (Mobile Information Device Profile). CLDCПолное подробное описание данной конфигурации можно найти в [2]. Я же здесь хочу отметить только некоторые основные моменты, которые отличают среду выполнения CLDC J2ME от, например, среды выполнения J2SE:
Нужно сказать, что спецификация CLDC сама по себе не определяет законченную среду выполнения, поэтому в реализацию CLDC от Sun был включен дополнительный пакет com.sun.kjava, классы которого реализуют тестовый пользовательский интерфейс и некоторые протоколы для Generic Connection Framework. MIDPДанный профиль построен на базе конфигурации CLDC и полностью определяет среду выполнения (но не всю инфраструктуру) приложения. Данный профиль нацелен на создание приложений для таких мобильных устройств как сотовые телефоны, пейджеры, PDAs, Smart Phones. Место, которое занимает профиль MIDP в технологии J2ME показывает рис. 2.
Не мудрствуя лукаво, приведем цитату из спецификации [3]: “MIDP определяет модель приложения, которая позволяет разделять нескольким приложениям ограниченные ресурсы мобильного устройства, эта модель называется MIDlet. Она определяет, что такое MIDlet приложение, как оно должно быть упаковано, какая среда выполнения доступна для MIDlet’a и как должно себя вести приложение, чтобы мобильное устройство могло им управлять…”. Чтобы не приводить больше теоретических сведений о MIDP профиле перейдем к практическому написанию приложения для него. Подготовка к разработкеДля начала разработки MIDP приложений или MIDlet’ов, Вам понадобиться установить некоторое программное обеспечение. Несколько вариантов возможных конфигураций приведено ниже:
Существует еще огромное количество вариантов (см. [7]), но мы в данной статье будем ориентироваться на 3-ий, как самый честный в смысле соответствия спецификации. Mobile MessengerДля того, чтобы как можно более широко охватить круг возможностей, которые предоставляет MIDP для создания приложений, автор решил разработать систему мгновенного обмена сообщениями (жалкий аналог ICQ:) между клиентами, использующими мобильные устройства. Примерная блок-схема будущей системы представлена на рис. 3.
Предполагается следующий механизм взаимодействия: все сообщения передаваемые клиентом сначала попадают на сервер, который либо пересылает сообщения адресату (другому мобильному клиенту), либо выполняет какие-либо другие действия (например отвечает клиенту, что адресат недоступен). Самый главный вопрос, который встает при проектировании данной системы – как MIDP приложениям общаться с сервером? Вот тут мы и вспоминаем о ранее упомянутой Generic Connection Framework. Основная идея Generic Connection Framework – определить единый высокоуровневый интерфейс к протоколам передачи данных любого вида. Причем CLDC определяя Generic Connection Framework, не реализует ни одного протокола, полагаясь на их реализацию в каждом конкретном профиле (точнее программист полагается на реализацию протоколов в профиле :). Спецификация MIDP в свою очередь требует обязательной реализации только протокола HTTP. Да, казалось бы без серверных сокетов замахиваться на реализацию ICQ было бы просто глупо, но как оказалось все, опробованные мной реализации MIDP (Sun, Nokia, Motorola) включают реализацию протокола серверных сокетов (Sun, Motorola - datagram, Nokia – socket), что позволяет надеется на поддержку аналогичных протоколов в реальных мобильных устройствах. Решено, для обмена сообщениями между клиентом и сервером будем использовать протокол datagram (UDP). И так, в нашей системе явно вырисовываются три основные части:
Раз уж разговор зашел о Generic Connection Framework, то именно с коммуникационной части и начнем проектирование системы. Ресурсы
Замечание для российских граждан Рубрика: Java2ME
Вышел MySQL 5.1.30, первый стабильный рели....
После публикации 29 тестовых версий анонсирован первый стабильный релиз MySQL 5.1, пригодный для промышленной эксплуатации и обеспечивающий увеличение производительности для "тяжелых" SQL запросов, по сравнению с MySQL 5.0, примерно на 15-20%. Главные новшества появившиеся в MySQL 5.1:
Подробнее... |
Рубрика: MySQL
| Добавлено: 28.11.2008
Тестирование параллельных программ.
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
Подробнее... |
Рубрика: Тестирование
| Добавлено: 28.11.2008
Архитектура AMD64 (EM64T).
Аннотация. В статье кратко рассматривается архитектура AMD64 компании AMD и ее реализация EM64T компании Intel. Описаны особенности архитектуры, ее возможности, достоинства и недостатки.
Подробнее... |
Рубрика: Архитектура AMD
| Добавлено: 27.11.2008
Остальные статьи: |
Цитата дня (все,добавить):
|
Realcoding.NET
© 2003-2008 |
Контакты |
Реклама на сайте
|