Текст книги "Платформа J2Me"

Автор книги: Автор Неизвестен

сообщить о нарушении

Текущая страница: 11 (всего у книги 21 страниц)

Название метода RecordListener – Описание

void recordAdded (RecordStore recordStore, int recordld) – Уведомляет блок прослушивания записей о том, что запись была добавлена в указанное хранилище записей с указанным ID

void recordChanged (RecordStore recordStore, int recordld) – Уведомляет блок прослушивания записей о том, что запись с указанным ID была изменена в хранилище записей

void recordDeleted (RecordStore recordStore, int recordld) – Уведомляет блок прослушивания записей о том, что запись с указанным ID была удалена из хранилища записей

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

Различные свойства хранилищ записей

Класс RecordStore определяет несколько других свойств, которые полезны для приложений. В таблице 7.4 перечислены некоторые из других методов класса RecordStore и кратко описано их использование.

Таблица 7.4. Методы класса RecordStore

Название метода – Описание

void closeRecordStore () – Закрывает хранилище записей

static void deleteRecordStore () – Удаляет хранилище записей

long getLastModified () – Выдает время последней модификации

String getName () – Выдает название хранилища записей

int getNumRecords () – Выдает число записей в хранилище

byte [] getRecordfint recordl () – Извлекает запись по Ю

byte [] getRecord(int recordld, byte [] buffer, int offset) – Получает запись и помещает ее в предоставленный буфер

byte [] getRecordSize (int recordld) – Получает размер указанной записи

int getSize () – Выдает размер места (в байтах), которое занимает хранилище записей

int getSizeAvailable () – Выдает число оставшихся байтов, на которое хранилище записей может вырасти

int getVersion() – Выдает номер версии хранилища записей

static String [] listRecordStores () – Выдает список всех хранилищ записей, доступных набору MID-летов

static RecordStore openRecordStore (String name, boolean createlfNecessary) – Открывает указанное хранилище записей, создавая его, если оно не существует

Выводы по главе

Система управления записями (RMS) MIDP поддерживает постоянное хранение записей данных в зависимости от устройства. Класс RecordStore предоставляет API для постоянного хранения данных и извлекает подробную информацию о доступе к определяемым устройством областям хранения.

Хранилища записей определяются по именам, которые состоят максимум из 32 знаков уникода. Хранилища записей могут совместно использоваться MID-летами, находящимися в одном наборе MID-летов.

RMS определяет простую абстракцию базы данных, связанную с записями. Записи хранятся как массив байтов. Хранилище записей не имеет понятий встроенных типов Java.

Вы можете извлекать записи, предоставляя уникальный ID записи. Либо вы можете извлекать записи, получая список записей из RecordStore.

Списки необходимы для поиска записей в хранилище записей. Теоретически фильтры записей предоставляют своего рода механизм запросов. В связи с возможностью составления списков в RecordStore, фильтры записей поддерживают поиск только тех записей, которые соответствуют одному или нескольким критериям. Фильтр записей, класс, который реализует интерфейс RecordFilter, определяет критерии поиска.

Компараторы записей предоставляют возможность сортировки записей, извлекаемых из списка. Компараторы определяют политику сортировки и используются с механизмом составления списка. Реализация RecordComparator определяет семантику сортировки.

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

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

Разработчики должны также измерять производительность их реализации RMS при запуске приложений, чтобы убедиться, что производительность приемлема для конечных пользователей. Бывало, что действующие приложения начинали работать слишком медленно из-за использования обновлений хранилища записей. Подтверждено, что перезапись приложений таким образом, чтобы все содержимое хранилища записей было загружено и перемещено, быстрее, чем выполнение обновлений в измененных элементах!

Глава 8. Организация сетей и коммуникации в MIDP

