Определение платформы Java для портативных устройств

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

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

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

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

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

Например, профиль может поддерживать возможность сетевой коммуникации для популярного стандарта Short Message Service (SMS), широко используемого в мобильных телефонах. Поскольку стандарт SMS является повсеместно распространенным свойством в сотовой телефонии, имеет смысл задать эту службу в профиле, который предназначен для мобильных телефонов, вместо того чтобы встраивать ее в конфигурацию.

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

Java-приложение
Профиль
Конфигурация:	Библиотеки
Виртуальная Машина Java [JVM]
Операционная система компьютера
Аппаратное обеспечение устройства

Рисунок 1.1. Платформа J2ME состоит из ряда уровней, которые поддерживают базовую среду исполнения с корневыми библиотеками Java и Виртуальной машиной (VM), набора программных интерфейсов приложения системного уровня (API) в конфигурации и набора API программного уровня в профиле

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

Организация команд

Взглянув более внимательно на пример, приведенный в предыдущем разделе, вы можете догадаться, что на самом деле вы не можете контролировать то, где появляется каждая из меток Command на экранных клавишах. Как-никак, я не указывал левую или правую экранную клавишу для размещения обеих Command. Приложение HelloWorld2 добавило клавиши «Alert Me!» и «Say Hi», в таком порядке. Первая появилась на правой экранной клавише, вторая - на левой.

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

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

В масштабах класса HelloWorld3 определяет три объекта Command:

/**

Третья версия приложения HelloWorld.

Эта версия встраивается поверх HelloWorld2 с помощью добавления

нескольких команд к компоненту Displayable. Здесь демонстрируется,

что ComraandListener должен определять, какая из команд была

активирована на экране.

Вы также можете видеть, как реализация расставляет команды

на экранных клавишах и как она создает меню и упорядочивает команды

в меню в соответствии с типом команды.

*/

public class HelloWorld3 extends MIDlet,

{

Command showAlert= new Command("Alert Me!", Command.SCREEN, 1);;

Command sayHi = new Command("Say Hi", Command. SCREEN, I);-;

Command cancel = new Command("Cancel", Command.CANCEL, 1);

public HelloWorld3()

{

super ();

}

. . .

}

В методе startApp() эти объекты Command добавляются к главному экрану следующим образом:

form.addComraand(showAlert) ;

form.addCommand(sayHi) ;

form.addCommand(cancel);

Создание и запуск этой новой версии в эмуляторе J2ME Wireless Toolkit Emulator отражен в главном экране, показанном на рисунке 4.7.

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

Устройства имеют только две экранные клавиши, но мы вставили три команды в наш главный экран. Реализация обнаружила это и создала меню, которое содержит вторую, третью и другие команды. На рисунке 4.8 показан дисплей после того, как вы выбрали клавишу «Меню».

Запустите эту последнюю немодифицированную версию с помощью эмулятора Motorola iS5s, и вы увидите, что ключ «Меню» появится на левой экранной клавише, что отражено на рисунке 4.9. В действительности рисунки 4.8 и 4.9 демонстрируют, что конкретное поведение и политика размещения меню зависят от реализации.



Рисунок 4.7. Реализация добавляет экранную клавишу «Меню», когда она обнаруживает более, двух команд, добавленных к текущему Displayable



Рисунок 4.8. Выбор кнопки «Меню» отображает список элементов в экранном меню



Рисунок 4.9. Размещение меток — команд- зависит от реализации

Отображение изображения с помощью Canvas

Вы уже узнали в главе 5, что некоторые компоненты высокоуровневого пользовательского интерфейса MIDP умеют отображать изображения, например, как часть элемента в ChoiceGroup. Объекты Canvas также могут отображать изображения. Кроме рисования базовых геометрических фигур, объект Canvas может «рисовать» изображения с помощью того же контекста Graphics, который он использует для низкоуровневых функций рисования. MIDP поддерживает только формат изображений PNG.

На рисунке 6.12 показано изображение, отображаемое в Canvas. В листинге 6.10 показана исходная программа, создающая изображение, показанное на рисунке 6.12. Структура программы сходна с другими демонстрационными программами Canvas, приведенными в этой главе.

Рисунок 6.12. Canvas может отображать изображение, на самом деле рисуя изображение в контексте Graphics объекта изображения

Листинг 6.10. Чтобы отобразить изображение, Canvas просто «рисует» объект изображения с помощью процедуры рисования изображения объекта Graphics

import javax.microedition.lcdui.Canvas;

import javax.microedition.lcdui.Command;

import javax.microedition.lcdui.CommandListener;

import javax.microedition.lcdui.Display;

import javax.microedition.lcdui.Displayable;

import javax.microedition.lcdui.Graphics;

import javax.microedition.lcdui.Image;

import Java.io.lOException;

/*

Демонстрирует двойную буферизацию изображений в Canvas.

Изображения автоматически дважды буферизируются.

Эта программа демонстрирует, что вы ничего не должны делать для получения

поведения двойной буферизации при отображении изображений.

Однако вам все равно придется провести двойную буферизацию

операции, которая рисует фон Canvas, до рисования изображения.

*/

public class DoubleSufferlmageDemo extends Canvas

implements CommandListener

{

// Константа, которая представляет белый цвет.

private static final int WHITE = OxFF « 16 I OxFF « 8 I OxFF;

private static Command back = new Command ("Back", Command.BACK, 1);

private GraphicsDemo gDemo = GraphicsDemo.getlnstance();

private Display display = Display .getDisplay (gDerno) ;

// Ссылка на Image, которое отображает этот объект. Image image;

// Переменная, используемая для определения того,' осуществляет

// ли реализация автоматическую двойную буферизацию.

// Принимает значение «true», если реализация осуществляет

// автоматическую двойную буферизацию,

«false» в ином случае, private boolean autoDoubleBuffered = true;

/**

Конструктор No-arg.

*/

public DoubleBufferlmageDemo()

{

super();

if (!isDoubleBuffered())

{

autoDoubleBuffered = false;

}

// Создайте изображение PNG. Изображение «нарисовано» в

// изменяемом объекте Image, который имеет свой собственный

// внеэкранный Graphics. Мы сейчас создаем изображение в

// конструкторе, вместо метода paint (),

//так что оно создается только один раз. try

}

image = Image.createlraage("/bottle80x80.png" );

}

catch (lOException ioe)

{

System.out.println(ioe.getMessage()); ioe.printStackTracef);

}

addCommand(back); setCommandListener(this); display.setCurrent (this);

}

protected void paintClipRect(Graphics g)

{

int clipX = g.getClipX{} ;

int clipY = g.getClipY ();

int clipH = g.getClipHeight();

int clipW = g.getClipWidth () ;

int color = g.getColor();

g.setColor(WHITE);

g.fillRecc(clipX, clipY, clipW, clipH);

g.setColor (color);

/**

Рисует изображение на видимом Canvas этого объекта.

*/ public void paint(Graphics g)

Graphics originalG = null; int width = getWidth () ;

int height = getHeight () ;

if (image == null)

{

return; 1

// Мы все равно нуждаемся в двойной буферизации операций

// рисования, которые очищают графику Canvas, if (!autoDoubleBuffered)

{

// Сохраняет первоначальный графический контекст и использует

// внеэкранный Graphics из Image для очистки отсекаемого

// прямоугольника. originalG = g; g = image.getGraphics ();

paintClipRect (g);

}

else 1

// Нарисуйте фон с первоначальным Graphics, переданным в него. paintClipRect(g);



{

// Нам не нужна двойная буферизация вызова отображения Image.

// Вызов этого метода рисует изображение во

// внеэкранном Graphics объекта Image, копируя затем его

// содержимое в контекст Graphics устройства неявно.

g.drawlmage(image, 0, 0, Graphics.TOP I Graphics.LEFT);

public void commandAction(Command c, Displayable d)

{

if (c == back)

GraphicsDemo.getInstance().display!);

}

}

}

Процедура довольно прямолинейна. Вы должны сначала создать объект изображения, что вы сделали, когда переслали изображение в компонент высокоуровневого пользовательского интерфейса MIDP. Программа вызывает Image.createlmage(String name) для создания объекта Image. Этот метод определяет местоположение файла изображения, чье имя пути указано относительно директории res/ проекта.

Затем вы пересылаете изображение в объект Graphics, указывая точку привязки и местоположение (х, у) точки привязки. После этого программа просто вызывает метод Graphics.drawlmage() для отображения изображения. Реализация MIDP пересылает объект Graphics в метод приложения paint (Graphics g). Он представляет физический графический контекст устройства. То есть выполнение Graphics.drawlmage() в контексте Graphics, пересланного в ваш метод Canvas, paint (Graphics g), выражается в результате в визуализации на дисплее устройства.

Класс Image имеет четыре версии перегрузки метода createlmage(). В таблице 6.7 показаны все четыре версии. Вы уже видели третью версию, эта версия единственная, которая производит изменяемый объект изображения. Это вам необходимо для записи во внеэкранном контексте Graphics объекта Image.

Таблица 6.7. Методы класса Image для создания объектов изображений

Название метода изображения	Описание
static Image createlmage (byte [] imageData, int imageOffset, int imageLength)	Создает изменяемое изображение из указанных данных изображения, беря изображения начиная с указанных смещения и длины
static Image createlmage (Image source)	Создает изменяемую копию указанного изображения
static Image createlmage (int width, int height)	Создает новое изменяемое изображение с указанной шириной и длиной
static Image createlmage (String name)	Создает изменяемый объект изображения из изображения с путем к ресурсам, указанным в файле JAR набора МЮ-летов

<


Другие версии создают изменяемые объекты Image. Каждая версия дает вам возможность создавать изображение из различных источников. Первая версия создает изображение из необработанных двоичных данных. Вторая создает изображение из другого объекта изображения. Четвертая версия загружает изображение из файла JAR набора MID-летов. Строковый аргумент указывает имя файла ресурса в файле JAR.

В листинге 6.10 демонстрируется отображение реального изображения PNG. Вместо рисования изображений - рисунков, хранящихся как изображения в формате PNG, - вы можете нарисовать любую «картинку», которую вы сможете создать с помощью низкоуровневых процедур графического рисования, предоставляемых в классе Graphics. Вы можете рисовать геометрические фигуры или отдельные пиксели, заполнять части дисплея и так далее, чтобы создать изображение - рисунок - по, своему желанию.

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

Метод paint () создает объект Image из файла ресурса, который представляет изображение PNG для отображения. Но этот объект Image уже имеет связанный с ним контекст Graphics, являющийся внеэкранным Graphics. Поэтому, когда метод paint () выполняет следующий оператор, он копирует содержимое контекста Graphics объекта Image - фактические биты, которые составляют изображение, - в графический контекст дисплея:

g.drawlmage (image, О, О, Graphics.TOP I Graphics.LEFT);

Таким образом, двойная буферизация изображений осуществляется автоматически.

Хотя при рисовании изображения двойная буферизация осуществляется автоматически, очистка отсекаемого прямоугольника, то есть рисование фона Canvas, - нет. Посмотрите внимательнее на метод paint (Graphics д)в листинге 6.10, и вы увидите, что он все еще проверяет, не осуществляет ли реализация автоматическую двойную буферизацию. Если нет, метод paint (Graphics g) использует внеэкранный графический контекст для очистки отсекаемого прямоугольника.

Этот код немного отличается от кода, описанного в листинге 6.9, в этом коде нет явной ссылки на внеэкранный Graphics. Причина этого заключается в том, что объект Image уже предоставил внеэкранную графику. Метод paint (Graphics g) может просто использовать ее как внеэкранный Graphics, необходимый для очистки отсекаемого прямоугольника.

Отсечение областей для рисования

Когда ваше приложение вызывает метод Display.setCurrent(), он запрашивает реализацию об отображении вашего Displayable. Для объектов Canvas реализация делает ваш компонент текущим отображаемым и вызывает метод вашего класса paint (Graphics g). Реализация генерирует внутреннее событие рисования, которое пересылается в текущий отображаемый элемент. В этом кроется причина того, что метод paint() указан в таблице 6.1 как часть обработки событий API, определяемой Canvas.

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

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

Вы, несомненно, уже обратили внимание на наличие метода paintClipRect (Graphics g) в листинге 6.3. В листинге 6.7 повторяется этот метод. Это первый код, вызываемый методом paint (Graphics g) каждого приложения. Его цель состоит в удалении всех пикселей, которые были нарисованы предыдущей операцией рисования.

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

protected void paintClipRect(Graphics g)

int clipX = g.getClipX (); int clipY = g.getClipY() ;

int clipH = g.getClipHeight(); int clipW = g.getClipWidth();

int color = g.getColor();

g.setColor(WHITE);

g.fillRect(clipX, clipY, clipW, clipH);

g.setColor(color);

}

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

Вы можете получить отсекаемый прямоугольник, вызвав следующие методы Graphics:

int getClipHeight ()

int getClipWidth ()

int getClipX()

int getClipY()

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

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

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

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



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

void clipRect(int x, int у, int width, int height)

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

Вызов clipRect () всегда создает отсекаемый прямоугольник меньшего размера. Вы можете также установить любой размер отсекаемого прямоугольника с помощью следующего вызова:

setClipfint x, int у, int width, int height)

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

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

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



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

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

Персонализация

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

информация о предпочтениях предоставления - настройки того, как информация представляется пользователю;

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

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

