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

На рисунке 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, протоколы дейтаграмм не определяют атрибуты, которые отражают природу полезной нагрузки, которую они транспортируют.

Программа ConnectionDemo

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

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 описывает

Листинг 8.2. Класс 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

Листинг 8.3. Класс ResourceDisplay определяет форму, которая отображает ресурс. Он использует объект helper для получения этого ресурса

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

Листинг 8.4. Класс 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, работают с извлечением данных из ответного сообщения. Чтобы извлечь данные, соединение с сервером должно быть действующим, чтобы клиент получил ответное сообщение.

Дейтаграммы посылаются

Листинг 8.5. Дейтаграммы посылаются и получаются дейтаграммным соединением. Эта программа анализирует полезную нагрузку полученной дейтаграммы и отображает ее на экране

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. Таким образом, вы эффективно переписываете данные любой предыдущей операции, гарантируя, что вы не смешаете байты двух отдельных сообщений.

Сервер порождает новую

Листинг 8.6. Сервер порождает новую нить для создания объекта со стороны сервера, который взаимодействует с каждым клиентом. Клиент и сервер должны определять семантику своих сообщений

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;
)
}
}
}

Агент сервера является

Листинг 8.7. Агент сервера является объектом, который взаимодействует с клиентом независимо от демона сервера. Он запускает свою собственную нить, позволяя другим экземплярам одновременно взаимодействовать со своими клиентами

import javax .microedition. io._StreamConnectior.;
/**
Данный класс определяет компоненту, которую сервер
создает для взаимодействия с клиентом.
Он действует как «агент» от имени сервера для того, чтобы сервер
был свободен для прослушивания только новых запросов соединения.
Экземпляры данного класса являются частью сервера.
*/
public class ServerAgent implements Runnable
private StreamConnection conn;
/**
Конструктор.
@param с Объект соединения, который представляет
соединение с клиентом. Класс ServerSocket создает и пересылает
его в данный конструктор.
*/
public ServerAgent(StreamConnection c)
super ();
conn = с;
}
/**

Выполняется агент данного сервера. Начинается диалог с клиентом. Этот метод должен быть вызван явно после того, как создан данный объект.

public void run()
}
// Взаимодействует с клиентом. Реализует поведение,
// которое определяет данную службу.
}
}

Клиент имеет отдельно

Листинг 8.8. Клиент имеет отдельно соединение с агентом сервера. Модель состояния взаимодействий, а также синтаксис и семантика взаимодействий определяются сервером, но клиенты должны им подчиняться

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");

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

Производящий соединения блок создает

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

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

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

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

Различия между организацией сетей В 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	Описание
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	Описание
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 поддерживает организацию сетей через

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

MIDP поддерживает организацию сетей через свой пакет javax.microedition.io. Он предоставляет поддержку базовых коммуникационных протоколов без установления соединения и ориентированных на соединения.
Главный вопрос при проектировании сетевого пакета MIDP заключается в понятии структуры общих соединений. Она определяет общий механизм создания сетевых соединений для приложений. Кроме того, она определяет различия в установке и использовании различных видов соединений, которые затрагивают различные протоколы.
Эта структура дает возможность писать код приложения независимо от определенного вида соединения, которое будет использоваться. Эта независимость важна в мобильных средах, где природа базовых сетей может затронуть доступные службы приложения.
Класс Connector, создающий соединение, извлекает подробную информацию о запрашивании и получении различных видов соединений, которые используют различные базовые коммуникационные протоколы. С помощью создателя соединения приложения запрашивают о доступе к сетевым ресурсам. Ресурсы пересылаются приложениям через соединения, которые используют коммуникационный протокол, указанный в запросе соединения.
Иерархия типов соединений представляет различные типы соединений, которые может создать приложение. Определения различных интерфейсов этих типов соединений отражают протоколы, используемые различными типами соединений. Они также отражают желаемую семантику типа соединения.
Существует четыре базовых категории соединений. Потоковые соединения, поддерживающие соединения с коммуникационными портами, соединения уровня приложений со службами HTTP и базовые соединения сокета стиля Unix. Дейтаграммные соединения поддерживают соединения со службами передачи дейтаграмм.
В MIDP отсутствует поддержка других протоколов уровня приложений, таких, как RMI, CORBA или Jini. Причина этого кроется в том, что персональные мобильные устройства лишены требуемой мощности для поддержки этих механизмов распределенной обработки данных.
Новые профили, которые были встроены поверх CDC, предоставляют возможности, такие, как RMI. Создатели MIDP должны с осторожностью рассматривать то, какие коммуникационные возможности им необходимы для каждого приложения, и создавать свои приложения с расчетом на доступные.

I18NDemo midlet; 37 38 // Уведомление

36 I18NDemo midlet;
37
38 // Уведомление, отображаемое в ответ на
39 // активацию некоторых команд данной Form.
40 Alert alert;
41
42 // Команды, размещаемые в данной форме.
43 private Command showAlert;
44 private Command sayHi;
45 private Command cancel;
46 private Command exit;
47 private Command help;
48 private Command item;
49 private Command ok;
50 private Command screen;
51 private Command stop;
52
53 /**
54 Конструктор No-arg. Устанавливает заголовок по умолчанию
55 для данной формы.
56 */
57 HelloForm()
58 {
59 this(DEFAULT_TITLE);
60 }
61
62 /**
63 Конструктор.
64
65 @param title - заголовок Form.
66 */
67 HelloForm(String title)
68 {
69 super(title);
70
71 midlet = IISNDemo.get Instance()
72
73 // Добавляет строковый элемент в форму.
74 String msg = midlet.getResource("greeting" );
75 append(msg);
76
77 display = Display.getDisplay(midlet);
78
79 // Добавляет MyCommandListener в Form для прослушивания
80 // события нажатия клавиши «Back», которое должно
81 // создавать всплывающее диалоговое уведомление Alert.
82 setCommandListener(cl);
83
84 showAlert = new
85 Command(midlet.getRe source("alert") ,
86 Command.SCREEN, 1);
87 addCommand(showAlert);
88
89 sayHi = new .
90 Command(midiet.getResource("sayhi"),
91 Command.SCREEN, 1);
92 addCommand(sayHi);
93
94 cancel = new
95 Command{midlet.getResource("cancel"),
96 Command. SCREEN,, 1) ;
97 addCommand(cancel) ;
98
99 exit = new
100 Command(midlet.getResource("exit") ,
101 Command.SCREEN, 1);
102 addCommand(exit);
103
104 help = new
105 Command(midlet.getResource("help"),
106 Command.SCREEN,, 1);
107 addCommand(help) ;
108
109 item = new
110 Command(midiet.getResource("item"),
111 Command.SCREEN, 1);
112 addCommand(item);
113
114 ok = new
115 Command(midlet.getResource("ok"),
116 Command.SCREEN, 1);
117 addCommand(ok) ;
118
119 screen = new
120 Command(midlet.getResource("screen"),
121 Command.SCREEN, 1);
122 addCommand(screen);
123
124 stop = new
125 Command(midlet.getResource("stop"),
126 Command.SCREEN, 1);
127 addCommand(stop) ;
128 }
129
130 // Данный класс просто прослушивает активацию
131 // какой-либо команды. Экземпляр HelloForm
132 // устанавливает экземпляр данного класса как
133 // свой блок прослушивания команд. Экземпляр
134 // объекта не проверяет информацию команды, а
135 // просто отображает модальное Ale показывающее,
136 // что экранная клавиша была активирована пользователем.
137 private class MyCoramandListener
138 implements CommandLister.er
139 {
140 public void commandAction(Command c,
141 Displayable d)
142 {
143 String title =
144 midlet.getResource("alert_title") ;
145 String msg = null;
146
147 if (c == showAlert)
148 {
149 msg = midlet.getResource("alert_text");
150 alert = new Alert(title,
151 msg,
152 null, AlertType.INFO);
153 alert.setTimeout(Alert.FOREVER);
154 display .setCurrer.t (alert, HelloForm.this);
155 }
156 else if (c == sayHi)
157 {
158 alert = new Alert("Button pressed",
159 msg,
160 r.ull, AlertType.INFO);
161 alert.setTimeout(Alert.FOREVER);
162 display.setCurrent(alert, HelloForm.this);
163 }
164
165 if (c == exit)
166 {
167 IISNDemo.get Instance().destroyApp (true);
168 }
169 }
170 }
171 }

Проблема разработки интернационализации заключается в схеме поиска, используемой для нахождения локализованных строк в файле JAD. Программно определяемый метод getResource (String key), заданный в строках с 103 по 115, на самом деле определяет и реализует схему поиска. Чтобы обнаружить ресурс, метод getResource (String key) создает имя атрибута, а затем ищет сам атрибут.

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

String formTitle = getResource("title");
form = new HelloForm(formTitle);

Метод создает полное имя атрибута, объединяя три строки: 118NDemo - префикс атрибута для данного приложения, идентификатор атрибута ресурса без какой-либо меняющейся в зависимости от региональной настройки информации и обозначение региональной настройки. Параметр строки title является идентификатором атрибута ресурса, а не заголовком формы.

В строке 36 MID-лет определяет префикс атрибута I18NDemo-. Метод startApp() извлекает информацию о контексте региональной настройки, в котором исполняется приложение, из системного свойства microedition.locale и сохраняет его как экземпляр атрибута.

Объект HelloForm использует значение, выданное вызовом getResource(), как его заголовок. Класс HelloForm в листинге 9.3 повторяет этот сценарий. Он просто вызывает getResource() для поиска локализованных значений всех текстов, которые пользователь видит во время исполнения приложения.

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

Альтернативный подход заключается в создании нескольких версий файла JAD приложения так, чтобы каждая версия содержала атрибуты для каждой региональной настройки. Добавьте соответствующую версию JAD для требуемого контекста региональной настройки. Конечно, вам понадобится определить контекст локальной настройки, в которой будет использоваться телефон, или просто местные настройки пользователя.

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

