Текст книги "Программирование мобильных устройств на платформе .NET Compact Framework"

Автор книги: Иво Салмре

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

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

"Болтливость" в мобильных сетях обходится весьма недешево

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

НА ЗАМЕТКУ

При использовании Web-служб справедлив тезис, в соответствии с которым лучше передавать двоичные данные в результате выполнения второго запроса, чем пытаться сразу же передавать большой поток XML-данных. Поскольку объем двоичных данных при преобразовании их к формату XML значительно возрастает, это приводит к увеличению длительности их передачи. При длительных временах передачи возрастает вероятность сбоев. Улучшенная модель предполагает выполнение одного вызова Web-службы для передачи всех данных, которые могут быть эффективно переданы в виде XML, и ряда последующих вызовов для передачи таких двоичных файлов, как файлы изображений. В листинге 15.11 представлен код, позволяющий загрузить файл с Web-сервера и сохранить его на устройстве. Если необходимо передать содержимое нескольких двоичных файлов, имеет смысл поэкспериментировать с объединением всех двоичных данных в один сжатый файл; такой объединенный файл может быть передан в виде двоичных данных и распакован на другом конце канала связи.

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

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

//–

//Создать и обработать заказ

//–

//0. Установить связь

int sessionID = someWebService.LogOn(userCredentials);

//1. Вызвать Web-службу и создать новый заказ

int orderID = someWebService.CreateNewOrder(sessionID, userInfo, productInfo);

//2. Вызвать Web-службу и передать информацию о платеже

someWebService.ConfirmPayment(sessionID, orderID, paymentInfo);

//3. Вызвать Web-службу и передать информацию о доставке

someWebService.ConfirmShipping(sessionID, orderID, shippingAddress);

//4. Вызвать Web-службу и завершить оформление заказа

someWebService.FinalizeOrder(sessionID, orderID);

Листинг 15.10. Группирование запросов в одном вызове Web-службы

//–

//Создать и обработать заказ посредством группового запроса,

//включающего:

// 0. Начало связи

// 1. Создание нового заказа

// 2. Подтверждение платежа

// 3. Подтверждение доставки

// 4. Завершение оформления заказа

//–

//Сделать все за один раз

someWebService.BatchCreateOrder(userCredentials, userInfo, paymentInfo, shippingAddress);

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

Листинг 15.11. Код для загрузки файла с Web-сервера

//–

//Осуществляет синхронную загрузку файла с Web-сервера

//и сохраняет его в локальной файловой системе

// [in] httpWhereFrom: URL-адрес файла

// (например, "http://someserver/somefile.jpg")

// [in] filenameWhereTo: Место, куда необходимо записать файл

// (например, "\localfile.jpg")

//–