На данный момент вы знаете, как писать автономные приложения MIDP, которые могут, среди всего прочего, взаимодействовать с пользователем и хранить данные. Следующим шагом будет изучение того, как писать сетевые приложения. Как-никак, платформа J2ME поддерживает компьютерные технологии для портативных устройств, a CLDC/MIDP, в частности, поддерживает персональные мобильные устройства связи. Возможность связи очень важна для мобильных устройств с MIDP и является темой обсуждения в этой главе.

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

Модель организации сетей в MIDP

В MIDP, как и в J2SE, потоки ввода-вывода являются наиважнейшим механизмом, доступным приложениям, для чтения и записи потоков данных. Как J2SE, так и J2ME имеют пакет java.io, который содержит эти классы потоков. Кроме того, MIDP имеет пакет javax.microedition.io, который поддерживает сетевую работу и коммуникации в приложениях MIDP. Этот пакет отличается от пакета java.net J2SE, который определяет поддержку сетевой работы на данной платформе.

Приложения MIDP используют типы javax.microedition.io для создания и работы с различными видами сетевых соединений. Затем они считывают данные с этих соединений и записывают в них с помощью типов пакета java.io MIDP, который содержит подмножество классов и интерфейсов пакета java.io J2SE.

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

Cтpyктypa общих соединений MIDP

Структура общих соединений MIDP определяет инфраструктуру, которая обобщает детали определенных сетевых механизмов, протоколов и их реализаций приложения. В модели структуры общих соединений приложение делает запрос блоку соединения (connector) на создание соединения с указанным ресурсом. Чтобы создать соединение, вы используете адрес общего вида для указания сетевого ресурса. Форма адреса одинакова, независимо от типа соединения.

Блок соединения представляет собой текущее соединение, работающее как общее соединение. То есть оно характеризует соединение как соединение, которое имеет наименьший средний показатель атрибутов и поведения всех типов соединений.

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

В модели общего соединения MIDP вы определяете ресурс и получаете подключение к нему за один этап. Это отличает ее от модели J2SE, где приложение должно привлечь два объекта: один, представляющий сам указанный ресурс, и второй, являющийся потоком или соединением с ним.

Например, чтобы получить доступ к URL в J2SE, приложение создает объект Java,net.URL, который представляет собой ресурс действующего URL. Используя этот объект, приложение затем явно открывает соединение с ресурсом URL, который вырабатывает объект URL-соединения. Этот объект представляет собой текущее соединение между приложением и ресурсом и предоставляет механизм, с помощью которого приложение получает доступ к содержимому ресурса. Теперь приложение может получать входящий поток соединения, которое поставляет содержимое ресурса.

Класс URL знает, как получать доступ к физическому ресурсу. Объект соединения, с другой стороны, ничего не знает об обнаружении и открытии URL, но он знает, как соединяться с объектом URL. Программист должен понимать, какой объект использовать для доступа URL и какое соединение или поток связан с ним.

В общем, модель J2SE требует от программиста создания потока, который совместим с типом ресурса, к которому получен доступ – URL, файл, сетевой канал, дейтаграмма и так далее. Модель J2SE не извлекает этих подробностей из приложения.

В модели MIDP потоки ведут себя так же, как и в модели J2SE, они все еще не знают ничего о текущем физическом сетевом ресурсе. Они просто знают, как управлять содержимым, предоставленным им, при создании их экземпляра. Блок соединения, однако, скрывает от приложения подробности установления связывания потока с текущим сетевым ресурсом.

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

Чтобы использовать структуру общих соединений, приложения MIDP указывают сетевой ресурс, к которому они хотят получить доступ, используя универсальный идентификатор ресурса (universal resource identifier (URI)), за которым следует синтаксис стандартного URI Интернета, определяемого RFC 2396. URI поддерживает классический синтаксис для идентификации ресурсов в Интернете. Общая форма URI следующая

<схема>://<адрес;<параметры>

Частью URI является его поле схемы, которое представляет собой протокол, используемый для соединения. RFC 2396 поддерживает множество действующих схем, таких, как as file, datagram, socket, serversocket, http, ftp и так далее.

