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

Если все это кажется вам немного запутанным, то только потому, что так оно и есть. Сегодняшняя глобальная сеть мобильной телефонной связи являет собой сплошную "кашу"! Более того, можно ожидать, что на протяжении еще ряда лет она будет представлять собой пеструю смесь различных систем и поколений технологий. Причины этого в основном носят финансовый характер; получение от государства разрешения на использование диапазона радиочастот, а также развертывание и эксплуатация сетей мобильной связи обходятся в огромные денежные суммы. Это означает, что развертывание новых сетей — дорогостоящее предприятие, осуществляемое, как правило, путем использования фрагментарного похода, основанного на принципе первоочередного завоевания "наиболее лакомых" секторов рынка. Обновление сетей также является дорогостоящим и нередко требует замены устаревших базовых станций и телефонных трубок. Переход к новому поколению технологий означает необходимость развертывания параллельных перекрывающихся сетей, что позволяет операторам связи поддерживать существующую клиентуру, приносящую деньги "в клювике", и одновременно внедрять новые услуги. Дополнительные сложности в эту экосистему вносит тот факт, многими операторами мобильной связи Wi-Fi рассматривается одновременно и как угроза благополучию, и как счастливая возможность вырваться вперед; владельцы различных каналов связи используют различные подходы к тому, чтобы обеспечить существующим клиентам возможность доступа к "горячим точкам Wi-Fi" при сохранении обычных механизмов оплаты. Ниже приведены некоторые рекомендации, касающиеся выбора той сети мобильной связи из числа доступных, которая будет больше всего соответствовать потребностям вашего мобильного приложения:

1. Абстрагируйте сетевую технологию. К счастью, являясь разработчиком мобильного приложения, вы можете абстрагироваться от большинства низкоуровневых деталей мобильных коммуникационных технологий. Соединение с Web-cepвeром через сокет остается одним и тем же в сетях 2.5G и 3G, и сокету совершенно безразлично, какая технология положена в основу радиосвязи — CDMA, GSM или еще что-нибудь другое. Важный урок состоит в том, чтобы использовать настолько высокий уровень технологической абстракции, насколько это возможно. В качестве высокого уровня абстракции неплохо использовать запросы и ответы HTTP; сокеты находятся одним уровнем ниже, но остаются нейтральными по отношению к выбору сети. Чем дальше вы отходите от интерфейса радиосвязи устройства, тем более переносимым будет ваше приложение. Нет никаких причин для того, чтобы надлежащим образом спроектированное приложение не могло выполняться в неизменном виде и в сетях GSM, и в сетях CDMA.

2. Предусматривайте возможность работы на пониженных скоростях передачи данных. Хотя 3G-ceти могут обеспечивать очень высокую пропускную способность, можно предположить, что в обозримом будущем ваши целевые мобильные устройства будут, вероятно, работать в смешанном окружении, состоящем из сетей 2.5G и более поздних. Для сетей 2.5G достаточно разумным является предположение о том, что скорость передачи данных будет составлять примерно 20 Кбит/с; 20 Кбит/с = 2,5 Кбайт/с. Вполне вероятно, что при работе с улучшенными сетями ваше приложение сможет обмениваться данными с более высокой скоростью, но не менее вероятно, что в силу загруженности сети скорость передачи данных будет еще меньше, приближаясь к значениям, характерным для модемов, работающих через аналоговые телефонные линии. В этом же направлении действует еще один фактор — временные задержки; можно почти не сомневаться, что канал передачи данных в мобильной сети 2.5G будет характеризоваться большими задержками, чем кабельное соединение с Internet, о чем важно не забывать, если вы рассчитываете на немедленный (менее 1 секунды) отклик. Если ваше мобильное приложение должно использовать сети мобильной телефонной связи, то очень важно обеспечить его надежную работоспособность при пониженных скоростях передачи данных и увеличенных временах задержки. При разработке проекта целесообразно руководствоваться правилом, суть которого заключается в следующем: если объем загружаемых данных превышает 20 Кбайт, то имеет смысл отслеживать длительность загрузки и в случае превышения определенного порогового значения прекращать эту операцию. Разумеется, фактическое значение критической длительности загрузки и длительность интервала ожидания зависят от природы приложения и характеристик используемых сетей с учетом интересов конечного пользователя. Конечный пользователь не должен ждать поступления данных в течение неопределенного времени, если их загрузка осуществляется фоновым потоком; измеряйте степень выполнения загрузки и соответствующим образом устанавливайте критические значения параметров.