Взглянув на метод getResource(), показанный в строчках с 103 по 115, вы увидите, что он использует метод MIDlet.getAppProperty() для извлечения ресурсов из файла дескриптора приложения и файла манифеста. Если атрибут существует в обоих файлах с абсолютно одинаковыми именами ключа, тогда значение извлекается из файла дескриптора приложения и значение в файле манифеста игнорируется. Если не найдено ни одного атрибута или если для ключа не найдено ни одного значения, выдается значение ноль. Если вводимый ключ не найден, сбрасывается NullPointerException.

Значения атрибутов в файле JAD (или манифеста) должны быть кодированы с помощью символьной кодировки, которая поддерживает нужный язык. Существует два способа выполнения этого:

Кодировать значения атрибутов с помощью символьной кодировки, предназначенной для языка региональной настройки. Символьная кодировка может быть той, что соответствует более чем одному лишь нужному языку, как, например, LJTF-8. Кодировать значения атрибутов с помощью последовательностей переключения кода Уникод, например \u4EA9. Файл все равно состоит только из символов ASCII, но последовательности переключения уникода могут представлять любой символ любого письменного языка.

Листинг 9.2 включает поддержку английской и французской региональных настроек. Символьная кодировка ISO8859-1 может представлять английский и французский алфавиты. Если вы желаете локализовать данное приложение на языки, не поддерживаемые семейством ISO8859 (китайский, например), вам придется кодировать значения атрибутов с помощью соответствующей многобайтовой символьной кодировки.

Если вы выбрали первый из только что описанных подходов (кодирование с помощью символьной кодировки, предназначенной для языка региональной настройки), вам понадобится найти текстовой редактор, который поддерживает методы ввода китайского языка и записывает символы в соответствующую кодировку. Либо вы можете использовать второй подход и вводить последовательности переключения уникода Java для каждого символа. Просто найдите точку кодирования уникода для каждого символа в вашей строке. Этот подход работает, поскольку класс Java.lang.String знает, как создавать строковые объекты из последовательностей переключения уникода. Ваше приложение может затем считывать значения атрибутов и создавать из них объекты String.

Вы можете определить имена атрибутов с помощью панели Settings J2MEWTK. Поскольку WTK не поддерживает ввод не-ASCII текста, однако, вы не можете определить не английский локализованный текст значений атрибутов. Чтобы ввести не английские символы, вам придется использовать текстовой редактор для ввода символов непосредственно в файл JAD. Вы можете использовать тот, что поддерживает редакторы методов ввода (IME) для назначенного языка, или вводить последовательности переключения уникода.

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

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

I18NDemo-number_forraat-fr_FR: NumberFormat_FR

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

...
try
{
String name =
getAppProperty("I18NDemo-number_format-fr_FR");
// "name" теперь эквивалентно "NumberFormat_FR"
Class с = Class.forName(name);
NumberFormat_FR nf =
(NumberFormat_FR) с.new Instance();
}
catch (InstantiationException ie)
{
...
}
catch (IllegalAccessException iae)
{
...
catch (ClassNotFoundException cnfe)
{
...
}
...

Конечно, вы должны предоставить MIDP-совместим'ый классификационный файл Java с файлом JAR вашего приложения для того, чтобы эта схема работала.

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

Кроме того, этот единственный файл JAD должен соответствовать всем МЮ-летам в наборе MID-летов, что делает его еще больше. При использовании файла JAD не в простой демонстрационной программе, а где-либо еще он станет слишком громоздким, так как число атрибутов вырастет.

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

Загружает определенные

127 /**
128 Загружает определенные пользователем ресурсы приложения
129 из указанного файла. Файл является частью файла JAR
130 приложения, расположенного на реальном устройстве.
131 J2MEWTK хранит файл в файле JAR приложения, расположенном
132 в директории приложения bin/.
133
134 @param file - имя определенного пользователем файла
135 ресурса приложения.
136 */
137 private int loadResources(String file)
138 {
139. Class с = getClass () ;
140
141 if (file == null)
142 {
143 return -1 ;
144 }
145 InputStream is = null;
146 is = с.getResourceAsStream(file);
147 if (is == null)
148 {
149 return -1;
150 }
151 Reader reader = new InputStreamReader(is);
152 processStream(reader);
153 return 0;
154 }
155
156 /**
157
158 */
159 private void processStream(Reader stream)
160 {
161 if (stream == null)
162 {
163 return;
164 }
165 StringBuffer key = new StringBuffer();;
166 StringBuffer value = new StringBuffer ();;
167 while (true)
168 {
169 // Считываем строку. Предполагается, что каждая строка
170 // содержит ключ и значение,
171 // отделенные двоеточием. Если -1, значит
172 // мы достигли конца файла.
173 key.deletef(), key.length());
174 value.delete(0, value.length());
175 int status = readLine(key, value, stream);
176 if (status == -1)
177 {
178 break;
179 }
180
181 // Вставляем этот ресурс в хэшированную таблицу
182 // ресурсов приложения.
183 resources.put(key, value);
184 }
185 }
186
187 /**
188 Считывает и обрабатывает следующую не пустую строку
189 из потока. Формат строки ожидается следующий
190 <ключ>[ \t]*:[ и]*<значение>, где
191 <ключ> and <значение> являются метками, состоящими
192 из буквенных символов или знаков пунктуации, но не
193 из пустых знаков пробела.
194 */
195 private int readLine(StringBuffer key,
196 StringBuffer value,
197 Reader stream)
198 {
199 if (key == null || value == null ||
200 stream == null)
201 {
202 return -1;
203 }
204
205 try
206 {
207 char c;
208 while (true)
209 {
210 // Пропускаем символы новой строки.
211 while (true)
212 {
213 с = (char) stream.read ();
214 if (c == r\n')
215 {
216 continue;
217 }
218 break;
219 }
220
221 if (lisWhiteSpace(c) Si !isDelimeter(c))
222 {
223 key.append(c);
224 }
225
226 // Пропускаем впередиидущий пробел.
227 while (true)
228 {
229 с = (char) stream.read();
230 if (isWhiteSpace (c))
231 {
232 continue;
233 }
234 break;
235 }
236
237 if (lisWhiteSpace(c) S& !isDelimeter(c))
238 {
239 key.append (с);
240 }
241
242 // Считываем ключ.
243 while (true)
244 {
245 с = (char) stream.read();
246 if (isWhiteSpace(c) II isDeliraeter(c))
247 {
248 break;
249 }
250 else
251 {
252 key.append(c);
253 }
254 }
255
256 // Пропускаем пробел, идущий перед или
257 // после символа.
258 while (true)
259 {
260 с = (char) stream.read();
261 if (isWhiteSpace(c) II isDelimeter(c))
262 {
263 continue;
264 }
265 value.append(c);
266 break;
267 }
268
269 // Считываем остальную часть значения метки.
270 while (true)
271 {
272 с = (char) stream.read();
273 if (c == '\n')
274 {
275 break;
276 }
277 else
278 {
279 value.append(c);
280 }
281 }
282 break;
283 }
284 }
285 catch (lOException ioe)
286 {
287 ioe.printStackTrace() ;
288 return -1;
289 }
290 return 0;
291 }
292
293 /**
294
295 */
296 private boolean isWhiteSpace(char c)
297 {
298 if (c == ' ' И с == '\t')
299 {
300 return true;
301 }
302 else
303 {
304 return false;
305 }
306 }
307
308 /**
309
310 */
311 private boolean isDelimeter(char c)
312 {
313 if (c == ':')
314 {
315 return true;
316 }
317 return false;
318 }
319
320 /**
321 Выдает значение, связанное с указанным
322 ключом из пакета ресурсов приложения.
323
324 @param key - ключ пары «ключ-значение».
325
326 @выдает значение, связанное с
327 указанным ключом.
328 */
329 private String getResource(String key)
330 {
331 if (resources == null)
332 {
333 return null;
334 }
335 return (String) resources .get (-key) ;
336 }
337
338 /**
339 Прекращает выполнение. Запрашивает реализацию
340 на завершение данного MID-лета.
341 */
342 public void quit()
343 {
344 notifyDestroyed ();
345 }
346
347 public void destroyApp(boolean destroy)
348 {
349
350 }
351
352 public void pauseApp()
353 {
354
355 }
356 }

Acпекты интернационализации

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

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

Для поддержки вышеупомянутых свойств интернационализированное приложение должно выполнять некоторое динамическое конфигурационное и информационное извлечение. Обычно приложение определяет свой контекст региональной настройки динамически при запуске. Затем оно конфигурирует все необходимые компоненты выполнения - такие, как календарные объекты, сортировщики строк, объекты задания формата и компоненты работы с сообщениями - которые должны отвечать требованиям контекста региональной настройки.

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

определение среды региональной настройки устройства; загрузка локализованных ресурсов приложения; динамический поиск и извлечение локализованных ресурсов для отображения пользовательского интерфейса; отображение локализованных ресурсов.

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

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

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

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

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

25 decembre 2002
2002/12/25
25/12/2002

08.30
14.45

20.000,45 (двадцать тысяч и сорок пять сотых)

В Соединенных Штатах, однако, те же самые значения обычно пишутся следующим образом:

December 25, 2002
12/25/2002

8:30 am
2:45 pm

20,000.45 (двадцать тысяч и сорок пять сотых)

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

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

Cтроковая сортировка

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

Cтруктуры интернационализации

В основном проблема всех разработок интернационализации заключается в поиске механизма, который дает возможность приложениям извлекать правильную версию локализованных ресурсов при работе. В отличие от J2SE, MIDP не имеет реального API или классов, которые поддерживают общее извлечение локализованных ресурсов. Здесь нет класса ResourceBundle или каких-либо его подклассов. Приложения MIDP должны создавать свои собственные механизмы для определения и извлечения локализованного ресурса. В реальности, наиболее жизнеспособными подходами являются:

