НА ЗАМЕТКУ  
   Существует множество технологий, которые могут быть использованы при разработке Web-приложений, ориентированных на мобильные устройства. Кроме элементов управления технологии Microsoft ASP.NET для мобильных устройств, существуют и другие Web-технологии, поддерживающие разработку мобильных приложений. Для этих технологий существуют свои стратегии создания мобильных Web-приложений. Если вы уже привыкли работать с какой-то определенной Web-технологией, то вполне вероятно, что доступно и соответствующее расширение этой технологии, ориентированное на мобильные устройства.

Собственный код

Инструменты разработки на С++ для мобильных устройств

   Во время написания данной книги компания Microsoft предлагала свободно распространяемый инструментальный набор средств для разработчиков устройств на языках C/C++ под названием eVC++. eVC++ — это аббревиатура от Embedded Visual С++. Этот продукт, который можно бесплатно загрузить с Web-сайта Microsoft, позволяет разработчикам создавать собственный код на языках C/C++ для устройств, работающих под управлением операционных систем Windows СЕ, Pocket PC и Microsoft Windows Mobile 2003 Software for Smartphone (ради краткости при дальнейших ссылках на последний из названных программных продуктов я буду использовать его сокращенное название — Microsoft Smartphone). В основу этой среды разработки была положена среда Visual Studio 6.0 С++, являющаяся предшественницей Visual Studio .NET. Согласно планам Microsoft последующие версии Visual Studio .NET (начиная с выпуска "Whidbey" в 2005 году) будут обеспечивать поддержку разработки собственных кодов C/C++ для устройств, в результате произойдет слияние обеих указанных сред в одну среду.
   При разработке приложений для Windows ХР Embedded можно использовать ту же среду Visual Studio .NET, что и для настольных компьютеров и серверов.
   Созданием сред для разработки приложений в собственных кодах занимаются и другие компании, в том числе MetroWorks и WindRiver. Существует также множество инструментальных средств командной строки, часть которых является бесплатной, тогда как за остальные надо платить. Типичные продукты поставляются в виде отдельных пакетов, предназначенных для различных целевых сред. Так, существуют отдельные среды разработки для Windows СЕ, Symbian Operating System, а также для LINUX, FreeBSD, Palm OS и так далее.
   Инструменты разработки приложений для мобильных устройств характеризуются различными уровнями поддержки стандартов ANSI C/C++. Если вы хотите обеспечить переносимость кода или библиотек, придерживайтесь следующих рекомендаций: 
   • Тщательно выясняйте уровень поддержки стандартов, который обеспечивается используемыми вами компиляторами, обращая особое внимание на такие тонкие вещи, как структурная обработка исключений. Различные компиляторы предоставляют различные уровни поддержки таких, например, средств, как обработка исключений, а возможно, и таких вещей, как операции с вещественными числами или стандартная битовая ширина целых чисел. 
   • Обзаведитесь хорошим руководством по программированию, содержащим подробные описания всех средств компилятора и библиотек программ, которые вы будете использовать в своих приложениях. Убедитесь в том, что эти средства и библиотеки поддерживаются всеми компиляторами, которые вы планируете использовать для различных целевых процессоров или операционных систем. 
   • Рассмотрите возможность использования "наименьшего общего знаменателя" для всей совокупности возможных средств, например, ограничьтесь применением только языка С (в смысле — откажитесь от С++) или же используйте лишь какое-то отдельное простое подмножество средств С++. Благодаря этому вы сможете быть уверены в том, что присутствие и поддержка выбранных вами языковых средств будут в равной степени обеспечиваться широким кругом компиляторов. 
   • Как можно чаще и начиная уже с ранних стадий разработки, тестируйте приложение на каждом компиляторе/платформе, для работы с которыми оно запланировано. Качество кода, обеспечиваемое различными компиляторами C/C++, не обязательно одинаково, и некоторые их них могут содержать ошибки, которые могут быть выявлены только в процессе выполнения или отладки программы. В целом, компиляторы C/C++ для мобильных устройств используются далеко не так широко, как компиляторы для настольных компьютеров и серверов, работающих на процессорах семейства х86. Как следствие, число разработчиков, рискующих испытать свои силы на поприще генерации кодов для них, не так уж и велико. Как показала практика, чем менее широко используется какой-либо программный продукт, тем больше скрытых ошибок в нем содержится и тем больше ограничений ему свойственно. Не утруждая себя частым тестированием кодов на протяжении всего периода разработки с использованием для этого всей совокупности компиляторов и платформ, для выполнения на которых предназначено приложение, вы заведомо готовите для себя неприятные сюрпризы в будущем! 
   • Тщательно ознакомьтесь с описанными в соответствующих лицензионных соглашениях ограничениями, касающимися использования применяемых вами компиляторов библиотек и инструментальных средств. Если вы создаете приложение, предназначенное для коммерческого использования, изучите лицензионные соглашения всех без исключения компиляторов, библиотек исходных кодов и библиотек времени выполнения, а также средств компоновки, которые вами используются. Каким бы утомительным ни было чтение этих документов, лучше быть хорошо осведомленным об этих ограничениях уже с самого начала, чем переделывать всю работу или переходить на другой компилятор на более поздних стадиях производственного цикла. Смена компилятора может казаться легкой, но повозиться вам придется немало, и вдобавок это отнимет много времени. Все сказанное выше справедливо в отношении любого программного обеспечения разработчика, но в отношении средств разработки приложений для мобильных устройств это справедливо вдвойне из-за огромного разнообразия специализированных инструментальных средств, сопровождаемых лицензионными соглашениями самых различных видов, включая EULA (end-user license agreement — лицензионное соглашение с конечным пользователем), ограничения, касающиеся лицензионных платежей, ограничения, касающиеся защиты прав на интеллектуальную собственность, например, GPL (general public license — общедоступная лицензия), LGPL (lesser general public license — общедоступная лицензия с ограничениями), FreeBSD и тому подобное.
   Caveat emptor^[1]; Пусть программист будет бдителен! Никто никого не запугивает; это только призыв к тому, чтобы, делая свой выбор, вы поступали осмотрительно. 
   Разработка приложений для мобильных устройств с использованием собственных кодов не является чем-то необычным и вполне может соответствовать вашим потребностям, но решение об этом вы должны принимать осознанно, понимая причины, побуждающие вас к такому выбору. Если при создании мобильного приложения вы решаете прибегнуть к написанию собственных кодов, убедитесь в том, что для этого имеются веские причины, и не пожалейте времени на то, чтобы заранее продумать, какие возможности компиляторов C/C++ вам могут для этого понадобиться и какие усилия вам придется приложить для преодоления возникающих при этом проблем разработки и отладки. Разрабатывать мобильные приложения на основе собственного кода намного сложнее, чем для настольных компьютеров или серверов. Чтобы добиться в этом успеха, вы должны быть вооружены ясным пониманием целей и знаниями инструментальных средств, которые собираетесь для этого использовать.

Основной исполнительный механизм

Плавающая запятая: что собой представляет число?

   Исполнительный механизм .NET Compact Framework и библиотеки времени выполнения имеют встроенную поддержку операций с плавающей запятой. Это следует особо подчеркнуть, так как не каждая среда выполнения мобильных устройств может похвастаться этим. Понимание этого играет очень важную роль, если до того, как приступить к работе с мобильными устройствами, вы занимались разработкой программ для настольных компьютеров или серверов.
   Например, для Java J2ME CLDC (Common Limited Device Configuration) версии 1.0 поддержка операций с плавающей запятой не требуется, чего нельзя сказать о версии J2ME CLDC 1.1. Java MIDP 2.0 (Mobile Information Device Profile) требует только поддержки CLDC 1.0. Если вы ориентируетесь на мобильные устройства со средой выполнения J2ME, выясните, какую версию CLDC поддерживает эта среда.
   Большинство многофункциональных мобильных приложений в той или иной форме требуют выполнения вычислений с десятичными числами. Хотя и существуют способы имитации некоторых операций с плавающей запятой путем выполнения целочисленных операций с фиксированной запятой, они могут делать вычисления громоздкими и не обеспечивают достаточной гибкости, необходимой для удовлетворения повышенных запросов.
   Определяя требования к среде выполнения своего мобильного приложения, обратите особое внимание на наличие поддержки математических функций, причем не только тех, которые предназначены для выполнения операций с плавающей точкой, но и тех, которые используются для обработки величин, представляющих валюту, дату и время. Нелишне также удостовериться в том, что обеспечивается поддержка и таких более сложных библиотечных функций, как тригонометрические и экспоненциальные функции. В .NET Compact Framework все эти средства поддерживаются.
   Преимуществом сред выполнения, в которых поддержка операций с плавающей запятой отсутствует, является то, что они занимают меньше места в памяти и способны выполняться в более простом окружении. Их большим недостатком является ограниченность функциональных возможностей, предлагаемых разработчикам приложений. Тщательно проанализируйте свои потребности и выберите среду выполнения и целевые устройства, которые обладают всеми необходимыми для вас показателями функциональности и гибкости. 

Библиотеки классов

Переносимость

Более пристальный взгляд на мобильные Web-браузеры

   Интересным примером многофункциональных клиентских приложений, выполняющихся на мобильных устройствах, являются мобильные Web-браузеры. Целесообразно сравнить между собой мобильные Web-браузеры и их настольные аналоги, чтобы выяснить, в чем состоит суть различий между ними. Благодаря этому мы получим в свое распоряжение неплохие метафоры для анализа того, как будут вести себя приложения для настольных компьютеров при их переносе на мобильные устройства и какие изменения необходимо в них внести, чтобы работать с ними в мобильных условиях было действительно удобно
   В настоящее время Internet-браузеры предлагаются многими мобильными устройствами, однако по способу их использования браузеры этого типа отличаются от их аналогов, устанавливаемых на настольных компьютерах.
   Несмотря на то что в их основе лежит одна и та же технология (оба типа браузеров обеспечивают визуализацию HTML-разметки при отображении документов), способы взаимодействия с ними пользователей заметно различаются между собой. Браузеры настольных компьютеров предназначены для доступа к как можно более широкому кругу Web-сайтов, а также для загрузки и отображения сложных документов. Задача же мобильных Internet-браузеров состоит в том, чтобы обеспечивать доступ к Web-сайтам, ориентированным на мобильные устройства, и загрузку документов с одновременным извлечением из них лишь наиболее существенной информации. Типичные мобильные браузеры работают одним из двух способов они либо 1) загружают содержимое, предназначенное специально для мобильных устройств, которое отличается упрощенными схемами компоновки страниц, меньшими размерами фотографий и изображений и приспособлено для просмотра в небольших окнах, либо 2) загружают обычное Web- содержимое, но пытаются вычленить из него и отобразить для пользователя лишь наиболее существенную его часть. 