3. Хорошо изучите действующие системы оплаты связи. Хотя в некоторых старых (в основном. 2G) системах передачи данных взимаемая плата зависит от длительности соединения, оплата услуг по предоставлению данных в большинстве сетей мобильной связи основывается на количестве переданных битов. Ставки оплаты для отечественных сетей и сетей с услугами роуминга могут значительно отличаться. Все эти факторы будут оказывать самое непосредственное влияние на те расходы, которые понесет пользователь вашего приложения, оплачивая услуги связи. Относительно того, какие тарифы оплаты связи можно считать приемлемыми, а какие — неприемлемыми, трудно дать какие-либо определенные рекомендации; это будет определяться природой вашего приложения. Выбирая технологию мобильной связи, целесообразно измерить характерные объемы загружаемых и выгружаемых данных и оценить соответствующие затраты применительно к различным коммуникационным моделям.

Все большее количество мобильных телефонов с развитой функциональностью, поступающих на рынок, поддерживают Wi-Fi, причем эти возможности либо являются встроенными, либо делаются доступными посредством подключения съемных карт; двумя наиболее популярными форматами таких карт являются карты Compact Flash и Secure Digital Wi-Fi. В свою очередь, в лэптопах и специализированных мобильных вычислительных устройствах, имеющих встроенную поддержку Wi-Fi, съемные карты часто предусматриваются для обеспечения дополнительной возможности доступа к сетям мобильной телефонной связи.

Если учесть, что введение дополнительных возможностей означает увеличение цены и энергопотребления, то какой смысл в том, чтобы мобильные устройства могли осуществлять связь как через сети мобильной телефонной связи, так и через сети Wi-Fi? Ответ таков: "Все зависит от приложения", что является другой формулировкой ответа: "Все зависит от вашего проекта".

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

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

В качестве примера рассмотрим действия эксперта по дорожно-транспортным происшествиям. Предположим, что в функции эксперта входит выезд на место происшествия и составление отчета, к которому в качестве вещественных доказательств прилагаются цифровые фотографии. Очень важно, чтобы сведения о дорожном происшествии поступали как можно быстрее; все его участники должны заполнить свои страховые заявки, в необходимых случаях должна быть оказана медицинская помощь, машины должны быть отбуксированы в разные места и так далее. Указанные причины и обуславливают важность немедленного составления отчета о происшествии. В долговременной перспективе важны также различного рода вещественные доказательства, и в этом отношении подробные фотографии, сделанные на месте происшествия, могут оказать неоценимую помощь. Встроенное в мобильный телефон, который эксперт всегда имеет при себе, специализированное приложение может значительно повысить эффективность этого процесса. По прибытии на место происшествия эксперт начинает готовить новый отчет об инциденте, используя мобильное устройство. Запустив мобильное приложение, он может ввести важную информацию, касающуюся дорожного происшествия, например, автомобильные номера машин-участниц инцидента, номера водительских прав, контактную информацию о пассажирах, и результаты первоначальной оценки происшедшего. Как только эта информация подготовлена, ее можно немедленно поместить на сервер, используя мобильное телефонное соединение. Поскольку эта информация является в основном текстовой, а ее объем сравнительно невелик, то процесс выгрузки данных займет мало времени, так что мобильная телефонная связь вполне подходит для этих целей. После того как эта информация введена в систему, можно сразу же приступать к растаскиванию автомобилей, поэтому в скорейшем завершении первого этапа сбора и отправки информации об инциденте заинтересованы все стороны. Теперь наш эксперт может приступить к работе, требующей большей тщательности: сделать подробные фотографии, записать в звуковые файлы показания очевидцев происшествия и собрать дополнительную информацию. Часть информации может быть немедленно выгружена на сервер, но основной ее объем можно кэшировать на устройстве, что позволит сэкономить и время, и деньги. Позже, когда эксперт вернется в офис или окажется в том месте, где предоставляется доступ к сети Wi-Fi, он сможет выгрузить на сервер цифровые фотографии, записанные с голоса показания и другие данные, занимающие большой объем.