извлечение локализованных ресурсов из файла JAD; извлечение локализованных ресурсов из текстового файла, который является частью файла JAR приложения; извлечение локализованных ресурсов из классификационного файла Java, такого, как определяемый приложением механизм упаковки пакетов ресурсов стиля J2SE.

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

Форматирование дат времени и чисел

Форматирование дат, времени и чисел

MIDP не предоставляет поддержки форматирования дат, времени, числовых или денежных значений. В MIDP нет классов платформы J2SE, которые поддерживают это форматирование: здесь нет классов DateFormat, NumberFormat и DecimalFormat. Однако производители могут предоставлять определяемые реализацией классы для поддержки этих возможностей форматирования.

MIDP определяет классы Date и TimeZone в своем пакете java.util, но эти классы на самом деле не интернационализированы. То есть их интерфейсы не определяют каких-либо возможностей, которые связаны с чувствительной к региональным настройкам обработкой.

Класс Date просто представляет определенный экземпляр формата времени в Универсальном синхронизированном времени (UTC). В MIDP нет поддержки изменения значения Date на представление временного значения в любой другой временной зоне или для форматирования временных значений при отображении пользователям. Платформа J2SE, однако, имеет связанные классы (такие, как DateFormat), которые могут форматировать значения даты в манере, принятой в данном регионе. В MIDP нет таких классов.

MIDP поддерживает временные зоны с помощью своего класса java.util.TimeZone. Этот класс абстрактен. Ваша реализация MIDP предоставит, по крайней мере, один конкретный подкласс, который представляет временную зону GMT. Спецификация MIDP требует поддержки только временной зоны GMT, однако ваша реализация может также поддерживать другие зоны.

Метод TimeZone.getDefault() выдает объект TimeZone, который представляет временную зону, устанавливаемую по умолчанию, для сервера, на котором ваше приложение запущено. Убедитесь, что он может определить временную зону GMT, даже если это не временная зона, в которой работает приложение вашего компьютера.

Метод TimeZone.getTimeZone(String id) выдает объект TimeZone для трехбуквенного обозначения аргумента временной зоны, указанного в вызове. Имейте в виду, что выдаваемый объект может не представлять временную зону, которую вы запрашивали, потому что реализация не поддерживает ее. Очевидно, для вас как для разработчика приложения важно знать, в каких временных зонах поддерживается ваша платформа.

Инициализация приложения с локализованными ресурсами

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

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

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

Использование атрибутов МIDлета

Использование атрибутов МID-лета для определения локализованных ресурсов

Как вы знаете, вы можете размещать определяемые пользователем атрибуты в файле JAD вашего приложения. Это означает, что вы можете использовать файл JAD для определения атрибутов MID-лета, которые представляют локализованные ресурсы, используемые вашим приложением.

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

Для демонстрации данного подхода я вновь использовал демонстрационную программу HelloWorld из главы 3. Приложение переименовано на IISNDemo для отличия его от оригинальной версии.

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

Использование классификационных

Использование классификационных файлов Java для определения интернационализированных ресурсов

В данном третьем подходе приложения определяют классы Java, которые содержат локализованные ресурсы. Каждый класс содержит ресурсы для одной региональной настройки. Файлы откомпилированы и упакованы как часть JAR приложения. При работе локализованные ресурсы затем достаются с помощью создания экземпляра соответствующего класса.

Эта разработка аналогична разработке иерархии пакетов ресурсов J2SE. Классы java.util.ResourceBundle и java.util.ListResourceBundle J2SE являются абстрактными классами, определяющими структуру создания агрегаций произвольных чувствительных к региональным настройкам объектов Java. Эти объекты могут быть любыми объектами Java.

Этот подход к разработке интернационализации определяет свою собственную версию классов ResourceBundle и ListResourceEundle J2SE. В листингах 9.7 и 9.8 показаны их реализации, которые определяют, соответственно, подмножества классов ResourceBundle и ListResourceBundle платформы J2SE. Хотя эти реализации являются собственными, сигнатуры методов являются теми же, что и у их аналогов в J2SE.

Использование текстовых файлов

Использование текстовых файлов приложения для определения локализованных ресурсов

Второй подход к локализации использует программно определяемые текстовые файлы, которые содержат локализуемые атрибуты. Приложение с помощью данной схемы может, например, определить один файл локализованных атрибутов для каждой региональной настройки. Схема имен может соответствовать обозначению региональной настройки, например, en_US.txt для английской, fr_FR.txt для французской, ja_JP.txt для японской и так далее. В листинге 9.4 показан один пример такого файла, содержащего пары «ключ-значение» локализованных строк.

Файл JAD содержит

Листинг 9.1. Файл JAD содержит один атрибут на строку приложения на поддерживаемую региональную настройку

I18NDerao-alert-en_US: Alert
I18NDemo-alert-fr_FR: Alerce
H8NDemo-alert_text-en_US: The button was pressed
I18NDemo-alert_text-f£_FR: Le bouton a ete presse
I18NDemo-alert_title-en_US: Button Pressed
I18NDemo-alert_title-fr_FR: Eouton a ete Presse
I18NDemo-cancel-en_US: Cancel !18NDemo-cancel-fr_FR: Quitter
I18NDemo-exit-en_US: Exit IlSNDemo-exit-fr_FR: Sortie
I18NDemo-greeting-en_US: Another MIDlet!
I18NDerao-greeting-fr_FR: Un autre MIDlet!
I18NDemo-help-en_US: Help I18NDemo-help-fr_FR: Aider
I18NDemo-item-en_US: Item I18NDemo-item-fr_FR: Item,
I18NDemo-menu-en US: Menu
I18NDemo-menu-fr_Fr: Menu
I18NDemo-ok-en_US: OK
I18NDemo-ok-fr_FR: OK
I18NDe:r.o-sayhi-en_US: Say hi
I18NDemo-sayhi-fr_FR: Dis bonjour
I18NDemo-screen-en_US: Screen
I18NDemc-screen-fr_FR: Ecran I18NDemo-stop-en_US: Stop
I18NDemo-stop-fr_FR: Arreter I18NDemo-title-en_US: Hello, World
I18NDemo-title-fr_FR: A116, tout le Monde MIDlet-1: I18N Demo 1,
I18n.png, I18NDemo MIDlet-Info-URL:
MIDlet-Jar-Size: 19101 MIDlet-Jar-URL: ilSn.jar MIDlet-Name:
I18n MIDlet-Vendor: Vartan Piroumian MIDlet-Version: 1.0

Имена атрибутов в файле JAD, показанные в листинге 9.1, приобретают следующую форму:

<название МID-лета>
-<ключ>
-<обозначение региональной настройки>

Например, следующие два атрибута определяют заголовок MID-лета на английском и французском языках:

I18NDemo-title-en_US: Hello, World .
I18NDemo-title-fr_FR: A116, tout le Monde

В листингах 9.2 и 9.3 показаны два файла, которые составляют исходный код приложения. Они определяют и реализуют схему поиска атрибутов, отражаемую именами атрибутов в файле JAD. Программа извлекает версию атрибута, связанного с контекстом региональной настройки, в котором приложение работает.

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

Измененный класс HelloWorld

Листинг 9.2. Измененный класс HelloWorld называется IlSNDemo. Он использует схему поиска для извлечения правильной версии атрибутов строки приложения, базируясь на региональной настройке

1 import javax.microedition.midlet.MIDlet;
2
3 import javax.microedition.Icdui.Display;
4 import javax.microedition.Icdui.Displayable;
5 import javax.microedition.Icdui.Form;
6
7 /**
8 Первая версия приложения IlSNDemo.
9
10 <р>
Данная версия демонстрирует простейший подход к
11 загрузке локализованных ресурсов из файла JAD MID-лета.
12 этот подход быстро становится непригодным при большом
13 количестве ресурсов. И он полезен только для текстовых
14 сообщений, но не для других видов локализованных
15 ресурсов.
16 */
17 public class IlSNDemo extends MIDlet
18 {
19 // Региональная настройка, указанная для выполнения в
20 // данном MID-лете.
21 private String locale;
22
23 // Displayable. Этот компонент отображается
24 // на экране.
25 private HelloForm form;
26
27 // Экземпляр Display. Данный объект управляет всеми
28 // компонентами Displayable данного MID-лета.
29 private Display display;
30
31 // Экземпляр MID-лета.
32 private static IlSNDemo instance;
33
34 // Префикс имен атрибутов локализуемых
35 // ресурсов.
36 String attrPrefix = new String("I18NDemo-");

37
38 /**
39 Конструктор No-arg.
40 */
41 public I18NDemo()
42 {
43 super();

44 instance = this;
45 }
46
47 /*
48 Получает экземпляр данного класса, который существует в
49 работающем приложении.
50
51 Звоззращает экземпляр, созданный при запуске
52 приложения.
53 */
54 public static IlSNDemo getlnstance()
55 {
56 if (instance == null)
57 {
58 instance = new IlSNDemo ();

59 }
60 return instance;
61 }
62
63 /**
64 Запускает .MID-лет. Получает текущую региональную
65 настройку для реализации. Использует ее для
66 создания префикса ключей атрибутов всех
67 локализованных ресурсов. Названия локализованных
68 ресурсов в файле JAD соответствуют
69 совместимой схеме имен.
70 */
71 public void startApp()
72 {
73 // Извлекает региональную настройку из программного
74 // обеспечения AMS. Региональная настройка должна быть
75 // установлена прежде, чем данный MID-лет начнет выполняться.
76 locale =
77 System.get Property("microedition.locale");

78
79 // Создает элемент Displayable. Получает локализованную
80 // String, которая представляет заголовок
81 // Form, из определенных пользователем атрибутов файла
82 // JAD. Получает все локализованные строки таким
83 // образом.
84 String formTitle = getResource("title");

85 form = new HelloForm(formTitle);

86
87 // Это приложение просто отображает единственную форму,
88 // созданную ранее.
89 display = Display.getDisplay(this);

90 display.setCurrent(form);

91 }
92
93 /**
94 Выдает значение, связанное с указанным
95 ключом из списка определяемых пользователем
96 ресурсов MID-лета в файле JAD приложения.
97
98 @param key - ключ пары «ключ-значение».
99
100 @выдает значение, связанное с указанным
101 ключом.
102 */
103 public String getResource(String key)
104 {
105 StringBuffer index = new
106 StringBuffer(«ttrPrefix);

107 String value;
108
109 index.append(key);

110 index.append('-');

111 index.append(locale);

112
113 value = getAppProperty(index.toString ());

114 return value;
115 }
116
117 /**
118 Закрываем приложение. Уведомляем
119 реализацию о выходе.
120 */
121 public void quit() ,
122 {
123 notifyDestroyed ();

124 }
125
126 public void destroyApp(boolean destroy)
127 {
128
129 }
130
131 public void pauseApp()
132 (
133
134 }
135 }