Создание оптимальных условий для работы в Web на мобильных устройствах требует координации взаимодействия устройства с сервером

   Следует отметить, что извлечение лишь наиболее существенной части содержимого типичных HTML-страниц с сохранением возможности приемлемого представления документов на мобильных устройствах является сложной проблемой. Учитывая огромное разнообразие возможных схем компоновки страниц с помощью HTML, а также тот факт, что наряду с основной информацией страницы заполняются второстепенным содержимым и рекламой, очень трудно определить, какая именно информация является наиболее существенной, и разместить эту информацию на небольшом экране мобильного устройства. Вместо того чтобы возлагать всю нагрузку на устройство, очень часто можно добиться лучших результатов, перекладывая решение большинства проблем на сервер. Часто такие популярные Web-сайты, как MSNBC или ВВС, предлагают отдельные версии содержимого, рассчитанные на мобильные устройства. Для решения этой задачи на двух упомянутых сайтах используются различные подходы, каждый из которых заслуживает внимания:
   • http://www.msnbc.com/news/MobileChannel/mmc.asp. Этот Web-сайт автоматически подстраивает свой ответ под возможности браузера, выполняющего запрос. Результаты, получаемые при доступе к Web-сайту с обычного браузера настольного компьютера и браузера мобильного устройства, значительно различаются между собой.
   • http://news.bbc.co.uk/text_only.stm. На этом сайте ВВС для представления Web-содержимого используются изображения с низким разрешением и ограниченное форматирование, что обеспечивает возможность эффективного просмотра содержимого на мобильных устройствах.
   Задача отображения HTML-содержимого на мобильных устройствах может быть решена гораздо эффективнее, если сервер принимает участие в решении проблем, испытываемых устройством, и предоставляет упрощенное представление данных. Преодоление проблем, с которыми приходится сталкиваться приложениям на мобильных устройствах, за счет создания дополнительных специализированных служб на сервере — неплохая идея не только для Web-приложений, но и вообще для всех приложений, которым требуется доступ к данным, находящимся на сервере. Если для упрощения проблем разработки приложений, с которыми приходится сталкиваться в случае мобильных устройств, некоторую часть работы можно переложить на сервер, то в большинстве случаев этим надо обязательно воспользоваться.
   Кроме того, в отличие от адресной строки браузеров настольных компьютеров, которая всегда на виду и используется довольно часто, адресная строка браузеров мобильных устройств во многих случаях остается скрытой, и ею пользуются гораздо реже. Из-за небольших размеров экрана и ограниченных возможностей механизма ввода, а также вследствие того, что на ввод URL-адресов уходит больше времени, а сама адресная строка занимает драгоценное экранное пространство, в случае мобильных устройств она менее употребительна. Добавьте к этому также тот факт, что значительную часть обычного Web-содержимого воспроизвести на мобильных устройствах приемлемым образом не удается. Все эти факторы заметно сужают возможности устройств в отношении полностью свободной навигации по адресам Web-сайтов.
   Ничто из вышесказанного не должно создавать у вас впечатления, будто разработка Web-приложений для мобильных устройств и бесполезна, и неинтересна — это абсолютно не так! Существует немало отличных мобильных Web-приложений, предлагающих пользователю множество удобных возможностей при доступе к Web-ресурсам. В настоящее время, когда появились такие технологии разработки Web-приложений на стороне сервера, как ASP.NET Mobile Controls. Web-разработчикам стало легче создавать "мобильные представления" уже существующего Web-содержимого. Средства Web-просмотра для мобильных приложений всегда будут "приложениями-приманками", однако их эксклюзивность отличается от той, которая свойственна их аналогам для настольных компьютеров.

В чем состоит разница между ADO и ADO.NET?

   На протяжении последних 10-15 лет компания Microsoft предложила ряд различных библиотек объектов для доступа к данным, каждая из которых улучшала предшествовавшую модель. До появления ориентированной на использование управляемого кода технологии ADO NET применялась технология ADO название которой является аббревиатурой от ActiveX Data Objects (объекты данных ActiveX), и которая предназначалась главным образом для того, чтобы предоставить возможность обращаться к информации, хранящейся в базах данных, разработчикам на Visual Basic. В настоящее время все предыдущие модели (вместе с их многочисленными загадочными трехбуквенными акронимами наподобие DAO, RDO, ADO и номерами различных версий — прошу прощения, если я что-то перепутал!) вытеснены ADO NET.
   В то время как предыдущими технологиями доступа к данным, такими как ADO, предлагались объекты RowSet, каждый из которых представлял одиночную таблицу данных с курсором, указывающим на текущую строку, в ADO.NET предлагаются объекты DataSet, представляющие наборы связанных таблиц, хранящихся в памяти вместе с межтабличными ссылками на объекты.
   В ADO.NET данные представляются не в виде изолированной таблицы с курсором, обеспечивающим перемещение между строками, а в виде хранящейся в памяти схемы таблиц, навигация между которыми осуществляется с использованием объектно-ориентированных механизмов. В ADO.NET не существует понятия курсора текущей строки, поскольку данные явным образом отделены от любых подключений к базе данных, для которых мог бы потребоваться курсор. Для связывания объектов ADO.NET DataSet с внутренними источниками данных в ADO.NET используются объекты DataReader. Объекты DataReader предоставляют лишь возможность однонаправленного считывания данных из источника данных. Эти объекты используются внутренним образом для заполнения данными объектов ADO.NET DataSet.

НА ЗАМЕТКУ

   Данная тема великолепно исследуется и обсуждается в книге The Mythical Man Month (Мифический человеко-месяц) Фредерика Брукса (Frederick Brooks). Каждый, кто хочет получить солидную подготовку в области общей методологии разработки программного обеспечения, должен обязательно прочесть эту книгу.

Две ситуации, благоприятные с точки зрения применения методологии разбивки на компоненты

   Двумя областями, в которых использование компонентов предлагает эффективные способы решения сложных задач и значительно упрощает работу с этими технологиями, являются XML и криптография.
   Синтаксический анализ XML-выражений является примером непростой технической задачи, для решения которой очень хорошо подходит методология повторного использования компонентов. Число разработчиков, самостоятельно создающих собственные XML-анализаторы для своих приложений, весьма невелико лишь по той простой причине, что спроектировать и реализовать высокопроизводительный XML-анализатор, отличающийся высокой степенью надежности и универсальностью, очень нелегко. Если бы все те, кому необходимо использовать в своих приложениях XML, должны были создавать собственные XML-анализаторы, то последние страдали бы всевозможными мелкими огрехами и неувязками. Это нанесло бы непоправимый ущерб самой возможности организации взаимодействия между различными платформами, лежащей в основе XML. Исключая случаи чисто академических упражнений в проектировании алгоритмов (а XML предоставляет для этого действительно благодатную почву), написание собственного XML-анализатора было бы глупой затеей; вам никогда не удастся выполнить эту работу так же хорошо, как ее могут сделать те люди, перед которыми поставлена единственная задача: написать и протестировать такой анализатор. Вместо того чтобы заставлять каждого разработчика программного обеспечения тратить время на написание собственных специальных программ синтаксического разбора XML-выражений, методология проектирования, рекомендует применять готовые универсальные компоненты, прошедшие тщательное тестирование. В результате разработок, выполненных на чрезвычайно строгом уровне проектирования алгоритмов и тестирования, были созданы несколько XML-анализаторов, основанных как на собственном, так и на управляемом коде. Эти несколько компонентов повторно используются многими разработчиками приложений, желающими применять XML. В этом и состоит суть методологического подхода к решению изначально трудной задачи создания надежного XML-анализатора.
   Другим замечательным примером применения методологии повторного использования компонентов, где она оказывается более эффективной по сравнению с пользовательскими вариантами реализации, может служить криптография. Проектирование криптографических алгоритмов является своего рода сложным искусством. Вступая в определенное противоречие с ярко выраженным аспектом своей специфичности, криптографические функциональные средства с каждым днем приобретают все большее значение для разработчиков, создающих самые рядовые приложения. Давно доказано — лучшим способом создания незащищенного приложения является написание собственных криптографических алгоритмов. Если только вашей целью не является проведение исследований в области криптографии, то вы должны знать, что устоявшаяся инженерная практика программирования категорически рекомендует не заниматься созданием собственных криптографических систем. Проектирование, реализация и сопровождение криптографической системы, отвечающей требованиям надежности, живучести и быстродействия, — работа не из легких. Было бы крайне неразумно и чревато многими отрицательными последствиями, если бы все, кто нуждается в функциональных средствах криптографии, самостоятельно создавали криптографические системы для своих приложений. Итак, здесь мы также сталкиваемся с неизбежными проблемами проектирования алгоритма, решение которых более совершенные инструменты облегчить для нас не в состоянии. Но вместо того, чтобы поднимать руки вверх, признавая свое поражение: "Да, это действительно трудная задача, и с этим ничего не поделаешь", следует обратиться к методологии программных разработок, основанной на разбиении сложных алгоритмических задач общего характера на отдельные компоненты, а также к методологии, в соответствии с которой все участники рабочей группы должны следовать согласованному подходу, основанному на использовании компонентов. 
   Дополнительным преимуществом методологии, предполагающей использование готовых, берущихся "прямо с полки" компонент для решения проблем подобного рода, является снижение затрат на сопровождение программных продуктов. При обнаружении каких-либо изъянов в компонентах (а таковые всегда найдутся) они корректируются централизованным образом, а не по отдельности для каждого из многочисленных разрозненных вариантов реализации.