Большинство систем использует механизмы персонализации сторонних разработчиков. Как и большинство предназначенного для Web программного обеспечения, большая часть служб персонализации поддерживает API HTML-через-НТТР.

Поддержка интернационализации в 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. Это означает, что вам нужно знать, какой календарь поддерживается вашей платформой, и согласуется ли он с региональной настройкой, поддерживаемой реализацией.

Поддержка постоянного хранения устройством

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

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

Подготовка приложений к системам инициализации

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

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

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

Таблица 10.1. Атрибуты MID-лета, связанные с инициализацией приложения

Название атрибута MID-лета		Описание		Наличие
MI Diet- Dele te-Confirm		Определяет текстовое сообщение, которое должно быть представлено пользователю для подтверждения удаления набора MID-летов. Используется для уведомления пользователей во время работы AMS с приложением для того, чтобы освободить место для установки MID-лета		Необязателен
MIDlet-Description		Определяет текстовое описание набора MID-летов. Используется для представления описания пользователю во время обнаружения		Необязателен
MIDlet-Install-Notify		Определяет LJRL, на который пересылается отчет о состоянии установки MID-лета через HTTP-запрос POST		Необязателен
MIDlet-Jar-Size		Показывает размер (в байтах) файла JAR MID-лета. Используется AMS для определения того, содержит ли устройство достаточно общей памяти для установки набора MID-летов		Обязателен
MIDlet-Name		Определяет название набора MID-летов. Используется для предоставления названия набора MID-летов пользователям		Обязателен
MIDlet-Vendor		Определяет название поставщика набора MID-летов		Обязателен
MIDlet-Version		Используется для перемещения приложения		Обязателен

<
Как среда клиента, так и среда сервера используют файл JAD. Диспетчер инициализации использует его во время инициализации, а клиент использует во время установки и исполнения приложения. Во время инициализации сервер инициализации посылает файл JAD на устройство, где программное обеспечение агента пользователя использует его для подтверждения того, что набор MID-летов совместим с устройством, до загрузки файла JAR всего набора MID-летов. Во время исполнения, как вы узнали из главы 3, AMS использует информацию, представленную в файле JAD, для управления жизненным циклом приложения. Кроме того, AMS делает информацию файла JAD доступной MID-летам набора MID-летов для использования во время выполнения МЮ-лета.

Атрибут MIDlet-Install-Notify является необязательным атрибутом файлов JAD и manifest, который используется для инициализации. Его цель - дать программному обеспечению агента пользователя стандартный механизм передачи состояния установки в службу, предоставляющую набор MID-летов.

Значение атрибута MIDlet-Install-Notify должно описывать URL, на который агент пользователя посылает HTTP-запрос POST, содержащий информацию о состоянии установки. Посылать полный запрос POST в соответствии с рекомендациями приложения «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated Provisioning) спецификации MIDP входит в обязанности агента пользователя. То есть агенту пользователя необходимо получить некоторую информацию о приложении от AMS и включить ее - возможно, как параметры HTTP, - в запрос POST.

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

Хорошей идеей является обеспечение того, что дескрипторы вашего приложения определяют значение атрибута MIDlet-Install-Notify, чтобы агент пользователя мог выдать состояние установки даже в случаях, когда набор MID-летов не был извлечен. Например, возможно, что URL, который определяет местоположение файла JAR и является значением атрибута MIDlet-Jar-URL, неправилен.

Подтверждение пoкyпки и соблюдение обязательных условий

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

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

Подтверждение совместимости

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

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

В действительности проблема подтверждения совместимости является одной из причин, по которым атрибутам MicroEdition-Configuration и MicroEdition-Profile требуются атрибуты файла JAD. Система инициализации использует эту информацию при поиске совместимых приложений.

Поиск приложений

Поиск приложений - это процесс, с помощью которого пользователи обнаруживают интересующие их приложения. Это первый этап процесса инициализации, в который вовлечен конечный пользователь. Большинство систем инициализации обычно предоставляют пользователям какой-либо WML-интерфейс (или XHTML) для обнаружения приложений с помощью мобильных устройств. Мобильные устройства, которые предназначены для загрузки ОТА, имеют НТТР-микробраузер, который, наиболее вероятно, будет интегрирован до некоторой степени в программное ббеспечение пользовательского агента устройства.

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

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

пользовательский контекст;

контекст устройства;

контекст среды платформы J2ME;

требования приложения.

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

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

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

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

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



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

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

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

Чем выше уровень автоматизации, тем более эффективным становится процесс поиска, и тем менее вероятно, что он сделает ошибку. Это важно учитывать как пользователям, так и транспортировщикам. Просмотр вручную занимает много времени и часто приводит к появлению ошибок. Вероятно, можно с уверенностью сказать, что навигация вручную и серфинг по WML-страницам (или XHTML в развивающихся в настоящее время системах) требует длительных соединений. Это следует из больших затрат на время передачи в сетях с коммутацией каналов (сети 2G) и высоких издержек при передаче пакетов в сетях с коммутацией пакетов (сети 2.5G и 3G), которые нежелательны для пользователей. ^Это также занимает полосу пропускания, что нежелательно для транспортировщиков.

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



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

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

Понятия

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

Инициализация ОТА требует установления «телефонного звонка», или соединения для передачи данных в сетях передачи данных, таких, как 2.5G или 3G - для соединения мобильного устройства, которое является клиентом, с инициализирующим сервером. Со стороны сервера диспетчер инициализации теоретически представляет основной компонент системы инициализации, который управляет различными стадиями процесса инициализации. Эти стадии включают динамическое обнаружение, представление описаний содержимого, поставку, фиксацию транзакции и создание счета.

На устройстве программное обеспечение агента пользователя взаимодействует с диспетчером инициализации. Программное обеспечение агента пользователя должно быть совместимо с механизмом взаимодействия, определяемым диспетчером инициализации. Возможны две схемы: обнаружение протокола Wireless Application Protocol (WAP) с HTTP-пересылкой и обнаружение WAP с сегментацией и повторным ассемблированием (SAR) WAP. Беспроводные транспортировщики на определенных рынках, особенно в Японии, создают инфраструктуры, которые поддерживают TCP/IP к телефонной трубке. Эти инфраструктуры способны поддерживать передачу HTML (XHTML) телефонной трубке посредством HTTP-транспортировки, перемещая WAP. Когда эта модель станет более распространенной в реализациях сетей 2.5G и 3G, интерфейсы диспетчера инициализации изменятся соответственно.



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

AMS устройства может иметь возможность действовать в качестве программного обеспечения агента пользователя, или, по крайней мере, быть близко связанной с микробраузером устройства. В качестве альтернативы устройства могут содержать специализированное программное обеспечение обнаружения приложений (discovery application (DA)), чья работа заключается в идентификации наборов MID-летов для пользовательской загрузки. Помимо других обязанностей, программное обеспечение DA должно быть способно размещать инициализированные приложения в месте, доступном AMS. Термин диспетчер приложения Java (Java application manager (JAM)) используется для описания AMS системам, которые поддерживают инициализацию приложений Java.



Программное обеспечение агента пользователя на устройствах-клиентах должно работать совместно с системой инициализации, чтобы иметь возможность взаимодействовать с помощью четко определенных интерфейсов через общедоступный механизм взаимодействия. Обычно беспроводные сети используют HTTP через некоторый транспортный протокол для того, чтобы устанавливать коммуникации уровня приложений с мобильными устройствами. В действительности документ «Over The Air User Initiated Provisioning Recommended Practice, Addendum to the Mobile Information Device Profile» требует, чтобы инициализация OTA поддерживала протокол HTTP. HTTP является единственным протоколом, который должен поддерживаться обязательно. Вы можете найти эту спецификацию по адресу http://java.sun.com/products/midp/. Между прочим, возможно, что рекомендации данного документа станут частью спецификации MIDP-NG (следующее поколение).

Существует три причины инициализации приложений:

для автоматизации процесса определения совместимости приложений и сред, в которые они загружаются,

для предоставления возможности доставки приложений на устройства,

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

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

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



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

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

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

В настоящее время системы инициализации приложений предлагают несколько коммерческих производителей. Многие из их свойств созданы специально для поддержки инициализации приложений J2ME. То есть многие из свойств этих систем связаны с проблемами инициализации в беспроводных средах.

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

Интерфейс 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");

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

Преобразование

Как вы уже знаете, точка (х, у) указывает функции рисования место, расположенное относительно точки (0, 0). Точка (0, 0) является началом координат Graphics. Когда вы впервые получите ссылку на Graphics вашего Canvas, его начало координат, точка (О, О), всегда представляет верхний левый угол дисплея устройства.

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

void translate(int x, int у)

Аргументы являются координатами точки, которая станет новым началом координат объекта Graphics. Точка (0, 0) теперь является этим новым началом координат. Все операции по рисованию теперь относятся к этому новому началу координат. На рисунке 6.9 показан экран, созданный кодом, описанным в листинге 6.8. Он просто рисует заполненный квадрат в Canvas.

При нажатии на кнопку Go начало координат Graphics переносится, а затем заполненный квадрат перерисовывается. На рисунке 6.10 показан обновленный дисплей после того, как кнопка Go была нажата в первый раз. Обратите внимание, что координаты, переданные вызовам методов рисования в методе paint (Graphics g) не изменились. Причина этого кроется в том, что эти координаты всегда связаны с началом координат Graphics, а не с верхним левым углом области дисплея устройства. Операции по рисованию всегда указываются относительно начала координат Graphics, безотносительно к точке места назначения, которое она представляет.

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

Рисунок 6.9. Когда ваш Canvas впервые создан, начало координат его объекта Graphics, (0, 0), всегда относится к верхнему левому пикселю дисплея устройства

Рисунок 6.10. Дисплей после перемещения начала координат. Перемещение означает перенос начала координат объекта Graphics, а не дисплея

Листинг 6.8. После перемещения координаты, указанные процедурам рисования Graphics, не изменяются, поскольку они всегда связаны с началом координат контекста Graphics, а не дисплея

import javax.microedition.Icdui.Canvas;

import javax.microedition.Icdui.Command;

import javax.microedition.Icdui.CommandListener;

import javax.microedition.Icdui.Display;

import javax.microedition.Icdui.Displayable;

import javax.microedition.Icdui.Graphics;

/**

Демонстрирует преобразование контекста Graphics в Canvas.

(Усмотри javax.microedition.lcdui. Graphics

*/ public class TranslationDemo extends Canvas

implements CommandListener

{

private final int WHITE = OxFF « 16 I OxFF « 8 | OxFF;

private GraphicsDemo gDemo = GraphicsDemo.getlnstance ();

private Display display = Display.getDisplay(gDemo);

private static Command back = new Command("Back", Command.BACK, 1);

private static Command go = new Command("Go", Command.SCREEN, 1);

private static final int ORIGINAL_STATE = 1;

private static final int TRANSLATED_STATE = -1;

// Координата х начального рисунка, private int x = 20;

// Координата у начального рисунка, private int у = 20;

// Величина переноса в направлении х. private int deltaX = 30;

// Величина переноса в направлении у. private int deltaY = 30;

// Задает переменную, которая сообщает программе, рисовать ли на экране

// в первоначальной позиции или в преобразованной позиции,

private int state = ORIGINAL_STATE;

/**

Конструктор.

*/

public TranslationDemo()

{

super () ;

addCommand(back);

addCommand(go);

setCommandListener (this);

display.setCurrent(this);

}

protected void paintClipRect(Graphics g)

{

int clipX = g.getClipX() ;

int clipY = g.getClipY() ;

int clipH = g.getClipHeight(); int clipW = g.getClipWidth() ;

int color = g . getColor();

g.setColor(WHITE);

g.fillRect(clipX, clipY, clipW, clipH);

g.setColor (color) ;

}

public void paint(Graphics g)

{

int w = 50;

int h = 50;

paintClipRect(g); g.fillRect(x, y, w, h);



}

// Переключает режим рисования. Этот метод вызывается во время

// обработки команды «Go», которая переключает перемещение.

private void toggleState()

{

state = -state;

}

// Переключает преобразование. Перерисовывает заново Canvas.

private void toggleTranslation()

}

if (state == ORIGINAL_STATE)

x = x + deltaX; у = у т deltaY;

}

else

{

x = x - deltaX;

у = у - deltaY; 1 toggleState();

// Запрашивает у реализации вызов метода paint() для восстановления

// Canvas. Это выражается в генерировании внутреннего события

// рисования, которое обрабатывается реализацией, repaint () ;

*/

public void commandAction(Command c, Displayable d)

{

if (с == back)

GraphicsDemo.getInstanced.display!);

}

else if (c == go)

{

toggleTranslation() ;

}

}

}

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

Приложения личной информационной системы

Приложения личной информационной системы (Personal information management (PIM)) включают такие приложения, как календари с возможностью напоминания о событиях, адресную книгу, записную книжку и так далее. Все это - стандартные утилиты сайтов порталов Интернета. Проблема беспроводных сред заключается в поддержке : пользовательскогр интерфейса для этих приложений.

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

Протокол доступа к сообщениям в Интернете (The Internet mail application protocol (IMAP)) и почтовый протокол (post office protocol (POP)) являются двумя наиболее распространенными протоколами, поддерживаемыми почтовыми серверами. Беспроводные сети будут либо поддерживать эти протоколы на телефонах, либо реализовывать собственные.