CLDC не определяет поддержку каких-либо из них. Причина этого заключается в том, что спецификация CLDC не позволяет ручной настройки. Поэтому все реализации CLDC должны поддерживать одни и те же свойства. Реализации MIDP, однако, могут реализовать так много настроек, сколько пожелаете. Однако спецификация MIDP требует, чтобы реализации поддерживали, по крайней мере, протокол HTTP 1.1. Несколько факторов влияют на доступность поддержки протоколов в реализациях MIDP:

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

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

– Порталы беспроводного Интернета делают использование HTTP своим основным механизмом взаимодействий на уровне приложений.

Реализация платформы MIDP предоставляет действующую реализацию поддержки протоколов. Эти реализации протоколов не являются частью определений MIDP или CLDC. Они представляют собой зависящие от реализации компоненты, указанные в главе 1.

Блоки соединения и соединения

На рисунке 8.1 представлено схематичное изображение этапов, входящих в процесс создания и использования соединения. Эти этапы, которые мы перечислим позже, соотносятся с условным обозначением, показанным на рисунке 8.1.

Объект соединения содержит входной и выходной потоки для считывания и записи данных для ресурса, соответственно. На рисунке 8.1 схематично представлены взаимосвязи между соединением и его двумя потоками.

Рисунок 8.1. Производящий соединения блок создает соединения с сетевыми ресурсами, анализируя поле схемы URI и привлекая помощь определенных сетевых классов для создания соответствующего типа транспортного механизма

– Приложение запрашивает класс Connector для открытия соединения с сетевым ресурсом.

– Фабричный метод Connector.open() анализирует URI и возвращает объект Connection. Полученный объект Connection содержит ссылки на входной и выходной потоки к сетевому ресурсу.

– Приложение получает объект InputStream или OutputStream из объекта Connection.

– Приложение считывает данные из InputStream или записывает их в OutputStream в процессе своей обработки.

– Приложение закрывает Connection при завершении работы

Когда у вас установлено соединение, вы используете два потока для взаимодействия с сетевым ресурсом. Существует два аспекта при коммуникации с сетевым ресурсом

– анализ сообщения протокола;

– анализ полезной нагрузки сообщения – содержимого сообщения.

Например, если клиент устанавливает HTTP-соединение, он должен проанализировать синтаксис и семантику ответного сообщения протокола HTTP, возвращенного сервером. Сообщение HTTP передает некоторого рода содержимое, и клиент должен быть способен проанализировать содержимое соответствующим образом. Если, например, содержимое сообщения является данными HTML, клиент должен соответственно анализировать HTML содержимое. Если приложение не знает формата данных, переданных входящим потоком, оно не сможет правильно интерпретировать либо синтаксис, либо семантику содержимого потока.

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

Классы и интерфейсы cтpyктypы общих соединений

Пакет javax.microedition.io определяет один класс и набор интерфейсов, которые представляют различные типы содержимого соединений. Класс Connector является единственным конкретным элементом в структуре общих соединений. Вы должны использовать его для получения текущих соединений с ресурсами. Он действительно содержит фабричный метод, который создает различные типы структур соединений для поддержки различных протоколов.

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

На рисунке 8.2 показана иерархия наследования интерфейсов MIDP, которые являются частью общей структуры соединений.

Рисунок 8.2. Каждый из типов соединений поддерживает определенный уровень абстракции, который отражается в каждом интерфейсе с помощью методов. Возможности увеличиваются, а абстрактность уменьшается по мере того, как вы двигаетесь вниз по иерархии. Все интерфейсы находятся в пакете javax.microedition.io

На самом верху иерархии находится интерфейс Connection. Как предполагает его название, он представляет наиболее общий, абстрактный тип соединения. Естественно, все остальные типы соединений происходят из него. Интерфейс Connection содержит только один-единственный метод

public void close ()

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