Имя данного файла

Листинг 9.4. Имя данного файла - fr_FR.txt. Он состоит из франкоязычных версий строк приложения

alert: Alerte
alert_title: Bouton Presse alert_text: Le bouton a ete presse
cancel: Quitter exit: Sortie
greeting: Mon troisieme MIDlet!
help: Aider
item: Item
menu: Menu
ok: OK
sayhi: Dis bonjour
screen: Ecran
stop: Arreter
Mtle: A116, tout le Monde

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

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

В листингах 9.5 и 9.6 содержится код, который реализует одну возможную разработку, которая использует файлы текстовых ресурсов. Этот код считывает файлы, отформатированные подобно тому, что показан в листинге 9.4.

Класс I18NDemo2 использует

Листинг 9.5. Класс I18NDemo2 использует потоки для чтения файлов текстового ресурса. Реализация getResource () теперь отражает новую разработку для извлечения ресурсов из файлов, находящихся в файле JAR приложения

1 import javax.microedition.midlet.MIDlet;
2
3 import javax.microedition.Icdui.Display;
4 import javax.microedition.Icdui.Displayable;
5 import javax.microedition.Icdui.Form;
6
7 import java.io.DatalnputStream;
8 import Java.io.InputStream;
9 import Java.io.InputStreamReader;
10 import Java . io . EOFException;
11 import Java.io.lOException;
12 import Java.io.Reader;
13 import Java.io.UTFDataFormatException;
14 import Java.io.UnsupportedEncodingException;
15
16 import Java.util.Hashtable;
17
18 /**
19 Вторая версия приложения HSNDemo.
20
21 <р>
Эта версия'также дехонстрирует простой способ определения
22 локализованных ресурсов. Она считывает файл, который является
23 частью файла JAR приложения (не файла JAD)
24 для загрузки локализованных ресурсов. Файл
25 состоит из набора пар «ключ-значение», одной на строку,
26 которые представляют локализованные строки.
27 MID-лет должен затем проанализировать содержимое файла
28 и создать внутреннюю хэшированную таблицу для поиска.
29
30 <р>
Этот подход требует слишком много усилий по обработке
31 потока, который содержит файл
32 локализованных ресурсов. Более того, этот подход
33 не отвечает за локализацию ресурсов, которые
34 не являются строками.
35 */
36 public class I18NDemo2 extends MIDlet
37 {
38 // Файл, который содержит ресурсы для
39 // активной локальной настройки.
40 private String resourceFile;
41
42 // Региональная настройка, указанная для выполнения данного
43 // MID-лета.
44 private String locale;
45
46 // Символьная кодировка, установленная по умолчанию,
47 // используемая данной платформой.
48 private String encoding;
49
50 // HashTable, которая содержит локализованные
51 // ресурсы.
52 private Hashtable resources = new Hashtable () ;
53
54 // Displayable. Этот компонент отображается
55 // на экране.
56 private HelloForm2 form;
57
58 // Экземпляр Display. Данный объект управляет всеми
59 // компонентами Displayable данного MID-лета.
60 private Display display;
61
62 // Экземпляр данного MID-лета.
63 private static I18NDemo2 instance;
64
65 /**
66 Конструктор No-arg.
67 */
68 public I18NDemo2()
69 {
70 super();

71 instance = this;
72 }
73
74 /*"
75 Получает экземпляр данного класса, который существует
76 в действующем приложении.
77
78 @выдает экземпляр, созданный при запуске
79 приложения..
80 */
81 public static I18NDemo2 getlnstance ()
82 {
83 return instance;
84 {
85
86 /**
87 Запускает MID-лет. Получает текущее название
88 региональной настройки. Использует его для создания
89 имени файла, который содержит локализованные
90 ресурсы региональной настройки. Файл ресурса
91 находится в файле JAR приложения.
92 */
93 public void startApp()
94 {
95 // Извлекает региональную настройку из программного
96 // обеспечения AMS. Региональная настройка должна быть
97 // установлена до выполнения данного MID-лета.
98 locale =
99 System.getProperty("microedition.locale");

100
101 // Названия файлов локализованных ресурсов, соответствующих
102 // форме: <язык>
_<страна>
.txt.
103 // Создает строку имени файла и передает ее в
104 // метод, который открывает файл и извлекает
105 // содержимое.
106 resourceFile = locale + ".txt";
107 int status = loadResources(resourceFile);

108
109 if (status < 0)
110 {
111 quit();

112 return;
113 }
114
115 // Создаем элемент Displayable. Получаем
116 // локализованную String, которая представляет
117 // заголовок Form.
118 String formTitle = getResource ("title" );

119 form = new HelloForm2(formTitle);

120
121 // Это приложение просто отображает одну .
122 // форму, созданную выше.
123 display = Display.getDisplay (this);

124 display.setCurrent(form);

125 }
126

Класс HelloForm2 теперь

Листинг 9.6. Класс HelloForm2 теперь использует API I18Nderao2.getResource() для извлечения локализованных ресурсов

1 import javax.microedition.midlet.MIDlet;
2
3 import javax.microedition.Icdui.Alert;
4 import javax.microedition.Icdui.AlertType;
5 import javax.microedition.Icdui.Command;
6 import javax.microedition.Icdui.CommandListener;
7 import javax.mi'croedition. Icdui .Display ;
8 import javax.microedition.Icdui.Displayable;
9 import javax.microedition.Icdui.Form;
10
11 /**
12 Данный класс определяет Form, которая отображает некоторый
13 простой текст и меню команд. Цель данного класса
14 продемонстрировать интернационализацию и локализацию
15 видимых пользователю атрибутов. Он работает с классом
16 I18NDemo2.
17 */
18 public class HelloForm2 extends Form
19 {
20 // Заголовок даннвй Form, устанавливаемый по умолчанию.
21 private static final String DEFAULTJTITLE =
22 "Hello, World";
23
24 // Блок прослушивания команд, который обрабатывает
25 // командные события в данной Form.
26 private MyCommandListener cl = new
27 MyCommandListener (1;
28
29 // Экземпляр дисплея, связанный с данным
30 // MID-летом.
31 Display display;
32
33 // Ссылка на связанный с данным объектом
34 // объект MID-лета.
35 IlSNDemo midlet;
36
37 // Уведомление, отображаемое в ответ на активацию
38 // некоторой из команд данной Form.
39 Alert alert;
40
41 private Command showAlert;
42 private Command sayHi;
43 private Command cancel;
44 private Command exit;
45 private Command help;
46 private Command item;
47 private Command ok;
48 private Command screen;
49 private Command stop;
50
51 /**
52 Конструктор No-arg. Устанавливает заголовок
53 по умолчанию данной формы.
54 */
55 HelloForm2()
56 {
57 this(DEFAULT_TITLE);

58 }
59
60 /**
61 Конструктор.
62
.63 @param title - Заголовок данной Form.
64 */
65 KelloForm2(String title)
66 {
67 super (title);

68
69 midlet = IlSNDemo.getlnstance();

70
71 // Добавляет строковый элемент в форму.
72 String msg = midlet.getResource("greeting");

73 append (msg);

74
75 display = Display.getDisplay(midlet);

76
77 // Добавляет MyCommandListener в Form для прослушивания
78 // события нажатия клавиши «Back», которое должно
79 // создавать всплывающее уведомление Alert.
80 setCommandLiscener (cl) ;
81
82 showAiert = new
83 Command(midlet.getResource("alert"),
84 Command.SCREEN, 1);

85 addCommand(showAlert);

86
87 sayHi = new
88 Command(midlet.getResource("sayhi") ,
89 Command.SCREEN, 1) ;
90 addCommand(sayHi);

91
92 cancel = new
93 Command(midlet.getResource("cancel"),
94 Command.SCREEN, 1);

95 addCommand(cancel);

96
97 exit = new
98 Command(midlet.getResource("exit"),
99 Command.SCREEN, 1);

100 addCommand(exit);

101
102 help = new
103 Command(midlet.getResource("help"),
104 Command.SCREEN, 1);

105 addCommand(help);

106
107 item = new
108 Command(midlet.getResource ("item"),
109 Command.SCREEN, 1);

110 addCommand(item);

111
112 ok = new
113 Command(midlet.getResource("ok"),
114 Command.SCREEN, 1) ;
115 addCommand(ok);

116
117 screen = new
118 Command(midlet.getResource("screen") ,
119 Command.SCREEN, 1);

120 addCommand(screen);

121
122 stop = new
123 Command(midlet.getResource("stop"),
124 Command.SCREEN, 1);

125 addCommand(stop);

126 }
127
128 // Данный класс просто прослушивает активацию
129 // какой-либо команды. Экземпляр HelloForm
130 // устанавливает экземпляр данного класса как
131 // свой блок прослушивания команд. Экземпляр
132 // объекта не проверяет информацию команды,
133 // а просто отображает модальное Alert, показывающее,
134 // что экранная клавиша была активирована пользователем.
135 public class MyCommandListener
136 реализует CommandListener
137 {
138 public void commandAction(Command c,
139 Displayable d)
140 {
141 String title =
142 midlet.getResource("alert_title") ;
143 String msg = midlet.getResource("alert_text");

144
145 if (с == showAlert)
146 {
147 alert = new Alert(title,
148 msg,
149 null, AlertType.INFO);

150 alert.setTimeout(Alert.FOREVER);

151 display.setCurrent(alert, HelloForm2.this);

152 }
153 else if (c == sayHi)
154 {
155 alert = new Alert(title,
156 msg,
157 null, AlertType.INFO);

158 alert.setTimeout(Alert.FOREVER);

159 display.setCurrent(alert, HelloForm2.this);

160 }
161
162 if (c == exit)
163 {
164 I18NDemo.getInstance-() .destroyApp (true) ;
165 }
166 }
167 }
168 }

Наиболее проблематичным аспектом данного подхода является то, что вы, разработчик, должны создать инфраструктуру, которая позволит вашим приложениям считывать и анализировать файлы ресурсов. Также приложение должно создавать структуры внутренних данных, которые содержат локализованные ресурсы, считанные из файлов. Самым проблематичным аспектом создания этой инфраструктуры является предоставление адекватной обработки потоков, особенно обработки потоков для поддержки считывания значений строковых атрибутов. Метод MIDlet.getAppProperty(), использовавшийся в предыдущей схеме, основанной на файле JAD, извлекает информацию об обработке потоков. Но в данной схеме вы должны проделать всю эту работу самостоятельно.

Метод Class.getResourceAsStream(String name) является единственным способом, с помощью которого MID-лет может считывать файл из JAR приложения. Параметр имени представляет собой имя файла без информации о пути. Этот метод выдает объект java.io.InputStream, который является байтовым потоком.

Вы должны преобразовать этот байтовый поток в символьный для того, чтобы считывать значения строковых атрибутов в вашей программе. Единственный практичный способ преобразовать байтовые потоки в символьные - это использовать класс java.io.InputStreamReader. Вы создаете экземпляр данного класса, пересылая ваш объект InputStream в конструктор InputStreamReader. В строках с 137 до 154 листинга 9.5 символьный поток срздает определяемый приложением метод loadResources ().

Чтобы преобразовывать из байтов в символы, вы должны знать символьную кодировку файла ресурса, который вы считываете. В листинге 9.5 происходит преобразование из кодировки ISO8859-1 (используемой файлом en_US.txt) в уникод. При считывании символьных данных в программу конечной кодировкой всегда является уникод. Java всегда представляет символы и строки внутренне с помощью уникода.

Первая форма конструктора InputStreamReader, показанная в таблице 9.1 и использованная в листинге 9.5, преобразует из символьной кодировки, устанавливаемой платформой по умолчанию, в уникод. Если ваш файл ресурсов использует кодировку, отличную от кодировки, используемой платформой по умолчанию, вы должны использовать второй конструктор InputStreamReader, который принимает аргумент, указывающий- кодировку потока, считываемого вами.

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

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

Лучше всего использовать одну символьную кодировку для всего файла. В противном случае вам понадобится создать два символьных потока: один для анализа ключей атрибутов и второй для анализа значений. Подобная схема добавляет вашей обработке потоков ненужный уровень сложности.

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

Двумя практичными вариантами символьных кодировок являются последовательности переключения кодов UTF-8 и Unicode Java. UTF-8 - это код изменяющейся ширины, который поддерживает определения символьной кодировки ASCII. Он вмещает все символы всех языков. К несчастью, потоковые классы MIDP не имеют удобных методов, таких, как DatalnputStream.readUTFO J2SE, для считывания строк UTF. Итак, вам все равно придется выполнять анализ потока собственноручно. Другая сложность заключается в том, что теперь вам придется записывать ваши файлы ресурса в формате UTF-8. Поэтому вам нужны текстовые редакторы и другие инструменты, которые поддерживают создание файлов, кодированных в UTF-8.

Простейшее решение - использовать последовательности переключения кода Unicode Java для кодирования значений строковых атрибутов. Каждая последовательность переключения кода представляет собой уникальный символ уникода. У этого подхода есть два преимущества. Во-первых, вы можете записывать эти последовательности в файл как символы ASCII. Во-вторых, уникод поддерживает все языки. В листинге 9.4 используется ISO8859-1. Он адекватен для франкоязычных ресурсов, но в то же время он может не поддерживать корейский язык, например, тогда как уникод поддерживает. Вы можете использовать некоторые другие многобайтные кодировки, но затем вам придется положиться на редакторы методов ввода и другие инструменты для считывания и записи файла ресурса в этой кодировке.

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

Когда вы создали ваш объект InputStreamReader, который является символьно ориентированным потоком, вы можете извлекать символы из него с помощью методов read(). Они происходят из класса, стоящего над ними, java.io.Reader. Эти методы выдают char уникода. В таблице 9.1 перечислены методы класса Reader.

Класс ResourceBundle

Листинг 9.7. Класс ResourceBundle определяет структуру для агрегирования ресурсов, не заключающую в себе информацию об абстракции, требуемой для выполнения агрегирования

import Java.util.Hashtable;
/**
Данный класс определяет базовый класс для определения локализованных ресурсов
приложения. Он реализует подмножество класса java.util.ResourceBundle J2SE,
но придерживается интерфейса, определенного данным классом.
public abstract class ResourceBundle
«Родительские» ресурсы. Если ресурс не найден в данном пакете, производятся
поиски родительского пакета.
*/
protected ResourceBundle parent;
/**
Конструктор No-arg. public ResourceBundle () super();

/**
Получает пакет ресурсов с указанным именем класса.
Имя класса уже содержит язык и код страны назначения в стандартном формате.
Например, имя класса пакета ресурсов может быть «I18NDeraoResources_fr_FR».
@param className Полное имя класса, такое, как «I18NDemoResources_fr_FR».
@возвращает объект пакета ресурсов.
*/
public static ResourceBundle getBundle(String classNarae) throws IllegalArgumentException,
KissingResourceException
{
return ResourceBundle.getBundle(className, "");

}
/**
Получает пакет ресурсов с указанным базовым именем.
@param baseName Полностью определенное имя класса извлекаемого пакета.
Например, базовое имя «I18NDemo_fr_FR» - «HSNDerao».
Sparam строка региональной настройки, представляющая региональную настройку,
для которой должен быть извлечен пакет ресурсов.
Ожидаемая форма <язык>
.<страна>
в соответствии с ISO 639 и ISO 3166, соответственно.
@выдает пакет ресурсов для возвращения
*/
public static ResourceBundle getBundle(String baseName, String locale)
throws IllegalArgumentException, MissingResourceException
{
Class c; if (baseName == null)
{
throw new IllegalArgumentException("No basename.");

{
String className = baseName + "_" + locale;
ResourceBundle bundle = null;
try
{
с = Class.forName(className);

bundle = (ResourceBundle) с.newlnstance();

}
catch (ClassNotFoundException cnfe)
throw new
MissingResourceException("Class not found.");

}
catch (InstantiationException ie)
{
throw new
MissingResourceException("Can11 instantiate.") ;
}
catch (IllegalAccessException iae)
{
throw new
MissingResourceException("Can1t access.");

}
return bundle;
}
/**
Извлекает объект с указанным ключом. Если ключ не найден, ищется родительский пакет.
@param key Ключ объекта
@выдает объект с указанным ключом
*/
public final Object getObject(String key)
throws MissingResourceException
}
Object obj; if (key == null)
{
throw new NullPointerException();

}
obj = handleGetObject(key);
if (obj == null SS parent 1= null)
{
obj = parent.getObject(key);

}
if (obj == null)
{
throw new MissingResourceException ();

return obj;
}
/**
Ищет данный пакет ресурсов для объекта с указанным ключом.
@param key Ключ поиска желаемого объекта.
@выдает объект с указанным ключом.
*/
protected abstract Object handleGetObject(String key);

}

Класс ListResourceBundle

Листинг 9.8. Класс. ListResourceBundle использует «список» (в действительности двухмерный массив объектов) для агрегирования ресурсов

/**
Этот класс определяет пакет ресурсов как подходящий массив ресурсов.
Он воспроизводит класс того же имени, определяемый платформой J2SE, java.util.ListResourceBundle.
<р>
Данный класс абстрактен. Приложения вынуждены создавать его
подклассы и определять конкретные классы, которые содержат локализованные ресурсы.
<р>
0пределенные подклассы конкретного приложения должны быть названы так,
чтобы имя содержало язык и страну региональной настройки, в соответствии со
стандартами ISO 639 и ISO 3166 для языковых и страновых кодов соответственно.
*/
открытый абстрактный класс ListResourceBundle дополняет ResourceBundle
/**
Конструктор No-arg.
*/
public ListResourceBundle()
super();

// Массив ресурсов в формате ключ-значение, private static final Object [][] contents = null;
/**
Получает массив ресурсов.
@возвращает двухмерный массив пар ключ-значение, который определяет эту группу.
*/
public abstract Object [][] getContents();

/**
Получает объект, который представляет значение, связанное с указанным ключом.
@param key Ключ пары ключ-значение.
@выдает объект, который представляет значение пары ключ-значение.
*/
public final Object handleGetObject(String key)
{
Object value = null; if . (key == null)
{
return null;
}
Object [][] pairs = getContents ();

for (int i = 0; i < pairs. length; i + +) if (key.equals(pairs [i] [0]))
value = (pairs [i] [1]) ;
}
}
return value;
}
}

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

