Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лабораторные работы. Мобильные устройства.doc
Скачиваний:
2
Добавлен:
01.05.2019
Размер:
1.8 Mб
Скачать

Получение Web контента

В следующем примере описывается получение данных с помощью MIDP HttpConnection. Обратите внимание на то, что интерфейс HttpConnection является частью профиля MIDP, а не CLDC. HttpConnection совмещает в себе InputStream и OutputStream. Каждый HttpConnection может открыть и использовать только один InputStream и один OutputStream. Также важен порядок в котором используются потоки. OutputStream должен использоваться перед InputStream (если конечно вы собираетесь использовать InputStream). После того как поток данных использован, соединение должно быть закрыто и, если это необходимо, создано новое. Эта схема соответствует HTTP парадигме запрос-ответ.

HttpConnection намного сложнее сокетов и дейтаграмм. HTTP соединение может находиться в одном из трех состояний.

  • Устанавливается

  • Соединено

  • Закрыто

Сразу после открытия соединения HttpConnection находится в состоянии "устанавливается". На этой стадии можно задать различные параметры, например тип запроса (GET/POST) или настройки HEAD заголовка (с помощью методов setRequestMethod() и setRequestProperty()).

В состояние "соединено" поток переходит в результате вызова любого из методов, которые приводят к передачи данных на сервер:

  • openInputStream

  • openDataInputStream

  • getLength

  • getType

  • getEncoding

  • getHeaderField

  • getResponseCode

  • getResponseMessage

  • getHeaderFieldInt

  • getHeaderFieldDate

  • getExpiration

  • getDate

  • getLastModified

  • getHeaderField

  • getHeaderFieldKey

После того как поток перешел в состояние "соединено" вызов методов setRequestMethod() и setRequestProperty() приведет к возникновению IOException.

Приведенный ниже пример демонстрирует считывание данных из HttpConnection. Поскольку порт не указан, подключение происходит к 80 порту. По умолчанию для запроса используется метод GET.

HttpConnection c = null;

InputStream is = null;

StringBuffer sb = new StringBuffer();

try {

c = (HttpConnection)Connector.open(

"http://www.mobilab.ru",

Connector.READ_WRITE, true);

c.setRequestMethod(HttpConnection.GET); //default

is = c.openInputStream(); // transition to connected!

int ch = 0;

for(int ccnt=0; ccnt < 150; ccnt++) { // get the title.

ch = is.read();

if (ch == -1){

break;

}

sb.append((char)ch);

}

}

catch (IOException x){

x.printStackTrace();

}

finally{

try {

is.close();

c.close();

} catch (IOException x){

x.printStackTrace();

}

}

System.out.println(sb.toString());

В этом примере устанавливается соединение с сервером www.mobilab.ru. Поскольку используется HttpConnection и не указан конкретный порт, используется принятый по умолчанию порт 80. Для запроса используется метод GET (вообще-то метод GET используется по умолчанию и его установка в данном примере носит иллюстративный характер.

Когда какой протокол использовать?

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

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

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

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

GCF предоставляет богатые функциональные возможности и определяет правила работы с сетевыми соединениями в рамках J2ME архитектуры. GCF легко расширяется и производители телефонов могут добавлять поддержку своих протоколов и других типов соединения. В некоторых случаях производитель может использовать GCF для поддержки потока собственного мультимедийного контента со специальным типом соединения или для установления соединения с GPS ресивером. Эта гибкость позволяет производителям не ограничиваться стандартным набором протоколов, а развивать новые технологии.

Завдання

Проробити практичний матеріал, розглянутий в лабораторній роботі

Лабораторная работа №3

Использование Bluetooth в J2ME приложениях. (JSR-82) - Часть 1. Знакомство с технологией Bluetooth и Java API for Bluetooth

JSR-82 — это дополнительный J2ME пакет, реализующий Java Community Process, который предоставляет стандартный API для Bluetooth соединения.

Bluetooth — это дешевая технология, позволяющая электронным устройствам обмениваться информацией посредствам радиоканала. Радиус действия Bluetooth передатчиков, как правило, не превышает 15-ти метров. Для связи используется частота 2.45 GHz. В настоящее время доступна технология Bluetooth версии 1.1, которая включает в себя технологию радиосвязи, набор программ и профилей.

Разработчиком Bluetooth является Bluetooth Special Interest Group (SIG).