Прямые подинтерфейсы Connection представляют немного менее абстрактные типы соединений. По мере того как вы спускаетесь вниз с верхнего уровня иерархии соединений, интерфейс получает все большие возможности. Интерфейс InputConnection представляет поток данных соединения как InputStream, то есть поток данных с байтовой организацией. В таблице 8.1 показаны два его метода.

Таблица 8.1. Методы интерфейса InputConnection

Имя метода InputConnection – Описание

DatalnputStream openDatalnputStream () – Открывает и возвращает DatalnputStream, который соединяется с сетевым ресурсом, связанным с этим соединением

InputStream openlnputStream() – Открывает и возвращает InputStream, который соединяется с сетевым ресурсом, связанным с данным соединением

Эти методы возвращают типы объектов InputStream. Вспомните, что DatalnputStream является подклассом InputStream. Смысл заключается в том, что вы можете получить потоки, способствующие преобразованию данных в байтовые данные. Если вы желаете интерпретировать данные другим способом, ваша задача – создать подходящее «преобразование», которое позволит вам получать доступ и интерпретировать данные желаемым образом.

Интерфейс OutputConnection является еще одним подинтерфейсом Connection. Он работает с исходящими потоками и также определяет содержимое своих потоков как байтовые данные. Его методы показаны в таблице 8.2. Вы должны использовать этот интерфейс при записи байтовых данных в удаленный ресурс.

С помощью этих двух интерфейсов вы можете затем интерпретировать входящий или выходящий поток данных ресурса как последовательность необработанных байтов, анализируя их с помощью методов интерфейсов Datalnput или DataOutput. Конечно, вы должны знать формат данных, посылаемых устройством, или формат, ожидаемый устройством, соответственно. Другими словами, не существует абстракции данных, которая устраняет необходимость знать синтаксис и семантику данных в InputConnection или OutputConnection.

Таблица 8.2. Методы интерфейса OutputConnection

Имя метода OutputConnection – Описание

DataOutputStream openDataOutputStream () – Открывает и возвращает DataOutputStream, который соединяется с сетевым ресурсом, связанным с этим соединением.

OutputStream openOutputStream () – Открывает и возвращает OutputStream, который соединяется с сетевым ресурсом, связанным с этим соединением.

Потоковые соединения

Интерфейс StreamConnection происходит непосредственно из интерфейсов InputConnection и OutputConnection. Он наследует методы двух интерфейсов, описанных ранее в таблицах 8.1 и 8.2.

Интерфейс StreamConnection представляет соединение как поток данных в наиболее абстрактном смысле слова – как последовательность байтов. Это пустой интерфейс, он не привносит нового поведения в дополнение к любому из его двух вышестоящих интерфейсов. Тем не менее, его присутствие в иерархии необходимо для целей, лежащих за пределами обязанностей интерфейсов InputConnection и OutputConnection. Он работает как заполнитель, представляющий любой тип соединения, чьи данные могут быть обработаны как поток байтов.

Интерфейс StreamConnection извлекает подробную информацию о механизме соединения – протоколе, используемом в реализации определенного типа соединения, а также его синтаксисе и семантике. Например, J2ME Wireless Toolkit предоставляет две реализации StreamConnection – одну для соединения с портами связи, а другую для соединения с сокетами клиентов стиля Unix. Интерфейс StreamConnection определяет оба этих типа соединения как необработанные потоки данных без определения синтаксиса или семантики протокола. Реализации, однако, совершенно отличны. В данном разделе вы увидите, как настраивать соединение с коммуникационным портом. Затем вы узнаете, как настраивать соединение сокета.

Соединения с коммуникационными портами, как и все другие соединения, должны быть установлены путем передачи URI в Connector.open(). Вы должны указать адрес порта связи, который вы хотите открыть. Поле схемы должно иметь значение соггап, которое определяет соединение как потоковое соединение для коммуникационных портов. Полная форма адреса следующая:

address:= <схема>:<уэел>;

<параметры> cheme:= «coram»

unit:=

parameters:= <зависящие от устройства параметры конфигурации>

Например, вы могли открыть соединение с коммуникационным портом с помощью следующего оператора:

