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

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

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

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

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

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

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

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

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

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

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