Службы календаря обычно определяют свои собственные API и интерфейсы, которые настроены как для Web-доступа, так и для доступа приложений. Некоторые системы определяют один интерфейс HTML-через-НТТР. Клиентскому приложению календаря, которое использует сервер, на котором находится серверный компонент календаря, пришлось бы создавать запросы HTTP в соответствии с API, определенным сервером. Календарное уведомление может использовать SMS для посылки уведомлений клиентам. Приложениям MIDP, например, может понадобиться наличие некоторого способа взаимодействия с родным программным обеспечением обработки сообщений на телефоне. Во время написания данной книги спецификация MIDP не связывала интерфейсы с программным обеспечением родной системы. Ожидается, что спецификация MIDP-NG (следующее поколение) будет связывать интерфейсы родного устройства с приложениями MIDP.

Пример приложения

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

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

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

Следующие файлы включены в адресную книгу, описанную в данном примере:

AddScreen.java;

AddressBook.java;

AddressBookMain.java;

DeleteAllConfirmationScreen.java;

PersistenceDemo.java;

RecordList.java;

SearchResultScreen.java;

SearchScreen.java.

Подробные листинги этих файлов можно найти на Web-сайте «Prentice-Hall» по адресу http://www.phptr.com. Файл PersistenceDemo.java определяет MID-лет, который представляет меню, содержащее приложение адресной книги. Файл AddressBookMain.java определяет точку входа в приложение адресной книги.

В листинге 7.1 показан полный исходный код класса AddressBook.java. Этот класс извлекает подробную информацию о вызовах RMS API из остальной части МID-лета. При инициализации MID-лета он создает экземпляр класса AddressBook, который, в свою очередь, открывает хранилище записей с именем addressbook.

Листинг 7.1. Класс AddressBook позволяет приложению получать доступ к хранилищу записей

import javax.microedition.rms.RecordComparator;

import javax.microedition.rms.RecordEnumeration;

import javax.microedition.rms.RecordFilter;

import javax.microedition.rms.RecordStore;

import javax.microedition.rms.RecordStoreException;

import javax.microedition.rms.RecordStoreNotOpenException;

import Java.io.ByteArrayInputStream/

import java.io.ByteArrayOutputStream;

import Java.io.DatalnputStream;

import java.io.DataOutputStream;

import Java.io.lOException;

/**

Этот класс внедряет простую адресную книгу с целью демонстрации.

В нем хранятся записи, состоящие из полей имени String и номера телефона String.

Этот класс определяет два внутренних класса,

один является блоком сравнения записей, а второй фильтром записей,

используемым при извлечении записей.

*/

public class AddressBook

private static final String RECORD_STORE_NAME = "address-book";

private RecordStore recordStore;

public AddressBook () throws RecordStoreException

super!);

recordStore = RecordStore.openRecordStore(RECORD_STORE_NAME, true);

{

void close() throws RecordStoreException

{

try

{

recordStore.closeRecordStore();

}

catch (RecordStoreNotOpenException rsno)

{

}

}

/*

Получает хранилище записей, используемое этим объектом.

@возвращаем ссылку на RecordStore, используемый э.тим объектом.

public RecordStore getRecordStore()

}

return recordStore;

/**

Добавляет указанную запись в хранилище записей данной адресной книги.

@param name имя входа было добавлено.

@parara phone телефонный номер для входа был добавлен.

@сбрасывает RecordStoreException, если есть проблемы с добавлением записи.

public void addRecord(String name, String phone)

throws RecordStoreException

}

ByteArrayOutputStreara baos = new ByteArrayOutputStream();

DataOutputStream dos = new DataOutputStream(baos);

try

dos.writeUTF(name); dos.writeUTF(phone);

}

catch (lOException ioe)

{

ioe.printStackTracef);

)

int id =

recordstore.addRecord(baos.toByteArray(), 0,

baos.toByteArrayO .lengthy-System, out. println ("Record id = " + id);

}

/**

RecordEnumerator, упорядочивающий записи в

лексикографическом порядке по полям

имен записей.

*/

RecordEnumeration getMatchesByNarae(String matchKey)

throws RecordStoreNotOpenException

(

MacchAllNaraesFilter filter =

new MatchAllNamesFilter(matchKey);


AlphabeticalOrdering comparator =

new AlphabeticalOrdering();

return recordStore.enuraerateRecords(filter,

comparator, false);

}

/**

RecordFilter, устанавливающий совпадение, если имя варианта

(первое поле в записи варианта)!) точно соответствует имени

элемента списка или 2) если строка имени элемента списка

начинается с имени варианта. Возвращает значение true, ее

установлено соответствие, false - в ином случае.

*/

class MatchAllNamesFilter implements RecordFilter

{

String requestString;

public MatchAllNamesFilter(String matchKey) ;

requestString = matchKey;

}

public boolean matches(byte [] candidate)

{

ByteArraylnputStream bais =

new ByteArraylnputStream(candidate);

DatalnputStream dis = new DatalnputStream(bais);

Siring name = null;

try

}

name = dis.readUTF();

if (name.indexOf(requestString) == 0)

return true;

else

return false;

}

catch (lOException ioe)

{

ioe.printStackTrace!);

return true;

}
}

/**

Этот внутренний класс реализует RecordCornparator, чья политика

Заключается в выполнении сортировки по алфавиту.

*/

class AlphabeticalOrdering implements RecordCoraparator

}

Конструктор.

public AlphabeticalOrdering ()

(

)

public int compare(byte [] reel, byte [] rec2)

{

ByteArraylnputStream baisl =

new ByteArraylnputStream(recl);

DatalnputStream disl = new DatalnputStream(baisl);

ByteArraylnputStream bais2 =

new ByteArraylnputStream(rec2);

DatalnputStream dis2 = new DatalnputStream(bais2);

String namel = null; String name2 = null; try

namel = disl.readUTF ();

name2 = dis2.readUTF () ;

}

catch (lOException ioe)

ioe.printStackTrace();

}

if (namel == null II name2 == null) return 0;

int result = namel.compareTo(name2);

if (result < 0)

return RecordCornparator. PRECEDES;

else if (result == 0)

return RecordCoraparator.EQUIVALENT;

else

return RecordComparator.FOLLOWS;

}

}

/**

Удаляет все записи из хранилища данных.

В текущих реализациях самый быстрый способ удаления всех записей

заключается в удалении хранилища данных и повторном его создании,


вместо удаления каждой записи по очереди!

void deleteAHRecords ()

}

try

RecordEnumeration re =

recordStore.enumerateRecords(null, null, false);

while (re.hasNextElement())

*/

int id = re.nextRecordld();

recordStore.deleteRecord(id);

}

}

catch (RecordStoreException rse)

{

rse.printStackTracel);

} }

/**

Получает статистику хранилища данных, используемого данной адресной книгой.
/**

возвращает String статистических данных.

*/

public String getStatistics ()

{

int numRecords = 0;

int space = 0;

StringBuffer stats = new StringBuffer("Records:

*/

try

{

numRecords = recordStore.getNumRecords ();

space = recordStore.getSizeAvailable();

)

catch (RecordStoreException rse)

(

rse.printStackTrace();

}

stats.append(String.valueOf(nuraRecords));

stats.append("\n\n") ;

stats.append("Available bytes: ");

stats.append(String.valueOf(space));

return stats . toString();

}

}
Обратите внимание, что класс AddressBook определяет член типа RecordStore. Это экземпляр действительного хранилища записей, используемого приложением. Класс RecordStore является единственным открыто объявляемым классом в пакете RMS. Он определяет абстракцию хранилища записей.
Конструктор AddressBook сбрасывает RecordStoreException, поскольку метод openRecordStore() может сбрасывать три исключения, которые происходят от него. Пакет javax.microedition.rras определяет пять исключений. На рисунке 7.2 показана иерархия наследования, которая содержит типы исключений RMS.

Рисунок 7.2. Пакет RMS определяет несколько исключений, связанных с доступом к хранилищу данных. Все исключения принадлежат пакету javax.microedition.rms, если не определено иное
Класс AddressBook предоставляет следующие методы, поддерживающие функции уровня приложения, выполняемые в хранилище данных:
void addRecord(String name, String phone)

void deleteAHReccrds ()

String ge-Scatistics ()

RecordEnumeration getAHRecords(String matchKey)
При реализации данного приложения на реальном устройстве необходимо обеспечение более полного набора методов для окончательной доработки этого интерфейса. Тем не менее, данный набор можно использовать с целью демонстрации понятий, связанных с использованием RMS MIDP.


Работа с данными byte [ ]
Как уже упоминалось выше, приложение в этом примере работает с записями, которые содержат имя и номер телефона. Пользователь вводит как имена, так и телефонные номера как объекты String, поскольку экран ввода данных использует экземпляры класса TextField, описанный ранее в главе 5. Соответственно, метод addRecord () получает эти значения String и преобразует их в байты.
Так или иначе, эти значения должны быть преобразованы в один массив байтов перед добавлением в хранилище данных. Причина того, что вы должны выполнить это преобразование, заключается в том, что API RecordStore хранит записи только в виде однобайтового массива.
Метод addRecord () использует стандартную идиому ввода-вывода Java при создании DatalnputStream, который поддерживает запись встроенных типов Java в выходном потоке. Получающийся в результате байтовый массив затем добавляется в объект RecordStore.
Метод RecordStore.addRecord() возвращает int, которая представляет значение ID только что созданной записи. Ваше приложение может сохранить данный ID и использовать его при последующем извлечении записи. Но существует более интересный способ извлечения записей.

Процесс инициализации

На практике процесс инициализации включает две основных фазы:

регистрация приложений;

инициализация зарегистрированных приложений на устройствах.

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

обнаружение - поиск приложения;

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

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

В остальной части данного раздела я просто познакомлю вас с отдельными задачами без ссылки на эти три категории.

Программная cтpyктypa MID-лета

Теперь, когда.вы изучили жизненный цикл приложения, наступило время взглянуть на исходный код простого MID-лета. Вы, возможно, уже догадались, что я собираюсь начать с показа наипростейшего MID-лета - MIDP-версии все той же злополучной программы «HelloWorld». В листинге 3.1 показан исходный код для первой версии MID-лета HelloWorld.

Листинг 3.1. Это MIDP-версия знакомой вам программы HelloWorld

import javax.microedition.lcdui.Display;

import javax.microedition.lcdui.Displayable;

import javax.microedition.lcdui.Form;

import javax.microedition.midlet.MIDlet;

/**

Создание программы «Hello world» в J2ME MIDP.

Обратите внимание, что класс должен быть открытым, для того чтобы программа

управления приложениями устройства могла создать его экземпляр.

*/

public class HelloWorld extends MIDlet

{

// Displayable. Этот компонент отображается на экране, private Form form;

// Display. Этот объект управляет всеми компонентами

// Displayable.

private Display display;

// Открытый конструктор no-arg необходим, даже хотя система

// вызывает startAppO! AMS вызывает конструктор

// no-arg класса для создания экземпляра класса.

// Либо создайте открытый конструктор no-arg, либо

// объявите об отсутствии конструкторов и позвольте

// компилятору создать открытый конструктор no-arg. public HelloWorldO

{

super () ; I

public void destroyApp(boolean destroy)

form = null;

notifyDestroyed();

}

public void pauseAppO

}

public void startAppf)

// Создайте элемент Displayable. form = new Form (."Hello, World");

// Добавьте строку в форму. String msg = "My first MIDlet!"; form.append(msg);

// Это приложение просто выводит на экран одну форму, созданную выше.

display = Display.getDisplay (this) ;:

display.setCurrent(form);

}

}

Во-первых, отметьте, что это приложение описывает класс, называемый HelloWorld, который дополняет javax.microedition.midlet.MIDlet. Все MID-леты должны дополнять этот класс.

Класс HelloWorld является основным классом вашего приложения. По этой причине он должен быть объявлен открытым (public). Более того, вы должны объявить открытый безаргументный (no-argument) конструктор или убедиться, что конструкторов нет, в этом случае компилятор определит безаргументный конструктор для вас. Те читатели, которые знакомы с апплетами Java, найдут сходство между моделями управления жизненным циклом апплета и MID-лета.

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

AMS затем вызовет метод startAppO. В листинге 3.1 методы startApp(), pauseApp() и destroyApp() подменяют абстрактные объявления класса MIDlet. Обратите внимание на то, что все кода инициализации входят в метод startApp (), а не в конструктор. Вы, естественно, можете добавить какой-либо код инициализации в ваш конструктор, он будет выполнен перед вызовом startApp(). Однако метод startApp() всегда вызывается в качестве входной точки вашего MID-лета.

А как насчет метода main ()? Определение языка Java требует, чтобы все приложения на Java имели метод main () со следующей сигнатурой:

public static void main(String [] args)

Если приложения на J2ME являются настоящими приложениями Java, а это требование я оговаривал ранее, тогда где-то должен быть главный метод, который является реальной точкой входа, используемой виртуальной машиной для запуска процесса выполнения приложения. В действительности существует такой метод. Это часть реализации MIDP (не приложения), и, обычно, программное обеспечение AMS вызывает его. Программа AMS обрабатывает запросы вызова приложения, например, порождая подпроцесс нити запроса запуска каждого MID-лета и контролируя MID-лет из этой нити. Реальные детали зависят от продукта. В J2ME Wireless Toolkit компании «Sun» класс com.sun.midp.Main определяет метод main().

Метод startApp() создает объект, называемый формой, и пересылает в конструктор строку, которая представляет из себя название формы. Форма - это экземпляр класса javax.microedition.lcdui.Form, который является разновидностью экрана, отображаемого на вашем дисплее. Она имеет такое название, поскольку ее функции в чем-то сходны с функциями формы HTML - она содержит один или более визуальных элементов, таких как строки.