StreamConnection conn = Connector.open(«comm:0;baudrate=9600»);

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

Соединения содержимого соединений

Интерфейс ContentConnection дополняет интерфейс StreamConnection. Он уточняет понятие потокового соединения. Он определяет соединения, включающие содержимое, вместо представления их как простого потока необработанных байтов или потока, чья структура должна быть отмечена как приоритетная (priori).

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

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

Таблица 8.3. Методы интерфейса ContentConnection

Имя метода ContentConnection – Описание

String getEncoding() – Выдает значение поля, показывающего набор символов шифрования, используемых для представления содержимого сообщения

long getLength() – Выдает длину сообщения

String getType() – Выдает тип содержимого

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

Неудивительно, что интерфейс ContentConnection имеет один подинтерфейс, HttpConnection, который представляет соединения, использующие протокол HTTP. Интерфейс HttpConnection определяется MIDP, а не CLDC. HTTP является протоколом содержимого соединений уровня приложений. Вы, несомненно, понимаете, что три метода интерфейса ContentConnection, перечисленные в таблице 8.3, применимы к HTTP.

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

Таблица 8.4. Методы интерфейса HttpConnection

Название метода HttpConnection – Описание

long getDate () – Выдает значение поля заголовка даты

long getExpiration () – Выдает значение поля заголовка Expires

String getFile () – Выдает значение поля URL данного соединения

String getHeaderField (int n) – Выдает значение части пронумерованного поля заголовка ключ-значение

String getHeaderField (String name) – Выдает значение поля заголовка с указанным именем ключа. В качестве аргумента приемлемо любое действительное имя поля HTTP

long getHeaderFieldDate (String name, long def) – Выдает значение (анализируемое как дата) поля заголовка с указанным ключом

int getHeaderFieldlnt (String name, int def) – Выдает значение (анализируемое как целое) названного поля заголовка

String getHeaderFieldKey (int n) – Выдает часть ключа пронумерованного поля заголовка

String getHost () – Выдает часть HOST URL данного соединения

long getLastModified () – Выдает значение поля LastModified URL.

int getPort () – Выдает значение поля порта URL данного соединения

String getProtocol () – Выдает имя протокола URL

String getQuery () – Выдает область запроса URL, часть после первого"?" в URL

String getReff () – Выдает часть ссылки URL

String getRequestMethod () – Выдает метод текущего запроса

String getRequestProperty (String key) – Выдает значение указанного свойства общего запроса

int getResponseCode () – Выдает код состояния отклика v HTTP

String getResponseMessage () – Выдает сообщение отклика HTTP, связанное с кодом состояния отклика

String getURL () – Выдает строковую форму URL

void setRequestMethod (String method) – Устанавливает метод для URL; приемлемыми значениями являютсяGET, POST И HEAD

void setRequestProperty (String key, String value) – Устанавливает значение указанного свойства общего запроса

В дополнение к этим методам интерфейс HttpConnection также определяет полную совокупность констант, представляющих коды статуса и ошибок HTTP, которые показаны в таблице 8.5. Для получения дополнительной информации о константах кода статуса смотрите HTTP 1.1, спецификацию RFC2616, которую можно найти по адресу http://www.w3c.org или на http://www.ietf.org.

Таблица 8.5. Определения констант интерфейса HttpConnection

Константа HttpConnection – Описание

static String GET – Представляет метод запроса GET

static String HEAD – Представляет метод запроса HEAD

static int HTTP_ACCEPTED – HTTP статус 202

static int HTTP_BAD_GATEWAY – HTTP статус 502

static int HTTP_BAD_METHOD – HTTP статус 405

static int HTTP_BAD_REQUEST – HTTP статус 400

static int HTTP_CLIENT_TIMEOUT – HTTP статус 408

static int HTTP_CONFLICT – HTTP статус 409

static int HTTP_CREATED – HTTP статус 201

static int HTTP_ENTITY_TOO_LARGE – HTTP статус 413

