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