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

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

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

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

Информируйте пользователя о ходе выполнения процесса синхронизации данных

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

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

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

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

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

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

Разумеется, информация должна подаваться пользователю в приемлемом для него виде; сообщение наподобие: "Передача Patient312.xml через порт 8080 на сервер XYZ", скорее всего, большинству пользователей ни о чем не скажет, тогда как будучи отображенным в виде "Загрузка данных: диагностические данные пациента Боба Смита", оно станет намного более содержательным.

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

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

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

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

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

По существу, вы должны решить для себя следующее: 1) требуется ли вашему приложению безопасная передача данных, 2) с какими сетями будет взаимодействовать приложение, и 3) как будет реализован тот или иной уровень безопасности.

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

Передача данных и выбор сети

Для передачи информации на устройство или с устройства мобильное приложение может использовать множество различных коммуникационных механизмов. Важно понимать, что какого-то одного наилучшего механизма не существует. У каждого из коммуникационных механизмов имеются собственные достоинства, недостатки и наиболее подходящие сценарии использования. Некоторые механизмы ориентированы на соединение равноправных узлов (peer-to-peer connection), другие – на нательные сети (body-area network), Internet или локальные сети. Анализируя потребности определенного вида связи, полезно составить список технологий, пригодных для использования в нужном вам решении, и набросать схему того, каким образом могло бы работать решение, основанное на той или иной технологии. Почти всегда вам придется выбирать из нескольких возможных вариантов, и принятие решения о том, какой из них будет для вас наилучшим, должно явиться результатом как творческого подхода, так и самого скрупулезного анализа. Некоторые наиболее распространенные коммуникационные механизмы описаны ниже.

Wi-Fi: локальные сети

Протокол Wi-Fi, известный также под названием протокола 802.11 (со всеми его разновидностями: 802.11.a, b, g и так далее), по существу является протоколом беспроводной связи на коротких дистанциях, основанным на протоколе Ethernet; этот коммуникационный механизм предназначен для использования в локальных вычислительных сетях. Имеется много причин, по которым стоит рекомендовать Wi-Fi к применению: он популярен, концептуально прост в использовании, поддерживает относительно широкую полосу пропускания (во многих случаях 100 Мбит/с и выше), прост в настройке, а стоимость передачи информации посредством Wi-Fi, как правило, невысока. Базовая станция Wi-Fi, соединенная с сетью, обычно обеспечивает беспроводной доступ в радиусе примерно несколько сотен футов, если она не оказывается закрытой, например, зданиями (рис. 15.1).

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

С точки зрения программирования связь посредством Wi-Fi аналогична связи через кабель Ethernet. Этот вариант является великолепным универсальным решением проблемы под названием "Мне необходимо сетевое подключение". Вместе с тем, желая использовать Wi-Fi, вы должны провести следующий анализ:

■ Имеется ли у вас Wi-Fi? Не все мобильные устройства поддерживают Wi-Fi. Для большинства современных лэптопов встроенная поддержка Wi-Fi предусматривается. тогда как для большинства мобильных телефонов – нет. Некоторые мобильные устройства обеспечивают подключение карт Wi-Fi, причем обычно это делается посредством карт Compact Flash или Secure Digital. Можно ожидать, что в будущем протокол Wi-Fi будет поддерживаться большим количеством устройств, но это не будет встречаться сплошь и рядом.

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

■ Безопасность. Отправлять пакеты через Wi-Fi-соединения – это все равно что кричать с крыши здания; вас может услышать кто угодно. На самом деле, все не так уж и плохо, поскольку Wi-Fi-сети предлагают различные уровни встроенной поддержки шифрования, начиная от секретных ключей, совместно используемых базовой станцией Wi-Fi и устройствами, и заканчивая средствами защиты информации на основе сертификатов и открытых ключей шифрования (чрезвычайно надежная защита). Даже при передаче данных по нешифруемым открытым Wi-Fi-каналам можно без труда использовать протоколы SSL (Secure Socket Layer) или HTTPS (Secure HTTP) для шифрования передаваемых данных на уровне приложения. Если вам надо передавать важные данные, их обязательно следует шифровать.

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