static int HTTP_EXPECT_FAILED – HTTP статус 41 7

static int HTTP_FORBIDDEN – HTTP статус 403

static int HTTP_GATEWAY_TIMEOUT – HTTP статус 504

static int HTTP_GONE – HTTP статус 410

static int HTTP_INTERNAL_ERROR – HTTP статус 500

static int HTTP_LENGTH_REQUIRED – HTTP статус 41 1

static int HTTP_MOVED_PERM – HTTP статус 301

static int HTTP_MOVED_TEMP – HTTP статус 302

static int HTTP_MULT_CHOICE – HTTP статус 300

static int HTTP_NO_CONTENT – HTTP статус 204

static int HTTP_NOT_ACCEPTABLE – HTTP статус 406

static int HTTP_NOT_AUTHORITATIVE – HTTP статус 203

static int HTTP_NOT_FOUND – HTTP статус 404

static int HTTP_NOT_IMPLEMENTED – HTTP статус 501

static int HTTP_NOT_MODIFIED – HTTP статус 304

static int HTTP_OK – HTTP статус 200

static int HTTP_PARTIAL – HTTP статус 20В

static int HTTP_PAYMENT_REQUIRED – HTTP статус 402

static int HTTP_PRECON_FAILED – HTTP статус 412

static int HTTP_PROXY_AUTH – HTTP статус 407

static int HTTP_REQ_TOO_LONG – HTTP статус 414

static int HTTP_RESET – HTTP статус 205

static int HTTP_SEE_OTHER – HTTP статус 303

static int HTTP_TEMP_REDIRECT – HTTP статус 307

static int HTTP_UNAUTHORIZED – HTTP статус 401

static int HTTP_UNAVAILABLE – HTTP статус 503

static int HTTP_UNSUPPORTED_RANGE – HTTP статус 416

static int HTTP_UNSUPPORTED_TYPE – HTTP статус 41 5

static int HTTP_USE_PROXY – HTTP статус 305

static int HTTP_VERSION – HTTP статус 505

static String_HTTP_POST – Представляет метод запроса POST

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

В листингах с 8.1 по 8.4 показан исходный код для простой программы, которая демонстрирует, как пользователь мобильного устройства может запрашивать ресурс HTTP с удаленного сервера. Вы можете найти, что эта программа не работает при выполнении за пределами вашего корпоративного брандмауэра, в зависимости от конфигураций сети вашей компании, брандмауэра и прокси-сервера. Вы можете быть ограничены до посещения URI ресурсов, расположенных в пределах вашей корпоративной сети.

Протокол HTTP определяет семантику, связанную с тем, что клиентам необходимо запрашивать ресурсы через прокси-сервер. Браузер может изменять URI пользователя, основываясь на настройках его прокси, и посылать измененный запрос на прокси-сервер, который перенаправляет его на исходный сервер. Программа не делает таких изменений URI, и поэтому она не может пересылать URI, как ожидается вашим прокси-сервером. Если вы не знаете, как браузер изменяет URI, у вас могут возникнуть сложности при доступе к URI, являющимся внешним по отношению к вашей корпоративной сети. Результат выразится в том, что программа, показанная в листинге 8.1, сбросит lOException.

Программа, показанная в листинге 8.1, отображает только метаинформацию о запрошенных ресурсах и не отображает сам ресурс. Она лишь запрашивает информацию заголовка для каждого ресурса, используя метод HEAD HTTP. Написание программы, которая отображала бы произвольное содержимое, было бы равноценно написанию целого браузера, что, очевидно, лежит за пределами темы данной книги. К счастью, некоторые компании предлагают HTTP-браузеры, которые работают на устройствах MIDP, так что вам не придется проделывать эту огромную работу.

Листинг 8.1. Программа ConnectionDemo определяет MID-лет, который отображает мета-информацию протокола HTTP, а именно значения полей заголовка HTTP. Программа использует команду HEAD для получения лишь мета информации, а не всей страницы