Эволюция подходов к разработке программного обеспечения на протяжении ряда лет

   Каждый успешный этап развития вычислительных средств характеризовался своими специфическими проблемами и соответствующими методологиями, позволяющими добиваться успеха. Эти методологии базировались и продолжают базироваться как на самых современных из имеющихся инструментальных средствах разработки, так и на специфических видах разрабатываемых решений.
   На первых порах вычислительные ресурсы, например, память, регистры или тактовая частота процессоров были весьма ограниченными, и поэтому требование написания как можно более компактных и эффективных алгоритмов носило императивный характер. Эти цели являются актуальными и на сегодняшний день, но теперь они уравновешиваются долговременными преимуществами, которые сулит написание легких в обслуживании кодов, допускающих возможность их повторного использования. На данном этапе основной целью является не просто написание как можно более эффективного кода, а написание наиболее эффективного кода, отличающегося ясностью, надежностью и легкостью сопровождения. 
   Пакетная обработка
   В эпоху пакетных вычислений (то есть во времена, предшествовавшие появлению диалогового программного обеспечения) безраздельно царствовали алгоритмы. Тогда было возможно, и это имело действительно существенное значение, указать как входные, так и ожидаемые выходные данные системы еще до написания кода. В силу того, что модель применения программных продуктов описывалась схемой ввод→обработка→вывод, много времени тратилось на разработку центрального алгоритма, а главной задача проектирования заключалась в максимальной экономии дискового пространства и памяти. У этой модели есть свои достоинства, и сегодня она по-прежнему является идеалом, к которому следует стремиться при разработке отдельных процедур, предназначенных для обработки информации в пакетном режиме (например, при проектировании алгоритмов сортировки). Такой подход целесообразно применять при проектировании отдельных функций, но не сложных систем, обеспечивающих интерактивное взаимодействие с пользователем. Этот период можно назвать эрой "блок-схем". 
   Серверная обработка без сохранения состояний
   При построении надежных серверных приложений, отвечающих на запросы, роль Святого Грааля играет "отсутствие состояния". Ваш код получает запрос, обрабатывает его, а затем возвращает результат, не нуждаясь в сохранении состояния на протяжении периода времени между двумя последовательными запросами. Все это очень напоминает пакетную обработку, поскольку в данном случае также используется модель, описываемая схемой ввод→обработка→вывод. Разумеется, современные сложные Web- приложения (например, система покупательских тележек на Web-сайте Amazon) должны сохранять свое состояние в течение промежутков времени между двумя последовательными запросами, а этого легче всего достигнуть осуществляя управление состояниями на основе существенно централизованного механизма инкапсуляции, обеспечивающего выполнение как можно большего объема кода без сохранения состояния 
   Интерактивные вычисления, управляемые событиями
   Управляемые событиями вычисления (event-driven computing) представляют вычислительную модель, в которой приложение находится в состоянии долговременного обмена информацией с конечным пользователем. Выполнение кода осуществляется в ответ на действия и запросы конечного пользователя; задача приложения заключается в обеспечении соответствующей реакции на то, что делает пользователь. В отличие от пакетных приложений интерактивные (диалоговые) приложения не имеют определенного фиксированного периода завершения и продолжают обрабатывать новые события, запускаемые пользователем, до тех пор, пока пользователь не решит прервать рабочий сеанс. Эту модель программирования обычно называют "управляемой событиями", поскольку в результате действий пользователя вырабатываются дискретные события (например, события щелчка мыши, выбора элемента списка или закрытия окна), на которые должно реагировать разрабатываемое приложение. При построении удачного интерактивного приложения, управляемого событиями, очень многое зависит от того, насколько тщательно продумана модель управления состояниями.

Оптимальный подбор предоставляемых средств определяет все остальное

Высокая производительность — основная предпосылка создания удобных условий работы для пользователя

Пример разработки пользовательского интерфейса с учетом обеспечения высокой производительности

   Как ActiveSync, так и Internet Explorer для Pocket PC и интеллектуальных телефонов предлагают элементы пользовательского интерфейса, назначение которых состоит в том, чтобы информировать пользователей о состоянии выполнения инициированных ими асинхронных запросов. Благодаря этому пользовательский интерфейс сохраняет свою интерактивность, и у пользователя не возникает чувства потери контакта с приложением.
   Для синхронизации календарной информации с сервером Exchange Server приложению ActiveSync может требоваться телефонный звонок или иная форма операции соединения, на выполнение которой уходит длительное время. В процессе выполнения такой операции пользовательский интерфейс устройства отображает пояснительный текст, информирующий пользователя о текущем состоянии попытки создания соединения. Таким текстом может быть "Набор номера...", "Соединение с сервером", "Синхронизация расписания", "Загружено 12 из 20" и тому подобное. Такие несложные уведомляющие элементы пользовательского интерфейса не дают никакого выигрыша в производительности, но зато сохраняют в пользователе уверенность в том, что полезная для него работа продолжает выполняться, и удерживают его от попыток отмены запроса из-за того, что ответ на него затягивается.
   Браузер Pocket Internet Explorer также может нуждаться в соединении с источниками данных, поиске IP-адресов URL и выполнении других задач в процессе загрузки Web-страниц. При выполнении подобных затяжных задач заголовок окна браузера обновляется постоянно отображая текст, информирующий пользователя о состоянии соединения. Кроме того, при загрузке Web-содержимого отображается анимация флага Windows. Оба указанных действия информируют пользователя о том, что выполнение операции продолжается.
   В обоих случаях пользовательский интерфейс сохраняет свою интерактивность, а пользователям предоставляется возможность отменить операцию, если они того захотят. Наличие возможности в любой момент прекратить выполнение операции поддерживает в пользователе чувство уверенности в сохранении контроля над ситуацией, а непрерывное получение им информации о состоянии выполнения операции уменьшает вероятность того, что он ее отменит. Конечно, было бы лучше, если бы такие операции выполнялись мгновенно, но в тех случаях, когда это невозможно, следующее наилучшее решение заключается в поддержании интерактивности пользовательского интерфейса и непрерывном информировании пользователя о развитии ситуации.

Удачный пользовательский интерфейс — довольные пользователи

Удачная модель данных означает высокую производительность и гибкость дизайна

Работа с локальными ресурсами устройства

Формат данных

Различные уровни абстракции программной модели

Выбор формата хранения данных и программной модели

Работа с внешними по отношению к устройству ресурсами

Производительность и надежность

Уровни абстракции программной модели

Листинг 5.2. Неявное изменение состояний приложения (неудачный подход)

Листинг 5.3. Явное изменение состояний приложения (удачный подход)

Постойте-ка! Но ведь речь идет о мобильных приложениях. Разве размер их кода не должен быть меньше размера кода настольных приложений?

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

Стиль программирования: использование операторов goto и полных путей доступа в пространствах имен

   Следует дать некоторые пояснения относительно двух аспектов стиля программирования, принятого во всех примерах кодов, приводимых в данной книге. 
   Использование операторов goto
   Вопрос о том, следует ли считать использование операторов goto в программах допустимым или же его необходимо рассматривать как признак плохого стиля программирования, является в определенной мере дискуссионным. Применимость операторов goto выступает предметом споров постольку, поскольку осуществляемая с их помощью передача управления противоречит принципам, лежащим в основе использования операторов условного перехода (if/then) и операторов циклов.
   Лично я принадлежу к лагерю тех, кто считает использование операторов goto в программах вполне допустимым при условии выполнения следующих требований:
   1) Им соответствует передача управления только в прямом направлении.
   2) Они способствуют повышению удобочитаемости интересующих нас участков кода. Применение операторов goto может считаться непозволительным лишь в том случае, если это затрудняет понимание логики передачи управления в выполняющейся программе. Примером неудачного использования операторов goto может служить передача управления в различных направлениях, поскольку результатом этого является создание сложной системы замысловатых переходов внутри функций и трудности в отслеживании их логики; несомненно, любой из нас возражал бы против подобного использования этого оператора. 
   Использование полных путей доступа в пространствах имен
   Возможны два способа указания типов переменных в программах:
   1) В теле программы можно указывать полный путь доступа. Например, оператор System.Threading.Thread newThread; объявляет переменную newThread типа System.Threading.Thread. Достоинством таких подробных объявлений является простота их применения.
   2) В начале файла с текстом программы можно задавать использование определенного пространства имен, применяя для этого ключевое слово using языка C# или ключевое слово Imports языка Visual Basic .NET. Например, если в начале файла с программой на языке C# содержится оператор using SystemThreading;, то переменная System.Threading.Thread может быть объявлена просто как Thread newThread; без указания ее полного имени.
   С функциональной точки зрения оба способа являются эквивалентными. Разработчикам, знакомым с использованием пространств имен, последний способ может предоставлять дополнительные удобства в работе. Разработчикам же, которые только осваивают это понятие, легче будет использовать первый из этих способов, поскольку он точно описывает логическую принадлежность каждого класса или типа. Учитывая тот факт, что не все читатели данной книги могут быть одинаково хорошо знакомы с пространствами имен .NET, я решил везде использовать более подробный синтаксис.
   На заметку! Прежде чем вы сможете использовать те или иные классы и типы в своей программе, вы должны указать, к каким сборкам (assembly), они относятся. Очень важно, чтобы вы понимали, что ключевые слова using и Imports являются всего лишь удобным синтаксическим средством и не отменяют необходимости включения ссылки на сборку. Чтобы компилятору стали известны типы, содержащиеся в сборке, вы должны явно включить соответствующую ссылку в свою программу. В Visual Studio .NET список сборок можно просмотреть с помощью элемента управления TreeView в окне проводника решений Solution Explorer. Как правило, предварительно сконфигурированные часто используемые ссылки автоматически включаются во вновь создаваемые проекты.

Листинг 5.4. Код программы нахождения простых чисел, предназначенный для выполнения фоновым потоком 

Листинг 5.5. Тестовая программа, которая вызывает на выполнение приведенный выше код фонового потока, осуществляющего поиск простого числа

НА ЗАМЕТКУ

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

Поиск информации в Web с помощью мобильных устройств имеет свои особенности

   Мне не раз приходилось слышать оценку, согласно которой в течение всего лишь нескольких лет число мобильных устройств, имеющих доступ к Internet, превысит аналогичное число настольных компьютеров. Возможно, так оно и будет, но было бы неправильно считать, что способы использования Internet в обоих случаях будут одинаковыми. Стоит поговорить о том, почему это так.
   Ранее мы уже указывали на то, что в мобильных Web-бpayзepax адресная строка часто по умолчанию является скрытой. В случае настольных компьютеров такое поведение можно было бы считать упущением, но в случае мобильных устройств критерии оценки другие. На то есть две причины: 1) в случае мобильных устройств быстро вводить длинные URL-адреса обычно бывает непросто, и если имена Web-сайтов приходится задавать с указанием всех входящих в них символов то и редактор T9 не в состоянии ускорить эту процедуру, и 2) в силу требований к размерам изображений и компоновке экрана большая часть Web-содержимого плохо приспособлена для отображения на мобильных устройствах.
   По этой причине работа в Web с помощью мобильных устройств осуществляется с использованием списка наиболее часто посещаемых мобильных Web-сайтов, причем приходится проверять, чтобы ссылки, которые могут встречаться на этих стартовых страницах, также указывали на полезное содержимое, способное нормально отображаться на экране мобильного устройства.
   Именно поэтому ведется работа по выделению в Internet отдельного домена высшего уровня (например, .mobile, а не .com), предоставляющего содержимое специально для мобильных устройств. Мобильные устройства вскоре станут очень важными участниками деятельности в Internet, но использоваться в работе они будут не так, как браузеры современных настольных компьютеров. Ближайшее будущее обещает нам много интересного, поскольку можно ожидать появления в Web множества новшеств, специфических для мобильных устройств, а не простого переформулирования идей программного обеспечения, разработанного для настольных компьютеров.

