Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Что касается третьей цитаты, то формулировка этого закона Мэрфи говорит сама за себя. Если существует хоть малейшая вероятность сбоя связи, то, как показывает практика, этот сбой обязательно наступит, причем это произойдет неожиданно и в самый неподходящий момент. Это вовсе не означает, что конечным пользователям вашего мобильного приложения остается только смириться с ненадежностью его работы. Тем не менее, отсюда следует, что вы должны приложить все усилия к тому, чтобы предусмотреть в логике работы приложения вероятность возникновения подобных сбоев и по возможности сгладить их отрицательные последствия. Устойчивая связь при ненадежных соединениях вполне возможна. Важно только заранее предполагать вероятность возникновения проблем подобного рода и прибегать к соответствующим защитным мерам.
Написание кодов программ для работы с мобильными сетями
Во всех случаях, представляющих практический интерес, приложения взаимодействуют с ресурсами, находящимися вне самого приложения. Приложения взаимодействуют с операционной системой, локальными ресурсами устройства и сетевыми ресурсами. Чем выше уровень взаимодействия, тем шире возможности приложения, но тем меньше вы можете их контролировать. Усиление взаимодействия с ресурсами вне устройства сопровождается увеличением вероятности возникновения сбоев при подключении к ним. Самое главное, о чем вы всегда должны помнить при написании кода, обеспечивающего взаимодействие через сеть, — это то, что вы не можете полностью контролировать конечный результат попытки установления соединения.
Ниже приводится краткое описание нескольких возможных уровней взаимодействия, перечисленных в порядке усиления степени зависимости мобильного приложения от ресурсов окружения.
■ Замкнутые вычислительные системы. При написании алгоритмов обработки данных, принадлежащих только вашему приложению, его судьба находится полностью в ваших руках. Все, что происходит в такой системе, происходит в результате выполнения кода, который вы знаете до мелочей и всегда можете проверить. Если ваш алгоритм распределяет и освобождает память, то часть контроля в процессе управления памятью он уступает среде выполнения, но вы по- прежнему можете быть достаточно уверены в том, что сохраняете контроль над всей системой. Такая ситуация в значительной мере соответствует замкнутой системе, поведение которой является для вас полностью предсказуемым.
■ Кооперативные вычисления совместно с операционной системой. При написании кода, взаимодействующего со средой выполнения и операционной системой, вы уступаете им несколько больше контроля в обмен на получение расширенных услуг с их стороны. В качестве типичного примера можно привести представление пользовательского интерфейса на современных вычислительных устройствах; пользовательский интерфейс является результатом совместной работы кода приложения и операционной системы. Базовая операционная система и среда выполнения приводят пользовательский интерфейс в действие и посылают вашему приложению события и сообщения, когда происходит нечто, что может представлять для него интерес. При разработке такого класса систем вы уже не располагаете возможностями столь полного контроля, как в случае замкнутых систем; теперь вы имеете дело с кооперативной системой, в которой комфортные условия работы пользователя обеспечиваются совместными усилиями вашего приложения и среды выполнения. Хотя вы и не можете точно сказать, что именно происходит в операционной системе, но вы все еще в состоянии делать достаточно надежные предположения относительно того, как будет вести себя приложение в целом. Например, в то время как ваше приложение уступает контроль над низкоуровневыми деталями функционирования пользовательского интерфейса, можно достаточно уверенно говорить о том, что оно по-прежнему сохраняет полный контроль над всем, что происходит с интерфейсом, и не разделяет этот ресурс ни с какими другими приложениями.
■ Кооперативные вычисления совместно с другими приложениями, выполняющимися на том же устройстве. Ваше мобильное приложение обладает полным контролем над своим пользовательским интерфейсом постольку, поскольку операционная система и среда выполнения устанавливают логические границы между индивидуальными ресурсами различных приложений; мое — это мое, а ваше — это ваше. Когда приложение начинает работать с глобальными ресурсами устройства, например, локальными файлами или базами данных, оно должно учитывать, что не только оно одно может использовать эти ресурсы. Роль честного посредника, распределяющего эти ресурсы, играет операционная система, но она не может гарантировать вашему приложению права исключительного полного доступа к данному ресурсу в любой момент времени. Кроме того, существует вероятность превышения допустимых пределов расхода ресурсов; например, если другие приложения исчерпали все доступное пространство файловой системы, то в вашем приложении должны быть предусмотрены адекватные способы выхода из подобных ситуаций. При работе с разделяемыми ресурсами очень важно предусматривать в коде соответствующие защитные меры, исходя из того непреложного факта, что любая попытка доступа к разделяемому ресурсу может оказаться неудачной. Необходимо также продумать, что будет происходить в тех случаях, когда к ресурсу будут пытаться получить доступ одновременно несколько приложений; одни типы ресурсов разрешают лишь одиночный доступ, другие допускают параллельный доступ, но не гарантируют согласования данных в процессе обновлений, тогда как третьи обеспечивают атомарное выполнение операций чтения и записи данных. Понимание поведения глобальных ресурсов устройства в условиях состязательного доступа к ним играет очень важную роль в обеспечении устойчивой работы приложения.
■ Кооперативные вычисления с интенсивным использованием сети. Если ваше приложение зависит от услуг, предоставляемых по сети, то появляются два дополнительных источника потенциальной неустойчивости. Доступ к сетевым ресурсам может оказаться невозможным из-за неготовности компьютера на другом конце сети к совместной работе. Что-то может нарушиться из-за того, что одно из звеньев сетевой цепочки, соединяющей два компьютера между собой, может повести себя не так, как ожидалось.
Ситуацию дополнительно осложняет тот факт, что сбой сетевых ресурсов может происходить во время сеанса связи; в случае локальных взаимодействий в пределах устройства такое происходит очень редко. Например, хотя наступление сбоя в процессе чтения из локальной файловой системы и возможно, но вероятность этого пренебрежимо мала; жесткий диск может разрушиться, но такое случается крайне редко, и если это произойдет, то у вас возникнут более крупные проблемы, чем просто невозможность считать данные из файла. Вероятность таких сбоев настолько мала, что многие операционные системы регулярно выполняют локальные операции чтения/записи, даже не уведомляя об этом выполняющиеся поверх операционную систему приложения. При чтении файлов через сеть вероятность возникновения сбоев в процессе выполнения этой операции резко возрастает, что часто наблюдается в случае беспроводных сетей и становится еще более заметным, если при чтении файлов мобильным устройством требуется осуществлять сетевой роуминг. Сбои не обязательно происходят постоянно, но случаются настолько часто, что к этому надо быть готовым и заранее предусматривать принятие соответствующих мер.
Ниже приводятся рекомендации по созданию отказоустойчивых сетевых мобильных приложений.
Не допускайте того, чтобы работа приложения всецело зависела от возможности подключения к сети
Точно так же как группа людей, действующих согласованно, может достигнуть гораздо большего, чем один человек, действующий в одиночку, возможности мобильного приложения, взаимодействующего с окружающими его сетями, намного превышают возможности изолированного приложения. Чтобы группа людей в некоторой организации могла успешно справляться с поставленными задачами, должны быть предусмотрены меры, позволяющие корректно разрешать ситуации, соответствующие перебоям в связи между членами группы и перебоям в работе каждого из них. Ни одно звено взаимодействия не должно быть критическим, иначе при его сбое наступит сбой в работе организации в целом. То же самое справедливо и в случае мобильных устройств.
Мобильные устройства значительно выигрывают от взаимодействия с внешним миром, но они никогда не должны всецело зависеть от такого рода взаимодействий. Несмотря на всю очевидность этой истины, ею часто пренебрегают.
Каждая удачная попытка доступа к сетевым ресурсам должна рассматриваться в вашем приложении скорее как счастливая случайность, а не как закономерная необходимость. Для большинства мобильных устройств сеансы взаимодействия с сетью осуществляются "почти по требованию" в том смысле, что хотя пользователь мобильного приложения, как правило, и может перейти в то физическое место, где сеть является доступной, но он не может рассчитывать на то, что устройство сможет оставаться постоянно подключенным к сети. В этом отношении мобильные устройства значительно отличаются от настольных компьютеров, имеющих постоянное кабельное подключение к сети, и лэптопов, подключение которых к сети в условиях стационарной работы не составляет большого труда. Если увидеть человека, склонившегося над клавиатурой своего лэптопа в зале ожидания железнодорожного вокзала, можно не так уж часто, то людей, манипулирующих клавишами своих мобильных телефонов, на том же вокзале встретится довольно много. И хотя количественные оценки этих показателей могут колебаться в зависимости от обстоятельств, различия между обеими ситуациями налицо.
Следствием подхода, в соответствии с которым сетевой доступ необходимо рассматривать лишь как нерегулярный, являются две полезные рекомендации, касающиеся проектирования мобильных приложений:
1. Полезные данные необходимо загружать и кэшировать заблаговременно, когда доступно сетевое соединение. Очень важно определить, какие виды информации будут наиболее полезными для вашего приложения при его работе в автономном режиме, и сделать все для того, чтобы соответствующие данные были заблаговременно загружены и доступны, когда в них возникнет потребность. В то время как при работе с локальными ресурсами устройства целесообразно откладывать их размещение в памяти до тех пор, пока они не потребуются, информацию, хранящуюся вне устройства, целесообразно заранее загружать и накапливать, чтобы подготовиться к работе приложения в автономном режиме. Например, подключение к локальной базе данных устройства может быть отложено до момента, когда в этом возникнет действительная необходимость. В отличие от этого, нужные данные следует загружать из внешней базы данных заблаговременно, когда будет доступно соединение с сетью. В идеальном случае загрузка данных должна выполняться как фоновая задача, которая не блокирует пользовательский интерфейс. Кроме того, предварительная загрузка информации позволяет существенно повысить производительность приложения, особенно в тех ситуациях, когда приложению или пользователю эти данные требуются часто, но иначе их пришлось бы каждый раз загружать по требованию.