Загрузка...
Учебная работа. Дипломная работа: Использование платформы j2me для мобильных телефонов при организации видеонаблюдений
«Гомельский муниципальный институт имени Франциска Скорины»
Математический
факультет
Кафедра вычислительной арифметики и программирования
Дипломная работа
«Внедрение платформы
j
2
me
для мобильников при организации видеонаблюдения»
Гомель 2009
Реферат
Главные слова:
видеонаблюдение, обнаружение движения, мидлет, платформа J2ME, Блютуз, SMS-сообщение, MMS-сообщение, файловая система мобильного телефона, камера, библиотека LWUIT, FileConnectionAPIJSR-75, MobileMediaAPIJSR-135, BluetoothAPIJSR-82, WirelessMessagingAPIJSR-205.
объект исследования:
программирование мобильного телефона.
Способы исследования:
платформа J2ME.
Цель дипломной работы:
исследование принципов и способностей использования ресурсов мобильного телефона при разработке приложений на платформе J2ME.
Выводы:
исследованы способности работы со последующими ресурсами телефона: файловая система, камера, Блютуз, отправка SMS и MMS-сообщений. Создано приложение для мобильного телефона на платформе J2ME, которое дозволяет производить видеонаблюдение.
Содержание
Введение
1. Обзор литературы
2. Платформа J2ME
2.1 Главные понятия
2.2 библиотека LWUIT
2.3 Блютуз
3. Проектирование приложения для мобильного телефона на базе платформы J2ME
3.1 Постановка задачки
3.2 Построение интерфейса
3.3 Передача данных по Блютуз
3.4 Работа с файловой системой телефона
3.5 Отправка SMS и MMS-сообщений
3.6 метод обнаружения движения
Заключение
Перечень источников
Введение
Видеонаблюдение – процесс, осуществляемый с применением технических решений, созданных для зрительного контроля за охраняемыми либо наблюдаемыми территориями, объектами, субъектами. Основная задачка видеонаблюдения – обеспечение сохранности объекта методом зрительного наблюдения без передачи инфы во наружные общедоступные сети.
Видеонаблюдение сделалось полностью обыденным явлением современной ежедневной жизни. Развлекательные и торговые объекты, автостоянки и гаражные комплексы, кабинеты, транспорт, публичные места, промышленные объекты, также объекты банковского сектора снабжаются камерами. Видеоконтроль обеспечивает предупреждение злодеяний и их наиболее резвое раскрытие, делает контроль действий персонала.
Зависимо от типа применяемого оборудования системы видеонаблюдения делятся на цифровые и аналоговые (классические). В любом случае оборудование состоит из видеокамер, устройств обработки, записывающего оборудования и устройств вывода изображения (монитор). Также в систему нередко врубаются доп устройства типа кожухов, устройств управления, передачи на далекие расстояния и т.п.
Цифровая система видеонаблюдения обеспечивает:
— высочайшее свойство воспроизводимой видеозаписи;
— высшую скорость доступа к видеоархиву;
— цифровое повышение и масштабирование хоть какого кадра;
— резвый поиск и просмотр видеозаписи по камере, дате и времени;
— возможность интеграции с иными компьютерными системами сохранности;
— легкая и дешевая трансляция видеоархивов по каналам связи;
— возможность отправки тревожных сообщений по электрической почте и SMS;
— возможность экспорта видеоинформации на совместимые наружные носители.
Аналоговая система видеонаблюдения ординарна в настройке и работе и дозволяет нанимать для обслуживания персонал наименьшей квалификации. Минусы аналоговых систем видеонаблюдения последующие:
— ограниченность функций – оборотная сторона высочайшей надежности;
— неизменное сервис – смена и архивация кассет, повторяющаяся очистка и подмена видеоголовок видеомагнитофона.
Аналоговые системы употребляют там, где нужно организовать видеонаблюдение в маленьком числе помещений и информацию с видеокамер записывать на видеомагнитофон.
Беря во внимание обширное распространение сотовой связи, мобильники сейчас употребляются в почти всех современных системах видеонаблюдения и разрешают просматривать данные от камер, также получать SMS с извещением о обнаруженном движении.
к примеру, программка GOALmobile– это видеотелефон, осуществляющий одновременную трансляцию с 1-го телефона на иной. При всем этом необходимо лишь, чтоб мобильник поддерживал функцию GPRS. количество сразу транслируемых камер не ограничено. Переключение меж ними делается на телефонной трубке. В составе системы сохранности данная разработка дозволяет получать тревожные сообщения с выводом на экран видеоизображения происходящего действия либо его записи, также управлять исполнительными механизмами, присоединенными к системе охраны. к примеру, при нажатии на клавишу звонка перед дверью квартиры на телефон поступит сигнал, и на мониторе будет выведена жива трансляция камеры-глазка. При всем этом есть возможность надавить клавишу 1 для открытия замка, клавишу 2 для включения сирены, клавишу 3 для выдачи голосового сообщения и т.д.
Не считая того, разработаны приложения для мобильников, которые употребляют камеру телефона для обнаружения движения. К примеру, Цюрихский Институт всепроникающей компьютеризации сделал программку, позволяющую применять интегрированные камеры телефонов, находящихся в общей сети, в качестве системы видеонаблюдения.
Программка с заглавием Facet дозволяет мобильникам обмениваться данными при помощи Блютуз, а благодаря особым методам телефоны могут рассматривать действия, попадающие в объектив камеры. Смысл деяния программки такой, что если закрепить пару телефонов, к примеру, Nokia N6630, на потолке и включить программку Facet, то как в поле обзора одной из камер будет попадать передвигающийся объект, телефон сходу же будет отсылать сигнал находящемуся телефону, также отсылать данные на комп через GPRS. Схожая система может употребляться в качестве охранной в тех вариантах, когда всеполноценную систему наблюдения развернуть не представляется вероятным.
Но данные приложения дорогие и сделаны в главном лишь для телефонов и коммуникаторов. Потому животрепещущей задачей является создание аналогичного приложения на платформе J2ME, которая поддерживается большинством телефонов.
1
. Обзор литературы
В истинное время сотовая связь – самая обширно применяемая из всех видов мобильной связи. Более всераспространенными видами телефонов являются обыденный телефон, телефон, коммуникатор и КПК.
Телефоны и коммуникаторы различаются от обыденных мобильников наличием довольно развитой операционной системы, открытой для сотворения программного обеспечения посторонними разрабами. установка доп приложений дозволяет существенно сделать лучше функциональность телефонов и коммуникаторов по сопоставлению с обыкновенными мобильными телефонами.
В истинное время не существует точного разграничения меж телефонами и коммуникаторами, так как функциональность обоих классов устройств приблизительно схожа. Нередко применяется так именуемый «исторический подход», который заключается в последующем: если устройство ведет свою родословную от КПК – это коммуникатор, а если от мобильников – это телефон. В рамках этого подхода под коммуникаторами обычно предполагаются устройства с сенсорным экраном (быть может дополнен клавиатурой), работающие под управлением операционной системы Windows Mobile. Устройства, использующие для ввода инфы только цифровую клавиатуру (аналог телефонной), именуются телефонами. Большая часть устройств под управлением операционной системы Симбиан обычно относят к телефонам (кроме Nokia серии 9XXX, Nokia E90 и неких остальных). В других вариантах размещение устройства зависит от производителя (обычно устройства с сенсорным экранам относят к коммуникаторам, а к телефонам относят устройства без него), хотя большая часть телефонов работает на 2-ух конкурирующих меж собой операционных системах: Симбиан и Windows Mobile Smartphone Edition. В мире Симбиан более известными платформами являются Nokia Series 60, 80, 90 и Sony Ericsson UIQ. В лагере Windows более популярна платформа HTC.
Также часть профессионалов делит коммуникаторы и телефоны по наличию либо отсутствию полноразмерной (QWERTY) клавиатуры (виртуальной либо физической).
Современные телефоны (модели средней ценовой группы и выше) отлично управляются со почти всеми задачками, выходящими за рамки телефонных: работа с электрической почтой, просмотр текстовых документов и электрических таблиц, работа с планировщиком задач и иными. расширение функциональности телефонов может быть за счет J2ME-программ, которые поддерживаются фактически всеми мобильными телефонами, телефонами и коммуникаторами. Экран целого ряда мобильников не уступает большинству телефонов (в крайнее время телефоны оснащаются и сенсорными экранами), почти все модели обустроены разъемом для карты памяти. Телефоны в очах данной группы юзеров смотрятся наиболее симпатичными за счет остальных причин (отчасти обусловленных продвижением телефонов и коммуникаторов производителями), таковых как: расширенные мультимедийные функции (наиболее высококачественная камера, расширенные способности проигрывания видеофайлов, усовершенствованные музыкальные возможности), Wi-Fi, GPS и др.
Программки, написанные специально для операционной системы телефона либо коммуникатора, являются всеполноценными скомпилированными в двоичный код последовательностями низкоуровневых микропроцессорных установок. Потому что во всех телефонах установлены наиболее массивные микропроцессоры, чем в мобильных телефонах, способности программера по созданию таковых приложений фактически не ограничены. Спец приложения наиболее функциональны и рациональней употребляют ресурсы микропроцессора, чем «всепригодные» J2ME-программы. Потому телефоны пользуются большей популярностью посреди разрабов программного обеспечения.
Для операционной системы Симбиан приложения разрабатываются на языке С++ с внедрением последующих сред разработок: Visual Studio, IDE Metrowerks CodeWarrior Development Studio, Borland C++ BuilderX Mobile Edition, Carbide.C++.
В истинное время получили огромное распространение коммуникаторы и телефоны, которые совмещают внутри себя функции КПК с функциями мобильного телефона. КПК владеют недочетов по сопоставлению с коммуникаторами, главный из которых – наименьшее время автономной работы. К началу 2008 года КПК были фактически вытеснены телефонами и коммуникаторами, объемы поставок КПК повсевременно понижаются.
Android– не так давно показавшаяся платформа, основанная на Linux, разрабатываемая OHA. С внедрением Android SDK и плагина для Eclipse ADT для платформы Androidможно создавать приложения на языке программирования Java, управляющие устройством через разработанные компанией Гугл библиотеки. Также есть возможность писать приложения на C и остальных языках программирования. Под управлением Android работают телефоны HTC G1, Самсунг i7500 и др.
Выбор платформы J2ME для разработки обоснован ее распространенностью и возможностью доступа к нужным ресурсам телефона.
2. Платформа J2ME
2.1 Главные понятия
Платформа J2ME была разработана компанией Sun Microsystems с целью предоставления способности сотворения Java-приложений для устройств с ограниченными ресурсами памяти и микропроцессора, таковых как мобильники, пейджеры, смарт-карты, органайзеры и миникомпьютеры.
Платформа J2ME является неопасной для использования, поэтому что при доступе в веб, использовании остальных коммуникаций, отправке SMS, доступе к файловой системе юзер непременно будет о этом уведомлен и для продолжения использования функции нужно его доказательство. При корректной реализации спецификаций единственным вариантом несанкционированного доступа является программка троян, которая под видом необходимости выполнения полезной юзеру функции по сути будет применять приобретенные права в собственных целях.
Архитектура платформы J2ME представлена на рисунке 2.1.
Набросок 2.1 – Архитектура платформы J2ME
Устройства, на которых сумеет работать J2ME-приложение (мидлет), определяются поддерживаемой конфигурацией и профилем платформы [2]. Конфигурация описывает самые базисные классы, такие как класс System, Runtime, Thread и т.д., другими словами является фундаментом платформы. Над каждой конфигурацией надстраиваются свои профили. Профиль описывает требования к аппаратной части устройства, также может включать малый набор API.
Выделяют 2 конфигурации: CLDC и CDC. CDC создана для устройств, имеющих неизменное сетевое соединение, таковых как двунаправленные пейджеры, телевизионные приставки, авто системы навигации, умственные коммуникаторы. Такие устройства характеризуются наиболее массивными системными ресурсами, к примеру, как минимум 2 мб памяти.
Над конфигурацией CDCмогут быть надстроены профили FoundationProfile, PersonalBasisProfileи PersonalProfile.
Foundation Profile не имеет функциональности для работы с GUI. Предназначен для встраиваемых устройств.
Personal Basis Profile содержит главные элементы GUI. Является надстройкой над Foundation Profile.
Personal Profile содержит графический интерфейс юзера, основанный на AWT. Является надстройкой над Personal Basis Profile.
Конфигурация CLDC создана для устройств с ограниченным объемом памяти и вычислительной мощностью (телефоны, органайзеры, КПК). Для этих мобильных устройств свойственны последующие характеристики:
— информации в процессе решения вычислительных и информационных задач) (либо вычислительной системы) которое делает арифметические и логические операции данные программкой преобразования инфы управляет вычислительным действием и коор 16 либо 32-разрядный;
— память от 160 до 512 кб;
— беспроводное сетевое соединение;
— питание от аккумов.
Данная конфигурация содержит лишь базисные пакеты Java.lang.*, java.io.*, java.util.*, javax.microedition.io.* и добавленный в версии 1.1 пакет Java.lang.ref.*. Пакеты, совпадающие с J2SE, содержат малый набор классов, нужных для сотворения приложений.
По реализации пересекающихся с J2SE классов версии б-кода CLDC 1.0 соответствует JDK 1.1, CLDC 1.1 – JDK 1.3. время от времени к наименованию конфигурации добавляют HI, что значит HotSpot Implementation (виртуальная машинка с усовершенствованными методами оптимизации выполняемого кода в целом и нередко выполняемых кусков кода а именно, для J2SE она стала виртуальной машинкой по дефлоту с версии 1.3).
MIDP– единственный профиль для конфигурации CLDC. Он содержит пакеты для работы с графикой, звуком, взаимодействия с консолью (клавиатура и экран), базисный набор классов для отображения обычных экранов и частей управления. Есть две главные версии MIDP API – 1.0 и 2.0 (самих версий MIDP больше, но в их конфигурации касаются сохранности и не затрагивают само API).
Профиль MIDP задает последующие технические свойства:
— разрешение экрана минимум 96х54 пикселя;
— 32 кб динамической памяти;
— 128 кб под составляющие MIDP;
— 8 кб для хранения неизменных данных;
— беспроводная сеть;
— питание от аккума.
Последующие способности устройств исходя из убеждений разраба обуславливаются поддержкой доп пакетов. к примеру, для работы с мультимедиа употребляется MMAPI (JSR-135).
Нужной составляющей CDLC является KVM, которая из-за компактности имеет ряд труднодоступных параметров:
— не поддерживаются операции с дробными числами;
— недозволено сделать класс-загрузчик для динамической загрузки классов во время выполнения;
— отсутствует механизм отражения – набор средств для получения полной и исчерпающей инфы о каком-либо классе во время выполнения программки;
— не реализован Java Native интерфейс – возможность воззвания из Java-программ к программкам, реализованным на остальных языках программирования, так именуемым native-методам;
— не поддерживается финализация;
— отсутствует поддержка групповых потоков.
Главным классом написания приложений для мобильных устройств является MIDlet. Актуальный цикл мидлета основан на способах startApp(), pauseApp(), destroyApp() и представлен на рисунке 2.2.
Набросок 2.2 – Актуальный цикл мидлета
Все экранные формы расширяют абстрактный класс Displayable. Этот класс обрисовывает экранную форму, которая может иметь заголовок, бегущую строчку, несколько установок и слушатель событий. Отображаемое содержимое формы определяется подклассами. Существует 6 классов, которые представляют собой разные типы экранных форм [3]:
— List дозволяет избрать юзеру элементы из перечня. Любой элемент в перечне представляется строкой и может иметь Image;
— TextBox дозволяет юзеру вводить и редактировать текст;
— Alert можно сопоставить с диалоговым окном, оповещающим о некий произошедшей ситуации;
— Form может содержать комбинацию частей, которые могут представлять строки, изображения, поля ввода, списки;
— Canvas дозволяет приложению самому обеспечивать отрисовку, переопределив способ Paint (Graphics g);
— TextBox – представляет собой многострочное поле для ввода и редактирования текста.
Подсветка экрана, вибратор, звук в MIDP 1.0 отсутствуют (они возникли лишь в MIDP 2.0). Но, не глядя на все эти ограничения, можно следить большущее количество мобильников, в каких есть такие способности. Происходит это поэтому, что производители добавляют собственный свой API, реализующий данные способности. В связи с сиим мидлет, изготовленный для 1-го телефона, может не работать на другом.
J2ME-приложение состоит из 2-ух файлов: jad и jar. Jad-файл – это дескриптор приложения, текстовый файл, в каком указаны атрибуты приложения. Jar-файл – это сама программка, это пакет мидлетов (Midlet Suite).
2.2 библиотека LWUIT
Библиотека LWUIT [4] базируется на профиле MIDP 2.0 и создана для резвой разработки пользовательских интерфейсов, которые будут идиентично смотреться на телефонах разных производителей. к примеру, на телефонах Nokia элемент StringItem (строковый элемент формы) ставит опосля себя знак перевода строчки, а на телефонах Sony Ericsson – нет. На Nokia элемент Ticker (бегущая строчка) закрывает заголовок формы, на остальных телефонах – нет, а на третьих Ticker может совершенно не поддерживаться. Таковая портабельность получается из-за реализации собственного слоя поверх системной канвы и разработанных собственных частей графического интерфейса.
LWUIT сотворена по виду Swing и реализует ординарную графику и модель пользовательского интерфейса с маленькими исходными требованиями к ресурсам и умеренными требованиями к производительности. В ней употребляется Интеграция графики SVG и механизм MVC.
Данная библиотека заходит в состав Sun J2ME SDK 3.0 и предоставляет последующие главные способности:
— поддержка окон;
— пользовательские стили;
— анимация;
— сенсорная навигация.
Базисным классом для всех частей графического интерфейса является Component. Все элементы добавляются в контейнеры, до этого чем они будут отображены на дисплее. Контейнеры также могут быть вложены друг в друга. Самым главным контейнером является Form, который представляет собой экранную форму. В общем случае у него есть строчка заголовка сверху, строчка меню с командами понизу и по центру размещается ContentPane – контейнер для частей графического интерфейса. Дальше приводится листинг 2.1 сотворения обычного приложения с внедрением данной библиотеки, которое выводит приветствие и содержит одну клавишу.
Листинг 2.1 – Создание формы
importcom.sun.lwuit. Display;
import com.sun.lwuit. Form;
import com.sun.lwuit. Label;
import com.sun.lwuit.layouts. BorderLayout;
import com.sun.lwuit.plaf.UIManager;
import com.sun.lwuit.util. Resources;
public class HelloMidlet extends javax.microedition.midlet.MIDlet {
public void startApp() {
// инициализациябиблиотеки
Display.init(this);
// Установкапользовательскойтемы
try {
Resources r = Resources.open («/myresources.res»);
UIManager.getInstance().setThemeProps (r.getTheme (
r.getThemeResourceNames() [0]));
} catch (Java.io.IOException e) {
System.out.println («IOException «+e.getMessage());
}
// 1. Созданиеформы
Form mainForm = new Form («Form Title»);
// для определения метода размещения копонетов
mainForm.setLayout (newBorderLayout());
mainForm.addComponent (BorderLayout.CENTER, new Label («HelloWorld»));
// 4. Добавлениекоманднойкнопки
mainForm.addCommand (new Command («Run», 2));
mainForm.show();
}
public void pauseApp() {
}
public void destroyApp (boolean unconditional) {
}
}
Дальше рассматриваются главные элементы графического интерфейса [5].
Label может показывать строку текста и / либо картину.
Button представляет собой клавишу и помещается на ContentPane. Может содержать набросок.
Чтоб обработать нажатие клавиши, нужно воплотить интерфейс ActionListener. Дальше приводится программный код обычного обработчика нажатия клавиши (листинг 2.2).
Листинг 2.2 – Обработканажатиякнопки
final Button button = new Button («Old Text»);
button.addActionListener (new ActionListener() {
public void actionPerformed (ActionEvent evt) {
button.setText («New Text»);
}
});
RadioButton– радиокнопка, является наследником Button.
ButtonGroup дозволяет соединять воединыжды радиокнопки в группы, чтоб в хоть какой момент была выбрана лишь одна из их.
CheckBox является наследником RadioButton и представляет собой флаг.
ComboBox – это выпадающий перечень. К нему можно применить все способности прорисовки, как и для частей перечня List. В выпадающем перечне ComboBox могут содержаться не только лишь строки текста, да и радиокнопки, флажки, клавиши и остальные списки.
TextArea предоставляет возможность редактировать текст в редакторе текста телефона – это означает, что может быть внедрение наиболее сложных способов ввода (к примеру, T9).
TabbedPane – это контейнер, который дозволяет переключаться меж разными группами компонент, расположенными на вкладках.
2.3 Блютуз
Блютуз– это дешевая разработка, позволяющая электрическим устройствам обмениваться информацией посредствам радиоканала. Радиус деяния Блютуз-передатчиков, как правило, не превосходит 15-ти метров. Для связи употребляется частота 2.45 GHz. В истинное время доступна разработка Блютуз версии 1.1, которая содержит в себе технологию радиосвязи, набор программ и профилей.
разработка названа в честь короля Дании HaroldBluetooth, жившем в X веке, который соединил и правил Норвегией и Данией.
1-ое Блютуз-устройство возникло на рынке в 1999. Разрабом Блютуз является Блютуз Special Interest Group. Всоставэтойорганизациивходяттакиекомпании, какSony Ericsson, Intel, IBM, Toshiba, Nokia, Microsoft, 3COM, Motorola.
Цель спецификации [6] протокола Блютуз– обеспечить взаимодействие устройств разных производителей, потому она описывает целый стек протоколов, а не только лишь радиосистему (набросок 2.3).
Набросок 2.3 – Стек протоколов Блютуз
HCI– это обычно слой, разделяющий программную и аппаратную реализацию стека протокола. Слои ниже theHCI, как правило, реализованы аппаратно, а слои выше – программно. Но устройства с ограниченными ресурсами могут вполне воплотить всю функциональность аппаратно.
Applications– профили Блютуз, которые определяют, как приложения должны применять стек протоколов.
TelephonyControlSystem (TCS) – обеспечивает телефонный сервис.
ServiceDiscoveryProtocol (SDP) – употребляется для поиска сервисов на удаленном Блютуз-устройстве.
WAPи OBEX– предоставляют интерфейсы для верхнего слоя остальных протоколов связи.
RFCOMM– обрисовывает RS-232 как поочередный интерфейс.
L2CAP– собирает данные от верхних слоев и преобразовывает их меж пакетами различных размеров.
HCI– управляет связью меж хостом и Блютуз-модулем.
LinkManagerProtocol– контролирует и изменяет связи с иными устройствами.
Basebandи LinkController– управляют физическими связями, частотой хопов и сборкой пакетов.
Radio– модулирует и демодулирует данные для передачи и приема по воздуху.
разработка Блютуз [7] употребляет технический прием FHSS. Радиодиапазон делится на 79 подканалов. В любой момент времени употребляется лишь один из этих подканалов. Переключение меж ними (хоп) происходит любые 625 микросекунд (1600 хопов за секунду). Такое нередкое переключение нужно, чтоб уменьшить интерференцию, вызываемую иными расположенными Блютуз-устройствами и иными устройствами, использующими этот же самый спектр частот (к примеру, микроволновая печь либо Wi-Fi).
Если устройство ведет взаимодействие через Блютуз и Wi-Fi сразу, то применяется механизм AFH.
Любому Блютуз-устройству назначается неповторимый 48-битный адресок, который употребляется для идентификации и синхронизации хопов, также для генерации ключей в процедурах сохранности Блютуз.
Пикосеть – это форма Блютуз-сети (набросок 2.4). Она состоит из 1-го мастера и нескольких (не наиболее 7) подчиненных устройств (slaves).
Набросок 2.4 – Пикосеть
Устройство, инициирующее соединение, автоматом становится мастером. Подчиненные устройства могут лишь предавать данные в выделенное им время. Все взаимодействия меж подчиненными устройствами осуществляются не впрямую, а через мастера. При подключении новейшего устройства к пикосети вероятен обмен ролями.
Две пикосети могут существовать в границах радиодиапазона друг друга. Частота хопов не синхронизируется меж пикосетями, потому постоянно будут возникать конфликты на одной и той же частоте.
Две взаимодействующие пикосети образуют рассеянную сеть – scatternet (набросок 2.5). Общий узел является разделяемым и в любой момент времени может работать лишь в одной пикосети, что уменьшает трафик вдвое меж ними.
Набросок 2.5 – Взаимодействие 2-ух пикосетей
В процессе поиска [8] находящихся Блютуз-устройств (inquiry) запрашивающее устройство будет получать Блютуз-адреса и время всех найденных устройств. Чтоб устройство было найдено, нужно у него установить соответственный режим доступности – IAC.
IAC может принимать два значения: GIAC и LIAC. GIAC употребляется, когда нужно разрешить устройству быть найденным постоянно, а LIAC– когда устройство обязано быть доступно в течении ограниченного промежутка времени.
Опосля обнаружения устройства можно его просканировать на наличие доступных сервисов. Для этого предназначен протокол ServiceDiscoveryProtocol.
Блютуз-устройство хранит информацию обо всех собственных сервисах в специальной базе данных – ServiceDiscoveryDataBase. Любая запись в ней содержит атрибуты, определяющие один сервис. Атрибуты определяются 16-ричным идентификаторами.
Неотклонимыми для каждой записи являются лишь два атрибута ServiceRecordHandle (ID 0x0000) и ServiceClassIDList (ID 0x0001). Разные атрибуты содержат данные различных типов. Потому употребляются особые элементы данных для хранения этих значений, которые состоят из дескриптора типа данных, определяющего тип и размер, и самих данных.
UniversallyUniqueIDentifier (UUID) – это тип данных для идентификации сервисов, протоколов, профилей и пр. Он представляет собой 128-битное число, которое является постоянно неповторимым. Блютуз-разработка употребляет UUIDразличной длины. Спектр маленьких UUID зарезервирован для более нередко применяемых сервисов, протоколов и профилей.
Блютуз-профиль предоставляет набор высокоуровневых процедур и унифицированных методов использования верхних слоев Блютуз. Профиль описывает метод реализации функциональности с применением Блютуз.
Сохранность при использовании Блютуз играет важную роль, поэтому что передаваемые беспроводным методом данные могут быть прослушаны находящимися устройствами, также устройство, которое доступно для обнаружения, быть может подвержено сканированию на наличие сервисов и их следующему использованию.
Для решения обозначенных выше заморочек спецификация Блютуз описывает модель сохранности, состоящую из 3-х компонент: аутентификация, шифрование, авторизация. К тому же определены три режима сохранности, которые входят в профиль GAP, поддерживаемый всеми сертифицированными Блютуз-устройствами:
— незащищенный;
— сохранность на уровне сервисов – употребляется большинством Блютуз-устройств. Необходимость защиты решается на уровне сервиса. Меры защиты инициируются наиболее высочайшими слоями опосля того, как Блютуз-связь уже установлена наиболее низкими слоями;
— сохранность на уровне установления связи – инициируется наиболее низкими слоями в стеке протоколов Блютуз. Этот режим вероятен лишь для Блютуз-устройств с заводскими предустановленными опциями, которые не могут быть изменены юзером.
На наиболее массивных устройствах с Блютуз юзер может сам определять уровень сохранности.
Сопряжение, либо связывание (bonding), – это процедура аутентификации Блютуз-устройствами друг друга, зависящая от разделяемого ими аутентификационного ключа. Если такового ключа нет у их, то новейший ключ должен быть сотворен до окончания сопряжения.
Генерация аутентификационного ключа именуется парингом (pairing). Паринг включает генерацию ключа инициализации и аутентификационного ключа, опосля что производится обоюдная аутентификация.
Ключ инициализации основан на ключе доступа (введенным юзером случайном числе) и Блютуз-адресе 1-го из устройств. Ключ доступа становится известным лишь двум данным устройствам. Аутентификационный ключ основан на случайном числе и Блютуз-адресах обоих устройств. Ключ инициализации употребляется для шифрования при обмене данными для сотворения аутентификационного ключа и позже отбрасывается.
По окончании процесса паринга устройства являются аутентифицированными друг другом. Оба устройства употребляют один и этот же аутентификационный ключ. Устройства дальше числятся сопряженными и могут аутентифицировать друг друга через bonding без ключа доступа.
Устройства могут оставаться в паринге до того времени, пока одно из их не востребует установления новейшего паринга либо пока не будет удален аутентификационный ключ на одном из устройств.
Сохранение ключа аутентификации прибыльно при нередком установлении соединения меж данными устройствами.
Опосля того, как два устройства аутентифицировали друг друга, шифрование быть может нужно для данного соединения хоть какому из этих устройств.
До внедрения шифрования устройства должны условиться о режиме шифрования и длине ключа.
Вероятны три режима шифрования:
— отсутствие шифрования – если одно из устройств не поддерживает шифрование, то будет соединение без шифрования;
— шифрование пакетов меж устройствами и широковещательных пакетов;
— шифрование лишь пакетов меж устройствами.
До внедрения шифрования устройства должны условиться о размере ключа (8 – 128 бит).
Авторизация – это процесс предоставления удаленному Блютуз-устройству доступа к некому сервису. Чтоб быть авторизированным, удаленное устройство сначала обязано быть поначалу аутентифицировано через bonding.
Доступ быть может предоставлен на время либо повсевременно.
При авторизации для некого устройства быть может установлен атрибут trust, который сравнивает права авторизации с неким устройством. Устройство с таковым атрибутом (доверенное устройство) может подключаться к Блютуз-сервису и процесс авторизации будет успешен без вмешательства юзера.
Чтоб хранить информацию о доверенных устройствах и разных уровнях авторизации для разных сервисов, используются две базы данных – одна для устройств, иная для сервисов. Неким слоям нужен доступ к сиим базам, который предоставляет Менеджерсохранности.
Остальные принципиальные задачки, решаемые менеджером сохранности, – это запрос ключа доступа во время процесса паринга и запрос авторизации, когда удаленное устройство пробует объединиться с обслуживанием, требующим авторизации, также предоставление интерфейса для опции характеристик сохранности.
3
. Проектирование приложения для мобильного телефона на базе платформы J2ME
3.1 Постановка задачки
Требуется создать приложение для мобильного телефона на платформе J2ME, которое будет производить видеонаблюдение и предоставлять последующие главные способности:
— расписание работы камеры – возможность указывать время начала и окончания видеонаблюдения;
— обнаружение движения и отправка SMS-сообщения либо MMS-сообщения с подходящим изображением;
— оповещение о возникающих неверных ситуациях на обозначенный номер;
— файловый браузер для выбора либо сотворения папки, в которую требуется сохранять видеоданные от камеры как последовательность изображений;
— передача видеоданных, получаемых от камеры, в виде отдельных кадров по Блютуз.
Для передачи данных по Блютуз требуется создать 2-ой мидлет, который будет принимать данные, показывать приобретенное изображение и по мере необходимости сохранять его в заблаговременно избранную папку.
3.2 Построение интерфейса
Графический интерфейс приложения реализован при помощи библиотеки LWUIT. Стиль дизайна всех использованных частей интерфейса был настроен вручную. Главные принципы опции стиля последующие.
Во-1-х, можно поменять стиль 1-го определенного компонента. Стиль всякого элемента определяется объектом класса Style. Чтоб получить стиль компонента, нужно вызвать способ getStyle(). При помощи способа setStyle() можно поменять стиль данного компонента.
Во-2-х, можно поменять стиль всех компонент 1-го типа, к примеру, клавиш. Для этого нужно получить объект UIManager.getInstance(), который описывает стиль дизайна всех частей по дефлоту. Дальше следует применять его способ setComponentStyle с 2-мя аргументами – имя класса компонента и объект класса Style. В листинге 3.1 приведен программный код опции стиля текстового поля по дефлоту.
Листинг 3.1 – Применение стиля дизайна для текстового поля
/**
* ConfigureTextFieldStyle
*
* @param manager– User Interface Manager
*/
private void configureTextField (UIManager manager) {
Style textFieldStyle = new Style();
textFieldStyle.setFgSelectionColor(0x0000);
textFieldStyle.setFgColor(0x000000);
textFieldStyle.setBgTransparency(0x00);
textFieldStyle.setFont(boldFont);
textFieldStyle.setBorder (Border.createLineBorder(1));
manager.setComponentStyle(«TextField», textFieldStyle);
}
На рисунке 3.1 показана экранная форма с главными элементами и уже примененными стилями.
Набросок 3.1 – Заставка приложения
При разработке экрана заставки (набросок 3.1) было нужно сглаживание по центру. В библиотеке LWUIT нет такового метода размещения компонент, потому был сотворен класс CenterLayout (листинг 3.2), расширяющий класс Layout. Layout является абстрактным классом, который наследуют все другие классы-менеджеры размещения компонент контейнера. В новеньком классе были переопределены способы layoutContainer (Containerparent) и getPreferredSize (Containerparent).
Листинг 3.2 – Сглаживание частей по центру
/**
* Layout the given parent container children
* @param parent the given parent container
*/
public class CenterLayout extends Layout {
public void layoutContainer (Container parent) {
int components = parent.getComponentCount();
Style parentStyle = parent.getStyle();
int centerPos = parent.getLayoutWidth() / 2 +
parentStyle.getMargin (Component.LEFT);
int y = parentStyle.getMargin (Component.TOP);
for (int iter = 0; iter < components; iter++) {
Component current = parent.getComponentAt(iter);
Dimension d = current.getPreferredSize();
current.setSize(d);
current.setX (centerPos – d.getWidth() / 2);
Style currentStyle = current.getStyle();
y += currentStyle.getMargin (Component.TOP);
current.setY(y);
y += d.getHeight() + currentStyle.getMargin (Component.BOTTOM);
}
}
/**
* Returns the container preferred size
*
* @param parent the parent container
* @return the container preferred size
*/
public Dimension getPreferredSize (Container parent) {
int components = parent.getComponentCount();
Style parentStyle = parent.getStyle();
int height = parentStyle.getMargin (Component.TOP)
+ parentStyle.getMargin (Component.BOTTOM);
int marginX = parentStyle.getMargin (Component.RIGHT)
+ parentStyle.getMargin (Component.LEFT);
int width = marginX;
for (int iter = 0; iter < components; iter++) {
Component current = parent.getComponentAt(iter);
Dimension d = current.getPreferredSize();
Style currentStyle = current.getStyle();
width = Math.max (d.getWidth() + marginX
+ currentStyle.getMargin (Component.RIGHT) +
currentStyle.getMargin (Component.LEFT), width);
height += currentStyle.getMargin (Component.TOP) + d.getHeight() +
currentStyle.getMargin (Component.BOTTOM);
}
Dimension size = new Dimension (width, height);
return size;
}
}
В последующем листинге 3.3 содержится программный код экранной формы-заставки с применением разработанного класса-менеджера размещения частей CenterLayout.
Листинг 3.3 – Экранная форма заставки
publicclassSplashScreenextendsForm {
public SplashScreen() {
setLayout (new CenterLayout());
setTitle («Welcome»);
addComponent (new Label((«Video observer»)));
addComponent (new Label((«by M. Luskanova»)));
}
}
Набросок 3.2 – основное меню
Для сотворения головного меню (набросок 3.2) был реализован особый класс, который представляет собой один пункт меню. Любой элемент такового меню является контейнером с несколькими строками и представляет их как единое целое. Таковая функциональность получается из-за наследования от класса Container и переопределения способов getComponentAt() и pointerPressed() (листинг 3.4).
способ getComponentAt (int x, int y) вызывается, когда нужно возвратить компонент, находящийся в данной точке экрана. Если этот способ не переопределить, то будет возвращен элемент, входящий в данный контейнер. Переопределение второго способа гарантирует, что не произойдет никакой обработки (к примеру, выделения) в случае, если юзер изберет какой-нибудь элемент данного пт.
способ pointerPressed (int x, int y) производится в случае нажатия сенсорного указателя. Если этот способ не переопределить, то будет выделен компонент снутри данного контейнера.
Листинг 3.4 – Пункт головного меню
public class MylistItem extends Container implements FocusListener {
private Style selectedStyle =
UIManager.getInstance().getComponentStyle («_selected»);
private Style unselectedStyle =
UIManager.getInstance().getComponentStyle («_unselected»);
/**
* This method provides performance of
* included components as one
*/
public Component getComponentAt (int x, int y) {
return this;
}
/**
* Do nothing when User clicks on any element
*/
public void pointerPressed (int x, int y) {
}
/**
* Returns»_unselected» style by default
*/
protected String getUIID() {
return «_unselected»;
}
/**
* Change style for selected menu item
*/
public void focusGained (Component cmp) {
cmp.setStyle(selectedStyle);
}
/**
* Change style for unselected menu item
*/
public void focusLost (Component cmp) {
cmp.setStyle(unselectedStyle);
}
}
способ getUIID() переопределен для того, чтоб возвращать стиль невыделенного элемента. способ focusGained() вызывается при получении данным пт меню фокуса, и потому требуется этот пункт отрисовать иным стилем.
При перемещении фокуса на последующий пункт меню необходимо поменять стиль этого пт на обыденный, что и производится в переопределенном способе focusLost().
Само меню создается последующим образом с внедрением вышеуказанного класса (листинг 3.5). Preferences.getInstanse() – это объект, который хранит все изготовленные юзером опции.
Листинг 3.5 – Создание головного меню
Preferences pr = Preferences.getInstanse();
setLayout (new BoxLayout (BoxLayout.Y_AXIS));
getContentPane().setIsScrollVisible(false);
MylistItem mli = new MylistItem (MainMenuConstatns.SCHEDULE, «Schedule»);
if (! pr.isStartRecordFromUnbounded()) {
mli.addString («from» +
pr.getStartRecordFromCalendar().get (Java.util. Calendar.YEAR) +».» +
pr.getStartRecordFromCalendar().get (Java.util. Calendar.MONTH) +».» +
pr.getStartRecordFromCalendar().get (Java.util. Calendar.DAY_OF_MONTH)
+» «+pr.getStartRecordFromCalendar().get (Java.util. Calendar.HOUR_OF_DAY)
+»:»+pr.getStartRecordFromCalendar().get (Java.util. Calendar.MINUTE));
}
if (! pr.isEndRecordAtUnbounded()) {
mli.addString («till» +
pr.getEndsRecordAtCalendar().get (Java.util. Calendar.YEAR) +».» +
pr.getEndsRecordAtCalendar().get (Java.util. Calendar.MONTH) +».» +
pr.getEndsRecordAtCalendar().get (Java.util. Calendar.DAY_OF_MONTH) + » » +
pr.getEndsRecordAtCalendar().get (Java.util. Calendar.HOUR_OF_DAY) +»:» +
pr.getEndsRecordAtCalendar().get (Java.util. Calendar.MINUTE));
}
if (! pr.isStartRecordFromUnbounded() ||! pr.isEndRecordAtUnbounded()) {
if (pr.isScheduleIsActive()) {
mli.addString («Active»);
} else {
mli.addString («Disabled»);
}
}
addComponent(mli);
mli = new MylistItem (MainMenuConstatns.TRANSLATE_VIDEO, «Translate video»);
addComponent(mli);
if (pr.getBTConnectionURL()!= «») {
mli.addString («via блютуз to «+pr.getBTFriendlyName());
}
if (pr.getSaveVideoToFile()!= «») {
mli.addString (pr.getSaveVideoToFile());
}
if (pr.getMovNotification()!= «») {
String msgType = (pr.isSendSMS()? «sms»: «mms») +» to»;
addComponent (new MylistItem (MainMenuConstatns.MOVEMENT_NOTIFICATION,
new String[] {«Movement notification», msgType
+ pr.getMovNotification()}));
} else {
addComponent (new MylistItem (MainMenuConstatns.MOVEMENT_NOTIFICATION,
«Movement notification»));
}
if (pr.getErrNotificationNumber()!= «») {
addComponent (new MylistItem (MainMenuConstatns.ERROR_NOTIFICATION,
new String[] {«Error Notification», pr.getErrNotificationNumber()}));
} else {
addComponent (new MylistItem (MainMenuConstatns.ERROR_NOTIFICATION,
«Error Notification»));
}
addComponent (new MylistItem (MainMenuConstatns.CAMERA, «Camera»));
addComponent (new MylistItem (MainMenuConstatns.EXIT, «Exit»));
addComponent (new MylistItem (MainMenuConstatns.HELP, «Help»));
Обработка нажатия юзером клавиш и определение, какая экранная форма обязана быть показана дальше, производится так, как показано в последующем листинге 3.6.
Листинг 3.6 – Обработка нажатий клавиш для головного меню
class MainMenuActionListener implements ActionListener {
public void actionPerformed (ActionEvent act) {
Component cmp = getFocused();
if (cmp instanceof MylistItem) {
int id = ((MylistItem) cmp).getId();
switch (id) {
case MainMenuConstatns.SCHEDULE:
midlet.getScheduleDisplay().show();
break;
case MainMenuConstatns.TRANSLATE_VIDEO:
midlet.getVideoTransmitionDisplay().show();
break;
case MainMenuConstatns.MOVEMENT_NOTIFICATION:
midlet.getMovementNotificationDisplay().show();
break;
case MainMenuConstatns.CAMERA:
midlet.getCamera().show();
midlet.getCamera().startCamera();
midlet.getCamera().revalidate();
break;
case MainMenuConstatns.EXIT:
midlet.exitMIDlet();
break;
case MainMenuConstatns.HELP:
midlet.getHelpScreen().show();
break;
case MainMenuConstatns.ERROR_NOTIFICATION:
midlet.getErrorNotification().show();
break;
}
}
}
На форме опции расписания (набросок 3.3) нужно было воплотить динамическое скрытие / отображение неких частей, а конкретно: когда выбирается радиокнопка enter time, то должны сходу под ней отобразиться поля для ввода часов, минут, денька, месяца, года. А при выбирании радиокнопки unbounded эти поля должны быть укрыты.
Набросок 3.3 – Наполнение расписания работы камеры
Таковая функциональность реализуется методом указания у каждой радиокнопки ActionListener, который выслеживает выбор радиокнопок (листинг 3.7). dateFrom и dateTo являются контейнерами типа Container и содержат все нужные поля для указания четкой даты и времени.
Листинг 3.7 – Обработка выбора радиокнопок
publicvoidactionPerformed(ActionEventevt) {
Component cmp = (Component) evt.getSource();
if (cmp == rb1DateFromEnter) {
if (rb1DateFromEnter.isSelected()) {
if (! getContentPane().contains(dateFrom)) {
addComponent (3, dateFrom);
revalidate();
return;
}
}
}
if (cmp == rbDateFromUnbounded) {
if (getContentPane().contains(dateFrom)) {
removeComponent(dateFrom);
revalidate();
return;
}
}
if (cmp == rbDateToEnter) {
if (rbDateToEnter.isSelected()) {
if (! getContentPane().contains(dateTo)) {
addComponent (getContentPane().getComponentCount() – 2, dateTo);
dateTo.setFocus(true);
revalidate();
return;
}
}
}
if (cmp == rbDateToUnbounded) {
if (getContentPane().contains(dateTo)) {
removeComponent(dateTo);
revalidate();
return;
}
}
}
Набросок 3.4 – Экранная форма со перечнем
Для всех списков в данном приложении разработан особый метод их отображения – класс MyListCellRenderer. По дефлоту для отображения списков применяется DefaultListCellRenderer, который просто преобразовывает все элементы к объектам класса Label. Для сотворения собственного метода отображения частей перечня нужно воплотить интерфейс ListCellRenderer.
Способ getListCellRendererComponent этого интерфейса должен возвращать отображаемый элемент перечня из объекта, передаваемого ему в качестве параметра. Переопределение способов getListFocusComponent обеспечивает возможность опции стилей отображения выделенного и невыделенного элемента перечня.
Пример перечня, реализованного при помощи MyListCellRenderer, приведен на рисунке 3.4. В листинге 3.8 приведен программный код класса, который прорисовывает перечень.
Листинг 3.8 – Прорисовкасписка
public class MyListCellRenderer extends Container implements ListCellRenderer {
public MyListCellRenderer() {
setLayout (new BoxLayout (BoxLayout.Y_AXIS));
}
/**
* Returns displayable list element from received object
*/
public Component getListCellRendererComponent (List list, Object value,
int index, boolean isSelected) {
if (value instanceof String) {
setText((String) value);
} else {
setText (value.toString());
}
setFocus(isSelected);
applyStyle (this, isSelected);
return this;
}
/**
* Applies style for selected and unselected element
*/
private void applyStyle (Component component, boolean isSelected) {
Style style = null;
if (isSelected) {
style = UIManager.getInstance().getComponentStyle («_selected»);
} else {
style = UIManager.getInstance().getComponentStyle («_unselected»);
}
component.setStyle(style);
}
public Component getListFocusComponent (List list) {
returnnull;
}
}
3.3 Передача данных по Блютуз
API для работы с Блютуз содержится в пакете JSR-82 [9]. Эта библиотека состоит из 2-ух пакетов: базисное BluetoothAPI и OBEX.
Для работы с Блютуз у телефона должны быть минимум 512 кб памяти, также поддерживаться CLDC.
Чтоб приложение могло применять способности Блютуз, нужно воплотить интерфейс DiscoveryListener и его способы deviceDiscovered(), inquiryCompleted(), servicesDiscovered(), serviceSearchCompleted(), применяемые для обнаружения рядом находящихся Блютуз-устройств.
Дальше приводится программный код (листинг 3.9), который инициирует поиск. Сначала инициализируется переменная LocalDevice local, которая представляет собой данный телефон; позже инициализируется переменная DiscoveryAgent agent. Конкретно этот объект запускает поиск способом startInquiry() с параметрами DiscoveryAgent.GIAC и ссылкой на объект, который воплотил интерфейс DiscoveryListener и будет обрабатывать все действия, связанные с обнаружением устройств и их сервисов. Этот способ возвращает true, если поиск устройств был удачно начат, либо false в неприятном случае.
Переменная Vector devicesFound употребляется для сохранения всех найденных устройств.
Листинг3.9 – Началопоискаустройств
* This method starts device discovering
*/
public void doDeviceDiscovery() {
try {
local = LocalDevice.getLocalDevice();
} catch (BluetoothStateException bse) {
Log.out.println («EXCEPTION!»+ bse.toString());
}
agent = local.getDiscoveryAgent();
devicesFound = new Vector();
try {
if (! agent.startInquiry (DiscoveryAgent.GIAC, this)) {
Log.out.println (» DISCOVERING IS NOT STARTED»);
}
} catch (BluetoothStateException bse) {
Log.out.println (» BluetoothStateException «+ bse.toString());
}
}
При обнаружении Блютуз-устройства вызывается способ deviceDiscovered(), который получает в качестве характеристик отысканное устройство remoteDevice и его тип deviceClass.
Дальше приводится программный код (листинг 3.10) этого способа. В способе производится добавление в перечень, отображаемый на дисплее, доступных находящихся Блютуз-устройств. Отысканное устройство также добавляется в массив devicesFound.
Листинг 3.10 – Обработка действия, связанного с обнаружением новейшего устройства
/**
* Called when a device is discovered during device discovery
* @param remoteDevice founded device
* @param deviceClass
public void deviceDiscovered (RemoteDevice remoteDevice,
DeviceClass deviceClass) {
try {
midlet.getSelectDeviceDisplay().getDevicesList().addItem (
remoteDevice.getFriendlyName(false));
devicesFound.addElement(remoteDevice);
} catch (IOException ex) {
Log.out.println («ex when device has been discovered «+ex.toString());
}
}
Опосля окончания поиска всех устройств вызывается способ inquiryCompleted(), в параметре которого содержится код поискового результата. Дальше приводится этот способ (листинг 3.11).
Листинг 3.11 – Окончание поиска устройств
/**
* Calledwhendevicediscoveringiscomplete
* @param – param discovering status
public void inquiryCompleted (int param) {
midlet.getSelectDeviceDisplay().removeCommand (midlet.getSelectDeviceDisplay().
getStopSearchDevices());
midlet.getSelectDeviceDisplay().addCommand (midlet.getSelectDeviceDisplay().
getBackSelectDevice());
switch (param) {
case DiscoveryListener.INQUIRY_COMPLETED:
if (devicesFound.size() > 0) {
midlet.getSelectDeviceDisplay().removeCommand (
midlet.getSelectDeviceDisplay().getStopSearchDevices());
midlet.getSelectDeviceDisplay().addCommand (
midlet.getSelectDeviceDisplay().getBackSelectDevice());
doServiceSearch((RemoteDevice) devicesFound.elementAt(0));
} else
break;
case DiscoveryListener.INQUIRY_ERROR:
//Error during inquiry
break;
case DiscoveryListener.INQUIRY_TERMINATED:
// Inquiry terminated by agent.cancelInquiry()
break;
}
}
Набросок 3.5 – Перечень отысканных устройств
Опосля поиска устройств (на рисунке 3.5 показан перечень найденных устройств) начинается поиск сервисов на одном из их. Отысканные сервисы запоминаются в массиве ServiceRecord[] servicesFound. В последующем листинге 3.12 приводится способ, который начинает поиск сервисов. Для начала поиска вызывается способ searchServices() ранее сделанного объекта DiscoveryAgent agent, которому передаются последующие характеристики: атрибуты искомого сервиса либо его UUID, удаленное устройство, на котором создавать поиск, также ссылка на объект, который будет обрабатывать все действия, связанные с обнаружением сервисов.
Листинг3.12 – Инициацияпоискасервисов
/**
* This method starts service search on the divice
* @param device to be scanned for services
public void doServiceSearch (RemoteDevice device) {
* Service search will always give the default attributes:
* ServiceRecordHandle (0x0000), ServiceClassIDList (0x0001),
* ServiceRecordState (0x0002), ServiceID (0x0003) and
* ProtocolDescriptorList (0x004).
* These hex-values must be supplied through an int array
*/
int[] attributes = null; // {0x100};
/*
* Supplying UUIDs in an UUID array enables searching for
* specific services.
UUID[] uuids = new UUID[1];
uuids[0] = new UUID(0x0003);
try {
agent.searchServices (attributes, uuids, device, this);
} catch (BluetoothStateException e) {
Log.out.println («BluetoothStateException error»+ e.getMessage());
}
}
Когда поиск сервисов завершен, вызывается способ serviceSearchCompleted(), код которого приведен ниже (листинг 3.13). В параметре данного способа содержится код поискового результата сервисов.
Листинг 3.13 – Завершениепоискасервисов
/**
* Called when service search completes
* @param transID identifies a particular service search
* @param respCode indicates why the service search is ended
*/
public void serviceSearchCompleted (int transID, int respCode) {
switch (respCode) {
case DiscoveryListener.SERVICE_SEARCH_COMPLETED:
Log.out.println («serviceSearchCompleted: SERVICE_SEARCH_COMPLETED»);
if (servicesFound.length > 0) {
midlet.getSelectDeviceDisplay().addCommand (
midlet.getSelectDeviceDisplay().getSelectDeviceCommand());
}
/*
* The service to connect to has been found earlier
* (by service discovery) and the service record is
* referencedthrough the object named: service (of type
* ServiceRecord)
*/
break;
case DiscoveryListener.SERVICE_SEARCH_DEVICE_NOT_REACHABLE:
Log.out.println («serviceSearchCompleted: SERVICE_SEARCH_DEVICE_NOT_REACHABLE»);
break;
case DiscoveryListener.SERVICE_SEARCH_ERROR:
Log.out.println («serviceSearchCompleted: SERVICE_SEARCH_ERROR»);
break;
case DiscoveryListener.SERVICE_SEARCH_NO_RECORDS:
Log.out.println («serviceSearchCompleted: SERVICE_SEARCH_NO_RECORDS»);
break;
case DiscoveryListener.SERVICE_SEARCH_TERMINATED:
Log.out.println («serviceSearchCompleted: SERVICE_SEARCH_TERMINATED»);
break;
}
}
Когда посреди найденных устройств выбрано одно и выполнен на нем поиск сервисов, то можно выполнить передачу данных по Блютуз. Передача осуществляется через StreamConnection, URL которого выходит при помощи последующего способа (листинг 3.14).
Листинг 3.14 – Получение URLдля доступа к сервису
public String getServiceConnectionURL (int nom) {
if (nom < servicesFound.length) {
return servicesFound[nom].getConnectionURL (
ServiceRecord.NOAUTHENTICATE_NOENCRYPT,
false);
} else {
returnnull;
}
}
Последующий листинг 3.15 содержит код, который делает передачу данных. способ sendImageViaBluetooth получает массив б, который представляет собой изображение.
Листинг 3.15 – Отправкаизображенияпо Блютуз
publicstaticvoidsendImageViaBluetooth (byte[] data) {
OutputStream btOutStr = null;
try {
StreamConnection conn = null;
String connectionURL = Preferences.getInstanse().getBTConnectionURL();
if (connectionURL == «») {
Log.out.println («connectionURL is empty»);
return;
}
try {
conn = (StreamConnection) Connector.open(connectionURL);
} catch (IOException e) {
Log.out.println (» sendImageViaBluetooth» + e.toString());
}
btOutStr = conn.openOutputStream();
btOutStr.write(data);
btOutStr.close();
} catch (IOException ex) {
Log.out.println («sending image via BT failed (IOException)» + ex.toString());
} catch (Throwable th) {
Log.out.println («sending image via BT failed» + th.toString());
} finally {
try {
btOutStr.close();
} catch (IOException ex) {
Log.out.println («IOException while closing stream» + ex.toString());
}
}
}
Прием и отображение приобретенного кадра производится аналогичным методом на другом телефоне. Соответственный код представлен в приложении А.
На последующем рисунке 3.6 приведен пример получения клиентом изображения по Блютуз и отображения его на форме.
Набросок 3.6 – Передача данных по Блютуз
3.4 Работа с файловой системой телефона
В конфигурации CLDC отсутствует API для работы с файловой системой и наружными картами памяти телефона, т. к. не у всякого устройства с профилем MIDP есть файловая система.
Платформа J2SE содержит в себе Java.io. File и сопутствующие классы, но эти пакеты очень тяжеловесны для мобильных устройств. Для работы с файлами в мобильных устройствах разработан пакет JSR-75 [10], который предоставляет обычный и легковесный FileConnection API для работы с файловой системой. FileConnection API дозволяет приложениям создавать, делать чтение и запись в файлы и директории, размещенные на телефоне либо карте памяти. Главные классы и интерфейсы пакета JSR-75 последующие:
— интерфейс FileConnection – для доступа к файлам и директориям;
— интерфейс FileSystemListener – для прослушивания уведомления о добавлении либо удалении корневых директорий;
— класс FileSystemRegistry – центральный реестр для слушателей о добавлении либо удалении корневых файловых систем;
— класс ConnectionClosedException – исключение, которое выбрасывается в случае невозможности выполнения способов FileConnection из-за закрытия соединения;
— класс IllegalModeException – исключение, которое выбрасывается в случае выполнения способов, требующих особенных режимов сохранности, таковых как READ либо WRITE, но FileConnection открыт в другом режиме.
приложение может открыть соединение, используя способ Connector.open(). Его единственный параметр – URL, содержащий полный путь к файлу специального формата: file:// <host>/<root>/<directory>/<directory>/…/<fileName>. Элемент host быть может пустым.
Перечень доступных корневых директорий устройства можно получить при помощи вызова способа FileSystemRegistry.listRoots().
Установив соединение FileConnection с файлом либо каталогом, можно делать последующие деяния:
— определять, куда показывает соединение FileConnection – на файл либо папку – при помощи способа isDirectory();
— получать фильтрованный перечень файлов и директорий способом list (String filter, boolean includeHidden);
— инспектировать, существует ли директория либо файл, применяя способ exists();
— определять, является ли сокрытым файл, используя способ isHidden();
— создавать, удалять файл либо директорию способами create(), mkdir() и delete();
— открывать входной / выходной поток для чтения / записи данных в файл, применяя способы openInputStream(), openOutputStream().
Листинг разработанного навигатора по файловой системе мобильного телефона представлен в приложении Б.
На рисунке 3.7 приведен пример отображения 1-го их каталогов файловой системы телефона.
Набросок 3.7 – Файловый Броузер
3.5 Отправка SMS и MMS-сообщений
Для отправки сообщений с мобильного телефона было применено Wireless Messaging API 2.0 (пакет javax.wireless.messaging) [11]. Главные классы этого пакета последующие:
— MessageConnection – интерфейс, который описывает операции для посылки и получения сообщений;
— TextMessage – интерфейс, представляющий текстовые сообщения;
— MultipartMessage – интерфейс для представления составных сообщений;
— MessagePart – экземпляры данного класса могут быть добавлены в MultipartMessage. Любой MessagePart состоит из данных.
Для отправки сообщений приложение обязано поначалу получить экземпляр MessageConnection, передав способу javax.microedition.io. Connector.open() URL, определяющий адресат. В этом URL содержится информация о применяемом протоколе (SMS либо MMS), номере телефона и порте адресата.
Опосля сотворения MessageConnection формируется SMS либо MMS-сообщение, заполняется данными и отчаливает на обозначенный номер (листинги 3.16 и 3.17).
Листинг3.16 – ОтправкаSMS-сообщений
* Send SMS with specified text to phoneNumber
public static void sendSMS (String phoneNumber, String text) {
try {
String addr = «sms:// » + phoneNumber+»:5678″;
MessageConnection conn = (MessageConnection) Connector.open(addr);
TextMessage msg = (TextMessage) conn.newMessage (MessageConnection.TEXT_Message);
msg.setPayloadText(text);
conn.send(msg);
conn.close();
} catch (IOException ex) {
Log.out.println («IOException at Utilities.sendSMS()» + ex.toString());
}
}
Листинг3.17 – Отправка MMS-сообщений
* Send MMS with specified image in second parameter to phoneNumber
*/
public static void sendMMS (String phoneNumber, byte[] data) {
try {
private static MessageConnection conn;
private static MultipartMessage msg;
String addr = «mms:// » + phoneNumber +»:5432″;
conn = (MessageConnection) Connector.open(addr);
msg = (MultipartMessage) conn.newMessage (MessageConnection.MULTIPART_Message);
// size of the part and the number of bytes loaded to mms
int partSize = 10000, counter = 0;
byte buf[] = new byte[partSize];
for (int i = 0; i < data.length / partSize && counter<=290000; i++) {
int curPartLength = partSize;
// if the number of left bytes in data[] is lenss then part size
if (counter + partSize > data.length) {
buf = new byte [data.length – counter];
curPartLength = data.length – counter;
}
// load next part of mms
for (int j = 0; j < curPartLength; j++) {
buf[j] = data [counter++];
}
MessagePart p = new MessagePart (
buf,
Preferences.getInstanse().getEncodingType(),
String.valueOf(i), null, null);
msg.addMessagePart(p);
}
} catch (SizeExceededException ex) {
Log.out.print («SizeExceededException «+ex.toString());
} catch (Exception e) {
Log.out.print («Exception «+e.toString());
} finally {
try {
conn.send(msg);
conn.close();
} catch (IOException ex) {
Log.out.print («IOException «+ex.toString());
}
}
}
Для указания номера, на который нужно отправлять сообщения с извещениями о обнаруженном движении либо о вероятных ошибках в работе, разработаны две формы (набросок 3.8).
Набросок 3.8 – Настройка SMS и MMS-уведомлений
3.6 метод обнаружения движения
Метод обнаружения движения основан на сопоставлении поочередных кадров, которые получаются от камеры с внедрением MobileMediaAPI[12] последующим образом (листинг 3.18).
Листинг3.18 – Доступккамере
player = Manager.createPlayer («capture://video»);
player.realize();
videoControl = (VideoControl) getPlayer().getControl («VideoControl»);
videoControl.setDisplayFullScreen(true);
byte[] b = new byte[5000];
// get snapshot
b = videoControl.getSnapshot(encodings);
im = Image.createImage (b, 0, b.length);
rgbIm = new RGBImage(im);
// call method for motion detection
int r = process (rgbIm.getRGB());
На рисунке 3.9 приведена диаграмма деятель, которая обрисовывает процесс видеонаблюдения.
Функция обнаружения движения получает в качестве параметра очередной кадр камеры, который представляет собой одномерный массив. Любой элемент массива – это одна точка изображения в формате AARRGGBB, который обозначает последующее:
— AA – прозрачность (0xFF значит полную непрозрачность, а 0 – полную прозрачность);
— RR, GG, BB – соответственно красноватая, зеленоватая, голубая rgb-составляющие цвета данной точки.
Обнаружение движения производится в несколько шагов. На первом сравниваются два поочередных кадра и формируется маска. Для этого подсчитывается средняя прозрачность всех точек 2-ух сравниваемых кадров и определяется их разность (корректировка). Дальше происходит сопоставление соответственных точек этих кадров и рассчитываются разности rgb-составляющих цветов этих точек (листинг 3.19).
Эти разности потом корректируются, а конкретно: присваивается 0, если данная разность меньше корректировки, в неприятном случае – из данной разности вычитают корректировку. Дальше получают колер сероватого по скорректированным rgb-разностям, как показано в листинге 3.19 (вычисление переменной result). В результирующую маску записывается этот колер сероватого с учетом прозрачности alpha, взятой из соответственной точки предшествующего кадра. Если в данных точках есть существенное изменение, то в маску записывается белоснежная точка.
Листинг3.19 – Формированиемаски
// current image (inDataInt) and the previous one (refDataInt)
int alpha = refData[ip] & 0xFF000000;
refDataInt = (refData[ip] & 0xFF0000) / 256 / 256;
inDataInt = (inData[ip] & 0xFF0000) / 256 / 256;
r = (refDataInt > inDataInt)? refDataInt – inDataInt: inDataInt – refDataInt;
refDataInt = (refData[ip] & 0x00FF00) / 256;
inDataInt = (inData[ip] & 0x00FF00) / 256;
g = (refDataInt > inDataInt)? refDataInt – inDataInt: inDataInt – refDataInt;
refDataInt = (refData[ip] & 0x0000FF);
inDataInt = (inData [ip++] & 0x0000FF);
b = (refDataInt > inDataInt)? refDataInt – inDataInt: inDataInt – refDataInt;
// intensity normalization
r -= (r < correction)? r: correction;
g -= (g < correction)? g: correction;
b -= (b < correction)? b: correction;
result = (byte) (Java.lang. Math.sqrt((double) ((r * r) + (g * g) + (b * b)) / 3.0));
// bwData is a mask
if (result > (byte) threshold) {
bwData [op++] = alpha + 0xFFFFFF;
} else {
bwData [op++] = alpha + result;
}
Дальше анализируется приобретенная маска и подсчитывается количество областей, где рядом находящиеся точки красноватого цвета. На рисунке 3.10 показаны рядом находящиеся точки (отмечены эмблемой «v») около текущей (обведена толстой линией). Если количество таковых областей больше некого порога, то движение было найдено.
v
v
v
v
v
v
v
v
v
Набросок 3.10 – анализ маски
Полный листинг способа обнаружения движения приведен в приложении В.
Набросок 3.9 – Диаграмма деятель для процесса видеонаблюдения
Заключение
В дипломной работе освещены теоретические базы платформы J2ME, архитектуры Блютуз и обработка видеоданных для обнаружения движения. Создано приложение на платформе J2ME, которое дозволяет производить видеонаблюдение. В нем употребляются такие ресурсы мобильного телефона как файловая система, камера, Блютуз, отправка SMS и MMS-сообщений. Исследована библиотека LWUIT, используемая для построения графического интерфейса.
приложение состоит из 2-ух мидлетов, устанавливаемых на различных телефонах, один из которых делает видеонаблюдение и передает данные по Блютуз, а 2-ой эти данные воспринимает.
Для первого мидлета предусмотрена возможность отправки на обозначенный номер SMS и MMS-сообщений с извещением о движении, также сообщений о вероятных ошибках. приложение имеет интегрированный броузер файловой системы и дозволяет выбирать папку для сохранения данных камеры в виде отдельных изображений. Включение камеры для обнаружения движения и ее отключение быть может выполнено по заблаговременно определенному расписанию.
2-ой мидлет воспринимает изображения, указывает их и сохраняет на телефоне.
интерфейс данного приложения реализован при помощи библиотеки LWUIT. Для отправки SMS и MMS-сообщений с мобильного телефона использовалось Wireless Messaging API 2.0 (JSR-205). Работа с файловой системой построена на базе FileConnectionAPI (JSR-75). Передача данных по Блютуз реализована при помощи пакета JSR-82. Доступ к камере выполнен при помощи MobileMediaAPI (JSR-135).
Приобретенные результаты докладывались на XII Республиканской научной конференции студентов и аспирантов «Новейшие математические способы и компьютерные технологии в проектировании, производстве и научных исследовательских работах». Размещены тезисы доклада[13].
Спи
сок использованных источников
1 Официальный веб-сайт компании SunMicrosystems. Платформа Java 2 MicroEdition[электрический ресурс] / Режим доступа: HTTP://Java.sun.com/javame/reference/apis.jsp. – Дата доступа: 25.05.2009.
2 Горнаков С.Г. Программирование мобильников на Java 2 MicroEdition / С.Г. Горнаков. – М.: ДМК Пресс, 2004. – 336 с.
3 Пирумян B.В. Платформа программирования J2ME для портативных устройств / B.В. Пирумян Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2002. – 352 с.
4 Статьи разрабов LWUIT [электрический ресурс] / Режим доступа: HTTP://lwuit.blogspot.com/ – Дата доступа: 25.05.2009.
5 Официальный веб-сайт библиотеки LWUITEdition[Электронный ресурс] / Режим доступа: https://lwuit.dev.Java.net/ – Дата доступа: 25.05.2009;
6 Архипкин В.Я. Блютуз. Технические требования. Практическая реализация / В.Я. Архипкин, А.В. Архипкин. – М.: Мобильные коммуникации, 2004. – 203 с.
7 Вишневский В.М Широкополосные беспроводные сети передачи инфы / В.М Вишневский, А.И. Ляхов, С.Л. Портной. – М.: Эко-Трендз, 2005. – 592 с.
8 Andre N. Klingsheim, J2ME Блютуз Programming, 2004.
9 Спецификация Блютуз API and OBEX API (JSR-82) for Java Platform, Micro Edition.
10 Спецификация FileConnection Optional Package (JSR-75) for Java2 Micro Edition Version 1.0.
11 Спецификация Wireless Messaging API (JSR-205) for Java2 Micro Edition Version 1.1.
12 Спецификация Mobile Media API (JSR-135) for Java2 Micro Edition.
13 Лусканова М.В. Организация видеонаблюдения при помощи мобильного телефона /
М.В. Лусканова, Е.А. Ружицкая // «Новейшие математические способы и компьютерные технологии в проектировании, производстве и научных исследовательских работах», XII Республиканская научная конференция студентов и аспирантов (2009, Гомель)
]]>