■ Поместите все процедуры доступа к сети в блоки try/catch (то есть организуйте структурную обработку исключений). Исходите из того, что время от времени будет выполняться каждый из этих catch-блоков, и имитируйте эти ситуации в процессе проектирования и тестирования приложения, чтобы проверить, правильно ли реагируют на возникновение исключений предусмотренные для них обработчики. Целесообразно предусмотреть, чтобы исключения возбуждались при любых периодических нарушениях связи; точно так же, целесообразно перехватывать подобные исключения и обрабатывать их так, чтобы это облегчало работу пользователя.
Доступ к сетевым ресурсам намного расширяет возможности мобильных приложений, но при этом неизбежно привносит в ваше приложение элементы, контролировать которые вы не в состоянии. Очень важно, чтобы мобильное приложение могло надежно вести себя в тех весьма реальных ситуациях, когда попытка получения доступа к внешним ресурсам оказывается неудачной или может быть завершена лишь в течение недопустимо длительного времени. Если вы предусмотрите корректную обработку ситуаций подобного рода, то ваше приложение от этого значительно выиграет, и будет не только отлично работать, но и лучше восприниматься пользователями. Пользователи будут благодарны вам или, по крайней мере, не будут честить ваше имя при появлении сообщения наподобие "соединение с сетью отсутствует".
Как и в случае локальных данных устройства, при работе с сетевыми ресурсами также используются несколько уровней абстракции. Так, в .NET Compact Framework предлагаются следующие уровни API-интерфейсов для работы с сетевыми данными:
■ Сокеты, использующие потоки.
■ Запросы/ответы HTTP.
■ Механизм SOAP.
Каждый из этих уровней абстракции, перечисленных в порядке их повышения, последовательно предлагает все более удобную и надежно протестированную инфраструктуру. Как и в случае локального обмена данными на устройствах, вы всегда должны выбирать наивысший из приемлемых для вас уровней абстракции и переходить к более низким уровням лишь тогда, когда убеждены, что более высокие уровни не в состоянии удовлетворить ваши запросы. Использование более низкоуровневых программных моделей означает более непосредственный контроль над тем, что происходит, и обеспечивает максимальную гибкость, но это достается за счет увеличения сложности кода, уменьшения возможностей переноса приложения на другие платформы и необходимости выполнения более тщательного тестирования. Вы также должны знать о том, что даже нижайшие уровни абстракции не предоставят вам возможности полного контроля; ваше приложение всегда должно будет каким-то образом справляться со сбоями в сети, а на низких уровнях абстракции это часто сделать сложнее. Должны же иметься веские причины того, что во всех случаях, кроме самых специальных низкоуровневых задач, разработчики вместо языка ассемблера используют языки более высокого уровня, и точно так же должны рассуждать и вы, выбирая коммуникационную модель для своего приложения. Выбору более высоких уровней абстракции следует отдавать предпочтение почти во всех случаях.
При необходимости вернитесь к шагам 0, 1, 2 и 3
Современная разработка является итеративным процессом. Это особенно справедливо в отношении разработки приложений для мобильных устройств. Исходя из своей квалификации и опыта, вы принимаете первоначальные решения, которые кажутся вам наилучшими, и при необходимости впоследствии пересматриваете их. Наличие опыта проектирования приложений для мобильных устройств поможет вам принять лучшие решения, но никогда не сделает их идеальными. Всегда вкрадется какая-нибудь непредвиденная проблема, которая вынудит вас заново пересмотреть свой проект и внести в него небольшие уточнения или, как это часто случается, радикальные изменения. Значительное место в оставшейся части книги отводится тому, чтобы научить вас с самого начала принимать наилучшие решения и одновременно привить необходимые технические навыки, которые позволят оставить открытыми двери для пересмотра проекта, если это потребуется.
Хороший проект мобильного программного обеспечения должен в обязательном порядке предусматривать обнаружение проблем, появления которых вам не избежать, уже на самых ранних стадиях разработки и ориентировать на создание кода, обладающего достаточно модульной и гибкой структурой, чтобы при необходимости в него можно было внести изменения, не рискуя безнадежно запутаться.