public void downloadFileToLocalStore(string httpWhereFrom, string filenameWhereTo) {

 System.IO.FileStream myFileStream = null;

 System.IO.Stream myHTTPResponseStream = null;

 System.Net.WebRequest myWebRequest = null;

 System.Net.WebResponse myWebResponse = null;

 //Если файл, который мы хотим записать, уже существует, удалить его

 if (System.IO.File.Exists(filenameWhereTo) == true) {

  System.IO.File.Delete(filenameWhereTo);

 }

 try {

  //Создать Web-запрос

  myWebRequest = System.Net.HttpWebRequest.Create(httpWhereFrom);

  //Получить ответ

  myWebResponse = myWebRequest.GetResponse();

  //Получить поток для ответа

  myHTTPResponseStream = myWebResponse.GetResponseStream();

  //Создать локальный файл, в который необходимо направить поток ответа

  myFileStream = System.IO.File.OpenWrite(filenameWhereTo);

  //Этот размер буфера является настраиваемым

  const int buffer_length = 4000;

  byte [] byteBuffer = new byte[buffer_length];

  int bytesIn;

  //Считать файл и направить поток данных в локальный файл

  do {

   //Считать данные

   bytesIn = myHTTPResponseStream.Read(byteBuffer, 0, buffer_length);

   //Записать данные

   if (bytesIn != 0) {

    myFileStream.Write(byteBuffer, 0, bytesIn);

   }

  } while (bytesIn != 0);

 } catch (Exception myException) //Сбой при загрузке!

 {

  //Что-то случилось. Освободить ресурс

  attemptCleanup_ThrowNoExceptions(myFileStream, myHTTPResponseStream, myWebResponse);

  //Теперь, когда ресурс освобожден, повторно сгенерируем исключение,

  //чтобы сообщить приложению о том, что произошел сбой!

  throw myException;

 }

 //Загрузка прошла успешно!

 //Закрыть все ресурсы

 try {

  //Стандартная процедура закрытия ресурсов

  myFileStream.Close();

  myFileStream = null;

  myHTTPResponseStream.Close();

  myHTTPResponseStream = null;

  myWebResponse.Close();

  myWebResponse = null;

 } catch (Exception myException) //Сбой в процессе закрытия ресурса!

 {

  //Что-то случилось. Освободить ресурс

  attemptCleanup_ThrowNoExceptions(myFileStream, myHTTPResponseStream, myWebResponse);

  //Теперь, когда ресурс освобожден, повторно сгенерируем исключение,

  //чтобы сообщить приложению о том, что произошел сбой!

  throw myException;

 }

 //Успешное выполнение!

}

//–

//Пытается закрыть и освободить все объекты

//Перехватывает любое вырабатываемое исключение.

//–

void attemptCleanup_ThrowNoExceptions(

 System.IO.FileStream myFileStream,

 System.IO.Stream myHTTPResponseStream,

 System.Net.WebResponse myWebResponse) {

 if (myFileStream != null) {

  try {

   myFileStream.Close();

  } catch {} //He выполнять никаких действий.

 }

 if (myHTTPResponseStream != null) {

  try {

   myHTTPResponseStream.Close();

  } catch {} //He выполнять никаких действий.

 }

 if (myWebResponse != null) {

  try {

   myWebResponse.Close();

  } catch {} //He выполнять никаких действий.

 }

} //конец функции

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

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

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

■ Может потребоваться настройка прокси-серверов вручную. Приложения, выполняющиеся в корпоративных сетях, часто получают доступ в Internet через прокси-сервер, который устанавливается между интрасетью и WWW (World Wide Web). В то время как прокси-соединения для настольных компьютеров и лэптопов часто настраиваются автоматически, в случае мобильных устройств это не всегда так. Если у вас возникают проблемы при вызове Web-служб из мобильного приложения, то обычно имеет смысл проверить, может ли получить доступ к тому же Web-серверу Web-браузер, установленный на том же устройстве. Если доступ к серверу с помощью браузера получить не удается, то, вероятно, вам потребуется вручную настроить параметры прокси-сервера на данном устройстве.

■ Может потребоваться настройка параметров GRPS-соединений и других мобильных сетевых соединений вручную. Во многих сетях мобильной связи используется понятие точек доступа, аналогичных прокси-серверам в корпоративных сетях, через которые осуществляется доступ к сети Internet. В сетях GSM 2.5G такие соединения известны под названием GRPS-соединений, и их настройка вручную может понадобиться для каждой локальной сети мобильной связи, к которой устройство подключается посредством функции роуминга. Может потребоваться на стройка имен пользователей, паролей и DNS-адресов. Как и в случае прокси– серверов, целесообразно убедиться в работоспособности соединения, проверив, что установленный на устройстве Web-браузер способен получить доступ в Internet. Если Web-браузер работает нормально, то, вероятнее всего, проблем с подключением вашего мобильного приложения к сети Internet, у вас не возникнет.