Затем метод startApp() создает стандартный объект String и добавляет его в форму. Он затем получает ссылку на объект, называемый display, и устанавливает объект формы в качестве текущего отображаемого на дисплее объекта.

Когда этот код выполняется, вы видите экран, изображенный на рисунке 3.4. Когда вы нажимаете на кнопку с телефонной трубкой, которая сообщает устройству об отключении, AMS вызывает destroyApp(), который просто устраняет все ссылки на объект формы, созданные перед этим. Теперь наступает время сборки мусора. Затем AMS закрывает MID-лет.

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

Происхождение, терминология и понятия

Термины беспроводный Web и беспроводный Интернет относятся к среде, в которой беспроводные радиоустройства могут получать доступ к World Wide Web и Интернету. Эти термины являются чем-то абстрактным по той причине, что они не несут информации об архитектуре или физической природе среды. Беспроводной Интернет, как и Интернет, является сетевым комплексом, объединением сетей. Однако, в отличие от Интернета, это объединение беспроводных и проводных сетей.

Беспроводные сети связываются с проводными сетями - и с Интернетом - посредством шлюза беспроводного Интернета (wireless Internet gateway (WIG)), шлюзом, состоящим из аппаратного и программного обеспечения, который соединяет беспроводную сеть транспортировщика с его собственной проводной сетью intranet. Шлюзы беспроводного доступа в Интернет обычно состоят из принадлежащего провайдерам программного и аппаратного обеспечения, которое позволяет взаимодействовать с мобильными центрами коммутации (mobile switching center (MSC)). Вместе все эти компоненты реализуют определенные типы систем беспроводных коммуникаций. Например, многие из производителей мобильных телефонов предлагают свои собственные WIG. Они работают только с определенными системами беспроводных коммуникаций и с определенными базовыми станциями и телефонами.

На рисунке 11.1 показана схематичная логическая диаграмма, которая представляет связи между компонентами беспроводной сети, шлюзами WIG и сетями intranet транспортировщика. WIG дает беспроводной сети - и беспроводным устройствам - доступ в Интернет посредством проводной сети intranet поставщика беспроводной связи. Intranet беспроводного транспортировщика соединяется с проводными сетями или сетевыми комплексами, которые дают ему доступ к Интернету.

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

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

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

Беспроводные порталы поддерживают многие из тех же приложений, что и интернет-порталы. Они предоставляют службы обмена сообщениями, которые включают электронную почту, мгновенный обмен сообщениями (instant messaging (IM)), интегрированную систему обработки сообщений (unified messaging (UM)), наряду с календарем, утилитами книги записи деловых встреч и адресной книги и так далее. Разработчики i приложений создают приложения портала, которые взаимодействуют с этими службами портала посредством программных интерфейсов приложений, определенными службами порталов.

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

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



Аналогичным образом характеристики службы SMS влияют на проектирование и реализацию приложений IM, реализованных поверх инфраструктуры SMS. Например, SMS использует номера мобильного терминала (мобильного телефона) для представления адреса посылающей и принимающей сторон. Это практический выбор разработки, который отражает .информацию, доступную службе SMS.

Можно реализовать систему IM, которая позволяет пользователям указывать пользовательский ID получателей сообщения. Однако, поскольку беспроводные системы указывают мобильные терминалы с помощью их MSN, инфраструктуре приложения обмена сообщениями придется преобразовать пользовательский ID в MSN. Хотя это осуществимо, этот подход вызывает трудности при разработке, и, как обычно, компромиссы в сложности, цене, инфраструктуре, производительности и так далее.

J2ME и MIDP делают подобные интернетовским IM для мобильных устройств более осуществимыми. Теоретически приложения MIDP могут реализовать клиента ICQ или IRC или клиента, который совместим с IM протоколом одного из основных коммерческих порталов. Этот подход может быть даже легче, чем реализация традиционного мобильного IM (SMS), поскольку программные интерфейсы SMS доступны только через расширения собственной платформы.

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

Использование протокола беспроводного приложения (wireless application protocol (WAP)) в средах беспроводного Интернета представляет собой другой пример. Описание протокола WAP и всех более низких уровней протоколов, которые поддерживают WAP, отражает ограничения и трудности транспортировки данных в беспроводных сетях первого поколения. Протокол WAP был предназначен для транспортировки содержимого, созданного на языке разметки беспроводных систем (wireless markup language (WML)). Системы, которые реализуют эту службу, имеют высокоинтегрированные платформенные уровни. Чтобы поддерживать другие комбинации, такие, как транспортировка HTML через WAP, потребовалось бы создание структуры дополнительных служб платформы или инфраструктуры приложений. При разработке приложения пришлось бы учитывать возможности платформы телефона, механизмы транспортировки, производительность и так далее.



Понятие виртуального портала иллюстрирует эту мысль. Виртуальный беспроводной портал - это портал, который не связан физически с беспроводной сетью. То есть он является просто интернет-порталом, который поддерживает службы, совместимые с технологией беспроводных устройств, и к которым беспроводные устройства могут получать доступ посредством механизма связи транспортировщика с интернетом. Беспроводные устройства с возможностью связи с беспроводным Интернетом могут получать доступ к любому интернет-порталу, но с учетом ограничивающей политики, навязываемой беспроводным транспортировщиком. Разработчики приложений портала, которые находятся на интернет-порталах, вероятнее всего, столкнутся с ограничениями устройств и сред, для которых применимы данные приложения. Например, беспроводной пользователь, чья система поддерживает только WML через WAP, не сможет использовать приложение, которое выдает HTML-содержимое.

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

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

К сожалению, в MIDP также отсутствует явная поддержка организации сообщений. В отличие от J2SE, MIDP не предлагает API для работы с сообщениями и здесь нет класса MessageFormat. При разработке решения организации работы с сообщениями в приложении 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. Но эта ситуация будет через несколько лет, а вы должны создавать приложения с расчетом на современные ожидания.

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

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

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

Название метода		Описание
void- closeRecordStore ( )		Закрывает хранилище записей
static void deleteRecordStore ( )		Удаляет хранилище записей
long getLastModif ied ( )		Выдает время последней модификации
String getNameO		Выдает название хранилища записей
int getNumRecords ()		Выдает число записей в хранилище
byte [] getRecordfint recordld)		Извлекает запись по Ю
byte [] getRecord(int recordld, byte [] buffer, int offset)		Получает запись и помещает ее в предоставленный буфер
byte [] getRecordSize (int recordld)		Получает размер указанной записи
int getSizef)		Выдает размер места (в байтах), которое занимает хранилище записей
int getSizeAvailable ( )		Выдает число оставшихся байтов, на которое хранилище записей может вырасти
int getVersionf)		Выдает номер версии хранилища записей
static String [] listRecordStores ()		Выдает список всех хранилищ записей, доступных набору MID-летов
static RecordStore openRecordStore (String name, boolean createlfNecessary)		Открывает указанное хранилище записей, создавая его, если оно не существует

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

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

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

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

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

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

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

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

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

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

Регистрация приложений

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

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

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

Не все системы инициализации могут поддерживать как возможность внутреннего постоянного хранения файлов JAR, так и возможность ссылки на внешние файлы JAR. Как разработчик, вы должны предусмотреть, какие схемы приемлемы и какие, по вашему мнению, соответствуют сценариям использования ваших приложений. Возникают вопросы нетехнического плана - такие, как правовые вопросы обеспечения защиты от несанкционированного доступа к вашему приложению, которое может содержать ценную интеллектуальную собственность, или соглашения служебного уровня (service-level agreement (SLA)) с покупателем или транспортировщиком.

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

Сценарий oбработки команд

Сценарий обработки команд в MIDP является теоретически сходным с другими ин-струментариями графического пользовательского интерфейса. Блок прослушивания команд (command listener) является объектом, который получает уведомления о наличии команд. Блоки прослушивания команд регистрируются для получения уведомления о командах.

Некоторые внешние действия, такие, как нажатие пользователем на кнопку, отражаются в реализации MIDP, обнаруживая событие и связывая его с отображаемым в настоящее время экраном. Это инкапсулирует событие в объект Command. Зарегистрированный блок прослушивания команд получает уведомление о событии. Блок прослушивания затем предпринимает какое-либо действие, которое отражает поведение команды.

Команды могут быть связаны только с элементами Displayable. To есть вы можете добавлять или удалять объекты Command в и из объекта Displayable с помощью следующих методов класса Displayable:

public void addCommand(Command crad)

public void removeCoramand(Command cmd)

Объект блока прослушивания команд должен прикрепляться к Displayable для получения уведомления о команде с помощью вызова следующего метода в объекте

Displayable:

void setCommandListener(CommandListener cl)

Только один блок прослушивания команд разрешен на один Displayable. Реализация MIDP поставляет команды только в текущий Displayable. Это ограничение пришлось ввести с учетом реалистичных ожиданий от производительности современных реализаций MIDP. MIDP определяет модель одной нити для обработки событий. Поддержка многочисленных блоков прослушивания команд потребовала бы модели со множеством нитей обработки событий.

На рисунке 4.1 показана диаграмма UML связей между классами Displayable и Command и интерфейсом CommandListener.

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

Обратите внимание, что эта диаграмма не является всесторонним UML-представлением каждого представителя, атрибута типов и так далее. На рисунке 4.2 показана диаграмма экземпляра объекта, которая отражает взаимодействие экземпляров этих классов в работающем приложении.

Рисунок 4.2. Эта диаграмма объекта показывает, что в работающем приложении могут существовать многие отображаемые на экране объекты и более чем один может регистрировать тот же самый блок прослушивания. Однако Displayable может иметь только один командный блок прослушивания

В отличие от инструментария Swing MIDP не имеет общей модели блока прослушивания событий. Высокоуровневый API имеет только один тип командного блока прослушивания, называемого, что неудивительно, javax.microedition.lcdui.Command-Listener.

В листинге 4.1 показана вторая версия MID-лета HelloWorld. Она добавляет экранные клавиши к главному окну и устанавливает блок прослушивания команд для распознавания нажатия пользователем на экранную клавишу. MID-лет отвечает, показывая другой вид экрана, называемый уведомлением (alert), который является MIDP-эквивалентом всплывающего диалогового окна.

Листинг 4.1. В программу HelloWorld2 добавлена обработка команд

import javax.microedition.midlet.MIDleC;

import javax.microedition.lcdui.Alert;

import javax.microedition.lcdui.AlertType;

import javax.microedition.lcdui.Command;

import javax.microedition.lcdui.CommandListener;

import javax.microedition.lcdui.Display;

import javax.microedition.ledui.Displayable;

import javax.microedition.lcdui.Form;

* /**

Вторая версия приложения HellcWorld.

Эта версия добавляет команду в компонент Displayable и устанавливает

* /

• блок прослушивания команд для активации команд и принятия какого-либо

действия в ответ на нее. Этот пример демонстрирует, как Displayable

определяет семантику выполнения команд.

*/

public class HelloWorld2 extends M.I Diet

// Display. Этот Объект управляет всеми компонентами Displayable.

private Display display;

// Displayable. Этот компонент отображается на экране, private-Form form;

private final String ALERT_LABEL = "Alert Me!"; private Alert alert;

// Две команды добавлены к отображаемым на экране объектам

// этого MID-лета. private Command showAlert; private Command sayHi;



// Экземпляр внутреннего класса, который определяет

// CommandListener для этого MID-лета.

private MyCommandListener cl = new MyCommandListener();

public HelloWorld2()

(

super();

public void destroyApp(boolean destro()

form = null; notifyDestroyed();

}

public void pauseApp()

)

public void startApp()

form = new Form("Hello World();

String msg = "My second MIDletl"; form.appendjmsg);

form.setCommandListener(cl) ;

showAlert = new Command(ALERT_LABEL, Command.SCREEN, 1);

form.addCommand(showAlert) ;

sayHi = new Command("Say Hi", Command.SCREEN, 1);

form.addCommand(sayHi);

display = Display.getDisplay(this) ; display.setCurrent(form);

}

private class MyCommandListener implements CommandListener

public void commandAction(Command c, Displayable d)

{

'alert = new Alert("Button pressed",

"The '" + ALERT_LABEL + "' button was pressed", null, AlertType.INFO); alert.setTimeout(Alert.FOREVER); display.setCurrent(alert, form);

}

}

}

Я создал вышеописанный МID-лет HelloWorld2 с помощью моего любимого текстового редактора. Затем я разместил исходный файл под управление установленного у меня инструментария Wireless Toolkit:

? pwd

/cygdrive/c/J2mewtk/apps/HelloWorld/src

$Is

HelloWorld.lava HelioWorld2.Java

$

J2ME Wireless Toolkit компилирует все файлы .Java в директории. Компиляция проекта HelloWorld компилирует обе версии HelloWorld. На рисунке 4.3 показан стартовый экран эмулятора, который появляется, когда я открываю проект HelloWorld. Обратите внимание, что теперь вы видите два MID-лета в списке. Используя клавиши стрелок, выберите HelloWorld2 и запустите его, нажав экранную кнопку Launch (Запуск).

На рисунке 4.4 показан главный экран HelloWorld2. Обратите внимание, что теперь справа появилась экранная клавиша под названием «Alert Me». На этом устройстве недостаточно места, чтобы показать полное сообщение «Alert Me!», которое установлено в исходном коде - так что восклицательный знак пропущен.



