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

 //Для файлов на сервере:

 // В дополнение ко всем вышеперечисленным причинам возможных сбоев

 // при открытии локального файла сбои также возможны

 // из-за проблем доступа к сети, принятой на сервере

 // политики безопасности и так далее

 //------------------------------------------------------------------

 System.IO.StreamReader myStreamReader = System.IO.File.OpenText(filename);

 string inputLine;

 //Организовать построчное чтение файла

 do {

  //--------------------------------------------------------------

  //ВВЕСТИ СТРОКУ:

  //Для локальных файлов:

  // Если файл был успешно открыт, этот вызов

  // никогда не завершится сбоем.

  //

  //Для файлов на сервере:

  // Проблемы доступа к беспроводным сетям, с которыми мы можем

  // столкнуться при попытке доступа к файлу, повышают вероятность

  // сбоя для этого кода и генерации соответствующего исключения

  //--------------------------------------------------------------

  inputLine = myStreamReader.ReadLine();

  //Если не было возвращено значение 'null', то мы

  //не достигли конца файла. Увеличить значение счетчика строк.

  if (inputLine != null) {

   numberLinesInput++;

  }

  //Продолжать выполнение, пока в файле есть данные для чтения

 } while(inputLine != null);

 //----------------------------------------------------------

 //ЗАКРЫТЬ ФАЙЛ:

 //Аналогично предыдущему, вероятность сбоя при выполнении

 //этой операции повышается при доступе к файлу, находящемуся

 //в общей сетевой папке

 //----------------------------------------------------------

 myStreamReader.Close();

 //Возвратить количество строк в файле

 return numberLinesInput;

}

Имитация сбоев связи с целью тестирования отказоустойчивости приложения

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

В листинге 15.2 представлен механизм, позволяющий тестировать устойчивость работы мобильного приложения после устранения последствий сбоев при связи. Листинг содержит условно компилируемый код, который можно активизировать, поместив в начале файла с исходным кодом директиву #define DEBUG_SIMULATE_FAILURES.

Приведенная ниже функция writeDataToSocket() вызывается в процессе нормальной передачи данных. Для тестирования реакции приложения на сбои при обмене данными можно установить переменную g_failureCode = SimulatedFailures.failInNextWriteSocketCode в любой момент в процессе выполнения приложения. Когда впоследствии будет вызываться коммуникационный код, он возбудит исключение при первом вызове, но не при последующих. Это позволяет имитировать при тестировании ситуации, в которых сетевое соединение внезапно обрывается, вызывая сбой при передаче данных, но затем восстанавливается. Подобное использование условной компиляции тестирующего кода является не совсем элегантным, но зато эффективным способом мониторинга выполнения кода при имитации реальных условий возникновения сбоев.

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

//-----------------------------------------------------------------

//Глобальная переменная, которую мы хотим использовать для указания

//необходимости генерации исключений в процессе передачи данных

//-----------------------------------------------------------------

#if DEBUG_SIMULATE_FAILURES

//Переменная для хранения информация о следующем сбое

static SimulatedFailures g_failureCode = SimulatedFailures.noFailurePending;

//Список сбоев, которые мы хотим имитировать

public enum SimulatedFailures {

 noFailurePending, //Отсутствуют текущие сбои, подлежащие обработке

 //Имитируемые сбои:

 failInNextWriteSocketCode,

 failInNextWebServiceCall,

 failInNextFileIODuringFileOpen,

 failInNextFileIODuringFileRead

 //и так далее

}

#endif //DEBUG_SIMULATE_FAILURES

//-----------------------------------------------------

//Функция, которую мы используем для передачи данных...

//-----------------------------------------------------

private void writeDataToSocket(System.Net.Sockets.Socket mySocket, byte[] dataToSend) {

 //------------------------------------------------------------------

 //Этот код следует компилировать лишь при тестировании сетевых сбоев

 //------------------------------------------------------------------

#if DEBUG_SIMULATE_FAILURES

 //Если это сбой, который мы хотим тестировать, генерировать исключение

 if (g_failureCode == SimulatedFailures.failInNextWriteSocketCode) {

  //Сбросить этот сбой, чтобы он не возник

  //при следующем вызове этой функции

  g_failureCode = SimulatedFailures.noFailurePending;

  throw new Exception("Test communications failure: " + g_failureCode.ToString());

 }

#endif

 //Передать данные обычным образом...

 mySocket.Send(dataToSend);

} //конец функции

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

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

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

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