Несколько слов о прохождении контрольных точек

   Очень важно, чтобы проект не хромал на контрольных точках и проходил их твердо и уверенно, а члены группы были едины в своих действиях и по завершении этапа испытывали чувство гордости за проделанную работу. Всегда существует искушение заняться проблемами производительности "когда-нибудь потом", поскольку их решение непосредственно не венчается созданием каких-либо новых инструментальных средств или возможностей; ни в коем случае не поддавайтесь этому соблазну! Как неоднократно доказано на практике, гораздо лучше пройти контрольную точку, пусть и с нарушением установленных сроков, но строго выполнив все необходимые требования, чем быстро ее проскочить, ограничившись компромиссными решениями.
   Ослабление критериев завершения этапов нисколько не ускорит вашего приближения к конечной цели. Если вы видите, что график работ нарушается, то можете выбрать один из трех возможных вариантов дальнейших действий: 
   1. Отказ от разработки некоторых из возможностей продукта для сосредоточения всех усилий на реализации тех возможностей, которые остаются. Если вы решите поступить именно таким образом, то лучше всего сделать это как можно раньше, чтобы разработка остальных возможностей была выполнена на высоком уровне. Отказ от части возможностей приложения на более поздних этапах будет очень болезненно восприниматься теми, кто разрабатывал соответствующие части кода, и конечными пользователями, которые рассчитывали на эти возможности, а также неблагоприятно скажется на разработке оставшейся части продукта, поскольку на ее структуру могли влиять зависимости, которые теперь оказались ненужными. Поскольку отказ от разработки части запланированных возможностей всегда дается очень трудно, это должно делаться корректно, начинаться как можно раньше и осуществляться в условиях уверенного руководства действиями группы. 
   2. Продление графика выполнения работ до более реалистических сроков в соответствии с текущей оценкой состояния проекта. По мере продвижения работы над проектом будут выявляться ранее неизвестные факты, которые позволят вам точнее спрогнозировать срок окончания работ. Если график выполнения контрольной точки должен быть продлен (с соответствующим продлением графика выполнения остальных работ), делайте это решительно, устанавливая реальные сроки. Конечным результатом должен стать график, реальность выполнения которого ни у кого не будет вызывать сомнений. 
   3. Нахождение более оптимальных способов распределения рабочей нагрузки среди членов группы. Включение в группу разработчиков на промежуточных этапах выполнения проекта дополнительных участников, не знакомых с тем, что уже сделано, редко когда приводит к желаемому эффекту. Вместо этого можно попытаться более оптимальным образом распределить работу среди имеющихся участников группы. Аналогично двум предыдущим пунктам, при принятии решений, касающихся распределения рабочей нагрузки среди участников, важную роль играют реалистическая оценка ситуации, а также энергичность и решительность осуществления руководства группой. Лучше быстро утвердить болезненный процесс перераспределения обязанностей одним решением, чем делать это по частям в несколько приемов.

Интерактивное взаимодействие конечных пользователей с приложением

Абсолютная производительность критических алгоритмов

Получение информации об основных показателях производительности в .NET Compact Framework

   В .NET Compact Framework версии 1.1 имеется встроенный механизм, позволяющий быстро получать "черновую" метрику работы приложений на основе управляемого кода в этой среде. Упомянутый механизм обеспечивает получение показателей производительности приложения в целом и по завершении выполнения приложения выводит соответствующий текстовый файл. В этом текстовом файле содержатся следующие данные:
   • Суммарное время выполнения
   • Количество объектов, размещенных в памяти в процессе выполнения кода.
   • Количество операций по сборке мусора, произведенных в процессе выполнения кода.
   • Количество сгенерированных исключений. (Накладные расходы, связанные с обработкой исключений, возбуждаемых часто и без крайней на то необходимости внутри циклов, могут оказаться весьма существенными )
   Поскольку полученные показатели характеризуют работу программы на уровне приложения, их целесообразно использовать в тех случаях, когда вы сравниваете два различных алгоритма или настраиваете определенный алгоритм. Тестируемые алгоритмы следует выделить в собственные исполняемые файлы. Исполняемые файлы должны содержать как можно меньше лишнего кода, чтобы основная часть производимых вычислений приходилась на тестируемые алгоритмы. Исключите из кода любые другие формы или код, которые могут приводить к загрузке, JIT-компиляции и выполнению нежелательных компонентов, если таковые имеются.
   Технические рекомендации относительно того, как активизировать генерацию рассматриваемых показателей времени выполнения, содержатся в статье "Developing Well Performing .NET Compact Framework Applications" ("Разработка высокопроизводительных приложений .NET Compact Framework") на Web-сайте http://msdn.microsoft.com.
   На момент написания данной книги указанная статья располагалась по следующему URL-адресу:
   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfperf.asp
   Кроме того, в этой статье рассматриваются различные способы оценки функциональности кода на основании сравнительного анализа показателей производительности; этот материал также заслуживает прочтения.

Листинг 7.1. Пример кода для измерения временных интервалов, который вы можете использовать для хронометража работы своих приложений

HA ЗАМЕТКУ

   В документации по .NET Compact Framework утверждается, что интервал значений свойства .TickCount не может быть меньше 500 мс (0,5 секунды). Я обнаружил, что на практике достигается несколько лучшее разрешение (менее 100 мс, или 0,1 секунды), чем указанное. Вам придется немного поэкспериментировать самостоятельно. Если окажется, что вам необходим счетчик с более высоким разрешением, можете видоизменить приведенный выше код, включив в него системные вызовы операционной системы, управляющей собственным кодом, для получения доступа к низкоуровневым системным счетчикам. В большинстве случае возможностей приведенного выше кода вам должно быть вполне достаточно, а в силу своей простоты он оказывается удобным для использования в тех случаях, когда измерения требуется выполнить быстро.

Листинг 7.2. Тестовая программа, демонстрирующая использование приведенного выше кода для измерения временных интервалов

Советы относительно повышения надежности результатов измерений

   1. Вы можете пользоваться эмпирическим правилом, в соответствии с которым чем больше длительность события, которую вы измеряете, тем меньше относительная ошибка. Поэтому, если вы сравниваете два алгоритма, для выполнения которых требуется примерно 0,5 секунды, лучше выполнить каждый из них по 10 раз и разделить полученные результаты на 10.
   2. Повторяйте каждый эксперимент несколько раз, убеждаясь в том, что получаемые результаты оказываются в достаточной степени близкими друг к другу.
   3. Если вы сравниваете эффективность двух алгоритмов, выполните каждый из них несколько раз и отбросьте первые из полученных для каждого из них результатов измерений, если они значительно отличаются от результатов последующих измерений. Вполне возможно, что во время первоначального выполнения кода вашим приложением выполняется загрузка и компиляция библиотек, связанных различными зависимостями. Если оба алгоритма имеют аналогичные зависимости, то загрузка и JIT-компиляция этого кода отразится на результатах первого измерения. Время, необходимое для JIT-компиляции кода, среди сравниваемых результатов учитываться, как правило, не должно.
   4. Чтобы при сравнении эффективности двух различных алгоритмов получить наилучшие результаты, заново запускайте приложение в промежутках между тестами. Повторный запуск приложения сбросит весь предварительно скомпилированный и находящийся в кэш-памяти код, тем самым предоставляя вам общее начало отсчета для каждого теста.
   Почти во всех случаях измерения временных промежутков не могут быть идеальными, они могут быть лишь в достаточной степени надежными. Важно лишь следить за тем, чтобы величина измеряемых показателей превышала уровень шумов, которые всегда присутствуют. Независимо от того, что именно вы пытаетесь измерить, всегда можно найти способы, позволяющие отладить методику измерений таким образом, чтобы получаемые результаты были надежными.

НА ЗАМЕТКУ

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

Ответная реакция устройства и пульты дистанционного управления домашней электронной техникой

   Для различных типов устройств предусматриваются различные виды ответной реакции. Быстрая, безошибочная и информативная обратная связь с пользователем является отличительным признаком хорошо спроектированного мобильного устройства.
   Проведем мысленный эксперимент, обратившись в качестве примера к телевизионному пульту дистанционного управления. Хорошие пульты часто обеспечивают несколько разновидностей обратной связи. Во-первых, вы должны ощущать физическое сопротивление кнопок нажатию; каждому, кому приходилось пользоваться дистанционным пультом управления, не имеющим дискретных физических кнопок, знакомо чувство неуверенности, возникающему при нажатии так называемых "программных" кнопок. Во-вторых, в ответ на нажатие какой-либо кнопки дистанционные пульты часто подсвечиваются, указывая на то, что они приняли запрос и пытаются отреагировать на ваш ввод. В-третьих, непосредственной визуальной ответной реакцией телевизионного приемника на получение команды от пульта является вывод на экран шкалы регулятора громкости, цифры или любого другого визуального подтверждения. Если в любом из перечисленных случаев задержка ответной реакции превышает 0,5 секунды, то из-за недостаточно быстрой обратной связи работа пульта кажется замедленной. Эта задержка называется задержкой реакции, и если она наблюдается, то у пользователя немедленно возникает ощущение, что ему попался бракованный пульт. Это вовсе не означает, что пользователь требует, чтобы результаты выполнения отданной команды всегда проявлялись немедленно (хотя это всегда радует); главное, что отличает хороший пульт от плохого, — это немедленное извещение пользователя о том, что его команда принята
   Аналогичные моменты должны учитываться вами и при проектировании приложений. Часто для организации хорошей обратной связи требуется всего лишь добавить в приложение немного кода и чуть-чуть его приукрасить, но это оказывает огромный положительный эффект на пользовательское восприятие устройства и его оценку качества приложения.

Примеры, иллюстрирующие различные варианты организации обратной связи с пользователем

 Листинг 7.3. Демонстрация трех различных уровней организации обратной связи с пользователем

НА ЗАМЕТКУ

   Следует отметить, что поскольку обработка исключений входит в состав базовых средств времени выполнения и отладки .NET Compact Framework и Visual Studio .NET, то производительность приложения может в заметной степени меняться в зависимости от двух обстоятельств
   1. Производительность кода, генерирующего исключения, может значительно ухудшаться, если программа выполняется с подключенным отладчиком. Это объясняется тем, что в этом случае среда уведомляется о возбуждении исключений, даже если они перехватываются кодом приложения. Это означает, что алгоритмы, выполнение которых сопровождается возбуждением многочисленных исключений, при подключенном отладчике будут работать очень медленно! Вы не должны забывать об этом на стадиях проектирования и разработки приложения; возбуждение множества исключений может замедлить разработку. Обычно поведение среды разработки не должно вынуждать вас к изменению способа написания кода, но в данном случае вы должны включить в документ проекта дополнительный пункт, в соответствии с которым следует избегать многократного возбуждения исключений в часто выполняемых циклах.
   2. Различия в производительности кода, использующего обработку исключений, при его выполнении на эмуляторах и физических устройствах весьма заметны. Чтобы получить наиболее точные данные о том, каким образом возбуждение и обработка исключений влияют на производительность вашего приложения, соответствующие тесты должны выполняться на физических устройствах при отключенном отладчике.

Листинг 7.4. Сравнение производительности двух алгоритмов, в одном из которых используются исключения, а во втором — нет