Это первая проблема транспортабельности, с которой вы столкнулись, и она имеет практическое значение. К счастью, эмулятор поддерживает четыре различных устройства. Вы можете выполнить ваши MID-леты с помощью любого из четырех эмуляторов устройств, поддерживаемых эмулятором J2ME Wireless Toolkit Emulator, чтобы посмотреть, как они выглядят на каждом. Таким образом вы можете обнаружить множество потенциальных проблем, связанных с транспортабельностью.



Рисунок 4.3. Добавление нового MID-лета к набору приводит в резул: тате к тому, что AMS отображает меню, из которого вы выбираете приложение, которое хотите запустить



Рисунок 4.4. Основной экран MID-лета HelloWorld2

Ha рисунке 4.5 показан основной экран HelloWorld2, как он появляется при имитировании устройства Motorola i85s. Обратите внимание, что в отличие телефона со стандартными настройками, он способен отображать полный текст команды на экранной клавише. Есть также вторая Command с меткой «Say Hi», которая появляется на экранной клавише слева.

Нажатие на экранную клавишу «Alert Me!» отображает экран уведомления, показанный на рисунке 4.6. Действие отображения этого экрана является поведением, которое HelloWorld2 определило для команды, связанной с выбором экранной клавиши.

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

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



Рисунок 4.5. Изображение первого экрана МЮ-лета HelloWorld2 с добавленной экранной клавишей на эмуляторе Motorola i85s





Рисунок 4.6. Нажатие на экранную клавишу «Alert Me!» отображает это уведомление. Уведомления являются типом отображаемых экранов

Определение CommandListener как интерфейса дает возможность использовать этот второй подход. Каждый тип Screen уже имеет класс более высокого уровня и поэтому не может наследовать от второго родительского класса. Использование интерфейсов Java особенно полезно в данном случае.

После создания экземпляра MyCommandListener экземпляр регистрируется в Form. Затем приложение создает объект Command, чью метку заголовка «Alert Me!» вы видели в эмуляторе. Эта команда затем добавляется в форму. Когда пользователь нажимает экранную клавишу «Alert Me!» на работающем MID-лете, реализация «посылает» уведомление блоку прослушивания, экземпляру MyCommandListener, вызывая метод commandAction(). Метод commandAction () затем создает объект Alert и отображает его.

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

Активизируйте экранную клавишу «Say Hi», расположенную слева в MID-лете HelloWorld2, и вы увидите, что в результате поведение будет тем же самым, как и если бы вы нажали кйопку «Alert Me!», появится то же самое уведомление. Конечно, это поведение неправильно, поскольку Alert показывает, что была активизирована клавиша «Alert Me!».

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



Блок прослушивания регистрируется с и получает уведомления от Displayable, а не от источника события (такого, как клавиша кнопочной панели). Поэтому блок прослушивания должен идентифицировать и «выбрать» команду, в которой он заинтересован, среди всех возможных Command, связанных экраном, отображаемым в настоящее время.

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

Чтобы исправить ошибку в последней версии программы, я переписываю метод commandAction () в классе MyCommandListener, как показано в листинге 4.2.

Листинг 4.2. Блок прослушивания команд теперь различает команды, исследуя их метки

public void commandAction(Command c, Displayable d)

if (c == showAlert)

{

alert = new Alert("Button pressed", "The '" + ALERT_LABEL +

"' button was pressed", null, AlertType.INFO); ) else if (c == sayHi)

alert = new Alert("Button pressed", "The " +

"'Say Hi' button was pressed", null, AlertType.INFO);

}

alert.setTimeout(Alert.FOREVER); display.setCurrent(alert, form);

}

Здесь все еще только один CommandListener на Screen - и может быть только один. Его метод commandAction () вызывается в ответ на нажатие любой клавиши. Но теперь он проверяет контекст уведомления объекта Command и выдает различные уведомления соответственно.

Семантика команд

Взгляните вновь на команду «Exit» («Выход»). Объект Command определяется с помощью метки «Exit» («Выход»). Но это не делает команду командой выхода! Я указал тип Command.EXIT в вызове конструктора. Это указание атрибута типа делает команду командой «Exit» («Выход»). Если бы я задал ее тип, как, скажем, Command. SCREEN, эта команда не появилась бы на экранной клавише. Вы можете попробовать проделать это самостоятельно.

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

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

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

В действительности расстановка приоритетов команд не является столь важной, когда вы работаете с высокоуровневыми API MIDP. Тем не менее, важно знать об этом понятии. Обычно пользователь не способен делать только одну вещь за раз, так что не будет лишним добавить высокоприоритетные события в приложение.

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

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

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

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

Системные качества

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

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

нефункциональные требования описывают системные характеристики или качества системы.

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

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

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

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

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

В контексте системной архитектуры системные качества включают следующие категории:

качества пользовательского уровня - практичность, доступность;

качества уровня служб - производительность, надежность, доступность;

качества стратегического уровня - расширяемость, гибкость;

качества системного уровня - безопасность, управляемость, восстанавливаемость.

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

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

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

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



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

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

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

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

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



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

Гибкость - это измерение того, насколько легко приложение может приспособиться или объединиться с новыми или измененными службами. Например, разработчик нашего почтового клиента MIDP может захотеть предугадать необходимость соединения с обоими почтовыми серверами РОРЗ или ШАР. Это решение может подтвердить реали- } зацию образца разработки, который спрячет подробности механизма соединения от большинства приложений, делая легким добавление поддержки для новых почтовых протоколов программного уровня.

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

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



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

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

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

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



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

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

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

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

Системные свойства

CLDC/MIDP поддерживает системные свойства, которые являются парами «ключ-значение», представляющими информацию о платформе и среде, в которой выполняются приложения MIDP. Теоретически это тот же тип свойств, который вы найдете в J2SE. К сожалению, в CLDC/MIDP нет класса Java.util.Properties для облегчения вашей работы со свойствами.

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

Как и приложения J2SE, приложения MIDP могут отыскивать системные свойства с помощью класса java.lang.System. Чтобы узнать значение свойства, используйте метод класса System

String getProperty(String key)

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

Таблица 3.4. Стандартные системные свойства CLDC

Ключ свойства		Описание		Значение по умолчанию
mi с г oedit ion. con figuration		Название и версия поддерживаемой конфигурации		CLDO1.0
microedit ion. encoding		Набор знаков кодировки по умолчанию, используемый платформой		IS08859-1
micr oedit ion. locale		Название текущей местной среды платформы		нуль
microedition. platform		Название платформы или устройства		нуль
micr oedition. profiles		Названия всех поддерживаемых профилей		нуль

Листинг 3.2 иллюстрирует отслеживание системных свойств в MID-лете. Код дополняет пример, указанный в листинге 3.1.

Листинг 3.2. MID-леты имеют прямой доступ ко всем четырем стандартным системным свойствам, определяемым спецификацией CLDC

import javax.microedition.Icdui.Display;

import javax.microedition.Icdui.Displayable;

import javax.microedition.Icdui.Form;

import javax.microedition.midlet.MIDlet;

/**

Создание программы «Hello world» в J2ME MIDP.

Заметьте, что класс должен быть открытым, для того чтобы программа

управления приложениями устройства могла создать его экземпляр.

*/

public class HelloWorld extends MIDlet

public void startApp()

{

// Создайте элемент Displayable. form = new Fo.rmC'Hello World");

// Добавьте строку в форму. String msg = "My first MIDlet!"; form.append(msg);

// Это приложение просто выводит на экран одну форму, созданную выше.

display = Display.getDisplay(this);

display.setCurrent(form);

printSystemPropertiesf) ;

/**

Вывести значения стандартных системных свойств

С помощью вызова System.getProperty().

*/

protected void printSystemProperties()

String conf;

String profiles; String platform; String encoding; String locale;

conf = System.getProperty("microedition.configuration") ;

System.out.println(conf);

profiles = System.getProperty("microedition.proflies");

System.out.println(profiles);

platform = System.getProperty("microedition.platform");

System.out.println(platform);

encoding = System.getProperty("microedition.encoding");

System.out.println(encoding);

locale = System.getProperty("microedition.locale");

System.out.println(locale); System.out.println();

}

}

Обратите внимание на добавление вызова к методу printSystemProperties () в конце метода startApp(). Этот метод просто извлекает и отображает стандартные данные значений пяти стандартных системных свойств MIDP. Данные, которые программа записывает в стандартные результаты, показаны здесь:

CLDC-1 .0

MIDP-1.0

J2me

ISO-8859-1

enJJS

Четвертая строчка выходных данных просто воспроизводит набор знаков кодировки, который использует текущая реализация платформы CLDC/MIDP. Последняя строка выходных данных отражает текущую локализацию. Спецификации локализации включают две части: первая часть показывает языковые настройки, в то время как вторая часть показывает код страны. Международная организация по стандартизации (ISO) издает два стандарта, которые определяют набор приемлемых значений для языкового и странового кодов.

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

Системы управления приложениями устройств

Все приложения J2ME - MID-леты и другие - являются настоящими приложениями Java, которые запускаются под контролем Java VM. Но что контролирует Java VM, например, на мобильном телефоне? Не существует командного процессора, с которого вы можете активизировать ваши любимые приложения Java, как вы можете сделать на рабочей станции. Запуск, остановка и управление приложениями Java контролируется программами управления приложениями {application management software, AMS), которые находятся на этом устройстве. В действительности AMS контролирует весь жизненный цикл приложения от установки, обновления и управления версиями до удаления программного обеспечения.

Производители устройств обычно предоставляют программное обеспечение AMS. Это самый логичный сценарий, потому что программное обеспечение AMS должно работать вместе с программным обеспечением родной системы устройства, которую, по всей видимости, производитель знает лучше всего. Тем не менее, производители комплектующего оборудования также могут разрабатывать системы AMS для определенных устройств. Программное обеспечение AMS может быть написано, например, в Java или некоторых других машинных языках, таких, как С. Понимание вопросов, связанных с управлением приложениями, важно для разработчика на J2ME. Управление приложениями описывается в главе 10. Вы должны знать о последствиях вашего выбора в отношении упаковки, лицензирования, загрузки для использования и так далее, и как эти решения повлияют на удобство, простоту использования и жизнеспособность вашего программного обеспечения.

Службы местоопределения

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

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

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

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

Глобальная система местоопределения (Global positioning system (GPS)) - мобильные устройства содержат полностью основанные на технологии GPS приемные устройства.

Сетевое местоопределение - технология и обработка местоопределения расположены отдельно в беспроводной сети.

Полуавтоматическая GPS - телефон и сеть работают совместно для предоставления полной информации о местоположении.

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

Локальная информация, создаваемая сетевыми системами, менее точна, чем информация, создаваемая системами GPS. В основанных на сети системах беспроводная сеть сама определяет положение мобильного устройства. Мобильный центр коммутации (mobile switching center (MSC)) должен содержать программное обеспечение, которое может пересылать эту информацию службам приложения. Поскольку MSC обычно прозрачен для приложений, транспортировщик должен создавать объединение между MSC и службами приложения. То есть эти системы должны быть приспособлены друг к другу.

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

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

Содержание и cmpyктypa книги

Структура книги следующая:

Глава 1: Знакомство с платформой Java 2 Micro Edition (J2ME)

Глава 2: Процесс разработки приложений MIDP

Глава 3: Программная структура приложений MIDP

Глава 4: Высокоуровневый программный интерфейс приложения (API) MIDP

Глава 5: Компоненты пользовательского интерфейса (UI) MIDP

Глава 6: Низкоуровневый программный интерфейс приложения (API) MIDP

Глава 7: Поддержка постоянного хранения в MIDP

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

Глава 9: Интернационализация

Глава 10: Инициализация приложений

Глава 11: Среда беспроводного Интернета

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

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

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

Глава 4 продолжает тему главы 3. В ней затронут высокоуровневый программный интерфейс приложения (API) в MIDP, который заключает в себе набор компонентов UI, определяемых MIDP. Вы узнаете, как манипулировать различными компонентами UI, а также как выполнять обработку событий, называемую command processing в терминологии MIDP.

В главе 5 описа'ны компоненты пользовательского интерфейса (UI) MIDP. После изучения базовых обобщенных понятий, определяемых MIDP и описанных в главе 4, вы готовы к изучению того, как использовать компоненты, которые строятся на основе этих обобщений.

В главе 6 описывается низкоуровневый программный интерфейс приложения (API) в MIDP, который реализуется остальными компонентами UI MIDP, не описанными в главе 5.

В главе 7 описываются механизмы постоянного хранения, доступные вам благодаря MIDP.

Глава 8 посвящена организации сетей и коммуникаций. Здесь вы узнаете, как использовать службы организации сети и распределенной обработки данных и функциональные возможности, определяемые CLDC и MIDP. Вы также получите некоторое понятие о решениях создания и поддержки служб связи в J2ME.

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

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

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

Соединения 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.



Рисунок 8.5. Базирующиеся на сокетах службы должны быть способны выполнять асинхронную обработку. Демон порождает нить для контролирования взаимодействия с каждым клиентом

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

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

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

address := <протокол>://<адресат>

protocol := "socket"

target := [<хост>]:<порт>

host := Оначимое DNS-имя хоста или его номер>

port := оначимый системный номер порта>

Еще раз повторюсь, присутствие или отсутствие имени компьютера в URI говорит о том, является ли соединение серверным или клиентским. Демон сервера сначала открывает соединение на своем известном сокете, как показано в следующем примере:

