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

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

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

Резюме 

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

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

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

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

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

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