Несколько слов по поводу WiMax

Протокол WiMax, известный также под названием протоколов 802.16 и 802.20, – это развивающийся стандарт, который должен вобрать в себя все лучшее из того, что предлагают сети Wi-Fi и сети мобильной телефонной связи, предоставить возможности широкополосной передачи пакетов, свойственные сетям Wi-Fi, на большие расстояния и, в перспективе, обеспечить возможность роуминга между точками доступа (access points). В то время как протокол 802.11 (Wi-Fi) предназначен для беспроводных локальных сетей, новые стандарты предназначены для введения беспроводных региональных сетей, охватывающие значительно большие расстояния по сравнению с Wi-Fi. Как и в случае любого нового стандарта, для внедрения WiMax несомненно потребуется определенное время, однако этот протокол является весьма многообещающим в отношении скорости и стоимости передачи данных. Операторы традиционных стационарных сетей, операторы мобильных сетей и производители связного оборудования заинтересованы в развитии этого направления, и о том, какие изменения ожидают коммуникационный ландшафт, в настоящее время можно только догадываться. Автор данной книги не может дать иных прогнозов, кроме того, что, по его мнению, развитие этого процесса будет весьма интересным, и он растянется на ближайшие несколько лет. Как и в случае всех остальных механизмов беспроводной связи, которые мы здесь обсуждаем, работа с протоколом WiMax потребует от вашего приложения готовности работать в условиях нестабильного доступа к сети и неоднородных сетей, включая сети Wi-Fi, WiMax, 2.5 G, 3G и другие сетевые технологии.

Более подробную информацию об этих развивающихся стандартах вы сможете найти на Web-сайте:

http://grouper.ieee.org/groups/802/16/ и

http://grouper.ieee.org/groups/802/20/

Bluetooth: персональные сети

Bluetooth – это коммуникационный механизм персональных вычислительных сетей (Personal Area Network – PAN), предназначенный для объединения различных устройств, непосредственно окружающих пользователя, в единую сеть. PDA-устройства, лэптопы, мобильные телефоны, принтеры и, возможно, даже торговые автоматы и автономные центры интерактивной информации – все они могут выступать в роли целевых объектов сетей Bluetooth. Назначение стандарта Bluetooth состоит в том, чтобы позволить различным устройствам, оказавшимся вблизи друг друга, вступать друг с другом в различные отношения, зависящие от конкретной ситуации. Как видно на рис. 15.2, существует два вида вычислительных устройств, которые может объединять Bluetooth: персональные устройства, переносимые индивидуумом, и внешние устройства, с которыми может вступать в контакт владелец устройства, располагающего возможностями Bluetooth.

Часто неправильно считают, что стандарт Bluetooth подразумевает только "что-то одно", то есть представляет собой исключительно коммуникационный протокол и ничто другое, хотя на самом деле это не так. Несмотря на то что Bluetooth построен поверх базового сетевого стека, наиболее существенным аспектом Bluetooth являются построенные поверх него "профили". Сам по себе Bluetooth – это коммуникационный механизм, но почти вся наиболее интересная работа выполняется на уровне профилей Bluetooth. С практической точки зрения это означает, что если только два различных устройства не поддерживают одни и те же профили Bluetooth, то они мало что смогут сообщить друг другу. Например, Bluetooth-принтеру, который поддерживает профиль Bluetooth "Basic Printing Profile", может быть известно о существовании в той же комнате удаленного элемента управления "A/V Remote Control Profile", но эти два устройства не смогут общаться на понятном им обоим языке, если только они не разделяют общий набор профилей.

Рис. 15.2. Схематическое изображение персональной сети

Список поддерживаемых профилей вы можете найти на Web-сайте организации Bluetooth www.bluetooth.org.