Будут ли меня преследовать те же проблемы, если я пишу приложение на основе собственного кода?

   В отличие от сред выполнения управляемого кода (.NET Compact Framework, Java и так далее), при разработке приложений в собственных кодах сборка мусора не используется. Однако это вовсе не означает, что в этом случае вам удается соскочить с крючка; напротив — нагрузка на стадии проектирования, вероятнее всего, только увеличится! При выполнении на настольных компьютерах приложения, основанные на собственных кодах, пользуются всеми преимуществами, которые неявно предоставляет операционная система, осуществляя обмен страницами ОЗУ с дисковым файлом подкачки. В результате этого, хотя выполнение приложения и может замедляться, оно при любых условиях сохраняет свою работоспособность. Если же ваше мобильное приложение превысит допустимые пределы расхода памяти, то оно просто-напросто исчерпает все ее резервы и завершится сбоем. Отсюда следует, что при разработке мобильных приложений, основанных на собственных кодах, разработчик должен заранее предпринять меры, позволяющие избежать возникновения подобных ситуаций. Кроме того, алгоритмы на основе собственного кода, которые без особой на то необходимости распределяют и освобождают память лишь потому, что были неудачно спроектированы, будут вынуждены бороться с проблемами фрагментации памяти, что также приведет к снижению производительности. В то время как среды времени выполнения управляемого кода могут справляться с фрагментацией памяти за счет ее уплотнения в процессе сборки мусора, в случае собственных кодов аналогичные встроенные возможности отсутствуют. А это означает, что вы должны сами продумать детальную схему управления памятью и самостоятельно ее реализовать.

Не решатся ли обсуждаемые проблемы сами по себе с приходом мобильных устройств "следующего поколения"?

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

Являются ли растровые изображения "пользовательскими" данными или "служебными" данными приложения?

   Поскольку данные растровых изображений представляют загруженные в память и готовые для использования в графике приложения изображения, они могут занимать много места. Держать растровые данные больших изображений может оказаться дорогим удовольствием, и поэтому следует уделить должное внимание тому, когда их следует загружать в память, а когда — освобождать память от них.
   Некоторые типы растровых изображений являются пользовательскими данными. Например, если приложение предназначено для обслуживания сделок по продаже недвижимости и загружает в память изображения домов, то каждая фотография является уникальной и соответствует пользовательским данным, относящимся к данному объекту недвижимости. Наряду с адресом этого дома и его ценой она загружается вместе с остальной информацией об объекте. To же самое можно сказать об изображениях используемых в медицине, которые прилагаются к карточке пациента; каждое изображение связывается с пользовательскими данными.
   Некоторые типы растровых данных являются служебными данными приложения. Растровые изображения, используемые для создания кнопок с привлекательным внешним видом, хранящиеся в кэш-памяти фоновые изображения, стандартные заготовки графических диаграмм — все эти объекты являются служебными данными приложения, поскольку они никак конкретно не связаны с теми данными, с которыми работает пользователь. К этой же категории следовало бы отнести и типовое растровое изображение человеческого тела, которое может использоваться в медицинском приложении для указания очагов болезни. Все эти ресурсы являются общими, и они не связаны ни с какими конкретными данными. Одни формы могут использовать эти ресурсы, другие — могут не использовать; данные изображений могут загружаться, а могут и игнорироваться в зависимости от режима работы приложения и не зависят от того, с каким именно набором данных работает пользователь
   Некоторые типы растровых изображений могут быть отнесены к любой из двух названных категорий. Если у вас есть приложение для торговли недвижимостью, которое может отображать три разновидности изображений поэтажного плана в зависимости от того, какие пользовательские данные загружены, или медицинское приложение, в котором имеется шесть различных разновидностей изображений человеческого тела, соответствующих различным комбинациям пола, размеров и веса то перечисленные изображения можно рассматривать либо в качестве служебных данных приложения, либо в качестве пользовательских данных. Аналогично, если в вашей игре имеются растровые изображения для всех персонажей на экране, и эти изображения меняют свой внешний вид по мере перехода пользователя на более высокие игровые уровни, то одинаково убедительные аргументы могут быть выдвинуты и в пользу того, что данные изображения относятся к служебным данным приложения, и в пользу того, что они относятся к пользовательским данным. В подобных случаях вы должны выбирать для ресурсов ту модель памяти, которая больше всего подходит для вашего приложения. Помещайте изображения рассматриваемой разновидности в ту схему управления памятью, которая наилучшим образом соответствует вашим запросам. 

Использование интерфейса IDisposable и освобождение дорогостоящих неуправляемых ресурсов в .NET Compact Framework

   Если объект больше не используется, код вашего приложения может освободить его, удалив все ссылки, которые на него указывают. Занимаемая объектом память будет восстановлена, когда во время очередной сборки мусора (обычно это происходит тогда когда приложению необходимо распределить память) среда выполнения обнаружит, что на данный объект не указывает ни одна ссылка. Обычно такая схема вас будет вполне устраивать, но из нее следует, что удаление объектов из памяти может откладываться на неопределенное время и производиться лишь тогда, когда острая необходимость в дополнительной памяти заставит систему произвести сборку мусора. Поскольку мы не можем точно сказать, когда именно это произойдет, а, следовательно, и судить о том, когда именно будет удален объект, о времени жизни такого объекта в памяти говорят как о "недетерминированном". Недетерминированность очистки памяти от ненужных объектов является обычной проблемой систем управления памятью, использующих сборку мусора. Поэтому, как правило, следует избегать использования в логике приложения кода, выполнение которого связывается с вызовом деструктора объекта поскольку в этом случае приложение не может явно контролировать, когда именно будет выполнен такой код.
   Проблемы могут возникать также в тех случаях, когда освобождаемый за ненадобностью объект представляет такой "дорогостоящий неуправляемый ресурс", как соединение с базой данных, файловый дескриптор или некоторый графический ресурс. До тех пор, пока объект не будет удален из памяти во время сборки мусора, неуправляемый ресурс, который он представляет, будет удерживаться приложением. Это может отрицательно сказываться на производительности системы как в отношении клиентского устройства, так и в отношении ресурсов сервера удерживаемых клиентом.
   Для того чтобы справиться с этой проблемой, в .NET Compact Framework предусмотрена схема позволяющая коду явно освобождать базовый ресурс, удерживаемый объектом. Для всех объектов, которые представляют дорогостоящие ресурсы, предусмотрен метод Dispose(). Определение этого метода содержится в интерфейсе IDisposable; классы, поддерживающие детерминированный отказ от своих ресурсов, реализуют этот интерфейс и, таким образом, включают в себя метод Dispose().
   Если объект имеет метод Dispose(), то вы всегда можете вызвать этот метод, если необходимость в использовании данного объекта в приложении отпала. Метод Dispose() должен вызываться тогда, когда вы собираетесь удалить любые переменные ссылки на него, чтобы предоставить сборщику мусора возможность удалить этот объект из памяти. Тем самым гарантируется, что дорогостоящий объект, представляемый ресурсом, будет немедленно освобожден. Как и в других ситуациях, имеющих отношение к управлению памятью, если в случае приложений для настольных компьютеров такой подход является просто плодотворным, то в случае мобильных приложений, испытывающих дефицит системных ресурсов (таких, например, как дескрипторы операционной системы). ею применение жизненно необходимо.
   Точно так же, проектируя класс, который представляет дорогостоящий ресурс, вы должны реализовать интерфейс IDisposable, тем самым предоставляя коду, использующему этот класс, возможность детерминированного освобождения удерживаемых данным классом ресурсов. Для подробного ознакомления с деталями надлежащей реализации этого свойства обратитесь к той части документации .NET Compact Framework, в которой описывается метод IDisposable.Dispose().
   На заметку! В языке C# введено специальное ключевое слово, упрощающее вызов метода Dispose() в тех случаях, когда область использования ресурса ограничивается блоком кода функции. Вместо обязательного явного вызова метода .Dispose() можно объявить соответствующую переменную с помощью ключевого слова using.
   Например:
   using(System.Drawing.Graphics myGfx = System.Drawing.Graphics.FromImage(myImage)) {
    //Выполнение всей необходимой работы с помощью функции myGfx…
   } // Метод myGfx.Dispose() вызывается здесь автоматически…
   В случае использования такого объявления метод Dispose() вызывается автоматически при выходе за пределы области видимости переменной. Ключевое слово using очень удобно использовать в тех случаях, когда переменная существует только внутри некоторого блока кода.

Используя кэширование, руководствуйтесь здравым смыслом

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

Листинг 8.1. Применение отложенной загрузки, кэширования и освобождения графических ресурсов 