StreamConnectionNotifier wellKnown =

Connector.open("socket://:98765");



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

StreamConnectionNotifier wellKnown =

Connector.open("serversocket://:98765");

Класс StreamConnectionNotifier является MIDP эквивалентом класса Java.net.Serversocket платформы J2SE. StreamConnectionNotifier является на самом деле сокетом сервера.

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

StreamConnection clientConn = vellKnovn.acceptAndOpen();

Этот оператор блокирует операции до тех пор, пока не появится запрос клиента на соединение. При появлении запроса клиента на соединение метод acceptAndOpen () обрабатывает запрос перед передачей управления. Чтобы обработать запрос на соединение, он

Принимает запрос на соединение;

Создает новый объект соединения;

Связывает соединение с неиспользуемым сокетом;

Уведомляет клиента о новом соединении сокета.

Эти этапы объясняют название StreamConnectionNotifier. Демон сервера будет «уведомлен» о запросе на соединение при возвращении вызова блокирующего acceptAndOpen (). И он уведомляет клиента о том, что он должен прослушивать новый сокет, установленный для взаимодействия клиент-сервер. В таблице 8.13 показан единственный метод интерфейса StreamConnectionNotifier.

Таблица 8.13. Методы интерфейса 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 - представляет клиента.

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

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

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

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

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

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

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

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

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

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

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

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

Название метода HttpConnection	Описание
long getDate ( )	Выдает значение поля заголовка даты
long getExpiration ()	Выдает значение поля заголовка Expires
String 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.

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

Константа HttpConnection	Описание
static String GET	Представляет метод запроса GET
static String HEAD	Представляет метод запроса HEAD
static int HTTP_ACCEPTED	HTTP статус 202
static int HTTP_BAD_GATEWAY	HTTP статус 502
static int HTTP_BAD_METHOD	HTTP статус 405
static int HTTP_BAD_REQUEST	HTTP статус 400
static int HTTP_CLIENT_TIMEOUT	HTTP статус 408
static int HTTP_CONFLICT	HTTP статус 409
static int HTTP_CREATED	HTTP статус 201
static int HTTP_ENTITY_TOO_LARGE	HTTP статус 413
static int HTTP_EXPECT_FAILED	HTTP статус 41 7
static int HTTP_FORBIDDEN	HTTP статус 403
static int HTTP_GATEWAY_TIMEOUT	HTTP статус 504
static int HTTP_GONE	HTTP статус 410
static int HTTP_INTERNAL_ERROR	HTTP статус 500
static int HTTP_LENGTH_REQUIRED	HTTP статус 41 1
static int HTTP_MOVED_PERM	HTTP статус 301
static int HTTP_MOVED_TEMP	HTTP статус 302
static int HTTP_MULT_CHOICE	HTTP статус 300
static int HTTP_NO_CONTENT	HTTP статус 204
static int HTTP_NOT_ACCEPTABLE	HTTP статус 406
static int HTTP_NOT_AUTHORITATIVE	HTTP статус 203
static int HTTP_NOT_FOUND	HTTP статус 404
static int HTTP_NOT_IMPLEMENTED	HTTP статус 501
static int HTTP_NOT_MODIFIED	HTTP статус 304
static int HTTP_OK	HTTP статус 200
static int HTTP_PARTIAL	HTTP статус 20В
static int HTTP_PAYMENT_REQUIRED	HTTP статус 402
static int HTTP_PRECON_FAILED	HTTP статус 412
static int HTTP_PROXY_AUTH	HTTP статус 407
static int HTTP_REQ_TOO_LONG	HTTP статус 414
static int HTTP_RESET	HTTP статус 205
static int HTTP_SEE_OTHER	HTTP статус 303
static int HTTP_TEMP_REDIRECT	HTTP статус 307
static int HTTP_UNAUTHORIZED	HTTP статус 401
static int HTTP_UNAVAILABLE	HTTP статус 503
static int HTTP_UNSUPPORTED_RANGE	HTTP статус 416
static int HTTP_UNSUPPORTED_TYPE	HTTP статус 41 5
static int HTTP_USE_PROXY	HTTP статус 305
static int HTTP_VERSION	HTTP статус 505
static String_HTTP_POST	Представляет метод запроса POST

<


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

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

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

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

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



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

}

}

Листинг 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();

}

}

}

Листинг 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();

}

}

}

Листинг 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.3. Объекты HttpConnection переходят в три различных состояния во время своего существования

Таблица 8.6. Методы интерфейса HttpConnection для создания запроса HTTP

Название метода HttpConnection	Описание
void setRequestMethod (String method)	Устанавливает метод запроса HTTP, либо HEAD, либо POST, либо GET
void setRequestProperty (String key, String value)	Включает в запрос указанное поле заголовка со значением, установленным на value

Таблица 8.7. Методы интерфейса HttpConnection, которые позволяют соединению перейти в состояние «установлено»

Название метода 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.

Таблица 8.8. Методы интерфейса HttpConnection, вызываемые в состоянии «установлено»

Название метода HttpConnection	Описание
void close ()	Прерывает соединение (происходит из интерфейса Connection)
String getFile()	Получает поле <file> URL данного соединения
String getHostO	Получает поле <host> URL данного соединения
int getPortO	Получает поле <port> URL данного соединения
String getProtocol ()	Получает поле <protocol> URL данного соединения
:" i ing getQuery ()	Получает строку запроса URL данного соединения
String getRequestMethodf)	Получает текущий метод запроса (GET, POST и так далее)
String getRequestProperty (String key)	Получает значение свойства указанного общего запроса данного соединения
String getRef()	Получает поле <ref> URL данного соединения
String getURL()	Получает полный URL данного соединения как строковое значение

<


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

Соединения HTTP могут транспортировать множество различных видов содержимого, такого, как HTML и XML. Кроме того, HTTP может использоваться как упаковщик для туннелирования других данных протокола уровня приложений. Вы, таким образом, имеете удобный механизм передачи данных для приложений клиент-сервер.

HTTP широко используется серверами как механизм передачи множества различных служб. Службы могут быть реализованы с помощью любой из множества технологий, независимо от того, что они используют HTTP в качестве механизма передачи. Службы могут быть реализованы с помощью сервлетов Java, Java Server Pages (JSP), Pearl scripts, CGI и так далее.

Модель сервлетов является особенно мощной, поскольку сервлеты написаны на Java и легко стыкуются с другими технологиями Java enterprise, они также без проблем взаимодействуют с клиентскими технологиями. Кроме того, сервлетные системы поддерживаются стандартными Web-серверами и могут без труда создавать выводимые данные в различных форматах. В главе 11 вы узнаете, как порталы беспроводного Интернета используют эти технологии для построения служб для мобильных устройств.

Соглашения, используемые в этой книге

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

Таблица 1.1. Соглашения об обозначениях

Описание данных		Используемое обозначение
Исходные коды Java, машинно-генерируемый текст		Шрифт Courier
Первое использование нового термина		Курсив
Обычный текст		Шрифт Times New Roman

Таблица 1.2. Соглашения исходных кодов, используемые в этой книге

Тип данных		Пример
Имена методов Java, имена переменных: Первое слово с маленькой буквы, последующие слова с большой		Protected int variableName Public void lookAtThisMethodName ()
Имена классов Java: первая буква заглавная для всех слов		Public class AllWordsFirstCapital

Согласование лицензии на программное обеспечение

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

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

Среда беспроводного приложения

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

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

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

Среда, показанная на рисунке 11.2, является той, в которой беспроводные приложения устанавливаются и запускаются. Эти приложения включают не только приложения телефонов - такие, как приложения МID, - но также серверные компоненты, которые поддерживают службы, используемые приложениями на телефоне.

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

Платформа J2ME, и MIDP в частности, создают платформу, которая поддерживает так называемых интеллектуальных клиентов. Они могут быть приблизительно определены как приложения, которые выполняют значительно больший объем обработки на клиенте, чем Web-приложения. Огромное количество приложений MIDP будет приложениями клиент-сервер или распределенными приложениями, взаимодействующими с компонентами клиент-сервер. Эти приложения M1DP будут взаимодействовать с системами, которые находятся в сети intranet беспроводного транспортировщика.

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

Большая часть Интернета стандартизирована на HTTP как на основном транспортном механизме сеансового уровня. Протоколы уровня приложений туннелируются при помощи HTTP, что связано с вопросами безопасности. Рисунок 11.2 отражает эту архитектуру между intranet, Интернет и пользовательскими объектами.

Беспроводная сеть, однако, ставит некоторые уникальные проблемы. Беспроводные сети используют сложные наборы собственных протоколов, которые представляют собой решения практических проблем реализации организации межсетевого обмена между беспроводными интерфейсами. Эти собственные наборы развиваются параллельно совершенствованию беспроводных систем и их продвижению к поддержке TCP/IP на телефонных трубках в системах третьего поколения (3G). Тем не менее, уровни, лежащие под сетевым уровнем, все еще очень отличаются от уровней, расположенных в проводных сетевых комплексах.



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

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

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



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

Более интересен для разработчиков MIDP набор протоколов над транспортным уровнем. Существует два основных небора. Первый использует протокол WAP, использование которого горячо отстаивается во многих современных беспроводных Web-системах. По причинам, связанным с практической разработкой, WAP транспортирует содержимое, форматированное на языке разметки для беспроводных систем (wireless markup language (WML)). Второй подход, который, вероятно, будет принят в системах 3G, транспортирует XHTML/XML через HTTP. Кроме того, протоколы уровня приложений могут быть туннелированы с помощью HTTP.

Stringltem

Класс Stringltem определяет двухсоставный компонент дисплея. Объекты Stringltem содержат метку и какой-либо неизменяемый текст. На рисунке 5.7 показан экран, отображаемый классом StringltemDemo, который вы можете запустить из окна, в котором указаны основные компоненты пользовательского интерфейса.

Рисунок 5.7. Строковые элементы состоят из двух частей: текстовая метка и текстовое значение

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

Листинг 5.6. Строковые элементы являются формами

import javax.raicroedition.lcdui.Command;

import javax.microedition.lcdui.CommandListener;

import javax.microedition.lcdui.Displayable;

import javax.microedition.lcdui.Form;

import javax.microedition.lcdui.Stringltem;

/**

Это? класс демонстрирует использование класса

Stringltem пользовательского интерфейса MIDP.

@see javax.microedition.lcdui.Stringltem

*/

public class StringltemDemo extends Form implements CommandListener

private Command back = new Command("Back", Command.BACK, 1);

private static Displayable instance;

private Stringltem si = new Stringltem("Stringltem's title",

"Immutable item text");

/**

Конструктор.

"/

public StringltemDemo()

super("Stringltem Demo"); append(si); addCoramand(back);

setCommandListener(this);

}

instance = this;

}

...

}

Объекты Stringltem предоставляют вам удобный способ связать метку со значением. Вы можете вложить String в Form вместо использования объекта Stringltem, но Stringltem имеет преимущество, выражающееся в том, что его реализация гарантирует, что строки метки и значения останутся на дисплее вместе.

Структуры архитектуры

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

SunTone AM предлагает структуру, чьи основные характеристики включают:

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

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

управляемая системными качествами - обращение к системным качествам на всех этапах разработки;

архитектурно-ориентированная - твердая приверженность архитектурным принципам;

базирующаяся на примерах - применение при решении задач проектирования образцов, которые на практике доказали, что являются решениями общераспространенных проблем.

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

Полное описание или объяснение даже одного из этих принципов лежит за пределами возможностей данной книги. Краткое описание, предоставляемое здесь, тем не менее, предназначено для ознакомления вас с понятиями, связанными с этими архитектурными принципами, и дает вам, разработчику приложений J2ME, понятие о том, как получить преимущества от искусства и науки построения архитектуры. Для более тесного знакомства с архитектурой и архитектурной методологией SunTone AM смотрите книгу "Dot-Corn & Beyond".

Первый элемент структуры SunTone AM, случай использования, - это описание системного требования. Случаи использования собирают и документируют системные требования в читабельной для человека форме. Невозможно преувеличить значение того, что разработка будет отвечать требованиям системы. Процесс сбора требований является деятельностью, дополняющей построение архитектуры. Существует несколько хороших книг, которые объясняют случаи использования в полном объеме, такие, как книга Элистера Кокбарна (Alistair Cockburn) «Writing Effective Use Cases», которая указана в разделе «Справочная литература» в конце данной книги.

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

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

Сбор требований - указание новых требований и детализирование существующих требований.

Построение архитектуры - описание разработки системы.

Разработка - например, объектно-ориентированный анализ и проектирование.

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

Тестирование - тестирование функциональной возможности, встроенной на данном этапе.

Отладка - выявление, локализация и исправление ошибок.

SunTone AM объединяет эти этапы в повторяемые циклы, каждый раз улучшая свою реализацию до тех пор, пока все требования не будут соблюдены. Например, при разработке IMAP-почтового клиента для платформы MIDP разработчик может понять, что определенную архитектуру нелегко реализовать из-за ограничений доступных библиотек. Разработчик понимает это после прохождения через'первый цикл вышеуказанных этапов разработки. После завершения первоначального прототипа становится ясно, что некоторую часть логической схемы сложно реализовать.



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

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

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

Свойства приложения

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

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

String getAppProperty(String key)

Параметр key является именем атрибута, например, MIDlet-Name. Возвращаемая строка является связанным значением, находящимся в файле JAD.

Листинг 3.3 демонстрирует, как MID-лет может извлекать атрибуты. Он модифицирует листинг 3.2, добавляя вызов к методу printAppProperties() в конце метода startApp(). Новый метод startApp() :

Листинг 3.3. Измененный метод теперь также выдает свойства приложения. Программное обеспечение AMS устройства управляет свойствами приложения.

public void startApp()

// Создайте элемент Displayable. form = new FormC'Hello, World")/'

// Добавьте строку в форму. String msg = "My-first MIDlet!"; form.append(msg);

// Это приложение просто выводит на экран одну форму,

// созданную выше.

display = Display.getDisplay (this) ;

display.setCurrentfform);

printSystemProperties () ; printAppProperties () ) ) ;

}

Метод, показанный в листинге 3.3, выдает значения стандартных свойств приложения MID-летa в стандартный результат. Листинг 3.4 показывает метод printAppProperties().

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

/ * *

Вывести свойства приложения с помощью вызова

MIDlet.getAppProperty ().

*/

