Блоки прослушивания записей
Приложения имеют способность получать уведомления при добавлении записи, ее удалении или изменении в хранилище записей. Класс RecordStore позволяет вам добавлять и удалять блоки прослушивания записей из определенного хранилища данных с помощью методов, перечисленных в таблице 7.2. Блок прослушивания записей является любым классом, реализующим интерфейс RecordListener, определенный в пакете javax.microedition.rms. Он объявляет три метода, показанных в таблице 7.3.
Cпиcки
Существует на самом деле два способа извлечения записей из хранилища данных:
Извлечение отдельной записи с помощью ее уникального ID;
Извлечение списка записей и выбор из них одной или нескольких нужных вам записей.
Чтобы извлечь определенную запись, вы можете использовать следующий метод класса RecordStore:
byte [] getRecord(int recordld)
Этот метод, очевидно, требует, чтобы вы знали уникальный ID записи, которую вы хотите извлечь. К сожалению, это означает, что вам, возможно, придется хранить ID где-нибудь в легкодоступном месте после того, как он будет выдан вам методом addRecord (). Это не всегда удобно или практично при большом количестве записей.
Самый легкий способ найти записи, которые вам нужны, - это использовать списки, которые поддерживаются классом RecordStore. Список весьма удобен при извлечении записей, если вы не знаете ID записей, которые вам нужны. Вы можете создать список записей, хранящихся в хранилище записей, а затем исследовать его, выбрав одну или несколько записей, которые вам нужны.
Класс RecordStore определяет метод
RecordEnumeration
enumerateRecords(RecordFilter filter,
RecordComparator comparator,
boolean keepUpdated)
который выдает список записей в хранилище записей. В листинге 7.2 показан исходный код RecordList.Java. Этот класс создает и отображает список всех записей адресной книги. Обратите внимание, что для того, чтобы извлекать записи, ID записей указывать не нужно.
Фильтры записей
Следующий пример не осуществляет поиска определенных записей. Однако существует способ, при котором вы можете использовать списки для извлечения некоторого подмножества записей хранилища. Вы можете использовать списки для вывода записей, которые удовлетворяют некоторым критериям, которые вы указали.
Первый аргумент в методе enuraerateRecords() указывает фильтр записей. Фильтр является объектом, определяющим семантику соответствия записи набору критериев, которые определяют, должна ли запись включаться в набор списка.
Фильтр записей является классом, реализующим интерфейс RecordFilter, который определяется в пакете javax.microedition.rms. Этот интерфейс определяет единственный метод boolean matches (byte [] candidate). Ваш подкласс RecordFilter задает этот метод и устанавливает критерии фильтрации записей, указанных в списке всех записей хранилища записей. Метод enumerateRecords() активизирует вашу реализацию на каждой записи, извлеченной из хранилища записей.
В листинге 7.3 показан код класса SearchScreen. Java. Он ищет записи, которые начинаются с подстроки, введенной пользователем, или эквивалентные указанной пользователем строке.
Компараторы записей
Вы, несомненно, заметили, что второй аргумент, пересланный в enumerateRecords () в предыдущих примерах, был равен нулю. Этот второй параметр является «заполнителем» для компаратора записей. Компаратор записей - это объект, который сравнивает две записи для определения их упорядочивания или сортировки. Компараторы предоставляют приложениям возможность выполнять различную сортировку.
Как и фильтры, компараторы определяют семантику функции сравнения. Компаратор записей является реализацией интерфейса RecordComparator, который определяет единственный метод
int ccmparefbyte [] recordl, byte [] record2)
Компаратор также определяет три константы, описанные в таблице 7.1, которые ваша реализация должна использовать как текущие выводимые значения данного метода.
Класс AddressBook позволяет приложению получать доступ к хранилищу записей
import javax.microedition.rms.RecordComparator;
import javax.microedition.rms.RecordEnumeration;
import javax.microedition.rms.RecordFilter;
import javax.microedition.rms.RecordStore;
import javax.microedition.rms.RecordStoreException;
import javax.microedition.rms.RecordStoreNotOpenException;
import Java.io.ByteArrayInputStream/
import java.io.ByteArrayOutputStream;
import Java.io.DatalnputStream;
import java.io.DataOutputStream;
import Java.io.lOException;
/**
Этот класс внедряет простую адресную книгу с целью демонстрации.
В нем хранятся записи, состоящие из полей имени String и номера телефона String.
Этот класс определяет два внутренних класса,
один является блоком сравнения записей, а второй фильтром записей,
используемым при извлечении записей.
*/
public class AddressBook
private static final String RECORD_STORE_NAME = "address-book";
private RecordStore recordStore;
public AddressBook () throws RecordStoreException
super!);
recordStore = RecordStore.openRecordStore(RECORD_STORE_NAME, true);
{
void close() throws RecordStoreException
{
try
{
recordStore.closeRecordStore();
}
catch (RecordStoreNotOpenException rsno)
{
}
}
/*
Получает хранилище записей, используемое этим объектом.
@возвращаем ссылку на RecordStore, используемый э.тим объектом.
public RecordStore getRecordStore()
}
return recordStore;
/**
Добавляет указанную запись в хранилище записей данной адресной книги.
@param name имя входа было добавлено.
@parara phone телефонный номер для входа был добавлен.
@сбрасывает RecordStoreException, если есть проблемы с добавлением записи.
public void addRecord(String name, String phone)
throws RecordStoreException
}
ByteArrayOutputStreara baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
try
dos.writeUTF(name);
dos.writeUTF(phone);
}
catch (lOException ioe)
{
ioe.printStackTracef);
)
int id =
recordstore.addRecord(baos.toByteArray(), 0,
baos.toByteArrayO .lengthy-System, out.
println ("Record id = " + id);
}
/**
RecordEnumerator, упорядочивающий записи в
лексикографическом порядке по полям
имен записей.
*/
RecordEnumeration getMatchesByNarae(String matchKey)
throws RecordStoreNotOpenException
(
MacchAllNaraesFilter filter =
new MatchAllNamesFilter(matchKey);
AlphabeticalOrdering comparator =
new AlphabeticalOrdering();
return recordStore.enuraerateRecords(filter,
comparator, false);
}
/**
RecordFilter, устанавливающий совпадение, если имя варианта
(первое поле в записи варианта)!) точно соответствует имени
элемента списка или 2) если строка имени элемента списка
начинается с имени варианта. Возвращает значение true, ее
установлено соответствие, false - в ином случае.
*/
class MatchAllNamesFilter implements RecordFilter
{
String requestString;
public MatchAllNamesFilter(String matchKey) ;
requestString = matchKey;
}
public boolean matches(byte [] candidate)
{
ByteArraylnputStream bais =
new ByteArraylnputStream(candidate);
DatalnputStream dis = new DatalnputStream(bais);
Siring name = null;
try
}
name = dis.readUTF();
if (name.indexOf(requestString) == 0)
return true;
else
return false;
}
catch (lOException ioe)
{
ioe.printStackTrace!);
return true;
}
}
/**
Этот внутренний класс реализует RecordCornparator, чья политика
Заключается в выполнении сортировки по алфавиту.
*/
class AlphabeticalOrdering implements RecordCoraparator
}
Конструктор.
public AlphabeticalOrdering ()
(
)
public int compare(byte [] reel, byte [] rec2)
{
ByteArraylnputStream baisl =
new ByteArraylnputStream(recl);
DatalnputStream disl = new DatalnputStream(baisl);
ByteArraylnputStream bais2 =
new ByteArraylnputStream(rec2);
DatalnputStream dis2 = new DatalnputStream(bais2);
String namel = null; String name2 = null; try
namel = disl.readUTF ();
name2 = dis2.readUTF () ;
}
catch (lOException ioe)
ioe.printStackTrace();
}
if (namel == null II name2 == null) return 0;
int result = namel.compareTo(name2);
if (result < 0)
return RecordCornparator. PRECEDES;
else if (result == 0)
return RecordCoraparator.EQUIVALENT;
else
return RecordComparator.FOLLOWS;
}
}
/**
Удаляет все записи из хранилища данных.
В текущих реализациях самый быстрый способ удаления всех записей
заключается в удалении хранилища данных и повторном его создании,
вместо удаления каждой записи по очереди!
void deleteAHRecords ()
}
try
RecordEnumeration re =
recordStore.enumerateRecords(null, null, false);
while (re.hasNextElement())
*/
int id = re.nextRecordld();
recordStore.deleteRecord(id);
}
}
catch (RecordStoreException rse)
{
rse.printStackTracel);
} }
/**
Получает статистику хранилища данных, используемого данной адресной книгой.
/**
возвращает String статистических данных.
*/
public String getStatistics ()
{
int numRecords = 0;
int space = 0;
StringBuffer stats = new StringBuffer("Records:
*/
try
{
numRecords = recordStore.getNumRecords ();
space = recordStore.getSizeAvailable();
)
catch (RecordStoreException rse)
(
rse.printStackTrace();
}
stats.append(String.valueOf(nuraRecords));
stats.append("\n\n") ;
stats.append("Available bytes: ");
stats.append(String.valueOf(space));
return stats . toString();
}
}
Обратите внимание, что класс AddressBook определяет член типа RecordStore. Это экземпляр действительного хранилища записей, используемого приложением. Класс RecordStore является единственным открыто объявляемым классом в пакете RMS. Он определяет абстракцию хранилища записей.
Конструктор AddressBook сбрасывает RecordStoreException, поскольку метод openRecordStore() может сбрасывать три исключения, которые происходят от него. Пакет javax.microedition.rras определяет пять исключений. На рисунке 7.2 показана иерархия наследования, которая содержит типы исключений RMS.
Списки дают вам возможность
import javax.microedition.midlet.MIDlet;
import javax.microedition.lcdui.Alert;
import javax.microedition.lcdui.AlertType;
import javax.microedition.lcdui.Command;
import javax.microedition.lcdui.CommandListener;
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.List;
import javax.microedition.rms.RecordEnumeration;
import javax.microedition.rms.RecordStore;
import javax.microedition.rms.RecordStoreException;
import java.io.ByteArraylnputStream;
import Java.io.DatalnputStream; import Java.io.lOException;
/**
Этот класс является компонентом пользовательского интерфейса,
отображающим список записей, находящихся в хранилище записей.
Он использует объект AddressBook, определенный классом MID-лета
для данного приложения MID-лета.
@смотри AddressBook
@смотри AddressBookMain
*/
public class RecordList extends List
implements CommandListener
{
private static Command go =
new command("Go", Command.SCREEN, 1);
private static Command back =
new Command("Back", Command.BACK, 1);
private Display display;
private static RecordList instance;
/**
Конструктор.
@param title название экрана пользовательского интерфейса,
который является List.
*/
public RecordList (String title)
superltitle, List.IMPLICIT);
instance = this;
PersistenceDemo pDemo = PersistenceDemo.getlnstance ();
display = Display .get-Display (pDemo) ;
addCommand(back);
setCommandListener (this);
if (buildRecordList() <= 0) setTitle("No records found");
}
/""
Возвращает один экземпляр данного класса.
Вызов этого метода перед созданием объекта возвращает нулевой указатель.
@возвращает экземпляр данного класса.
*/
public static RecordList getlnstance()
}
return instance;
}
void display ()
{
display.setCurrent (this);
{
/**
Создает список записей, хранящихся в хранилище записей. Выдает число найденных записей. Этот метод извлекает все записи из хранилища записей, то есть он не использует фильтров для извлечения записей.
Он также не использует компараторов записей, так что не упорядочивает выводимые записи.
<р>
Этот метод не сбрасывает исключений, но находит исключения,
которые происходят при доступе к хранилищу записей.
(@возвращает число записей, найденных в хранилище записей,
или 0, если записей не найдено.
*/
int buildRecordList ()
{
AddressBook addressBook =
AddressBookMain.get Instance!).getAddressBook();
RecordStore recordStore = addressBook.getRecordStore();
int numRecords = 0; try
RecordEnuraeration re;
re = recordStore.enumerateRecords(null,
null, false);
if (re.numRecords() >
0)
{
ByteArraylnputStream bais = null;
DatalnputStreara dis = null;
String name = null;
while (re.hasNextElement())
byte [] record = re.nextRecord();
bais = new ByteArraylnputStream(record);
dis = new DatalnputStrearn (bais ) ;
String strRec = new String(record);
name = dis . readUTFO ;
appendfname, null ;
numRecords++;
)
)
else
}
Alert a = new Alert("No records",
"No records found in record store", null,
AlertType.CONFIRMATION);
a.setTimeout(Alert.FOREVER);
display.setCurrent (a, AddressBookMain.get Instance ());
} )
catch (RecordStoreException re)
re.printStackTrace();
Alert a = new Alert("Error retrieving record",
"Error retrieving record.", AlertType.CONFIRMATION);
a.setTimeout(Alert.FOREVER);
display.setCurrent (a, this);
catch (lOException ioe)
}
ioe.printStackTrace();
}
finally
{
return numRecords;
{
public void coramandAction(Command c, Displayable d)
if (c == back)
AddressBookMain.getlnstancel).display ();
}
}
}
Метод buildRecordList() использует составление списка для получения всех записей, хранящихся в хранилище записей, а затем извлекает поле имени каждой из них, чтобы создать список всех имен. Вызов enumerateRecords () выдает RecordEnumeration, содержащий все записи. С помощью методов hasNextRecord() и nextRecord() цикл while просто извлекает имена из каждой записи и добавляет их в объект List для отображения.
Для каждой записи вы должны расшифровать байтовый массив обратно тому процессу, согласно которому вы создали запись ранее. Вы знаете, что первый элемент, имя, является string, так что вы можете преобразовать его из байтов в String. Обратите внимание, что та же самая идиома потока ввода-вывода Java используется здесь для создания DatalnputStream, который поддерживает API для легкого преобразования встроенных типов Java.
Поиск имен, которые
import javax.microedition.lcdui.Command;
import javax.microedition.lcdui.CommandListener;
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.Form;
import javax.microedition.lcdui.TextField;
import javax.microedition.rms.RecordEnumeration;
import javax.microedition.rms.RecordStoreException;
import Java.util.Enumeration;
import Java.util.Vector;
/**
Этот класс внедряет экран, который дает возможность пользователю искать одну
или несколько определенных записей в адресной книге. Пользователь вводит имя
или префикс, который представляет имя одной или нескольких записей
в адресной книге.
*/
public class SearchScreen extends Form
implements CommandListener
{
private static Command go =
new Command("Go", Command.SCREEN, 1);
private static Command back = new Command("Back", Command.BACK, 1);
private static SearchScreen instance; private Display display;
private AddressBookMain addressBook; private TextField keyEntry;
/**
Конструктор.
*/
public SearchScreen(}
(
super("Search for entry");
instance = this;
PersistenceDerao pDemo = PersistenceDemo.getlnstance () ;
display = Display .getDisplay (pDerno) ;
addressBook = AddressBookMain.getlnstance ();
keyEntry = new TextField("Enter name",
null, 20, TextFieid.ANY);
append(keyEntry);
addCommand(go);
addCommand(back);
setCoramandListener(this);
}
/**
Возвращает один экземпляр данного класса.
Вызов данного метода до создания объекта возвращает нулевой указатель.
/**
возвращает экземпляр данного класса.
**/
public static SearchScreen getlnstance ()
return instance; ) void display!)
( display.setCurrentlthis) ;
}
/**
Отображает данные, переданные на экран.
На самом деле этот метод передает обязанности по отображению
данных экземпляру SearchResultScreen. Этот метод,
однако, устанавливает новый экземпляр данного класса на текущее отображение.
Затрата выражается в Vector записей из хранилища записей адресной книги.
*/
void displaySearchResults(Vector results)
SearchResultScreen screen =
new SearchResultScreen (results);
display. setCurrenJ: (screen) ;
)
Создает конечный набор записей, соответствующих указанному имени.
Критерии отбора заключаются в том, что запись должна
соответствовать имени, введенному
пользователем в TextField "keyEntry". Этот метод задействует метод
AddressBook.getMatchesByName() для применения специального фильтра,
определяющего соответствие этого имени.
*/
Vector buildSearchResults()
{
AddressBook addressBook =
AddressBookMain.getInstance().getAddressBookf);
String matchKey = keyEntry.getString();
Vector results = new Vectorf);
try
{
RecordEnuraeration re =
addressBook.getMatchesByName(matchKey);
byte [] record = null;
while (re.hasNextElement())
record = re.nextRecord () ; results.addElement(record);
}
}
catch (RecordStoreException rse)
}
rse.printStackTracet) ;
)
return results;
)
/**
Создает результаты поиска и отображает их на экране.
class BuildSearchResultsAction implements Runnable
{
public void run ()
Vector results = buildSearchResults ();
displaySearchResults(results) ;
}
}
public void commandAction(Command c, Displayable d) ;
if (c == go)
Runnable action = new BuildSearchResultsAction();
action.run () ;
)
else if (c == beck)
}
AddressBookMain.getInstanced.display!);
}
}
}
Метод buildSearchResults() в классе SearchScreen получает список записей, вызывая метод getMatchesByName (String matchKey) в классе AddressBook. Этот метод фильтрует записи для вывода лишь тех, в которых поле имени начинается с matchKey.
Метод getMatchesByName () выполняет эту фильтрацию, пересылая фильтр записей как первый аргумент в метод enumerateRecords (). Экземпляр MatchAllNamesFilter определяет семантику фильтра для нахождения всех записей, которые начинаются с подстроки matchKey.
Метод enumerateRecords () обращается к следующему методу объекта фильтра для каждой записи в хранилище:
boolean matches(byte [] candidate)
Если в результате выводится true, он включает эту запись в набор списка. Теоретически это сходно с определением запроса SQL в системе родственных баз данных. Объект RecordFilter определяет критерии поиска.
Обратите внимание, что в листинге 7.2 аргумент RecordFilter был равен нулю. Таким образом класс RecordList может вывести все записи в списке, фильтр не применяется.
Вы можете описать несколько фильтров для поддержки поиска по различным критериям. Следуя программе листинга 7.4, вы можете определить несколько внутренних классов, которые реализуют RecordFilter и используют внутренний класс, соответствующий осуществляемому поиску.
Этот компаратор записей
/*'*
Этот внутренний класс реализует RecordComparator,
чья политика заключается в выполнении сортировки по алфавиту.
*/
class AlphabeticalOrdering implements RecordComparator
/**
Конструктор No-arg.
*/
public AlphabeticalOrdering()
}
super();
)
public int comparelbyte [] reel, byte [] rec2)
ByteArraylnputStream baisl =
new ByteArraylnputStream(reel);
DatalnputStream disl = new DatalnputStream (baisl);
ByteArraylnputStream bais2 -
new ByteArraylnputStream(rec2);
DatalnputStream dis2 = new DatalnputStream(bais2);
String namel = null;
String name2 = null; try
(
namel = disl.readUTF ();
name2 = dis2.readUTF () ;
catch (lOExceotion ioe)
ioe.pnntStackTrace () ;
}
if (namel == null I| name2 == null) return 0;
int result = namel.compareTo(narae2);
if (result < 0)
return RecordComparater.PRECEDES;
else if (result == 0)
return RecordComparator.EQUIVALENT;
else
return RecordComparator.FOLLOWS;
}
}
Ваша адресная книга может использовать этот новый компаратор для лексикографической сортировки списка имен, извлеченных из хранилища записей. Например, чтобы отсортировать имена, выведенные поиском, вы просто создаете экземпляр вашего нового компаратора и пересылаете его как второй аргумент в вызов enumerateRecords (). Следующий фрагмент кода, показанный в листинге 7.5, является новой версией вызова метода getMatchesByName(String matchKey) в классе AddressBook.
Чтобы осуществить
RecordEnumeration getMatchesByName(String matchKey)
throws RecordStoreNotOpenException
{
MatchAllNaraesFilter filter =
new MatchAHNamesFilter (matchKey) ;
AlphabeticalOrdering comparator =
new AlphabeticalOrdering();
return recordStore.enumerateRecords(filter,
comparator, false) ;
}
Вы можете запустить это приложение и определить для себя, какие из записей, выведенных в результате поиска, теперь будут отсортированы лексикографически. Вы также можете использовать этот компаратор для сортировки имен, выводимых в List функцией ввода адресной книги. Вместо пересылки null как для фильтра, так и для компаратора перешлите экземпляр компаратора AlphabeticalOrdering при извлечении списка всех записей.
Модель хранения данных RMS
RMS поддерживает создание множества хранилищ записей, показанных на рисунке 7.1, и управление ими. Хранилище записей - это база данных, основным понятием которой является запись. Каждое хранилище записей содержит ноль или больше записей. Название хранилища записей чувствительно к регистру и может состоять максимум из 32 знаков уникода. Хранилище записей создается МШ-летом.
Поддержка постоянного хранения устройством
Каждое соответствующее требованиям MIDP устройство поддерживает выделенную область памяти для постоянного хранения данных приложения. Данные MID-лета, хранящиеся там, постоянно существуют при множестве инициализаций приложения, которое их использует. Как физическое местоположение, так и размер хранилища данных зависят от устройства.
RMS API извлекает подробную информацию об области хранения устройства и доступе к этой информации, а также предоставляет единообразный механизм для создания, уничтожения и изменения данных. Это гарантирует переносимость MID-летов на различные устройства.
Пример приложения
В остальной части этой главы описываются частные подробности RMS с помощью следующего примера, использующего базовые свойства RMS. Этот пример является простой адресной книгой, которая хранит имена и номера телефонов.
Многие из примеров имеют дело с созданием организации и структуры приложений MIDP. Большинство протекающих операций RMS ограничены одним классом. В этом примере вы можете видеть, как включать использование постоянного хранения в приложение, которое вы, вероятно, найдете на настоящем мобильном устройстве.
Конечно, вы можете создать и исполнить исходный код, приведенный в этой главе, для получения представления о том, как приложение продвигается вперед по различным экранам. Я оставляю это на ваше усмотрение вместо того, чтобы показывать вам здесь изображения всех этих экранов.
Следующие файлы включены в адресную книгу, описанную в данном примере:
AddScreen.java;
AddressBook.java;
AddressBookMain.java;
DeleteAllConfirmationScreen.java;
PersistenceDemo.java;
RecordList.java;
SearchResultScreen.java;
SearchScreen.java.
Подробные листинги этих файлов можно найти на Web-сайте «Prentice-Hall» по адресу http://www.phptr.com. Файл PersistenceDemo.java определяет MID-лет, который представляет меню, содержащее приложение адресной книги. Файл AddressBookMain.java определяет точку входа в приложение адресной книги.
В листинге 7.1 показан полный исходный код класса AddressBook.java. Этот класс извлекает подробную информацию о вызовах RMS API из остальной части МID-лета. При инициализации MID-лета он создает экземпляр класса AddressBook, который, в свою очередь, открывает хранилище записей с именем addressbook.
Работа с данными byte [ ]
Как уже упоминалось выше, приложение в этом примере работает с записями, которые содержат имя и номер телефона. Пользователь вводит как имена, так и телефонные номера как объекты String, поскольку экран ввода данных использует экземпляры класса TextField, описанный ранее в главе 5. Соответственно, метод addRecord () получает эти значения String и преобразует их в байты.
Так или иначе, эти значения должны быть преобразованы в один массив байтов перед добавлением в хранилище данных. Причина того, что вы должны выполнить это преобразование, заключается в том, что API RecordStore хранит записи только в виде однобайтового массива.
Метод addRecord () использует стандартную идиому ввода-вывода Java при создании DatalnputStream, который поддерживает запись встроенных типов Java в выходном потоке. Получающийся в результате байтовый массив затем добавляется в объект RecordStore.
Метод RecordStore.addRecord() возвращает int, которая представляет значение ID только что созданной записи. Ваше приложение может сохранить данный ID и использовать его при последующем извлечении записи. Но существует более интересный способ извлечения записей.
Различные свойства хранилищ записей
Класс RecordStore определяет несколько других свойств, которые полезны для приложений. В таблице 7.4 перечислены некоторые из других методов класса RecordStore и кратко описано их использование.
Константы RecordComparator
Константа | Описание | ||
public static int EQUIVALENT | Две записи эквивалентны в соответствии с семантикой сравнения | ||
public static int FOLLOWS | Запись 1 «больше», чем запись 2, в соответствии с семантикой сравнения | ||
public static int PRECEDES | Запись 1 «меньше», чем запись 2, в соответствии с семантикой сравнения |
Идея использования компараторов сходна с понятием фильтрации записей. Вы определяете класс, который реализует интерфейс javax.microedition.rras.RecordComparator. Вы передаете его экземпляр в вызов enumerateRecords (). Записи, извлеченные из хранилища записей, сравниваются друг с другом, по две одновременно, а затем сортируются в соответствии с результатами сравнения. Вы можете таким образом извлекать записи из списка в порядке, определяемом компаратором.
В листинге 7.4 демонстрируется использование компаратора записей. Он определяет новый внутренний класс класса AddressBook, который вы видели в листинге 7.1. Новый внутренний класс AlphabeticalOrdering реализует RecordComparator. Его метод сравнения извлекает поле имени из каждого параметра байтового массива и сравнивает их лексикографически (по словам).
Методы поддержки блока прослушивания событий RecordStore
Название метода RecordStore | Описание | ||
Void addRecordListener (RecordListener listener) | Делает указанный объект блоком прослушивания для данного хранилища записей | ||
Void removeRecordListener (RecordListener listener) | Удаляет указанный блок прослушивания как блок прослушивания данного хранилища записей |
Методы интерфейса RecordListener
Название метода RecordListener | Описание | ||
void recordAdded (RecordStore recordStore, int recordld) | Уведомляет блок прослушивания записей о том, что запись была добавлена в указанное хранилище записей с указанным ID | ||
void recordChanged (RecordStore recordStore, int recordld) | Уведомляет блок прослушивания записей о том, что запись с указанным ID была изменена в хранилище записей | ||
void recordDeleted(RecordStore recordStore, int recordld) | Уведомляет блок прослушивания записей о том, что запись с указанным ID была удалена из хранилища записей |
Возможность связывать блоки прослушивания с хранилищами записей означает, что ваши блоки прослушивания могут быть уведомлены об изменении любой записи в хранилище записей, к которому данные блоки прослушивания относятся. Необходимо переслать обратно информацию о задействованном хранилище записей, потому что ваш блок прослушивания может без труда регистрироваться более чем с одним хранилищем записей. Идея регистрации блока прослушивания записей сходна с идиомой, используемой любым другим блоком прослушивания событий, так что я не буду описывать здесь примеры кодов.
Методы класса RecordStore
Название метода | Описание | ||
void- closeRecordStore ( ) | Закрывает хранилище записей | ||
static void deleteRecordStore ( ) | Удаляет хранилище записей | ||
long getLastModif ied ( ) | Выдает время последней модификации | ||
String getNameO | Выдает название хранилища записей | ||
int getNumRecords () | Выдает число записей в хранилище | ||
byte [] getRecordfint recordld) | Извлекает запись по Ю | ||
byte [] getRecord(int recordld, byte [] buffer, int offset) | Получает запись и помещает ее в предоставленный буфер | ||
byte [] getRecordSize (int recordld) | Получает размер указанной записи | ||
int getSizef) | Выдает размер места (в байтах), которое занимает хранилище записей | ||
int getSizeAvailable ( ) | Выдает число оставшихся байтов, на которое хранилище записей может вырасти | ||
int getVersionf) | Выдает номер версии хранилища записей | ||
static String [] listRecordStores () | Выдает список всех хранилищ записей, доступных набору MID-летов | ||
static RecordStore openRecordStore (String name, boolean createlfNecessary) | Открывает указанное хранилище записей, создавая его, если оно не существует |
MIDP поддерживает постоянное хранение записей
Система управления записями (RMS) MIDP поддерживает постоянное хранение записей данных в зависимости от устройства. Класс RecordStore предоставляет API для постоянного хранения данных и извлекает подробную информацию о доступе к определяемым устройством областям хранения.
Хранилища записей определяются по именам, которые состоят максимум из 32 знаков уникода. Хранилища записей могут совместно использоваться MID-летами, находящимися в одном наборе MID-летов.
RMS определяет простую абстракцию базы данных, связанную с записями. Записи хранятся как массив байтов. Хранилище записей не имеет понятий встроенных типов Java.
Вы можете извлекать записи, предоставляя уникальный ID записи. Либо вы можете извлекать записи, получая список записей из RecordStore.
Списки необходимы для поиска записей в хранилище записей. Теоретически фильтры записей предоставляют своего рода механизм запросов. В связи с возможностью составления списков в RecordStore, фильтры записей поддерживают поиск только тех записей, которые соответствуют одному или нескольким критериям. Фильтр записей, класс, который реализует интерфейс RecordFilter, определяет критерии поиска.
Компараторы записей предоставляют возможность сортировки записей, извлекаемых из списка. Компараторы определяют политику сортировки и используются с механизмом составления списка. Реализация RecordComparator определяет семантику сортировки.
Блоки прослушивания записей являются блоками прослушивания, регистрирующимися с определенным хранилищем записей. Они дают возможность уведомления вашей программы об изменениях, вносимых в любую запись, находящуюся в хранилище записей.
Производительность является важной проблемой при доступе к хранилищу записей. Производительность современных реализаций RMS довольно низка. Разработчики приложений должны с осторожностью подходить к использованию RMS, применяя ее только тогда, когда это необходимо. Они должны рассматривать другие альтернативы постоянного хранения данных и сравнивать различные варианты.
Разработчики должны также измерять производительность их реализации RMS при запуске приложений, чтобы убедиться, что производительность приемлема для конечных пользователей. Бывало, что действующие приложения начинали работать слишком медленно из-за использования обновлений хранилища записей. Подтверждено, что перезапись приложений таким образом, чтобы все содержимое хранилища записей было загружено и перемещено, быстрее, чем выполнение обновлений в измененных элементах!
Записи
Запись является массивом байтов типа byte []. RMS не поддерживает описание или форматирование полей записи. Ваше приложение должно определять элементы данных записи и их формат.
Читатель записи поэтому должен знать формат, который использовался при ее создании. Поскольку запись является просто массивом байтов, приложения должны преобразовывать данные из произвольных типов в байты при создании записей, а затем преобразовывать их из байтов в типы при чтении данных.
Блоки соединения и соединения
На рисунке 8.1 представлено схематичное изображение этапов, входящих в процесс создания и использования соединения. Эти этапы, которые мы перечислим позже, соотносятся с условным обозначением, показанным на рисунке 8.1.
Объект соединения содержит входной и выходной потоки для считывания и записи данных для ресурса, соответственно. На рисунке 8.1 схематично представлены взаимосвязи между соединением и его двумя потоками.
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.
Дейтаграммные соединения и дейтаграммы
Интерфейс javax.microedition.io.DatagramConnecti.on дополняет Connection. Его положение в диаграмме иерархии наследования, показанной на рисунке 8.2, а также его название, предполагают, что дейтаграммные соединения являются на самом деле соединениями, хотя и отличными от других соединений потоков и содержимого соединений. В действительности интерфейс DatagramConnection описывает соединения, которые посылают и получают дейтаграммы через протокол дейтаграмм.
В мире сетевых технологий термин протокол дейтаграмм подразумевает облегченный протокол - протокол без установления состояний. Но само это отличие на самом деле не помогает объяснить его позицию в иерархии структуры общих соединений. Более правильно, вероятно, различать протоколы уровня приложений и низкоуровневые протоколы.
Термин протокол дейтаграмм обозначает протокол, который находится на более низком уровне в модели OSI, чем протоколы уровня приложений. Протоколы дейтаграмм переносят дейтаграммы, которые иногда называются пакетами. Эти протоколы обычно переносят сообщения дейтаграмм с одной машины на другую, основываясь исключительно на информации, содержащейся в этой дейтаграмме. Несколько пакетов, посланных с одной машины на другую, могут быть переданы по различным маршрутам и приходить на назначенный компьютер в любом порядке. Доставка пакетов в общем и целом не гарантирована.
Универсальный интернет-протокол передачи дейтаграмм (Internet Universal Datagram Protocol (UDP)) является одним конкретным примером протокола передачи дейтаграмм. В действительности это протокол, поддерживаемый некоторыми реализациями MIDP. Он встроен непосредственно поверх интернет-протокола (Internet Protocol (IP)) сетевого уровня. Помните, что в соответствии со спецификацией MIDP, HTTP 1.1 является единственным протоколом, который должны поддерживать реализации, все остальные - необязательно. Разработчики должны помнить об этом при учете портативности приложений.
Использование протокола UDP дает приложениям MIDP другой стандартный механизм для взаимодействия с четко определенными сетевыми службами.
В главе 11 вы узнаете о некоторых обстоятельствах, при которых использование протоколов передачи дейтаграмм является более предпочтительным, чем высокоуровневых протоколов.
В UDP отсутствуют многие свойства, которые имеются в транспортных протоколах, как, например, в TCP, такие, как согласование вариантов соединений, повторная сборка пакетов, сквозной контроль потока, управление окнами, устранение ошибок, разбиение на части и гарантированная доставка. Он отказывается от этих свойств в пользу очень эффективной быстрой пересылки. Приложения MIDP могут использовать дейтаграммные соединения, когда им нужны быстрые соединения без перехода из состояния в состояние и когда не требуется гарантированная пересылка.
В таблице 8.9 перечислены методы интерфейса DatagramConnection. Вы можете видеть, что это относительно простой интерфейс. Эта простота отражает низкоуровневую природу базового протокола реализации. Сравните это с интерфейсом HttpConnection, чьи методы отражают относительно более сложную природу сообщений протокола HTTP и используют поля сообщений типа MIME для определения семантики сообщения. В отличие от протоколов уровня приложений, таких как, HTTP, протоколы дейтаграмм не определяют атрибуты, которые отражают природу полезной нагрузки, которую они транспортируют.
Классы и интерфейсы cтpyктypы общих соединений
Пакет javax.microedition.io определяет один класс и набор интерфейсов, которые представляют различные типы содержимого соединений. Класс Connector является единственным конкретным элементом в структуре общих соединений. Вы должны использовать его для получения текущих соединений с ресурсами. Он действительно содержит фабричный метод, который создает различные типы структур соединений для поддержки различных протоколов.
Иерархия интерфейсов в структуре общих соединений определяет абстракции, которые характеризуют различные типы соединений, поддерживаемых блоком создания соединений. Эти интерфейсы предоставляют методы, которые облегчают приложениям управление общими типами соединений.
На рисунке 8.2 показана иерархия наследования интерфейсов MIDP, которые являются частью общей структуры соединений.
Программа ConnectionDemo
import javax.microedition.midlet.MI Diet;
import javax.microedition.lcdui.Display;
Этот класс определяет MID-лет для демонстрационной программы, которая
запрашивает у пользователя URI, затем создает соединение HTTP с исходным
сервером и извлекает ресурс. Программа использует
объект Form, для того чтобы дать пользователю возможность ввести URI.
*/
public class ConnectionDemo extends MID-лет
}
private static ConnectionDemo instance;
private URIEntry urlForm; public ConnectionDemo()
super();
instance = this; }
/**
Возвращает один экземпляр класса.
Вызов этого метода до создания объекта возвращает нулевой указатель.
@возвращаем экземпляр данного класса,
public static ConnectionDemo getlnstance ()
return instance;
}
public void startApp()
Display display;
URIEntry urlForm = URIEntry.getlnstance();
display = Display.getDisplay(this);
display.setCurrentlurlForm);
}
public void pauseApp()
}
}
void quit ()
destroyApp(true);
notifyDestroyedf) ;
}
public void destroyApp(boolean destroy)
{
instance = null;
/**
Устанавливает данный объект в качестве текущего отображаемого
объекта MID- лета .
*/
public void display()
Display.getDisplay(this).setCurrent(urlForm);
}
}
Класс URIEntry описывает форму, которая приглашает пользователя ввести URI
import: javax.micrcedition.midlet.MIDlet;
import javax.microedition.Icdui.Command;
import javax.microedition.Icdui.CommandListener;
import javax.raicroedition.Icdui.Display;
import javax.microedition.Icdui.Displayable;
import javax.microedition.Icdui.Form;
import javax.microedition.Icdui.TextField;
/**
Этот класс задает Form, приглашающую пользователя ввести URI,
с которым должно быть установлено соединение HTTP.
Пользователь вводит URI и нажимает командную кнопку «Go».
Экземпляр данного класса затем создает экземпляр класса ResourceDisplay,
который выполняет обязанности извлечения ресурса HTTP и его отображения.
*/
public class URIEntry extends Form implements CommandListener
}
private static Command go =
new Command("Go", Command.SCREEN, 1);
private static Command exit =
new CommandCExit", Command. EXIT, 1) ;
private static URIEntry instance;
// URI, введенный пользователем, private TextField uri;
// Нить, контролирующая выполнение объекта
// ResourceDisplay. private Thread thread;
/**
Конструктор.
@param title заголовок Form.
*/
private URIEntry(String title)
}
super(title);
instance = this;
uri = new TextField. ("Connect to:",
null, 70,
TextField.URL);
uri.setStringf'http://") ; append (uri) ;
addCommand(go);
addCommand(exit);
setCommandListener(this);
}
/**
Выдает один экземпляр данного класса.
^возвращение экземпляра данного класса.
*/
public static URIEntry getlnstance ()
}
if (instance == null)
{
instance = new URIEntry("Enter URL");
}
return instance;
}
/**
Устанавливает этот объект в качестве текущего отображаемого
объекта MID-лета.
*/
public void display()
MIDlet га = ConnectionDemo.getInstance();
Display.getDisplay(m).setCurrent(this);
}
public void commandAction(Command c, Displayable d)
}
if (c == go)
}
// Этот экран отображает метаинформацию ресурса,
// указанного с помощью URI.
ResourceDisplay view =
new ResourceDisplay(uri.getString());
MIDlet m = ConnectionDemo.getInstar.ee ();
Display.getDisplay(m).setCurrent(view);
thread = new Thread(view);
thread.start();
}
else if (c == e\it)
}
ConnectionDemo.getlnstance().quit();
}
}
}
Класс ResourceDisplay
import javdx.microedition.lcdui.Command;
import javax.microedition.Icdui.CommandListener;
import javax.microedition.Icdui.Form;
import javax.microedition.Icdui.Displayable;
/**
Данный класс задает Form, которая отображает метаинформацию,
описывающую HTTP-ресурс. Она контролируется отдельной нитью,
поэтому она реализует Runnable.
Этот объект Form использует объект helper для коммуникации с HTTP-ресурсом
через Connection. Он затем забирает данные соединения
из объекта helper для отображения на экране для пользователя.
public class ResourceDisplay extends Form
implements CommandListener, Runnable
{
private static Command back =
new Command("Back", Command.BACK, 1);
private static Displayable instance;
// Объект helper создает соединение с ресурсом на исходном
// сервере и извлекает метаинформацию ресурса.
// private HttpResource resource;
Конструктор.
Sparam uri URI ресурса для извлечения по запросу HTTP протокола.
*/
public ResourceDisplay(String uri)
{
super("Http Info");
instance = this;
resource = new HttpResource(uri);
addCommand(back);
setCommandListener(this);
}
/**
Запускает выполнение данного объекта:
запускает объект helper HttpResource.
@смотри . rtpResource
*/
public void run()
{
resource.run();
append(resource.getResourceMetalnfo());
}
/**
Возвращает один экземпляр данного класса.
Вызов этого метода перед созданием объекта возвращает нулевой указатель.
@возвращаем экземпляр данного класса.
*/
public static Displayable getlnstance ()
{
return instance;
{
public void commandAction(Command c, Displayable d)
{
if (c == back)
{
URI Entry, get Instanced .display();
}
}
}
Класс HttpResource определяет объект, который на самом деле извлекает сетевой ресурс
import Java.io.InputStream;
import Java.io.lOException;
import javax.microedition.io.Connect ion;
import javax.microedition.io.Connector;
import javax.microedition.io.HttpConnection;
import javax.microedition.Icdui.Displayable;
/**
Данный класс определяет объект helper, используемый классом
ResourceDisplay. Он создает соединение с ресурсом HTTP,
посылает запрос и получает ответ. Он размещает ответную
метаинформацию в буфере. Этот класс предоставляет метод,
который дает возможность другому объекту получать эту информацию
как объект String асинхронно. Этот класс также записывает результат
диагностики в стандартный вывод с целью демонстрации.
Результат появится в окне эмулятора J2MEWTK.
Обратите внимание, что этот класс реализует Runnable.
Он может использоваться программой для выполнения
работы асинхронно, контролируемый нитью, отличной от
основной нити приложения. В данной демонстрации соединения
отдельная нить не порождает подпроцесс контролирования
данного экземпляра, поскольку экземпляр ResourceDisplay,
который использует данный экземпляр, уже контролирует отдельная нить.
**/
public class HttpResource implements Runnable
private static Displayable instance;
// URI, представляющий выбранный ресурс.
private String uri;
// Буфер для поддержки информации ресурса.
private StringBuffer contents = new StringBuffer();
// Соединение с ресурсом. private Connection conn;
// Ссылка на HTTP-соединение, private HttpConnection httpConn;
// Входной поток соединения, private InputStream is;
// Значение поля атрибута статуса HTTP. private int status = -1;
/**
Конструктор.
@pararc uri URI, указывающий выбранный ресурс.
*/
public HttpResource (String uri)
{
super ();
this.uri = uri;
}
private String userAgentID ()
{
StringBuffer buf = new StringBuffer();
String config =
System.get Property("microedition.configuration");
String profile =
System.get Property("microedition.profiles");
buf.append("Configuration/");
buf.append(config);
buf.append!" Profile/");
buf.append(profile);
return buf . toStrir.g () ; )
/**
Запускает данный объект. Соединяется с URI,
посылает запрос, получает отклик и анализирует ответное сообщение.
*/
public void run()
System.out.println("Connection class name = " + conn.getClass().getName ());
connect () ; parse () ;
System.out.println(gecResourceMetalnfo() ) ;
try conn.close();
}
catch (lOException ioe) System.out.println(ioe.getMessage()) ;
ioe.printStackTrace();
}
}
/**
Соединяется с исходным сервером, который поддерживает URI.
Если произошло исключение во время соединения, этот метод
Перехватит его и не выдаст указания на ошибку, за исключением
Записи в стандартном результате диагностики.
*/
protected void connect!)
}
try
}
while (true)
{
// Соединение находится в состоянии «установка». conn = Connector.open(uri);
httpConn = (HttpConnection) conn;
httpConn.setRequestProperty("method", HttpConnection.HEAD);
httpConn.setRequestProperty("User-Agent", userAgentID());
// Соединение находится в состоянии «установлено». if (resourceRelocated())
{
uri = httpConn.getHeaderField("location");
// Соединение находится в состоянии «отключено» после
// вызова close().
conn.close();
}
else
}
breaX;
*/
if (serverError())
{
conn.close () ; return;
}
// Соединение находится в состоянии «установлено», is = httpConn.openlnputStream ();
System.out.println("Input stream class name = " + is.getClassO .get Name () ) ;
int responseCode = httpCcnn.getResponseCode ();
printResponseCode (responseCode) ; catch (lOExceptior. ioe)
{
contents.append(ioe.getMessage());
System.out.println(ioe.getMessage());
ioe.printStackTrace() ;
}
}
private boolean resourceRelocated()
{
boolean relocated = false; try
}
status = httpConn.getResponseCode();
if (status == HttpConnection.HTTP_MOVED_TEMP II
status == HttpConnection.HTTP_MOVED_PERM II
status == HttpConnection.HTTP_TEMP_REDIRECT)
{
relocated = true;
}
}
catch (lOException ioe)
}
System.out.println(ioe.getMessage() ) ;
ioe.printStackTrace() ;
}
return relocated;
}
private boolean serverError ()
{
boolean error = false;
try
{
status = httpConn.getResponseCode();
if ((status == HttpConnection.HTTP_NOT_IMPLEMENTED)
If (status == HttpConnection.HTTP_VERSION)
If (status == HttpConnection.HTTP_INTERNAL_ERROR)
If (status = = HttpConnection.HTTP_GATEWAY_TIMEOUT)
If (status == HttpConnection.HTTP_BAD_GATEWAY))
}
error = true; } }
catch (lOException ioe)
{
error = true;
System.out.println(ioe.getMessage()) ;
ioe.printStackTrace() ;
}
return error;
}
private void parse()
(
if (httpConn == null) return;
String protocol = httpConn.getProtocol();
contents.append("Protocol: " t protocol + "\n");
String type = httpConn.getType();
content's . append ("Type : " + type + "\n");
String encoding = httpConn.getEncoding ();
contents.append("Encoding: " + encoding + "\n");
long length = httpConn.getLength ();
contents.append("Length: " + length + "\n");
String uri = httpConn.getURL();
contents.append("URL: " + uri + "\n");
String host = httpConn.getHost();
contents.append("Host: " + host + "\n");
String query = httpConn.getQuery();
contents.append("Query: " + query + "\n");
String requestMethod = httpConn.getRequestMethod();
contents.append ("Method: " + requestMethod + "\n");
}
private void printResponseCode(int code)
{
System.out.print("Response code :
**/
switch (code) case HttpConnection.HTTP_ACCEPTED:
Systern.out.print In("HTTP_ACCEPTED");
break;
case HttpConnection.HTTP_BAD_GATEWAY:
Systern.out.print In("HTTP_BAD_GATEWAY");
break;
case HttpConnection.HTTP_BAD_METHOD:
Systern.out.print In("HTTP_BAD_METHOD") ; break;
'case HttpConnection.HTTP_BAD_REQUEST:
Systern.out.print In("HTTP~BAD_REQUEST");
break;
case HttpCo-.nection.HTTP_CONFLICT:
System.out.println("HTTP_CONFLICT");
break;
case HttpConnection.HTTP_CREATED:
System.out.print In("HTTP_CREATED");
break;
case HttpConnection.HTTP_FORBIDDEN:
System.out.print In("HTTP_BAD_FORBIDDEN");
break;
case HttpConnection.HTTP_GATEWAY_TIMEOUT:
System.out.print In("HTTP_GATEWAY_TIMEOUT");
break;
case HttpConnection.HTTP_GONE:
Systern.out.print In("HTTP_GONE");
break;
case HttpConnection.HTTP_NO_CONTENT:
System.out.println("HTTP_NO_CONTENT");
break;
case HttpConnection.HTTP_NOT_ACCEPTABLE:
Systern.out.print In("HTTP_NOT_ACCEPTABLE");
break;
case HttpConnection.HTTP_NOT_FOUND:
System.out.print In("HTTP~NOT_FOUND");
break;
case HttpConnection.HTTP_OK:
System.out.println("HTTP_OK");
break;
case HttpConnection.HTTP_PROXY_AUTH:
Systern.out.print In("HTTP_PROXY_AUTH");
break;
case HttpConnection.HTTP_UNAVAILABLE:
Systern.out.print In("HTTP_UNAVAILABLE");
break;
case HttpConnection.HTTP_VERSION:
System.out.print In("HTTP_VERSION");
break; default:
System.out.println ();
;. }
/**
Получает метахнформацию ресурса.
@выдает метаянформацию, возвращенную
исходным сервером в ответном сообщении.
*/
public String getResourceMetalnfо()
}
return contents.toString();
}
}
Четыре класса представлены в примере, показанном в листингах 8.1 - 8.4:
ConnectionDemo — определяет MID- лет для данной демонстрации. Он отображает экземпляр URIEntry.
URIEntry — определяет форму, приглашающую пользователя ввести URI, который программа будет извлекать.
ResourceDisplay — определяет форму, которая отображает метаинформацию полученного ресурса.
HttpResource — определяет класс helper, используемый классом ResourceDisplay для выполнения самого получения указанного пользователем ресурса.
Класс ConnectionDemo определяет MID-лет. Он отображает форму (определяемую классом URIEntry), которая приглашает пользователя ввести URI.
Класс HttpResource обрабатывает процессы установки соединения, посылки запроса и получения и анализа ответа. Класс ResourceDisplay отображает результаты. Класс HttpResource содержит набор основных кодов - то есть сетевой код. Программа создает один экземпляр данного класса для каждого установленного соединения.
Программа действует следующим образом. Пользователь вводит URI в текстовое поле объекта URIEntry. Объект URIEntry создает экземпляр класса ResourceDisplay при получении команды до, введенной пользователем, что означает: «Иди и принеси указанный ресурс». Это происходит в основной нити обработки событий. Объект URIEntry затем создает отдельную нить для контролирования остальной части выполнения экземпляра ResourceDisplay.
Экземпляр ResourceDisplay создает экземпляр класса HttpResource для выполнения работы по извлечению ресурса. Эта работа осуществляется асинхронно в новой созданной нити. Новая нить контролирует следующие этапы:
создание экземпляра HttpResource;
установление соединения с удаленным сервером;
получение отклика сервера, содержащего ресурс;
анализ полученного ресурса;
отображение данных ресурса.
Все эти этапы могут занимать много времени. Если они исполнялись нитью обработки событий, которая посылала команды в приложение, реализации MIDP придется подождать, пока выполнение вышеупомянутых этапов не завершится, прежде чем она сможет делать что-либо еще.
Это использование нитей является важной идиомой. Цель приложений - избежать выполнения продолжительной обработки команд в методе commandAction(). Эта обработка может блокировать работу на недопустимо длинные периоды времени, как, например, при ожидании ответа с сервера HTTP. Важно, чтобы каждый CommandListener получал данные РЗ своего метода commandActionO «как можно быстрее». Например, в программе, показанной в листинге 8.1, вызов Connector.open() блокирует работу, пока не получит ответ или пока не выйдет время. Временной интервал по умолчанию составляет около 15 секунд в эмуляторе J2MEWTK.
Вероятно, реализация MIDP не может быть блокированной от выполнения какой-либо обработки событий так долго.
Класс HttpResource определяет API, который поддерживает получение ресурсов в отдельной нити. Он реализует Runnable и определяет его обработку в методе run(). В нашем примере эта возможность на самом деле не используется, поскольку вторая нить начинает выполнение с методом run() класса ResourceDisplay, который затем вызывает метод HttpRespource.run(). Класс HttpResource может быть использован, однако, в другом приложении, и его реализация Runnable отражает его поддержку многонитевого исполнения.
Объекты соединений. Как вы знаете, различные интерфейсы в структуре общих соединений представляют различные типы соединений. Однако это конкретные реализации данных интерфейсов, которые на самом деле предоставляют соединению его свойства и возможности. Сейчас самое подходящее время более внимательно взглянуть на реализации, стоящие за этими интерфейсами.
Я ссылался на класс Connector как на производящий соединение. Более точно, метод Connector.open() реализует фабричный метод образца проектирования. Для получения более подробной информации по данному и другим образцам проектирования смотрите «Образцы проектирования» (Design Patterns) от «Gamma et al.». Вы пересылаете в класс Connector сформированный в общем виде адрес некоторого ресурса, с которым вы хотите установить соединение. Этот URI указывает схему - тип желаемого соединения - но, с другой стороны, извлекает подробную информацию о соединении, связанную с протоколом. Производитель соединения пересылает обратно объект, чей класс реализует протокол, представленный полем схемы запроса соединения.
Класс этого объекта реализует интерфейс, который определяет тип установленного соединения. Тип внедряемого класса абстрактен, поскольку вы ссылаетесь на объект с помощью ссылки на тип интерфейса. Например, объект соединения, выдаваемый в листинге 8.4, реализует интерфейс HttpConnection. Взгляните на следующие строчки кода, расположенные в методе HttpResource.connect ().
Connection conn;
HttpConnection httpConn;
. . .
conn = Connector.open(uri);
httpConn = {HttpConnection) conn;
. . . .
Первый оператор выдает объект соединения. URI указывает схему http. Текущий объект соединения больше чем просто Connection, это HttpConnection. Поэтому вы можете не рискуя создать ссылку на объект, чей тип - HttpConnection. Вы можете сделать это, потому что фабричный метод выдает объект, чей класс реализует HttpConnection, a не просто Connection. Этот объект отличается от объекта, который был бы выдан при других значениях поля схемы в вызове Connector.ореn().
Первый оператор, показанный в следующей выдержке из метода HttpResource.run(), выдает полностью определенное имя конкретного класса, который реализует интерфейс HttpConnection:
public void run ()
System.out.println("Connection class name = " +
conn.getClass() . get Name () ) ;
connect () ;
parse () ;
...
}
Если вы запустите эту программу на эмуляторе Sun J2ME Wireless Toolkit, вы увидите, что в следующих выходных данных выводится имя класса, который является частью реализации J2ME Sun, которая используется эмулятором Sun J2ME Wireless Toolkit:
com.sun.midp.io.j2me.http.Protocol
Если вы запустите программу, показанную в листингах 8.1 - 8.4, на эмуляторе другого производителя, вы увидите другое имя класса. Таким образом опознается реализация данного производителя интерфейса HttpConnection. Все определяемые протоколом классы зависят от реализации.
Модель состояний соединения HTTP. Соединения HTTP могут находиться в одном из трех состояний в течение их жизненного цикла. Эта модель состояний отражает природу запроса-отклика протокола HTTP. Это следующие три состояния:
Установка - создан объект соединения, но соединения с исходным сервером еще нет.
Установлено - соединение с сервером было установлено, параметры запроса были посланы на сервер, и объект соединения ожидает отклика с сервера.
Отключено - соединение было разорвано. Последующие вызовы методов соединения сбрасывают lOException.
На рисунке 8. 3 показана диаграмма перемещения из состояния в состояние объектов соединения HTTP. Объект соединения существует в состоянии установки при создании его экземпляра. На данный момент строка запроса не была создана. Чтобы создать запрос, вы должны установить метод HTTP и заголовки запроса. Эти значения устанавливаются с помощью методов, перечисленных в таблице 8.6. Прежде чем соединение сможет войти в состояние «установлено», - прежде, чем оно пошлет запрос серверу и получит ответ, - оно должно установить параметры запроса HTTP, то есть создать сообщение запроса. Вызов этих методов, однако, не приведет к переходу в другое состояние.
Соединение переходит в состояние «установлено», когда вызваны любые из методов, перечисленных в таблице 8.7. Состояние установленного соединения представляет собой период между временем, когда запрос был послан на сервер, и временем, когда либо клиент, либо сервер прервали соединение. Вы можете видеть, что все методы, показанные в таблице 8.7, работают с извлечением данных из ответного сообщения. Чтобы извлечь данные, соединение с сервером должно быть действующим, чтобы клиент получил ответное сообщение.
Дейтаграммы посылаются
import javax.microedition.midlet.MIDlet;
import javax.microedition.Icdui.Display;
import javax.microedition.Icdui.Command;
import javax.microedition.Icdui.CommandListenerj;
import javax.microedition.Icdui.Displayable;
import javax.microedition.Icdui.TextBox;
import javax.microedition.Icdui.TextFie Id;
import javax.microedition.io.Connector;
import javax.microedition.io.Datagram;
import javax.microedition.io.DatagramConnection;
import Java.io.lOException; ft,
Этот класс реализует дейтаграммкого клиента,
который соединяется с сервером синхронизирующего
сетевого протокола (NTP) через стандартный порт NTP 123.
Для контроля клиента назначается отдельная нить,
поэтому он реализует Runnable. Приложение может
осуществлять коммуникации асинхронно из управления
его пользовательским интерфейсом.
Обратите внимание, что данный файл представляет только «скелет клиента».
Полная семантика сообщений службы NTP здесь не показана. Цель в том, чтобы
просто продемонстрировать структуру клиента с помощью дейтаграмм MIDP.
*/
public class DatagramTest extends MIDlet,
implements CommandListener, Runnable
}
private static final int BUF_SIZE = 1024;
private static Command exit =
new Command ("Exit", Command.EXIT, 1);
private static DatagramTest instance; private Display display;
private TextBox dgramText;
// Дейтаграммное соединение. private DatagramConnection conn;
// Дейтаграмма, которая поддерживает посылку
и получение данных, private Datagram dgram;
// Адрес демона синхронизирующего сетевого протокола (NTP) на
// определенном сервере. NTP использует
протокол UDP. private String address = "datagram://srl-usca28-07:123";
/"*
Конструктор No-arg.
*/
public DatagramTest()
{
super ();
instance = this;
}
/**
Конструктор.
Обратите внимание, что проверок действительности параметра
не осуществляется. Если он деформирован, при попытке соединения
будет сброшено исключение.
@param service URI дейтаграммной службы, с которой соединяемся.
*/
public DatagramTest(String service)
(
this ();
address = service;
}
/**
Выдает один экземпляр данного класса. Вызов данного метода
до создания объекта возвращает нулевой указатель.
@выдает экземпляр данного класса.
*/
public static DatagramTest getlnstance()
}
return instance;
{
public void startApp()
}
display = Display.getDisplay (this);
dgramText = new TextBox("Datagram contents", null, 2048,
TextField.ANY);
dgramText.setCommandListener (this);
display.setCurrent(dgramText);
run ();
}
/*
Запускает дейтаграммного клиента.
Открывает соединение со службой дейтаграммы.
Заполняет объект дейтаграммы и посылает его. Получает
ответ асинхронно и записывает байты в стандартный результат для
демонстрации. Бесшумно перехватывает исключения, связанные
с любым соединением.
*/
public void run ()
}
try int maxLength;
// Откройте клиентское соединение,
conn = (DatagramConnection) Connector.open(address);
maxLength = conn.getMaximumLength();
dgram = conn.newDatagram(maxLength);
// Убедитесь, что указатель для чтения/записи находится в
// начале буфера, так что данные будут переписывать
// буферную память, dgram.reset();
// Заполните дейтаграмму перед посылкой сообщением,
// которое служба дейтаграммы поймет.
// Создайте запрос в дейтаграмме.
**/
// Пошлите только что заполненную дейтаграмму. conn.send(dgram);
// Получите дейтаграмму; ее содержимое помещается в
// указанный объект дейтаграммы. conn.receive(dgram);
// Используйте данный байтовый массив для пересылки содержимого
// ответа сервера более управляемому объекту Java,
// как, например, String. Вы можете затем использовать
// дейтаграмму для другого события пересылки или получения.
byte [] data = dgram.getData ();
// Извлеките строку ответа. String str = new String (data);
// Проделайте обработку ответа. Здесь он
// просто распечатывается для демонстрации. System.out.println(str);
// Переустановите указатель для чтения/записи для объекта
// дейтаграммы.
В следующий раз, когда данные будут записываться
// в буфер дейтаграммы, он перепишет данные последней операции
// по пересылке или получению.
//Это гарантирует, что предыдущие и последующие данные не
// перемешаются в одном буфере и что не будет создано
// испорченных засоренных сообщений.
dgram.reset();
// Продолжайте обработку, возможно, посылая и получая другие
// сообщения сервера.
// ....
}
catch (lOException ioe)
(
System.out.println(ioe.getMessage() ) ;
loe.printStackTrace();
quit();
}
return;
}
public void pauseApp()
{
}
void quit()
destroyApp(true);
notifyDestroyedf);
}
public void destroyApp(boolean destroy) }
try }
conn.close () ;
}
catch (lOException ioe) ioe.printStackTracef) ;
public void display!)
Display.getDisplay(this).setCurrent(dgramText);
)
public void commandAction(Command c, Displayable d)
{
if (c == exit)
}
quit();
}
}
}
Обратите внимание, что любой из объектов Datagram по умолчанию содержит тот же адрес, что и создающий их объект DatagramConnection. Вы можете изменять адрес дейтаграммы с помощью методов интерфейса Datagram.
Приложение должно поставлять объект Datagram для посылки или получения дейтаграммы. Чтобы послать дейтаграмму, приложение заполняет объект дейтаграммы данными, составляющими сообщение, которое должно быть послано на сервер. Когда приложение получает дейтаграмму, его объект соединения заполняет объект дейтаграммы данными, которые оно получает от посылающего устройства.
Вы можете использовать тот же объект дейтаграммы для посылки и получения нескольких сообщений. Чтобы сделать это, вы должны убедиться, что вы не перепутали данные нескольких сообщений. Перед повторным использованием объекта дейтаграммы для посылки или приема нового сообщения используйте метод Datagram.reset() для переустановки указателя чтения/записи буфера.
Объект Datagram имеет буфер, в котором хранятся байты, составляющие сообщение, которое будет послано или получено. Если вы повторно используете объект Datagram, байты, которые были помещены в буфер предыдущей операцией посылки или получения, все еще будут находиться там.Вызов reset () устанавливает сдвиг указателя чтения/записи на начало данного буфера и устанавливает длину на 0. Таким образом, вы эффективно переписываете данные любой предыдущей операции, гарантируя, что вы не смешаете байты двух отдельных сообщений.
Сервер порождает
import javax.microedition.io.Connector;
import javax.microedition.io.StreamConnection;
import javax.microedition.io.StreamConnectionNotifier;
import Java.io.lOException;
/**
Данный класс реализует службу, которая прослушивает запросы
клиентских соединений на известном сокете.
Он открывает соединение на предварительно определенном номере порта.
А затем блокирует обработку на данном порте,
ожидая клиентского запроса соединения.
Когда запрос появляется, он принимает его и открывает новое
соединение сокета. Эти два этапа выражаются в реализации,
уведомляющей реализацию клиента о новом соединении сокета.
Этот сервер затем порождает компонент и передает его новому
объекту соединения. Компонент запускает отдельную нить. Компонент
теперь свободен для взаимодействия с клиентом асинхронно
от продолжающейся работы сервера.
public class ServerSocket imlements Runnable
{
// Порт по умолчанию, на котором установлен известный
// сокет. public static final String DEFAULT_PORT = "9876";
// Порт, на котором установлен известный
// сокет. protected String wellKnownPort;
// URI, который данный сервер использует для открытия своего
// известного сокета. protected String uri;
// Соединение с известным сокетом.
protected StreamConnectionNotifier wellKnownConn;
// Соединение сокета, которое соединяется с клиентом,
protected StreamConnection clientConn;
/**
Конструктор для подклассов.
*/
protected ServerSocket()
super ();
/**
Конструктор.
@param port Известный порт, на котором устанавливается
этот объект как блок прослушивания.
*/
public ServerSocket (String port)
}
thisl);
if (port == null)
{
wellKnownPort = DEFAULT_PORT;
}
else
}
wellKnownPort = port;
}
setURI(port);
{
protected void setURI(String port)
{
StringBuffer buf = new StringBuffer("socket://:");
buf.append(port);
uri = buf.toString();
}
/**
Запустите данный сервер. Этот метод должен быть
вызван явно после создания данного объекта. Он запускает
прослушивание запросов клиентов на известном сокете.
Оператор вызова должен запустить это выполнение в отдельной нити.
*/
public void run()
{
while (true)
{
try
{
// Откройте соединение известного сокета для данной
// «службы». wellKnownConn = (StreamConnectionNotifier)
Connector.open(uri);
//Прослушиваем запросы соединения. Данный вызов
// блокирует работу до тех пор, пока не будет получен
// запрос на соединение.
clientConn = wellKnownConn.acceptAndOpen()
// Создадим экземпляр агента»сервера, объект, который
// представляет службу для клиента. Каждый экземпляр
// взаимодействует с одним клиентом.
// Порождаем нить для взаимодействия с
// клиентом, создавшим запрос на соединение.
ServerAgent agent = new ServerAgent(clientConn);
Thread thread = new Thread (agent);
} catch (lOException ioe)
( System.out.printlnfioe.getMessage!));
ioe.printStackTrace();
break;
)
}
}
}
Агент сервера является
import javax .microedition. io._StreamConnectior.;
/**
Данный класс определяет компоненту, которую сервер
создает для взаимодействия с клиентом.
Он действует как «агент» от имени сервера для того, чтобы сервер
был свободен для прослушивания только новых запросов соединения.
Экземпляры данного класса являются частью сервера.
*/
public class ServerAgent implements Runnable
private StreamConnection conn;
/**
Конструктор.
@param с Объект соединения, который представляет
соединение с клиентом. Класс ServerSocket создает и пересылает
его в данный конструктор.
*/
public ServerAgent(StreamConnection c)
super ();
conn = с;
}
/**
Выполняется агент данного сервера. Начинается диалог с клиентом. Этот метод должен быть вызван явно после того, как создан данный объект.
public void run()
}
// Взаимодействует с клиентом. Реализует поведение,
// которое определяет данную службу.
}
}
Клиент имеет отдельно
import javax.microedition.midlet.MI Diet;
import javax.microedition.io.StreamConnection;
import javax.microedition.io.Connector;
import Java.io.lOException;
/**
Данный класс реализует клиента, который соединяется с сервером.
Для создания экземпляра данного класса вы должны указать сервер
(имя сервера DNS) и известный порт службы, с которой вы хотите
установить соединение.
*/
public class ClientSocket implements Runnable
{
public static final String P.ROTOCOL = "socket";
/'/ Порт известного сокета сервера, private String serverPort;
// Имя сервера, с которым соединяемся, private String serverHostName;
// URI известного серверного сокета. private String serverURI;
// Соединение с.сервером.
private StreamConnection streamConn;
protected ClientSocket()
}
super();
}
/**
Открытый конструктор. Вы должны указать имя сервера DNS
и номер порта службы. @param server - имя DNS машины,
с которой вы хотите соединиться.
@param port - Номер порта сервера, с которым вы хотите соединиться.
*/
public ClientSocket(String server, String port)
throws TOException
(
this();
serverHostName = server; serverPort = port;
serverURI = buildServerURI ();
open () ;
}
/**
Конструктор.
@param uri - полностью сформированный URI службы,
запрос на соединение с которой вы хотите создать.
@сбрасывает InvalidArgumentException при несформированном URI.
*/
public ClientSocket(String uri) throws lOException
{
this ();
serverURI = uri;
}
Открывает соединение. После того как создан данный объект,
соединение с сервером еще не открыто. Вы должны открыть его явно.
Это делает модель использования более гибкой для клиентов.
@ сбрасывает lOException, если соединение не может быть
открыто по некоторым причинам.
*/
public void open() throws lOException
streamConn = (StreamConnection) Connector.open(serverURI);
/**
Закрывает соединение с сервером.
*/
public void closed try streamConn. closed ; }
catch (lOException ioe)
}
ioe.printStackTraced ;
{
{
Выполняет клиентское взаимодействие.
Запускает посылку клиентом запросов на сервер.
Этот метод должен быть вызван после того, как метод opend установит соединение.
*/
public void run ()
{
// Начинаем взаимодействие с сервером.
// Посылаем запросы, читаем ответы
....
private String buildServerURI ()
}
StringBuffex uri = new StringBuffer(PROTOCOL);
uri.append ("://");
uri.append(serverHostName);
uri.append(":");
uri.append(serverPort);
return uri.toString ();
}
}
Использование соединений сокета в приложениях MIDP. Естественно, тот факт, что интерфейс StreamConnectionNotif ier определен как часть пакета IOMIDP, предполагает, что он должен использоваться приложениями, запускаемыми на устройствах MIDP. Это означает, что MID-лет может поддерживать открытое соединение с известным соке-том для использования клиентами. Клиенты, однако, могут находиться в другом месте.
На самом деле клиенты должны быть удалены от сервера. Назначение сокета сервера на мобильном устройстве заключается в том, чтобы обрабатывать входящие запросы соединения от удаленных клиентов. Использование сокетов для взаимодействий на одном и том же устройстве определенно неэффективно. Хотя это возможно, существуют более удобные модели.
Удаленный клиент может работать на другом мобильном устройстве или на удаленном узле. Потенциально любой из этих типов клиентов может находиться в одной и той же сети как устройство, которое поддерживает сокет сервера, или они могут находиться отдельно от сети транспортировщика. Характеристики сети транспортировщика, в которой ваше приложение работает, определяют набор клиентов, которые могут соединиться с вашим мобильным устройством.
Сети транспортировщика используют протокол сетевого уровня как часть набора протоколов своей сети. Каждое устройство получает уникальный сетевой адрес, в то время как оно соединяется с сетью. Для того чтобы клиенты соединялись с вашим устройством - и вашим серверным сокетом, - они должны быть способны определять сетевой адрес вашего устройства.
Конфигурация и реализация сети транспортировщика могут не раскрывать адресов соединенных с ней мобильных устройств внутренне или внешне, таким образом делая соединение клиентов с желаемым мобильным устройством невозможным.
Многие сети транспортировщиков используют некоторого рода динамические сетевые адреса, присваиваемые мобильным устройствам. Если это так, клиентам, желающим соединиться, придется определять адрес мобильного устройства динамично. Если не предоставляется никакого поискового механизма, клиенты не смогут запросить соединение с устройством.
Независимо от того, являются ли адреса мобильного устройства статическими или динамическими, сеть транспортировщика может задействовать какую-либо схему трансляции сетевого адреса (network address translation (NAT)) для изменения или преобразования адреса мобильного устройства. Мотив использования схемы NAT может быть связан с ограничениями места или безопасности. Определенные сетевые протоколы могут не иметь достаточного адресного места для обработки всех цифр сетевых устройств. Если это так, и если транспортировщик желает узнать адреса своих устройств, ему придется предоставить какой-либо реестр для отображения динамических адресов и механизм поиска. В противном случае ваше серверное приложение не будет доступно.
По причинам безопасности транспортировщики могут не захотеть выставлять адреса мобильных устройств своих пользователей на всеобщее обозрение. Если это так, ваше приложение может быть доступно только приложениям, работающим на системах транспортировщика. Более того, доступ может быть ограничен до привилегированных приложений, даже в сети транспортировщика. И даже в сети каждому устройству придется иметь способ объявления своего сетевого адреса другим устройствам для соединения с ним. В большинстве современных поколений беспроводных сетей мобильные устройства не осведомлены о наличии или адресе друг друга. Это может измениться в сетях поколения 3G, которые должны распространиться более широко в ближайшие несколько лет.
Беспроводные сети 3G двигаются в сторону принятия IPv6 как своих протоколов сетевого уровня. В IPv6 существует множество адресов, что делает возможным назначение уникального IP-адреса каждому мобильному устройству в мире. Если каждое устройство имеет уникальный статический IP-адрес, любое приложение, которое знает адрес вашего устройства, может соединиться с известным портом вашего устройства.
Опять же, однако, политики безопасности и конфигурации, применяющиеся транспортировщиком, могут повлиять на возможности, в действительности доступные приложениям.
Модель организации сетей в 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 является извлечение подробной информации о неоднородной природе, сложности и реализации большого количества различных беспроводных сетевых сред. Достижение этой цели требует изоляции разработчиков приложений от воздействия характеристик сети.
Потоковые соединения
Интерфейс StreamConnection происходит непосредственно из интерфейсов InputConnection и OutputConnection. Он наследует методы двух интерфейсов, описанных ранее в таблицах 8.1 и 8.2.
Интерфейс StreamConnection представляет соединение как поток данных в наиболее абстрактном смысле слова - как последовательность байтов. Это пустой интерфейс, он не привносит нового поведения в дополнение к любому из его двух вышестоящих интерфейсов. Тем не менее, его присутствие в иерархии необходимо для целей, лежащих за пределами обязанностей интерфейсов InputConnection и OutputConnection. Он работает как заполнитель, представляющий любой тип соединения, чьи данные могут быть обработаны как поток байтов.
Интерфейс StreamConnection извлекает подробную информацию о механизме соединения - протоколе, используемом в реализации определенного типа соединения, а также его синтаксисе и семантике. Например, J2ME Wireless Toolkit предоставляет две реализации StreamConnection - одну для соединения с портами связи, а другую для соединения с сокетами клиентов стиля Unix. Интерфейс StreamConnection определяет оба этих типа соединения как необработанные потоки данных без определения синтаксиса или семантики протокола. Реализации, однако, совершенно отличны. В данном разделе вы увидите, как настраивать соединение с коммуникационным портом. Затем вы узнаете, как настраивать соединение сокета.
Соединения с коммуникационными портами, как и все другие соединения, должны быть установлены путем передачи URI в Connector.open(). Вы должны указать адрес порта связи, который вы хотите открыть. Поле схемы должно иметь значение соггап, которое определяет соединение как потоковое соединение для коммуникационных портов. Полная форма адреса следующая:
address := <схема>:<уэел>;
<параметры> cheme := "coram"
unit := <integer, представляющая открываемый порт eomn>
parameters := <зависящие от устройства параметры конфигурации>
Например, вы могли открыть соединение с коммуникационным портом с помощью следующего оператора:
StreamConnection conn = Connector.open("comm:0;baudrate=9600");
Полный набор параметров, которые приемлемы, зависит от родной системы программного обеспечения драйвера устройства, и, в конечном счете, конечно, на устройстве, с которым соединение было установлено.
Различия между организацией сетей В J2ME и J2SE
В предыдущих разделах данной главы описывался полный набор сетевых свойств I MIDP. Пакет java.io MIDP определяет все эти свойства. В MIDP нет пакета java.net, как в J2SE.
Вы также должны знать, что пакет java.io MIDP поддерживает подмножество при- 1 вычных байтовых и символьных классов входных и выходных потоков, представленных в J2SE. В частности, классы BufferedReader, LineNumberReader и StringReader пакета java.io J2SE отсутствуют в пакете java.io MIDP.
Хотя базовая инфраструктура, связанная с сокетными соединениями, существует в реализациях MIDP, в MIDP все еще отсутствует поддержка нескольких механизмов распределенных коммуникаций, которые доступны в платформе J2SE. В MIDP отсутствуют следующие объекты уровня приложений:
RMI требует слишком большой мощности для поддержки в мобильных устройствах на настоящий момент;
Jini требует RMI, поэтому не присутствует;
JavaSpaces не существует в J2ME;
Связующее программное обеспечение CORBA не существует в J2ME.
Вы увидите в главе 11, что отсутствие этих механизмов необязательно является препятствием. Основная причина их отсутствия заключена в производительности персональных мобильных устройств, однако технология, которую используют порталы беспроводного Интернета для создания внешних интерфейсов своих служб, дает устройствам MIDP соответствующие возможности связи для современных приложений.
Как вы хорошо знаете, тематика данной книги сконцентрирована на MIDP платформы J2ME. Тем не менее, полезно сказать несколько слов о CDC и организации сетевой работы. CDC предлагает более мощную поддержку сетей и коммуникаций, чем CLDC/MIDP. Например, стандартные комиссии определили профиль RMI. Были разработаны и другие определения профиля. Если вы действительно нуждаетесь в этих возможностях, вы должны подумать о том, какие устройства будут использовать ваше приложение, и является ли более подходящей конфигурацией для вашего приложения CDC или CLDC.
Очень возможно, что через несколько лет персональные мобильные устройства станут достаточно мощными для поддержки других профилей, таких, как профиль RMI. Но эта ситуация будет через несколько лет, а вы должны создавать приложения с расчетом на современные ожидания.
Соединения coкeтa
Соединения сокета являются последним типом соединений, явно представленных сетевой инфраструктурой MIDP. Реализации MIDP, поддерживающие сокеты, реализуют традиционные сокеты стиля UNIX. Стоит напомнить еще раз, что от реализаций не требуется поддерживать какой-либо механизм соединения, кроме HTTP 1.1. Многие из них не хотят поддерживать соединения сокета.
Интерфейс StreamConnectionNotifier представляет известный сокет сервера. Интерфейс StreamConnection, который вы видели ранее, представляет сокет клиента.
Сокет - это сетевой механизм транспортного уровня, который обычно реализует пару протоколов TCP/IP в фиксированных межсетевых средах. Сокет сервера является программой, предоставляющей сетевую службу для соединений через сокеты.
Сокеты не требуют создания абсолютно никакой структуры полезной нагрузки, которую они транспортируют. Как и дейтаграммы, они просто транспортируют последовательность байтов. Служба определяет формат, синтаксис и семантику транспортируемых данных, составляющих сообщения. Клиенты должны соблюдать эти правила, для того чтобы использовать службу.
Соединения сокета находятся на транспортном уровне. Их поддержка осуществляется автоматически, если сокеты реализованы с помощью соединений TCP. TCP является ориентированным на соединения протоколом транспортного уровня, предназначенным для хранения данных в течение нескольких пересылок между клиентом и сервером.
Однако сокеты не всегда реализуются с помощью TCP/IP. Тем не менее, поскольку TCP/IP является стандартной парой протоколов Интернета транспортного и сетевого уровня, системы, которые реализуют сокеты с помощью других механизмов, должны связываться с Интернет-узлами с помощью шлюза. Это требование действует как в среде фиксированных сетей, так и в беспроводном Интернете.
В настоящее время TCP/IP не поддерживается многими беспроводными сетями. Тем не менее, беспроводные сети все равно могут поддерживать соединения сокета. Они могут подчиняться интерфейсу сокета и создавать такие же связанные с соединением абстракции, что и TCP/IP, используя другие протоколы - даже собственные.
Однако если транспортировщик использует нестандартный набор протоколов, они будут иметь шлюз, который свяжет их беспроводную сеть с внешним миром.
Протоколы уровня приложений могут быть определены поверх протоколов транспортного уровня, если это необходимо. Реализация протокола уровня приложений использует любой доступный механизм транспортировки. Например, HTTP является протоколом уровня приложений. Создатели приложения MIDP могут выбирать, не создать ли протокол уровня приложений непосредственно поверх механизма сокета, если таковой поддерживается. Если сокеты не поддерживаются, сообщения протокола уровня приложений могут быть туннелированы с помощью HTTP. Протокол уровня приложений ответственен за определение своего собственного состояния, которое отличается от состояния протокола транспортного уровня.
Модель соединения сокета. Соединения сокета устанавливаются также, как и другие типы соединений, клиенты используют метод Connector.open() и указывают URI базирующейся на сокетах службы, с которой они хотят соединиться. Однако со стороны сервера модель соединения немного отличается из-за определяемой соединениями природы сокетов. Эта модель необходима для серверов, чтобы иметь возможность обеспечивать многочисленные одновременные соединения клиентов.
Это стандартная идиома, которую вы должны использовать для того, чтобы работать с сокетами сервера. Она та же, что и модель соединения сокета стиля Unix. Следующие этапы описывают сценарий соединения:
Демон сервера устанавливает соединение, которое связано с известным сокетом - сокетом сервера, чей порт и служба были предварительно установлены и объявлены.
Демон сервера прослушивает запросы соединения клиента.
Клиент создает запрос соединения для демона сервера и ожидает отклика.
Демон принимает запрос соединения и создает новое соединение с клиентом, сервер связывает соединение с новым сокетом. Сервер создает новый объект приложения, который будет взаимодействовать с клиентом через новое соединение и порождает нить для контролирования этого объекта.
Запрос соединения клиента возвращается. Приложение клиента теперь имеет объект соединения, чьей конечной точкой является новый сокет, созданный сервером.
Клиент и сервер взаимодействуют через новое соединение.
Демон сервера продолжает прослушивать последующие запросы соединения на известном сокете.
На рисунке 8.5 показано схематичное представление этого процесса. Порядок этапов в вышеописанном списке соответствует порядку, показанному на рисунке 8.5.
Соединения содержимого соединений
Интерфейс ContentConnection дополняет интерфейс StreamConnection. Он уточняет понятие потокового соединения. Он определяет соединения, включающие содержимое, вместо представления их как простого потока необработанных байтов или потока, чья структура должна быть отмечена как приоритетная (priori).
Конечно, все потоки содержат некоторого рода «содержимое», основная цель сообщений протокола заключается в транспортировке полезной нагрузки данными. Идея, лежащая в основе интерфейса ContentConnection, заключается в том, что он представляет соединения, которые могут описать свое содержимое некоторым образом, обычно с помощью наличия атрибутов метаинформации, определенных протоколом. Интерфейс ContentConnection предоставляет подробную информацию об извлечении этой информации из потока, так что вам не придется знать синтаксис или семантику протокола реализации.
Интерфейс ContentConnection представляет собой общие характеристики семейства протоколов уровня приложений, которые обычно определяют атрибуты, описывающие транспортируемые ими данные. Более точно, ContentConnection определяет несколько базовых атрибутов, которые являются общими для всех таких соединений содержимого соединений. В таблице 8.3 перечислены три метода, определяемые ContentConnection. Вы можете видеть, как они применяются по отношению к семейству протоколов уровня приложений.
Методы интерфейса InputConnection
Имя метода InputConnection | Описание | ||
DatalnputStream openDatalnputStream ( ) | Открывает и возвращает DatalnputStream, который соединяется с сетевым ресурсом, связанным с этим соединением | ||
InputStream openlnputStreamf) | Открывает и возвращает InputStream, который соединяется с сетевым ресурсом, связанным с данным соединением |
Эти методы возвращают типы объектов InputStream. Вспомните, что DatalnputStream является подклассом InputStream. Смысл заключается в том, что вы можете получить потоки, способствующие преобразованию данных в байтовые данные. Если вы желаете интерпретировать данные другим способом, ваша задача - создать подходящее «преобразование», которое позволит вам получать доступ и интерпретировать данные желаемым образом.
Интерфейс OutputConnection является еще одним подинтерфейсом Connection. Он работает с исходящими потоками и также определяет содержимое своих потоков как байтовые данные. Его методы показаны в таблице 8.2. Вы должны использовать этот интерфейс при записи байтовых данных в удаленный ресурс.
С помощью этих двух интерфейсов вы можете затем интерпретировать входящий или выходящий поток данных ресурса как последовательность необработанных байтов, анализируя их с помощью методов интерфейсов Datalnput или DataOutput. Конечно, вы должны знать формат данных, посылаемых устройством, или формат, ожидаемый устройством, соответственно. Другими словами, не существует абстракции данных, которая устраняет необходимость знать синтаксис и семантику данных в InputConnection или OutputConnection.
Методы интерфейса OutputConnection
Имя метода OutputConnection | Описание | ||
DataOutputStream openDataOutputStream () | Открывает и возвращает DataOutputStream, который соединяется с сетевым ресурсом, связанным с этим соединением. | ||
OutputStream openOutputStream() | Открывает и возвращает OutputStream, который соединяется с сетевым ресурсом, связанным с этим соединением. |
Методы интерфейса 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.
Методы интерфейса HttpConnection
Название метода HttpConnection | Описание | ||
long getDate ( ) | Выдает значение поля заголовка даты | ||
long getExpiration () | Выдает значение поля заголовка Expires | ||
String getFilef) | Выдает значение поля URL данного соединения | ||
String getHeaderFieldfint n) | Выдает значение части пронумерованного поля заголовка ключ-значение | ||
String getHeaderField (String name) | Выдает значение поля заголовка с указанным именем ключа. В качестве аргумента приемлемо любое действительное имя поля HTTP | ||
long getHeaderFieldDate (String name, long def) | Выдает значение (анализируемое как дата) поля заголовка с указанным ключом | ||
int getHeaderFieldlnt (String name, int def) | Выдает значение (анализируемое как целое] названного поля заголовка | ||
String getHeaderFieldKey (int n) | Выдает часть ключа пронумерованного поля заголовка | ||
String getHostf) | Выдает часть HOST URL данного соединения | ||
long getLastModif ied() | Выдает значение поля LastModified URL. | ||
int getPortf) | Выдает значение поля порта URL данного соединения | ||
String getProtocol () | Выдает имя протокола URL | ||
String getQueryO | Выдает область запроса URL, часть после первого "?" в URL | ||
String getReff) | Выдает часть ссылки URL | ||
String getRequestMethod () | Выдает метод текущего запроса | ||
String getRequestProperty (String key) | Выдает значение указанного свойства общего запроса | ||
int getResponseCode() | Выдает код состояния отклика v HTTP | ||
String getResponseMessage ( ) | Выдает сообщение отклика HTTP, связанное с кодом состояния отклика | ||
String getURLO | Выдает строковую форму 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.
Определения констант интерфейса 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, так что вам не придется проделывать эту огромную работу.
Методы интерфейса HttpConnection для создания запроса HTTP
Название метода HttpConnection | Описание | ||
void setRequestMethod (String method) | Устанавливает метод запроса HTTP, либо HEAD, либо POST, либо GET | ||
void setRequestProperty (String key, String value) | Включает в запрос указанное поле заголовка со значением, установленным на value |
Методы интерфейса
Название метода HttpConnection | Описание | ||
InputStream openlnputStream () | Открывает и выдает ссылку на InputStream (происходит от InputConnection) | ||
OutputStream openOutputStream() | Открывает и выдает OutputStream для соединения (происходит из OutputConnection) | ||
DatalnputStream openData!nputStream( ) | Открывает и выдает ссылку на DatalnputStream (происходит из InputConnection) | ||
DataOutputStream openDataOutputStream() | Открывает и выдает ссылку на DataOutputStream (происходит изOutputConnection) | ||
long getDate() | Получает значение поля заголовка date | ||
String getEncoding () | Получает строку, которая описывает шифрование содержимого в ответе (происходит от ContentConnection] | ||
long getExpiration ( ) | Получает значение поля заголовка expires | ||
String getHeaderField (String name) | Получает значение указанного поля заголовка | ||
long getHeaderFieldDate (String name, long def) | Получает значение указанного поля заголовка. Значение анализируется как число | ||
String getHeaderFieldlnt (String name, int def) | Получает значение указанного поля заголовка. Значение анализируется как число | ||
String getHeaderFieldKey (int n) | Получает указанное поле заголовка. Аргумент представляет собой индекс поля заголовка | ||
long getLastModif ied ( ) | Получает значение поля заголовка last-modified | ||
long getLength() | Извлекает длину поля заголовка. | ||
int getResponseCode ( ) | Получает код состояния отклика HTTP | ||
String getResponseMessage ( ) | Получает ответное сообщение HTTP | ||
String getType() | Получает тип содержимого, предоставляемого сервером (происходит из ContentConnection) |
Когда соединение находится в состоянии «установлено», вы можете лишь извлекать из него данные либо закрыть его. Вы можете задействовать методы, перечисленные в таблицах 8.7 и 8.9. Методы, показанные в таблице 8.8, извлекают различные части ответа HTTP, за исключением метода close (), который разрывает соединение.
Если соединение находится в состоянии «установлено», вы можете больше не активизировать методы, показанные в таблице 8.6. Вы не можете переустановить параметры запроса, что означает, что вы не можете снова использовать объект соединения для доступа к нескольким различным URI. Вы вынуждены создавать экземпляр нового соединения, пересылая новый URI в вызов Connector.ореп(). Кстати, либо клиент может прервать соединение после получения отклика, либо удаленный сервер может разорвать соединение послелосылки этого отклика.
Обратите внимание, что в листинге 8.4 порядок, в котором поля заголовков вставляются в сообщения запроса или извлекаются из ответного сообщения сервера, несущественен. Класс соединения имеет дело с абстракциями создания правильно сформированных сообщений HTTP и анализа ответов HTTP.
Методы интерфейса HttpConnection, вызываемые в состоянии «установлено»
Название метода HttpConnection | Описание | ||
void close () | Прерывает соединение (происходит из интерфейса Connection) | ||
String getFile() | Получает поле <file> URL данного соединения | ||
String getHostO | Получает поле <host> URL данного соединения | ||
int getPortO | Получает поле <port> URL данного соединения | ||
String getProtocol () | Получает поле <protocol> URL данного соединения | ||
:" i ing getQuery () | Получает строку запроса URL данного соединения | ||
String getRequestMethodf) | Получает текущий метод запроса (GET, POST и так далее) | ||
String getRequestProperty (String key) | Получает значение свойства указанного общего запроса данного соединения | ||
String getRef() | Получает поле <ref> URL данного соединения | ||
String getURL() | Получает полный URL данного соединения как строковое значение |
Использование соединений содержимого соединений. Сила, стоящая за использованием стандартных механизмов соединений содержимого соединений, заключается в том, что не требуется собственного проектирования для создания либо механизма доступа, либо согласованного формата полезного содержимого сообщений. Эта стандартизация служит мотивом поддержки механизма соединения HTTP в MIDP. HTTP является наиболее распространенным стандартным протоколом программного уровня в Интернете на сегодняшний день. Он дает вам возможность получать доступ к большому количеству разнообразных сетевых служб, поскольку поддерживает транспортировку произвольных данных с помощью своего механизма тегирования типа MIME.
Соединения HTTP могут транспортировать множество различных видов содержимого, такого, как HTML и XML. Кроме того, HTTP может использоваться как упаковщик для туннелирования других данных протокола уровня приложений. Вы, таким образом, имеете удобный механизм передачи данных для приложений клиент-сервер.
HTTP широко используется серверами как механизм передачи множества различных служб. Службы могут быть реализованы с помощью любой из множества технологий, независимо от того, что они используют HTTP в качестве механизма передачи. Службы могут быть реализованы с помощью сервлетов Java, Java Server Pages (JSP), Pearl scripts, CGI и так далее.
Модель сервлетов является особенно мощной, поскольку сервлеты написаны на Java и легко стыкуются с другими технологиями Java enterprise, они также без проблем взаимодействуют с клиентскими технологиями. Кроме того, сервлетные системы поддерживаются стандартными Web-серверами и могут без труда создавать выводимые данные в различных форматах. В главе 11 вы узнаете, как порталы беспроводного Интернета используют эти технологии для построения служб для мобильных устройств.
Методы интерфейса DatagramConnection
Название метода DatagramConnection | Описание | ||
int getMaximumLength ( ) | Выдает максимально возможную длину дейтаграммы, определен базовым протоколом реализации | ||
int getNominalLength ( ) | Выдает номинальную длину дейтаграммы | ||
Datagram newDatagram(byte [] buf, int size) | Создает новый объект дейтаграммы, получая данные из указанного массива | ||
Datagram newDatagram(byte [ ] buf, int size, String addr) | Создает новый обьект дейтаграммы с указанными массивом данных и с указанным адресом назначения | ||
Datagram newDatagramfint size) | Создает новый обьект дейтаграммы | ||
Datagram newDatagram (int size, String addr) | Создает новый обьект дейтаграммы с указанным адресом | ||
void receive (Datagram dgram) | Получает дейтаграмму и забирает ее данные для заполнения данного аргумента дейтаграммы | ||
void send (Datagram dgram) | Посылает указанную дейтаграмму |
Чтобы использовать дейтаграммное соединение, приложение-клиент выполняет следующие шаги:
Оно создает объект DatagramConnection.
Получает объект Datagram из объекта DatagramConnection.
Затем оно заполняет объект Datagram данными, составляющими полезную нагрузку, которая будет послана принимающему объекту.
Запрашивает соединение о посылке дейтаграммы.
Запрашивает соединение о получении ответной дейтаграммы.
Чтобы создать дейтаграммное соединение, вам все равно нужно использовать класс Connector. Вы указываете, что желаете получить дейтаграммное соединение, поставляя строковую дейтаграмму в поле схемы URI, который вы передаете одной или трем формам метода Connector.open(). Полный синтаксис дейтаграммных адресов следующий:
address := <протокол>://<адресат>
protocol := "datagram"
target := [<хост>]:<порт>
host := Значимое DNS-имя хоста или его номер>
port := Значимуй системный номер порта>
Указание полей хоста необязательно. Если вы пропускаете поле хоста, соединение представляет соединение сервера - реализация допускает, что объект, запрашивающий соединение, является сервером.
Серверы не инициируют передачу сообщений, так что для указания места назначения имя хоста не требуется. Соединение сервера ожидает клиента для посылки ему дейтаграммы. Сервер извлекает адрес посылающего из дейтаграммы, полученной им, и использует его для ответа. Пример указания соединения сервера:
datagram:/7:513
Если поле хоста указано, соединение открывается как соединение клиента. Реализация предполагает, что запрашивающий является клиентом, который инициирует соединение, поскольку он желает послать дейтаграмму адресованному узлу. Пример соединения клиента, указывающего известный компьютер:
datagram://server.foo.com:513
Когда соединение установлено, ваше приложение может использовать его для отправки и получения дейтаграмм. Интерфейс javax.microedition.io.Datagram определяет дейтаграммы, которые являются частями сообщения, посланными и полученными протоколами передачи дейтаграмм. Объект DatagramConnection посылает и получает объекты Datagram. Обратите внимание, что методы, указанные в таблице 8.9, содержат несколько ссылок на тип Datagram.
В таблице 8.10 перечислены методы интерфейса Datagram. Обратите внимание, что они отражают только следующие понятия:
адрес - представляет адрес посылающего или принимающего объекта;
полезная нагрузка - дейтаграмма рассматривает данные как один непрозрачный объект без интерпретации его формы, структуры или типа.
Это минимальная информация, требуемая всеми пакетами. Все дейтаграммы должны устанавливать эту информацию для того, чтобы пересылка прошла успешно.
В интерфейсе Datagram отсутствует информация о синтаксисе или семантике полезной нагрузки. Причина этого заключается всего лишь в том, что дейтаграммы не определяют синтаксиса или семантики данных, которые они переносят. Дейтаграммы просто рассматривают свою полезную нагрузку как последовательность байтов. Полезная нагрузка дейтаграммы определяется просто как byte [].
Дейтаграмма может содержать любую информацию. Дейтаграммная служба определяет формат и содержимое ее дейтаграмм.Посылающее и получающее устройства должны создавать дейтаграммы таким образом, чтобы они придерживались этих определений. То есть byte [] должен быть правильно написан посылающим и правильно проанализирован принимающим устройством.
Интерфейс Datagram происходит из интерфейсов Datalnput и DataOutput в пакете java.io. Такое происхождение гарантирует наличие удобного интерфейса для чтения двоичных данных из дейтаграммы и записи в нее. На рисунке 8.4 показана иерархия происхождения интерфейса Datagram. В таблице 8.11 перечислены методы интерфейса Datalnput, а в таблице 8.12 перечислены методы интерфейса DataOutput. Эти интерфейсы идентичны интерфейсам пакета java.io J2SE.
Методы интерфейса Datagram
Название метода интерфейса Datagram | Описание | ||
String getAddress () | Выдает адрес в данной дейтаграмме | ||
byte [] getData() | Выдает буфер, содержащий полезную нагрузку дейтаграмм | ||
int getLength() | Выдает длину полезной нагрузки дейтаграммы | ||
int getOffsetO | Выдает смещение указателя для чтения/записи в буфере полезной нагрузки | ||
void reset() | Восстанавливает позицию указателя для чтения/записи в буфере полезной нагрузки | ||
void setAddress (Datagram reference) | Устанавливает, что адрес данной дейтаграммы является адресом указанной дейтаграммы | ||
void setAddress (String addr) | Устанавливает адрес, указываемый строкой | ||
void setData (byte[] buffer, int offset, int len) | Устанавливает полезную нагрузку данной дейтаграммы | ||
void setLength (int len) | Устанавливает длину полезной нагрузки дейтаграммы |
В дополнение к согласованию формата, посылающее и принимающее устройства должны быть способны определять местонахождение друг друга. Каждая служба имеет связь со стандартным портом. Эта связь гарантирует, что клиент знает, как установить соединение с сервером, который предоставляет желаемую службу.
Методы интерфейса Datalnput
Название метода Datalnput | Описание | ||
boolean readBoolean ( ) | Считывает только значение Boolean из входного потока | ||
byte readByte() | Считывает один байт из входного потока | ||
char readCharf) | Считывает символ из входного потока | ||
void readFully (byte [] b) | Считывает байты из входного потока, пока указанный массив не наполнится | ||
void readFully(byte[] b, int off, int len) | Считывает указанное число байт в указанный буфер, начиная с указанного сдвига | ||
int readlnt() | Считывает значение int из входного потока | ||
long readLong() | Считывает значение long из входного потока | ||
short readShort() | Считывает два входных байта и выдает значение short | ||
int readUnsignedByte() | Считывает один байт, дополненный нулями, из потока | ||
int readUnsignedShort () | Считывает два входных байта и выдает значение int | ||
String readUTF() | Считывает в UTF-8 шифрованную строку символов | ||
int skipBytes (int n) | Просматривает п байтов из входного потока |
Методы интерфейса DataOutput
Название метода DataOutput | Описание | ||
void writeByte (byte [ ] b) | Записывает все байты в выходной поток | ||
void write (byte[] b, int off, int len) | Записывает указанное число байтов в выходной поток, начиная от смещения | ||
void write (int b) | Записывает младший байт в выходной поток | ||
void writeBoolean (boolean v) | Записывает значение boolean | ||
void writeByte (int v) | Записывает младший байт int | ||
void writeChar (int c) | Записывает два младших байта в выходной поток | ||
void writeChars (String s) | Записывает каждый символ в уникоде в выходной поток | ||
void writelnt(int v) | Записывает int (четыре байта) в выходной поток | ||
void writeLong (long v) | Записывает значение long (четыре байта) в выходной поток | ||
void writeShort (int v) | Записывает int как два байта в выходной поток | ||
void writeUTF(String s) | Записывает каждый символ в формате Java LJTF, которому предшествуют два байта, показывающие длину в байтах |
Например, если приложение MIDP хочет взаимодействовать со стандартным демоном синхронизирующего сетевого протокола Unix (Unix Network Time Protocol (NTP)), оно должно создать соединение, которое использует стандартный номер порта демона NTP, то есть 123. Приложение-клиент MIDP должно задать формат полезной нагрузки ответных дейтаграмм, придерживаясь определения NTP. Оно также должно быть способно анализировать ответ, возвращенный сервером.
MIDP кое в чем отличается от платформы J2SE в своей поддержке дейтаграммных соединений. J2SE имеет пакет java.net. Например, ее класс, DatagramPacket определяет дейтаграмму. Класс DatagramSocket реализует протокол передачи дейтаграмм с помощью соединений сокета.
Эти классы не существуют в CLDC/MIDP. В действительности пакет java.net недоступен в CLDC/MIDP. С другой стороны, CDC содержит пакет java.net, который содержит эти классы.
В листинге 8.5 демонстрируются вышеописанные понятия. Код, описанный в этом листинге, является дейтаграммным клиентом, который соединяется с определенной дейтаграммной службой.
Важными шагами, выполняемыми программой, являются следующие:
Она получает новый объект DatagramConnection.
Получает объект Datagram из DatagramConnection.
Заполняет Datagram должным образом отформатированной семантической информацией, которая составляет запрос (как разработчик, удостоверьтесь, что длина дейтаграммы не превышает максимальной длины, позволенной протоколом).
Получает ответную Datagram от DatagramConnection. Этот вызов блокирует обработку до тех пор, пока дейтаграмма не будет получена или время вызова не истечет.
Обрабатывает данные в дейтаграмме.
Повторяет цикл для следующих взаимодействий.
Программа, описанная в листинге 8.5, на самом деле не осуществляет этап 3. Его выполнение требует создания должным образом отформатированного сообщения, как ожидается службой, с которой соединяется клиент. Также «обработка», указанная в шаге 5, включает лишь вывод ответа сервера в стандартный результат. В настоящих приложениях клиент использовал бы дейтаграммную информацию для локальной обработки.
Методы интерфейса StreamConnectionNotifier
Метод StreamConnectionNotifier | Описание | ||
StreamConnection acceptAndOpen () | Возвращает новый потоковый обьект, связанный с новым сокетом и соединенный с запрашивающим клиентом |
Клиенты запрашивают соединение у известного сокета, создавая клиентский запрос соединения в стандартной форме. Например, следующий оператор представляет клиентский запрос соединения:
StreamConnection conn =
Connector.open("socket://server.foo.com:98765");
Клиенты должны включать имя сервера, поддерживающего службу; номер порта представляет известный сокет сервера. Клиенты, которые хотят соединиться со службой на локальной машине, могут использовать обозначение localhost для сервера, как показано в следующем вызове:
StreamConnection conn =
Connector.open("socket://localhost:98765");
Оба вызова StreamConnectionNotifier.acceptAndOpen(} сервера и Connector.open() клиента создают объект StreamConnection. Вы уже видели класс StreamConnection при нашем обсуждении коммуникационных портов.
Вы можете быть удивлены, почему структура общих соединений использует интерфейс StreamConnection для представления сокетных соединений, а также для соединений с коммуникационными портами. Причина этого заключается в том, что данное общее название, как оно само и предполагает, представляет оба типа соединений как потоки байтов. Более того, оно может представлять любой другой тип поточно-ориентированного соединения, даже если оно использует другой протокол.
Нигде не оговаривается, какие виды протоколов может представлять интерфейс StreamConnection. Интерфейс извлекает подробную информацию о реализации протокола из приложения. Приложения не осведомлены о платформно-определяемых классах, которые реализуют интерфейсы. Хотя реализации интерфейса структуры общих соединений могут варьироваться, они должны поддерживать указанное поведение и семантику интерфейса.
Важно заметить, что не все реализации поддерживают серверные сокеты. И, из тех, что делают это, некоторые в настоящее время работают не совсем правильно.
Если поддержка серверных сокетов недоступна на вашей реализации, но вы по некоторой причине должны использовать сокеты, вам придется разработать схему, по которой клиент сможет соединяться с «сервером». Сервер не сможет поддерживать модель известного сокета, ему придется определить другую модель, которая позволит клиентам получить средство установления соединения.
В листингах 8.6 - 8.8 демонстрируется набор классов, которые составляют структуру сокетных коммуникаций в MIDP. Смысл заключается в том, что эти классы будут использоваться приложением, которое нуждается в сокетных коммуникациях. Эти примеры составляют не больше чем основу, которая формирует базовую структуру поддержки сокетных взаимодействий. Они не являются функционирующими приложениями.
Некоторые данные были проигнорированы в этом коде. Например, сама сетевая служба не определена, нет определения синтаксиса или семантики сообщения протокола уровня приложений. Кроме того, код не обращается к очистке рабочих нитей со стороны сервера. Следующие классы являются классами, составляющими данный пример:
ServerSocket - определяет демон сервера, который прослушивает известный сокет на предмет клиентских запросов соединения.
Server Agent - определяет объект, один экземпляр которого демон создает для каждого клиентского запроса. Каждый экземпляр взаимодействует с клиентом. Данный класс определяет действительную службу.
ClientSocket - представляет клиента.
MIDP поддерживает организацию сетей через свой пакет javax.microedition.io. Он предоставляет поддержку базовых коммуникационных протоколов без установления соединения и ориентированных на соединения.
Главный вопрос при проектировании сетевого пакета MIDP заключается в понятии структуры общих соединений. Она определяет общий механизм создания сетевых соединений для приложений. Кроме того, она определяет различия в установке и использовании различных видов соединений, которые затрагивают различные протоколы.
Эта структура дает возможность писать код приложения независимо от определенного вида соединения, которое будет использоваться. Эта независимость важна в мобильных средах, где природа базовых сетей может затронуть доступные службы приложения.
Класс Connector, создающий соединение, извлекает подробную информацию о запрашивании и получении различных видов соединений, которые используют различные базовые коммуникационные протоколы. С помощью создателя соединения приложения запрашивают о доступе к сетевым ресурсам. Ресурсы пересылаются приложениям через соединения, которые используют коммуникационный протокол, указанный в запросе соединения.
Иерархия типов соединений представляет различные типы соединений, которые может создать приложение. Определения различных интерфейсов этих типов соединений отражают протоколы, используемые различными типами соединений. Они также отражают желаемую семантику типа соединения.
Существует четыре базовых категории соединений. Потоковые соединения, поддерживающие соединения с коммуникационными портами, соединения уровня приложений со службами HTTP и базовые соединения сокета стиля Unix. Дейтаграммные соединения поддерживают соединения со службами передачи дейтаграмм.
В MIDP отсутствует поддержка других протоколов уровня приложений, таких, как RMI, CORBA или Jini. Причина этого кроется в том, что персональные мобильные устройства лишены требуемой мощности для поддержки этих механизмов распределенной обработки данных.
Новые профили, которые были встроены поверх CDC, предоставляют возможности, такие, как RMI. Создатели MIDP должны с осторожностью рассматривать то, какие коммуникационные возможности им необходимы для каждого приложения, и создавать свои приложения с расчетом на доступные.