■ Различные сети мобильной телефонной связи могут вести себя необычным образом. Технология доступа в Internet через сети мобильной телефонной связи еще не отработана окончательно. В прежние времена (два-три года тому назад) телефоны поставлялись со встроенным оборудованием, обеспечивающим речевую связь, а также ограниченными по своим возможностям функциями передачи данных; операторы сетей мобильной телефонной связи могли легко тестировать качество оказания этих услуг, поскольку им было известно, какого типа запросы могут передаваться по их сетям. В наши дни развитие многоцелевого телефонного оборудования приобрело взрывной характер. Несмотря на устойчивые тенденции развития инфраструктуры сетей мобильной телефонной связи в направлении надежной поддержки смартфонов, играющих роль платформы для обычных приложений, это преобразование еще нельзя считать завершенным. В силу этого в серверной инфраструктуре еще могут присутствовать некоторые жестко запрограммированные элементы, ориентированные на работу со строго определенными клиентскими приложениями и протоколами. Например, несколько лет назад мы столкнулись с одной мобильной сетью, которая всегда отправляла HTTP-ответы в сжатом виде, и по этой причине они не могли быть прочитаны клиентскими приложениями, ожидающими данные в виде простого текста. В результате этого ответы Web-служб воспринимались приложением так, словно информация была перепутана и не имела ничего общего с XML-данными, получение которых ожидалось. Причина этого состояла в том, что Internet-браузеру на клиентских телефонах было известно о том, что данные будут поступать в сжатом виде, и он мог обеспечить распаковку данных, но эта возможность не была сделана доступной для других приложений. Потребовалась разработка временного способа преодоления этих трудностей, позволяющего обычным клиентским приложениям передавать модифицированные заголовки HTTP– запросов, которые в явном виде требовали отправки ответов в несжатой форме. Есть все основания полагать, что в настоящее время такие проблемы вряд ли могут возникать, однако некоторые "блохи" подобного рода могут все еще оставаться невыявленными. Поэтому в целях диагностики возникающих проблем рекомендуется применять многоэтапный подход. Если при попытках доступа к Web-службе возникают проблемы, я советую придерживаться следующей последовательности отладочных шагов: 1) попытайтесь вызвать Web-службу из приложения, развернутого на настольном компьютере; если сделать это не удается, то проблема не является специфической для устройства; 2) попытайтесь просмотреть несколько Web-страниц, используя клиентское устройство; если сделать это удается, то соединение с Internet работает нормально; 3) попытайтесь загрузить файлы с интересующего вас сервера, используя для этого объект System.Net.HTTPWebRequest платформы NET Compact Framework, как показано в листинге 15.11; если это срабатывает и содержимое загруженного файла правильно интерпретируется, то данные поступают в ваше приложение надлежащим образом; 4) попытайтесь вызвать Web-службу из приложения, развернутого на настольном компьютере, с отключением cookie-файлов на стороне клиента: 5) построчно просмотрите автоматически сгенерированный в вашем приложении клиентский код Web-службы для точной локализации ошибок. Выполнение отладки с целью выявления причин возникновения проблем подобного рода всегда доставляет много хлопот; применение унифицированного пошагового подхода приводит к наилучшим результатам.

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

Резюме

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

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

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

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

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

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

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

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

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

Web-службы предлагают полезный способ организации взаимодействия приложений с Internet и интрасетями. Путем использования данных в формате XML, обычно передаваемых посредством протоколов HTTP или HTTPS, Web-службы могут предоставить вашему мобильному приложению возможность воспользоваться всеми преимуществами существующей инфраструктуры Web для удовлетворения коммуникационных потребностей. Важно, однако, понимать, что платой за предоставляемые Web– службами полезные абстракции являются значительные накладные расходы. XML-формат порождает текстовые файлы большого размера и не способен обеспечить эффективный обмен данными через сеть в случае крупных XML-сообщений. Кроме того, для определения IP-адресов может требоваться использование серверов доменных имен, что служит источником дополнительных накладных расходов.

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

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

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