protected void printAppProperties ()

(

System.out.println(getAppProperty("MI Diet-Name"));

System.out.println(getAppProperty("MIDlet-Jar-Size"));

System, out. println (getAppProperty ("MI Diet-Jar-URL ")) ;

System.out.println(getAppProperty("MIDlet-Vendor"));

}
Эта последняя версия программы HelloWorld теперь выводит следующие строки в дополнение к стандартному результату, который вы можете видеть в окне основной консоли Wireless Toolkit. Метод printAppProperties () выводит последние четыре строки результата.
CLDC-1.0

MIDP-1.0

J2me

ISO-8859-1

en_US

HelloWorld 6781

HelloWorid.jar Vartan Piroumian
Четыре атрибута, выбранные в листинге 3.4, являются стандартными свойствами приложений, доступными для всех MID-летов. Однако вспомните главу 2 и то, что в таблице 2.4 описаны некоторые дополнительные обязательные атрибуты MID-лета. Также спецификация MIDP определяет некоторые необязательные дополнительные атрибуты, в таблице 2.5 перечислены эти необязательные атрибуты. Ваши приложения имеют доступ к ним ко всем через механизм, продемонстрированный в листингах 3.3 и 3.4.
Кроме того, MID-леты могут описывать необязательные зависимые от приложения атрибуты. Вы можете описать так много связанных с приложением свойств, сколько хотите. Ваше приложение будет затем получать к ним доступ с помощью метода MIDlet.getAppProperty(), показанного в листингах 3.3 и 3.4. Эта возможность является своего рода конфигурированием или механизмом настройки MID-летов. Вы увидите некоторые примеры выборочного описания атрибутов и их использования в главе 9.

Ticker

Тикер (Ticker) является объектом, предоставляющим прокручиваемый текст наверху дисплея. TickerDemo в листинге 5.8 создает дисплей, показанный на рисунке 5.9.

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

Ticker связан с дисплеем, но не с экраном. Вы размещаете Ticker на экране с помощью метода Screen.setTicker (Ticker t), как показано в коде листинга 5.8.

Листинг 5.8. Исходный код демонстрационной программы Ticker

import javax.microedition.lcdui.Command;

import javax.microedition.lcdui.CommandListener;

import javax.microedition.lcdui.Display;

import javax.microedition.lcdui.Displayable;

import javax.raicroedition.lcdui.Ticker;

import javax.raicroedition.lcdui.Form;

/**

Этот класс демонстрирует использование класса

Ticker пользовательского интерфейса MIDP.

@see javax.microedition.lcdui.Gauge

*/

public class TickerDerno extends Form

implements CommandListener

}

private String str = "This text keeps scrolling until the demo stops...";

private Ticker ticker = new Ticker(str);

private Command back = new Command("Back", Command.BACK, 1);

private static Displayable instance;

/**

Конструктор.

*/

public TickerDemo()

{

super("Ticker demo");

instance = this;

addCommand(back); setTicker(ticker) ; setCommandListener(this);

{

...

}

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

Взглянув на рисунок 5.1 еще раз, вы заметите, что Ticker не является Item. Он является производным непосредственно от Java.lang.Object, что подсказывает вам, почему Ticker может быть привязан к дисплею, а не к экрану. Его не нужно извлекать из Item, поскольку он на самом деле не является чем-то, что размещено в Form.

Imageltem

Несколько компонентов пользовательского интерфейса MIDP поддерживают отображение изображений. На рисунке 5.10 показано изображение, отображенное в форме. В листинге 5.9 показан исходный код для программы, которая отображает рисунок 5.10.

Рисунок 5.10. Несколько компонентов пользовательского интерфейса MIDP поддерживают отображение изображений. Здесь форма содержит компонент Image Item, который отображает изображение

Листинг 5.9. Конструктор создает объект изображения и пересылает его компоненту пользовательского интерфейса для отображения. Обратите внимание, что указание пути для изображения относительно к директории ресурсов этого проекта при установке с помощью инструментария J2ME Wireless Toolkit

import javax.microedition.lcdui.Command;

import javax.microedition.Icdui.ComraandListener;

import javax.microedition.Icdui.Displayable;

import javax.microedition.Icdui.Form;

import javax.microedition.Icdui.Image;

import javax.microedition.Icdui.Imageltem;

import Java.io.lOException;

/**

Этот класс демонстрирует использование класса

Imageltem пользовательского интерфейса MIDP.

Усмотри javax.microedition.Icdui.Imageltem

*/

public class ImageltemDemo extends Form implements CommandListener

{

private Imageltem imageltem;

/**

Конструктор.

@сбрасывает lOException, если указанный ресурс изображения не может быть найден.

public ImageltemDemo() throws lOException

*/

super("Imageltem Demo");

String path = "/bottle80x80.png";

Image image = Image.createlmage(path);

imageltem = new Imageltem)"Ship in a bottle", image,

Imageltem.LAYOUT_CENTER,

"Image not found"); append(imageltem);

addCommand(back);

setCommandListener(this) ;

instance = this;

}

...

}

В листинге 5.9 демонстрируется использование класса Imageltem компонента пользовательского интерфейса MIDP. Imageltem является подклассом Item, так что он должен быть размещен в Form, как было продемонстрировано в листинге.

Прежде чем вы сможете отобразить изображение, вы должны создать объект изображения. Класс javax.microedition.lcdui.Image определяет изображения. Чтобы создать экземпляр Image, укажите имя пути к файлу изображения. Файлы изображений должны храниться в формате Portable Network Graphics (PNG). J2ME поддерживает работу с изображениями только в этом формате.



Обратите внимание, что в листинге 5. 9 имя пути файла изображения связано с директорией res/ директории проекта UlComponents. Директория res/ содержит все файлы ресурсов, включая файлы изображений. Если вы разместите свои изображения где-либо еще, они не будут найдены и ваша программа сбросит lOException, когда попытается открыть файл.

В листинге 5.9 конструктор создает Imageltem с помощью только что созданного объекта Image. Параметрами конструктора являются строка заголовка, которая отображается над изображением, объект изображения, указание размещения изображения и текстовая строка, которая будет показана в случае, если изображение не может быть отображено по какой-либо причине.

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

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

Компонент пользовательского интерфейса MIDP	Описание
Alert	Изображение отображается вместе с текстом
ChoiceGroup	Изображение отображается слева от текста каждого элемента
List	Изображение отображается слева от текста элемента
Imageltem	Предоставляет контроль размещения самого объекта изображения

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

Удаление приложения

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

Разработчикам не нужно предусматривать уведомление сервера об удалении приложения. В этот процесс вовлечены только агент пользователя и сервер. Разработчики ' должны, однако, предусмотреть вероятность необходимого удаления приложения на клиенте при подготовке файла JAD приложения. Атрибут MIDlet-Delete-Conf irm является необязательным атрибутом файла JAD. Цель - предоставить AMS текстовое сообщение, предоставляемое пользователю для подтверждения удаления связанного набора MID-летов.

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

Упорядочивание команд

Вы, должно быть, удивлены, почему команда «Cancel» (Отмена) была помещена на экранную клавишу, даже несмотря на то, что бна была добавлена на экран последней. Интуитивно вы можете предположить, что она должна добавляться последней в меню. Вы бы предположили, конечно, что клавиша «Alert Me!», которая была добавлена первой, должна быть на экранной клавише.

Объяснение этого очевидного отклонения заключается в том, что команды организуются в соответствии с их типом. Вспомните из предыдущего раздела этой главы, что одной из трех частей информации, которые определяют Command, является тип команды. Класс Command определяет константы, которые представляют собой действующие типы. Вы видели перечисление этих констант в таблице 4.1.

Теперь я добавляю следующие объекты Command в пример HelloWorld3. На уровне классов я определяю следующие новые команды:

...

public class HelloWorid3 extends MIDlet

private Command exit = new Command("Exit", Command.EXIT, 2);

private Command help = new Command ("Help", Command.HELP, 3);

private Command item. = new Command ("Item", Command . ITEM, 4 ) ;

private Command ok = new Command("OK", Command.OK, 5);

private Command screen = new Command("Screen", Command.SCREEN, 6);

private Command stop = new Command("Stop", Command.STOP, 7);

...

}

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

В методе startApp() я добавляю эти новые объекты команд к главному экрану. Новая версия startApp() выглядит таким образом:

public void startApp()

// Создайте элемент Displayable. form = new Form("Hello World");

// Добавьте элемент строки в форму. String msg = "My first MIDlet!"; form.append(msg);

// Добавьте MyCommandListener в Form, чтобы принимать

// события нажатия клавиш, которые должны порождать

// всплывание диалогового окна уведомления, form.setCommandListener(cl);

form.addCommand(showAlert); form.addCommand(sayHi);

form.addCommand(cancel) ;

form.addCommand(exit} ;

form.addCommand(help); form.addCommand(item);

form.addCommand(ok); form.addCommand(screen);

form.addCommand(stop);

// Это приложение просто отображает одну форму, созданную выше,

display = Display.getDisplay(this); display.setCurrentfform);

}

Когда вы запустите новую версию, первое, что вы должны заметить, это то, что команда «Cancel» («Отмена») замещена командой «Exit» («Выход») на экранной клавише, как показано на рисунке 4.10. Активация меню показывает, что клавиша «Cancel» («Отмена») все еще на самом деле здесь, но теперь она в меню.



Рисунок 4.10. Реализация MIDP определяет политику размещения команд в соответствии с их типом

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

Установка приложения и подтверждение установки

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

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

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

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

Подтверждение установки включает информирование диспетчера инициализации об успешной установке. Уведомление об установке важно, поскольку пользователи обычно получают счета после того, как они установили приложение. Атрибут MIDlet-Install-Notify предоставляет способ для разработчиков приложений указывать URL, к которому должна быть послана HTTP-команда POST при успешной установке. Разработчики могут задавать значение этого атрибута. Иногда это значение будет задавать инициализирующее программное обеспечение, поскольку диспетчер инициализации лучше знает URL, который он установил для отслеживания установок.

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

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

Платформа J2ME предназначена для двух

Платформа J2ME предназначена для двух классов портативных компьютерных устройств. Первый класс состоит из стационарных устройств с фиксированными сетевыми соединениями, таких, как компьютерные приставки к телевизору. Второй класс состоит из персональных мобильных устройств с нестационарной сетевой связью, таких, как «карманные» компьютеры, мобильные телефоны и так далее.
Различные комбинации конфигураций и профилей J2ME поддерживают эти классы устройств. Конфигурация CDC и профиль Foundation поддерживают первый класс устройств, а конфигурация CLDC и профиль MIDP поддерживают второй класс. Конфигурация стремится предоставлять интерфейсы для служб системного уровня. Профиль стремится предоставлять стандартные интерфейсы для служб уровня приложений. Конфигурация дает возможность работы профиля, предоставляя необходимые средства и механизмы. Устройства должны иметь некую систему управления приложениями (AMS), чтобы «самозапустить» процесс инициализации приложений J2ME на устройствах. Производитель устройства обычно предоставляет AMS.


В этой главе вы узнали о базовой организации и структуре приложений MIDP. Центром модели программирования MIDP является MID-лет.
Основными компонентами структуры MID-лета являются экземпляр MID-лета, экземпляр Display и одна или более «штучек» Displayable, которые являются компонентами пользовательского интерфейса.
Объекты MID-лета связаны с объектом Display. MID-леты создают элементы Displayable, которые являются компонентами пользовательского интерфейса, и требует, чтобы они отображались на экране устройства. Display управляет экраном устройства и видимостью элементов пользовательского интерфейса.
Абстрактный класс Screen является первым из двух основных типов, которые катего-ризируют все объекты Displayable. Класс Screen является центральной абстракцией дисплея. Класс Form является конкретным подклассом Screen. Только Screen видим в каждый момент жизни MID-лета.
Все MID-леты имеют связанные с ним свойства и атрибуты. Свойства являются стандартными системными свойствами, определенными спецификацией CLDC. Они относятся к платформе и поддерживаются и управляются системой управления приложениями. Атрибуты связаны с MID-летами. Существуют обязательные атрибуты, которые доступны для всех MID-летов, и необязательные атрибуты. Кроме того, существуют определяемые в зависимости от приложения атрибуты, которые могут быть определены автором MID-лета. Атрибуты существуют в файле JAD приложения и управляются программным обеспечением AMS устройства во время выполнения.