Конкретный подкласс

Листинг 9.9. Конкретный подкласс ListResourceBundle легко определяет локализованные ресурсы. Каждый подкласс определяет «список» значений ресурсов (в действительности являющийся массивом) и определяет метод getContents (). import javax.microedition.Icdui."Image

import Java. io.lOException;
/**
Данный класс определяет локализованные ресурсы приложения I18NDemo3.
Вы извлекаете ресурс, вызывая метод getObject() в классе ResourceBundle.
*/
public class I18NDemoResources_en_US extends ListResourceBundle
// Содержит один из локализованных ресурсов. Нам необходимо
// инициализировать данную переменную в статическом
// инициализаторе данного класса, private static Image applcon;
private Object [][] contents =
{
("title", "Hello, World"}, // Form title.
("greeting", "My third MIDlet"}, // Form text.
("alert_title", "Button Pressed"), // Alert title.
{"alert_text", "A button was pressed!"),// Alert text.
{"exit", "Exit"}, // "Exit" menu item.
{"menu", "Menu"}, // "Menu" soft button.
{"cancel", "Cancel"}, // "Cancel" menu item.
{"stop", "Stop"}, // "Stop" menu item.
{"ok", "OK"}, // "OK" menu item.
{"alert", "Alert"}, // "Alert" soft button.
{"sayhi","Say Hi"}, // "Say Hi" menu item.
{"screen", "Screen"}, // "Screen" menu item.
{"item", "Item"}, // "Item" menu item.
{"help", "Help"}, // "Help" menu item.
{"app_icon", applcon} // Application icon.
};
/**
Конструктор No-arg.
*/
public I18NDemoResources_en_US()
{
super();

}
public Object ij[] getContents()
{
return contents;
}
// Необходим статический инициализатор для инициализации
// переменных, которые не могут быть инициализированы в
// массиве содержимого. Например, мы не можем выделить что-либо
// в массиве содержимого'для создания изображения и,
// выполнить требуемую обработку исключений.
static
{
try
{
applcon = Image.createlmage("i!8n-en_US.png");

}
catch (lOException ioe)
{
System.оut.println(ioe.getMessage)));