"Структуры" и .NET Compact Framework

   Во многих случаях, если вы хотите инкапсулировать некоторые простые данные, то для локальных переменных внутри функций гораздо эффективнее использовать не объекты, а структуры. Структура — это просто удобный способ сгруппировать в одном пакете взаимосвязанные данные, а не передавать их в виде отдельных переменных.
   Структуры обладают более простыми свойствами по сравнению с объектами, но могут "упаковываться" в объекты и передаваться внутри программы так же, как они, если в этом возникает необходимость. Использование структур предоставляет определенные удобства и может привести к некоторому увеличению производительности (по сравнению с вариантом, когда используются объекты), но поскольку они выглядят, а во многих случаях и действуют подобно объектам и могут заключаться в объекты-оболочки, необходимо тщательно взвешивать, когда их следует использовать, чтобы избежать дополнительных накладных расходов и не создать лишнего мусора. В сомнительных случаях тестируйте алгоритмы, используя как отдельные переменные (например, базовые типы, подобные int, string, double), так и структуры, чтобы сравнить производительность приложения в обоих случаях и убедиться в том, что она остается примерно одинаковой.
   Более подробную информацию по этому вопросу вы можете получить, обратившись к разделам справочной документации .NET Compact Framework, посвященным типам значений ("value types") и структурам ("struct"). Ниже приводится пример с объявлениями структуры и класса:
   //Примечание. В VB.NET это был бы тип (type), а не структура (struct)
   //Это структура
   struct MyRect_Type {
    public int x;
    public int у;
   }
   //Это класс
   class MyRect_Class {
    public int x;
    public int у;
   }
   //Код примера
   class TestClass {
    public void foo() {
    //Требуется распределять как объект
    MyRect_Class myRectClass = new MyRect_Class();
    myRectClass.x = 1;
    myRectClass.y = 2;
    //Этот оператор распределяет новый объект
    myRectClass = new MyRect_Class();
    //Можно объявить как скалярный тип
    MyRect_Type myRectType;
    myRectType.x = 1;
    myRectType.y = 2;
    //Этот оператор обнуляет значения в структуре, но не
    //распределяет память для нового объекта!
    myRectType = new MyRect_Type();
   }

Листинг 8.2. Общий код, используемый во всех приведенных ниже вариантах тестов

Листинг 8.3. Тестовый пример, демонстрирующий неэкономное распределение памяти (типичный первоначальный вариант реализации интересующей нас функции) 

Листинг 8.4. Рабочий класс для первого тестового примера

Листинг 8.5. Тестовый пример, демонстрирующий уменьшение объема памяти, распределяемой для объектов (типичный образец улучшения первоначального варианта реализации интересующей нас функции) 

Листинг 8.6. Рабочий класс для второго тестового примера

Предшествующий код оставляет возможности для внесения дальнейших улучшений

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

Листинг 8.7. Тестовый пример, демонстрирующий значительное уменьшение объема памяти, распределяемой для объектов (типичный образец существенной алгоритмической оптимизации первоначального варианта реализации интересующей нас функции) 

Листинг 8.8. Рабочий класс для третьего тестового примера

Листинг 8.9. Сравнение эффективности использования строк и класса StringBuilder в алгоритмах

Заблаговременное прогнозирование потребностей пользователя

   Заблаговременное выполнение части работы, в которой заинтересован пользователь, может требовать от вас определенного мастерства, но и положительный эффект от этого может оказаться значительным. Если этот подход реализован так, как следует, то пользователям почти никогда не представится случая по достоинству оценить, какая громадная работа для этого вами проделана; точно так же здоровый человек почти никогда не обращает внимания на то, как работает его сердце.
   В качестве хорошего примера можно привести программу для просмотра изображений в Windows XP. Окно этой программы появляется сразу же после того, как вы дважды щелкнете мышью на имени файла изображения в окне проводника. В результате этого изображение загружается и отображается на экране. Одновременно с этим, но незаметно для пользователя и без какой-либо инициативы с его стороны, после вывода на экран первого изображения на фоне загружается также изображение, файл которого размещен в каталоге вслед за первым. Если следующим действием пользователя, которое можно считать наиболее вероятным, будет щелчок на кнопке Next Image (Следующее изображение) в программе для просмотра изображений, то следующая фотография незамедлительно появится на экране без видимой задержки. В случае современных крупных цифровых фотографий, загрузка, распаковка и масштабирование которых требуют значительного времени, это не такое уж и малое достижение. Описанная заблаговременная загрузка производится в основном только для изображений, которые располагаются следующими в списке файлов каталога изображений. Если вы щелкнете на кнопке Previous Image (Предыдущее изображение), то, вероятнее всего, увидите на экране сообщение "Generating preview" ("Генерируется изображение предварительного просмотра"), появляющееся на короткое время на экране при загрузке фотографии по требованию. Переходы в обратном направлении используются менее часто и поэтому не оптимизируются. Поскольку для цифровых изображений могут требоваться значительные ресурсы памяти, осуществление предварительной загрузки большого количества изображений в предвидении того, что пользователь может захотеть их просмотреть, на сегодняшний день вызывает затруднения. Аналогичным образом, то же самое сообщение "Generating preview" будет появляться на экране, если вы выполните ряд быстрых последовательных щелчков на кнопке Next Image, требующих загрузки очередных изображений; это объясняется тем, что вы требуете большего, чем позволяют возможности средств опережающего просмотра в отношении загрузки следующих фотографий. В большинстве случаев, прежде чем переходить к следующей фотографии, текущую фотографию рассматривают хотя бы в течение одной-двух секунд, и именно для такого сценария и была предусмотрена оптимизация.
   Оптимизация загрузки изображений программой просмотра основывается на вполне разумных предположениях:
   1. В большинстве случае порядок просмотра фотографий соответствует продвижению по списку в прямом направлении.
   2. Обычно каждую фотографию рассматривают достаточно долго для того, чтобы система успела выполнить фоновую загрузку следующей фотографии.
   Независимо от того, используется ли в программе просмотра изображений Windows XP фоновый поток для решения этой задачи или не используется (мне это неизвестно), она демонстрирует пример разумного применения асинхронной обработки для оптимизации рабочего процесса в случае наиболее распространенных действий. Прекрасная работа!

Работая в .NET Compact Framework, не пытайтесь получить доступ к элементам управления пользовательского интерфейса из потоков, которым они не принадлежат

   НА ЗАМЕТКУ
   Если вы используете Visual Studio .NET 2003, то вам необходимо загрузить SDK для Windows Mobile 2003-based Smartphones. Visual Studio NET 2003 поставлялась с "коробочным" вариантом средств разработки приложений для Pocket PC, но не для Smartphone. Поскольку SDK для Smartphone поставлялся после выхода Visual Studio .NET 2003, его следует загрузить и установить поверх Visual Studio .NET. Пакет SDK можно бесплатно загрузить с Web- сайта компании Microsoft (см. приложение А). Этот SDK включает в себя компоненты, необходимые для проектирования пользовательских интерфейсов Smartphone, а также эмулятор Smartphone, позволяющий выполнять приложения, даже если вы не располагаете физическим устройством Smartphone.

Листинг 9.4. Код, который должен быть помещен в класс Smartphone Form1.cs

Листинг 9.5. Код класса FindNextPrimeNumber.cs

Сохранение данных в виде XML

Сохранение данных в текстовых файлах с разделителями-запятыми

Сохранение данных в INI-файлах

Соображения, побуждающие к использованию подхода, основанного на модели XML DOM 

Соображения, побуждающие избегать использования подхода, основанного на модели XML DOM 

Листинг 10.1. Использование XML DOM для сохранения данных в файле и их загрузки

Листинг 10.2. Вызов кода, предназначенного для сохранения и загрузки XML-документа

Чем XMLReader и XMLWriter отличаются от SAX?

   В .NET Framework и .NET Compact Framework реализован подход, основанный на использовании программного курсора, при котором алгоритмы конечного разработчика отдают объекту XMLReader команды относительно перемещения курсора в прямом направлении и синтаксического анализа очередных элементов XML-данных, однако это не единственный из подходов, в которых используется однонаправленная обработка XML- данных. Другим популярным подходом аналогичного рода является модель SAX (Simple API for XML Model — простой API-интерфейс для работы с XML). В то время как при работе с XMLReader используется подход на основе программного курсора, предоставляющий программисту возможность выбирать, как и когда перемещаться курсору в прямом направлении, SAX представляет собой модель, основанную на событиях, в которой механизм синтаксического анализа выполняет проход по всему XML-документу (также только в прямом направлении) и генерирует события, которые код конечного разработчика может обрабатывать для исследования содержимого XML-документа в ходе его анализа. Модель XMLReader основана на "извлечении" данных, то есть код приложения извлекает очередную порцию XML-данных, которые необходимо обработать. Модель SAX основана на "выталкивании" данных, то есть порции XML-данных передаются событиям, которые обрабатываются кодом приложения. Обе модели преследуют одну и ту же цель, а именно — облегчить быстрое выполнение синтаксического анализа XML-документов при низких накладных расходах. Выбор между моделями SAX и XMLReader/XMLWriter определяется личными предпочтениями и доступностью соответствующих средств на платформе, с которой вы работаете. Приведенные в данном разделе рекомендации в равной степени справедливы для обеих моделей.

Соображения, побуждающие к использованию однонаправленной обработки XML-данных 

Соображения, побуждающие избегать использования однонаправленной обработки XML-данных 

Листинг 10.3. Использование однонаправленного чтения-записи XML-данных для загрузки XML-документа из файла и его сохранения

Почему в версии 1.1 .NET Compact Framework не поддерживаются XSLT и XPath?

   При проектировании .NET Compact Framework ставилась цель найти разумный компромисс между двумя проектными ограничениями. Необходимость сведения к минимуму размера NET Compact Framework (объем установленного на устройстве программного обеспечения не должен был превышать 2 Мбайт) вступала в противоречие со стремлением предоставить разработчикам как можно более широкие функциональные возможности. В процессе поиска компромиссных решений степень полезности тех или иных средств и необходимость в них тщательно взвешивались с точки зрения соответствующего увеличения размера .NET Compact Framework. Исходя из этих соображений и было решено, что в первом выпуске NET Compact Framework средства XPath и XSLT поддерживаться не будут.
   XPath — это язык запросов, используемый для проведения поиска в XML-документах. Этот язык предоставляет очень широкие возможности поиска, но отличается сложностью, и для его эффективного использования требуется значительная вычислительная мощность. XSLT — это технология преобразования дерева XML-документа в новый документ в соответствии с определенными правилами; эту технологию часто применяют для преобразования XML-данных в HTML-документы. Для его эффективного функционирования также требуются значительные вычислительные ресурсы.
   Полезность обоих указанных средств совершенно очевидна, и каждому разработчику хотелось бы иметь их в своем распоряжении, но было ли бы уместным их применение в случае мобильных приложений, выполняющихся на устройствах в условиях дефицита ресурсов? Поддержка XSLT и XPath лишь привела бы к напрасному увеличению размера .NET Compact Framework, поскольку предоставляемые разработчику функциональные возможности не могли бы эффективно использоваться во многих задачах, для которых они предназначены. Именно из этих соображений и было решено не включать поддержку XPath и XSLT в версию 1.1 .NET Compact Framework.
   Не исключено, что поддержка этих средств появится в последующих версиях .NET Compact Framework; в частности, существует настоятельная потребность в поддержке XPath. Однако разработчикам следует хорошенько подумать о том, с какими трудностями им придется столкнуться, если они решатся на использование пусть и ценных, но весьма требовательных в отношении необходимых вычислительных ресурсов библиотек. Обычно считается, что встроенные средства среды выполнения должны нормально функционировать при любых обстоятельствах, однако это далеко не так. Вспомните данные ранее в этой главе рекомендации относительно необходимости тщательно взвешивать достоинства и недостатки удобного, но требующего использования обширной информации о состоянии подхода, основанного на модели XML DOM, и более сложного, но менее зависимого от состояния подхода, основанного на однонаправленном доступе к данным с помощью объектов XMLReader и XMLWriter; руководствуйтесь этими же советами и тогда, когда возникает проблема выбора зависящей от состояния или требовательной к ресурсам библиотеки. Вы можете использовать такую библиотеку, но всегда оценивайте, с какими дополнительными расходами это будет сопряжено, и проводите соответствующие измерения.

Использование элементов управления TreeView и ListView среды .NET Compact Framework для повышения производительности приложений

   Элементы управления TreeView и ListView используются для отображения наборов взаимосвязанных данных в пользовательских интерфейсах. Поскольку эти элементы управления работают с наборами данных, часто возникает необходимость в добавлении к ним или удалении из них сразу целых групп элементов данных. Для обоих элементов управления предусмотрены высокопроизводительные методы, позволяющие эффективно решать подобные задачи. 
   • .BeginUpdate()/EndUpdate(). Оба эти метода присутствуют как в TreeView, так и в ListView, и предназначены для приостановки и возобновления автоматической перерисовки элемента управления на экране. Вызов метода BeginUpdate() указывает на то, что элемент управления не должен автоматически перерисовываться всякий раз, когда в него добавляются или из него удаляются элементы данных, тогда как вызов метода EndUpdate() восстанавливает режим автоматической перерисовки элемента управления. Выполнение необязательных операций перерисовки экрана может отрицательно сказываться на производительности приложения. Если в процессе работы вашего приложения возникает необходимость в помещении в элемент управления или исключении из него многочисленных данных, то соответствующий участок кода целесообразно окружить парой вызовов BeginUpdate() и EndUpdate(). 
   • .AddRange(). Для коллекции узлов элемента управления TreeView предусмотрен метод AddRange() (например, treeView1.Nodes.AddRange()), обеспечивающий групповое добавление узлов в TreeView. Такой "пакетный" режим обработки является гораздо более предпочтительным по сравнению с простым итеративным добавлением каждого узла по отдельности.
   Используя эти эффективные встроенные механизмы, вы можете добиться существенного выигрыша в отношении как производительности, так и бесперебойности работы пользовательского интерфейса. Если с каким-либо элементом управления приходится работать особенно часто, то стоит просмотреть список его свойств и методов, чтобы выяснить, не найдутся ли среди них такие, использование которых позволит увеличить производительность.

Пример: различия в производительности, обусловленные использованием различных подходов при работе с элементами управления TreeView

Visual Studio .NET автоматически создаст и свяжет с кнопкой пустой обработчик событий

   Все, что вы должны для этого сделать — это дважды щелкнуть на кнопке формы. Имя добавленной функции будет состоять из имени элемента управления (например, button1) и суффикса _Click. Visual Studio выполнит следующее: 1) создаст для вас функцию обработчика событий, 2) запишет код в функцию InitializeComponent() формы, предназначенную для подключения только что созданного обработчика события щелчка, и 3) откроет окно редактора кода, чтобы вы могли ввести в нем код для обработчика события. При желании вы можете назвать кнопку по-другому, изменив свойство Name в окне Properties (окно справа на рис. 11.1). Целесообразно сделать это до двойного щелчка на кнопке с целью создания и подключения обработчика события, поскольку функция обработчика создается с использованием текущего имени элемента управления. Если имя элемента управления будет изменено уже после создания этой функции, обработчик по-прежнему останется связанным с ним должным образом, но его имя не будет согласовываться с новым именем элемента управления. Обеспечить совпадение имен в этом случае вам придется вручную; сделать это не составляет особого труда, но для этого вам придется выполнить лишнюю работу.

