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

Для синхронизации этой информации устройства используют специальную службу, которая называется ActiveSync. Механизм ActiveSync периодически устанавливает через мобильную сеть соединение с Internet для подключения пользователя к серверу Exchange Server и последующей синхронизации данных. Процесс синхронизации состоит из двух операций:

1. Загрузка всех пакетных обновлений. Синхронизируются все локальные изменения, связанные с расписанием встреч, электронной почтой и списком контактов.

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

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

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

Отправка и получение SMS-сообщений с помощью мобильного телефона

SMS-сообщения — это короткие текстовые сообщения, пересылаемые между мобильными телефонами. SMS — многообещающая технология, используя которую пользователи мобильных телефонов могут легко обмениваться между собой несколькими строками текста. Устанавливая фиксированную плату за пересылку одного сообщения, операторы сетей мобильной связи получают огромные прибыли за счет предоставления лишь узкой полосы пропускания; SMS-сообщения с побитовой оплатой гораздо прибыльнее речевой связи! Таким образом, приложения для обработки SMS — это приложения-приманки, и вряд ли можно сомневаться в том, что изготовители мобильных телефонов и операторы сетей мобильной связи постарались отладить эту технологию идеальным образом.

Обмен SMS-сообщениями обладает одним большим достоинством и одним большим недостатком:

1. Преимущества SMS: разделение передачи и приема сообщений. Если SMS-сообщение пересылается с одного мобильного телефона на другой, то телефон, принимающий сообщение, во время его передачи не обязан быть подключенным к сети. Если вы совершаете перелет через Атлантику, и в этот момент кто-то отправляет вам SMS-сообщение, инфраструктура сети мобильной связи поместит сообщение в очередь на своих серверах и доставит его вам, когда вы приземлитесь и включите свои мобильный телефон. Точно так же будут развиваться события и в том случае, если принимающий телефон находится вне зоны досягаемости поскольку его владелец в данный момент находится в метро, лифте или катается на лыжах на той части склона, которая скрыта от сотового передатчика. По указанным причинам данный механизм прекрасно подходит для отправки кратких текстовых сообщений наподобие: "Встретимся в Лонгхорн Грилл в 17:00. Иво". Отправитель и получатель могут общаться между собой краткими предложениями, не соединяясь друг с другом.

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

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

Не допускайте того, чтобы поток пользовательского интерфейса блокировался на длительное время

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

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

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

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

■ Коль скоро мы не забываем о необходимости осуществления коммуникаций в асинхронном режиме и предусматриваем это в проекте приложения, то организовать впоследствии обмен данными в асинхронном режиме не составит никакого труда. Это — заблуждение. Несомненно, если вы не забываете о том, что, в конечном счете, коммуникационные операции должны будут выполняться асинхронно, то это облегчит вам переориентирование написанных вами функций синхронной связи на асинхронный режим выполнения в будущем, но одного этого еще мало. Истина состоит в том, что, как бы вы ни старались это предотвратить, в код, использующий синхронные процедуры, будут "намертво" встроены синхронные зависимости. Человек просто не в состоянии уследить за всеми неявными допущениями, которые вплетаются в логику приложения, и устранить возникающие из-за этого проблемы на более поздних этапах разработки приложения вам будет очень трудно.