ioe.printStackTrace();

}
}
}

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

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

Ресурс каждой региональной

Листинг 9.10. Ресурс каждой региональной настройки определяется в своем собственном соответствующем подклассе ListResourceBundle. Данный подкласс определяет атрибуты, локализованные для франкоязычного региона

import javax.microedition.lcdui.Image;
import Java.io.lOException;
/'**
Класс, представляющий локализованные ресурсы для французского языка региона Франции.
Обратите внимание на использование последовательностей
переключения уникода в строковых литералах. Использование последовательностей
переключения уникода в строковых литералах означает, что мы можем записать
этот файл с помощью одних только символов ASCII, делая его эксплуатацию
более легкой. Легко добавлять комментарии для создания удобочитаемых строк.
*/
public class I18NDemoResources_fr_FR
extends ListResourceBundle
{
// Содержит один из локализованных ресурсов. Нам необходимо
// инициализировать данную переменную в статическом
// инициализаторе данного класса.
private static Image applcon;
private Object [][] contents =
{ {"title", "All\uOOf4, tout le Monde"), // Form title.
// Создаем текст: "My third MIDlet". ("greeting", "Mon troisi\uOOe8me MIDlet"),
// «Кнопка была нажата» ("Button was Pressed").
{"alert_title", "Bouton a \uCOe9t\uOOe9 press\uOOe9"),
// «Кнопка была нажата» ("The button was pressed").
{"alert_text", "Le bouton a \uOOe9t\uOOe9 press\uOOe9!"},
("exit", "Sortie"), // Пункт меню «Выход» ("Exit").
("menu", "Menu"), // Экранная клавиша «Меню» ("Menu").
("cancel", "Quitter"), // Пункт меню «Отмена» ("Cancel").
("stop", "Arreter"), // Пункт меню «Стоп» ("Stop").
("ok", "OK"), // Пункт меню "OK".
("alert", "Alerte"), // Экранная клавиша «Уведомление» ("Alert").
i"sayhi","Dis bonjour"), // Пункт меню «Скажи- привет» ("Say Hi").
("screen", "Ecran"), // Пункт меню «Экран» ("Screen").
{"item", "Item"), //.Пункт меню «Предмет» ("Item").
("help", "Aider"), // Пункт меню «Помощь» ("Help").
("app_icon", applcon) // Значок приложения.
};
/**
Конструктор No-arg.
*/
public I18NDemoResources_fr_FR()
{
super();

/**
Получает содержимое пакета ресурсов.
@возвращает массив пар ключ-значение.
public Object [][] getContents()
{
return contends;
}
// Обратите внимание, что статический инициализатор создает
// экземпляры класса Image с другими изображениями, нежели он
// использует в региональной настройке en_US. static
{
try
{
applcon = Image.createlmage("i!8n-fr_FR.png");

}
catch (lOException ioe)
{
System.out.printIn(ioe.getMessage());

io.e.printStackTracel) ;
}
}
}

В листинге 9.11 показана программа I18NDemo3, которая использует данный набор классов пакетов ресурсов. Метод startAppO данного MID-лета создает экземпляр соответствующего класса пакета ресурсов. Он создает имя класса, связывая базовое имя семейства файлов локализованных ресурсов, I18NDemoResources, с конечной региональной настройкой. С помощью всего лишь нескольких операторов приложение получает доступ ко всем локализованным ресурсам.

Класс I18NDemo3 создает

Листинг 9.11. Класс I18NDemo3 создает экземпляр соответствующего класса пакета ресурсов для контекста рабочей региональной настройки. Ресурсы любого типа Java данного пакета легко доступны

import javax.microedition.midlet.MIDlet;
import javax.microedition.Icdui.Display;
import javax.microedition.Icdui.Displayable;
import ]avax.microedition.Icdui.Form;
import Java.util.Hashtable;
Третья версия приложения IlSNDemo.
<р>
Данная версия IlSNDemo использует пакет ресурсов для определения
локализованных ресурсов. Приложение определяет текущую региональную
настройку и пытается загрузить связанный с ней пакет, содержащий
соответствующие локализованные ресурсы. Если оно не может найти эти ресурсы,
оно загружает ресурсы U.S. English, представленные языком en_US и страной назначения.

<р>
Этот подход наиболее предпочтителен. Легко поддерживаются локализованные
ресурсы, отличные от строк.
*/
public class I18NDemo3 extends MIDlet
{
// Региональная застройка, указанная для выполнения
// данного МID-лета.
private String locale;
// Пакет ресурсов, который содержит локализованные ресурсы
// для выполнения данного приложения, private static ResourceBundle bundle;
{
// Displayable. Этот компонент отображается
// на экране.
private HelloForm3 form;
// Экземпляр Display. Этот объект управляет всеми
// компонентами Displayable для данного MID-лета.
private Display display;
// Экземпляр MID-лета.
private static !18NDerao3 instance;
/**
Конструктор No-arg.
*/
public I18NDemo3()
{
super();

instance = this;
}
/**
Получает экземпляр данного класса, который существует в действующем приложении.
@выдает экземпляр, созданный при запуске приложения.
*/
public static I18NDemo3 getlnstance()
{
if (instance == null)
{
instance - new I18NDemo3();

}
return instance;
}
/**
Получает пакет ресурсов, используемый данным MID-летом.
Этот метод полезен для других классов, которым необходим доступ
к локализованным ресурсам приложения.
@выдает локализованные ресурсы MID-лета.
*/
public static ListResourceBundle getResourceBundle ()
{
return (ListResourceBundle) bundle;
}
/**
Запускает MID-лет. Определяет текущую региональную настройку среды исполнения
и использует ее для создания имени пакета локализованных ресурсов. Использует
это имя для создания имени класса Java, который затем загружается с помощью
Class. Если нет соответствия пакету ресурсов, по умолчанию используется пакет
ресурсов U.S. English.
*/
public void startApp()
{
// Извлекает региональную настройку из программного обеспечения
// AMS.Региональная настройка должна быть установлена
// до выполнения данного MID-лета.
locale = System.getProperty("microedition.locale");

bundle = null;
cry
{
bundle =
ResourceBundle.getBundle("IlSNDemoResources", locale);

if (bundle == null)
{
bundle =
ResourceBundle.getBundle("IlBNDemoResources", "en_US");

}
}
catch (MissingResourceException mre)
mre.printStackTracef);

}
try
}
/ Создаем элемент Displayable. Получаем локализованную
// String, которая представляет заголовок Form.
String formTitle = (String)
bundle.getObject("title");

form = new HelloForm3(formTitle);

}
catch (MissingResourceException mre)
{
rare.printStackTrace();

}
// Это приложение просто отображает одну форму, созданную ранее, display = Display.getDisplay(this);
display.setCurrent(form);

}
/**
Выдает значение, связанное с указанным ключом из списка определяемых
пользователем ресурсов MID-лета в файле JAD приложения.
@param key Ключ пары ключ-значение.
@выдает значение, связанное с указанным ключом.
*/
public Object getResource(String key)
}
Object resource = null;
try
{
resource = bundle.getObject(key);

}
catch (MissingResourceException mre)
}
}
return resource;
/**
Выход из MID-лета. Уведомляет реализацию, что она
может прервать работу всех ресурсов приложения.
Реализация вызывает destroyApp().
*/
public void quit()
{
notifyDestroyed();

/*
public void destroyApp(boolean destroy)
{
{
public void pauseApp()
{
}
}

На рисунке 9.1 показано основное окно, созданное программой I18NDemo3 при ее запуске в региональной настройке en_US. Программа динамически извлекает локализованные ресурсы, описанные в листинге 9.9. На рисунке 9.2 показан экран меню того же приложения, запущенного в региональной настройке fr_FR, которая использует локализованные ресурсы, описанные в листинге 9.10. Код приложения I18NDemo3 абсолютно не изменяется. Он просто динамически определяет контекст региональной настройки при инициализации и загружает соответствующий пакет ресурсов.

Последовательности

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

import javax.microedition.Icdui.Image;
import Java.io.lOException;
/**
Данный класс определяет локализованные ресурсы для приложения I18NDemo3.
Вы извлекаете ресурс, вызывая метод getObject() в классе ResourceBundle.
*/
public class I18NDemoResources_ja_JP
extends ListResourceBundle
{
// Содержит один из локализованных ресурсов. Нам необходимо
// инициализировать эту переменную в статическом инициализаторе
// данного класса.
private static Image applcon;
private Object [][] contents =
{
// "Привет, мир"
{"title", "\u24f64\u3055\u3093, \u3053\u3093\u306b\u3061\u306f"),
// "Мой третий MID-лет".
("greeting", "\u79cl\u306e 3 \u3063\u3081\u306e MIDlet"},
// "Кнопка нажата".
{"alert_title")
"\u30dc\u30bf\u30f3\u304c\u62bc\u3055\u308c\u307e\u3057\u305f"},
// "Кнопка была нажата".
"alert_text",
"\u30dc\u30bf\u30f3\u304c\u62bc\u3055\u308c\u3C7e\u3057\u305f!"}
// Пункт меню "Выход", {"exit", "\u51fa\53e3"},
// Экранная клавиша "Меню".
("menu", "\u30el\u30cb\u30e6\u30fc"),
// Пункт меню "Отмена".
("cancel", "\u3Cad\u30e4\u30f3\u30bb\u30eb"),
// Пункт меню "Стоп". {"stop", "\u505c\u6b62"),
// Пункт меню "ОК". ("ok", "OK"},
// Экранная клавиша "Предупреждение", {"alert", "Alert"),
// Пункт меню "Скажи привет", ("sayhi","\u30cf\u30a4"},
// Пункт меню "Экран".
{"screen", "\u30b9\u30af\u30ea\u30f3"),
// Пункт меню "Предмет", {"item", "\u9805\u76ee"),
// Пункт меню "Помощь".
("help", "\u308d"},
// Значок приложения.
{"app_icon", applcon)
/**
Конструктор No-arg.
*/
public I18NDemoResources_ja JP()
{
super();

)
public Object [][] getContents ()
{
return contents;
{
// Необходим статический инициализатор для инициализации
// переменной, которая не может быть инициализирована в
// массиве содержимого. Например, мы не можем выделить что-либо
// в массиве содержимого для создания изображения и выполнить
// требуемую обработку исключений.
static
{
try
{
applcon = Image.createlmage("i!8n-ja_JP.png");

{
catch (lOException ioe)
{
System.out.println(ioe.getMessage());

ioe.printStackTracef);

}
}
}

В листинге 9.14 показан файл I18NDemoResources_zh_CH. Java, который определяет локализованные ресурсы для упрощенного китайского языка.

Листинг 9.14. Этот файл определяет локализованные ресурсы для региональной настройки zh_CN, Китай, приложения I18NDemo3

import javax.microedition.Icdui.Image; import Java.io.lOException;
/**
Данный класс определяет локализованные ресурсы для приложения I18NDemo3.
Вы извлекаете ресурс, вызывая метод getObjectO в классе ResourceBundle.
*/
public class I18NDemoResources_zh_CN
extends ListResourceBundle
{
// Содержит один из локализованных ресурсов. Нам необходимо
// инициализировать эту переменную в статическом инициализаторе
// данного класса.
private static Image applcon;
private Object [][] contents =
{
// Заголовок формы "Hello, World".
("title", "\u54c8\u7f57\u4el6\754c"),
// Текст формы "My third MIDlet".
("greeting", "\u62ll\u7684\7b2c\u4e09\u4187 MIDlet"},
// Заголовок уведомления "Button Pressed". ("alert_title", "\u6309\u4eOb\u6309\u9215"],
// Текст уведомления "A button was pressed!". ("alert_text", "\u6309\u4eOO\u4187\u6309\u9215!"},
// Пункт меню "Exit".
("exit", "\u767b\u51fa"},
// Экранная клавиша "Menu", ("menu", "\u76ee\u5f54"},
// Пункт меню "Cancel", {"cancel", "\u53d6\u6d88"j,
// Пункт меню "Stop", ("stop", "\u505c\u6b62"},
// Пункт меню "OK". {"ok", "OK"),
// Экранная клавиша "Alert", {"alert", "\u8b66\u793a"),
// Пункт меню "Say Hi", ("sayhi", "\u55e8"},
// Пункт меню "Screen". ("screen", "\u87a2\u5e55"),
// Пункт меню "Item", ("item", "\u9879\u76ee"},
// Пункт меню "Help", {"help", "\u8bf4\u660e"},
// Значок приложения. {"app_icon", applcon}
};
/**
Конструктор No-arg.
*/
public I18NDemoResources_zh CN()
{
super!);

{
public Object [][] getContents ()
{
return contents;
}
// Необходим статический инициализатор для инициализации
// переменной, которая не может быть инициализирована в
// массиве содержимого. Например, мы не можем выделить что-либо
// в массиве содержимого для создания изображения и выполнить
// требуемую обработку исключений.
static
{
try
{
applcon = Imagb.createlraage("i!8n-zh_CN.png");

}
catch (lOException ioe)
{
System.out.println(ioe.getMessage!));
ioe.printStackTrace();

}
}
}

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

Подход пакетов ресурсов также содействует легкому переносу приложений в среду J2SE. Реализации классов пакетов ресурсов, показанных в листингах 9.7 и 9.8, создают только подмножество необходимых свойств. Но их строгое следование интерфейсам версий J2SE означает, что подклассы ListResourceBundle вашего приложения совместимы снизу вверх.

Пакеты ресурсов также способствуют лучшей восстанавливаемости и большей понятности. Зависящие от приложения подклассы ListResourceBundle могут быть легко восстановлены только лишь с помощью текстового редактора, основанного на ASCII. Любой ASCII-текстовой редактор может считывать и записывать символы ASCII или последовательности переключения кода Unicode Java, присутствующие в пакетах ресурсов. Кроме того, поскольку это исходные файлы Java, разработчики могут вставлять комментарии, которые ясно описывают каждый ресурс и контекст, в котором приложение его использует.

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

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

Установка нескольких файлов классов Java для локализованных ресурсов может потребовать больше ресурсов хранения устройства, чем вы можете себе позволить. Наиболее очевидной проблемой при разработке MIDP является потребление памяти. Хотя два первых подхода неудобны по нескольким причинам, они затрачивают меньше ресурсов памяти, чем подход классификационного файла Java. Иногда, когда вы не можете позволить себе лишние траты памяти, вы можете позволить приложению затратить несколько дополнительных секунд при запуске на считывание и анализ локализованных ресурсов. Одним из возможных компромиссов является игнорирование иерархии наследования ResourceBundle и предоставление единственного класса, который содержит локализованные ресурсы для каждой региональной настройки. Предоставьте соответствующий локализованный классификационный файл указанной региональной настройке приложения. Здесь вы жертвуете гибкостью ради производительности. Вы также теряете совместимость снизу вверх с J2SE, но это может быть неважно.

З Класс HelloForm определяет

Листинг 9.З. Класс HelloForm определяет объект формы и использует ту же самую схему, что и основной класс МID-лета

1 import javax.raicroedition.midlet.MIDlet;
2
3 import javax.microedition.Icdui.Alert;
4 import javax.microedition.Icdui.AlertType;
5 import javax.microedition.Icdui.Command;
6 import javax.microedition.Icdui.CommandListener;
7 import javax.microedition.Icdui.Display;
8 import javax.microedition.Icdui.Displayable;
9 import javax.microedition.Icdui.Form;
10
11 /*
12 Данный класс определяет Form, которая отображает
13 простой текст и меню команд. Цель данного класса
14 заключается в демонстрации i18n и 110n
15 видимых пользователю атрибутов. Класс извлекает
16 локализованные ресурсы из программного обеспечения
17 управления приложениями.
18 */
19 открытый HelloForm дополняет Form
20 {
21 // Заголовок данной Form, устанавливаемый по умолчанию.
22 private static final String DEFAULT_TITLE =
23 "Hello, World";
24
25 // Блок прослушивания команд, который обрабатывает
26 // командные события в данной Form.
27 private MyCommandListener cl = new
28 MyCommandListener ();

29
30 //. Экземпляр дисплея, связанный с
31 // данным MID-летом.
32 Display display;
33
34 // Ссылка на связанный с данным объектом
35 // объект MID-лета.

Поддержка интернационализации в MIDP

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

Классы Calendar, Date и TimeZone: пакет Java.util; Системные свойства: microedition.encoding, microedition.locale; Изменение кодировки: пакет java.io; Определяемые пользователем атрибуты набора MID-летов: файл дескриптора приложения (файл JAD); Извлечение ресурсов (файлов) из файла JAR набора MID-летов: Class.getResourceAsStream(String resourceName).

Пакет java.util MIDP содержит три класса, которые связаны с интернационализацией, а именно: Calendar, Date и TimeZone. Эти классы, однако, сами по себе не являются межнациональными. То есть их конкретные реализации не поддерживают операций во многих региональных настройках. Например, Calendar не выполняет вычислений, связанных с календарем определенного региона. Класс Date не чувствителен к форматам даты и времени региона. Они также не представляют сами по себе локализованные ресурсы. В этих классах присутствуют, однако, базовые определения, из которых могут быть организованы подклассы.

Классы Calendar и TimeZone абстрактны. Реализации MIDP должны предоставлять, по крайней мере, один конкретный подкласс каждого из них. Хотя и не интернационализированные, их реализации будут совместимы с региональными настройками, поддерживаемыми реализацией MIDP. Например, в регионе Соединенных Штатов реализация будет, скорее всего, поддерживать грегорианский календарь.

Большинство реализаций MIDP поддерживает только одну региональную настройку. В действительности спецификация MIDP требует от реализации поддержки лишь одной региональной настройки и одной временной зоны - время по Гринвичу (GMT).

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

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

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

Читатели, знакомые с поддержкой интернационализации платформы J2SE, заметят, что в MIDP довольно заметно не хватает всесторонней поддержки интернационализации (смотри пакет Java.text J2SE). Причина опять же заключается в ограниченности среды мобильных устройств. MIDP не имеет пакета Java.text. В действительности MIDP не поддерживает API для таких свойств интернационализации, как пакеты ресурсов, форматирование сообщений, числовое форматирование, чувствительные к региональным настройкам форматы дат и времени и так далее. В MIDP также отсутствуют новые свойства интернационализации пакета Java.text JDK версии 1.4, такие, как сортировка, двунаправленная текстовая поддержка, аннотации, атрибуты и так далее.

Поддержка календаря и временных зон

Опять же в отличие от платформы J2SE в MIDP есть только ограниченная поддержка календаря. Класс java.util.Calendar абстрактен. Поэтому каждая платформа MIDP будет предоставлять, по крайней мере, одну конкретную реализацию. Скорее всего, она не будет интернационализирована.

Конкретный подкласс платформы Calendar, вероятнее всего, реализует один определенный календарь, такой, как грегорианский или лунный. Он может соответствовать контекстам региональных настроек, в которых вы размещаете ваши приложения, а может и не соответствовать. Метод Calendar.getlnstance(TimeZone zone) выдает объект Calendar, который использует указанную временную зону и региональную настройку платформы, установленную по умолчанию. Обратите внимание, что этот фабричный метод не делает класс Calendar полностью интернационализированным классом. Он все еще не выдает соответствующий календарь, основываясь на региональном контексте. Например, если вы укажете китайское стандартное время (Chinese Standard Time), вы не получите объект, который представляет лунный календарь, используемый в Китае, во всех реализациях MIDP. Это означает, что вам нужно знать, какой календарь поддерживается вашей платформой, и согласуется ли он с региональной настройкой, поддерживаемой реализацией.

Понятия

Интернационализация - это действия программного обеспечения по соблюдению географического, лингвистического и культурного контекста, определяемого средой исполнения. Термин интернационализация иногда сокращается как «i18n», потому что 18 букв в этом слове между буквами «i» и «n» опускаются.

Последовательности переключения

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

import javax.microedition.Icdui.Image;
import Java.io.lOException;
/"*
Данный класс определяет локализованные ресурсы
для приложения I18NDemo3. Вы извлекаете ресурс, вызывая метод getObjectf)
в классе ResourceBundle.
*/
public class I18NDemoResources_ru_RU
extends ListResourceBundle
{
// Содержит один из локализованных ресурсов. Нам необходимо
// инициализировать эту переменную в статическом инициализаторе
// данного класса.
private static Image applcon;
private Object [][] contents =
// "Привет, мир".
("title", "\u0417\u0434\u0440\u0430\u0441\u0442\u0432\u0443\u0439,
\u041c\u0446\uO*440!"),
// "Мой третий MID-лет".
{"greeting", "\u041c\043e\u0439 \u0442\u0440\u0435\u0442\u0438\u0439 MIDlet!"},
// "Кнопка нажата".
{"alert_title",
"\u041a\u043d\u043e\u043f\u043a\u0430 \u041d\u0430\u0436\u0430\u0442\u0430"},
// "Кнопка была нажата!".
("alert_text", "\u041a\u043e\u043e\u043f\u043a\u0430
\u0411\u044b\u043b\u0430 \u043d\u0430\u0436\u0430\u0442\u0430!"},
// Экранная клавиша "Выход".
("exit", "\u0412\u044b\u0445\u043e\u0434"},
{
// Экранная клавиша "Меню".
("menu", "\u041c\u0435\u043d\u044e"},
// Пункт меню "Отмена".
{"cancel",
"\u041f\u0440\u0435\u043a\u0440\u0430\u0442\u0446\u0442\u044c"),
// Пункт меню "Стоп".
("stop", "\u0421\u0442\u043e\u043f"},
// Пункт меню "ОК". {"ok", "OK"},
// Экранная клавиша "Предупреждение".
("alert", "\u0412\u043d\u0446\u043c\u0430\u043d\u0446\u0435"),
// Пункт меню "Скажи привет".
("sayhi","\u0421\u043a\u0430\u0436\u0446
\u043f\u0440\u0446\u0432\u0435\u0442"),
it Пункт меню "Экран".
{"screen", "\u042d\u043a\u0440\u0430\u043d"),
// Пункт меню "Предмет".
("item", "\u041f\u0440\u0435\u0434\u04c3\u0435\u0442"),
// Пункт меню "Помощь".
("help", "\u041f\u043e\u043c\u043e\u0449\u044c"},
// Значок приложения. ("app_icon", applcon} };
/**
Конструктор No-arg.
*/
public I18NDemoResources_ru_RU()
super();
}
public Object [][] getContents()
}
return contents;
}
// Необходим статический инициализатор для инициализации
// переменной, которая не может быть инициализирована
// в массиве содержимого. Например, мы не можем выделить
// что-либо в массиве содержимого для создания изображения и
// выполнить требуемую обработку исключений.
static
{
try
{
applcon = Image.createlmage("i!8n-ru_RU.png");
}
catch (lOExce'ption ioe)
{
System.out.print In(ioe.getMessage());
ioe.printStackTrace() ;
}
}
}

Если вы все еще не убеждены, взгляните на листинг 9.13, который показывает ресурсы того же самого приложения, локализованные на японский язык. Класс I18NdemoResources_ja JP был создан с помощью того же текстового редактора, основанного на ASCII. Японские символы не могут быть введены в традиционном текстовом редакторе без поддержки IME. И, если вы используете IME, вы должны убедиться, что используете уникод для записи строковых литералов в файл. В противном случае вашему приложению придется выполнять преобразование посимвольной кодировки.

Работа с сообщениями

К сожалению, в MIDP также отсутствует явная поддержка организации сообщений. В отличие от J2SE, MIDP не предлагает API для работы с сообщениями и здесь нет класса MessageFormat. При разработке решения организации работы с сообщениями в приложении MIDP, разработчики должны ра матривать следующие вопросы:

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

Разработка решения интернационализации приложения MIDP

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

Региональные настройки и локализация

Региональная настройка представляет собой определенный географический, лингвистический и культурный контекст. Она описывает контекст, в котором работают интернационализированные приложения. Термин локализация относится к практике предоставления приложению возможности работать в контексте определенной региональной настройки. Слово локализация иногда сокращается как «11Оn», поскольку 10 букв опускаются между буквами «l» и «n» в этом слове. Разработчик локализует приложение для одной или нескольких региональных настроек после его интернационализации.

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

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

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

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

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

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

Символьные кoдиpoвки

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

ASCII является примером символьной кодировки. Поскольку символьная кодировка ASCII соответствует только английскому алфавиту, нам необходимы другие символьные кодировки - иногда называемые наборами символов - для работы с другими языками. Как вы знаете, Java внутренне использует символьную кодировку уникода для представления всех символьных данных. Данные, считываемые программой, могут быть представлены в уникоде, а могут и не быть. Если они не представлены, данные могут быть преобразованы перед импортом в приложение.

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

Конструкторы и методы java io Reader

Название Конструктора и метода java.io. Reader	Элемент	Описание
InputStreamReader (InputStream is)	Конструктор	Создает поток, который преобразует из кодировки, устанавливаемой платформой по умолчанию, в уникод
InputStreamReader (InputStream is, String enc)	Конструктор	Преобразует из указанной кодировки в уникод
void closed	Метод	Закрывает поток
void mark(int readAheadLimit)	Метод	Устанавливает лимит опережающего считывания для метки
boolean markSupported()	Метод	Показывает, поддерживает ли данный поток разметку
int read()	Метод	Считывает один символ
int read (char [] cbuf, int off, int len)	Метод	Считывает количество «len» символов в части символьного массива, начиная от указанной сдвига
boolean ready ()	Метод	Показывает, должно ли здесь считываться что-либо
void reset ()	Метод	Переустанавливает поток в последнюю позицию метки
long skip (long n)	Метод	Пропускает указанное число символов

Единственной пропущенной задачей является анализ символов, которые вы считываете. К сожалению, MIDP не имеет удобных классов, таких, как класс StringTokenizer J2SE, который облегчает расстановку меток. Вы должны поэтому самостоятельно проанализировать локализованные ресурсы, один символ за раз, с помощью любой из двух форм перегрузки Reader.read(). Если вы использовали такой формат файла, как в листинге 9.4, самое меньшее, что вы должны сделать затем, это отделить поле ключа от поля значения для каждого атрибута, убрать пробелы и так далее. В листинге 9.5 весь код в строках 127-318 посвящен обработке потока.

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

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

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

это действия по предоставлению приложению

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

Интернационализация - это действия по предоставлению приложению возможности динамического извлечения и использования чувствительных к региональным настройкам ресурсов при раб*оте. Интернационализация является важным свойством приложений MIDP. Интернационализированное приложение предназначено для большей пользовательской аудитории.
Интернационализация приложения означает предоставление ему при выполнении возможности извлечения ресурсов, которые совместимй с контекстом региональной настройки, в которой приложение работает. Локализация - это процесс предоставления ресурсов одному или нескольким контекстам региональной настройки.
Локализация - это деятельность по созданию определяемых региональной настройкой ресурсов для интернационализированных программ, к которым приложение получает доступ при выполнении. Работы по интернационализации и локализации сходны. Организация и задание формата локализованных ресурсов должны отражать схему и проектирование интернационализации. Решения всесторонней интернационализации и локализации должны обращаться к чувствительным к региональным настройкам операциям в следующих областях приложения:
работа с сообщениями; задание формата даты, времени, числовых и денежных значений; поддержка календаря; чувствительные к региональной специфике значки, изображения и цвета. Возможности, доступные в платформе MIDP, влияют на выбор варианта разработки интернационализации и затрагивают осуществимость реализации определенных разработок приложений MIDP. Платформа MIDP предоставляет три следующих основных механизма, которые могут быть использованы для создания возможностей интернационализации:
определяемые пользователем атрибуты набора MID-летов: файл дескриптора приложения; поддержка извлечения ресурсов (файлов) из файла JAR набора MID-летов: Class. getResourceAsStream(StringresourceName); преобразование символьных кодировок: пакет java.io. Разработчики приложений MIDP должны также учитывать факторы производительности, восстанавливаемости и установки при разработке решений интернационализации и локализации.