Листинг 11.1. Заполнение данными и очистка от них элементов управления TreeView с использованием альтернативных стратегий

.NET Compact Framework: не все поддерживаемые обработчики прерываний предоставляются конструктором форм Visual Studio .NET

   Платформа .NET Compact Framework поддерживает подмножество управляющих событий платформы .NET Compact Framework, ориентированной на настольные компьютеры. Следует отметить, что одно лишь наличие в .NET Compact Framework сигнатуры какого-либо события еще не является гарантией того, что это событие может быть возбуждено во время выполнения. Могут существовать специфические условия совместимости или причины, связанные со свойствами объектного наследования, в силу которых определение события необходимо было связать с элементом управления, но само событие запускаться во время выполнения в .NET Compact Framework не будет. Единственный способ прояснения подобных ситуаций состоит в том, чтобы подключить событие к элементу управления и посмотреть, будет ли оно запущено во время выполнения. Эта ситуация дополнительно осложняется тем фактом, что не все события, поддерживаемые платформой .NET Compact Framework, отражаются в графической среде проектирования Visual Studio .NET. Среди поддерживаемых событий имеются и такие, которые не фигурируют в списке событий C# в панели свойств или в выпадающем списке событий Visual Basic .NET в редакторе кода.
   События, отображаемые в среде проектирования, должны поддерживаться платформой .NET Compact Framework, но имеется ряд дополнительных событий, которые .NET Compact Framework поддерживает, но не отображает. Причиной такого поведения явилась недостаточная координация работ над этим проектом: группа, работающая над средствами проектирования, и группа, работающая над средой выполнения, не смогли идеально организовать взаимодействие между собой! (Надеюсь, что в процессе дальнейшего усовершенствования платформы подобная ситуация уже не повторится.) Большинство обычных событий отображаются в окне конструктора форм, но некоторые специфические события могут требовать подключения их к форме вручную. Сделать это несложно, но для этого надо хотя бы немного знать о том, как осуществляется подключение обработчиков событий.
   Если вы хотите использовать событие, которое поддерживается в .NET Compact Framework, но не предлагается в качестве доступного в среде проектирования Visual Studio .NET, вам придется вручную вставить одну строку кода в функцию InitializeComponent() формы, содержащей данный элемент управления. Функцию InitializeComponent() вы найдете в обычно скрытом или свернутом разделе "Windows Form Designer-Generated Code" редактора кода класса.
   Добавление обработчика событий BeforeExpand в элемент управления TreeView иллюстрирует приведенный ниже фрагмент кода:
   #region Windows Form Designer generated code
   private void InitializeComponent()
   … строки кода для других элементов управления …
   //
   // treeView1
   //
   this.treeView1.ImageIndex = -1;
   this.treeView1.Location = new System.Drawing.Point(72, 48);
   this.treeView1.Name = "treeView1";
   this.treeView1.SelectedImageIndex = -1;
   this.treeView1.Size = new System.Drawing.Size(168, 176);
   this.treeView1.TabIndex = 0;
   //ОДНОСТРОЧНЫЙ КОД ДЛЯ ПОДКЛЮЧЕНИЯ СОБЫТИЯ, КОТОРЫЙ ВЫ ДОЛЖНЫ ВСТАВИТЬ
   this.treeView1.BeforeExpand += new.System.Windows.Forms.TreeViewCancelEventHandler(this.TreeView1BeforeExpand);
   … строки кода для других элементов управления …
   Представленный выше код подключает обработчик события BeforeExpand элемента управления treeView1. Функция обработчика события должна иметь специальную сигнатуру. В данном случае она имеет следующий вид:
   private void TreeView1BeforeExpand(object sender, System.Windows.Forms.TreeViewCancelEventArgs e) {}
   Неплохим способом обеспечения автоматической генерации обоих вышеприведенных фрагментов кода является использование проекта Windows Application для настольных компьютеров. В Visual Studio .NET проекты для настольных компьютеров поддерживают графический способ создания и подключения всех поддерживаемых обработчиков прерываний. Сгенерированный при этом код вы далее можете скопировать и вставить в соответствующие части своего проекта .NET Compact Framework.
   Заслуживает рассмотрения и слегка видоизмененный вариант описанной выше стратегии. Поскольку конструктор форм автоматически вставляет и удаляет код внутри функции InitializeComponent(), существует вероятность того, что он добавит свой код поверх добавленного вами кода. Чтобы этого избежать, может оказаться целесообразным создать собственную функцию (например, MyInitializeComponent()), чтобы вставить в нее свой код, выполняющий все действия по инициализации, и вызвать эту функцию в коде конструктора формы сразу же после вызова InitializeComponent(). Благодаря этому вы сможете быть уверены в том, что ваш код не будет случайно удален конструктором форм.

Пример: заполнение элемента управления TreeView данными по требованию

Листинг 11.2. Динамическое заполнение данными элемента управления TreeView

Пример: демонстрация возбуждения события, заключающегося в изменении содержимого текстового окна в результате установки значения свойства .Text

   НА ЗАМЕТКУ
   При выполнении приложения на платформе .NET Compact Framework 1.1 в случае установки значения свойства Text элемента управления TextBox программным путем событие TextChanged в действительности запускается дважды.
   Выполнение того же кода на настольном компьютере сопровождается только однократным запуском указанного события. Вероятно, поведение последующих версий NET Compact Framework будет изменено таким образом, чтобы оно совпадало с поведением .NET Framework (однократный запуск события). События — коварная вещь. Будьте очень внимательны в своих предположениях относительно того как и когда запускаются события.

Листинг 11.3. Запуск обработчика событий при изменении содержимого элемента TextBox программным путем 

Не позволяйте событиям заставать вас врасплох

Пример приложения Pocket PC, демонстрирующий работу средств контроля запуска событий

Листинг 11.4. Использование модели состояний для обновления интерфейса и контроль запуска событий с целью более глубокого изучения процесса обработки событий и управления им

Листинг 11.5. Вызов метода Update() элемента управления для отображения пояснительного текста, информирующего о ходе выполнения задачи

Уменьшение размера файла: достижение баланса между степенью сжатия и разрешением изображения

   Для уменьшения размеров файлов цифровых изображений используют три способа:
   1. Снижение разрешения. Суть этого способа заключается в уменьшении фактического количества пикселей, составляющих изображение. Если в Windows XP войти в программу Paint, выбрать в меню Рисунок пункт Растянуть/наклонить и уменьшить изображение до 50% его первоначальной ширины, то количество пикселей в изображении уменьшится наполовину. Уменьшив далее изображение до 50% его первоначальной высоты, вы еще раз уменьшите его разрешение в два раза. Теперь количество пикселей в полученном изображении будет составлять 25% от первоначального (0,5×0,5 = 0,25). Уменьшение количества пиксельных данных, подлежащих сохранению, означает уменьшение общего размера изображения.
   2. Выбор наиболее подходящего формата файлов. Различные разновидности распространенных файловых форматов отличаются друг от друга своей способностью сжимать различные изображения. Одни форматы хорошо подходят для фотографий (множество цветовых оттенков, мало резких границ), другие больше всего пригодны для сохранения компьютерной графики (резкие границы изображений, небольшое количество цветовых оттенков). В некоторых форматах сжатие изображений вообще не применяется. Выбор наиболее подходящего формата позволит обеспечить наилучшее качество изображения при минимальном размере.
   Некоторые файловые форматы обеспечивают дополнительную возможность выбора глубины цвета сохраняемого изображения. Глубина цвета представляет собой количество битов, используемых для описания изображения. Если можно обойтись меньшим количеством цветов, то выбор меньшей глубины цвета позволит уменьшить размер файла.
   3. Увеличение степени сжатия. Во многих случаях алгоритмы сжатия с потерей качества предоставляют возможность выбора приемлемой степени сжатия, обеспечивающей получение изображений желаемого качества.
   Чтобы добиться снижения размера файла изображения, начните с разрешения. Уменьшите размер изображения, приведя его в соответствие с размерами экрана вашего устройства; благодаря этому вы сможете избавиться от ненужных данных. Далее, выберите подходящий формат файла, который обеспечивает наилучшее качество изображения при минимально возможном размере файла и минимальной глубине цвета. Наконец, если применяется метод сжатия с потерями, поэкспериментируйте с параметрами сжатия.

Формат JPG/JPEG

Формат PNG

Формат GIF