На практике необходимость совпадения профилей обоих устройств не налагает столь сильных ограничений, как могло бы показаться на первый взгляд, по следующим двум причинам: 1) профили распространенных типов устройств, которые от возможности обмениваться между собой информацией могли бы только выиграть, обычно перекрываются друг с другом, и 2) несмотря на существование множества различных профилей, на практике лишь немногие из них доминируют в тех областях, которые представляют интерес с точки зрения использования мобильных устройств. Существуют распространенные профили для синхронизации информации, с которой работают PDA-устройства, а также профили для использования мобильного телефона в качестве сетевого концентратора.

Что немаловажно, существует также профиль, позволяющий использовать Bluetooth-устройство в качестве последовательного порта RS-232; название этого профиля соответствует его назначению – "Serial Port Profile". Благодаря этому такие устройства Bluetooth воспринимаются как СОМ-порты и могут поддерживать старые протоколы последовательной передачи данных. Многие устаревшие источники информации поддерживают традиционную связь через последовательный порт RS-232, и на протяжении ряда лет последовательные протоколы получили широкое распространение.

Обычным средством подключения этих устройств к компьютеру служил кабель RS-232. В качестве показательного примера, имеющего отношения к мобильным средствам связи, можно привести приемные устройства глобальной системы навигации и определения положения (Global Positioning System – GPS). В этой системе для передачи информации о глобальном местоположении от датчиков положения на вычислительное устройство в течение многих лет использовался последовательный протокол NMEA (National Marine Electronics Association – Национальная ассоциация судовой электроники). Теперь связь с этими устройствами является беспроводной, и вместо того чтобы изобретать совершенно новые протоколы, для многих последующих поколений этих устройств было решено по-прежнему использовать проверенные протоколы последовательной передачи данных, но осуществлять это посредством беспроводных соединений Bluetooth.

Программирование с использованием Bluetooth следует той же схеме, которая применяется при работе с перечисленными выше профилями. Разработчик, применяющий Bluetooth, может работать либо с низкоуровневыми API-интерфейсами Bluetooth, – возможно, посредством сокетов, если устройство поддерживает отображение данных между сокетами и Bluetooth, – либо с API-интерфейсами, специфичными для профилей. Например, если доступ к устройству Bluetooth осуществляется посредством профиля Serial Port Profile, то разработчик может вообще забыть о Bluetooth и просто работать с API-интерфейсами СОМ-порта. Выбор остается за вами, однако, как ранее уже отмечалось в данной главе, работать с более абстрактными высокоуровневыми API-интерфейсами почти всегда проще. Может даже оказаться, что использовать API– интерфейсы последовательного порта вам будет гораздо проще, чем углубляться во все детали обмена данными посредством протокола Bluetooth. При малейшей возможности упрощайте себе задачу и используйте более абстрактные API-интерфейсы.

Если вы программируете с использованием .NET Compact Framework версии 1.1, то для доступа к функциональным возможностям Bluetooth вам надо будет использовать собственный код (native code), если только независимыми производителями программного обеспечения уже не предусмотрены специальные встроенные интерфейсные оболочки, которые вы сможете использовать в управляемом коде (managed code). В NET Compact Framework версии 1.1 встроенная поддержка для работы как с Bluetooth, так и с последовательным СОМ-портом отсутствует. Вместе с тем, по адресу www.gotdotnet вы найдете образец кода, демонстрирующий, каким образом можно использовать вызовы собственного кода для решения таких низкоуровневых коммуникационных задач, как доступ к последовательному порту.

НА ЗАМЕТКУ

Поскольку стандарт Bluetooth специально разрабатывался для мобильных устройств, он, как правило, обеспечивает неплохие характеристики энергосбережения, но при необходимости вы сможете найти и другие, более специализированные коммуникационные механизмы. В дополнение к таким технологиям персональных сетей, как Bluetooth, существуют также такие технологии нательных сетей, характеризуемые низким энергопотреблением, как Zig-Bee (IEEE 802.15). Сетевые протоколы нательных сетей пригодны для работы с встроенными датчиками и другими видами устройств, для которых необходим низкий уровень энергопотребления.