Эта глава знакомит вас с полным набором классов компонентов пользовательского интерфейса MIDP. Существует две общие категории компонентов интерфейса пользователя: те, что расположены под Displayable в иерархии, и те, что находятся под иерархией Item.
Класс Screen происходит непосредственно из Displayable и определяет основные абстракции в MIDP. Приложения MIDP в своей основе базируются на экранах.
Form, вид Screen, является только разновидностью экрана, которая может включать другие компоненты. Form может содержать объекты String, изображения, определяемые классом Image, и объекты, чьи типы являются подклассами класса Item.
Стандартное приложение MIDP должно быть способно переходить с экрана на экран. Поэтому экраны должны уметь передавать ссылки в экземпляр объекта экрана, который дисплей должен отображать следующим. Стандартная идиома заключается в предоставлении статического метода, возвращающего такую ссылку в каждом классе, который определяет экран.
В главе 3 представлена полная программная структура и метафоры программирования. В главе 4 описан высокоуровневый API MIDP. Эта глава дополняет все это знакомством с компонентами MIDP, которые реализуют высокоуровневый API.
В следующей главе вы познакомитесь с низкоуровневым API MIDP.


Два класса в пакете javax.microedition. lcdui формируют определение низкоуровневого программного интерфейса приложения в MIDP: класс Graphics и класс Canvas. Низкоуровневый API MIDP дает вашему приложению возможность получать информацию о событиях низкого уровня, которые недоступны для компонентов высокоуровневого программного интерфейса приложения. Объекты Canvas могут получать информацию о событиях нажатия кнопки или движения указателя. Объекты Canvas являются объектами Displayable. По этой причине они все еще могут выполнять обработку команд, как и другие компоненты Displayable.
Чтобы использовать низкоуровневый API, вы должны создать подкласс Canvas. Затем вы должны описать метод paint (Graphics g) в вашем подклассе, для того чтобы создать видимый внешний вид его экземпляров. Метод подкласса paint (Graphics g) определяет этот видимый внешний вид.
Метод paint (Graphics g) рисует внешний вид компонента Canvas с помощью графического контекста, определенного классом Graphics. Класс Graphics поддерживает рисование и заполнение базовых геометрических фигур, таких, как линии, дуги, прямоугольники, текст и так далее. Он также поддерживает рисование в цвете. Другими поддерживаемыми свойствами являются выбор шрифта для рисования текста, отсечение и перенос начала координат Graphics.
Объекты Canvas могут также отображать изображения с помощью функциональных возможностей класса Graphics. Приложения загружают изображения из файлов, которые должны храниться в формате PNG.
Двойная буферизация - это технология, которая повышает эффективность рисования на ресурсно ограниченных устройствах. Приложения используют два графических контекста. Приложение сначала рисует во внеэкранном буфере, а затем копирует содержимое этого буфера в графическую среду, связанную с дисплеем устройства, формируя изображение внешнего вида компонента Canvas. При рисовании изображений двойная буферизация осуществляется автоматически.


Система управления записями (RMS) MIDP поддерживает постоянное хранение записей данных в зависимости от устройства. Класс RecordStore предоставляет API для постоянного хранения данных и извлекает подробную информацию о доступе к определяемым устройством областям хранения.
Хранилища записей определяются по именам, которые состоят максимум из 32 знаков уникода. Хранилища записей могут совместно использоваться MID-летами, находящимися в одном наборе MID-летов.
RMS определяет простую абстракцию базы данных, связанную с записями. Записи хранятся как массив байтов. Хранилище записей не имеет понятий встроенных типов Java.
Вы можете извлекать записи, предоставляя уникальный ID записи. Либо вы можете извлекать записи, получая список записей из RecordStore.
Списки необходимы для поиска записей в хранилище записей. Теоретически фильтры записей предоставляют своего рода механизм запросов. В связи с возможностью составления списков в RecordStore, фильтры записей поддерживают поиск только тех записей, которые соответствуют одному или нескольким критериям. Фильтр записей, класс, который реализует интерфейс RecordFilter, определяет критерии поиска.
Компараторы записей предоставляют возможность сортировки записей, извлекаемых из списка. Компараторы определяют политику сортировки и используются с механизмом составления списка. Реализация RecordComparator определяет семантику сортировки.
Блоки прослушивания записей являются блоками прослушивания, регистрирующимися с определенным хранилищем записей. Они дают возможность уведомления вашей программы об изменениях, вносимых в любую запись, находящуюся в хранилище записей.
Производительность является важной проблемой при доступе к хранилищу записей. Производительность современных реализаций RMS довольно низка. Разработчики приложений должны с осторожностью подходить к использованию RMS, применяя ее только тогда, когда это необходимо. Они должны рассматривать другие альтернативы постоянного хранения данных и сравнивать различные варианты.
Разработчики должны также измерять производительность их реализации RMS при запуске приложений, чтобы убедиться, что производительность приемлема для конечных пользователей. Бывало, что действующие приложения начинали работать слишком медленно из-за использования обновлений хранилища записей. Подтверждено, что перезапись приложений таким образом, чтобы все содержимое хранилища записей было загружено и перемещено, быстрее, чем выполнение обновлений в измененных элементах!


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


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


Инициализация приложений - это процесс поставки программного обеспечения на устройства. Инициализация не ограничивается беспроводными сетями, J2ME или даже приложениями Java. Тем не менее, системы инициализации стали важным компонентом, поддерживающим установку приложений J2ME, особенно в сфере инициализации ОТА приложений MIDP.
Процесс инициализации включает много этапов, среди которых регистрация приложений в системе инициализации и обнаружение, выбор, покупка, загрузка, установка и подтверждение установки программного обеспечения. Цель систем инициализации заключается в облегчении прохождения этих этапов и автоматизации процесса настолько, насколько это возможно для предоставления более совершенных возможностей и безошибочной работы.
Поскольку системы инициализации автоматизируют большую часть процесса инициализации, они хорошо подходят для беспроводных сетей. Они смягчают многие трудности и автоматизируют многие этапы, включенные в инициализацию приложений на устройствах с ограниченными пользовательскими интерфейсами через беспроводные соединения.
Системы инициализации являются комплексными корпоративными приложениями, которые обычно интегрируются в сеть беспроводного транспортировщика. Они предоставляют услуги инициализации для беспроводных подписчиков. Ключевым моментом для разработчиков приложений является подготовка своих приложений MIDP для использования в системах инициализации, поддерживаемых транспортировщиками, у которых их приложения будут зарегистрированы. Понимание сущности интерфейсов, свойств и возможностей системы инициализации, с которой вы будете взаимодействовать, важно. Как разработчик приложения, вы должны быть способны предоставить всю информацию, необходимую системе инициализации, для того чтобы вы могли извлечь из нее максимально возможные преимущества.
Системы инициализации поддерживают многие другие свойства, которые не были обсуждены в данной главе. Многие из этих свойств прозрачны для разработчика приложений, в том смысле, что разработчику не приходится ничего делать для регулировки этих аспектов работы системы инициализации. Многие из них не влияют на приложение. Или они просто обращаются к функциям, которые не зависят от вопросов разработки, конфигурирования или установки приложения.


Среда беспроводного Интернета состоит из мобильных устройств, беспроводной се ти, шлюзов и сетевых комплексов, которые соединяют беспроводную сеть с Интерне том. Сила беспроводного Интернета заключается в том, что он позволяет мобильны\ устройствам получать доступ к Web и другим интернет-приложениям. Среда беспровод ной сети создает абстракции, которые скрывают от приложений различия между беспро водной сетью и Интернетом.
Беспроводные устройства получают доступ ко многий из тех же категорий приложе ний, что и постоянно подсоединенные устройства с проводной связью, такие, как персо нальные компьютеры. Кроме того, определенные приложения, такие, как службы дина мического местоопределения, особенно популярны в области мобильных устройств.
Основанная на Java технология платформы J2ME значительно увеличивает способ ность мобильных устройств использовать преимущества интернет-приложений. Он помогает скрывать от приложений различия в технологии и службах беспроводной CCTI и Интернета.
Однако в реальном мире ограничения и сдерживающие факторы технологической плана требуют, чтобы предназначенное для Интернета основанное на Web программно! обеспечение специально приспосабливалось к беспроводному Интернету, то есть обра щалось к технологиям, используемым для доступа радиоустройств. Но с развитием тех нологии беспроводной Интернет начнет поддерживать абстракции, которые устраня' необходимость наличия специального, основанного на Web программного обеспечения которое поддерживает мобильные устройства отлично от постоянно подсоединенны: устройств, таких, как персональные компьютеры.
Архитектура - это набор понятий и действий, которые поддерживают проектирова ние и описание системы. Методология построения архитектуры - это порядок примене ния архитектурных понятий и действий. Методология построения архитектуры SunTom - это дополнение к процессу Rational Unified Process.
Методологию построения архитектуры дополняет сбор требований. Разработчи! должен согласовать архитектуру с объявленными требованиями системы. Методологи: построения архитектуры SunTone подчеркивает важность определения нефункциональ ных или системных качеств системы и использования их для установления соответстви: системы объявленным требованиям.
Разработчик J2ME должен рассматривать выполнение архитектурного анализа в ка честве первого этапа при проектировании и разработке приложения. Построение архи тектуры может помочь разработчику описать программное обеспечение, которое он соз дает, а также выяснить, каким образом лучше взаимодействовать со службами беспро водного Интернета, если он понимает принципы построения архитектуры систеи беспроводного Интернета.

Загрузка приложения

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

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

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

Более совершенные системы дадут пользователю возможность перезапускать загрузку из точки, на которой произошло прерывание. Это свойство предпочтительно, поскольку оно сокращает продолжительность передачи и уменьшает использование полосы пропускания. Более совершенные системы также поддерживают как небезопасную (HTTP), так и безопасную (HTTPS/SSL) загрузку приложений.

Записи

Запись является массивом байтов типа byte []. RMS не поддерживает описание или форматирование полей записи. Ваше приложение должно определять элементы данных записи и их формат.

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

Жизненный цикл выполнения приложения

Здесь приведен пример этапов, включаемых в выполнение приложения:

Запуск эмулятора. Вы увидите появившееся окно, которое имитирует интерфейс устройства. Если вы используете J2MEWTK версии 1.0.2, вы заметите, что эмулятор просто выполняет приложение HelloWorld, потому что это единственное приложение, присутствующее в наборе. На рисунке 3.1 показано главное окно выполнения этого MID-лета. Однако, если у вас J2MEWTK версии 1.0.3, вы увидите список выбора из всех MID-летов, даже если он у вас один.

Добавьте вторую версию программы, названную HelloWorld2, к набору MID-летов. Вы можете начать этот процесс, нажав на кнопку Settings... (Параметры...) на основном окне инструментария, которое вы видели на рисунке 2.5. Во-первых, напишите исходный код и затем поместите его в директорию проекта srс /. Добавьте его к набору MID-летов, выбрав закладку MIDlets (MID-леты) в окне параметров проекта. На рисунке 3.2 показано окно конфигурации после добавления нового MID-лета.

Рисунок 3.1. Этот MID-лет запускается с помощью используемого по умолчанию цветного телефона, предоставляемого инструментарием. Обратите внимание на название MID-лета

Рисунок 3.2. Добавьте новые MID-леты к набору с помощью закладки MIDIets (MID-леты) в окне Settings (Параметры)

Теперь создайте проект и затем выполните его. В это время вы увидите окно, показанное на рисунке 3.3. Заметьте, что теперь вы видите меню, которое показывает названия обоих MID-летов, находящихся в наборе MID-летов. Поскольку присутствует более одного MID-лета, который можно выполнить, AMS должна вывести меню и позволить вам выбрать тот, который вы хотите запустить. Конечно, эмулятор здесь принимает на себя роль AMS реального устройства.

На реальном устройстве AMS устройства показывает это меню. Например, телефоны Motorola и Siemens используют стандартные списки выбора, которые позволяют вам выбрать сначала AMS, затем набор MID-летов и, наконец, MID-лет. На чужих рынках (в Японии, например) телефоны могут иметь кнопку, помеченную «Web», которая запускает AMS и автоматически запускает Web-браузер, созданный на Java. Перечисленные MID-леты - это те, которые известны AMS.

Когда вы добавляете MID-лет к набору, вы сообщаете инструментарию, что вы хотите, чтобы новый MID-лет был доступен для выполнения. Когда вы создаете MID-лет, инструментарий размещает его файлы .class в файле JAR набора MID-летов и обновляет файлы манифеста и JAD. Этот порядок действий осуществляется в согласии со спецификацией J2ME, которая, как вы помните, требует, чтобы МГО-леты содержались в файле JAR.

Выберите MID-лет HelloWorld и затем нажмите на экранную кнопку Launch (Запуск), чтобы выполнить его. На рисунке 3.4 показано одно окно, которое он создает и показывает.



Рисунок 3.3. Если доступно более одного MID-лета, AMS выводит меню, показывая вам их все. AMS, а не ваше приложение, создает кнопку Launch (Запуск). Вы должны нажать на нее, чтобы запустить выбранный МЮ-лет



Рисунок 3.4. Главное окно этого приложения содержит название и одну строчку текста

Нажмите на красную кнопку с трубкой («hang up» - «отбой») на эмуляторе и вы вернетесь в главное окно AMS. Закрыв окно эмулятора, вы завершите его работу. Теперь вы закончили полный жизненный цикл выполнения приложения. Далее в этой главе вы узнаете больше о деталях жизненного цикла MID-лета и модели состояний MID-лета.

---

---