Автор неизвестен - Платформа J2Me
}
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. Это следующие три состояния:
— Установка — создан объект соединения, но соединения с исходным сервером еще нет.
— Установлено — соединение с сервером было установлено, параметры запроса были посланы на сервер, и объект соединения ожидает отклика с сервера.
— Отключено — соединение было разорвано. Последующие вызовы методов соединения сбрасывают 10Exception.