Формат BMP

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

   Существуют два способа интеграции управляемой среды выполнения с графикой и моделью пользовательского интерфейса хоста. Среда выполнения может использовать готовые библиотеки элементов пользовательского интерфейса, поддерживаемые операционной системой, или же привлечь для выполнения этой работы собственные библиотеки.
   .NET Compact Framework, выполняющаяся на устройствах, использующих операционные системы Windows СЕ, Pocket PC и Smartphone, предоставляет визуализацию большинства своих элементов управления пользовательского интерфейса и управление ими операционной системе. Под этим подразумевается что элементу управления Window платформы .NET Compact Framework соответствует элемент управления Window операционной системы Windows СЕ, элементу управления ListView платформы .NET Compact Framework — элемент управления ListView операционной системы Windows СЕ, элементу управления Button платформы .NET Compact Framework — элемент управления Button операционной системы Windows СЕ и так далее. Преимущества такого подхода обусловлены несколькими причинами:
   1 Производительность. Специалисты по разработке операционных систем затратили много времени на проектирование и настройку элементов управления своих пользовательских интерфейсов. Добиться аналогичной производительности при перерисовке всех окон и элементов управления и обеспечить надлежащее управление их взаимодействием с пользователем путем самостоятельной реализации этих возможностей очень трудно.
   2. Внешний вид и нюансы поведения. Элементы управления .NET Compact Framework обладают теми же поведенческими характеристиками, что и элементы управления базовой системы Windows. Реализация пользовательского интерфейса сопряжена с необходимостью принятия множества мелких решений наподобие: "Как именно должны прорисовываться пиксели при визуализации элемента управления? Что должно происходить, если выделить блок текста и нажать клавишу забоя, ввести букву, выполнить двойной щелчок на слове?" Добиться точного воспроизведения внешнего вида и нюансов поведения пользовательского интерфейса очень трудно, а вместе с тем люди очень чувствительны к малейшим отклонениям от того, к чему они привыкли.
   3. Размер кода. Повторная реализация кода для перерисовки и манипулирования элементами управления, который уже предусмотрен в операционной системе, приведет к ненужному увеличению размера кода каркаса приложения. Привлечение для этих целей того, что уже имеется в операционной системе, позволяет сэкономить значительный объем рабочего пространства среды выполнения.
   Несмотря на то что в .NET Compact Framework, выполняющейся на устройствах с операционными системами Pocket PC, Smartphone или Windows СЕ, реализация большинства элементов пользовательского интерфейса делегируется операционной системе, это вовсе не означает, что вы не имеете возможности создать совершенно новый элемент управления средствами каркаса приложения. В .NET Compact Framework можно создать графический элемент управления с нуля, и это делается в тех случаях, когда в базовой операционной системе аналогичный элемент управления отсутствует. Эту работу может выполнить конечный разработчик, но для таких элементов управления, как GridControl, она была выполнена и в .NET Compact Framework.
   Описанный подход применяется не во всех управляемых средах выполнения. Некоторые из них получают от базовой операционной системы лишь пространство для рисования и самостоятельно организуют рисование элементов управления и манипулирование ими. Преимуществом такого подхода является то, что он позволяет обеспечить единообразие внешнего вида и поведения интерфейса на каком бы устройстве приложение ни выполнялось. К недостаткам реализации нестандартных пользовательских интерфейсов относятся увеличение размера приложения и накладных расходов, связанных с необходимостью выполнения дополнительной обработки, а также риск того, что внешний вид и нюансы поведения элементов управления не будут совпадать с аналогичными свойствами элементов управления базовой операционной системы. Суть дела здесь состоит в достижении некоего разумного компромисса.
   Если .NET Compact Framework переносится на другую платформу (в процессе ее проектирования такая возможность заранее предполагалась), то она должна будет либо использовать возможности пользовательского интерфейса базовой операционной системы, либо предоставить свою реализацию этих элементов управления в виде библиотек на основе собственного или управляемого кода. По своим возможностям встроенной поддержки элементов управления пользовательского интерфейса операционные системы различных устройств существенно отличаются друг от друга, так что объем работы, которую при этом придется выполнить, и выбор стратегии проектирования оказываются в высшей степени зависящими от характеристик конкретной целевой операционной системы.

Четырехминутный практикум по работе с графикой в .NET Compact Framework

   В документации к .NET Framework и .NET Compact Framework содержится обширная информация по работе с графикой, с которой вам обязательно стоит ознакомиться. Ниже приведены лишь самые основные сведения.
   Рабочей лошадкой графики в NET является объект System.Drawing.Graphics. Если вы знакомы с методами разработки приложений в собственных кодах Windows, считайте, что это — объектно-ориентированная версия hDC (Device Context, контекст устройства). Чтобы нарисовать что-либо (например, фигуру, линию, текст, растровое изображение) на поверхности битовой карты, ваш код должен вызвать соответствующий метод объекта Graphics. Не менее важно знать о том, что после того как вы закончите работать с созданным перед этим объектом Graphics, необходимо освободить память от этого объекта при помощи вызова функции Dispose(), иначе он будет занимать драгоценные системные ресурсы. Для того чтобы постоянно держать под рукой какой-либо из объектов Graphics, у вас должны быть веские причины.
   Если объект Graphics не создается, а передается, то обычно этот объект вам предоставляет вызывающая функция. В подобных случаях забота о том, чтобы освободить память от этого объекта с помощью метода Dispose(), обычно лежит не на вашем коде; при вызове метода Dispose() объекта, который все еще используется другим кодом, возникают проблемы. Наиболее распространенные ситуации, в которых объект Graphics передается другой функции, возникают, когда вы пишете обработчик Paint для нестандартного элемента управления или подключаетесь к обработчику Paint для формы или стандартного элемента управления. В этих случаях вы выполняете нужные операции рисования при помощи передаваемого вам объекта Graphics.
   Перья (Pen), кисти (Brush), шрифты (Font), растровые изображения (Bitmap) также должны создаваться. Эти объекты не принадлежат какому-то одному объекту Graphics; одни и те же объекты могут использоваться различными объектами Graphics. Когда работа с этими объектами в вашем коде закончена, для них также необходимо вызывать метод Dispose(). Тем не менее, в случае мобильных приложений использование глобальных объектов Pen, Brush, Font или Bitmap, если они часто используются, может оказаться полезным и эффективным. Производительность приложения можно значительно повысить, применяя тщательно продуманную стратегию кэширования объектов.
   Для указания атрибутов рисования визуализируемых объектов используется класс ImageAttributes. Он передается при помощи перегруженных методов Graphics.DrawImage() и позволяет вашему приложению устанавливать прозрачный цвет для битовых образов, копируемых на другую поверхность. Использование класса ImageAttributes на платформе .NET Compact Framework позволяет вашему приложению назначать один из цветов битового образа в качестве прозрачного; благодаря этому ваш код получает возможность визуализировать на битовых образах объекты, форма которых отличается от прямоугольной. Такая возможность оказывается очень полезной при написании игр. Как и в случае других классов, объекты ImageAttributes по окончании работы должны вызывать метод Dispose(). 

Отображение растровых изображений в элементе управления PictureBox

Листинг 11.6. Создание изображения на внеэкранной растровой поверхности и передача его в элемент управления PictureBox

Рисование непосредственно в форме

Листинг 11.7. Создание объекта Graphics для формы

Листинг 11.8. Подключение к функции Paint формы

Обработчики событий или перекрытые функции?

   Существует еще один способ подключения к запросам Paint. В приведенном выше примере для этого использовался подход, основанный на механизме наследования. Однако обработку событий Paint можно осуществлять и при помощи обработчика событий. Это выполняется точно так же, как и подключение к обработчику событий Click; для получения запросов событий необходимо зарегистрировать функцию. Если вместо перекрытия метода OnPaint() использовать обработчик событий, то в приведенный выше код необходимо внести три вида изменений:
   1. Следует изменить имя и сигнатуру метода таким образом, чтобы они соответствовали тому, что требуется для обработчика событий Paint (например, protected void PaintEventHandler(object sender, PaintEventArgs e) вместо protected override void OnPaint(PaintEventArgs e)).
   2. Вызов base.OnPaint (e) необходимо удалить, поскольку осуществление этого вызова не входит в обязанности обработчика событий. В действительности, именно базовая реализация base.OnPaint(e) вызывает любой зарегистрированный обработчик событий.
   3. В функцию InitializeComponent формы необходимо добавить код для подключения нового обработчика событий. Например, добавьте такой код:
   this.Paint += new System.Windows.Forms.PaintEventHandler(this.PaintEventHandler);
   InitializeComponent();
   Выбирая между обработчиком событий и механизмом наследования, вы можете руководствоваться собственными соображениями. Что касается меня, то для такой низкоуровневой работы, как подключение к обработке запросов перерисовки экрана (Paint), я предпочитаю использовать подход, основанный на механизме наследования, который мне более понятен. Для высокоуровневых событий, например щелчков (Click), я предпочитаю прибегать к подходу, основанному на использовании обработчиков событий, поскольку этот код автоматически генерируется для меня после двойного щелчка на элементе управления в окне конструктора форм.

Реализация пользовательских элементов управления

   НА ЗАМЕТКУ
   Существует возможность сделать пользовательский элемент управления видимым на стадии проектирования!
   В данном примере пользовательский элемент управления для простоты создается во время выполнения. Чтобы отобразить его для разработчика на стадии проектирования, в результате чего этот элемент управления будет виден в окне конструктора форм подобно любому другому стандартному элементу управления, в приложение следует кое-что добавить. Обсуждение этого вопроса выходит за рамки данной книги, однако соответствующая информация содержится в документации по .NET Compact Framework.Окно сообщения, появляющееся в ответ на запуск события щелчка на пользовательском элементе управления

Листинг 11.9. Простой пользовательский элемент управления, который изменяет цвета и запускает событие, определяемое пользователем

Листинг 11.10. Код, который должен быть помещен в форму для создания экземпляра пользовательского элемента управления

Пример 1: предварительная визуализация объектов бизнес-диаграммы

Пример 2: предварительная визуализация объектов для сюжетной игры

   HA ЗАМЕТКУ
   Те, кого интересует исходный текст этого приложения, могут найти его на Web-сайте. Приложение было написано на языке VB.NET и названо "HankTheCaveMan" ("Пещерный человек Хэнк"). Оно позволяет продемонстрировать многие из концепций графики, которые обсуждаются в этой главе. Полный исходный код приложения доступен для загрузки на сайте обмена исходными кодами www.gotdotnet.com вместе с бесчисленным множеством других примеров и информации.

Листинг 11.11. Три полезных способа кэширования графических ресурсов

Листинг 13.1. Использование конечного автомата для экспериментов с двумя различными вариантами компоновки пользовательского интерфейса

Местоположение, местоположение и еще раз местоположение

Выбирайте соответствующие элементы управления для соответствующих устройств

Когда целесообразнее использовать различные формы, а когда — осуществлять смену элементов управления

Пример создания динамического элемента управления

Листинг 13.2. Динамическое создание элементов управления на форме во время выполнения

Пример элемента управления TextBox с фильтром

Листинг 13.3. Фильтрующее текстовое окно, принимающее текст в формате ###-##-####