Эту книгу я посвящаю своим учителям, как формальным, так и неформальным, но в первую очередь — родителям, Эйр (Aire) и Уильяму Салмре (William Salmre). Если мне и удалось взглянуть на кое-что по-новому и изложить свои мысли с пользой для дела, так это только благодаря доброте и терпению тех, кто не пожалел времени на то, чтобы провести меня вверх по склону горы и указать правильное направление. Спасибо вам всем.

Благодарности издательства

Издательский дом "Вильямс" благодарит Ерофеева Сергея и Кущенко Сергея за большой вклад в подготовку издания книги.

Салмре Иво

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

Об авторе

Иво Салмре (Ivo Salmre) более десяти лет работал в компании Microsoft, занимаясь в основном проектированием и выпуском инструментальных средств разработки программного обеспечения для настольных компьютеров и серверов, но впоследствии сосредоточившись на мобильных устройствах. Иво был ведущим программистом проекта .NET Compact Framework. Он получил степень бакалавра в области электротехники в университете штата Коннектикут, и его доклады можно часто услышать на отраслевых конференциях. Прожив десять лет в Сиэтле и немногим более года в Лондоне, в настоящее время Иво работает в Европейском Инновационном Центре компании Microsoft (Microsoft European Innovation Center — EMIC) в городе Аахене, Германия, где занимается исследованиями в области разработки программных моделей для современных мобильных устройств. Иво — уроженец города Норфолка, штат Коннектикут.

Предисловие

Мобильные устройства на наших глазах претерпевают революционные изменения

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

Эта книга учит тому, как создавать великолепные приложения для мобильных устройств. С этой целью изложение важных концептуальных сведений сопровождается конкретными практическими примерами. Примеры разработаны на языках программирования С# и Visual Basic .NET для выполнения в среде Microsoft .NET Compact Network, хотя лежащие в их основе идеи в равной степени применимы ко всем мобильным компьютерным программным технологиям и платформам. Наибольшую пользу эта книга принесет тем, кто использует в своей работе Visual Basic и С#, поскольку они получат возможность расширить свои познания в этой области. В общем, книга адресована всем, кто заинтересован в создании высококачественного программного обеспечения для мобильных устройств, вне зависимости от того, приверженцами какой технологии программирования они являются.

Если бы мне позволили помечтать о рецензии, то хотелось бы, чтобы она была примерно такой:

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

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

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

Чего в наши дни не хватает большинству технических книг?

В наши дни выходит в свет очень много технической литературы, посвященной разработке программного обеспечения. На полках книжных магазинов и в Web в изобилии представлены описания всевозможных программ и масса справочного материала. Мы живем в мире, в котором на нас обрушиваются мощные информационные потоки, но, несмотря на это или, возможно, именно по этой причине, приблизиться к реальным знаниям очень трудно. Тому, кто к этому стремится, приходится переворачивать тонны породы, чтобы докопаться до скрытых где-то в их недрах драгоценных алмазов сути. Будучи, как и порода, чрезвычайно полезными сами по себе, сырые факты — это все же далеко не те драгоценные камни, которые мы хотим отыскать. Чего не хватает — и это особенно касается имеющейся литературы по разработке программного обеспечения для мобильных устройств — так это доступной книги прикладного характера, в которой принципы и методы эффективного проектирования мобильных программ излагались бы с использованием конкретных примеров, иллюстрирующих теорию. Автор надеется передать читателям книги те драгоценные крупицы знаний, которые обогатят их и подтолкнут к открытию замечательных возможностей, таящихся в программном обеспечении для мобильных устройств. В этой книге изложение основного материала сопровождается практическими примерами, которые должны вдохновить читателей на проведение собственных экспериментов и наблюдений в процессе изучения ключевых элементов, лежащих в основе создания мобильных приложений.

Что нового в этой книге?

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

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

На кого рассчитана эта книга?

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

■ Разработчики программного обеспечения на языках Java, С# и VB.NET для настольных компьютеров и серверов, которые подумывают о переходе, или уже перешли, к разработке программного обеспечения для мобильных устройств. Те разработчики программного обеспечения для настольных компьютеров и серверов, кто уже использует упомянутые языки программирования, смогут сразу же приступить к работе с приведенными в книге примерами программ. Кроме того, книга поможет им глубже понять различия между разработкой программного обеспечения для классических настольных компьютеров и серверов с одной стороны и мобильных устройств с другой. Надеюсь, что для разработчиков этой категории чтение книги послужит своего рода приятным ознакомительным туром и убедит их в том, что разработка мобильного программного обеспечения — это стрела, которая каждый разработчик обязательно должен иметь в своем колчане. Эта книга поможет им получить знания и навыки, без которых невозможно создать хорошее мобильное приложение.

■ Разработчики программного обеспечения на С++, которые подумывают о переходе к языкам управляемой среды выполнения, например С#. Существует довольно большая вероятность того, что те, кто сегодня использует для разработки программ С и С++, в ближайшем будущем для выполнения некоторой части своей программистской работы будут использовать языки с управляемым кодом, примером которых может служить язык С#. Достигаемый при этом выигрыш в производительности и надежности программ просто ошеломляет. Многие примеры в этой книге написаны на С#, так что разобраться в текстах программ разработчикам на С/С++ не составит особого труда.

■ Разработчики программного обеспечения на Visual Basic, которые хотели бы начать работать с VB.NET или С#. В этой книге примеры приводятся как на С#, так и на Visual Basic .NET, что облегчает изучение основ упомянутых языков и использование библиотек времени выполнения .NET Framework. Поскольку платформа .NET Compact Framework представляет собой некое функционально развитое подмножество инструментальных средств платформы .NET Framework, ориентированной на настольные компьютеры и серверы, написание программ для мобильных устройств превратится для разработчиков этой категории в приятный способ изучения новых программных моделей.

■ Все, кто заинтересован в оттачивании своего технического мастерства в области программирования. Данная книга в основном направлена на то, чтобы оказать помощь читателю в выработке устойчивых технических навыков. Те, кто желает отточить свое мастерство в области разработки программного обеспечения для серверов, настольных компьютеров и других устройств, смогут по-новому и с пользой для себя посмотреть на задачи программирования с точки зрения разработчиков программ для мобильных устройств.

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

Благодарности

Эта книга не только посвящена всему, что связано с мобильными устройствами, но и сама является продуктом компьютеризации мобильных устройств. Мне пришлось потратить много времени на поездки в разные регионы с рюкзаком и карманами, до отказа набитыми всевозможными мобильными устройствами, составлявшими мне компанию в дороге. Книга была написана на протяжении года, проведенного в поездках, которыми были охвачены, по крайней мере, шесть стран на территории двух континентов, что не обошлось без невероятного количества кофе, выпитого в вечерние часы. Кстати, хочу заметить, что кофе в Европе по своему вкусу, как правило, значительно превосходит сорта, доступные в Северной Америке, так что проблемой "кофейного отставания" американцам следовало бы заняться более основательно.

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

■ Сотрудники издательств Addison-Wesley и Pearson, которые вдохновляли меня и поддерживали мои намерения. Особую благодарность хочу выразить Карен Гетман (Karen Gettman), с которой я обсуждал первоначальное предложение о написании "технической книги, не похожей на все остальные", Элизабет Здунич (Elizabeth Zdunich), терпеливо работавшей со мной на протяжении всего процесса написания книги, а также Лори Лайенс (Lori Lyons) и Кейт Клайн (Keith Cline) за их титанический труд по редактированию книги.

■ Замечательные люди, которые просмотрели первоначальный черновой вариант книги. Если задача рецензента состоит в том, чтобы избавить будущего читателя книги от любых ошибок, неточностей и некорректности в авторских суждениях, то эти люди великолепно справились со своей работой. Мне очень повезло с получением от этих замечательных людей как вдохновляющих, так и "любовно укоризненных" отзывов. Если наши усилия увенчались успехом, то значительная доля возможных похвал по праву должна принадлежать рецензентам. В частности, хочу поблагодарить Крэйга Нибла (Craig Neable), Билла Дрэйпера (Bill Draiper), Джона Скита (Jon Skeet), Майкла Мэйтланда (Michael Maitland), Дуга Холланда (Doug Holland) и Алекса Фейнмана (Alex Feinman) за предоставление подробных отзывов на рукопись, сопровождаемых несметным количеством полезных советов и исправлений.

■ Мое руководство в компании Microsoft, поддержку которого я ощущал на протяжении всего времени. Это просто замечательно, когда тебе предоставляют полную свободу действий и дают возможность заняться собственным проектом, за что я им очень благодарен.

От издательства

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

Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бумажное или электронное письмо, либо просто посетить наш Web-сервер и оставить свои замечания там. Одним словом, любым удобным для вас способом дайте нам знать, нравится или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более интересными для вас.

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

Наши координаты:

E-mail: info@williamspublishing.com

WWW: http://www.williamspublishing.com

Информация для писем из:

России: 115419, Москва, а/я 783

Украины: 03150, Киев, а/я 152

ГЛАВА 1

Введение

"Скажите, пожалуйста, как мне выйти отсюда?"

"Все зависит от того, куда тебе надо выйти ", — ответил Кот.

Льюис Кэрролл, Алиса в стране чудес

(Encarta 2004, Quotations)

Добро пожаловать в мир разработки мобильного программного обеспечения

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

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

Что такое мобильные устройства? С вычислительной точки зрения мобильные устройства представляют собой некое компромиссное решение. Мы жертвуем невероятной вычислительной мощью, огромной емкостью памяти и графическими возможностями современных настольных компьютеров в пользу мобильных устройств в основном ради небольших размеров самих устройств, возможности использовать устройства сразу же, как только в этом возникает необходимость, а также их способности работать в течение длительного времени без перезарядки батарей. Этот компромисс вовсе не так уж плох, как могло бы показаться на первый взгляд. Принимая во внимание непрерывный экспоненциальный рост мощности процессоров и снижение цен, мы находимся на том этапе, когда, например, мое самое заурядное устройство Pocket PC (процессор XScale с тактовой частотой 400 МГц, ОЗУ объемом 64 Мбайт) по своим возможностям во многих отношениях оказывается мощнее настольных компьютеров, работавших под управлением Windows 95 всего лишь несколько лет тому назад. Но наряду с этим мобильные устройства являются также качественно другими. Простой перенос операционной системы и приложений с настольного компьютера на мобильное устройство не даст тех результатов, которые могли бы удовлетворить конечного пользователя. Каждому, кто пользуется современным мобильным телефоном или устройством PDA (Personal Digital Assistant — персональный электронный помощник, "карманный компьютер"), хорошо известно, что хотя устройство, которым он владеет, и является самым настоящим компьютером с богатым набором разнообразных возможностей, все же оно значительно отличается от настольного или переносного компьютера. В случае мобильных устройств приоритеты проектирования и пользовательские ожидания иные, нежели в случае традиционных настольных компьютеров.

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

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

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

Данная книга является руководством по разработке программного обеспечения, предназначенного для использования на мобильных устройствах, поскольку при создании мобильных приложений приобретение навыков использования систематического подхода к проектированию и созданию программ становится особенно актуальным. Эта тема пока еще плохо освещена в литературе, а недостаток руководств, написанных доступным языком, и описаний соответствующих методик вызывает чувство неудовлетворенности как у разработчиков, пытающихся перенести свои профессиональные интересы в область мобильных устройств, так и у конечных пользователей, которые реально испытывают на себе отрицательные последствия любых просчетов, допущенных проектировщиками программного обеспечения. Несмотря на то что при написании примеров, приведенных в данной книге, использовалась платформа NET Compact Framework, лежащие в их основе идеи имеют общий характер и представляют интерес для всех разработчиков приложений, какую бы из мобильных сред они для себя ни выбрали. Независимо от того, используются ли собственные коды C/C++, платформы .NET Compact Framework или Java/J2ME, либо любая другая технология, ориентированная на мобильные устройства, хорошее знание устоявшихся методов разработки мобильных приложений играет весьма существенную роль. Читатель научится ясно понимать и со знанием дела анализировать проблемы, с которыми приходится сталкиваться при разработке мобильных приложений, что позволит ему при любых обстоятельствах доводить процесс разработки до успешного завершения. Хочу надеяться, что эта попытка облегчить читателям вхождение в данную область и поделиться с ними знаниями, приобретенными моими коллегами и мною в нелегких условиях, когда нам приходилось пробираться по узким лабиринтам, а на всем пути нас подстерегали многочисленные невидимые ловушки, окажется удачной. Эта книга задумана как руководство, в котором вы найдете необходимые практические рекомендации относительно того, как пройти все этапы разработки мобильного программного обеспечения, чтобы ваши усилия увенчались успехом, и вы смогли извлечь из мобильных вычислительных устройств все то, на что они способны.

Успех определяется несколькими ключевыми факторами

Успешность технического решения зависит от того, насколько удачными были проектные решения. Главную роль в этом играет умение выделить самое главное, отделить зерна от плевел и обозначить ключевые моменты, на продумывание которых стоит затратить свое драгоценное время. В любом деле можно легко отличить специалиста, который делает все "легко и непринужденно", от пыхтящего от натуги новичка. Причина этого очень проста: специалист способен делать все с изящной легкостью потому, что ему это дается действительно легко! Он сразу же интуитивно понимает, на чем необходимо сосредоточить свои усилия, а на что можно просто не обращать внимания. В то же время не обладающий достаточным опытом новичок изводит себя, пытаясь сосредоточиться одновременно на всем, что и заканчивается результатом, предсказать который не представляет особой сложности. Каждый, кому довелось пройти путь от начинающего лыжника или виндсерфера (два вида спорта, для которых характерна очень крутая кривая обучения) до уровня специалиста, сможет по достоинству оценить справедливость этого утверждения. Иногда даже сами специалисты не могут сказать, что именно делает их специалистами, а просто знают, как правильно сделать то-то и то-то (временами такая их позиция буквально бесит новичков, ожидающих от них хоть каких-то объяснений). Обучение тому, как выделить главное, на чем следует сконцентрироваться, является ключевым аспектом становления специалиста. Можно воспользоваться близкой аналогией из области математики, приведя в качестве примера "эффекты первого порядка" в их противопоставлении эффектам "второго, третьего и более высоких порядков", где идея состоит в том, что в любом конкретном уравнении с множеством отдельных членов имеются малозначительные факторы и факторы, с которыми "действительно следует считаться" Общее поведение системы определяется эффектами нижайших порядков. Точно так же обстоит дело и с разработкой мобильного программного обеспечения: здесь все имеет значение, но одни факторы играют гораздо более важную роль, чем другие.

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

1. Сфера применения приложения. Очень важно ясно представлять себе, как в общих чертах, так и на уровне конкретных пользовательских сценариев, какие задачи должно решать данное мобильное приложение. Это утверждение может казаться слишком очевидным, но современные программные проекты буквально "напичканы" всевозможными "уникальными средствами" и обеспечивают достижение целей, ценность которых вызывает сомнения, что и стало причиной краха целого ряда многообещающих проектов, как крупных, так и небольших. Не стоит особняком в этом смысле и мобильное программное обеспечение. Успешные мобильные приложения должны острее фокусироваться на решении частных задач и преследовать еще более конкретные цели, чем их аналоги, выполняющиеся на настольных компьютерах и серверах. Очень важно отчетливо представлять себе, в решении каких задач данное приложение должно оказать помощь пользователю. Так же, если не еще более важно, сформулировать, чего данное приложение делать не должно. Отчетливая направленность приложения имеет критическое значение.

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

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

4. Модель данных и модель памяти. Способ внутреннего представления данных в приложении, объем данных, хранящихся в памяти в каждый момент времени, и методы обработки данных влияют на функционирование мобильного приложения самым кардинальным образом

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

Соответствующие технические методы, обеспечивающие удовлетворение описанных выше требований, обсуждаются в последующих главах.

Как читать эту книгу

Те знания, которыми автор делится с читателями в этой книге, были приобретены им на протяжении многих лет напряженной работы и являются результатом его личного опыта, а также подробных обсуждений с друзьями и партнерами по сети их собственного опыта, накопленного в процессе разработки мобильных приложений. Разработка мобильных программ — это работа, которая одновременно доставляет огромное удовольствие. Всякий раз, когда видишь, как на экране мобильного устройства, без труда умещающегося в кармане, вдруг появляется и начинает выполняться созданное тобой приложение, испытываешь чувство удовлетворения. При наличии таких технологий, как .NET Compact Network и Visual Studio .NET компании Microsoft, a также других конкурентоспособных инструментов и сред выполнения, предлагаемых различными поставщиками, разработка приложений для мобильных устройств становится вполне доступным занятием. Наилучший способ ознакомления с соответствующими методиками и их изучения — это их применение на практике и реализация наряду с собственными идеями.

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

И самое главное — смело экспериментируйте!

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

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

Серверные приложения для мобильных устройств

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

НА ЗАМЕТКУ

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

Технология компании Microsoft, предназначенная для разработки Web-приложений, носит название ASP.NET (Active Server Pages .NET). ASP.NET предлагает "мобильные элементы управления" ASP.NET, предназначенные для мобильных устройств. Visual Studio .NET 2003 предоставляет пользователям возможность создавать мобильные ASP.NET-приложения. На рис. 1.1 показано диалоговое окно Visual Studio для создания нового проекта ASP.NET Mobile Web Application.

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

■ Проектное пространство. Вам предоставляется проектное пространство (design surface), которое учитывает особенности мобильных устройств и характеризуется использованием упрощенной и модернизированной парадигмы компоновки элементов управления, ориентированной на мобильные приложения.

■ Элементы управления, разработанные специально для устройств. Вместо обычного набора элементов управления HTML вам предлагается набор элементов управления Mobile Web Forms (Web-форм для мобильных устройств). Эти элементы специально спроектированы таким образом, чтобы они могли нормально визуализироваться на широком ряде устройств. Некоторые из предлагаемых элементов управления, такие, например, как элемент управления PhoneCall, являются специфическими для определенных типов устройств.

■ Язык визуализируемой разметки документов. На стадии выполнения приложения элементы управления Mobile Web Forms, выполняющиеся на сервере, могут генерировать документы, в которых используются синтаксис языков разметки Wireless Markup Language (WML), Compact HTML (cHTML) или HTML, в зависимости от возможностей браузера, установленного на мобильном устройстве, от которого поступил запрос.

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

Для доступа к мобильным Web-приложениям на устройстве должен быть установлен мобильный браузер, располагающий соответствующими возможностями. Существует множество разновидностей мобильных браузеров, но наиболее распространенными являются уже упоминавшиеся ранее WML-, cHTML- и HTML-браузеры. Большинство современных мобильных телефонов поставляются с предварительно установленным Web-браузером того или иного типа

Значительно больше информации относительно разработки мобильных ASP.NET- приложений вы найдете в оперативной справочной документации. (Великолепной отправной точкой для этого может служить раздел "Mobile" на Web- сайте http://www.asp.net.)

Рис. 1.1. Создание нового проекта ASP.NET для мобильного Web приложения

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

В этой книге основное внимание уделено разработке клиентских приложений для мобильных устройств. Если вы решаете, что ваше мобильное приложение будет лучше всего работать в качестве "толстого" клиента, то вам придется принять еще одно важное решение. Вы должны решить, какую именно технологию следует использовать на стороне клиента. Будете ли вы создавать приложение с использованием собственного или управляемого кода? У каждого из этих двух вариантов имеются свои преимущества и недостатки.

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

Приложения на основе собственного кода (native code) обычно разрабатываются с использованием языков С или С++. Собственные коды полезны в тех случаях, когда вы хотите добиться от системы максимальной производительности или же вам требуется низкоуровневый доступ к оборудованию. В то же время, собственным кодам свойствен ряд серьезных недостатков, перечень которых приводится ниже.

■ Процесс разработки приложений с использованием собственного кода менее продуктивен по сравнению с вариантом управляемого кода. Поскольку вы работаете на более низком уровне абстракции, для создания кода программы потребуется больше времени.

■ Собственный код зависит от процессора. Результатом компиляции собственного кода является последовательность машинных команд, которые зависят от целевого микропроцессора. Таким образом, если предполагается, что в дальнейшем программа должна будет выполняться на процессорах, относящихся к разным семействам, то вам придется компилировать и развертывать несколько версий приложений. Иногда то же самое может потребоваться даже в случае разных процессоров, принадлежащих одному семейству. Так, существует несколько различных вариантов очень популярных микропроцессоров ARM, для каждого из которых необходимо использовать отдельные версии компиляторов собственного кода.

■ Собственный код требует более жесткого тестирования по сравнению с управляемым кодом. Работая с собственным кодом, вы должны самостоятельно заботиться о распределении памяти и других ресурсов. Как показывает практика, создание "идеального приложения" — задача не из легких, если вообще осуществимая. В сложных системах почти всегда найдутся области памяти, которые в силу тех или иных причин не были освобождены после того, как необходимость в них отпала. По прошествии некоторого времени даже небольшая утечка памяти или иных ресурсов в повторяющемся коде может привести к исчерпанию ресурсов устройства. Многие сотовые телефоны почти никогда не выключаются. Во многих устройствах PDA предусмотрены средства немедленного восстановления состояния системы, которые поддерживают выполнение приложений или их сохранение в памяти даже в тех случаях, когда устройство выключается. Своим поведением в отношении утечки памяти мобильные устройства больше напоминают не настольные компьютеры, а серверы, которые часто также остаются включенными в течение длительного времени. В случае утечки памяти система, в конечном счете, перестанет отвечать на ваши запросы или будет работать нестабильно. Разработка собственных кодов для мобильных устройств требует предельного внимания и строгого тестирования приложений в режиме "24/7" (24 часа в сутки, 7 дней в неделю).

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

Во время написания данной книги компания 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++ вам могут для этого понадобиться и какие усилия вам придется приложить для преодоления возникающих при этом проблем разработки и отладки. Разрабатывать мобильные приложения на основе собственного кода намного сложнее, чем для настольных компьютеров или серверов. Чтобы добиться в этом успеха, вы должны быть вооружены ясным пониманием целей и знаниями инструментальных средств, которые собираетесь для этого использовать.

Управляемый код

Термин "управляемый код" (managed code) относится к программному коду, выполняющемуся в управляемой среде (managed environment), будь то среда сервера, персонального компьютера, мобильного устройства или встроенной системы. Диспетчер среды времени выполнения (runtime engine), или просто —среды выполнения, отвечает за распределение ресурсов, управление выполнением потоков и необходимую синхронизацию, а также обеспечивает безопасность типов выполняющегося кода, предотвращая несанкционированный доступ к памяти. Этот уровень абстракции располагается выше уровня собственного кода, что позволяет значительно повысить производительность труда разработчиков и надежность кода. Время существования объектов и других типов, размещенных в памяти выполняющимся кодом, отслеживается диспетчером среды выполнения, что избавляет разработчика от необходимости решения этой задачи. В результате компиляции управляемого кода генерируются двоичные коды инструкций, которые включают в себя метаданные с подробными описаниями классов, типов, переменных и другую информацию, необходимую для управления выполнением кода. Содержащиеся в метаданных описания кодов диспетчер среды выполнения использует для реализации своих административных и контрольных функций. Именно богатый набор метаданных и является ключевым отличием управляемого кода от собственных кода. К числу других характеристик, являющихся общими для многих управляемых сред выполнения, относятся следующие:

■ Независимость от процессора. При компиляции программы, написанной с использованием управляемого кода, получаются не специфические для процессора машинные команды, а программа на промежуточном языке. Для промежуточного языка (intermediate language) часто используют сокращение IL, а в некоторых средах времени выполнения его называют "байтовыми кодами" ("byte codes"); оба эти термина имеют один и тот же смысл. Впоследствии этот промежуточный код преобразуется в мобильном устройстве в соответствующий формат исполняемого кода. Компиляция программы в формат IL обеспечивает возможность выполнения одного и того же скомпилированного кода не только на различных процессорах, но и с использованием адресов различного размера. Так, один и тот же IL-компонент может выполняться и на 32-, и на 64-разрядных процессорах, поскольку инструкции не зависят от размера адресных полей процессора.

■ Независимость от операционной системы. Среды выполнения управляемого кода вместе с их библиотеками обеспечивают разработчикам возможность написания программ на уровне абстракции, расположенном поверх базовой операционной системы. Учитывая тот факт, что пользовательские интерфейсы и модели взаимодействия с пользователем для классов устройств, в которых применяются различные степени абстрагирования верхних уровней, значительно отличаются друг от друга, принцип разработки программ "пишется однажды, выполняется везде" ("write once, run everywhere") вряд ли можно считать практически осуществимым, однако операционная система все еще остается весьма полезным средством обеспечения переносимости приложений на устройства разных классов. Кроме того, возможность создавать автономные (автономные (headless) — не имеющие пользовательского интерфейса) компоненты, способные выполняться на различных устройствах без перекомпиляции, оказывается очень полезной при построении повторно используемых модулей. После того как автономные компоненты заполнены общим кодом, остается лишь реализация зависящих от конкретного типа устройства пользовательских интерфейсов, в которых используются общие модули такого типа.

■ JIT-компиляция (just-in-time — оперативная) и/или интерпретация кода. Существует два метода выполнения управляемого кода: 1) JIT-компиляция, когда IL сначала транслируется в собственные машинные команды процессора, а затем выполняется, и 2) интерпретация, когда просматривается каждая инструкция IL, и для выполнения предусмотренных ею действий вызываются предопределенные библиотеки. Код, получаемый в результате JIT-компиляции, работает быстрее, однако интерпретаторы легче создавать, поскольку они не обязаны знать, как генерировать специфические для процессора команды. Во многих случаях сначала создают интерпретатор, с помощью которого можно быстро перенести управляемый код времени выполнения на новый процессор, и лишь затем создают JIT-компиляторы, позволяющие оптимизировать код для конкретных типов наиболее распространенных процессоров. Один и тот же IL-код может либо интерпретироваться, либо JIT-компилироваться; окончательный выбор остается за теми, кто реализует исполняемый код.

■ Сборка мусора. Сборка мусора — это операция, избавляющая разработчиков приложений от необходимости заниматься утилизацией памяти, используя низкоуровневые функции. Существует множество различных стратегий сборки мусора, каждая из которых оптимизирована для сценариев определенного типа. Исследования в этой области продолжаются, приводя к нахождению все более оптимальных стратегий для самых важных сценариев. Обычной стратегией, применяемой в средах выполнения на мобильных устройствах, является стратегия "отслеживания и очистки" ("mark and sweep"), суть которой состоит в том, что среда выполнения периодически составляет список всех переменных, находящихся в данный момент в области видимости, и отслеживает все объекты, на которые эти объекты ссылаются. Каждый из обнаруженных таким способом объектов снабжается "меткой", указывающей на то, что объект все еще используется. На основании этой схемы создается дерево активных объектов (live-object tree), представляющее полный набор всех объектов, к которым код приложения может получить доступ. После того как все активные объекты отмечены, выполняется операция очистки, которая освобождает все объекты, являющиеся для приложения недоступными. Программы, осуществляющие сборку мусора, представляют собой чрезвычайно сложные системы, так что для оптимизации производительности серверов, настольных компьютеров и мобильных устройств всегда остается масса возможностей. В организациях, занимающихся разработкой сред выполнения управляемых кодов, значительная доля усилий направляется на повышение эффективности стратегий сборки мусора до уровня, способного обеспечить получение максимально возможных производительности и надежности.

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

■ Поддержка безопасности объектов. Наконец, управляемый код может расширить возможности политик безопасности, используемых на устройстве. Среды выполнения управляемого кода с развитой поддержкой средств безопасности могут установить политику, определяющую, какие именно полномочия предоставляются тем или иным разновидностям кода. Такой подход часто называют обеспечением безопасности путем явной проверки полномочий. Примерами политик безопасности подобного рода могут служить следующие: "Код, подписанный заслуживающей доверия третьей стороной, может выполняться без каких-либо ограничений", "Код, присутствующий в локальной файловой системе, может получать доступ к файлам, находящимся в указанном наборе папок" или "Загруженный из Internet код, не снабженный подписью заслуживающей доверия третьей стороны, имеет минимальные права доступа без возможности выполнения типовых операций файлового ввода-вывода". В разных средах выполнения поддержка средств безопасности различна; так, поддержка средств безопасности платформой J2ME отличается от той, которая обеспечивается платформой .NET Compact Framework v1.1. Политики безопасности, поддерживаемые платформой .NET Compact Framework v1.1, являются подмножеством политик безопасности, поддерживаемых платформой .NET Framework.

Двумя наиболее распространенными средами выполнения управляемого кода на мобильных устройствах являются J2ME (Java Mobile Edition) и .NET Compact Framework. В данной книге для иллюстрации принципов разработки программного обеспечения для мобильных устройств используется платформа .NET Compact Framework, хотя большинство обсуждаемых положений справедливы по отношению к любым разновидностям методов разработки мобильных программ, включая разработку программ с использованием собственных кодов

Преимущества управляемого кода трудно переоценить. Руководствуйтесь следующим общим правилом: если имеется хоть малейшая возможность использовать для разработки проекта управляемый код, воспользуйтесь ею. Благодаря этому значительно сократятся сроки разработки кода и количество ошибок в нем, облегчится перенос кода на новые устройства, повысятся его безопасность и устойчивость, а сопровождать его будет гораздо легче, чем аналогичный собственный код. Разрабатывать приложения с использованием собственных кодов имеет смысл лишь тогда, когда это диктуется соображениями производительности или необходимостью получения низкоуровневого доступа к устройствам. Но и в этих случаях лучше всего написать на собственном коде лишь небольшие критические участки программы, а во всей остальной ее части использовать высокоуровневый управляемый код. Как будет показано далее в этой книге, использование проверенных методов проектирования мобильного программного обеспечения в сочетании с управляемой средой времени выполнения, поддерживающей JIT-компиляцию, приводит к тому, что необходимость в привлечении собственных кодов возникает лишь в редких случаях. Возможностей управляемого кода чаще всего будет вполне достаточно даже для создания динамичных игр с высокой долей анимации. Преимущества высокоуровневых абстракций управляемого кода невозможно оспаривать. Пару десятков лет тому назад программисты переходили при разработке программ от языка ассемблера к языку С, оставляя ассемблерный код лишь для решения узкоспециальных или критических задач. Такой переход на более высокий уровень абстракции позволил разрабатывать намного более сложные приложения, отличающиеся повышенной надежностью, в гораздо более короткие сроки. В настоящее время совершается аналогичный переход от собственных кодов C/C++ к средам с управляемым кодом.

.NET Compact Framework — среда выполнения управляемого кода для устройств

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

Платформа .NET Compact Framework состоит из двух основных частей:

1) основного исполнительного механизма;

2) широкого набора библиотек управляемых классов.

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

Основной исполнительный механизм .NET Compact Framework реализован на собственном коде. Его задачей является загрузка управляемого кода, компиляция, запуск и выполнение всех задач, связанных с обеспечением выполнения управляемого кода. Платформа .NET Compact Framework перенесена на несколько различных семейств процессоров, включая х86, StrongARM, SH3, MIPS и другие.

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

Исполнительный механизм .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 все эти средства поддерживаются.

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

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

Ниже перечислены API-интерфейсы, используемые разработчиками при создании приложений. Эти API-интерфейсы можно разбить на следующие четыре логические категории:

1. Библиотеки базовых классов. Эти классы являются основой основ программирования. Поддержка строк, массивов, коллекций, файловых операций ввода-вывода, потоков, сетей и многих других вещей, которые вам всегда хотелось бы иметь под рукой при написании кодов, — все это содержится в библиотеках базовых классов.

2. Рисунки/формы. Библиотеки инструментов рисования и создания форм обеспечивают поддержку создания двумерных рисунков и богатого набора всевозможных форм и элементов управления, которые вы будете использовать при построении пользовательских интерфейсов.

3. Доступ к данным. Библиотеки доступа к данным предлагают модель реляционных таблиц, функционирующих в памяти, которая носит название ADO.NET и предназначена для работы с данными, созданными в памяти, загруженными из XML-документов или запрошенными из базы данных.

4. XML и Web-службы. В библиотеках этой категории содержатся средства, необходимые для работы с XML-документами и вызова Web-служб для обмена информацией между устройствами и серверами посредством XML и протокола SOAP.

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

Исполнительный механизм .NET Compact Framework и библиотеки классов проектировались таким образом, чтобы их можно было сравнительно легко переносить на устройства различных типов, работающие под управлением различных операционных систем. Одними из первых целевых устройств были те, которые работали под управлением операционных систем Windows СЕ 4.1, Pocket PC 2000/2002/2003 и выше, а также Microsoft Smartphone. В будущем возможна поддержка и других платформ, не относящихся к семейству платформ Windows.

Следует также отметить, что поскольку платформа .NET Compact Framework создавалась поверх стандартов ЕСМА и ISO для инфраструктуры общего языка (Common Language Infrastructure — CLI), то вполне возможно, что другие организации разработают собственные варианты реализации CLI для языков С# и VB.NET, ориентированные на различные типы устройств. В этих реализациях библиотеки базовых классов, вероятнее всего, останутся теми же, но высокоуровневые библиотеки в них могут быть другими. В настоящее время существует, по крайней мере, две реализации CLI от независимых производителей, предназначенные для настольных компьютеров и серверов.

Резюме

Современные многофункциональные мобильные устройства предоставляют разработчикам замечательные возможности для создания конкурентоспособного мобильного программного обеспечения. Программы для мобильных устройств способны украсить людям досуг, доставить им ценную информацию и облегчить принятие решений, а также увеличить производительность труда за счет того, что работа может выполняться не только за рабочим столом. Учитывая богатое разнообразие новейших технологий и возможностей, наше время можно считать поистине благодатным для разработчиков программного обеспечения.

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

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

Если выбран вариант многофункционального приложения, развернутого на локальном устройстве, то необходимо дать ответ также на следующий вопрос: "Следует ли создать приложение с использованием собственного кода или же с использованием среды выполнения управляемого кода?" Ответ по умолчанию подразумевает использование управляемого кода, поскольку в этом случае вы получаете существенный выигрыш в производительности и надежности, которые обеспечиваются современными средами, поддерживающими управляемый код.

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

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

ГЛАВА 2

Характеристики мобильных приложений

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

А.Н. Уайтхед (А.N. Whitehead, 1861-1947), английский математик и философ

(Encarta 2004, Quotations)

Введение

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

Данная глава должна подготовить необходимую для этого почву и приучить вас мыслить категориями "мобильности". От умения рассуждать с учетом специфики устройств зависит очень многое, поскольку это самым радикальным образом повлияет на ваш подход к проектированию приложений. Создание неординарных мобильных приложений требует хорошего понимания того, какие именно ключевые характеристики делают то или иное приложение действительно замечательным. В этой главе даются ответы на такие вопросы: "Чем именно отличается использование приложений для мобильных устройств от использования приложений для настольных компьютеров?" и "Каковы наиболее важные отличительные характеристики хороших мобильных приложений?"

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

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

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

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

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

Долговременные и кратковременные виды деятельности

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

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

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

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

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

Исследовательские и целевые виды деятельности

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

Хорошим примером подобного рода исследовательского подхода к обработке информации может служить просмотр Web-ресурсов на настольном компьютере. Обычные сетевые соединения с высокой пропускной способностью обеспечивают загрузку больших объемов информации на локальные носители. Это дает возможность загружать больше информации, чем требуется непосредственно в данный момент, просто на тот случай, если предложенная пользователю дополнительная информация может ему пригодиться. В результате загрузки пользователь, как правило, получает документ, насыщенный большим количеством ссылок на самую разнообразную информацию, которая, как предполагается, может предоставлять для него интерес. В процессе ознакомления с содержимым таких документов пользователи обычно переходят к другим, дополнительно указанным документам и часто открывают одновременно несколько окон, чтобы иметь возможность быстро переключаться между документами для нахождения нужной информации. С подобной ситуацией, например, сталкивался каждый, кто использовал Web для поиска вариантов приобретения авиабилетов со скидкой. В этом случае пользователь открывает сразу несколько окон, соответствующих Web-сайтам различных компаний-перевозчиков, в каждом из которых можно получить информацию о тарифах в зависимости от дат вылета и прилета. Из окон браузеров эту информацию часто копируют в электронные письма или другие документы. Если пользователь сталкивается с информационно-насыщенной Web-страницей с множеством ссылок, то предугадать его дальнейшие действия довольно-таки трудно.

Щелкнет ли пользователь на ссылке?

Введет ли он новый адрес в адресной строке браузера?

Будет ли пользователь копировать некоторую информацию из Web-страницы в другой документ?

Запустит ли он программу электронной почты или службу мгновенного обмена сообщениями?

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

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

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

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

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

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

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

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

Более пристальный взгляд на мобильные 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-просмотра для мобильных приложений всегда будут "приложениями-приманками", однако их эксклюзивность отличается от той, которая свойственна их аналогам для настольных компьютеров.

Форм-фактор

Ключевой и определяющей характеристикой большинства мобильных устройств являются их размеры. Этот физический фактор служит показателем полезности устройства — если оно способно уместиться в вашем кармане, значит оно полезно! Другими важными аспектами форм-фактора мобильных устройств являются следующие.

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

■ Возможность осуществлять управление устройством одной или двумя руками. Конструкция многих мобильных устройств обеспечивает возможность управления ими при помощи одной руки. Большинство мобильных телефонов удовлетворяют этому требованию. Некоторые устройства должны удерживаться в одной руке, а управляться другой. В эту категорию попадает большинство устройств PDA. Для эффективной работы с лэптопом обычно требуется использовать обе руки и иметь плоскую поверхность, на которую можно было бы поставить компьютер. Ваше приложение должно следовать той парадигме использования, которая налагается устройством, то есть, не следует создавать приложение, эффективная работа с которым возможна только при условии использования обеих рук, если оно предназначено для выполнения на мобильных устройствах, которыми обычно оперируют лишь одной рукой. Этот аспект является очень важным при уточнении сферы применения приложения. Другим важным фактором являются условия физического окружения, в которых приходится пользоваться микрокомпьютером. Возможности сенсорного дисплея создают богатейшую среду для переключения между приложениями, однако разработчики нередко создают и тестируют пользовательские интерфейсы либо запуская приложения на эмуляторах устройств, установленных на настольных компьютерах, либо сидя за рабочим столом. В результате этого пользовательские интерфейсы оказываются весьма далекими от того, что действительно требуется при использовании приложений в реальных условиях. В процессе реального использования приложений устройства могут находиться под воздействием толчков или вибрации, а людям часто хочется или приходится использовать свои устройства во время ходьбы или они предпочитают надавливать на экран пальцами, а не пером. Как ни парадоксально это звучит, но в условиях реального использования ввод данных посредством сенсорного экрана небольших мобильных устройств требует больших размеров элементов управления, нежели в случае стационарных приложений, установленных на персональных компьютерах. Важно определить, должно ли ваше приложение быть "дружественным к одной руке", "дружественным к перу" и требовать использования обеих рук или "дружественным к пальцу", если оно предназначено для использования на устройстве с сенсорным экраном и предусматривает возможность работы с ним во время движения пользователя.

■ Отсутствие необходимости в подключении силовых или сигнальных кабелей на длительное время. Чтобы эффективно выполнять свои функции, мобильные устройства не должны быть "привязанными" к чему-либо в течение длительных промежутков времени. Целесообразно руководствоваться общим правилом, в соответствии с которым устройства и выполняющиеся на них приложения не должны нуждаться в подключении к внешним источникам питания или кабельным коммуникационным линиям более одного раза в день. Насколько часто ваше приложение требует, чтобы устройство работало на полную мощность, а также насколько часто приложению требуется подключение к сетевым данным — это весьма важные факторы, которые следует учитывать при проектировании приложения.

Приведенные выше соображения относительно форм-факторов устройств должны самым серьезным образом учитываться вами при разработке проекта. Разрешение проблем, обусловленных особенностями форм-фактора устройства, а также адаптация программного проекта к различным форм-факторам потребует от вас принятия нестандартных технических решений.

Т9 — прекрасный пример остроумного технического решения, позволяющего преодолеть ограничения, свойственные мобильным устройствам

Редактор T9 позволяет быстро вводить текст на мобильных телефонах, имеющих стандартную 12-клавишную клавиатуру. До появления T9 пользователи, вводя текстовые предложения, должны были старательно нажимать на клавиши с цифрами от 1 до 9 вплоть до 4 раз, чтобы добиться ввода нужной буквы. В табл. 2.1 указаны суммарные количества нажатий, необходимые для ввода простого текста "text message" до и после появления T9.

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

Например, как r, так и s представлены на клавиатуре клавишей с цифрой 7. Если вы хотите ввести слово cars, вам придется выждать одну секунду после ввода r, чтобы программное обеспечение распознало окончание ввода этой буквы и переместило точку вставки в позицию следующей буквы, которая будет вводиться. Каждый, кто хотя бы однажды попробовал пользоваться обоими способами ввода в течение нескольких дней, уже никогда не вернется к старому способу, существовавшему до появления редактора T9.

Как это все работает? Статистика! Когда вы нажимаете клавиши 8, 3 и 9, программное обеспечение просматривает свой словарь и определяет, что единственными наиболее вероятными словами, которые вы могли вводить, являются слова vex и text, в связи с чем вам и предлагаются оба эти варианта. Когда вы нажимаете последнюю клавишу 8, программное обеспечение обнаруживает, что единственным из хранящихся в его словаре словом, согласующимся с набранной комбинацией, является слово text, которое вам и предлагается. Поддерживая словарь, содержащий слова и ключевые комбинации на вашем национальном языке, программное обеспечение может значительно повысить скорость написания коротких сообщений. Если вам необходимо выйти за пределы словарного запаса словаря, вы можете дополнить его вводом "неизвестных" слов, используя старый механизм ввода.

Годится ли такой способ для написания романа "Война и мир" с помощью мобильного телефона? Разумеется, нет, но он прекрасно подходит для ввода предложения "Только что закончил чтение романа 'Война и мир' — очень длинная книга!" и отправки его своему другу.

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

Таблица 2.1. Нажатия клавиш мобильного телефона, необходимые для ввода текста "text message"

Требуемая буква

Нажатия клавиш до появления Т9

Нажатия клавиш после появления Т9

Т

8, = t

8, = t

Е

3,3, = d,e

3, = е

X

9,9, = w,x

9, = х

T

8, = t

8, = t

<пробел>

1, = пробел

1, = пробел

M

6, = m

6, = m

E

3,3 = d,e

3, = e

S

7,7,7,7, = p,q,r,s

7, = s

S

7,7,7,7, = p,q,r,s

7, = s

А

2, = а

2, = а

G

4, = g

4, = g

E

3,3 = d,e

3, = e

Общее количество нажатий

22

12

Требования надежности

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

■ Во многом подобно серверам, мобильные устройства и их приложения нередко работают по 24 часа в сутки 7 дней в неделю. Сотовые телефоны и PDA часто работают в режиме постоянного включения или же для них предусмотрены режимы ожидания, гарантирующие, что после запуска устройства оно перейдет в состояние, аналогичное тому, в котором оно находилось при завершении последнего рабочего сеанса. Хотя и настольные компьютеры все чаще надолго оставляют во включенном состоянии, все же пользователи перезапускают их, начинают и заканчивают рабочие сеансы, не придерживаясь какой-либо определенной периодичности, а также довольно часто запускают и закрывают приложения, что время от времени приводит к сбросу ресурсов, необходимость в которых отсутствует. В противоположность этому, поскольку от мобильных приложений ожидается "мгновенная доступность", их часто оставляют выполняться в фоновом режиме, чтобы исключить периоды ожидания во время запуска и предоставить пользователям возможность продолжить работу с той точки, на которой она была прервана. По этой причине мобильные устройства похожи на серверы в том смысле, что они также должны всегда пребывать в состоянии готовности к немедленному предоставлению услуг своим клиентам.

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

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

■ Во время выполнения высокоприоритетных приложений многие мобильные устройства должны решать другие критически важные задачи. Если мобильный телефон окажется неспособным выполнять свои основные функции из-за аварийного завершения работы приложения, замедления реакции на действия пользователя, блокирования пользовательского интерфейса или иных причин, то разумеется, это доставит конечному пользователю мало радости. Для повышения надежности выполнения устройством своих основных функций в большинстве мобильных операционных систем предусмотрены различные уровни защиты, но если ваше приложение не организовано надлежащим образом, то вероятность снижения полезности устройства в отношении выполнения других функций не будет полностью исключена. В терминологии серверов подобные ситуации носят название "отказа в обслуживании" ("denial-of-service"). Как и серверы, многие мобильные устройства должны поддерживать ряд критических служб, которые должны быть доступны для пользователей в любое время.

В силу указанных причин очень важно, чтобы ваше мобильное приложение могло выполняться эффективно и бесперебойно в течение длительных периодов времени

Важные характеристики мобильных приложений

Сравнению и противопоставлению мобильных устройств и их приложений с их настольными и серверными аналогами мы отвели в этой главе достаточно много места и времени. Поэтому сейчас будет весьма уместно перечислить все то, что делает мобильное приложение по-настоящему качественным.

Время запуска

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

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

Отклик устройства

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

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

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

Фокусирование внимания на отдельных задачах

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

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

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

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

Настройка взаимодействия с внешними источниками информации

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

Единообразие стиля интерфейса

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

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

Различия в архитектуре компьютеров

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

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

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

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

В настольных компьютерах ОЗУ и долговременная память разделены. В то же время, в устройствах ОЗУ часто используются и как рабочая память приложений, и как промежуточная или долговременная память. В качестве долговременных хранилищ данных все чаще используется флэш-память, обычно в виде съемных карт памяти.

Некоторые простые подсчеты, касающиеся размеров памяти

Объем ОЗУ современных многофункциональных мобильных устройств достигает 64 Мбайт. ОЗУ такого объема часто разделяются на программное ОЗУ и виртуальную файловую систему. Предположим, что 32 Мбайт такого ОЗУ приходится на файловую систему, предназначенную для хранения всех долговременных данных, с которыми вы работаете (такими данными могут быть фотографии, документы, музыка или другая информация). При этом в совместном распоряжении операционной системы и приложений остается 32 Мбайт. Допустим, что одновременно выполняются пять приложений (не столь уж редкая ситуация), каждое из которых использует примерно одинаковый объем ОЗУ, а сама операционная система использует те же ресурсы, что и отдельное приложение. В результате этого на каждое приложение приходится примерно 5-6 Мбайт ОЗУ. Хотя этот объем памяти и значителен, он далеко не бесконечен. Несколько крупных цифровых фотографий, перенесенных в память, израсходуют большую часть ОЗУ. Многие мобильные устройства располагают значительно меньшими рабочими объемами ОЗУ, а количество одновременно запускаемых приложений в реальных случаях может превышать то, которое мы использовали выше в качестве примера. Доступный на устройстве объем ОЗУ устанавливает абсолютный предел, превышение которого невозможно ни при каких обстоятельствах. Если имеющаяся физическая память устройства истощена, объекты не будут перемещаться в страничный файл, как это было бы в случае настольных компьютеров. Вероятнее всего, приложение израсходует всю доступную память и закончится аварийно.

Несколько мегабайт доступного рабочего пространства — это не так уж плохо при условии их эффективного использования, аналогично тому, как однокомнатная квартира на Манхэттене способна предоставить довольно много свободного места, если не забивать ее разным хламом. Стоит только перестать контролировать заполнение квартиры вещами, как очень быстро будет достигнуто критическое состояние, при котором в комнату больше ничего нельзя будет внести, и в ней останется ровно столько места, чтобы его едва хватало для перемещения в пределах квартиры. Будучи набитой лишними вещами, ваша комната станет бесполезной. Аналогичные соображения применимы и в случае мобильных устройств.

Резюме

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

Малое время запуска, способность к быстрому отклику и целевая ориентация — вот отличительные признаки качественно спроектированного мобильного приложения. Будучи вместе взятые, эти факторы формируют в процессе использования мобильных устройств высокопроизводительную пользовательскую среду. Всегда помните об этом, когда проектируете создаете и тестируете свои приложения для мобильных устройств.

С точки зрения компьютерной архитектуры мобильные устройства отличаются от настольных компьютеров и лэптопов тем, что в своем большинстве они не оборудуются жесткими дисками и их ОЗУ используются как для выполнения программ, так и для хранения файлов. В настоящее время появляется все больше устройств, в которых для долговременного хранения файлов может использоваться флэш-память. Флэш-память обеспечивает неплохие возможности для организации долговременного хранения данных, но обычно она не может быть использована для расширения программного ОЗУ, как это делается в настольных компьютерах, в которых для расширения виртуальной памяти используются страничные файлы на дисках. Отсюда следует, что в случае мобильных устройств эффективное управление памятью имеет гораздо большее значение, чем в случае настольных компьютеров, в силу значительной ограниченности объема ОЗУ, используемого для выполнения программ.

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

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

ГЛАВА 3

Внутренняя структура .NET Compact Framework

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

Виктор Папанек (Victor Papanek) (американец австрийского происхождения, дизайнер, преподаватель, писатель. 1925-1998)

(Encarta 2004, Quotations)

Введение

В этой главе предлагается концептуальное объяснение принципов функционирования .NET Compact Framework и других сред времени выполнения управляемого кода. Благодаря этому разработчики, создающие приложения для мобильных устройств на основе управляемого кода, будут хорошо представлять себе, каким образом их приложения работают в средах с управляемым кодом. Тем, кто создает приложения с использованием собственных кодов, знание стратегий проектирования, применяемых в средах времени выполнения управляемого кода, поможет создавать приложения для мобильных устройств, отличающиеся высоким быстродействием и экономным расходованием памяти.

Вообще говоря, программное обеспечение, созданием которого занято большинство разработчиков, можно разделить на три категории:

■ Приложения. Приложение (application) представляет собой компьютерную программу, с которой взаимодействует конечный пользователь. Эта программа либо запускается для обслуживания конкретных запросов конечного пользователя, либо предоставляет услуги конечным пользователям. Проектные решения принимаются исходя из того, насколько полезными они будут для конечного пользователя. В данной книге под "приложениями" будут пониматься графические приложения с развитым пользовательским интерфейсом.

■ Повторно используемые компоненты. Повторно используемые компоненты (reusable components) представляют собой модульные фрагменты кода, которые разработчики могут использовать для ускорения процесса создания приложений. При создании компонентов проектные решения принимаются исходя из того, чтобы облегчить их повторное использование разработчиками, создающими приложения. С точки зрения технической, в отношении проектного формализма компоненты занимают промежуточную позицию между приложениями и каркасами приложений. Повторно используемые компоненты могут быть либо графическими, либо "безликими", в том смысле, что в них отсутствует код пользовательского интерфейса. Типичные компоненты содержат несколько крупных основных классов, для поддержки которых предусматриваются меньшие классы. Хорошим примером повторно используемых компонентов может служить модуль построения графических диаграмм. Один и тот же хорошо спроектированный модуль может использоваться одновременно несколькими различными приложениями. В таком модуле может иметься один "диаграммный" класс и несколько меньших вспомогательных классов, представляющих такие характеристики диаграмм, как отображаемые данные, информация об осях и цветовые параметры линий диаграмм.

■ Каркасы приложений. Каркасы, или скелеты (остовы) приложений (frameworks) — это формализованные, тщательно спроектированные и организованные деревья объектов. Каркасы приложений призваны играть роль фундамента, на котором можно строить приложения и компоненты. При создании каркасов приложений значительные усилия направляются на разработку логической организации деревьев объектов, содержащихся в каркасе, чтобы в своей совокупности они составляли одно взаимосвязанное целое. Это объясняется тем, что каркасы приложений должны упрощать решение как можно более широкого круга задач программирования. Обычно каркасы состоят из многочисленных классов небольшого или среднего размера, которые разработчики могут многократно использовать для решения стоящих перед ними задач. Хотя граница, разделяющая каркасы приложений и компоненты, довольно условна, компонентами, как правило, считаются программные единицы, которые удовлетворяют конкретные потребности приложений, тогда как к каркасам приложений обычно относят более универсальные наборы инструментов проектирования. Примером среды, ориентированной на разработку приложений на основе каркасов приложений, является .NET Compact Framework.

В действительности .NET Compact Framework представляет собой нечто большее, чем просто каркас для создания приложений. Это одновременно и программный каркас (programming framework), который разработчики могут использовать для создания мобильных приложений, компонентов и высокоуровневых каркасов, и исполнительный механизм (execution engine), который может получать откомпилированные приложения и запускать их в управляемой среде выполнения. Для этого исполнительного механизма существует и другое распространенное название — среда времени выполнения (runtime).

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

■ На обеспечении каких возможностей остановили свой выбор разработчики платформы, и какие проектные решения были приняты в процессе разработки .NET Compact Framework? Несмотря на наличие между ними множества общих черт, каждая из сред времени выполнения для мобильных устройств имеет свои особенности, зависящие от возможных сценариев использования конечного продукта, на которые ориентировался проект. Все среды времени выполнения, предназначенные для мобильных устройств, оптимизируются для эффективного выполнения программ небольшого размера, но для каждой из технологий сред выполнения существуют определенные области, в которых с целью расширения набора функциональных возможностей приходится сознательно идти на увеличение размера программ и объема потребляемых ресурсов. Соответствующие знания будут полезны как разработчикам приложений, так и разработчикам системных архитектур, которые должны принимать решения относительно того, какие возможности мобильной среды времени выполнения, выбранной для разработки, могут им понадобиться, будь то .NET Compact Framework, J2ME или любая другая среда времени выполнения для мобильных устройств.

■ В частности, какова архитектура .NET Compact Framework? Ответ на этот вопрос будет интересовать тех разработчиков приложений и системных архитектур, которые планируют создавать каркасы приложений на основе управляемых сред времени выполнения, поскольку это облегчит им понимание того, какие аспекты проектирования с использованием сред времени выполнения для мобильных устройств являются ключевыми.

■ Какие характеристики важны для достижения максимальной производительности приложений, компонентов и каркасов, построенных на основе .NET Compact Framework? Это представит интерес для каждого разработчика, использующего для создания кодов управляемую среду времени выполнения .NET Compact Framework.

Как проектировалась .NET Compact Framework

Залогом успешного решения любой технической задачи является предварительное определение общих целей, к достижению которых следует стремиться в процессе работы над проектом. Было бы неправильно сказать, что все основные идеи, относящиеся к проекту .NET Compact Framework, зародились в одной голове, поскольку это не соответствовало бы действительности. Идеи проекта .NET Compact Framework явились результатом бурных споров между основными участниками группы разработки инструментальных средств и сред выполнения, каждый из которых горячо отстаивал свое мнение. Одни из них придерживались той точки зрения, что самое главное — это добиться максимально возможного уменьшения размера кода. Другие ставили во главу угла обеспечение межплатформенной совместимости кода. Часть членов группы считала, что ключом к завоеванию рынка будет создание прикладных систем уровня предприятия для Pocket PC. Каждая из этих идей тщательно изучалась, сопоставлялась с другими идеями и сразу же апробировалась в ходе лабораторных испытаний, проводимых группой целевых разработчиков. Благодаря сотрудничеству с независимыми разработчиками, которые в ходе указанных лабораторных испытаний использовали уже самые первые из созданных нами кирпичиков для построения реальных мобильных приложений, нам удалось многое выяснить относительно того, что именно является наиболее важным, обязательно необходимым или же просто желательным для сред времени выполнения, ориентированных на мобильные устройства.

Эта обратная связь определяла наши действия на протяжении всей первой фазы нашего многолетнего процесса разработки, и мы глубоко благодарны всем тем, кто предоставил нам бесценную информацию, выполняя тестирование первоначальных результатов нашего труда. Их независимые суждения позволили нам уточнить, доработать и отшлифовать базовые принципы, которые следовало использовать для доведения проекта до его полного завершения. После согласования основных целей проекта началась вторая фаза процесса разработки, обеспечившая практическую реализацию этих идей, их уточнение, а в необходимых случаях и внесение поправок в промежуточный продукт для достижения разумного компромисса между взаимно конкурирующими требованиями к размеру, производительности и возможностям программного кода. Увенчавшим наши усилия конечным результатом в виде версии 1.1 платформы .NET Compact Framework мы были весьма удовлетворены. В случае мобильных устройств описанный итеративный характер процесса проектирования играет особенно важную роль по той причине, что в разработке программного обеспечения для устройств накоплен пока еще гораздо меньший опыт, чем в случае настольных компьютеров или серверов. Мобильные устройства стали использоваться в качестве гибких прикладных платформ сравнительно недавно, и многие разработчики только пытаются разглядеть свой путь при слабом утреннем свете нового дня; итеративный подход с учетом обратной связи с пользователями приобретает в этих условиях особое значение. К вопросу о том, как придать итеративный характер процессу проектирования, мы будем постоянно возвращаться на протяжении всей этой книги.

Ниже, в порядке уменьшения степени важности, перечислены основные критерии, которым должна была удовлетворять первая версия .NET Compact Framework.

1. .NET Compact Framework необходимо было создавать как подмножество разработанной ранее для настольных компьютеров и серверов среды .NET Framework, совместимое с последней па уровне двоичных кодов и удовлетворяющее требованиям стандартов. На разработку среды .NET Framework, ориентированной на настольные компьютеры и серверы, были затрачены большие усилия, и не воспользоваться достигнутыми результатами было бы просто глупо. К тому же, значительная часть этих результатов, включая двоичный формат откомпилированных приложений (IL), язык программирования С# и библиотеки базовых классов программного каркаса, уже была подана на рассмотрение в органы стандартизации (ЕСМА-334 и ЕСМА-335, ISO/IEC 23270 (С#), ISO/IEC 23271 (CLI) и ISO/IEC 23272) и утверждена. При создании .NET Compact Framework ставилась явная задача реализации этих стандартов, а вместе с этим и использования языковых компиляторов .NET. Возможность использования уже прошедших всестороннюю апробацию и доказавших свою работоспособность компиляторов С# и VB.NET для создания приложений на платформе .NET Compact Framework наряду с привлечением большого количества инструментальных средств проектирования, тестирования и отладки, уже доступных для разработки программного обеспечения на настольных компьютерах и серверах, делали этот путь гораздо более надежным и технически эффективным, чем разработка нового варианта реализации указанных средств с нуля.

2. Межплатформенные возможности. Хотя первые реализации среды .NET Compact Framework предназначаются для операционных систем Pocket PC, Windows CE и Microsoft Smartphone, сама она была спроектирована таким образом, чтобы при необходимости ее можно было переносить на другие платформы. Одним из практических следствий такого проектного решения является тот факт, что все вызовы из .NET Compact Framework, затрагивающие базовую операционную систему, осуществляются через единый интерфейс — PAL (platform abstraction layer — уровень абстракции платформы). Это упрощает учет зависимостей базовой операционной системы в процессе проектирования и облегчает задачу переноса среды времени выполнения и библиотек в другие операционные системы. Отсюда вовсе не следует, что перенос программного обеспечения в другую операционную систему не будет представлять никакой сложности лишь по той единственной причине, что этот аспект был учтен в процессе проектировании .NET Compact Framework. Например, в некоторых операционных системах часть функциональных средств, на которые отображается PAL, может отсутствовать, в связи с чем необходимо, чтобы PAL для этой платформы реализовал такие возможности, как многопоточное выполнение, управление памятью, создание графических объектов или иную функциональность, которую целевая операционная система предоставить не может. Решение подобной задачи может оказаться весьма непростым, но оно сводится к хорошо известному и проверенному процессу, который не был упущен из виду в процессе проектирования .NET Compact Framework.

3. Мощные возможности клиентской стороны, включая поддержку рисования и форм, выполнение функций клиента Web-служб и предоставление модели доступа к данным, обладающей широкими возможностями. Мы пришли к выводу, что для того, чтобы среда времени выполнения для устройств воспринималась разработчиками прикладных программ как конкурентоспособная, она должна удовлетворять нескольким ключевым требованиям. Прежде всего, требовалось, чтобы она обеспечивала создание пользовательских интерфейсов с широким набором возможностей, предоставляющих современные элементы управления, к которым разработчики уже успели привыкнуть (например, сетки, списки и древовидные представления). Далее, она должна была обеспечивать ту же простоту использования Web-служб приложениями, что и в случае .NET-приложений, выполняющихся на настольных компьютерах (то есть делать эту задачу тривиальной) Кроме того, она должна была предоставлять современную, расширяемую модель для работы с базами данных (ADO.NET), обеспечивающую самые широкие возможности. Поддержка всех вышеперечисленных средств была реализована в библиотеке объектов .NET Compact Framework.

4. Низкие требования к объему установленной на устройстве и занимаемой платформой памяти. Для того чтобы иметь практические шансы пробиться на массовый рынок устройств с типичными размерами образов ПЗУ (ROM images), наша система должна была занимать не более 2 Мбайт памяти. Возможность размещения в образе ПЗУ с типичным для массовых устройств объемом рассматривалась нами как неотъемлемая характеристика платформы для мобильных устройств. Чтобы облегчить решение этой задачи, не менее важно было обеспечить возможность установки платформы в файловых системах ОЗУ существующих устройств таким образом, чтобы оставалось еще достаточно много места для приложений и данных. Для решения обеих задач требовалось, чтобы необходимый для платформы объем памяти, используемой на устройстве, не превышал 2 Мбайт. Кроме того, .NET Compact Framework должна была сохранять работоспособность и в средах, в которых действуют жесткие ограничения в отношении доступных объемов ОЗУ. Эти цели значительно отличаются от тех, которые ставились при разработке платформы .NET Framework для настольных компьютеров и серверов, ориентированной на выполнение в условиях сред с достаточными запасами ресурсов, когда достижение максимальной пропускной способности имело намного более высокий приоритет по сравнению с минимизацией объема памяти, занимаемого платформой.

5. Требовалось предоставить практическую поддержку, по крайней мере, двух языков .NET — С# и Visual Basic .NET. Хотя с теоретической точки зрения коды на любом из языков программирования, ориентированных на стандартизированное подмножество байтовых кодов IL и стандартизированное множество библиотек программ .NET Compact Framework (ЕСМА и ISO), должны быть способными к компиляции для выполнения на платформе .NET Compact Framework, это необходимо было подтвердить на практике путем фактической реализации нескольких языков. Мы выбрали языки С# и Visual Basic, поскольку они являются наиболее популярными языками .NET. Как и в случае варианта реализации для настольных компьютеров и серверов, это подразумевало включение в .NET Compact Framework библиотеки времени выполнения Microsoft.VisualBasic.DLL.

6. Платформа должна была служить удобной заменой собственных кодов для большинства приложений коммерческого, научного, производственного и развлекательного характера. Было очень важно, чтобы разработчики программного обеспечения для настольных компьютеров и серверов не испытывали никаких неудобств в работе или ограничений с точки зрения синтаксиса при переходе к платформе .NET Compact Framework. Если бы эта цель не была достигнута, то количество разработчиков указанной категории, пожелавших совершить такой переход, было бы значительно меньше, нежели то, на которое мы рассчитывали. Такой урок можно было извлечь из предыдущих попыток создания сред времени выполнения, ориентированных на устройства, которым не удалось достигнуть "критической массы". Как проект Embedded Visual Basic компании Microsoft, так и аналогичные проекты других компаний не оправдали ожиданий, поскольку в них не был предусмотрен ряд ключевых возможностей, которые обычно используются при создании программного обеспечения для настольных компьютеров и серверов или в случае применения собственных кодов при разработке программного обеспечения для устройств. Мы исходили из того, что при любой успешной замене подхода, основанного на использовании собственных кодов, любой другой предлагаемый подход должен поддерживать следующие возможности:

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

• Все базовые элементы языков программирования и широко используемые библиотеки программ. Мы не могли исключить ни такие предоставляемые любым современным объектно-ориентированным языком программирования возможности, как механизм наследования или обработка структурных исключений, ни такие низкоуровневые библиотечные функции, как функции ввода-вывода файлов, основанные на потоках. Разработчик рассчитывает на то, что эти средства программирования будут всегда находиться у него под рукой, и в случае их отсутствия у него возникает чувство, будто его лишили самого необходимого, тогда как он должен всегда работать в комфортных условиях и быть во всеоружии.

7. Возможность доступа к средствам базовой операционной системы, если в этом возникает необходимость. Осознав всю важность фактора межплатформенной переносимости, мы поняли, что разработчики не должны быть ограничены доступом только к тем средствам, которые были нами первоначально запланированы. Наша основная задача заключалась в том, чтобы предоставить разработчикам удобное подмножество средств платформы .NET Framework, предназначенной для настольных компьютеров, которое было бы пригодным для создания тех видов приложений, о которых говорили сами разработчики, однако можно было предполагать, что неизбежно возникнут случаи, когда предусмотренной нами функциональности разработчикам окажется мало. Какой смысл в том, чтобы предоставлять разработчику возможность создать 90 процентов мобильного приложения с использованием управляемого кода, если он зайдет в тупик из-за недостатка необходимых средств при создании остальных 10 процентов приложения. Поэтому предоставление разработчикам удобного способа, обеспечивающего возможность вызова собственных кодов, было сочтено важным фактором, позволяющим разработчикам обойти трудности, связанные с отсутствием в .NET Compact Framework той или иной функциональности. Вот четыре примера: в настоящее время вызовы собственных кодов (или поставляемых независимыми разработчиками библиотечных функций, служащих оболочками для вызовов собственных кодов) нужны для явного управления сетевыми соединениями, набора телефонных номеров, воспроизведения звука и доступа к API-интерфейсам шифрования; эти функциональные возможности требуются далеко не каждому разработчику, но те, кому они действительно необходимы, будут чувствовать себя стесненными в своих действиях, если не смогут получить доступ к указанным средствам из-за невозможности использования вызовов собственных кодов

Чем объясняется присвоение первому выпуску NET Compact Framework номера версии 1.1, а не 1.0?

Дотошный читатель мог заметить, что при ссылках на первый выпуск .NET Compact Framework в качестве номера версии используется не номер 1.0, а номер 1.1. На то имеются свои основания.

Первый выпуск .NET Compact Framework проектировался так, чтобы обеспечивалась его совместимость с версией 1.1 .NET Framework для настольных компьютеров и серверов, и предполагался к поставке одновременно с ней. Версия 1.0 .NET Framework поставлялась в 2002 году вместе с Visual Studio.NET 2002. Версия 1.1 .NET Framework и NET Compact Framework поставлялись вместе с Visual Studio .NET 2003. В согласии со смыслом номеров версий, номер 1.1 соответствует младшему выпуску продукта, функциональность которого обновлена по сравнению с версией 1.0.

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

Заранее приносим свои извинения за возможные недоразумения по этому поводу.

.NET Compact Framework как подмножество платформы для настольных компьютеров

Приступая к проектированию .NET Compact Framework, мы знали, что в конечном счете должны получить некое совместимое подмножество среды .NET Framework, предназначенной для настольных компьютеров, которое удовлетворяло бы требованиям разработчиков. Вопрос о том, каким именно образом следовало определить это подмножество, стал предметом серьезного обсуждения. Следует ли отталкиваться от платформы .NET Framework, постепенно исключая из нее все то, что не нужно, или же лучше начать проектирование новой платформы с нуля, включая в нее только те средства, которые являются действительно необходимыми? Будучи не в состоянии решить эту философскую дилемму, мы остановились на том, чтобы использовать оба подхода и посмотреть, какой из них окажется более приемлемым. Такой способ действий требовал большего времени и ресурсов, однако, по моему мнению, только с его помощью и можно было окончательно разрешить указанные разногласия. Действуя в направлении сверху вниз, мы могли определить максимальный состав тех ключевых возможностей, поддержку которых мы хотели бы обеспечить, тогда как подход, соответствующий продвижению снизу вверх, позволял нам составить хорошее представление о том, какой может быть минимальная реализация и как влияет на размерные показатели и производительность добавление тех или иных возможностей. (Ради справедливости замечу, что лично я принадлежал к числу тех проигравших участников дебатов, которые рекомендовали использовать для создания библиотек программ разработку в направлении сверху вниз. Эта модель оказалась полезной в отношении понимания того, что же именно мы хотим создать, но не могла обеспечить необходимую производительность. Единственным путь, гарантирующий достижение этой цели, был связан с осуществлением разработки по принципу "снизу вверх".)

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

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

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

При проектировании сред выполнения управляемого кода возможны два подхода:

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

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

Везде, где только это было возможно, функциональность .NET Compact Framework реализовывалась за счет управляемого кода; с использованием собственных кодов написано лишь 20-30 процентов общего объема кода .NET Compact Framework. Для написания всех библиотек программ применялся управляемый код. Лишь сам исполнительный механизм и небольшая часть графической подсистемы написаны с использованием собственных кодов.

Использование управляемого кода во всех библиотеках программ позволяет осуществлять их загрузку и компиляцию, а также управление памятью теми же методами, что и в случае любых других библиотек. Схема логического разделения .NET Compact Framework на отдельные составляющие, написанные с использованием управляемого и собственного кодов, представлена на рис. 3.1.

Рис. 3.1. Компоненты .NET Compact Framework, написанные с использованием собственного и управляемого кодов

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

Исполнительный механизм NET Compact Framework представляет собой низкоуровневый код, отвечающий за загрузку, JIT-компиляцию и выполнение управляемого кода, а также управление памятью. Ему приходится брать на себя всю черновую работу, обеспечивающую выполнение управляемого кода.

Исполнительный механизм написан на языках C/C++ и компилируется в собственные команды процессора. На этот механизм дополнительно возлагается задача трансляции .NET Compact Framework и приложений конечного пользователя в исполняемый формат во время выполнения. Этот процесс известен под названием JIT- компиляции (just-in-time — оперативная). С помощью этого же механизма обрабатываются любые переходы из управляемого кода в собственный код, например, вызовы функций основанного на собственном коде API-интерфейсов базовой операционной системы; этот процесс называется переключением (thunking).

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

Библиотеки управляемого кода

Библиотеки управляемого кода .NET Compact Framework являются той программной частью, с которой взаимодействуют разработчики. Как и в случае варианта .NET Framework для настольных компьютеров, библиотеки .NET Compact Framework размещены в нескольких DLL-файлах. Эти библиотеки присутствуют на настольных компьютерах во время проектирования, а также устанавливаются на целевых устройствах для использования во время выполнения.

Для работы с этими библиотеками во время проектирования используются имена System.DLL, Systems.Windows.Form.DLL и System.Xml.DLL. На устройствах эти файлы могут иметь другие имена в зависимости от потребностей целевых устройств, связанных с именованием и учетом версий файлов. В процессе компиляции библиотеки управляемого кода используются аналогично тому, как заголовочные файлы используются компиляторами C/C++ или библиотеки типов используются прежними (полученными с применением VB6 и более ранних версий) кодами на языке Visual Basic для передачи информации об интерфейсах и типах, используемых компилируемым кодом.

Тот факт, что эти файлы имеют то же DLL-расширение, что и файлы библиотек собственных кодов C/C++, объясняется исключительно желанием сохранить привычный подход к именованию файлов; природа их двоичного содержимого совершенно другая, и в состав их имен с равным успехом может быть включено любое другое удобное расширение. То, что имена файлов .NET Compact Framework обычно совпадают с именами соответствующих файлов .NET Framework, также объясняется только соображениями удобства. В действительности эти файлы могут быть дополнительно разделены на еще большее количество файлов или объединены в один файл, если в этом возникнет необходимость. В будущих реализациях для систем, отличных от Windows, может быть выбран именно такой вариант, если это окажется более предпочтительным.

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

С точки зрения программирования каждый из этих DLL-файлов предоставляет разработчику набор иерархических пространств имен, содержащих классы и типы. Примерами пространств имен, содержащих классы и типы, могут служить:

System.*

System.Xml.*

System.Data.*

System.Drawing.*

и тому подобные.

DLL-файлы и пространства имен связаны между собой отношениями типа "многие ко многим"; один DLL-файл может предоставлять имена сразу для нескольких пространств имен (например, если это потребуется, файл Foo.DLL может содержать типы, относящиеся как к пространству имен MyNamespace.*, так и к пространству имен SomeOtherNamespace.SomethingElse.*), а несколько DLL-файлов могут предоставлять имена для одних и тех же пространств имен (например, при необходимости одновременно оба файла Foo.DLL и Bar.DLL могут предоставлять типы для пространств имен MyNamespace.* и SomeOtherNamespace.SomethingElse.*). Во время компиляции приложения компилятору передается набор имен файлов, подлежащих просмотру с целью поиска классов и типов, которые пользователь намеревается применять в своем приложении; эти имена принято называть ссылками (references). Если в коде разработчика или библиотеках, на которые имеются ссылки, некоторые типы/методы/свойства найти не удается, генерируется сообщение об ошибке времени компиляции. Кроме того, в случае обнаружения нескольких версий типов в разных библиотеках также генерируется сообщение об ошибке времени компиляции, связанной с неоднозначностью определения типа.

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

Библиотеки базовых классов

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

■ Все основные типы данных, к которым, например, относятся целые числа, строки, числа с плавающей запятой, дата/время, массивы и коллекции.

■ Средства файлового ввода-вывода, потоки, сетевые сокеты.

■ Средства поиска типов, методов и свойств в сборках и привязки к ним во время выполнения. Эти возможности называют отображением (reflection).

■ Средства, позволяющие учитывать в приложениях региональную и местную специфику. Эти возможности называют глобализацией (globalization).

Вышеперечисленные функциональные возможности вместе с дополнительными базовыми классами инкапсулированы в следующих иерархических пространствах имен:

System.*

System.Collections.*

System.ComponentModel.*

System.Diagnostics.Globalization.*

System.IO.*

System.Net.Sockets.*

System.Security.*

System.Text.*

System.Threading.*

Библиотеки пользовательского интерфейса

При создании библиотек пользовательского интерфейса преследовались две цели: 1) предоставить разработчикам возможность создавать многофункциональные приложения уровня предприятия с использованием таких современных высокоуровневых элементов управления пользовательского интерфейса, как Button, PictureBox, ListView, TreeView, TabControl и так далее, и 2) предоставить разработчикам возможность выполнения низкоуровневых операций рисования на мобильных устройствах с использованием расширенного набора операций для обработки растровых изображений, позволяющего рисовать такие, например, двумерные объекты, как линии, многоугольники, текст и изображения.

Описанные функциональные возможности предлагаются в двух иерархических пространствах имен:

■ System.Drawing.* — средства создания двумерных рисунков.

■ System.Windows.* — элементы управления пользовательского интерфейса и вспомогательные функциональные средства.

Библиотеки клиентов Web-служб

Web-службы — стандартный способ организации связи между приложениями, выполняющимися на различных платформах. По существу, сервер Web-службы — это Web-сервер, предоставляющий приложениям программные интерфейсы, для доступа к которым в качестве языка общения используется XML. Синтаксис такого общения на языке XML определяется протоколом SOAP, название которого представляет собой аббревиатуру от Simple Object Access Protocol — простой протокол доступа к объектам. Клиент Web-службы — это приложение, которое может осуществлять вызовы с целью создания запросов, посылаемых серверам Web-служб, и интерпретировать получаемые ответные сообщения SOAP. Для описания предоставляемых интерфейсов серверы Web-служб в ответ на соответствующий запрос возвращают WSDL-документы. WSDL — это аббревиатура от Web Service Description Language (язык описаний Web-служб), и, подобно SOAP, этот язык представляет собой синтаксис, построенный поверх XML. WSDL описывает предоставляемый Web-службой программный интерфейс; для создания запросов этих интерфейсов используется протокол SOAP.

Ключевой особенностью платформы .NET Framework для настольных компьютеров и серверов, равно как и инструмента разработки Visual Studio .NET, является простота создания Web-служб и получения соответствующих услуг. В Visual Studio .NET предусмотрена возможность синтаксического анализа WSDL-документов и генерации простых в использовании клиентских классов-заместителей (proxy classes), при помощи которых разработчики могут получать доступ к Web-службам. Благодаря наличию упомянутых классов-заместителей вызов Web-службы концептуально сводится к простой процедуре создания объекта и вызова его метода.

При проектировании .NET Compact Framework специально ставилась задача поддержки достаточно многофункционального набора классов, свойств и методов, обеспечивающих компиляцию вышеупомянутых клиентских классов-заместителей, автоматически генерируемых Visual Studio .NET. Эта задача была успешно решена, и теперь организовать работу приложений на мобильных устройствах в качестве клиентов Web-служб столь же просто, как и в случае их аналогов, выполняющихся на настольных компьютерах и серверах.

Функциональные средства этой категории предоставляются пространством имен System.Net.*.

Библиотеки XML

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

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

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

XML предлагает достижение разумного компромисса между чрезмерно сложным и чрезмерно упрощенным подходами к структуризации информации. Такое наполовину структурированное хранение данных обеспечивает значительные преимущества по сравнению с обычными текстовыми файлами. Данные сохраняются в иерархическом текстовом формате с использованием дескрипторов (tags), предоставляющих информацию о структуре содержимого. Например, информация о шрифте может быть сохранена посредством фрагмента текста <Font> ххх </Font>, который позволяет приложению, интерпретирующему текст, легко определить, что означает этот элемент данных. Приложения, работающие с XML-данными, могут выбирать лишь те порции текста, которые представляют для них интерес или смысл которых для них понятен. Таким образом, XML является важным усовершенствованием по сравнению с предыдущими текстовыми форматами, такими как файлы *.INI, контейнеры PropertyBag или HTML-текст, так как обеспечивает одновременно и больший объем структурной информации, и большую гибкость.

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

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

Для работы с XML-документами в .NET Compact Framework предлагается двухуровневый подход:

■ Средства однонаправленного чтения и записи XML-документов. Для максимально быстрого выполнения однонаправленного (forward-only) чтения/записи XML-документов без применения кэширования используются классы XmlReader и XmlWriter. Задачей этих классов является чтение или запись XML-данных соответственно из потоков или в потоки с поддержкой лишь минимально необходимого объема информации о состоянии. Этими возможностями могут воспользоваться разработчики, имеющие дело с XML-документами большого объема, когда на первый план выступает необходимость обеспечения высокой производительности приложений.

■ XML DOM (Document Object Model — объектная модель документов). Класс XmlDocument используется для представления создаваемого в памяти дерева объектов, описывающего XML-документ. XmlDocument и связанные с ним классы представляют объектную модель документов, обеспечивающую легкий доступ к элементам представляемых деревьев XML. Документ считывается только в прямом направлении с использованием обсуждавшегося выше класса XmlReader, на основании чего создается дерево элементов, представляющее XML-документ в памяти. Аналогичным образом, данные из XML-дерева могут быть записаны в поток; для выполнения этой задачи используется класс XmlReader. Возможности класса XmlDocument больше всего подходят тем разработчикам, которые либо имеют дело с XML-документами небольших или средних размеров, либо хотят вносить как можно меньше усложнений при работе с XML-документами

Концептуально соответствующая функциональность концептуально представлена в пространстве имен System.Xml.*.

Библиотеки данных

Данные в современных базах данных хранятся в виде наборов взаимосвязанных таблиц. Для работы с реляционными данными такого рода в NET Framework предлагается объектная модель под названием ADO.NET. Модель ADO.NET предоставляет в распоряжение разработчиков классы, позволяющие управлять в памяти набором связанных между собой реляционных таблиц, а также классы, обеспечивающие различные представления этих данных. О данных, для управления которыми используется модель ADO.NET, говорят, что они находятся в объекте DataSet.

В чем состоит разница между 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.

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

■ Сохранение внесенных текущих изменении в базах данных. Интерфейс между объектами ADO.NET DataSet и базами данных обеспечивается классом DataAdapter. Классы DataAdapter получают список добавлений, обновлений и удалений, относящийся к DataSet, и применяют соответствующую логику для распространения этих изменений на основную базу данных. Обычно это делается путем выполнения SQL-операторов или вызова хранимых процедур, предназначенных для работы с базой данных.

■ Сохранение данных в виде XML-документа. Объекты DataSet можно сериализовать в документы XML и сохранять в виде файлов с возможностью их последующей повторной загрузки.

■ Пересылка данных другому звену. Поскольку объекты DataSet, включая информацию о внесенных в них изменениях, без труда переводятся в форму постоянно существующих XML-документов, можно легко осуществлять их передачу между различными звеньями вычислительной системы посредством вызовов Web-служб.

■ Локальное использование данных. Объекты DataSet можно использовать как мощную абстракцию для работы с базами данных в памяти. Если эти данные предназначены только для чтения то внесенные в них локальные изменения не распространяются на данные, расположенные на сервере или в долговременном хранилище.

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

Управляемый код может содержать большое количество информации, которая может быть полезной для разработчиков при отладке каркасов, компонентов и приложений. В качестве примера подобных данных, привносящих добавленную стоимость, можно привести текстовые описания возможных исключений, которые возникают в процессе выполнения кода. Одно дело, когда сообщения об ошибках выводятся в виде малоинформативных фраз наподобие "Неизвестное исключение" или "Возбуждено исключение System.IO.SomeRandomException", и совершенно другое, когда вы получаете понятное простому смертному сообщение, подробно описывающее суть происшедшего и его наиболее вероятную причину. Информация подобного рода полезна на стадиях тестирования и отладки, но при разработке таких крупных проектов, как NET Compact Framework, для хранения всех строк сообщений об ошибках может потребоваться слишком много места, что в случае мобильных устройств является непозволительной роскошью.

.NET Framework для настольных компьютеров просто включает в себя обширную информацию об исключениях наряду с другими ресурсами. Эта информация доступна не только на английском, но и на многих других основных языках, для которых была выполнена локализация Visual Studio; это означает, что конечные пользователи имеют возможность получать богатую диагностическую информацию на своем родном языке. Чтобы обеспечить доступ к этой информации программным путем, каждое исключение управляемого кода имеет свойство .Message, открывающее программный доступ к соответствующему тексту.

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

В .NET Compact Framework эта проблема решается за счет разбиения указанной информации на отдельные вспомогательные компоненты не входящие в базовый состав NET Compact Framework. Эти вспомогательные компоненты могут устанавливаться поверх .NET Compact Framework в соответствии с необходимостью или желанием. Файл, содержащий эту информацию, имеет название System.SR.dll, а его размер составляет 91 Кбайт. Для других языков локализации предусмотрены дополнительные версии этого файла. Всего в настоящее время существует 10 таких локализованных языковых версий, суммарный размер которых достигает 900 Кбайт, что составляет ощутимую долю общего размера .NET Compact Framework. Таким образом, исключение этих строк из .NET Compact Framework позволяет значительно уменьшить суммарный размер системы.

При установке .NET Compact Framework в ОЗУ или ПЗУ мобильных устройств указанные вспомогательные файлы, как правило, не устанавливаются; обычно их устанавливают лишь тогда, когда это необходимо или желательно. В среде разработки Visual Studio .NET эти файлы автоматически устанавливаются во время отладки, поскольку их присутствие почти всегда является желательным для разработчиков

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

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

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

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

Средства подключения к базам данных SQL СЕ/SQL

Необязательные компоненты другой разновидности, которые могут устанавливаться поверх .NET Compact Framework, обеспечивают связь с определенными базами данных. Когда поставлялась версия 1.1 .NET Compact Framework, одновременно с ней поставлялись ее необязательные компоненты, обеспечивающие доступ к локальным базам данных SQL СЕ и удаленным базам данных SQL Server. Не являясь частью базового состава .NET Compact Framework, эти компоненты оказываются весьма полезными при создании приложений, работающих с упомянутыми базами данных. Существуют также аналогичные компоненты, обеспечивающие доступ к базам данных сторонних разработчиков.

Элементы, отсутствующие в первой версии .NET Compact Framework

Защита доступа

Концепция явной проверки полномочий являлась центральной при проектировании общеязыковой среды выполнения (Common Language Runtime), лежащей в основе как .NET Framework, так и NET Compact Framework. Другим распространенным на званием этой концепции является безопасность доступа кода.

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

■ Полные доверительные отношения. Код выполняется в системе на уровне полных доверительных отношений и может делать все то, что могло бы делать собственное приложение.

■ Ограниченный доступ к файловой системе. Операции файлового ввода-вывода могут быть запрещены или ограничены некоторыми каталогами, исходя из подтверждений, предоставленных компонентом.

■ Ограниченный доступ к пользовательскому интерфейсу. Возможность вызова пользовательских интерфейсов может быть разрешена или запрещена компонентам.

■ Сетевой доступ. Возможность доступа к сети может быть разрешена или запрещена компонентам.

■ Доступ к собственному коду. Возможность осуществления вызовов собственных кодов может быть разрешена или запрещена компонентам.

В варианте .NET Framework, ориентированном на настольные компьютеры и серверы, доступны не только эти, но и многие другие разрешения, которые могут определяться в качестве политик. По данному вопросу имеется обширная литература и документация.

.NET Compact Framework проектировалась с учетом поддержки описанной модели безопасности, основанной на политиках. Однако в первом выпуске .NET Compact Framework политика безопасности определялась очень просто: "Весь код пользуется полными доверительными отношениями". Это означает, что приложения, предназначенные для .NET Compact Framework v1.1, выполняющейся на устройстве, будут выполняться в этой среде с тем же набором разрешений, с которым на устройстве выполняются собственные коды.

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

В дальнейшем желательно внедрить модель безопасности, поддерживающую загрузку кода на лету и присвоение полномочий на основе подтверждений, предоставляемых кодом. Поэтому весьма вероятно, что в будущих версиях .NET Compact Framework будет предусмотрено несколько различных уровней доверительности и полномочий, охватывающих интервал от "полного доверия" на основе предоставляемых подтверждений до весьма ограниченных возможностей для кода, пользующегося низким уровнем доверительности. Кроме того, различные типы мобильных устройств будут, вероятно, характеризоваться заданием на них различных политик. На некоторых устройствах политики будут определяться конечными пользователями, на других — администраторами, изготовителями оборудования или же сетевыми операторами, обслуживающими то или иное устройство. Поддержка этих возможностей будет осуществляться встроенной моделью обеспечения безопасности доступа.

Мультимедиа

Еще одной областью, от явной поддержки которой в первом выпуске .NET Compact Framework мы решили отказаться, является работа с мультимедийной информацией. Это, например, означает, что разработчики, желающие воспроизводить звуки или показывать видео, должны использовать для этой цели собственные коды. Как и в предыдущем случае, если бы для разработки, тестирования и доработки этих средств у нас было больше времени, то их поддержка была бы обеспечена уже в первом выпуске .NET Compact Framework. Анализ отзывов, полученных нами от лиц, проводивших первые испытания этого продукта, позволил сделать вывод, что применительно к тем видам приложений, в создании которых в настоящее время существует потребность, поддержка данных возможностей не являлась критическим фактором успешности. По всей вероятности, в будущих версиях .NET Compact Framework поддержка мультимедийной информации будут более интенсивной.

Оглядываясь назад, мы можем констатировать, что принятое нами решение было правильным.

Как запускается и выполняется код

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

1. Загружается управляемое приложение. Двоичный заголовок приложения указывает операционной системе на то, что оно не является приложением в собственных кодах. Вместо того чтобы просто предоставить возможность выполняться инструкциям кода, загружается исполнительный механизм .NET Compact Framework, которому сообщается о том, что он должен запустить приложение на выполнение.

2. Исполнительный механизм находит класс, содержащий "главную" точку входа "main", с которой должно начинаться выполнение приложения. Таковым является класс с сигнатурой функции, соответствующей виду static void Main(). В случае обнаружения типа с такой сигнатурой происходит загрузка класса и производится попытка выполнения "главной" процедуры (шаги 3 и 4).

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

4. Исполнительный механизм пытается выполнить указанную процедуру. Если уже имеется откомпилированный код, связанный с процедурой, осуществляется выполнение этого кода.

5. Если исполнительный механизм обнаруживает, что свойство или метод, которые требуется запустить на выполнение, не откомпилированы, они компилируются по требованию. Производится загрузка содержащейся в классе информации, которая необходима методу. Код верифицируется для гарантии того, что он содержит безопасные, допустимые и корректно сформированные IL-инструкции, а затем подвергается JIT-компиляции. Если метод ссылается на другие типы, которые еще не были загружены, осуществляется необходимая загрузка определений соответствующих классов и типов. Методы, содержащиеся в классах, не компилируются до тех пор, пока в этом не возникнет необходимости; именно в этом и состоит смысл JIT-компиляции.

6. Выполняется скомпилированный к этому моменту метод. Если возникает необходимость в распределении памяти для типов или методов, исполнительному механизму направляются соответствующие запросы. Любые вызовы классов методами возвращают нас к шагу 5.

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

Что такое "тип"?

На заметку! "Типом" являются любые данные, с которыми может работать программист. Это можно сформулировать и иначе, сказав, что типами являются любые типы данных и классы. Все является типом, включая целые и десятичные числа, другие скалярные величины, строки и классы. Любая "сущность", которой вы можете манипулировать внутри кода, является экземпляром типа. Классы являются специальными типами в том смысле, что они содержат не только данные, но и код, и поддерживают такие объектно-ориентированные свойства, как наследование.

На заметку! После загрузки определений классов и других типов в память, их верификации и компиляции эти данные размещаются в распределенной памяти точно так же, как и любые другие данные, которые разработчики распределяют в своих приложениях. Рассмотрим пример. Предположим, вы создаете объект ArrayList:

System.Collection.ArrayList aList = new System.Collection.ArrayList();

При этом выполняются следующие операции:

1. Вышеприведенный код представляется в вашем приложении на промежуточном языке IL. Этот IL-код подвергается JIT-компиляции во время выполнения непосредственно перед тем, как выполняться в первый раз. Этот код помещается в распределенную память.

2. По окончании JIT-компиляции кода исполнительный механизм пытается определить, загружена ли информация о типе System.Collections.Array в память; если это не так, выполняется распределение памяти для этого типа, а также загрузка и связывание определения с классом ArrayList.

3. Во время выполнения приведенного выше фактического кода должен быть выполнен конструктор объекта ArrayList. Если соответствующий код еще не загружался и не подвергался JIT-компиляции, осуществляется распределение памяти для кода конструктора и JIT-компиляция этого кода. Выполняется загрузка кода, его верификация и JIT-компиляция, и память, распределенная для кода этого конструктора, связывается с конструктором класса ArrayList.

То же самое относится и к любому другому загружаемому типу или вызываемому методу; если необходимая работа по их загрузке не была до этого выполнена, они загружаются и компилируются по мере необходимости, и используемая для этого память связывается с типом.

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

Управление памятью и сборка мусора

В процессе своего обычного выполнения ваш код периодически инициирует загрузку определений типов в память, компиляцию и выполнение кода, а также размещение объектов в памяти и их удаление из памяти. .NET Compact Framework проектировалась таким образом, чтобы обеспечить наилучший баланс между скоростью запуска, устойчивостью и непрерывностью выполнения кода даже в условиях существования жестких ограничений на объем доступной памяти. Для достижения этой цели загрузчик классов, механизм JIT-компиляции, а также модули распределения памяти и сборки мусора работают скоординированным образом.

Вероятнее всего, выполнение вашего кода будет сопровождаться периодическим созданием новых объектов и их последующим уничтожением после того, как необходимость в них исчезает. Эффективное удовлетворение запросов памяти для размещения объектов и ее освобождение достигаются в .NET Compact Framework за счет утилизации освобождаемой памяти путем так называемой "сборки мусора" (garbage collection). Операции по сборке мусора в той или иной форме используются в большинстве современных сред выполнения управляемого кода.

Сборка мусора в основном предназначена для решения двух задач: 1) восстановления памяти, которая больше не используется, и 2) уплотнения участков используемой памяти таким образом, чтобы для вновь распределяемых областей памяти были доступны как можно более крупные блоки. Тем самым решается одна из наиболее распространенных проблем, которая называется фрагментацией памяти. По своей сути эта проблема аналогична проблеме фрагментации дискового пространства. Если дисковое пространство периодически не реорганизовывать, то по прошествии некоторого времени оно дезорганизуется и разобьется на ряд чередующихся свободных и занятых участков небольшого размера; эти участки и являются фрагментами. Можно считать, что здесь мы имеем дело с проявлением действия закона увеличения энтропии применительно к дисковому пространству и памяти; для того, чтобы обратить энтропийные эффекты, необходимо затратить определенную работу. В результате фрагментации доступ к данным замедляется, поскольку в процессе чтения файлов головкам приходится многократно перемещаться вдоль поверхности диска. Фрагментация памяти оборачивается еще худшими бедами, так как для размещения объектов требуются достаточно большие непрерывные блоки памяти, способные уместить целиком все данные, относящиеся к объекту. После выполнения многочисленных операций выделения и освобождения порций памяти различного размера свободные области оказываются расположенными вразброс, а их размеры являются недостаточными, чтобы обеспечивалось наличие больших непрерывных участков памяти, необходимых для размещения объектов. Уплотнение всей используемой, но расположенной вразброс памяти позволяет создавать крупные блоки свободной памяти, которую можно эффективно использовать при распределении памяти для вновь создаваемых объектов.

Восстановление памяти является сравнительно несложным процессом. Выполнение кода временно прекращается, а активные (live) объекты (то есть объекты, к которым ваш код может осуществлять непосредственный или косвенный доступ) отыскиваются и рекурсивно помечаются. Так как остальные объекты, находящиеся в памяти, уже недоступны активному коду, они остаются непомеченными, что позволяет идентифицировать их как "мусор" и восстановить соответствующую память. Такая разновидность сборки мусора известна под названием "отслеживание и очистка" ("mark and sweep"). Обычно эта операция осуществляется довольно быстро.

Возможность уплотнения объектов в памяти является дополнительным преимуществом выполнения управляемого кода. В этом случае, в отличие от собственных кодов, все известные ссылки на ваши объекты известны и исполнительному механизму. Благодаря этому можно перемещать объекты из одного места памяти в другое, если в этом возникает потребность. Диспетчер памяти (исполнительный механизм) отслеживает, где именно находятся те или иные объекты, и перемещает их в случае необходимости. Это позволяет уплотнять расположение набора управляемых объектов, разбросанных в памяти.

Однако в рукаве у .NET Compact Framework наряду с JIT-компилятором, диспетчером памяти и сборщиком мусора спрятан еще один козырь: возможность очищать память от пассивного (dead) JIT-компилированного кода. Обычно это делать нежелательно, но при определенных обстоятельствах такая возможность становится незаменимой. Если уж исполнительный механизм, обеспечивая максимальную производительность, потрудился и выполнил JIT-компиляцию управляемого кода до собственных команд процессора, то отбрасывание JIT-компилированного кода могло бы показаться расточительством, поскольку когда в следующий раз возникнет необходимость в выполнении этого кода, то потребуется его повторная JIT-компиляция. В то же время, наличие такой возможности оборачивается благом в следующих двух случаях:

1. Когда приложение осуществило JIT-компиляцию и был выполнен большой объем кода, который в ближайшее время не будет вновь выполняться. Довольно часто ситуации подобного рода возникают в тех случаях, когда выполнение приложения происходит в несколько стадий. Вполне возможно, что код, запускаемый на начальной стадии выполнения приложения для инициализации или настройки объектов и данных, впоследствии повторно выполняться не будет. Если возникает необходимость в дополнительном распределении памяти, то имеется полный смысл использовать для этого память, в которой хранится данный код.

2. Когда набор хранящихся в памяти активных объектов становится настолько большим, что возникает риск аварийного завершения выполнения приложения, если для размещения дополнительных объектов, которые в соответствии с алгоритмом должны создаваться в ходе нормального выполнения приложения, не найдется достаточно большого объема свободной памяти. В этом случае исполнительный механизм будет вынужден вытеснять из памяти и периодически перекомпилировать необходимый приложению код лишь для того, чтобы приложение было в состоянии продолжать дальнейшее выполнение. Если другой возможной альтернативой является только прекращение выполнения приложения из-за нехватки памяти, то единственным решением может быть лишь очистка памяти от JIT-компилированного кода, даже если это означает дополнительные затраты времени на последующую повторную компиляцию этого кода.

Краткий обзор методов управления памятью и сборки мусора

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

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

Рис. 3.2. Упрощенное схематическое представление состояния памяти приложения в процессе выполнения

Таблица 3.1. Условные графические обозначения, используемые на рис. 3.2, 3.3 и остальных рисунках

Фигура

Описание

Темно-серые овалы

Используемые в настоящее время объекты (например, объект Obj12 на рис. 3.2).

Белые овалы

Пассивные объекты. Эти объекты (например, объект Obj6 на рис. 3.2) являются "мусором", к которому у приложения больше нет доступа и от которого можно избавиться с целью высвобождения дополнительной памяти.

Темно-серые прямоугольники

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

Внутренние прямоугольники

Код, содержащийся в классах. (Код целиком находится внутри класса.)

Темно-серые внутренние прямоугольники

Код, подвергнутый JIТ-компиляции, поскольку метод был вызван хотя бы один раз (например, код Code1 класса ClassXYZ на рис.3.2).

Светло-серые внутренние прямоугольники

Код, который еще не подвергался JIТ-компиляции. По сравнению с прямоугольниками JIТ-компилированного кода эти прямоугольники имеют меньшие размеры, ибо еще не скомпилированные методы (например, метод Code4 класса XYZ на рис. 3.2) занимают в памяти очень мало места.

Приведенную на рис. 3.2 схему можно прокомментировать следующим образом:

■ Размеры отдельных элементов схемы выбраны таким образом, чтобы они давали представление об относительных объемах используемой памяти. Визуально большие классы и типы используют больше памяти по сравнению с визуально меньшими, поскольку содержат больше "начинки". Объекты различных типов используют различные объемы памяти. Пассивные объекты занимают память до тех пор, пока не будет выполнена операция сборки мусора. Методы, не подвергавшиеся JIТ-компиляции, занимают в памяти очень мало места.

■ В память загружаются описания всех типов и классов, которые используются в вашем приложении. Для различных типов и классов требуются различные объемы памяти.

■ JIT-компиляции подвергаются методы класса, которые вызывались хотя бы один раз. Пример: JIT-компиляции подвергались коды Code1, Code2, Code3 и Code7 класса ClassXYZ.

■ Те методы классов, которые еще не вызывались, не компилируются и поэтому не занимают много места в памяти. Пример: методы Code4 и Code5 класса XYZ еще не подвергались JIТ-компиляции. Как только они будут вызваны, будет осуществлена их JIT-компиляция и произведено распределение памяти для откомпилированного кода.

■ Объекты представляют собой экземпляры типов и классов и требуют места в памяти.

■ "Активные (live) объекты" — это объекты, к которым ваш код может получить доступ путем непосредственного или опосредованного использования глобальных, статических и стековых переменных.

■ "Пассивные (dead) объекты" — это объекты, доступ к которым со стороны вашего приложения стал уже невозможным, но которые еще не были удалены из памяти исполнительным механизмом. Таковыми на рис. 3.2 являются объекты Obj 3, Obj 6, Obj 9 и Obj11. До тех пор пока эти объекты не будут удалены, они будут занимать память подобно активным объектам или JIT-компилированному коду.

По мере того как объекты и другие типы, для которых память распределяется из кучи, будут создаваться вашим приложением и впоследствии становиться ненужными, наступит такой момент, когда невозможно будет создать никакой другой дополнительный объект, не удалив из памяти пассивные объекты. Как только это произойдет, исполнительный механизм инициирует сборку мусора. Состояние памяти приложения непосредственно перед выполнением операции сборки мусора показано на рис. 3.3.

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

Рис. 3.3. Состояние памяти приложения непосредственно перед сборкой мусора

Рис. 3.4. Пассивные объекты удалены из памяти, а активные — уплотнены

В состоянии нормального устойчивого выполнения приложение периодически создает объекты и избавляется от них. В необходимых случаях исполнительный механизм осуществляет сборку мусора и уплотняет память, освобождая ее для размещения вновь создаваемых объектов. Типичное состояние памяти приложения в условиях сосуществования активных и пассивных объектов, а также JIT-компилированного и некомпилированного кода показано на рис. 3.5.

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

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

Рис. 3.5. Типичное состояние памяти приложения при его устойчивом выполнении

Рис. 3.6. Типичное состояние памяти приложения при его устойчивом выполнении непосредственно после сборки мусора

Рис. 3.7. Активные объекты, занимающие всю доступную память

.NET Compact Framework справляется с подобными ситуациями, освобождая большие количества памяти, занимаемой текущим JIT-компилированным кодом. Может быть сброшен любой код, не выполняющийся в данный момент с использованием стека (или стеков, если речь идет о многопоточном выполнении). Это позволяет востребовать обратно память и использовать ее для нужд приложения, связанных с необходимостью размещения новых объектов или JIT-компиляции нового кода в случае, если метод ранее не выполнялся, но теперь вызывается. Состояние памяти приложения после отбрасывания ранее JIT-компилированного кода и сборки мусора показано на рис. 3.8.

Удаление JIT-компилированного кода является серьезным шагом, ибо часть этого кода придется JIT-компилировать повторно, но эта мера может оказаться весьма эффективной, если значительная часть ранее JIT-компилированного кода больше не потребуется для выполнения приложения. Это часто имеет место в тех случаях, когда заметная доля кода приходится на "начальный" код, используемый лишь для настройки последующего выполнения, или когда приложение разделяется на логические блоки, которые не обязательно должны выполняться все одновременно. Состояние памяти приложения вскоре после того, как отброшен весь возможный JIT-компилированный код, показано на рис. 3.9. Последующее размещение новых объектов и повторная JIT-компиляция кода методов осуществляются по мере необходимости.

Рис. 3.8. Удаление ранее JIT-компилированного кода и освобождение памяти, которая ранее была занята JIT-компилированным кодом методов

Рис. 3.9. Методы подвергаются повторной JIT-компиляции по мере их вызова, новые объекты размещаются в памяти, а отбрасываемые объекты становятся "мусором"

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

Рис. 3.10. Чрезмерно интенсивная загрузка памяти. Активные объекты занимают всю доступную память даже после того, как она максимально освобождена от JIT-компилированного кода

Резюме

.NET Compact Framework представляет собой богатую своими возможностями среду времени выполнения управляемого кода для мобильных устройств, пригодную для создания самых различных приложений, компонентов и каркасов приложений. Она с самого начала предназначалась для использования на устройствах, характеризующихся ограниченными ресурсами, но с самого начала проектировалась как совместимое на уровне двоичного кода подмножество платформы .NET Framework, ориентированной на настольные компьютеры и серверы. Подобно другим средам выполнения управляемого кода .NET Compact Framework включает в себя механизм выполнения собственных кодов и набор библиотек классов выполняющегося поверх него управляемого кода. Были применены стратегии проектирования, специально предназначенные для мобильных и встроенных устройств, что позволило обеспечить предоставление широкого подмножества функциональности платформы NET Framework и одновременно учесть специфику требований мобильных устройств в отношении размеров и производительности приложений.

Библиотеки классов, поставляемые в составе .NET Compact Framework версии 1.1, могут быть условно разбиты на пять логических блоков: 1) пользовательский интерфейс и поддержка графики, 2) поддержка XML, 3) поддержка клиентов Web-служб, 4) поддержка доступа к данным и всей связанной с этим функциональности, и 5) библиотеки базовых классов. Библиотеки базовых классов проектировались таким образом, чтобы разработчики приложений для настольных компьютеров чувствовали себя комфортно и уверенно при написании кодов для устройств; они должны найти здесь все средства, наличие которых могли ожидать. Сочетание указанных библиотек предоставляет разработчикам богатую палитру функциональных возможностей, которые позволяют создавать приложения коммерческого, производственного, научного и развлекательного характера. По всей видимости, в будущих версиях .NET Compact Framework будет добавлена поддержка моделей, обеспечивающих безопасность доступа кода, а также поддержка мультимедийных средств.

При создании приложений, предназначенных для выполнения в управляемых средах, особенно на мобильных устройствах, полезно иметь общее концептуальное представление о том, каким образом в таких средах осуществляется управление памятью и выполнением приложения. В .NET Compact Framework предлагается JIT-компиляция кода, а также освобождение памяти, используемой приложением, от "мусора". При нормальном выполнении приложения в очистке от "мусора" и периодическом уплотнении нуждается лишь память, занимаемая объектами. Если же необходимость в свободном пространстве возникает в условиях интенсивной загрузки памяти, то операции освобождения памяти и сборки мусора могут применяться также по отношению к JIT-компилированному коду. Аналогично тому, как в случае приложений, основанных на собственных кодах, возможно исчерпание памяти, серьезные проблемы, связанные с перерасходом памяти, могут возникать и в управляемых средах. Это происходит тогда, когда приложение исчерпывает всю доступную память в процессе размещения объектов. В подобных случаях производительность приложения резко падает, поскольку сборщик мусора постоянно пытается освобождать для вновь возникающих нужд память, острая нехватка которой становится все ощутимее. Если необходимую память распределить не удается, приложение завершается аварийно. Ситуаций, в которых возникает острая нехватка памяти, следует избегать, и в последующих главах книги значительная доля внимания будет уделена обсуждению того, как проектировать алгоритмы и создавать приложения, способные эффективно работать с такими ресурсами устройств, как память, освобождаемая в результате сборки мусора.

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

ГЛАВА 4

Как добиться успеха при разработке мобильных приложений

Из словаря Merriam-Webster

Основная запись: meth• od• ol• о• gy (методология)

Функция: существительное

Форма(ы) с окончаниями: мн. -gies

Этимология: нов. лат. methodologia, от лат. methodus + -logia -logy

Дата: 1800

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

2: Анализ принципов и процедур, применяемых при проведении исследований в определенной области.

(www.m-w.com, 2004)

Введение

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

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

Что касается разработки приложений для настольных компьютеров и серверов, то за последние 10–15 лет в разрешении "временных" проблем в этой области был достигнут огромный прогресс.

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

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

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

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

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

НА ЗАМЕТКУ

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

Трудности временного характера и способы их преодоления

Некоторые из проблем, с которыми приходится сталкиваться разработчикам программного обеспечения, можно с полными основаниями охарактеризовать как "временные трудности". С появлением более совершенных инструментальных средств разработки острота этих проблем может снизиться. Хорошим примером временных трудностей могут служить проблемы отладки. За многие годы был достигнут огромный прогресс в предоставлении разработчикам средств отладки приложений в процессе их выполнения. Это привело к кардинальным изменениям самого процесса отладки, благодаря чему эта ранее трудоемкая задача, которая решалась при помощи столь разнородного инструментария, как карандаш и бумага, низкоуровневые средства наподобие дизассемблеров или отладочная печать, и требовала немалой доли интуиции, в настоящее время превратилась в весьма естественную интерактивную составную часть любого набора современных средств разработки. Среди разработчиков, пользующихся современным инструментарием, сегодня вряд ли найдутся такие, кто считает отладку отдельным видом деятельности, отличным от проектирования и написания кода. Сейчас все это объединено в рамках одного естественного процесса разработки программного обеспечения, и разработчики плавно переключаются с одного вида деятельности на другой. Еще не так давно наблюдалась явно иная картина, и, по крайней мере, в отношении программного обеспечения, выполняющегося на устройствах, об этом можно говорить со всей определенностью. Представляя собой когда-то сложнейшую проблему, отладка кода в наши дни значительно упростилась. То были временные трудности, и улучшение технологий позволило с ними справиться

Трудности постоянного характера и методологии, привлекаемые для их разрешения

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

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

Неплохим примером ситуаций, которым свойственны неизбежные сложности, является проектирование алгоритмов. Современные объектно-ориентированные языки разработки значительно облегчили инкапсуляцию и организацию кода, но они не в состоянии упростить или автоматизировать собственно проектирование алгоритмов. Несомненно, наличие богатого набора базовых классов, предлагаемых современными программными средами, способствует написанию эффективных алгоритмов, однако проектирование принципиально новых алгоритмов по-прежнему является нелегкой задачей, которая, по всей вероятности, будет оставаться таковой и в ближайшем обозримом будущем. Это имеет место по той простой причине, что алгоритмам, в силу самой их природы, свойственна специфичность, обусловленная конкретикой задачи, и не существует никаких известных общих способов, позволяющих преобразовать ваши намерения в алгоритм, который наилучшим образом соответствовал бы намеченным целям; в подобных случаях автоматизация возможна лишь при условии значительного сужения масштаба задачи и создания специального инструментария для ее решения. То же самое можно сказать и о написании многопоточного кода. Применение усовершенствованных инструментальных средств, языков программирования и библиотек, несомненно, облегчает эту работу и позволяет решать задачи во многих случаях, допускающих строгое описание; вместе с тем, создать универсальную машину, способную разрезáть общие задачи на параллельные ломтики, нам никак не удается. Подобные проблемы являются неизбежными, и их решение требует тщательного проектирования и применения подходящей методологии.

Современные языки программирования и средства графического проектирования позволяют разработчикам полнее реализовывать свои намерения, но не устраняют необходимости в приобретении устойчивых навыков конструирования алгоритмов. Без таких навыков невозможно обойтись при построении критических систем, определяющих поведение и эффективность программного обеспечения. Лучшее, что смогла предложить современная технология программирования, — это упаковка сложных алгоритмов в повторно используемые компоненты и каркасы, и предоставление возможности моделирования взаимодействия компонентов между собой. При таком подходе проектирование критических систем, представляющих общий интерес, могут осуществлять высококлассные специалисты, а остальные разработчики получают возможность повторно использовать эти системы. Проектирование компонентов может быть упрощено, а взаимодействие между авторами компонентов и клиентами сделано более прозрачным за счет применения таких технологий моделирования, как UML (Unified Modeling Language — унифицированный язык моделирования) и панели графического проектирования, но эти технологии не в состоянии снять проблемы внутренней сложности, свойственные процессу проектирования эффективных алгоритмов. Постоянное совершенствование инструментальных средств будет способствовать преодолению временных трудностей, однако трудности постоянного характера, обусловленные самой природой алгоритмов, будут всегда оставаться.

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

Сначала выделяются критические компоненты и алгоритмы, требующие проектирования, кодирования и тестирования на самом высоком профессиональном уровне. Вся основная функциональность предоставляется разрабатываемым приложениям высокоуровневым и, как правило, менее строго тестируемым кодом, который использует эти компоненты. Причина успеха компонентов как методологии заключается в том, что она дает возможность разложить приложение на отдельные части. Это позволяет инженерам-программистам, специалистам в области архитектуры систем и руководителям идентифицировать наиболее трудные моменты алгоритмизации и сосредоточить на них внимание. Как и в случае любой другой методологии, при разбиении приложения на компоненты необходимо действовать осмотрительно, стараясь не переусердствовать в этом. Если выделять в отдельные компоненты все, что только возможно, исходя из того ложного допущения, что увеличение количества компонент, на которые разбивается проект, приводит к лучшему техническому решению, то в результате этого чрезмерно усложнятся интерфейсы между многочисленными компонентами различно] о рода. Средства моделирования могут оказать вам помощь в визуализации этих взаимодействий, но от сложной картины вам все равно не избавиться. Чрезмерное обилие необязательных компонентов размывает тот острый фокус, который, в соответствии с самим ее назначением, должна обеспечивать разбивка на компоненты для достижения высоких эксплуатационных характеристик критических элементов. Любая методология должна применяться осмотрительно и с отчетливым пониманием тех целей, которые при этом преследуются. Методология полезна лишь тогда, когда можно измерить ее эффективность при решении данной задачи, ибо только в этом случае вы будете уверены в том, что реализуются все ее преимущества.

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

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

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

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

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

Любой достаточно сложный проект по разработке мобильного программного обеспечения нуждается в хорошем наборе методологий, способных справляться со свойственными данному виду разработки трудностями постоянного характера. Должен существовать процесс, позволяющий определять трудные проблемы и убеждаться в том, что они решаются наиболее подходящим для этого способом. Технология компонентов позволяет справиться с одним специфическим типом проблем разработки программного обеспечения. Однако для решения других проблем, например, тех, которые связаны с обеспечением необходимой производительности приложений, проектированием эффективных пользовательских интерфейсов или созданием надежных каналов связи для мобильных устройств, потребуются дополнительные методологии. Умение распознавать проблемы постоянного характера и знание способов их преодоления является отличительным признаком хорошего руководителя группы разработчиков.

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

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

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

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

Пакетная обработка

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

Серверная обработка без сохранения состояний

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

Интерактивные вычисления, управляемые событиями

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

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

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

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

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

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

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

■ Вооружитесь определенной методологией разработки. Методология — это план того, как вы будете проектировать и писать код. Оставшаяся часть настоящей главы посвящена разработке методологии для мобильных приложений.

■ Подготовьте план проекта в явном виде, оформив его в форме одного основного документа. Любой проект только выиграет, если у вас будет один основной документ, с требованиями которого согласны все участники проекта. Шаблон такого плана проекта определяется ниже.

■ Планируйте периодические пересмотры проекта. Всегда возникают непредвиденные проблемы и требуются изменения плана. Мобильные устройства не являются замкнутыми системами, и их успешное взаимодействие с пользователем и внешним миром в целом представляет собой сложный процесс; поэтому по мере продвижения работы вы будете все время узнавать что-то новое для себя. Лучше всего, если вы будете осознавать необходимость этого с самого начала и внесете в свой план соответствующие пункты.

Описание проекта

Для всех проектов разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный "руководящий документ", в котором определяются: 1) требования проекта и целевое назначение завершенного продукта; 2) философия проекта, 3) архитектура приложения; 4) текущее состояние работ в данном направлении; 5) план в соответствии с которым продукт будет переводиться из его текущего состояния в состояние успешного завершения. Для крупных проектов могут предусматриваться дополнительные документы, но всегда должен существовать один основной документ самого верхнего уровня, в котором определяются основные цели проекта, его нынешнее состояние и план работ. Этот документ должен быть реально действующим документом, который, по мнению всех участников группы, правильно определяет направления работы

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

■ Цели проекта. В этом разделе основного документа должно быть ясно указано, для чего предназначается завершенный продукт, и какая философия лежит в основе проекта.

■ Состояние проекта. Этот раздел основного документа содержит точное описание текущего состояния проекта. Он является частью календарного плана проекта и позволяет судить о степени приближения работ над проектом к завершению. Здесь должны быть определены контрольные точки проекта, на достижение которых должны концентрироваться усилия, а также указано, какие элементы должны быть доработаны для завершения текущего контрольной точки процесса разработки. Здесь же должен предоставляться список наиболее значимых факторов риска или факторов, которые необходимо исследовать для разрешения соответствующих проблем.

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

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

Плановые пересмотры проекта

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

Детали ничего не стоят, если общая картина неверна

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

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

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

Решайте задачи в определенной очередности; не бойтесь при необходимости возвращаться назад

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

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

Шаг 0: прежде чем приступать к работе, определите сферу применения вашего приложения

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

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

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

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

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

Если вы не определите важнейшие с вашей точки зрения сценарии и возможности, то в результате вы получите бессистемную смесь средств, объединенных в одно приложение. Отсутствие явного списка основных функций приложения или разделения функций на группы в соответствии с их приоритетами приведет к тому, что пользовательский интерфейс не будет оптимизирован для эффективного решения ключевых задач. Например, если ожидается, что пользователь в основном будет заинтересован во вводе данных, то вы должны оптимизировать пользовательский интерфейс таким образом, чтобы обеспечить как можно более точное и надежное выполнение операций ввода. И наоборот, если ввод данных используется лишь изредка, то вариант пользовательского интерфейса ввода, оптимизированного не самым идеальным образом, может оказаться вполне допустимым, что позволит перебросить ресурсы проектирования и разработки на другие направления. Лишь только если группой разработчиков будут идентифицированы, перечислены и согласованы наиболее важные сценарии, эксплуатационные характеристики приложения могут быть настроены для их выполнения должным образом, а конечные пользователи не будут лишены важных для них средств из-за недосмотра.

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

Примеры удачных и неудачных описаний сценариев

Неудачное описание

Удачное описание

Приложение для обслуживания банковских операций

Приложение для обслуживания банковских операций

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

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

Опросы общественного мнения

Опросы общественного мнения

"Обеспечить замену бумаге и дощечке с зажимом при проведении опросов общественного мнения и избавиться от занесения данных опроса вручную." Какие вопросы будут задаваться? Когда будет выполняться синхронизация данных?

"Приложение должно предоставить пользователям возможность сбора информации в ходе опросов общественного мнения с помощью устройства Pocket PC. Вопросы будут предусматривать либо выбор одного из готовых вариантов ответа, либо простой цифровой ввод, а ответы будут кэшироваться на устройстве и отправляться на сервер после помещения устройства в лоток ПК. Опрос может содержать до 20 вопросов, а результаты, содержащие вплоть до 1000 ответов, должны храниться на устройстве. Ввод текста вручную не требуется. Мы указали, какие виды вопросов должно обрабатывать приложение, а также каким образом будет осуществляться синхронизация устройства. (Здесь следует обратить внимание на то, что при составлении списка сценариев мы не заботились о том, какой именно способ сохранения результатов на устройстве будет использоваться или каков будет конкретный механизм синхронизации для работающего сценария — это важно только для нашей реализации, но не для конечного пользователя.) Мы указали также, чего не требуем от приложения (например, от него не требуется обработка свободного текста).

Инвентарный учет

Инвентарный учет

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

"Приложение предназначено для использования на складах в режиме периодического доступа в сеть WI-Fi. Должна быть обеспечена возможность автономного режима работы с хранящимися на устройстве данными учета товаров, охватывающими вплоть до 5000 наименований. Идентификаторы товарных единиц должны сканироваться с помощью устройств для считывания штрих-кодов. Учетные записи о товарных единицах могут включаться в инвентарный список и исключаться из него. Устройства синхронизируются с использованием сети Wi-Fi, когда этого пожелает пользователь. Для обновления информации может быть затребован активный доступ к серверной базе данных. Ключевой сценарий: произвести сканирование при помощи устройства для считывания штрих-кодов и указать нажатием клавиши вид операции с инвентарным списком — добавление или исключение учетной записи. Произвести считывание порядкового номера покупки для его связывания с учетной записью о товарной единице. Ключевое требование — в случае невозможности считывания штрих-кода пользователь должен иметь возможность быстро ввести необходимую цифровую информацию вручную с помощью сенсорного экрана и пера. Для повышения надежности учета информация о неудачных попытках считывания штрих-кодов в процессе эксплуатации приложения должна заноситься в журнал." Мы указали, в чем состоит суть ключевых требований, а также выписали основной сценарий, в соответствии с которым будет эксплуатироваться приложение.

Игровые/обучающие приложения

Игровые/обучающие приложения

"Создать мобильное приложение для изучения слов иностранного языка." Какая емкость словаря потребуется? Каким образом будет осуществляться процесс обучения в целом?

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

Приложение для заказа авиабилетов

Приложение для заказа авиабилетов

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

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

Шаг 1: начните с анализа проблем производительности и никогда не упускайте их из виду

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

■ Вы должны определить общие показатели, характеризующие способность вашего приложения реагировать на действия пользователя. Например: "На появление диалога не должно уходить более 0,5 секунды", "Визуально определяемая реакция на нажатие клавиши должна следовать немедленно" или "Раскрытие узлов дерева не должно занимать более 0,15 секунды". Здесь были приведены в качестве примера неплохие значения показателей, к достижению которых следует стремиться.

■ Вы должны определить конкретные числовые показатели для ключевых сценариев. Например: "Загрузка данных инвентаризационной ведомости ни при каких обстоятельствах не должна останавливать работу пользовательского интерфейса на более чем 0,2 секунды без появления курсора ожидания" или "Дли тельность загрузки данных инвентаризационной ведомости ни в коем случае не должна превышать 3 секунд".

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

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

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

Рис. 4.1. Методология, подчиненная требованиям производительности

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

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

Нередко разработчики рассуждают таким, на первый взгляд вполне разумным, но на самом деле глубоко ошибочным образом: "Понять, какие части приложения нуждаются в улучшении, можно лишь только после того, как будет написан весь код". Такая позиция весьма порочна, поскольку в ней содержится предположение о том, что отдельные части вашего приложения каким-то удивительным образом не зависят друг от друга. Вместе с тем, когда вы напишете весь код, в него будет введено множество явных и неявных зависимостей между различными системами, и вы, вероятнее всего, будете в состоянии внести в код лишь некоторые изменения количественного, но не качественного характера. Вам не уйти от этого даже в том случае, если вы приложите максимум усилий к инкапсуляции кода приложения. Чем больше объем кода, тем больше в нем существует зависимостей между отдельными частями; пытайтесь бороться с этим, тщательно продумывая структуру приложения, но знайте, что таковы реалии жизни. Браться за решение проблем производительности следует тогда, когда базовый код еще обладает достаточной гибкостью и остается открытым для реструктуризации. Лучше всего заниматься этим сразу же по ходу написания кода.

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

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

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

(если производительность низка, выполнение последующих шагов вам ничего не даст)

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

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

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

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

Как ActiveSync, так и Internet Explorer для Pocket PC и интеллектуальных телефонов предлагают элементы пользовательского интерфейса, назначение которых состоит в том, чтобы информировать пользователей о состоянии выполнения инициированных ими асинхронных запросов. Благодаря этому пользовательский интерфейс сохраняет свою интерактивность, и у пользователя не возникает чувства потери контакта с приложением.

Для синхронизации календарной информации с сервером Exchange Server приложению ActiveSync может требоваться телефонный звонок или иная форма операции соединения, на выполнение которой уходит длительное время. В процессе выполнения такой операции пользовательский интерфейс устройства отображает пояснительный текст, информирующий пользователя о текущем состоянии попытки создания соединения. Таким текстом может быть "Набор номера...", "Соединение с сервером", "Синхронизация расписания", "Загружено 12 из 20" и тому подобное. Такие несложные уведомляющие элементы пользовательского интерфейса не дают никакого выигрыша в производительности, но зато сохраняют в пользователе уверенность в том, что полезная для него работа продолжает выполняться, и удерживают его от попыток отмены запроса из-за того, что ответ на него затягивается.

Браузер Pocket Internet Explorer также может нуждаться в соединении с источниками данных, поиске IP-адресов URL и выполнении других задач в процессе загрузки Web-страниц. При выполнении подобных затяжных задач заголовок окна браузера обновляется постоянно отображая текст, информирующий пользователя о состоянии соединения. Кроме того, при загрузке Web-содержимого отображается анимация флага Windows. Оба указанных действия информируют пользователя о том, что выполнение операции продолжается.

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

Шаг 2: спроектируйте подходящий пользовательский интерфейс

Как ранее уже отмечалось, прежде чем приступить к проектированию мобильного приложения, важно выделить ключевые сценарии и возможности, которые будут определять сферу его применения. Далее, процесс разработки должен быть ориентирован на достижение высокой производительности приложения, ибо это будет гарантией того, что при составлении кода вы не загоните сами себя в угол. Если вы не в состоянии добиться того, чтобы выбранные вами ключевые сценарии и средства функционировали удовлетворительно, пересмотрите проект.

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

Будьте готовы к необходимости итеративного проектирования пользовательского интерфейса, особенно если вы только начинаете работать с мобильными устройств или приступаете к работе с новым классом устройств, форм-фактор которых отличен от тех, с которыми вы имели дело до этого. По мере накопления опыта работы с устройствами данного класса вы сможете проектировать пользовательские интерфейсы в более сжатые сроки, но вам все равно придется возвращаться к предыдущим этапам работы, чтобы все было сделано наилучшим образом.

Рис. 4.2. Проектирование пользовательского интерфейса, ориентированное на достижение высокой производительности

Будет неплохо, если вы возьмете за правило отделять логику выполнения приложения от логики представления информации, в результате чего внесение изменений в пользовательский интерфейс не будет влечь за собой необходимости изменения логики приложения. Это вдвойне справедливо, когда речь идет об устройствах. Абстрагируя логику выполнения приложения от логики представления информации, вы усиливаете свои позиции как в отношении пересмотра и улучшения пользовательского интерфейса для конкретного целевого устройства, так и в отношении быстрого переноса приложения на новые классы устройств. Сегодняшнее приложение для устройств PDA завтра вполне может стать приложением для смартфонов, если только код его пользовательского интерфейса тесно не переплетен с основной логикой приложения. Тщательное разделение логики приложения и логики интерфейса принесет вам неплохие дивиденды как в плане сопровождения кода, так и в плане его переносимости.

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

(неудачный пользовательский интерфейс — ежедневный источник раздражения)

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

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

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

Шаг 3: выберите подходящие модели данных и памяти

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

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

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

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

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

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

(неудачная модель — заведомо низкую производительность)

Если согласиться с тем, что существует искусство создания замечательных приложений, то важнейшей его составляющей является умение выбирать наиболее подходящие модели данных. Рациональное управление памятью и ресурсами подразумевает следующее: 1) приобретение навыков экономного расходования памяти и хранения в ней только тех объектов, в которых действительно существует острая необходимость и которые будут немедленно использоваться, 2) использование кэширования важных данных на устройстве, но вне активной памяти и 3) перемещение остальных данных на накопитель, находящийся за пределами устройства. Научившись этим трем вещам, вы пройдете значительную часть дистанции, отделяющей вас от создания великолепно функционирующих приложений, работа с которыми будет доставлять удовольствие пользователям.

Шаг 4: выберите подходящую модель коммуникации и модель ввода-вывода

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

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

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

Рис. 4.4. Проектирование коммуникационной модели, ориентированное на достижение высокой производительности

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

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

Вообще говоря, формат, в котором хранятся данные, выбирается на основе компромисса между требованиями эффективности и удобства использования. Любые конкретные данные могут храниться в виде двоичных файлов, простых текстовых файлов, текстовых XML-файлов или в виде структурированных таблиц локальных баз данных. Требования эффективности означают минимизацию размера данных и обеспечение максимально возможной производительности приложения. К числу требований удобства использования относятся максимально возможное повышение производительности труда разработчика, улучшение условий сопровождения кода, минимизация объема необходимого тестирования, обеспечение возможности обмена данными между приложениями и гибкость формата, обеспечивающая возможность его последующего расширения.

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

Хранение данных в текстовых форматах значительно облегчает их использование и расширяет возможности их переноса в другие приложения, так как декодировать их легче. Однако размеры текстовых файлов больше по сравнению с их двоичными аналогами. Размеры XML-файлов оказываются еще большими, чем размеры обычных текстовых файлов, поскольку текстовые данные в них дополняются информацией о схеме данных. Эти дополнительные метаданные схемы значительно повышают гибкость данных в отношении учета их версий и переносимости в другие приложения, но требуют использования дополнительного пространства. Кроме того, при чтении и записи XML файлов их необходимо дополнительно пропускать через синтаксические анализаторы, что усложняет их обработку по сравнению с обычными текстовыми файлами, в которых для разделения данных используются запятые или символы табуляции. Отмеченная гибкость достается за счет дополнительных накладных расходов. Эти дополнительные расходы можно снизить, используя разумные стратегии реализации, но полностью избавиться от них невозможно.

Базы данных предлагают наивысшую степень организации данных, однако привносят с собой дополнительные накладные расходы, связанные с выполнением процессора базы данных.

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

Обычно программные модели, предназначенные для работы с сохраненными данными, имеют несколько уровней. Так, для работы с файлами в .NET Compact Framework предлагаются следующие уровни абстракции, перечисленные в порядке их повышения:

■ Двоичные потоки.

■ Текстовые потоки.

■ Объекты однонаправленного чтения и записи XML.

■ Объектная модель документов (DOM) XML.

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

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

Какой формат данных следует использовать для хранения данных — целиком зависит от целей вашего приложения; никакого универсального рецепта здесь не существует. Распространенной ошибкой тех, кто только приступает к разработке программного обеспечения для мобильных устройств, является допущение о том, что, поскольку в этом случае приходится иметь дело с ограниченными ресурсами, следует сразу же переходить на самый низкий уровень абстракции и использовать двоичные файлы наряду с потоковыми операциями файлового ввода-вывода. Иногда необходимость в этом действительно существует, но в большинстве случаев это просто означает выполнение ненужной работы, которая потребует дополнительного тестирования и, вероятно, приведет к худшему решению, не обеспечивающему достаточной гибкости. Общее правило заключается в том, чтобы использовать наивысший уровень абстракции, допустимый с точки зрения размера данных и достигаемой при этом производительности. Было бы неразумно изобретать собственный двоичный формат для данных сравнительно небольшого объема, поскольку при средних запросах памяти лучшего варианта, чем XML, не найти. С XML легко работать, он обеспечивает надежную работу с различными версиями данных и для него существует высокоуровневый API- интерфейс, упрощающий процесс программирования. Точно так же, в случае возникновения действительной необходимости в двоичном формате, например, для хранения больших объемов данных, описывающих изображения, гораздо предпочтительнее воспользоваться уже имеющимися и проверенными на практике форматами, если таковые имеются. Поскольку существует целый ряд хорошо зарекомендовавших себя форматов изображения, изобретение собственного формата будет, как правило, напрасной тратой времени. При любой удобной возможности старайтесь использовать уже существующие компоненты и форматы данных; изобретайте свои собственные форматы лишь в тех случаях, когда вы убеждены, что высокоуровневые подходы не сработают.

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

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

Доступ к данным может осуществляться через сеть Wi-Fi, данные могут передаваться посредством флэш-карты, вставленной в устройство, пересылаться при помощи мобильных телефонов с использованием протокола GPRS, передаваться через инфракрасный порт или просто пересылаться по Ethernet-кабелю, подключенному к устройству. Короче говоря, существует множество самых различных типов данных, которыми устройства могут обмениваться, и средств, обеспечивающих передачу этих данных.

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

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

■ Должно ли быть подключение к источникам актуальных данных постоянным или оно будет требоваться лишь время от времени?

■ Какие объемы данных потребуется перемещать? От ответа на этот вопрос могут зависеть другие ваши решения.

■ Каким образом будет осуществляться обмен данными? Посредством беспроводного сетевого соединения? Посредством лотка ПК? Посредством карты флэш-памяти?

■ Какова структура расходов на обеспечение соединений? Поскольку за использование сети Wi-Fi в составе интрасети ничего платить не надо, плата за использование мобильных сетей обычно взимается в соответствии с объемом передаваемых данных.

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

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

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

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

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

■ Поместите все процедуры доступа к сети в блоки try/catch (то есть организуйте структурную обработку исключений). Исходите из того, что время от времени будет выполняться каждый из этих catch-блоков, и имитируйте эти ситуации в процессе проектирования и тестирования приложения, чтобы проверить, правильно ли реагируют на возникновение исключений предусмотренные для них обработчики. Целесообразно предусмотреть, чтобы исключения возбуждались при любых периодических нарушениях связи; точно так же, целесообразно перехватывать подобные исключения и обрабатывать их так, чтобы это облегчало работу пользователя.

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

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

Как и в случае локальных данных устройства, при работе с сетевыми ресурсами также используются несколько уровней абстракции. Так, в .NET Compact Framework предлагаются следующие уровни API-интерфейсов для работы с сетевыми данными:

■ Сокеты, использующие потоки.

■ Запросы/ответы HTTP.

■ Механизм SOAP.

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

При необходимости вернитесь к шагам 0, 1, 2 и 3

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

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

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

Рис. 4.5. Пересмотрите предыдущие шаги проекта, если это необходимо для устранения проблем производительности

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

■ Остаются ли в силе намеченные вами первоначальные ключевые сценарии и набор возможностей приложения или они должны быть переопределены?

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

■ Работоспособна ли базовая модель данных, в соответствии с которой объекты загружаются в память и выгружаются из нее? Обеспечивает ли она масштабирование до тех реальных объемов данных, с которыми столкнутся ваши пользователи? Будет ли эта модель вести себя достаточно стабильно в процессе того, как пользователь своими действиями заставит приложение побывать во всех возможные состояниях, запросит дополнительные данные или запустит приложение, предоставив ему возможность выполняться непрерывно в течение многих недель?

■ Удовлетворяет ли коммуникационная модель мобильного приложения вашим требованиям? Используете ли вы наивысший из уровней абстракции API- интерфейсов и форматов файлов, который является для вас приемлемым?

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

Шаг 5: пакетирование приложения для его установки

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

■ Какие модули развертываются вместе с приложением? Представляет ли собой приложение единственный двоичный исполняемый файл или имеются дополнительные файлы данных, устанавливаемые вместе с ним, например, изображения, текстовые файлы или файлы баз данных? Должен ли и может ли любой из этих файлов быть включен в двоичный файл приложения в качестве ресурса для упрощения процесса развертывания? Требуются ли приложению другие библиотеки времени выполнения или компоненты, подлежащие установке вместе с ним на устройстве?

■ Какая процедура используется для развертывания приложения на устройстве? Устанавливается ли приложение на самом устройстве через сетевое соединение? Устанавливается ли оно через настольный компьютер, с которым устройство связано кабелем? Устанавливается ли оно с карты, вставляемой в устройство? Устанавливается ли приложение с одного устройства на другое посредством инфракрасного порта, облегчающего распространение приложения между равноправными устройствами?

■ Кто будет осуществлять развертывание приложения? Будут ли это делать конечные пользователи? Знакомы ли конечные пользователи с целевыми устройствами и процедурами инсталляции? Будут ли организации развертывать приложения на устройствах своих сотрудников? Будет ли приложение развертываться оператором мобильного телефона или загружаться из Web?

■ Как будут создаваться новые версии приложения? Будет ли приложение само проверять необходимость своего обновления за счет использования сетевого ресурса? Будет ли сервер сканировать устройства, чтобы определить, нуждаются ли они в установке новой версии? Будут ли новые версии приложения устанавливаться при помещении устройства в лоток ПК?

■ Могут ли возникнуть проблемы защиты приложения? При широком развертывании любого приложения всегда возникают вопросы, связанные с его защитой, которые обязательно следует рассмотреть. Должно ли приложение снабжаться цифровой подписью? Должны ли данные, с которыми работает приложение, быть тем или иным способом защищены? Что может произойти с данными, если устройство, на котором хранятся данные, будет утеряно или украдено?

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

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

Резюме

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

1. Вооружитесь определенной методологией разработки и строго придерживайтесь ее. Одна из этих методологий была представлена в общих чертах в этой главе и рассматривается более подробно в последующих главах. Эта методология хорошо приспособлена для мобильных устройств. Если окажется, что ваши потребности несколько отличаются, можете изменить ее, но в любом случае вы должны действовать в соответствии с определенной методологией.

2. Подготовьте единственный основной документ проекта, который определяет ваши цели и позволяет отслеживать степень выполнения проекта. Уровень формализации этого документа будет зависеть от того, что собой представляет ваша организация. Если вы — индивидуальный разработчик, работающий автономно, то этот документ будет просто помогать вам отслеживать разработку высокоуровневых задач и сценариев, определять ваши контрольные точки в процессе решения этих задач, а также отслеживать невыполненные пункты, подлежащие дополнительному анализу; объем такого документа не должен превышать нескольких страниц. В случае если у вас крупная организация, этот документ может представлять собой официальный контракт между вами и другой организацией, в котором подробно описывается, что именно должно быть выполнено, и какие проектные решения были приняты, а также детализированы контрольные этапы проекта и его состояние на протяжении всего периода разработки. В соответствии с этим документом и должна осуществляться разработка, и вы все время должны поддерживать его "актуальность". Пусть это будет единственный документ, который представляет задачи вашего проекта и позволяет объективно оценивать этапы его выполнения.

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

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

ГЛАВА 5

Наш друг конечный автомат

state [`stAt]

Функция: существительное

Использование: часто в качестве определения

Этимология: средневек. англ. stat, от устар. фр. и лат.; устар. фр. estat, от лат. status, между stare и stand — ближе к STAND

Дата: 13 столетие

1а: режим или условие нахождения <в состоянии готовности> b (1): настроение ума или темперамент <во взвинченном состоянии> (2) пребывание в необычном напряжении или волнении

2а: период или стадия физического существования чего-либо

(www.m-w.com, 2004)

ma-chine [mashEn]

сущ. (мн. ma-chines)

Использование: часто в качестве определения

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

стиральная машина

(Encarta 2004, Quotations)

Введение

Конечный автомат (state machine) (который называют еще и машиной состояний) — весьма полезная концепция, которую удобно использовать для структурирования приложений. Продуманное использование конечных автоматов облегчает организацию и сопровождение как логики пользовательского интерфейса, так и логики приложения. Благодаря этому ваш код будет более гибким и надежным, причем это относится к разработке не только мобильных, но и вообще любых приложений. Поскольку мобильные приложения должны использовать пространство экрана и системные ресурсы эффективно и экономно, конечные автоматы оказываются особенно полезными при разработке мобильного программного обеспечения. Конечные автоматы могут быть использованы для управления тем, какие наборы ресурсов следует удерживать памяти в любой момент времени, а также тем, какие элементы пользовательского интерфейса должны находиться на тех или иных участках экрана мобильного устройства. Конечные автоматы идеально подходят для решения такого рода задач.

В данной главе вводятся и исследуются методы использования конечных автоматов, и объясняется то, каким образом применение конечных автоматов может способствовать написанию эффективного и надежного кода.

Что такое конечный автомат?

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

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

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

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

На рис. 5.1 в схематическом виде представлен конечный автомат обучающей игры, позволяющей изучать иностранные слова путем выбора одного из предлагаемых вариантов ответа. Поведение приложения разбито на пять логических состояний. Эти логические состояния существуют независимо от того, будут ли они выбраны нами для введения их определений в конечный автомат. Конечный автомат — это просто формальное описание того, как работает приложение. Она позволяет нам ясно представлять себе различные состояния, в которых может находиться приложение в процессе взаимодействия с ним пользователя.

Другим способом представления состояний приложения является построение диаграммы переходов. Эта диаграмма содержит список дискретных состояний, в которых может находиться приложение, а также возможные варианты переходов между состояниями. Список возможных состояний и вариантов перехода из одного состояния в другое для нашего приложения представлен в табл. 5.1.

Рис. 5.1. Конечный автомат для простой обучающей игры, предназначенной для изучения иностранных слов путем выбора правильного ответа из нескольких предложенных вариантов

Таблица 5.1. Варианты изменения состояний для словарной игры с множественным выбором

Состояние

Внешний ввод

Следующее состояние

StartScreen

Пользователь выбрал вариант "Next Question"

AskQuestion

StartScreen

Пользователь выбрал вариант "Correct Answer"

Запрещенный переход!

StartScreen

Пользователь выбрал вариант "Incorrect Answer"

Запрещенный переход!

StartScreen

Пользователь выбрал вариант "End Game"

Запрещенный переход!

AskQuestion

Пользователь выбрал вариант "Next Question"

Запрещенный переход!

AskQuestion

Пользователь выбрал вариант "Correct Answer"

CongratulateUser

AskQuestion

Пользователь выбрал вариант "Incorrect Answer"

ScoldUser

AskQuestion

Пользователь выбрал вариант "End Game"

Запрещенный переход!

CongratulateUser

Пользователь выбрал вариант "Next Question"

AskQuestion

CongratulateUser

Пользователь выбрал вариант "Correct Answer"

Запрещенный переход!

CongratulateUser

Пользователь выбрал вариант "Incorrect Answer"

Запрещенный переход!

CongratulateUser

Пользователь выбрал вариант "End Game"

StartScreen

ScoldUser

Пользователь выбрал вариант "Next Question"

AskQuestion

ScoldUser

Пользователь выбрал вариант "Correct Answer"

Запрещенный переход!

ScoldUser

Пользователь выбрал вариант "Incorrect Answer"

Запрещенный переход!

ScoldUser

Пользователь выбрал вариант "End Game"

StartScreen

НА ЗАМЕТКУ

Я решил привести в таблице все возможные перестановки переменных, указанных в столбцах "Состояние" и "Внешний ввод", чтобы проиллюстрировать тот факт, что не любое изменение состояния разрешено. Переходы между состояниями, указанными в строках, для которых в столбце "Следующее состояние" содержится пояснение "Запрещенный переход!", недопустимы в нашем приложении. Если приложение пытается каким-либо образом осуществить такое изменение состояния, значит, в логике его выполнения присутствуют ошибки. В случае если предпринимается попытка выполнения недействительного перехода, логика конечного автомата должна возбуждать исключение или, по крайней мере, использовать оператор ASSERT в режиме отладки. Явная идентификация запрещенных переходов между состояниями облегчает отладку приложений.

В листинге 5.1 представлен код, реализующий определенный выше конечный автомат. Этот код соответствует диаграмме переходов, представленной в табл. 5.1 и на рис. 5.1. Обратите внимание на то, что в приведенной ниже функции участки кода, соответствующие различным изменениям состояний, содержат вызовы функций, отключенные с помощью символов комментариев. Эти функциональные вызовы представляют ту часть работы, которая должна быть выполнена для соответствующего изменения состояния, и отключены символами комментариев с той целью, чтобы приведенный ниже код можно было компилировать как независимый блок; реализация вызываемых функций остается за вами. Для определения текущего варианта изменения состояния удобно использовать блок операторов switch/case.

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

Листинг 5.1. Простой код конечного автомата для игры с множественным выбором

class MyStateMachineClass {

private enum GameState {

StartScreen, AskQuestion, CongratulateUser, ScoldUser

}

private GameState m_CurrentGameState;

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

//Конечный автомат, воздействующий на пользовательский интерфейс

//и управляющий переходами приложения в другие состояния в соответствии

//c текущим режимом работы пользователя

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

private void StateChangeForGame(GameState newGameUIState) {

//Определить, в какое состояние переходит приложение

switch(newGameUIState) {

case GameState.StartScreen:

//Если переход в данное состояние осуществляется из состояния,

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

if ((m_CurrentGameState != GameState.CongratulateUser) && (m_CurrentGameState != GameState.ScoldUser)) {

throw new System.Exception("Запрещённый переход!");

}

//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

// элементов управления пользовательского интерфейса

// 2. Настройка переменных/состояния игры, соответствующих

// данному режиму работы

//

// SetUpGameStateForStartScreen();

break;

case GameState.AskQuestion:

//Если переход в данное состояние осуществляется из состояния,

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

if ((m_CurrentGameState != GameState.StartScreen)

&& (m_CurrentGameState != GameState.CongratulateUser)

&& (m_CurrentGameState !=GameState.ScoldUser)) {

throw new System.Exception("Запрещённый переход!");

}

//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

// элементов управления пользовательского интерфейса

// 2. Настройка переменных/состояния игры, соответствующих

// данному режиму работы

//

// SetUpGameStateForAskQuestion();

break;

case GameState.CongratulateUser:

//Если переход в данное состояние осуществляется из состояния,

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

if (m_CurrentGameState != GameState.AskQuestion) {

throw new System.Exception("Запрещённый переход!");

}

//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

// элементов управления пользовательского интерфейса

// 2. Настройка переменных/состояния игры, соответствующих

// данному режиму работы

//

// SetUpGameStateForCongratulateUser();

break;

case GameState.ScoldUser:

//Если переход в данное состояние осуществляется из состояния,

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

if (m_CurrentGameState != GameState.AskQuestion) {

throw new System.Exception("Запрещённый переход!");

}

//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

// элементов управления пользовательского интерфейса

// 2. Настройка переменных/состояния игры, соответствующих

// данному режиму работы

//

// SetUpGameStateForScoldUser();

break;

default:

throw new System.Exception("Неизвестное состояние!");

}

//Сохранить запрошенное новое состояние в качестве текущего

m_CurrentGameState = newGameUIState;

}

} //Конец класса

Явно и неявно определенные конечные автоматы

Планируете ли вы это или не планируете, но ваш код будет так или иначе управляться состояниями. Например, если какой-либо элемент управления необходимо сделать недоступным для пользователя, то разработчики часто добиваются этого, устанавливая для свойств Enabled и Visible этих элементов управления значение false (например, TextBox1.Visible = false;). Для написания кода такого типа существует два возможных подхода, которые рассматриваются ниже

Подход 1: зависящее от специфики конкретной ситуации, децентрализованное, неявное управление состояниями (неудачный подход)

Специализированный стиль проектирования, ориентированный на максимально возможный учет специфики конкретной задачи, часто встречается в тех случаях, когда приложение в процессе разработки постепенно усложняется. Различные аспекты состояния приложения изменяются в разных местах приложения. Данные о состоянии хранятся в таких свойствах элементов управления, как Visible, Enabled, Size или Position. Переменные, используемые для хранения ключевой информации о состоянии, изменяются непосредственно в тех строках кода, где это оказывается необходимым, а загрузка данных и освобождение памяти от них распределяются по всему приложению в зависимости от конкретной ситуации. Развитие событий напоминает "перетягивание каната" между различными частями приложения, поскольку каждая из функций делает все необходимое для выполнения возложенных на нее задач, не обращая никакого внимания на остальную часть приложения. Простейшим примером подобного поведения может служить код, реагирующий на такие события пользовательского интерфейса, как щелчок на кнопке, которой соответствует встроенный код, изменяющий состояние приложения. В листинге 5.2 приведен типичный код, встречающийся в классах формы приложения, соответствующих описанному подходу. Как код события загрузки формы form1, так и код события щелчка кнопки button1 вносят изменения, которые влияют на общее состояние формы.

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

//Код, выполняющийся при загрузке формы

private void Form1_Load(object sender, System.EventArgs e) {

textBox1.Visible = true;

listBox1.Visible = false;

}

string m_someImportantInfo;

//Пользователь щелкнул на кнопке, желая перейти к выполнению

//следующего шага, предусмотренного в данном приложении. Скрыть

//текстовое окно и отобразить окно списка в отведенном для этого месте

private void button1_Click(object sender, System.EventArgs e) {

m_someImportantInfo = textBox1.Text;

textBox1.Visible = false;

listBox1.Visible = true;

}

Подход 2: плановое, централизованное, явное управление состояниями (удачный подход)

Явное управление состояниями — прямая противоположность предыдущему подходу. В этом случае любые переходы между состояния реализуются в рамках одной главной функции. В коде обработчика событий, ответственном за изменение некоторого аспекта состояния приложения, это обеспечивается вызовом единственной функции, которая также вызывается любым другим кодом, предназначенным для изменения состояния приложения в соответствии с логикой приложения. Пример реализации такого подхода представлен в листинге 5.3.

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

string m_someImportantInfo;

//Определить состояния, в которых может находиться приложение

enum MyStates {

step1, step2

}

//Главная функция, которая вызывается

//всякий раз, когда возникает необходимость

//в изменении состояния приложения

void ChangeApplicationState(MyStates newState) {

switch (newState) {

case MyStates.step1:

textBox1.Visible = true;

listBox1.Visible = false;

break;

case MyStates.step2:

m_someImportantInfo = textBox1.Text;

textBox1.Visible = false;

listBox1.Visible = true;

break;

}

}

//Пользователь щелкнул на кнопке, желая перейти к выполнению

//следующего шага, предусмотренного в данном приложении. Скрыть

//текстовое окно и отобразить окно списка в отведенном для этого месте

private void button1_Click(object sender, System.EventArgs e) {

//Вызвать главную функцию, осуществляющую изменение состояния

ChangeApplicationState(MyStates.step2);

}

//Код, выполняющийся при загрузке формы

private void Form1_Load(object sender, System.EventArgs e) {

//Вызвать главную функцию, осуществляющую изменение состояния

ChangeApplicationState(MyStates.step1);

}

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

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

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

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

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

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

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

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

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

Сколько конечных автоматов должно быть в приложении?

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

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

Ниже приведены описания некоторых полезных конечных автоматов, которые вы можете использовать в своих проектах.

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

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

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

На рис. 5.2 представлены состояния пользовательского интерфейса нашей обучающей словарной игры для Pocket PC. Верхняя часть экрана отведена игровому полю. Персонаж перемещается по игровому полю, собирая объекты, если пользователь правильно отвечает на вопросы. На схеме представлены четыре состояния приложения, а стрелками указаны возможные переходы между состояниями пользовательского интерфейса (ПИ)

Рис. 5.2. Различные состояния пользовательского интерфейса в игре с множественным выбором

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

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

Конечный автомат для модели памяти

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

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

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

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

■ Какой объем данных должен загружаться в каждый момент времени, чтобы пользователь имел возможность работать эффективно?

■ Когда и при каких условиях следует освобождать память от загруженных ранее данных?

■ Какой формат хранения данных в памяти является наиболее подходящим? При небольших объемах данных целесообразно выбирать тот формат, который более всего удобен с точки зрения программирования. С увеличением объема данных, например, при большом количестве строк, извлекаемых из базы данных, обязательным условием становится использование формата данных, оптимизированного в отношении расхода памяти и применяемых вычислительных методов. Кроме того, предусматриваемая модель должна обеспечивать сохранение в памяти недавно использованных данных и очистку памяти от всех остальных данных.

■ Существуют ли данные, которые было бы целесообразно кэшировать в памяти на все время работы? Вовсе не обязательно немедленно выгружать из памяти объекты, как только непосредственная необходимость в них исчезла, если спустя несколько мгновений приложение будет вынуждено вновь загружать их в память или заново воссоздавать. Память — это ресурс, благоразумное использование которого исключает как излишнюю расточительность, так и излишнюю скаредность. Есть ли смысл экономить на памяти, если положительный эффект от этого перекроется проигрышем во времени обработки?

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

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

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

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

Конечный автомат для фоновых задач

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

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

■ Загрузка или сохранение больших объемов данных. Загрузка нескольких сотен порций информации из XML-файла или базы данных может занимать довольно большое время.

■ Сетевые операции. Почти все операции, выполняемые в сети, подвержены риску задержек и других проблем связи.

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

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

Ниже приводится пример, иллюстрирующий использование конечного автомата для управления фоновыми вычислениями, выполнение которых может занимать много времени. Целью этих вычислений является нахождение ближайшего простого числа (prime), превышающего заданное целое число. Соответствующий код может выполняться либо в синхронном режиме в целях отладки, либо в асинхронном режиме, позволяющем избежать блокирования пользовательского интерфейса на время проведения вычислений. На рис. 5.3 представлена схема простого конечного автомата, при помощи которого фоновый поток выполнения может предоставлять информацию о своем состоянии. Кроме того, этот конечный автомат позволяет потоку пользовательского интерфейса возможность направлять фоновому потоку запросы, требующие прекратить выполнение.

Рис. 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. Код программы нахождения простых чисел, предназначенный для выполнения фоновым потоком

using System;

public class FindNextPrimeNumber {

//Определить возможные состояния

public enum ProcessingState {

notYetStarted,

waitingToStartAsync,

lookingForPrime,

foundPrime,

requestAbort,

aborted

}

int m_startTickCount;

int m_endTickCount;

long m_startPoint;

long m NextHighestPrime;

ProcessingState m_processingState;

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

//Простейший конечный автомат

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

public void setProcessingState(ProcessingState nextState) {

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

// Простейший защитный код, гарантирующий невозможность

// перехода в другое состояние в случае успешного

// завершения задачи или успешной отмены ее выполнения

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

if ((m_processingState == ProcessingState.aborted) || (m_processingState == ProcessingState.foundPrime)) {

return;

}

//Разрешить изменение состояния

lock(this) {

m_processingState = nextState;

}

}

public ProcessingState getProcessingState() {

ProcessingState currentState; //Безопасное выполнение потока

lock(this) {

currentState = m_processingState;

}

return currentState;

}

public int getTickCountDelta() {

if (getProcessingState() == ProcessingState.lookingForPrime) {

throw new Exception("Продолжается поиск простого числа! Окончательное время еще не вычислено");

}

return m_endTickCount - m_startTickCount;

}

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

// Возвращает простое число

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

public long getPrime() {

if (getProcessingState() != ProcessingState.foundPrime) {

throw new Exception("простое число еще не найдено!");

}

return m_NextHighestPrime;

}

//Конструктор класса

public FindNextPrimeNumber(long startPoint) {

setProcessingState(ProcessingState.notYetStarted);

m_startPoint = startPoint;

}

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

// Создает новый рабочий поток, который будет вызывать функцию

// "findNextHighestPrime()"

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

public void findNextHighestPrime_Async() {

System.Threading.ThreadStart threadStart;

threadStart =  new System.Threading.ThreadStart(findNextHighestPrime);

System.Threading.Thread newThread;

newThread = new System.Threading.Thread(threadStart);

//Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.waitingToStartAsync);

newThread.Start();

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

// Основной рабочий поток. Этот поток запускает поиск очередного

// простого числа и выполняется до тех пор, пока не произойдет

// одно из следующих двух событий:

// (а) найдено очередное простое число

// (b) от внешнего (по отношению к данному) потока поступила команда

// прекратить выполнение

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

public void findNextHighestPrime() {

//Если поступила команда прекратить выполнение, то поиск

//даже не должен начинаться

if (getProcessingState() == ProcessingState.requestAbort) {

goto finished_looking;

}

//Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.lookingForPrime);

m_startTickCount = System.Environment.TickCount;

long currentItem;

//Проверить, является ли число нечетным

if ((m_startPoint & 1) == 1) {

//Число является нечетным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 2;

} else {

//Число является четным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 1;

}

//Приступить к поиску простого числа

while(getProcessingState() == ProcessingState.lookingForPrime) {

//B случае нахождения простого числа возвратить его

if (isItemPrime(currentItem) == true) {

m_NextHighestPrime = currentItem; //Обновить состояние

setProcessingState(ProcessingState.foundPrime);

}

currentItem = currentItem + 2;

}

finished_looking:

//Выход. К этому моменту либо от другого потока поступила

//команда прекратить поиск, либо было найдено и записано

//следующее наибольшее простое число

//Зафиксировать время

m_endTickCount = System.Environment.TickCount;

//Если поступил запрос прекратить выполнение,

//сообщить, что выполнение процесса прекращено

if (getProcessingState() == ProcessingState.requestAbort) {

setProcessingState(ProcessingState.aborted);

}

}

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

//Вспомогательная функция, которая проверяет, является

//ли число простым

private bool isItemPrime(long potentialPrime) {

//Если число — четное, значит, оно не является простым

if ((potentialPrime & 1) == 0) {

return false;

}

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

//значение квадратного корня из числа

long end_point_of_search;

end_point_of_search = (long) System.Math.Sqrt(potentialPrime) + 1;

long current_test_item = 3;

while (current_test_item <= end_point_of_search ) {

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

// Проверить, не поступила ли команда прекратить выполнение!

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

if (getProcessingState() != ProcessingState.lookingForPrime) {

return false;

}

//Если число делится без остатка,

//значит, оно не является простым

if (potentialPrime % current_test_item == 0) {

return false;

}

//Увеличить число на два

current_test_item = current_test_item + 2;

}

//Число является простым return true;

}

} //конец класса

В листинге 5.5 содержится код, который может быть помещен в форму для тестирования приведенного выше алгоритма фоновой обработки.

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

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

// Код, обрабатывающий событие щелчка на кнопке Button1 формы

//

// Вызвать из этого потока функцию поиска простого числа!

// (Это приведет к блокированию потока)

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

private void button1_Click(object sender, System.EventArgs e) {

long testItem;

testItem = System.Convert.ToInt64("123456789012345");

FindNextPrimeNumber nextPrimeFinder;

nextPrimeFinder = new FindNextPrimeNumber(testItem);

nextPrimeFinder.findNextHighestPrime();

long nextHighestPrime;

nextHighestPrime = nextPrimeFinder.getPrime();

System.Windows.Forms.MessageBox.Show(System.Convert.ToString(nextHighestPrime));

//Сколько времени заняли вычисления?

int calculation_time;

calculation_time = nextPrimeFinder.getTickCountDelta();

System.Windows.Forms.MessageBox.Show(System.Convert.ToString(calculation_time) + " мс");

}

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

// Код, обрабатывающий событие щелчка на кнопке Button2 формы

//

// Вызвать функцию поиска простого числа из другого потока!

// (Данный поток блокироваться не будет)

// Для отслеживания состояния выполнения задачи используем конечный автомат

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

private void button2_Click(object sender, System.EventArgs e) {

long testItem;

testItem = System.Convert.ToInt64("123456789012345");

FindNextPrimeNumber nextPrimeFinder;

nextPrimeFinder = new FindNextPrimeNumber(testItem);

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

// Выполнить обработку в другом потоке

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

nextPrimeFinder.findNextHighestPrime_Async();

//Войти в цикл и ожидать до тех пор, пока не будет найдено

//простое число или выполнение не будет прекращено

while ((nextPrimeFinder.getProcessingState() != FindNextPrimeNumber.ProcessingState.foundPrime) &&

(nextPrimeFinder.getProcessingState() != FindNextPrimeNumber.ProcessingState.aborted)) {

//ТОЛЬКО В ТЕСТОВОМ КОДЕ:

//Отобразить окно сообщений и предоставить пользователю

//возможность убрать его с экрана.

//Это позволяет организовать паузу!

System.Windows.Forms.MessageBox.Show("Поиск продолжается... Щелкните на кнопке OK");

//Мы могли бы прекратить поиск путем следующего вызова функции:

//nextPrimeFinder.setProcessingState(

// FindNextPrimeNumber.ProcessingState.requestAbort);

}

//Осуществить корректный выход в случае прекращения поиска

if (nextPrimeFinder.getProcessingState() == FindNextPrimeNumber.ProcessingState.aborted) {

System.Windows.Forms.MessageBox.Show("Поиск прекращен!");

return;

}

long nextHighestPrime;

nextHighestPrime = nextPrimeFinder.getPrime();

System.Windows.Forms.MessageBox.Show(System.Convert.ToString(nextHighestPrime));

//Сколько времени заняли вычисления?

int calculation_time;

calculation_time = nextPrimeFinder.getTickCountDelta();

System.Windows.Forms.MessageBox.Show(System.Convert.ToString(calculation_time) + " мс");

}

Для выполнения примера с использованием указанного в листинге начального числа (123456789012345) на моем эмуляторе Pocket РС требовалось от 10 до 20 секунд. Исследуйте зависимость времени вычислений от количества цифр в начальном числе. (Как правило, с увеличением количества цифр время вычислений увеличивается.)

НА ЗАМЕТКУ

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

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

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

Резюме

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

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

ГЛАВА 6

Шаг 0: прежде чем приступать к работе, определите сферу применения приложения

Руби Гольдберг (Rube Goldberg) (1883-1970) — художник-карикатурист, рисовавший механизмы, предназначенные, несмотря на всю фантастичность своей конструкции, для выполнения самых обычных операций. Каждый из этих механизмов представлял собой завораживающее сплетение всевозможных рычагов, шкивов и пружин и снабжался забавным описанием принципов его работы. Вам следовало бы очень внимательно ознакомиться с запутанным внутренним устройством этих механизмов, чтобы впоследствии никогда не допускать ничего подобного при разработке своих приложений для мобильных устройств. Стремитесь к простоте и действуйте всегда целенаправленно!

Иво Салмре

(чтобы получить представление о механизмах Руби Гольдберга, посетите Web-сайт http://www.rube-goldberg.com/)

Введение

В название этой главы присутствует "Шаг 0", поскольку в книге, посвященной главным образом тому, как создавать приложения для мобильных устройств, ваше внимание должно быть обращено на необходимость получения в первую очередь ответа на следующий вопрос: "Какие конкретные задачи должны решаться при помощи данного мобильного приложения?" Очень важно всегда иметь для разрабатываемого приложения подходящий набор конечных целей. В процессе того, как вы будете ближе знакомиться с возможностями и ограничениями вашего целевого устройства, а также по мере появления новых или уточнения существующих требований в результате тестирования приложения, задачи разработки могут изменяться, но вы всегда должны хорошо представлять себе общую конечную цель, которая должна быть достигнута по завершении разработки. Приложение, для которого ясно не определены цели и сферы применения, обречено потонуть в море посредственных возможностей. Гораздо лучше выделить несколько важных задач, в которых будут больше всего заинтересованы пользователи мобильного устройства, и обеспечить возможность их эффективного решения, чем пытаться втиснуть все, что только возможно, в рамки одного универсального приложения.

Цель этой короткой главы состоит в том, чтобы помочь вам правильно очертить границы проекта разрабатываемого мобильного приложения. Успешность подобных приложений зависит от того, насколько они сфокусированы на решении строго определенного круга задач. Работа с мобильными приложениями, предназначенными для повышения производительности труда, обычно ведется в виде коротких сеансов, во время которых пользователь получает и изменяет данные или запрашивает услуги. Правильно определив набор необходимых средств, вы предоставите пользователям возможность быстрейшего получения информации и услуг, в которых они нуждаются. Вероятно, мобильное приложение с множеством форм, для просмотра и изучения которых пользователю понадобится более 20 минут, вряд ли можно считать соответствующим этому критерию; 20 секунд — вот те временные рамки, на которые вы должны ориентироваться. To же самое относится и к приложениям развлекательного характера; отличная мобильная игра должна быть простой в использовании, быстро запускаться и учитывать специфику кратковременных сеансов.

Независимое приложение или часть большой системы?

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

Независимые приложения

Простая игровая или вычислительная программа может быть выполнена в виде независимого приложения. Независимые приложения характеризуются отсутствием взаимодействия с другими приложениями и предоставляют пользователям лишь ограниченный набор средств, к которым возможен быстрый доступ. Если ваше приложение попадает в эту категорию, то определить сферу его применения будет сравнительно просто. Однако даже в этом случае могут потребоваться некоторые уточнения. Например, калькулятор, позволяющий быстро складывать, вычитать, умножать и делить числа, и калькулятор, предназначенный для решения алгебраических уравнений и построения графиков, должны фокусироваться на совершенно разных вещах. Можно предположить, что модели пользовательских интерфейсов и навигации в этих приложениях должны значительно различаться между собой. В каждом из этих случаев пользователям хотелось бы иметь возможность решать за 20 секунд совершенно непохожие задачи, а это требует расстановки различных акцентов в процессе проектирования приложений. Даже в случае небольших независимых приложений вопрос о сфере их применения не теряет своей актуальности.

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

Большинство приложений, заслуживающих интереса, взаимодействуют с другими системами. В некоторых случаях вместо варианта, предусматривающего создание одного крупного многоцелевого приложения, можно выбрать вариант создания набора приложений, установленных на одном устройстве, которые осуществляют совместный доступ к локальной базе данных. Каждое приложение может быть ориентировано на решение отдельного круга задач и разрабатываться так, чтобы наилучшим образом обеспечить достижение соответствующих целей. При построении набора приложений, которые будут совместно работать с разделяемыми данными, важно как можно точнее определить, что именно каждое приложение должно делать, а что не должно. Хорошим примером разделения функций между отдельными приложениями может служить набор офисных приложений. Типичное программное обеспечение офисного набора включает в себя текстовый процессор, программу для выполнения расчетов (электронные таблицы), а также программное обеспечение для подготовки презентационных материалов и обеспечения связи. Указанные программы могут взаимодействовать между собой множеством способов и разделять общие данные и компоненты, но сомнения в отношении того, какое из приложений больше всего подходит для решения той или иной задачи, возникают лишь в очень редких случаях. Кое-кому может показаться, что отдельные офисные приложения сами по себе являются слишком сложными, чтобы каждое из них можно было считать ориентированным на решение узкого круга задач, однако представьте, что бы произошло, если бы все они были объединены в одно огромное "суперприложение". Результат напоминал бы собой некий конгломерат. Залог создания успешных мобильных приложений — минимизация их размеров и специализация выполняемых ими функций

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

У конечного пользователя не должно возникать никаких сомнений относительно того, каким именно инструментом следует воспользоваться для решения той или иной конкретной задачи. Размытие целевого назначения приложений в пределах набора говорит о незавершенности продукта или разработке проекта путем незапланированного наращивания его возможностей, когда вместо систематического создания заранее предусмотренных средств существующие приложения дорабатываются в специализированном стиле по мере выявления новых потребностей. Если в процессе разработки мобильного приложения у вас рождается идея "убийственного сценария", задайтесь вопросом, следует ли включать этот сценарий в состав существующего приложения или лучше реализовать его надлежащим образом в виде независимого приложения. Можно легко объединить приложения в одно целое, но выделить вплетенный в тело приложения код очень непросто. Если вы сомневаетесь в том, как лучше поступить, начните с создания независимого приложения, не забыв при этом о правиле "20 секунд": пользователь, действуя без спешки, должен успевать достать устройство из кармана и перейти к разделу с нужной информацией в течение не более 20 секунд.

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

Многие из установленных на устройствах приложения взаимодействуют с внешними ресурсами, например, с данными, которые хранятся на настольном компьютере, доступны на сервере предприятия или предлагаются Internet-службами. Определяя сферу применения мобильных приложений, являющихся частью более крупных систем, необходимо не забывать о двух важных вещах:

1. Определите ключевой набор сценариев работы с устройством. Сценарии использования приложений для настольных компьютеров и Web-приложений значительно отличаются от сценариев использования мобильных приложений, и поэтому простой перенос функциональных возможностей соответствующих приложений на мобильные устройства является оправданным лишь в очень редких случаях. Очень важно, чтобы вы могли дать ответы на следующие вопросы. Быстрое решение каких задач может потребоваться пользователям данного приложения при работе в мобильных условиях? Каковы те ключевые элементы, необходимость быстрого поиска или выполнения которых может заставить пользователя извлечь устройство из кармана? От ответов на эти вопросы зависят сценарии использования вашего мобильного приложения.

2. Определите будет ли устройство взаимодействовать с данными, хранящимися на настольных компьютерах или серверах. При работе крупных приложений часто используются экземпляры данных, разбросанные по самым разным местам. Данные могут храниться на нескольких серверах, на настольных компьютерах и на устройствах. Очень важно иметь ясную картину того, с какими данными будет взаимодействовать ваше мобильное приложение. Если у вас есть возможность выбирать, с какими данными следует организовать взаимодействие, — теми, которые хранятся на сервере, или теми, которые хранятся на настольном компьютере, — то наиболее подходящим почти всегда будет второй вариант. Это обусловлено двумя причинами: 1) обычно данные, хранящиеся на настольном компьютере, являются локальной кэшированной копией серверных данных, реальное текущее состояние не всегда отражается правильно, и 2) в то время как настольный компьютер не всегда может быть доступным, серверы специально проектируются таким образом, чтобы обеспечивалась возможность постоянного доступа к ним. Обычно если принимается решение о том, что мобильное устройство должно синхронизироваться с данными, хранящимися на настольном компьютере, а не на сервере, то это делается на основе тактических, а не прочно обоснованных стратегических соображений. В качестве оправдания указанной близорукой политики приводят, например, такую аргументацию: "Я не могу получить разрешение на доступ к находящимся на сервере данных с мобильного устройства, и поэтому вынужден обратиться к модели, которая обеспечивает синхронизацию с данными, хранящимися на настольном компьютере" или "Структуры данных, хранящихся на серверах, слишком сложны для обработки, в то время как на настольных компьютерах данные хранятся в простых форматах, и поэтому синхронизация с ними осуществляется легче". Постарайтесь устоять перед подобного рода соблазнами. Если данные действительно хранятся на сервере, то вы должны организовать синхронизацию именно с ними, даже если для этого и придется создавать промежуточное серверное решение, поддерживающее получение доступа к данным. Формирование продуманной архитектуры взаимодействия с другими звеньями вашего приложения сторицей окупит себя в отношении надежности и сроков разработки. Кратковременным тактическим решениям свойственно очень быстро превращаться в непрерывный долговременный кошмар сопровождения. Корректная оценка сферы применения вашего мобильного приложения требует того, чтобы вы руководствовались отчетливой схемой, отражающей взаимодействие приложения с внешними по отношению к устройству системами.

Не пытайтесь просто переносить на устройства приложения, рассчитанные на настольные компьютеры! Мыслите категориями устройств!

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

Стереотипы использования мобильного и настольного программного обеспечения

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

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

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

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

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

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

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

Именно поэтому ведется работа по выделению в Internet отдельного домена высшего уровня (например, .mobile, а не .com), предоставляющего содержимое специально для мобильных устройств. Мобильные устройства вскоре станут очень важными участниками деятельности в Internet, но использоваться в работе они будут не так, как браузеры современных настольных компьютеров. Ближайшее будущее обещает нам много интересного, поскольку можно ожидать появления в Web множества новшеств, специфических для мобильных устройств, а не простого переформулирования идей программного обеспечения, разработанного для настольных компьютеров.

Шаги по определению сферы применения мобильного приложения

Ниже перечислены шаги, которым вы должны следовать при определении сферы применения вашего мобильного приложения.

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

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

3. Создайте начальный прототип. Располагая современным инструментарием RAD (Rad Application Development — быстрая разработка приложений), можно сравнительно легко создавать начальные прототипы того, что вы задумали. Создание прототипов — отличная вещь. Подготовка и выполнение прототипов на устройстве поможет вам лучше изучить возможности и ограничения выбранного вами оборудования и выявить проблемы проекта, которые вы могли упустить. Помимо этого, наличие выполняющегося прототипа сделает возможной оценку дееспособности определенных вами сценариев использования приложения

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

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

6. Проанализируйте, реализуемы ли для выбранного целевого устройства заложенные в прототипе приложения допущения, касающиеся вопросов обмена информацией. Критически оцените потребности вашего мобильного приложения в обмене информацией и взаимодействии с другими системами. Требуется ли высокоскоростной доступ в сеть? Существует ли необходимость в роуминге? Смогут ли соединение с сетью и синхронизация данных через настольный или переносной компьютер в достаточной мере удовлетворить потребности вашего мобильного приложения в обмене информацией?

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

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

ГЛАВА 7

Шаг 1: начинайте с анализа проблем производительности и никогда не упускайте их из виду

per• form• ance [pr fáwrmns] производительность: эффективность выполнения кем-то или чем-то определенной работы

(Encarta 2004, Dictionary)

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

Автор данной главы

Введение

Как указано в приведенной выше выдержке из словаря, производительность — это не просто скорость, но эффективность выполнения. Считаться полезным может лишь код, который выполняется эффективно. Производительность вашего мобильного приложения будет первым и главным критерием, по которому пользователи будут судить о его качестве и эффективности. Хотя высокая производительность приложения сама по себе не может гарантировать его успешности, однако если она не обеспечена — все ваши усилия заведомо обречены на неудачу.

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

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

Важность планомерного подхода

Томас Эдисон, который сам был человеком не слабым в изобретательстве, как-то сказал: "Гений — это один процент вдохновения и девяносто девять процентов пота". Достижение высокой производительности — это 80 процентов кропотливой работы и 20 процентов творчества. Соблюдение определенной дисциплины в процессе разработки приложения позволит своевременно обнаруживать появление проблем, обусловленных низкой производительностью, и не даст вам возможности игнорировать их или отложить их решение на более поздний период работы. Всегда существует соблазн не обращать на проблемы производительности никакого внимания; само по себе устранение проблем упомянутого рода не обогащает приложение никакими новыми средствами, так что эта работа считается не особенно интересной. Вместе с тем, если вы хотите преуспеть в разработке мобильного приложения, к которой приступаете, то систематическое решение проблем производительности играет в этом ключевую роль. Стиль работы, основанный на планировании, позволит вам не только выявить проблемы производительности на самых ранних стадиях разработки, но и найти соответствующие решения еще до того, как указанные проблемы успеют прочно вплестись в канву вашего проекта. С большинством этих проблем вы сможете справиться путем подходящей адаптации идей, изложенных в этой главе, а также реализации собственных идей, которые появятся у вас в процессе дальнейшей работы над проектом. Если с аналогичными ситуациями вы ранее не сталкивались, случайный проблеск творческого озарения может подсказать вам новое решение, которое до сих пор никому в голову не приходило, что позволит вам вдохнуть в свой проект новую жизнь. Самое главное — это придерживаться определенной самодисциплины, заставляющей вас не закрывать глаза на проблемы производительности, которые неизбежно возникнут, а заниматься ими до тех пор, пока они не будут разрешены. Когда Томас Эдисон испытывал нити накала для изобретенной им лампочки, ему пришлось перепробовать сотни различных материалов, прежде чем он смог остановиться на том, который обеспечивал наилучшее сочетание светимости и срока службы нити. Точно так же обстоит дело и с производительностью: получение нужного результата требует постоянного тестирования приложения и оценки качества его функционирования. Как показывает пример Эдисона, целеустремленность, настойчивость и творческий дух окупают себя сторицей.

Определите обязательные характеристики сценариев рабочих сеансов пользователя

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

■ При любых обстоятельствах пользователь не должен оставаться без визуального подтверждения того, что работа выполняется, на протяжении промежутков времени длительностью более 0,5 секунды.

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

Другие сценарии могут быть более конкретными:

■ На запуск нового сеанса шахматной игры должно уходить не более 1 секунды.

■ Для доступа к информации о заказах клиентов должно требоваться не более 3 секунд.

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

Определите контрольные точки разработки, критерии завершения которых ориентированы на достижение высокой производительности

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

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

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

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

Очень важно, чтобы проект не хромал на контрольных точках и проходил их твердо и уверенно, а члены группы были едины в своих действиях и по завершении этапа испытывали чувство гордости за проделанную работу. Всегда существует искушение заняться проблемами производительности "когда-нибудь потом", поскольку их решение непосредственно не венчается созданием каких-либо новых инструментальных средств или возможностей; ни в коем случае не поддавайтесь этому соблазну! Как неоднократно доказано на практике, гораздо лучше пройти контрольную точку, пусть и с нарушением установленных сроков, но строго выполнив все необходимые требования, чем быстро ее проскочить, ограничившись компромиссными решениями.

Ослабление критериев завершения этапов нисколько не ускорит вашего приближения к конечной цели. Если вы видите, что график работ нарушается, то можете выбрать один из трех возможных вариантов дальнейших действий:

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

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

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

Строгое соблюдение критериев завершения контрольных точек в той части, которая касается поддержания высокой производительности приложения, играет чрезвычайно важную роль по той простой причине, что добиться существенного улучшения производительности впоследствии без кардинального пересмотра проекта обычно оказывается невозможным. Типичные оправдания, подобные такому: "Главное сейчас — это завершить разработку готового варианта работоспособного кода к намеченному сроку, а проблемами производительности можно будет заняться и позже, при прохождении последующих контрольных точек", не выдерживают никакой критики. Справляться с проблемами производительности на более поздних стадиях производственного цикла всегда сложнее, поскольку с увеличением объема написанного кода зависимости между его отдельными частями только усиливаются, и это делает внесение необходимых изменений в проект все более затруднительным. Если кто-то говорит: "Проблемами производительности и их устранением мы займемся позже", то истинный смысл этого таков: "Мы не понимаем сути проблем производительности, с которыми столкнулись, и пока не можем сказать, каким образом собираемся устранять их в будущем. To, что мы создаем сейчас, — это прототип, который, как бы то ни было, может быть подготовлен к поставке; чтобы создать действительно завершенную версию приложения, нам, вероятно, придется переписать значительную часть кода".

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

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

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

■ Можно ли исключить или сократить периоды задержек путем технической доработки проекта?

■ Можно ли обрабатывать задержки, вызывая заставки или отображая курсоры ожидания, уведомляющие пользователя о том, что выполнение приложения продолжается?

■ Можно ли передать выполнение задачи фоновому потоку, чтобы обеспечить сохранение пользовательским интерфейсом постоянной способности к отклику?

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

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

К числу вопросов, на которые необходимо дать ответ, пересматривая критические алгоритмы, относятся следующие:

■ Можно ли ускорить выполнение этих алгоритмов путем их настройки или изменения?

■ Можно ли прогнозировать потребность алгоритмов в тех или данных и заблаговременно загружать нужные данные, прежде чем в них возникнет необходимость, чтобы пользователь мог быстрее получить результат?

■ Можно ли выполнять наиболее трудоемкую часть вычислений вне устройства, на сервере?

■ Можно ли произвести некоторые вычисления или подготовить некоторые изображения еще на стадии проектирования, чтобы исключить или уменьшить потребность в проведении соответствующих вычислений на стадии выполнения?

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

Время от времени критически пересматривайте написанный код

Замечательным способом улучшения качества создаваемого вами кода является его периодический критический анализ, направленный на обеспечение высокой производительности приложения. Хотя проектирование по соглашениям — не самая приятная стратегия построения алгоритмов, взаимный анализ кода, написанного разными участниками рабочей группы, является проверенным способом улучшения его качества. Критический анализ кода предоставляет преимущества двоякого рода

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

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

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

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

Определите модель памяти для вашего приложения

Поскольку мобильные приложения выполняются в средах с ограниченными ресурсами памяти, полезно определить и поддерживать явную модель, описывающую способы использования памяти и осуществления управления ею в вашем приложении. В современных высокоуровневых объектно-ориентированных вычислительных средах, использующих механизм сборки мусора (garbage collection), необходимости в отслеживании распределения отдельных областей памяти обычно не возникает, хотя это и может играть важную роль при низкоуровневом программировании таких, например, объектов, как драйверы устройств. Вместо этого гораздо важнее иметь в своем распоряжении модель, описывающую, какие именно объекты и в течение какого времени должны удерживаться в памяти. Рассматривая это как часть процесса проектирования, вы должны дать ответы на следующие вопросы:

■ Какие глобальные ресурсы будут кэшироваться в памяти? Одни объекты целесообразно кэшировать, тогда как хранить в памяти другие объекты было бы слишком расточительно. Трезво оцените, какие объекты к какой категории следует отнести.

■ Какой объем данных приложения будет загружаться в память в каждый момент времени? Большинству приложений приходится иметь дело с довольно крупными объемами данных, лишь часть которых должна быть загружена в память в каждый заданный момент времени.

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

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

Как можно чаще контролируйте показатели, характеризующие работу вашего приложения

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

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

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

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

3. Используйте показатели производительности алгоритмов, генерируемые средой выполнения, а также установленными на устройстве средствами мониторинга работы приложении. Некоторые среды выполнения управляемого кода обеспечивают возможность измерения показателей, характеризующих отдельные аспекты функционирования приложений. В частности, они позволяют определить, сколько времени выполняется тот или иной код, а также отслеживать распределение памяти для размещения объектов и выполнение операций сборки мусора. Информация такого рода может пригодиться вам для настройки алгоритмов и выявления случаев утечки памяти. Наилучшей стратегией при проведении подобного рода анализа является как можно более полная изоляция кода, поведение которого анализируется. Самые точные и реальные характеристики производительности алгоритмов удается получить в тех случаях, когда имеется возможность вычленения интересующего нас фрагмента кода из тела программы, помещения его в отдельный проект с целью последующего выполнения для получения соответствующих показателей. Анализ такого рода оказывается полезным при сравнении эффективности различных алгоритмов. Современные средства мониторинга и отладки кода также способны предоставлять ценную информацию о том, на что расходуется процессорное время. Примечание. Более подробно этот вопрос рассматривается ниже в разделе "Получение информации об основных показателях производительности в .NET Compact Framework".

4. Используйте показатели производительности алгоритмов, генерируемые средствами мониторинга, которые доступны в настольных компьютерах и серверах. Для сред выполнения, функционирующих на настольных компьютерах и серверах, разработаны потрясающие средства, предназначенные для мониторинга работы управляемого кода. В настоящее время средства этой категории пока значительно опережают аналогичные им инструментальные средства, разработанные для устройств; вероятно, в течение некоторого времени такая ситуация будет сохраняться. Частично это объясняется тем, что рынок настольных компьютеров и серверов существует дольше, а частично — тем фактом, что в средах выполнения, предназначенных для настольных компьютеров и серверов, для поддержки утилит мониторинга могут выделяться гораздо большие объемы памяти. Можно ожидать, что в ближайшее время среды выполнения, используемые на устройствах, а вместе с ними и соответствующие средства получения эксплуатационных характеристик программ, получат дальнейшее развитие, однако по-прежнему будут уступать своим аналогам, ориентированным на настольные компьютеры и серверы. Поставляемые для настольных компьютеров и серверов средства, позволяющие анализировать работу приложений, способны обеспечивать получение детальной картины того, на выполнение каких функций приходится основная доля процессорного времени, и какие участки кода могут тормозить выполнение программ. Кроме того, современные средства мониторинга работы кода часто интегрируются в стандартные среды разработки приложений, что значительно упрощает проведение указанного анализа. Запуск кода, изначально предназначенного для устройств, в среде настольного компьютера или сервера позволит вам получить представление о возможностях его выполнения на этих платформах и глубже разобраться в особенностях его поведения в условиях устройств. Примечание. Имейте в виду, что механизмы JIT-компиляции, обработка исключений и стратегии сборки мусора для настольных компьютеров, серверов и устройств могут существенно отличаться друг от друга. Возможности настольных компьютеров и серверов в отношении доступных объемов памяти значительно превышают возможности мобильных устройств, а для каждого типа микропроцессоров существуют свои области вычислений, в которых он превосходит другие типы. Результаты мониторинга работы приложения, полученные на настольном компьютере или сервере, могут дать вам много полезной информации, но некоторые из характеристик приложения при выполнении на устройстве могут измениться. Подобные различия будут становиться особенно заметными тогда, когда в коде интенсивно используются операции файлового ввода-вывода, выполняется обмен данными по сети или обрабатывается графика, поскольку производительность кода в этих случаях будет в значительной мере зависеть от используемого оборудования и операционной системы. Инструментальные средства мониторинга, используемые на настольных компьютерах и серверах, помогут вам развить свою интуицию и глубже разобраться в особенностях распределения памяти для объектов, но окончательные выводы вы должны делать только на основании результатов, полученных при выполнении приложения на устройствах.

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

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

Получение информации об основных показателях производительности в .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 код прост в использовании и имеет небольшие размеры, благодаря чему его включение в мобильное приложение приведет лишь к незначительному увеличению накладных расходов. Этот код предназначен для использования в качестве универсального средства тестирования производительности, при помощи которого вы сможете быстро измерять временные характеристики своих кодов. Это позволит вам быстро оценивать, сколько времени выполняется тот или иной участок разрабатываемого кода, и обнаруживать узкие места, требующие применения новых стратегий. Вы также можете использовать этот код для быстрого сравнения эффективности двух различных подходов, чтобы определить, какой из них лучше соответствует вашим запросам. Так, если для если для настройки пользовательского интерфейса и заполнения иерархического списка в элементе управления TreeView требуется три секунды, то вы можете захотеть изменить алгоритм таким образом, чтобы сначала заполнялись лишь узлы наивысшего уровня, а заполнение дочерних узлов откладывалось на более позднее время и осуществлялось лишь тогда, когда в этом возникнет действительная необходимость. Окончательное решение вы будете принимать на основании результатов соответствующих измерений и оценок качества приложения, предоставляемых конечными пользователями.

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

using System;

internal class PerformanceSampling {

//Значение этого параметра может быть задано произвольным, но количество

//тестовых интервалов, равное 8, представляется достаточным для

// большинства случаев

const int NUMBER_SAMPLERS = 8;

static string[] m_perfSamplesNames = new string[NUMBER_SAMPLERS];

static int[] m_perfSamplesStartTicks = new int[NUMBER_SAMPLERS];

static int[] m_perfSamplesDuration = new int[NUMBER_SAMPLERS];

//Определить начальное значение счетчика тактов системных часов

//для интервала

internal static void StartSample(int sampleIndex, string sampleName) {

m_perfSamplesNames[sampleIndex] = sampleName;

m_perfSamplesStartTicks[sampleIndex] = System.Environment.TickCount;

}

//Определить конечное значение счетчика тактов системных часов

//для интервала

internal static void StopSample(int sampleIndex) {

int stopTickCount = System.Environment.TickCount;

//Счетчик тактов системных часов сбрасывается в ноль каждые 24,9 дня

//(что соответствует примерно 2 миллиардам миллисекунд).

//Эта маловероятная возможность будет принята нами во внимание

if (stopTickCount >=m_perfSamplesStartTicks[sampleIndex]) {

//Обычно будет выполняться этот код

m_perfSamplesDuration[sampleIndex] = stopTickCount - m_perfSamplesStartTicks[sampleIndex];

} else {

//Значение счетчика тактов "перешло" через ноль,

//и мы должны это учесть

m_perfSamplesDuration[sampleIndex] = stopTickCount + (int.MaxValue - m_perfSamplesStartTicks[sampleIndex]) + 1;

}

}

//Возвратить длительность тестового интервала

//(в миллисекундах)

internal static int GetSampleDuration(int sampleIndex) {

return m_perfSamplesDuration[sampleIndex];

}

//Возвращает длительность истекшего тестового

//интервала в секундах

internal static string GetSampleDurationText(int sampleIndex) {

return m_perfSamplesNames[sampleIndex] + ": " +

System.Convert.ToString((m_perfSamplesDuration[sampleIndex] /(double) 1000.0)) +

" секунд.";

}

}

HA ЗАМЕТКУ

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

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

private void button1_Click(object sender, System.EventArgs e) {

const int TEST_SAMPLE_INDEX = 2; //Выберите любое действительное

//значение индекса

//Начать измерение

PerformanceSampling.StartSample(TEST_SAMPLE_INDEX, "TestSample");

//Отобразить окно сообщений

System.Windows.Forms.MessageBox.Show("Для прекращения измерения щелкните на кнопке OK");

//Прекратить измерение

PerformanceSampling.StopSample(TEST_SAMPLE_INDEX);

//Отобразить результаты

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(TEST_SAMPLE_INDEX));

}

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

1. Вы можете пользоваться эмпирическим правилом, в соответствии с которым чем больше длительность события, которую вы измеряете, тем меньше относительная ошибка. Поэтому, если вы сравниваете два алгоритма, для выполнения которых требуется примерно 0,5 секунды, лучше выполнить каждый из них по 10 раз и разделить полученные результаты на 10.

2. Повторяйте каждый эксперимент несколько раз, убеждаясь в том, что получаемые результаты оказываются в достаточной степени близкими друг к другу.

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

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

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

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

Одна из распространенных ошибок, допускаемых разработчиками, состоит в том, что при проектировании и тестировании алгоритмов используются меньшие объемы данных по сравнению с теми, с которыми приходится иметь дело в процессе реальной работы. Реальные данные дольше загружаются и сохраняются и, что немаловажно, могут потреблять большие объемы драгоценной памяти и резко замедлять общую производительность мобильного приложения. Типичными примерами, когда разработчики могут допускать подобную ошибку и осуществлять разработку и тестирование приложений с использованием меньших объемов данных, нежели те, с которыми сталкиваются конечные пользователи, могут служить следующие:

■ Приложение, использующее базу данных, тестируется с использованием 20 записей выбранных данных, тогда как в реальной работе будут использоваться от 200 до 2000 записей.

■ В процессе эксплуатации приложения будет требоваться синтаксический анализ текстового XML-файла. Размер пробного XML-файла составляет 15 Кбайт, в то время как в реальной работе будет использоваться файл размером 300 Кбайт.

■ Проектируется приложение, предназначенное для работы с цифровыми фотографиями. Фотографии загружаются с Web-сервера и сохраняются в локальной кэш-памяти устройства. В процессе разработки приложения используются четыре пробных изображения размером 200 Кбайт каждое, хотя обычный размер фотографий, получаемых при помощи цифрового фотоаппарата, составляет 800 Кбайт (или более).

Легко понять причины, по которым могут совершаться ошибки, проиллюстрированные в приведенных выше примерах. В процессе проектирования приложения форматы данных часто могут меняться, и вам гораздо легче создать файл нужного формата, включив в него 10 записей, а не 200. Кроме того, выполнять и тестировать приложения намного проще, если при их запуске не приходится ожидать загрузки всех данных. К сожалению, конечные пользователи будут лишены этой роскоши, ведь им приходится иметь дело с реальными объемами данных. Поэтому очень важно уже на ранних стадиях процесса проектирования и разработки мобильного приложения перейти к использованию реальных данных или имитирующих их данных сравнимого объема.

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

Тестируйте приложения в предельных режимах

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

■ Размеры файлов/данных на 20% превышают показатели, предусмотренные проектом. Этот уровень соответствует простейшему случаю превышения норм потребления памяти, установленных для вашего приложения. С проблемами такого рода приложение должно быть в состоянии справляться без особого труда.

■ Размеры файлов/данных на 50% превышают показатели, предусмотренные проектом. Этот уровень соответствует наиболее вероятному превышению норм потребления памяти, установленных для вашего приложения. Способно ли приложение корректно разрешить эту ситуацию за счет снижения эффективности выполнения или упомянутая ситуация повлечет за собой неприятные последствия?

■ Размеры файлов/данных на 100% превышают показатели, предусмотренные проектом. Значительное превышение норм потребления памяти.

■ Размеры файлов/данных на 200% превышают показатели, предусмотренные проектом. Действительно жесткие условия тестирования.

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

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

В вашем основном документе проекта должны быть указаны как рекомендуемый максимальный объем используемых данных, так и возможные последствия попыток пользователя работать с превышением пороговых размеров памяти, отведенной для хранения данных.

Своевременно предпринимайте меры по поддержанию высокой производительности приложения (со временем ситуация будет только ухудшаться!)

Я уже говорил об этом раньше и, несомненно, еще неоднократно буду повторять: не откладывайте в долгий ящик работу по поддержанию производительности на высоком уровне! Отложить эту работу — это все равно, что отложить на более поздние сроки устранение трудных ошибок в программе; такая тактика почти никогда не оправдывается. Очень легко убедить себя заняться этой работой позже. Позвольте привести несколько примеров распространенных оправданий, к которым охотно прибегает и автор этих строк:

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

■ Об эффективности кода пока беспокоиться нечего; сейчас я просто воспользуюсь теми приемами программирования, с которыми больше всего знаком, и на скорую руку сделаю основную работу. Позже я выясню, какие алгоритмы тормозят работу приложения, и подумаю над тем, каким образом их следует переписать. И вновь неверно. Если вы напишете заведомо неэффективный код, то прежде, чем вы приметесь за написание своих более эффективных алгоритмов, вам придется его исправлять. Это особенно касается кода, в котором выполняется множество операций со строками, и алгоритмам, которые предполагают распределение памяти для объектов в циклах. Часто не составляет никакого труда уже с самого начала использовать эффективные методики обработки строк или размещения объектов в памяти (далее об этом будет сказано более подробно); для этого надо всего лишь провести небольшое предварительное исследование с целью выяснения того, какие из существующих методик являются наиболее эффективными в используемой вами системе программирования. Можно дать два важных совета, следуя которым вы сможете создавать эффективно выполняющийся код: 1) выберите подходящий алгоритм, который в наибольшей степени соответствует вашим запросам, и 2) программируйте алгоритм с использованием доступных вам эффективных методик. Написание бесполезного кода низкого качества с мыслью о том, что впоследствии он будет исправлен, — это все равно, что пытаться покрасить дом, расплескивая краску по всей стене: вы можете быстро закрасить 80 процентов поверхности стен, но для полного завершения работы вам придется вновь заняться покраской всех стен.

НА ЗАМЕТКУ

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

■ Повышение производительности — это всего лишь тонкая настройка алгоритмов, которые мною уже написаны. В очередной раз неверно. Хотя улучшением отдельных алгоритмов иногда и можно добиться заметного выигрыша в производительности, в остальных случаях для этого может потребоваться существенная переделка проекта. Если только качество написанного вами кода не является совершенно ужасным, наибольший выигрыш в производительности вам может принести не оптимизация алгоритмов, которые вами уже написаны, а фундаментальная реструктуризация модели данных и пользовательского интерфейса вашего приложения, способная резко улучшить производительность. Очень важно не упустить тот момент, когда возникает необходимость в пересмотре фундаментальных положений проекта и поиске конструктивных альтернатив.

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

■ Дальнейшее повышение производительности просто невозможно. Я выжал из приложения все, что можно, и если его производительность низка, то с этим надо просто смириться. Глубочайшее заблуждение. Резервы повышения производительности существуют всегда, но для того, чтобы использовать их, может потребоваться радикальное переосмысление проекта. Возможно, для этого надо будет изменить организацию работы приложения. Возможно, потребуется перенести код с устройства на сервер (или использовать другие обходные пути). Возможно, потребуется предварительное вычисление некоторых данных на стадии проектирования, составить оптимизированные таблицы поиска и поместить их в код. Возможно, потребуется разделить ваше приложение на три меньших. Имеется бесчисленное множество способов "обмануть время" и найти пути повышения производительности приложения. Хотя тот факт, что для выполнения любой отдельной задачи часто существуют алгоритмы, обеспечивающие максимально возможное быстродействие, является сущей правдой, ваше приложение почти никогда не будет сводиться только к какому-то одному алгоритму или задаче. Ваше приложение таково, каким его воспринимает пользователь. Если вам никак не удается добиться приемлемой производительности, и вы убеждены в том, что используемым для ее оценки количественным показателям можно доверять, значит наступил момент, когда вы должны активизировать свое творческое воображение. Вспомните старую истину: "Необходимость — мать изобретательности". Величайшие открытия совершаются именно тогда, когда возникают, казалось бы, непреодолимые трудности, поскольку они заставляют вас задуматься об истинной природе проблемы, которую вы пытаетесь решить. Если производительность приложения остается низкой, то причиной этого, как правило, является недостаток творческого воображения, мешающий взглянуть на проблему с новой стороны. Станьте на голову и постойте в таком положении некоторое время или сделайте еще что-нибудь, что способно активизировать ваше творческое мышление. Решение обязательно появится.

Решение проблем производительности по мере их возникновения позволит вам уверенно переходить от одной стадии разработки приложения к другой. Если производительность приложения вдруг резко упала, вы можете вернуться назад к известной точке, в которой все показатели были нормальными, и вновь использовать ее в своей работе в качестве отправной точки. Уст ранение проблем производительности по мере продвижения работы во многом подобно подъему по скале с использованием страховки, когда вы разбиваете маршрут на отдельные участки, в конце каждого из которых забиваете страховочные клинья; единственное, чем вы рискуете, если сорветесь — так это тем, что зависнете на уровне последнего из забитых клиньев. Если же вы пожалеете затратить время на фиксацию и страховку достигнутых результатов, то можете сорваться и пролететь вниз до самого подножия скалы, что чревато большими неприятностями. В процессе разработки не рвитесь необдуманно вперед и время от времени стабилизируйте показатели производительности своего приложения.

Определение задач, решение которых необходимо для достижения высокой производительности

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

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

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

Ha всем, что связано с оценкой производительности, лежит печать субъективности

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

Немедленная ответная реакция приложения

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

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

Для различных типов устройств предусматриваются различные виды ответной реакции. Быстрая, безошибочная и информативная обратная связь с пользователем является отличительным признаком хорошо спроектированного мобильного устройства.

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

Аналогичные моменты должны учитываться вами и при проектировании приложений. Часто для организации хорошей обратной связи требуется всего лишь добавить в приложение немного кода и чуть-чуть его приукрасить, но это оказывает огромный положительный эффект на пользовательское восприятие устройства и его оценку качества приложения.

В качестве одной из целей разработки всегда указывайте обязательное подтверждение получения команд пользователя, даже если они не могут быть немедленно обработаны. Обычно любая задержка с таким подтверждением, превышающая 0,5 секунды, вызывает у конечного пользователя чувство раздражения. При возникновении задержки ответа пользователи часто пытаются повторить команду, что может стать причиной еще большего раздражения, если вторая команда переводит приложение в нежелательное состояние или оно начинает работать не так, как ожидается.

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

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

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

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

2. Хорошая обратная связь. В этом случае пользовательский интерфейс отображает "курсор ожидания" в течение всего периода, на протяжении которого интерфейс не способен отвечать на запросы пользователей. Наличие курсора ожидания говорит пользователям о том, что в настоящее время приложение не может реагировать на их запросы, а его исчезновение будет означать, что способность приложения реагировать на запросы восстановлена. Таким образом, для существенного улучшения поведения пользовательского интерфейса потребовались лишь самые незначительные усилия.

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

Предполагается, что представленный в листинге 7.3 текст вы поместите в класс Form в проекте для Pocket PC. Для создания и выполнения примера необходимо выполнить следующие действия:

1. В Visual Studio .NET (2003 или более поздней версии) начните новый проект для Pocket PC с использованием языка C#.

2. Разместите в окне конструктора формы для Pocket PC текстовую метку и три кнопки (как показано на рис. 7.1).

3. Дважды щелкните мышью на пустом месте окна конструктора форм; в результате этого будет создан и присоединен к форме обработчик событий Form1_Load, представленный ниже. Включите в эту процедуру приведенный ниже код.

4. Дважды щелкните на кнопке Button1 формы; в результате этого будет создан и присоединен к форме обработчик событий button1_Click, представленный ниже. Включите в эту процедуру приведенный ниже код.

5. Проделайте то же самое для кнопок Button2 и Button3 и включите их коды в соответствующие процедуры.

6. Нажмите клавишу <F5> для запуска приложения на эмуляторе или физическом устройстве Pocket PC. (Если вы хотите запустить приложение без отладчика, нажмите комбинацию клавиш <Ctrl+F5>.)

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

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

//Поместить надписи на кнопках

private void Form1_Load(object sender, System.EventArgs e) {

button1.Text = "Плохая обратная связь";

button2.Text = "Хорошая обратная связь";

button3.Text = "Улучшенная обратная связь";

}

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

//Пример слабых интерактивных возможностей интерфейса:

// - Визуальная индикация начала выполнения работы отсутствует

// - Визуальная индикация окончания выполнения работы отсутствует

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

// - 0 завершении выполнения задачи пользователь вынужден только догадываться

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

private void button1_Click(object sender, System.EventArgs e) {

//Имитировать выполнение работы путем создания паузы

//продолжительностью 4 секунды

System.Threading.Thread.Sleep(4000);

}

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

//Пример лучших интерактивных возможностей интерфейса:

// + Визуальная индикация начала выполнения работы

// (появление курсора ожидания)

// + Визуальная индикация окончания выполнения работы

// (исчезновение курсора ожидания)

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

// + По завершении выполнения задачи конечный пользователь узнает об этом,

// а пользовательский интерфейс восстанавливает способность к отклику

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

private void button2_Click(object sender, System.EventArgs e) {

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.WaitCursor;

//Имитировать выполнение работы путем создания паузы

//продолжительностью 4 секунды

System.Threading.Thread.Sleep(4000);

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default;

}

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

//Пример еще лучших интерактивных возможностей интерфейса:

// + Визуальная индикация начала выполнения работы // (появление курсора ожидания)

// + Отображение дополнительного текста, сообщающего пользователю // о том, что происходит

// + Визуальная индикация окончания выполнения работы // (исчезновение курсора ожидания)

// - Пользовательский интерфейс не способен к отклику в процессе работы

// + По завершении выполнения задачи конечный пользователь узнает об этом,

// а пользовательский интерфейс восстанавливает способность к отклику

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

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

private void button3_Click(object sender, System.EventArgs e) {

//Предоставить пользователю текст, информирующий его обо всем происходящем

label1.Text = "Ждите! Работа выполняется!";

//Заставить интерфейс обновить текст

//(иначе он сделает это только тогда, когда будет перерисовывать сообщение,

//a это может произойти и после выхода из данной функции)

label1.Update();

//Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.WaitCursor;

//Имитировать выполнение работы путем создания паузы

//продолжительностью 2,8 секунды

System.Threading.Thread.Sleep(2800);

//Необязательное дополнительное обновление состояния

label1.Text = "Ждите! Работа близка к завершению!";

label1.Update();

//Имитировать выполнение работы путем создания паузы

//продолжительностью 1,2 секунды

System.Threading.Thread.Sleep(1200);

//Известить пользователя текстовым сообщением о завершении работы

//(текст обновляется всякий раз, когда ПИ выполняет обычное

//обновление экрана)

label1.Text = "Работа успешно завершена!";

//Избавиться от курсора ожидания

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default;

}

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

Максимальная продолжительность отображения курсора ожидания

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

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

Максимальная продолжительность загрузки/сохранения данных, а также запуска/закрытия приложения

Задачи, для выполнения которых требуется длительное время, часто можно вытолкнуть в фоновый поток, так что пользователь даже не будет замечать, что задача выполняется долго. Если задача выполняется фоновым потоком, то говорят, что она выполняется в "асинхронном режиме". Однако в некоторых ситуациях для того, чтoбы приложение могло продолжить работу, требуется предварительно выполнить некоторые операции. К числу типичных ситуаций такого рода относятся следующие:

■ Загрузка документов. Если приложение предназначено для работы с документами, то для того, чтобы оно могло продолжить работу, может потребоваться загрузка документа.

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

■ Запуск приложения и инициализация данных. Как и в случае загрузки документов, может существовать необходимая для запуска приложения информация, которая должна быть загружена и обработана, прежде чем приложение сможет продолжить дальнейшее выполнение

Даже задержки, обусловленные необходимостью выполнения обязательных задач, могут вызывать у пользователя раздражение. В некоторых случаях заставки, курсоры ожидания или индикаторы выполнения позволяют несколько сгладить ситуацию, но не более того. 30-секундный запуск всегда остается 30-секундным запуском, и пользователей мобильных устройств, которым надо поработать всего 20 секунд, а затем вернуть устройство обратно в карман, это раздражает. Как выше уже отмечалось, вы должны явно устанавливать максимальные интервалы задержек, которые еще можно считать допустимыми с точки зрения пользователя в подобных ситуациях. Если ваше приложение превышает эти допуски, в проект необходимо ввести соответствующие изменения. Действительно ли вы загружаете лишь минимальный объем данных, требуемых при запуске приложения? Могут ли данные запуска кэшироваться или сохраняться в формате, в котором они будут быстрее загружаться? Если при запуске требуются сетевые данные, то могут ли они сохраняться в локальной кэш-памяти? Могут найтись самые разнообразные творческие решения, которые должны быть исследованы с точки зрения повышения производительности приложения в ключевых точках, и иногда, чтобы обеспечить достижение необходимых показателей, на которые рассчитывают пользователи мобильных устройств с немедленным доступом, вы должны будете пересмотреть некоторые из положений проекта.

Накладные расходы по обработке исключений

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

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

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

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

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

В листинге 7.4 представлен пример приложения, в котором сравниваются два алгоритма, решающие одну и ту же задачу, но значительно различающиеся между собой показателями производительности. Один алгоритм осуществляет сложение двух чисел и возвращает их сумму, а также булевское значение, которое указывает на знак результата — положительный или отрицательный. Другой алгоритм также складывает два числа и возвращает результат, но если результат является отрицательным числом, возбуждается исключение. Как и следовало ожидать, алгоритм, в котором в процессе нормального выполнения приложения используется возбуждение исключений, по своей производительности разительно отличается в худшую сторону от алгоритма, в котором исключения не используются. Хотя в абсолютном смысле оба алгоритма paботают довольно быстро и выполняют 10000 итераций менее чем за 2,5 секунды, один из них работает более чем в 350 раз быстрее по сравнению с другим; в случае вычислений, в которых интенсивно используются циклы, это различие может иметь критическое значение.

Результаты выполнения тестовых вычислений на физическом устройстве Pocket PC без подключения отладчика представлены в табл. 7.1. Как следует из приведенных в этой таблице данных, алгоритм, в котором возбуждение и перехват исключений не используются, работает в несколько сотен раз быстрее. В нашем примере применяются очень простые алгоритмы и простой механизм возбуждения и перехвата исключений; процесс обработки исключений требует осуществления средой выполнения сравнительно небольшого объема операций по освобождению памяти и разворачиванию стека. Чрезвычайная простота выполняемых вычислений позволяет более отчетливо выявить влияние обработки исключений на производительность приложения. В зависимости от сложности алгоритма и объема работы, необходимой для обработки возбужденных исключений, мы будем получать различные результаты, но можно сделать один совершенно очевидный вывод накладные расходы на обработку часто возбуждаемых исключений могут оказаться значительными, так что использования исключений в условиях нормального выполнения кода следует избегать, если только на то нет особой необходимости.

Таблица 7.1. Сравнительные показатели производительности простого алгоритма, выполняемого с возбуждением исключений и без такового

Количество итераций

Время выполнения с возбуждением исключений (с)

Время выполнения без возбуждения исключений (с)

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

10000

0,006

2,202

367

10000

0,006

2,201

367

100000

0,061

22,716

372

100000

0,055

22,834

415

100000

0,055

22,995

418

Выполнение используемого в качестве примера приложения на эмуляторе Pocket PC иллюстрирует рис. 7.2.

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

НА ЗАМЕТКУ

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

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

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

Представленный в листинге 7.4 код следует включить в форму проекта для Pocket PC. Для сборки и запуска приложения необходимо выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и создайте приложение C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически сгенерирован проект, и на экране появится конструктор форм Pocket PC.)

3. Добавьте в форму перечисленные ниже элементы управления. Возможная схема расположения элементов управления на форме показана на рис. 7.2.

• TextBox; переименуйте его в textBoxNumberAttempts.

• Button; переименуйте его в buttonRunNoExceptionCode.

• Button; переименуйте его в buttonRunExceptionCode.

• ListBox; оставьте в качестве его имени listBox1.

4. Выполните по отношению к каждой из кнопок следующие действия. Дважды щелкните на кнопке в конструкторе формы. В автоматически сгенерированной и подключенной функции обработчика событий введите один из приведенных ниже кодов с соответствующим именем button<ИмяКнопки>_Click.

5. Введите оставшуюся часть приведенного ниже кода.

6. Установите для свойства MinimizeBox значение FALSE. Это приведет к тому, что во время выполнения приложения в правом верхнем углу формы появится кнопка OK, используя которую легко завершить выполнение приложения; эта возможность оказывается особенно удобной при многократном тестировании формы.

7. Добавьте в проект новый класс, назовите его PerformanceSampling и, предварительно удалив его текущее содержимое, введите в него код, показанный в листинге 7.1.

8. Запустите приложение на физическом устройстве или эмуляторе, нажав для этого клавишу <F5>. Если вы хотите выполнить приложение без подключения отладчика, используйте сочетание клавиш <Ctrl+F5>; именно этот способ рекомендуется использовать в данном примере, поскольку при подключенном отладчике исключения обрабатываются гораздо медленнее.

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

//Примечание. В этом примере используется класс PerformanceSampling,

//            определенный ранее в этой главе. Убедитесь в том, что

//            этот класс включен в проект

//ТЕСТОВАЯ ФУНКЦИЯ:

//Сложить 'n1' и 'n2' и возвратить результат

//в 'n3'

// Возвращаемое значение:

// TRUE: если результат положителен

// FALSE: если результат отрицателен

bool returnFalseIfLessThanZero_Add2Numbers(int n1, int n2, out int n3) {

n3 = n1 + n2;

//Результат меньше 0?

if (n3 < 0) {

return false;

}

return true;

}

//===========================================================

// ТЕСТОВАЯ ФУНКЦИЯ:

//

//Сложить 'n1' и 'n2' и возвратить результат

//в 'n3'

//

//Если 'n3' меньше 0, то функция ПЕРЕДАЕТ УПРАВЛЕНИЕ ОБРАБОТЧИКУ ИСКЛЮЧЕНИЙ.

//B противном случае возвращается TRUE

//===========================================================

bool exceptionIfLessThanZero_Add2Numbers(int n1, int n2, out int n3) {

n3 = n1 + n2;

//Результат меньше 0?

if (n3 < 0) {

throw new Ехсерtion("Результат меньше 0!");

}

return true;

}

//===========================================================

//Осуществляет многократные вызовы простой функции и

//измеряет общее время выполнения

//

//Вызываемая функция НЕ приводит к возбуждению исключений

//===========================================================

private void buttonRunNoExceptionCode_Click(object sender, System.EventArgs e) {

const int TEST_NUMBER = 0;

int numberIterations;

numberIterations = System.Convert.ToInt32(textBoxNumberAttempts.Text);

//Отобразить количество итераций, которые предстоит выполнить

listBox1.Items.Add("=>" + numberIterations.ToString() + " итераций");

int count_SumLessThanZero;

int dataOut;

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

//Запустить таймер

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

PerformanceSampling.StartSample(TEST_NUMBER, "Исключения отсутствуют");

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

//Выполнить цикл, в котором осуществляется вызов функции

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

count_SumLessThanZero = 0;

bool sumGreaterThanZero;

for(int i = 0; i < numberIterations; i++) {

//=========================

//Вызвать тестовую функцию!

//=========================

sumGreaterThanZero = returnFalseIfLessThanZero_Add2Numbers(-2, -3, outdataOut);

if (sumGreaterThanZero == false) {

count_SumLessThanZero++;

}

} //конец цикла

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

//Остановить таймер

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

PerformanceSampling.StopSample(TEST_NUMBER);

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

//Показать результаты пользователю

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

if (count_SumLessThanZero == numberIterations) {

System.Windows.Forms.MessageBox.Show("Тест выполнен");

listBox1.Items.Add(PerformanceSampling.GetSampleDurationText(TEST_NUMBER));

} else {

System.Windows.Forms.MessageBox.Show("При выполнении теста возникали осложнения");

}

}

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

//===========================================================

//Осуществляет многократные вызовы простой функции и

//измеряет общее время выполнения.

//

//Вызываемая функция ВОЗБУЖДАЕТ исключения

//===========================================================

private void buttonRunExceptionCode_Click(object sender, System.EventArgs e) {

const int TEST_NUMBER = 1;

//Получить количество итераций

int numberIterations;

numberIterations = System.Convert.ToInt32(textBoxNumberAttempts.Text);

//Отобразить количество итераций, которые надлежит выполнить

listBox1.Items.Add("=>" + numberIterations.ToString() + " итераций");

int count_SumLessThanZero;

int dataOut;

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

//Запустить таймер

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

PerformanceSampling.StartSample(TEST_NUMBER , "Перехват исключения");

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

//Выполнить цикл, в котором осуществляется вызов функции

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

count_SumLessThanZero = 0;

bool sumGreaterThanZero;

for (int i = 0; i < numberIterations; i++) {

try {

//=========================

//Вызвать тестовую функцию!

//=========================

sumGreaterThanZero = exceptionIfLessThanZero_Add2Numbers(-2, -3, outdataOut);

} catch {

count_SumLessThanZero++;

}

} //конец цикла

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

//Остановить таймер

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

PerformanceSampling.StopSample(TEST_ NUMBER);

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

//Показать результаты пользователю

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

if (count_SumLessThanZero == numberIterations) {

System.Windows.Forms.MessageBox.Show("Тест выполнен");

listBox1.Items.Add(PerformanceSampling.GetSampleDurationText(ТЕST_NUMBER));

} else {

System.Windows.Forms.MessageBox.Show("При выполнении теста возникали осложнения");

}

}

Резюме

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

По мере написания кода и разработки приложения между его модулями будут формироваться различного рода взаимозависимости. Чем больше кода вы напишете, тем более жестким будет становиться приложение, оставляя вам все меньше возможностей для радикального изменения системы. Обеспечение высокой производительности часто требует радикального пересмотра проекта, и поэтому за решение проблем этого рода лучше всего браться сразу же после того, как они становятся очевидными. Для этого существуют два способа: 1) свяжите с каждым из ключевых этапов разработки определенные цели, связанные с производительностью, и не считайте этап успешно завершенным, пока эти цели не будут достигнуты, и 2) периодически измеряйте и анализируйте показатели производительности.

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

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

ГЛАВА 8

Производительность и управление памятью

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

Артур Конан-Дойль

(Encarta 2004, Quotations)

Определение модели памяти для приложения

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

Самое важное, что можно сказать о модели памяти, — это то, что она должна у вас быть. Было бы слишком легкомысленно допустить, чтобы в процессе разработки приложения разрастались сами по себе неконтролируемым образом, а не в соответствии с предварительно составленным планом. В случае приложений для настольных компьютеров это часто приводит к малопонятному коду, который трудно сопровождать и обновлять, и приложениям, которые функционируют не столь надежно и эффективно, как следовало бы. В случае мобильных приложений использование "сырой" модели памяти приводит к приложениям, которые обязательно упираются в "стену производительности", в результате чего они никогда не смогут функционировать так, как надо. В подобных ситуациях обычно трудно устранить проблемы, не прибегая к широкомасштабной переделке проекта. Разработка хорошо продуманной модели памяти позволяет избежать этой трясины и сделать проект более гибким. Целесообразно рассматривать использование памяти приложения на двух различных уровнях:

1. Управление памятью на макроскопическом "уровне приложения". Этот уровень относится к данным и ресурсам уровня приложения, которые поддерживаются вашим приложением в процессе выполнения. Эти данные обычно существуют в течение длительного времени, и их область видимости не ограничивается пределами отдельных функций. Для создания эффективно функционирующего мобильного приложения очень важно иметь надежную модель, управляющую объемом данных, подлежащих хранению в памяти в каждый момент времени, и удалением из памяти данных и ресурсов, непосредственное использование которых в ближайшее время не ожидается. Чрезмерный объем долгоживущих данных состояния загромождает память, которую можно было бы использовать для кэширования JIT-компилированного кода или как рабочую память для функций, и заставляет многократно и не самым эффективным образом очищать память от "мусора".

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

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

ОЗУ мобильных устройств имеют гораздо меньший объем и, как правило, не позволяют надлежащим образом реализовать механизмы, использующие дополнительные внешние накопители для организации быстрого обмена страницами с памятью. Кроме того, в условиях ограниченных ресурсных возможностей на мобильных устройствах могут быть реализованы лишь сравнительно простые механизмы очистки памяти от неиспользуемых объектов. Это означает, что небрежно организованное управление памятью в приложениях для мобильных устройств будет иметь весьма заметные отрицательные последствия как на макроскопическом, так и на микроскопическом уровнях. По сравнению с настольными компьютерами мобильные устройства гораздо менее терпимы к любым просчетам в управлении памятью.

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

Управление памятью на макроскопическом "уровне приложения"

На рис. 8.1 в схематическом виде отображено, как снижается производительность приложения с увеличением объема используемой памяти.

Рис. 8.1. Изменение производительности приложения с увеличением объема используемой памяти

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

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

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

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

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

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

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

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

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

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

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

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

Во всем должен существовать определенный баланс, который вам предстоит определить. Поскольку скоросшиватель — вещь довольно полезная, по своим размерам не очень габаритная и время от времени может использоваться, то его следует оставить под рукой. А что можно сказать по поводу большого парового пылесоса для чистки ковров? Опять-таки, вы могли бы сходить в магазин, купить пылесос, затратив на это значительные денежные и временные ресурсы, и держать его где-то в квартире; в то же время, если вы живете в небольшой квартирке и чистите свои ковры сравнительно редко, то такое решение было бы не самым разумным. Вместо этого вам следовало бы взять пылесос напрокат, сделать все, что надо, а затем отнести его обратно в пункт проката. Вы всегда должны планировать, какие вещи лучше держать при себе, а от каких лучше избавляться, когда они сделали свое дело.

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

Очевидно, что должны существовать какие-то правила, регламентирующие, что следует держать под рукой, а от чего необходимо избавляться. Действительно, такие правила существуют но, к счастью, они основываются на здравом смысле, и главное заключается в том, чтобы их систематически применять. Именно в том и состоит на значение явной модели использования памяти приложения, чтобы гарантировать последовательное применение основанных на здравом смысле соображений, обеспечивающих эффективное выполнение мобильного приложения.

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

Информация какого типа должна охватываться вашей макромоделью памяти? Полезно рассортировать данные и ресурсы приложения, с которыми вы работаете, на две разновидности: 1) объекты и ресурсы, которые необходимы приложению для эффективного выполнения, и 2) фактическая пользовательская информация, с которой работает приложение.

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

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

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

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

Поскольку данные растровых изображений представляют загруженные в память и готовые для использования в графике приложения изображения, они могут занимать много места. Держать растровые данные больших изображений может оказаться дорогим удовольствием, и поэтому следует уделить должное внимание тому, когда их следует загружать в память, а когда — освобождать память от них.

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

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

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

Управление "служебными" данными приложения

Как ранее уже отмечалось, "служебные" данные приложения — это те данные, с которыми пользователь непосредственно не взаимодействует и которые, таким образом, не являются "пользовательскими" данными. Эти данные представляют собой ресурсы, необходимые для эффективного функционирования приложения, а также отображения данных и манипулирования ими. Управление объектами и ресурсами, необходимыми для того, чтобы приложение могло эффективно выполняться, обычно может осуществляться с помощью простого конечного автомата. По мере прохождения приложением различных состояний ресурсы, которые полезно иметь под рукой, могут меняться. При переходе в новое состояние необходимые ресурсы могут создаваться и сохраняться в памяти приложения. Аналогичным образом, если приложение покидает некоторое состояние, то ресурсы, которые в новом состоянии непосредственно не требуются, могут быть удалены из памяти, а освобожденная память возвращена в пул свободной памяти. Часто эти состояния соответствуют отображаемым в данный момент формам или их вкладкам, которые пользователь имеет возможность листать, поочередно вызывая их на передний план. Во многих случаях при проектировании модели состояний приложения полезно идентифицировать дискретный ряд возможных режимов работы пользовательского интерфейса и применять их в качестве основы для построения модели состояний.

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

1. Загрузка данных из базы данных. Этот экран предоставляет пользователю возможность подтвердить свои права доступа к базе данных и загрузить данные конкретного пациента. К необходимым служебным данным приложения относятся следующие данные:

• Соединения с базой данных.

• Форма, отображающая пользовательский интерфейс, необходимый для входа в базу данных.

2. Сохранение данных в базе данных. Этот экран предоставляет пользователю возможность подтвердить свои права доступа к базе данных и сохранить данные конкретного пациента. К необходимым служебным данным приложения относятся следующие данные.

• Соединения с базой данных.

• Форма, отображающая пользовательский интерфейс, необходимый для входа в базу данных.

3. Основной экран приложения. Этот экран отображает данные истории болезни пациента, которые были загружены из базы данных, и предоставляет пользователю устройства возможность просматривать данные и переходить от одних данных к другим. К необходимым служебным данным приложения относятся следующие данные:

• Форма для основного экрана.

• Изображения общего назначения, используемые в пользовательском интерфейсе.

4. Экран, отображающий подробную информацию, необходимую для работы с конкретными данными и их редактирования. Этот экран отображается тогда, когда пользователю необходимо редактировать отдельные элементы данных о пациенте или вводить новые данные. К необходимым служебным данным приложения относятся следующие данные:

• Форма для редактирования загруженной записи.

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

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

• Графические перья и кисти, используемые для рисования диаграмм.

• Объекты шрифтов, используемых для отображения надписей на диаграммах.

• Кэшированные фоновые изображения.

• Внеэкранная поверхность растрового изображения, используемая для подготовки изображения диаграммы перед его копированием на экран.

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

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

Использование интерфейса 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 очень удобно использовать в тех случаях, когда переменная существует только внутри некоторого блока кода.

Управление объемом пользовательских данных, хранящихся в памяти

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

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

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

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

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

■ Возможность иметь различные реализации для различных классов устройств. Если ваши целевые устройства охватывают несколько различных классов, то вы имеете возможность настроить ограничения на использование памяти и накопителей для каждого из этих классов по отдельности. Мобильный телефон и устройство PDA могут иметь различные характеристики памяти и различные возможности в отношении загрузки данных по требованию. Отмеченные различия могут потребовать от вас использования различных подходов к кэшированию данных. Концентрация соответствующей управляющей логики в одном месте существенно упрощает эту задачу.

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

Для размещения объектов в памяти существуют две стратегии:

1. При вхождении приложения в новое состояние создаются все объекты, которые требуются для этого состояния. Достоинством этой стратегии является ее простота. Когда приложение переходит в новое состояние, вы просто вызываете функцию, которая и обеспечивает доступность и возможность использования всех необходимых объектов. Эта стратегия очень хорошо работает в тех случаях, когда имеется уверенность в том, что в ближайшее время приложению потребуются все созданные объекты. Возможные проблемы связаны с тем, что если ваше приложение находится в стадии становления и в его проект могут вноситься изменения, то применение указанной стратегии может привести к хранению в памяти большого количества ненужных объектов. Поскольку старые объекты, необходимости в которых больше нет, все равно создаются и загружаются в память, то драгоценные ресурсы тратятся понапрасну. Будьте внимательны при групповом создании наборов объектов, ибо в процессе выполнения вашего приложения может наступить такой момент, когда создаваемые объекты не используются, но связанные с ними накладные расходы ухудшают производительность.

2. Создание любого объекта откладывается до тех пор, пока необходимость в его создании не станет очевидной. Эта модель немного сложнее в проектировании, но зато во многих случаях оказывается более эффективной, поскольку объекты создаются лишь тогда, когда в них возникает действительная необходимость. При обсуждении этой модели часто употребляются такие выражения, как "фабрика классов" ("class factory"), "диспетчер ресурсов" ("resource dispenser") и "отложенная загрузка" ("lazy loading").

Приведенный в листинге 8.1 пример кода иллюстрирует два способа отложенного создания и кэширования глобально используемых графических ресурсов. Существует два способа создания объектов:

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

2. Индивидуальное создание графических ресурсов. В случае ресурсов, которые не должны обязательно использоваться вместе, как в приведенном выше примере, часто оказывается удобным создать функцию кэшированного доступа, посредством которой и реализуется управление доступом к ресурсу. Когда происходит первое обращение к этой функции с запросом ресурса (например, GraphicsGlobals.g_GetBlackPen();), она создает его экземпляр. В случае часто используемых ресурсов такой подход оказывается намного более эффективным, чем постоянное создание и уничтожение экземпляров ресурса всякий раз, когда он требуется для выполнения того или иного фрагмента кода. Создавая приведенный ниже код, я допустил, что все ресурсы должны освобождаться одновременно, и написал функцию (GraphicsGlobals.g_CleanUpDrawingResources();), которая освобождает все кэшированные ресурсы, которые были созданы. Эта функция должна вызываться тогда, когда приложение переходит в состояние, в котором эти ресурсы не требуются.

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

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

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

using system;

public class GraphicsGlobals {

private static System.Drawing.Bitmap s_Player_Bitmap1;

private static System.Drawing.Bitmap s_Player_Bitmap2;

private static System.Drawing.Bitmap s_Player_Bitmap3;

private static System.Drawing.Bitmap s_Player_Bitmap4;

private static System.Collections.ArrayList s_colPlayerBitmaps;

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

//Освободить все ресурсы

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

public static void g_PlayerBitmapsCollection_CleanUp() {

//Если не загружено ни одно изображение, то и память освобождать не от чего

if (s_colPlayerBitmaps == null) {

return;

}

//Дать указание каждому из этих объектов освободить

//любые удерживаемые ими неуправляемые ресурсы

s_Player_Bitmap1.Dispose();

s_Player_Bitmap2.Dispose();

s_Player_Bitmap3.Dispose();

s_Player_Bitmap4.Dispose();

//Обнулить каждую из этих переменных, чтобы им не соответствовали

//никакие объекты в памяти

s_Player_Bitmap1 = null;

s_Player_Bitmap2 = null;

s_Player_Bitmap3 = null;

s_Player_Bitmap4 = null;

//Избавиться от массива

s_colPlayerBitmaps = null;

}

//Функция: возвращает коллекцию изображений

public static System.Collections.ArrayList g_PlayerBitmapsCollection() {

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

//Если изображения уже загружены, их достаточно только возвратить

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

if (s_colPlayerBitmaps != null) {

return s_colPlayerBitmaps;

}

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

System.Reflection.Assembly thisAssembly = System.Reflection.Assembly.GetExecutingAssembly();

System.Reflection.AssemblyName thisAssemblyName = thisAssembly.GetName();

string assemblyName = thisAssemblyName.Name;

//Загрузить изображения

s_Player_Bitmap1 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(assemblyName + ".Hank_RightRun1.bmp"));

s_Player_Bitmap2 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(assemblyName + ".Hank RightRun2.bmp"));

s_Player_Bitmap3 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(assemblyName + ".Hank_LeftRun1.bmp"));

s_Player_Bitmap4 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(assemblyName + ".Hank_LeftRun2.bmp"));

//Добавить изображения в коллекцию

s_colPlayerBitmaps = new System.Collections.ArrayList();

s_colPlayerBitmaps.Add(s_Player_Bitmap1);

s_colPlayerBitmaps.Add(s_Player_Bitmap2);

s_colPlayerBitmaps.Add(s_Player_Bitmap3);

s_colPlayerBitmaps.Add(s_Player_Bitmap4);

//Возвратить коллекцию

return s_colPlayerBitmaps;

}

private static System.Drawing.Pen s_blackPen;

private static System.Drawing.Pen s_whitePen;

private static System.Drawing.Imaging.ImageAttributes s_ImageAttribute;

private static System.Drawing.Font s_boldFont;

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

//Вызывается для освобождения от любых графических

//ресурсов, которые могли быть кэшированы

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

private static void g_CleanUpDrawingResources() {

//Освободить память от черного пера, если таковое имеется

if (s_blackPen !=null) {

s_blackPen.Dispose();

s_blackPen = null;

}

// Освободить память от белого пера, если таковое имеется

if (s_whitePen != null) {

s_whitePen.Dispose();

r_whitePen = null;

}

//Освободить память от атрибута ImageAttribute, если таковой имеется.

//Примечание. Метод Dispose() для этого типа не предусмотрен,

//поскольку все его данные являются управляемыми

if (s_ImageAttribute != null) {

s_ImageAttribute = null;

}

//Освободить память от полужирного шрифта, если таковой имеется

if (s_boldFont != null) {

s_boldFont.Dispose();

s_boldFont = null;

}

}

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

//Эта функция позволяет получить доступ

//к черному перу, находящемуся в кэш-памяти

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

private static System.Drawing.Pen g_GetBlackPen() {

//Если перо еще не существует, создать его

if (s_blackPen ==null) {

s_blackPen = new System.Drawing.Pen(System.Drawing.Color.Black);

}

//Возвратить черное перо return s_blackPen;

}

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

//Эта функция позволяет получить доступ

//к белому перу, находящемуся в кэш-памяти

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

private static System.Drawing.Pen g_GetWhitePen() {

//Если перо еще не существует, создать его

if (s_whitePen == null) {

s_whitePen = new System.Drawing.Pen(System.Drawing.Color.White);

}

//Возвратить белое перо return s_whitePen;

}

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

//Эта функция позволяет получить доступ

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

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

private static System.Drawing.Font g_GetBoldFont() {

//Если перо еще не существует, создать его

if (s_boldFont ==null) {

s_boldFont = new System.Drawing.Font(

System.Drawing.FontFamily.GenericSerif, 10, System.Drawing.FontStyle.Bold);

}

//Возвратить полужирный шрифт

return s_boldFont;

}

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

//Эта функция позволяет осуществлять доступ

//к находящемуся в кэш-памяти объекту imageAttributes,

// который мы используем для изображений с прозрачностью

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

private static System.Drawing.Imaging.ImageAttributes g_GetTransparencyImageAttribute() {

//Если объект не существует, создать его

if (s_ImageAttribute == null) {

//Создать атрибут изображения

s_ImageAttribute = new System.Drawing.Imaging.ImageAttributes();

s_ImageAttribute.SetColorKey(System.Drawing.Color.White, System.Drawing.Color.White);

}

//Возвратить его

return s_ImageAttribute;

}

} //Конец класса

Управление памятью на микроскопическом "уровне алгоритма"

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

1. Вычислительная неэффективность алгоритма. Этот вид неэффективности наблюдается в тех случаях, когда спроектированный вами алгоритм предусматривает интенсивные вычисления или выполнение большего количества циклов, чем это объективно необходимо, от чего можно было бы избавиться, используя более эффективные алгоритмы. В качестве классического примера можно привести сортировку массива данных. Иногда у вас может появляться возможность выбирать между несколькими возможными вариантами алгоритмов сортировки, отдельными частными случаями которых могут, например, быть алгоритмы "порядка N" (линейная зависимость времени вычислений от количества сортируемых элементов), "порядка N*Log(N)" (зависимость времени вычислений от количества сортируемых элементов отличается от линейной, но остается все же лучшей, чем экспоненциальная) или "порядка N^2" (экспоненциальная зависимость времени вычислений от количества сортируемых элементов). Кроме вышеперечисленных "порядков" возможно множество других (например, N^3). Выбор наиболее подходящего алгоритма зависит от объема данных, с которыми вы работаете, объема доступной памяти и ряда других факторов, например, от состояния рабочих данных. Отдельные стратегии, например, предварительная обработка данных перед отправкой их на устройство или хранение данных в формате, специфическом для использования памяти в качестве хранилища, способны обеспечить значительное повышение производительности алгоритма. Существует огромное количество компьютерной литературы, посвященной проектированию эффективных алгоритмов и оценке их быстродействия, поэтому никаких попыток более подробного анализа этих вопросов в данной книге не делается. Необходимо только отметить, что чем больше объем обрабатываемых данных, тем ответственнее необходимо отнестись к принятию решения относительно выбора вычислительного алгоритма. Во всех затруднительных случаях тщательно анализируйте алгоритм и обращайтесь к существующей литературе по этому вопросу. Очень часто оказывается так, что кто-то другой уже прошел этот путь, и вам остается лишь перенять их опыт.

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

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

Пишите аккуратные алгоритмы: не сорите!

Как и в реальной жизни, сор в программировании — это отходы производственной деятельности, которые должны выбрасываться. Обычно сор появляется в результате неряшливости и неаккуратности. Стремление к получению кратковременных удобств часто порождает долговременные проблемы. При создании в алгоритмах мусора в виде временных объектов, необходимости в которых на самом деле нет, работа приложения замедляется в результате воздействия непосредственных и косвенных факторов:

1. Непосредственные факторы. Каждый раз, когда вы создаете объект, перед его использованием должна быть распределена и инициализирована память. Это прямые предварительные расходы, которые должен оплатить ваш алгоритм.

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

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

"Структуры" и .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();

}

Пишите экономные алгоритмы: разумно расходуйте память и повторно используйте объекты

Представленный ниже пример иллюстрирует несколько различных вариантов реализации одного и того же базового алгоритма. Алгоритм предназначен для обработки массива строк. Каждая строка в массиве состоит из трех частей, разделенных символом подчеркивания (например, big_shaggy_dog). Алгоритм предполагает просмотр каждого из элементов массива и проверку того, не является ли его средняя часть словом blue (например, my_blue_car). Если это так, то слово blue заменяется словом orange (например, my_blue_car становится my_orange_car).

Кроме того, в каждом из описанных алгоритмов используется вспомогательный класс, упрощающий разбиение строк и получение данных, содержащихся в каждом из трех сегментов. Первый алгоритм (листинги 8.3 и 8.4) представляет собой некое разумное первое приближение, а следующие два алгоритма (листинги 8.5 и 8.6 и листинги 8.7 и 8.8) — его оптимизированные варианты, улучшающие первоначальную тактику. Целью оптимизации являлось непосредственное улучшение производительности, а также уменьшение количества "мусора", вырабатываемого каждым из алгоритмов.

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

//Желаемое число повторений теста

const int LOOP_SIZE = 8000;

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

//Эта функция переустанавливает содержимое нашего тестового

//массива, что обеспечивает возможность многократного

//выполнения тестового алгоритма

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

private void ResetTestArray(ref string[] testArray) {

if (testArray == null) {

testArray =new string[6];

}

testArray[0] = "big_blue_duck";

testArray[1] = "small_yellow_horse";

testArray[2] = "wide_blue_cow";

testArray[3] = "tall_green_zepplin";

testArray[4] = "short_blue_train";

testArray[5] = "short_purple_dinosaur";

}

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

Примечание. В этом примере используется класс PerformanceSampling, определенный ранее в данной книге.

private void button2_Click(object sender, System.EventArgs e) {

//Вызвать сборщик мусора, чтобы быть уверенными в том,

//что тест начнется с чистого состояния.

//ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

//сборщика мусора в программах вручную будут приводить к снижению

//общей производительности приложений!

System.GC.Collect();

string [] testArray = null;

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

//Просмотреть элементы массива и найти

//те из них, в которых средним словом является

//"blue". Заменить "blue" на "orange"

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

//Запустить секундомер для нашего теста!

PerformanceSampling.StartSample(0, "WastefulWorkerClass");

WastefulWorkerClass workerClass1;

int outerLoop;

for (outerLoop = 0; outerLoop < LOOP_SIZE; outerLoop++) {

//Присвоить элементам массива значения, которые мы хотим

//использовать при тестировании

ResetTestArray(ref testArray);

int topIndex = testArray.Length - 1;

for (int idx = 0; idx <= topIndex; idx++) {

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

//Создать экземпляр вспомогательного класса,

//который расчленяет строку на три части

//

//Это неэкономный способ!

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

workerClass1 = new WastefulWorkerClass(testArray[idx]);

//Если средним словом является "blue", заменить его на "orange"

if (workerClass1.MiddleSegment == "blue") {

//Заменить средний сегмент

workerClass1.MiddleSegment = "orange";

//Заменить слово

testArray[idx] = workerClass1.getWholeString();

}

} //конец внутреннего цикла for

}//конец внешнего цикла for

//Получить время окончания теста

PerformanceSampling.StopSample(0);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(0));

}

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

using System;

public class WastefulWorkerClass {

private string m_beginning_segment;

public string BeginSegment {

get { return m_beginning_segment; }

set { m_beginning_segment = value; }

}

private string m_middle_segment;

public string MiddleSegment {

get { return m_middle_segment; }

set { m_middle_segment = value; }

}

private string m_end_segment;

public string EndSegment {

get { return m_end_segment; }

set { m_end_segment = value; }

}

public WastefulWorkexClass(string in_word) {

int index_segment1;

//Осуществляем поиск символов подчеркивания ("_") в строке

index_segment1 = in_word.IndexOf("_",0);

//B случае отсутствия символов "_" все, что нам нужно, это первый сегмент

if (index_segment1 == -1) {

m_beginning_segment = in_word;

m_middle_segment = "";

m_end_segment = "";

return;

}

//Если присутствует символ "_", усечь его

else {

//Если первым символом является "_", то первым сегментом будет ""

if (index_segment1 == 0) {

m_beginning_segment = "";

} else {

//Первый сегмент

m_beginning_segment = in_word.Substring(0, index_segment1);

}

//Найти второй символ "_"

int index_segment2;

index_segment2 = in_word.IndexOf("_", index_segment1 + 1);

//Второй символ "_" отсутствует

if (index_segment2 == -1) {

m_middle_segment = "";

m_end_segment = in_word.Substring(index_segment1 + 1);

return;

}

//Установить последний сегмент

m_middle_segment = in_word.Substring(index_segment1 + 1, index_segment2 - index_segment1 -1);

m_end_segment = in word.Substring(index segment2 + 1);

}

//Возвращает все три сегмента, объединенные символами "_"

public string getWholeString() {

return m_beginning_segment + "_" + m_middle_segment + "_" + m_end_segment;

}

} //конец класса

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

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

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

Примечание. В этом примере используется класс PerformanceSampling, определенный ранее в данной книге.

private void button3_Click(object sender, System.EventArgs e) {

//Вызвать сборщик мусора, чтобы тест

//начинался с чистого состояния.

//ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

//сборщика мусора в программах вручную будут приводить к снижению

//общей производительности приложений!

System.GC.Collect();

string[] testArray = null;

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

//Просмотреть элементы массива и найти

//те из них, в которых средним словом является

//"blue". Заменить "blue" на "orange"

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

//Запустить секундомер!

PerformanceSampling.StartSample(1, "LessWasteful");

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

//БОЛЕЕ ЭКОНОМНЫЙ СПОСОБ: Распределить память

//для объекта до вхождения в цикл

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

LessWastefulWorkerClass workerClass1;

workerClass1 = new LessWastefulWorkerClass();

int outerLoop;

for (outerLoop = 0; outerLoop < LOOP_SIZE; outerLoop++) {

//Присвоить элементам массива значения, которые

//мы хотим использовать при тестировании

ResetTestArray(ref testArray);

int topIndex = testArray.Length - 1;

for(int idx = 0; idx <= topIndex; idx++) {

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

//Теперь вместо повторного распределения памяти для объекта

//нам достаточно лишь повторно воспользоваться им

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

//workerClass1 = new WastefulWorkerClass(

// testArray[topIndex]);

workerClass1.ReuseClass(testArray[idx]);

//Если средним словом является "blue", заменить его на "orange"

if (workerClass1.MiddleSegment == "blue") {

//Заменить средний сегмент

workerClass1.MiddleSegment = "orange";

//Заменить слово

testArray[idx] = workerClass1.getWholeString();

}

}

}

//Остановить секундомер!

PerformanceSampling.StopSample(1);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(1));

}

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

using System;

public class LessWastefulWorkerClass {

private string m_beginning_segment;

public string BeginSegment {

get { return m beginning_segment; }

set { m_beginning_segment = value; }

}

private string m_middle_segment;

public string MiddleSegment {

get { return m_middle_segment; }

set { m_middle segment = value; }

}

private string m_end_segment;

public string EndSegment {

get { return m_end_segment; }

set { m_end_segment = value; }

}

public void ReuseClass(string in word) {

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

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

//полностью очистить внутреннее состояние

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

m_beginning_segment = "";

m_middle_segment = "";

m_end_segment = "";

int index_segment1;

//Осуществляем поиск символов подчеркивания (" ") в строке

index segment1 = in_word.IndexOf(" ",0);

//B случае отсутствия символов " " все, что нам нужно, это первый сегмент

if (index_segment1 == -1) {

m_beginning_segment = in_word;

return;

}

//Если присутствует символ " ", усечь его

else {

if (index_segment1 == 0) {

} else {

m_beginning_segment = in_word.Substring(0, index_segment1);

}

int index_segment2;

index_segment2 = in_word.IndexOf("_", index_segment1 + 1);

if (index_segment2 == -1) {

m_end_segment = in_word.Substring(index_segment1 + 1);

return;

}

//Установить последний сегмент

m_middle_segment = in_word.Substring(index_segment1 + 1, index_segment2 - index_segment1 - 1);

m_end_segment = in_word.Substring(index_segment2 + 1);

}

}

public string getWholeString() {

return m_beginning_segment + "_" + m_middle_segment + "_" + m_end_segment;

}

}

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

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

Избегайте размещения в памяти лишних объектов

Обратите внимание на то, что в приведенном выше коде мы часто вычисляем множество величин, которые нам не нужны. В частности, мы генерируем в каждой итерации цикла, по крайней мере, три новых строки: одну для первого сегмента, одну для среднего сегмента и одну для конечного сегмента исходной строки. Например, строка big_blue_boat разбивается на три различных строки: big, blue и boat. Для создания этих строк требуется определенное время, а, кроме того, впоследствии мы должны освободить занимаемую ими память.

В алгоритме выполняется проверка только среднего сегмента, в ходе которой устанавливается, совпадает ли он с некоторым конкретным значением (blue). Если совпадения нет. дальнейшая обработка не требуется. Это означает, что большую часть времени мы напрасно распределяем память для строк, предназначенных для размещения среднего и конечного сегментов, даже если они используются алгоритмом всего лишь для того, чтобы вновь собрать целую строку из отдельных кусочков. Что если вместо создания целых строк из кусочков старой строки в каждой итерации цикла мы будем просто сохранять символьные индексные значения, которые указывают нам, где находятся символы подчеркивания (_) в строке? Мы можем сохранять эти данные в виде целых чисел, накладные расходы для которых должны быть значительно меньше, чем при размещении новых строк. Если мы поступим именно таким образом, то сможем использовать исходные строковые и индексные значения для сравнения строк, начиная с первого символа подчеркивания и доходя до второго символа подчеркивания (например, blue_). Лишь в тех случаях, когда обнаруживается совпадение, нам потребуется создавать дополнительную строку для замены среднего сегмента. В большинстве случаев ситуация для нас намного улучшится и нам не надо будет распределять память для каких-либо объектов или строк. Лишь в тех случаях, когда обнаруживается совпадение средних сегментов, нам потребуется выполнять дополнительные строковые операции, но в любом случае нам придется выполнить не больше операций, чем выполнялось ранее. Как бы то ни было, хуже не будет.

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

Примечание. В этом примере используется  класс PerformanceSampling, определенный ранее в данной книге.

private void button5_Click(object sender, System.EventArgs e) {

//Вызвать сборщик мусора, чтобы тест //начинался с чистого состояния.

//ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

//сборщика мусора в программах вручную будут приводить к снижению

//общей производительности приложений!

System.GC.Collect();

string[] testArray = null;

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

//Просмотреть элементы массива и найти

//те из них, в которых средним словом является

//"blue". Заменить "blue" на "orange"

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

//Запустить секундомер перед началом выполнения теста

PerformanceSampling.StartSample(2, "DefferedObjects");

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

//БОЛЕЕ ЭКОНОМНЫЙ СПОСОБ: Распределить память для

//объекта до вхождения в цикл

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

LessAllocationsWorkerClass workerClass1;

workerClass1 = new LessAllocationsWorkerClass();

int outerLoop;

for (outerLoop = 0; outerLoop < LOOP_SIZE; outerLoop++) {

//Присвоить элементам массива значения, которые

//мы хотим использовать при тестировании

ResetTestArray(ref testArray);

int topIndex = testArray.Length - 1;

for(int idx = 0; idx <= topIndex; idx++) {

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

//Более экономный способ:

//Теперь вместо повторного распределения памяти для объекта

//нам достаточно лишь повторно воспользоваться им

//Кроме того: в этом варианте реализации дополнительные

// строки НЕ создаются

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

//workerClass1 = new WastefulWorkerClass(

// testArray[topIndex]);

workerClass1.ReuseClass(testArray[idx]);

//Если средним словом является "blue", заменить его на "orange"

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

//Более экономный способ:

//При таком способе сравнения не требуется создавать

//никаких дополнительных строк

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

if (workerClass1.CompareMiddleSegment("blue") == 0) {

//Заменить средний сегмент workerClass1.MiddleSegment = "orange";

//Заменить слово

testArray[idx] = workerClass1.getWholeString();

}

}

}

//Остановить секундомер!

PerformanceSampling.StopSample(2);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(2));

}

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

using System;

public class LessAllocationsWorkerClass {

public string MiddleSegment {

set { m_middleSegmentNew= value; }

}

private string m_middleSegmentNew;

private int m_index_1st_undscore;

private int m_index_2nd undscore;

private string m_stringIn;

public void ReuseClass(string in_word) {

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

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

//полностью очистить внутреннее состояние

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

m_index_1st_undscore = -1;

m_index_2nd_undscore = -1;

m_middleSegmentNew= null;

m_stringIn = in_word; //Это не приводит к созданию копии строки

//Осуществляем поиск символов подчеркивания ("_") в строке

m_index_1st_undscore = in_word.IndexOf("_",0);

//B случае отсутствия символов "_" все, что нам нужно, это первый сегмент

if (m_index_1st_undscore == -1) {

return;

}

//Найти второй символ " "

m_index 2nd_undscore = in_word.IndexOf(" ", m_index_1st_undscore + 1);

}

public int CompareMiddleSegment(string compareTo) {

//B случае отсутствия второго символа "_" отсутствует и средний сегмент

if (m_index_2nd_undscore < 0) {

//Если мы сравниваем с пустой строкой,

//то это означает совпадение

if((compareTo == null) || (compareTo == "")) {return 0;}

return -1;

}

//Сравнить средний сегмент с первым и вторым сегментами

return System.String.Compare(

m_stringIn, m_index_1st_undscore + 1, compareTo, 0, m_index_2nd_undscore - m_index_1st_undscore -1);

}

public string getWholeString() {

//Если полученный средний сегмент не является новым,

//возвратить исходный сегмент

if (m_middleSegmentNew == null) {

return m_stringIn;

}

//Создать возвращаемую строку

return m_stringIn.Substring(0, m_index_1st_undscore + 1) +

m_middleSegmentNew +

m_stringIn.Substring(m_index_2nd_undscore, m_stringIn.Length - m_index_2nd_undscore);

}

}

Анализ описанных выше шагов последовательной оптимизации

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

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

Результаты тестирования трех различных алгоритмов, обсуждаемых нами, представлены в таблицах 8.1 и 8.2.

Таблица 8.1. Результаты тестирования алгоритмов (в секундах) на эмуляторе Pocket PC с вычислением 8000 циклов

Порядковый номер теста

Неэкономное распределение памяти

Незначительное уменьшение объема распределяемой памяти

Значительное уменьшение объема распределяемой памяти

1

12,65

12,2

8,925

2

12,775

12,35

8,55

3

12,575

12,25

8,225

4

12,625

12,525

8,575

Среднее

12,65625

12,33125

8,56875

Экономия времени по сравнению с базовым уровнем

0%

2,57%

32,30%

Таблица 8.2. Результаты тестирования алгоритмов (в секундах) на физическом устройстве Pocket PC с вычислением 2000 циклов

Порядковый номер теста

Неэкономное распределение памяти

Незначительное уменьшение объема распределяемой памяти

Значительное уменьшение объема распределяемой памяти

1

30,609

30,151

20,484

2

30,538

30,016

20,362

3

30,517

30,195

20,377

4

30,457

30,316

20,429

Среднее

30,53025

30,1695

20,413

Экономия времени по сравнению с базовым уровнем

0%

1,18%

33,14%

Анализ приведенных выше результатов говорит о следующем:

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

■ Второй из проверенных нами вариантов оптимизации, заключающийся в отказе от распределения памяти для нескольких строковых объектов и использовании вместо этого строковых индексов, оказал на производительность приложения значительное воздействие. Благодаря внесению изменений в проект вспомогательного класса и задержке создания строкового класса до тех пор, пока это действительно не потребуется, мы непосредственно увеличили общую производительность алгоритма более чем на треть. Кроме того, как и в рассмотренном выше случае, нам удалось значительно уменьшить количество "мусора", образующегося в результате работы нашего алгоритма. Следствием этого явилось уменьшение общего объема "мусора", а также более ровное и быстрое выполнение приложения.

■ Закономерности изменения производительности в ряду вариантов оптимизации для эмулятора и физических устройств Pocket PC в основном совпадают, но между абсолютными показателями производительности алгоритма для этих двух случае наблюдаются разительные отличия. В нашем примере (распределение памяти для строк) результатом оптимизации явилось одинаковое улучшение производительности как на эмуляторе, так и на физических устройствах, но самый оптимальный вариант алгоритма выполнялся на эмуляторе со скоростью 934 итерации в секунду, а на физическом устройстве — 122 итерации в секунду. Таким образом, данный алгоритм выполняется на эмуляторе в 7,6 раз быстрее по сравнению с физическим устройством. Если этот алгоритм является критическим, и мы собираемся применять его ко многим тысячам единиц данных, то мы должны позаботиться об организации обратной связи с пользователями приложения на время проведения вычислений. В этой связи может потребоваться привлечение фоновых потоков выполнения для обработки данных или использование меньших объемов данных в каждый момент времени. Единственный способ получения реальных результатов оценки производительности — это выполнение приложения на реальных устройствах с использованием реальных объемов данных.

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

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

string str1 = "foo"; //Размещает в памяти строковый объект

string str2 = "bar"; //Размещает в памяти строковый объект

string str3 = str1 + str2; //Размещает в памяти строковый объект

string str3 = str3 + str3; //Размещает в памяти строковый объект

Каждый из этих операторов создает типы и размещает данные в памяти, и при этом нам даже не приходится вызывать никаких функций! Многие разработчики пользуются строками настолько бездумно, что легко могут допустить их некорректное использование. Не оптимизированная обработка строк является одной из наиболее вероятных причин плохой производительности. Ниже представлены некоторые рекомендации и правила, которыми следует руководствоваться при работе со строками. (При этом подразумевается, что вы работаете в .NET Framework/.NET Compact Framework, однако аналогичные правила будут действовать и в других средах. Более детальные разъяснения вы найдете в соответствующем справочном руководстве для своей среды.)

■ Строки неизменчивы (постоянны). Этот странный термин неизменчивый (immutable) просто означает, что текстовые данные строки не могут быть изменены в памяти. Те операции в коде, которые, как вам кажется, изменяют данные строки, на самом деле создают новую строку. Постоянство обладает некоторыми весьма привлекательными свойствами. Например, поскольку строковые данные сами по себе являются статическими, несколько переменных могут указывать на одни и те же данные; благодаря этому присвоение одной строковой переменной значения другой сводится к простому копированию "указателя" вместо глубокого копирования всех данных, которые ему соответствуют. Отрицательной стороной неизменчивости является невозможность изменения данных. Если вы хотите изменить, добавить или отсечь данные, то эти изменения будут отражаться в новой копии строки.

■ Когда на строковые данные не ссылается ни одна "активная" ("live") переменная, они становятся "мусором". Рассмотрим пример:

string str1 = "foo"; //"foo" — статические данные, скомпилированные

//в двоичные данные вашего приложения

string str2 = str1 + str1; //только что была создана новая строка, явля-

//ющаяся результатом конкатенации двух строк

str2 = "bar"; //Поскольку отсутствуют другие переменные, указываю-

//щие на те данные, на которые указывала переменная str2,

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

//очищена от них.

■ Если вы хотите сослаться на некоторую часть строки, то во многих случаях это проще всего сделать, используя целочисленные индексы в строке. Поскольку строки — это данные, представленные массивами символов, то использование индексов для получения этих данных не составляет труда. Существует множество функций, позволяющих осуществлять поиск и просмотр данных внутри строк (но только не изменять эти данные!).

■ Если вы создаете новые строки внутри циклов, настоятельно рекомендуется рассмотреть возможность использования объекта StringBuilder. Все виды строк создаются на основе других переменных, обрабатываемых в циклах. Типичным примером динамического создания строк может служить цикл, генерирующий текстовый отчет, каждая строка которого содержит следующие данные:

//Неэффективный код, выполняющийся внутри цикла...

{

myString = myString +"CustomerID: " +

System.Convert.ToString(customer[idx].id) +

", Name: " + System.Convert.ToString(customer[idx].name);

}

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

■ Измеряйте объективные количественные показатели своих алгоритмов. Занимаясь написанием алгоритма обработки строк, тестируйте его быстродействие! Испробуйте несколько различных подходов. Вы очень быстро научитесь распознавать, какой алгоритм будет эффективным, а какой — нет.

Пример эффективного создания строк

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

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

Примечание. В этом примере используется класс PerformanceSampling, определенный ранее в данной книге.

const int COUNT_UNTIL = 300;

const int LOOP_ITERATIONS = 40;

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

//HE ОЧЕНЬ ЭФФЕКТИВНЫЙ АЛГОРИТМ!

//

//Для имитации создания типичного набора строк используются

//обычные строки

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

private void button1_Click(object sender, System.EventArgs e) {

//Вызвать сборщик мусора, чтобы тест //начинался с чистого состояния.

//ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

//сборщика мусора в программах вручную будут приводить

//к снижению общей производительности приложений!

System.GC.Collect();

int numberToStore = 0;

PerformanceSampling.StartSample(0, "StringAllocaitons");

string total_result = "";

for (int outer_loop = 0; outer loop < LOOP_ITERATIONS; outer_loop++) {

//Сбросить старый результат total_result = "";

//Выполнять цикл до максимального значения x_counter, каждый

//раз присоединяя очередную тестовую строку к рабочей строке

for (int x_counter = 0; x_counter < COUNT_UNTIL; x_counter++) {

total_result = total_result + numberToStore.ToString() + ", ";

//Увеличить значение счетчика

numberToStore ++;

}

}

PerformanceSampling.StopSample(0); //Отобразить длину строки

System.Windows.Forms.MessageBox.Show("Длина строки: " + total_result.Length.ToString());

//Отобразить строку

System.Windows.Forms.MessageBox.Show("Строка : " + total_result);

//Отобразить длительность интервала времени, ушедшего на вычисления

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(0));

}

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

//ГОРАЗДО БОЛЕЕ ЭФФЕКТИВНЫЙ АЛГОРИТМ!

//

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

//объект StringBuilder

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

private void button2_Click(object sender, System.EventArgs e) {

//Вызвать сборщик мусора, чтобы тест

//начинался с чистого состояния.

//ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

//сборщика мусора в программах вручную будут приводить

//к снижению общей производительности приложений!

System.GC.Collect();

System.Text.StringBuilder sb = new System.Text.StringBuilder();

string total_result = "";

int numberToStore = 0;

PerformanceSampling.StartSample(1, "StringBuilder");

for (int outer_loop = 0; outer_loop < LOOP_ITERATIONS; outer_loop++) {

//Очистить объект StringBuilder (не создавая нового объекта)

sb.Length = 0;

//Очистить строку со старым результатом

total_result = "";

//Выполнять цикл до максимального значения x_counter, каждый раз

//присоединяя очередную тестовую строку к рабочей строке

for (int x_counter = 0; x_counter < COUNT_UNTIL; x_counter++) {

sb.Append(numberToStore);

sb.Append(", ");

//Увеличить значение счетчика

numberToStore++;

}

//Имитируем выполнение некоторых операций над строкой...

total_result = sb.ToString();

}

PerformanceSampling.StopSample(1);

//Отобразить длину строки

System.Windows.Forms.MessageBox.Show("Длина строки: " + total_result.Length.ToString());

//Отобразить строку

System.Windows.Forms.MessageBox.Show("String : " + total_result);

//Отобразить длительность интервала времени, ушедшего на вычисления

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(1));

}

Таблица 8.3. Сравнение результатов (в секундах) для 40×300 циклов, выполненных с использованием эмулятора

Порядковый номер теста

Неэкономное распределение памяти для строк

Использование класса StringBuilder

1

25,475

0,85

2

25,225

0,925

3

24,5

0,875

Среднее

25,07

0.88

Экономия времени по сравнению с базовым уровнем

0%

96,5%

Таблица 8.4. Сравнение результатов (в секундах) для 40×300 циклов, выполненных на физическом устройстве Pocket PC

Порядковый номер теста

Неэкономное распределение памяти для строк

Использование класса StringBuilder

1

22,502

6,257

2

22,34

6,346

3

22,378

6,35

Среднее

22,41

6,32

Экономия времени по сравнению с базовым уровнем

0%

71,8%

Ниже представлен анализ полученных результатов.

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

■ Создание новых строк в циклах приводит к образованию большого количества "мусора". Если имеется достаточный объем свободной памяти, сборщик мусора при необходимости может выполняться в процессе работы алгоритма. Он может выполняться несколько раз, а в условиях острого дефицита свободной памяти он может работать почти непрерывно. Усиливающаяся нехватка памяти приводит к постепенному ухудшению производительности. Даже после того как выполнение алгоритма завершается, остается много мусора, от которого следует очистить память. При этом вы должны найти все ранее распределенные, а затем удаленные объекты и окончательно освободить от них память.

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

Резюме

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

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

Среда выполнения вашего мобильного приложения во многом может быть уподоблена небольшой квартире- Пока такая квартира не слишком забита вещами, проживание в ней может доставлять одно удовольствие. Стоит, однако, вещам загромоздить ее, как вам станет трудно перемещаться по ней и вообще что-либо делать. Если в процессе вашей ежедневной деятельности создается много мусора, то вам приходится часто выносить мусорное ведро и тратить время на наведение порядка вместо того, чтобы заниматься полезной работой. На макроуровне в обыденной жизни следует стремиться к тому, чтобы жилье было опрятным и просторным, а все необходимые вещи были всегда под рукой. Что касается микроуровня, то следует просто не мусорить!

ГЛАВА 9

Производительность и многопоточное выполнение

Время пожирает все.

Овидий (43 до н.э.–17 н.э.), римский поэт

(Encarta 2004, Quotations)

Введение: когда и как следует использовать многопоточное выполнение

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

Как водится, сначала — плохие новости. За некоторыми исключениями, от введения дополнительных потоков ваш код работать быстрее не будет. Более того, в абсолютном смысле дополнительные потоки почти всегда лишь замедляют выполнение кода. Это происходит потому, что вы предоставляете операционной системе еще один поток, который ей приходится обслуживать, временами переключаясь на него. Переключение системы между различными потоками отрицательно сказывается на производительности.

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

А теперь — хорошие новости. Фоновые потоки могут быть весьма полезными. Благодаря фоновым потокам вы можете организовать в одном приложении несколько потоков выполнения команд приложения. Микропроцессор предоставляет каждому потоку квант времени для выполнения, и еще некоторое время тратится на переключение между потоками. Несмотря на то что общее количество инструкций программы, выполненных несколькими параллельными потоками, всегда будет меньше, чем в случае их выполнения единственным потоком, которому предоставлены все кванты времени, два потока могут решать параллельно разные задачи. Иногда такая возможность оказывается весьма ценной.

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

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

Многозадачность и многопоточность в современных операционных системах

Существующие на сегодняшний день современные многозадачные операционные системы позволяют использовать микропроцессор как разделяемый ресурс. Микропроцессорное время распределяется между различными задачами таким образом, что с точки зрения задачи она является единственным владельцем этого ресурса. Это называется многозадачностью, а на выполняемые задачи ссылаются как на процессы. В каждый момент времени на вашем мобильном устройстве выполняются, вероятно, одновременно несколько задач. Скорее всего, количество этих задач больше, чем вы могли бы думать. Некоторые из них обслуживают низкоуровневые потребности, так что "приложениями" вы их даже и не назовете, тогда как другие представляют собой хорошо знакомые вам программы. Время от времени операционная прерывает выполнение задачи в некоторой точке и передает управление другому ожидающему процессу или потоку. Все это хорошо работает, поскольку большую часть времени приложения ничем особенным не заняты; обычно они просто ожидают какого-либо ввода, который необходимо будет обработать. Если же каждый из процессов приложения использует все отведенное для него процессорное время для вычисления значения числа ??!pi□ с бесконечной точностью, то общая производительность значительно страдает. Многозадачность оправдывается тогда, когда значительную часть времени возможности микропроцессора используется в недостаточной степени.

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

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

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

Использование нескольких потоков выполнения в рамках одного и того же пространства памяти приложения может приводить к значительному усложнению кода приложения, обусловленному недетерминированностью времени выполнения вычислений. Попытки двух потоков получить доступ к одним и тем же областям памяти примерно в одно и то же время могут стать причиной возникновения сложных и не до конца определенных ситуаций. Это справедливо как в случае собственного кода С/С++, так и в случае управляемого кода. Для решения проблем подобного рода предназначены блокировки, мьютексы, семафоры и критические разделы; объекты последней разновидности позволяют создавать разделы кода, не являющиеся реентерабельными. В целом, многопоточность напоминает многоярусную автостраду, где есть участки, на которых все движение сливается в одну трассу. И вновь заметим, что подробному рассмотрению всех сложностей и подводных камней параллельного выполнения кода можно было бы посвятить целую книгу.

В конечном счете, все различные процессы и потоки конкурируют между собой за право захватить возможность выполнения на единственном процессоре (или на пуле процессоров, если речь идет о многопроцессорных системах). Каждый процесс может иметь, по крайней мере, один поток, но некоторые процессы могут иметь и несколько потоков выполнения. Операционная система делает все, что возможно, для обеспечения равноправного распределения процессорного времени между процессами и их потоками (примечание: "равноправие" не означает "поровну"), пытаясь минимизировать накладные расходы, связанные с переключением соответствующих контекстов.

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

Что можно сказать об оборудовании, поддерживающем несколько процессоров?

На многих серверах и некоторых настольных компьютерах устанавливаются несколько микропроцессоров. "Многоядерные" ("multicore") системы с дополнительными микропроцессорами становятся все более распространенными; такие микропроцессоры размещаются на одном кристалле и предоставляют многие из тех преимуществ, которые обеспечиваются наличием нескольких физически независимых процессоров. Многопроцессорные системы обеспечивают возможность подлинно одновременного выполнения кода.

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

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

1. Кроме вашего приложения, операционная система почти всегда выполняет другие процессы, а также заботится о собственных нуждах и осуществляет учет использования ресурсов задачами, например, управляет низкоуровневыми драйверами устройств и планирует задачи. Это означает, что ваше приложение не может рассчитывать на то, что в любой момент времени всеми процессорами, установленными на устройстве, будут распоряжаться только его потоки. Введение дополнительного процесса или потока просто создает "еще один рот", который операционная система, уже и так разделяющая свои вычислительные ресурсы между различными многочисленными задачами, должна накормить. Без получения от операционной системы специального разрешения на выделение процессора определенному потоку выполнения ваше приложение просто создает дополнительный запрос на использование доступных процессорных ресурсов.

2. Практическое проектирование надежных алгоритмов параллельных вычислений представляет собой непростую задачу. Разбиение вычислений на ряд независимых ветвей выполнения и их эффективная координация весьма затруднительны и являются предметом непрекращающихся исследований. Если несколько потоков выполняют различные части одной и той же задачи, то существует значительный риск того, что они где-то пересекутся, пытаясь одновременно получить доступ к одной и той же области памяти или стремясь использовать некоторый ресурс, не допускающий параллельного доступа.

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

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

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

В каких случаях следует использовать фоновые потоки

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

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

1. Создайте новый поток. В этой модели запускается новый поток, в качестве точки входа которого указывается нужная функция. Функция начинает выполняться, а по ее завершении выполнение потока прекращается.

2. Воспользуйтесь ожидающим потоком. В этой модели фоновый поток или пул потоков создаются заблаговременно и ждут, пока для них не найдется работа. В типичных случаях фоновые потоки находятся в состоянии ожидания или в блокированном состоянии и ожидают, пока их не пробудит некоторое действие, или периодически пробуждаются в соответствии с сигналами соответствующего таймера. Пробужденный поток выполняет затребованную работу, после чего вновь засыпает в ожидании очередных запросов, которые могут вновь его пробудить.

НА ЗАМЕТКУ

В версии NET Framework для настольных компьютеров имеется встроенная поддержка потоковых пулов. В этой модели для передачи выполнения работы ожидающему потоковому пулу используются "асинхронные делегаты". В версии 1 1 .NET Compact Framework поддержка универсальных асинхронных делегатов отсутствует.

Программисты на С/С++ могут рассматривать делегаты как аналоги указателей на функции. Программисты на LISP могут считать их аналогичными оболочкам. Делегаты позволяют задать привязку к методу определенного объекта и впоследствии вызвать этот метод, не ссылаясь на объект или имя конкретного метода. .NET Compact Framework обеспечивает поддержку делегатов. Асинхронные делегаты позволяют выполнять в асинхронном режиме методы, с которыми они связаны, с использованием потока из пула фоновых потоков. Указанный потоковый пул управляется средой времени выполнения. Асинхронные делегаты являются превосходным средством абстрагирования, поскольку освобождают разработчика от необходимости самостоятельного проектирования и тестирования собственных механизмов управления потоковыми пулами. Поскольку .NET Compact Framework с самого начала предназначалась для выполнения на устройствах с ограниченными ресурсами, взаимодействие между потоками для передачи параметров, что требуется при использовании асинхронных делегатов общего назначения, проектным решением для версии 1.1 не предусматривалось. Если вы хотите поддерживать потоковый пул, используя .NET Compact Framework, и выполнять фоновые задачи с использованием управляемых потоков, то можете это осуществить путем явного вызова метода System.Threading.ThreadPool.QueueUserWorkItem().

Вместо поддержки универсальных асинхронных делегатов в NET Compact Framework предусмотрена встроенная поддержка выполнения некоторых часто запрашиваемых задач в асинхронном режиме. В отношении таких задач, как создание HTTP-запроса данных с Web- сервера, поддержка асинхронного режима в .NET Compact Framework и .NET Framework совпадает. Кроме того, поддерживается класс System.Threading.Timer, обеспечивающий выполнение делегатов таймера фоновыми потоками. (Управляет этими потоками среда времени выполнения.) Таким образом, несмотря на то. что универсальные асинхронные делегаты в версии 1.1 NET Compact Framework не поддерживаются, в этой версии реализована поддержка конкретных асинхронных вызовов для большинства наиболее распространенных задач.

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

Рекомендации по использованию потоков в мобильных приложениях

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

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

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

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

Начинайте с создания однопоточного приложения

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

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

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

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

Рассмотрите возможность использования фоновых потоков, если выполнение задачи требует длительного или неопределенного времени

Подход, основанный на использовании курсора ожидания, является не совсем уместным, если либо 1) ожидаемая продолжительность выполнения задачи настолько велика, что длительное отображение этого курсора лишь усилит раздражение пользователя, либо 2) длительность выполнения задачи неизвестна или не ограничена, что бывает при доступе к внешним ресурсам устройства. В обоих случаях проанализируйте возможность использования фоновых потоков.

Максимально упрощайте многопоточный код и документируйте его для повышения надежности

Безопасность многопоточной поддержки — штука хитрая. Если не уделить должное внимание тому, как осуществляется считывание и запись переменных-членов, то может случиться так, что ваше приложение будет пытаться прочитать в одном потоке переменную, запись которой была начата другим потоком, но еще не успела закончиться; "атомарность", то есть неделимость — выполнение за один раз от начала до конца, для большинства операций над данными, находящимися в памяти, не гарантируется, поскольку для записи большинства типов данных требуется выполнение нескольких инструкций микропроцессора. Тот факт, что возникновение проблем подобного рода зависит от временных характеристик выполнения потоков и случается редко, значительно затрудняет их обнаружение, воспроизведение и отладку. Даже ecли гарантирована атомарность доступа к переменным, но при этом было уделено недостаточное внимание тому, как осуществляются вызовы функций-членов классов, то вы можете оказаться в ситуации, когда либо портятся данные, либо программа ведет себя непредсказуемым образом, поскольку соответствующие данные параллельно изменяются алгоритмами, выполняющимися разными потоками; представьте, например два потока, которые одновременно пытаются вставлять и удалять записи в одном и том же связанном списке. Для надежной обработки таких ситуаций необходимо определить "критические разделы" кода; тем самым будет гарантироваться, что любой код, связанный с одним и тем же объектом семафора, сможет выполнять только одним потоком. (В C# это достигается за счет использования оператора lock(объект), а в Visual Basic — с использованием оператора SyncLock(объект). Для получения более подробной информации относительно двух указанных операторов обратитесь к библиотеке справочной документации MSDN.) Ситуацию могут еще более осложнять "зависания", или "взаимоблокировки", когда два потока, выполняющиеся в одно и то же время в разных критических разделах, вызывают код, который должен войти в критический раздел, "принадлежащий" в данный момент другому потоку; при вхождении в критический раздел другого потока будет приостановлено выполнение каждого потока. По этой причине, а также с учетом факторов производительности, чрезмерно вольное использование критических разделов может привести к появлению дополнительных проблем.

Вы могли бы попытаться сделать все свойства и методы своих классов безопасными в отношении многопоточного выполнения, однако осуществить это чрезвычайно трудно с технической точки зрения и расточительно с точки зрения производительности. В конце концов, весь код вашего приложения оказался бы испещренным множеством самых различных критических разделов и бесчисленным количеством всевозможных объектов, используемых в качестве семафоров совместно с критическими разделами. Код такого типа чрезвычайно трудно проектировать и тестировать; кроме того, он характеризуется повышенными накладными расходами, обусловленными необходимостью осуществления проверок, обеспечивающих безопасность многопоточности, и чрезмерно сериализованным выполнением. Ни в .NET Framework, ни в .NET Compact Framework попытки решения этой задачи не делаются; вместо этого в обеих средах используется подход, основанный на тщательном документировании всех возможностей, и явное объявление того, какие операции безопасны в отношении многопоточного выполнения, а какие таковыми не являются. Предполагается, что разработчики внимательно ознакомятся с документацией и будут ею руководствоваться при использовании классов, свойств и методов. Метод класса, не являющийся безопасным в указанном смысле, не должен вызываться для параллельного выполнения из других потоков. Вместо этого, следует либо создать два различных экземпляра класса, либо сериализовать вызов не являющегося безопасным метода, поместив его в критический раздел. Именно таким способом обеспечивается доступ ко всему, что является необходимым и безопасным, а что таковым не является — документируется.

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

// К ДАННОЙ <ПЕРЕМЕННОЙ/СВОЙСТВУ/МЕТОДУ> ДОСТУП ИЗ НЕСКОЛЬКИХ ПОТОКОВ

// ОСУЩЕСТВЛЯТЬСЯ НЕ ДОЛЖЕН!!!

// Предполагается, что этот метод будет использоваться

// <высокоприоритетным/фоновым> потоком для ...

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

Рассмотрите возможность предварительного выполнения некоторой работы, осуществляемой кодом

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

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

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

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

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

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

Оптимизация загрузки изображений программой просмотра основывается на вполне разумных предположениях:

1. В большинстве случае порядок просмотра фотографий соответствует продвижению по списку в прямом направлении.

2. Обычно каждую фотографию рассматривают достаточно долго для того, чтобы система успела выполнить фоновую загрузку следующей фотографии.

Независимо от того, используется ли в программе просмотра изображений Windows XP фоновый поток для решения этой задачи или не используется (мне это неизвестно), она демонстрирует пример разумного применения асинхронной обработки для оптимизации рабочего процесса в случае наиболее распространенных действий. Прекрасная работа!

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

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

Кроме того, в рассматриваемом примере основному потоку предоставляется возможность запрашивать прекращение выполнения фоновой задачи. Для уведомления потока, выполняющего фоновую задачу, о поступлении запроса на прекращение выполнения, используется вызов метода m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.requestAbort) из другого потока. За периодическую проверку этого состояния и осуществление возможного прекращения выполнения операции отвечает код, выполняемый фоновым потоком. Конечный автомат для класса ThreadExecuteTask представлен на рис. 9.1.

Рис. 9.1. Конечный автомат для отдельной задачи, выполняемой фоновым потоком

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

using System;

public class ThreadExecuteTask {

//Перечисляем возможные состояния

public enum ProcessingState {

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

//Начальное состояние

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

//Пока ничего интересного не происходит

notYetStarted,

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

//Рабочие состояния

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

//Ожидание запуска фонового потока

waitingToStartAsync,

//Выполнение кода в фоновом потоке

running,

//Запросить отмену выполнения вычислений

requestAbort,

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

//Состояния завершения

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

//Состояние завершения: выполнение фонового потока

//успешно завершено

done,

//Состояние завершения: выполнение потока отменено

//до его завершения

aborted

}

ProcessingState m_processingState;

public delegate void ExecuteMeOnAnotherThread(ThreadExecuteTask checkForAborts);

private ExecuteMeOnAnotherThread m_CallFunction;

private object m_useForStateMachineLock;

public ThreadExecuteTask(ExecuteMeOnAnotherThread functionToCall) {

//Создать объект, который мы можем использовать

//в конечном автомате в целях блокировки

m_useForStateMachineLock = new Object();

//Обозначить готовность к началу выполнения

m_processingState = ProcessingState.notYetStarted;

//Сохранить функцию, которую необходимо вызвать

//в новом потоке

m_CallFunction = functionToCall;

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

//Создать новый поток и вызвать в нем функцию на выполнение:

// this.ThreadStartPoint()

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

System.Threading.ThreadStart threadStart;

threadStart = new System.Threading.ThreadStart(ThreadStartPoint);

System.Threading.Thread newThread;

newThread = new System.Threading.Thread(threadStart);

//Обозначить готовность к началу выполнения (в целях определенности

//это важно сделать еще до того, как будет запущен поток!)

setProcessingState(ProcessingState.waitingToStartAsync);

//Дать ОС команду начать выполнение нового потока в асинхронном режиме

newThread.Start();

//Возвратить управление функции, вызывающей этот поток

}

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

//Эта функция является точкой входа, вызываемой

//для выполнения в новом потоке

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

private void ThreadStartPoint() {

//Установить состояние обработки, соответствующее

//выполнению функции в новом потоке!

setProcessingState(ProcessingState.running);

//Запустить на выполнение пользовательский код и передать указатель в

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

//запрос на прекращение выполнения

m_CallFunction(this);

//Если выполнение не было отменено, изменить состояние таким образом,

//чтобы оно соответствовало успешному завершению

if (m_processingState != ProcessingState.aborted) {

//Обозначить завершение выполнения

setProcessingState(ProcessingState.done);

}

//Выйти из потока...

}

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

//Конечный автомат

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

public void setProcessingState(ProcessingState nextState) {

//B любой момент времени только одному потоку выполнения

//могут быть разрешены попытки изменить состояние

lock(m_useForStateMachineLock) {

//B случае попытки повторного вхождения в текущее состояние

//никакие дополнительные действия не выполняются

if (m_processingState == nextState) {

return;

}

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

//Простейший защитный код, гарантирующий

//невозможность перехода в другое состояние, если задача

//либо успешно завершена, либо успешно отменена

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

if ((m_processingState == ProcessingState.aborted) ||

(m_processingState == ProcessingState.done)) {

return;

}

//Убедиться в допустимости данного изменения состояния

switch (nextState) {

case ProcessingState.notYetStarted:

throw new Exception("Переход в состояние 'notYetStarted' невозможен");

case ProcessingState.waitingToStartAsync:

if (m_processingState != ProcessingState.notYetStarted) {

throw new Exception("Недопустимое изменение состояния");

}

break;

case ProcessingState.running:

if (m_processingState != ProcessingState.waitingToStartAsync) {

throw new Exception("Недопустимое изменение состояния");

}

break;

case ProcessingState.done:

//Мы можем завершить работу лишь тогда, когда она выполняется.

//Это возможно также в тех случаях, когда пользователь затребовал

//отмену выполнения, но работа к этому моменту уже была закончена

if ((m_processingState != ProcessingState.running) &&

(m_processingState != ProcessingState.requestAbort)) {

throw new Exception("Недопустимое изменение состояния");

}

break;

case ProcessingState.aborted:

if (m_processingState != ProcessingState.requestAbort) {

throw new Exception("Недопустимое изменение состояния");

}

break;

}

//Разрешить изменение состояния

m_processingState = nextState;

}

}

public ProcessingState State {

get {

ProcessingState currentState;

//Предотвратить попытки одновременного чтения/записи состояния

lock(m_useForStateMachineLock) {

currentState = m_processingState;

}

return currentState;

}

}

} //Конец класса

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

Листинг 9.2. Тестовая программа для выполнения работы в фоновом потоке

using System;

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

//Тестовый код, который используется для выполнения

//фоновым потоком

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

public class Test1 {

public int m_loopX;

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

//Функция, вызываемая фоновым потоком

// [in] threadExecute: Класс, управляющий выполнением нашего потока.

// Мы можем контролировать его для проверки

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

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

public void ThreadEntryPoint(ThreadExecuteTask threadExecute) {

//Это окно сообщений будет отображаться в контексте того потока,

//в котором выполняется задача

System.Windows.Forms.MessageBox.Show("Выполнение ТЕСТОВОГО ПОТОКА");

//------

//60 раз

//------

for (m_loopX = 0; m_loopX < 60; m_loopX++) {

//Если затребована отмена выполнения, мы должны завершить задачу

if (threadExecute.State == ThreadExecuteTask.ProcessingState.requestAbort) {

threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.aborted);

return;

}

//Имитировать выполнение работы: пауза 1/3 секунды

System.Threading.Thread.Sleep(333);

}

}

} //Конец класса

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

Листинг 9.3. Код для запуска и тестирования приведенного выше тестового кода

//Класс, который будет управлять выполнением нового потока

private ThreadExecuteTask m_threadExecute;

//Класс, метод которого мы хотим выполнять в асинхронном режиме

Test1 m_testMe;

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

//Этот код должен быть запущен ранее другого кода, поскольку

//он запускает новый поток выполнения!

//

//Создать новый поток и обеспечить его выполнение

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

private void buttonStartAsyncExecution_Click(object sender, System.EventArgs e) {

//Создать экземпляр класса, метод которого мы хотим вызвать

//в другом потоке

m_testMe = new Test1();

//Упаковать точку входа метода класса в делегат

ThreadExecuteTask.ExecuteMeOnAnotherThread delegateCallCode;

delegateCallCode = new ThreadExecuteTask.ExecuteMeOnAnotherThread(m_testMe.ThreadEntryPoint);

//Дать команду начать выполнение потока!

m_threadExecute = new ThreadExecuteTask(delegateCallCode);

}

//Проверить состояние выполнения

private void buttonCheckStatus_Click(object sender, System.EventArgs e) {

//Запросить у класса управления потоком, в каком состоянии он находится

System.Windows.Forms.MessageBox.Show(m_threadExecute.State.ToString());

//Запросить класс, метод которого выполняется в потоке,

//о состоянии выполнения

System.Windows.Forms.MessageBox.Show(m_testMe.m_loopX.ToString());

}

//Принудительно вызвать запрещенное изменение состояния

//(это приведет к возбуждению исключения)

private void buttonCauseException_Click(object sender, System.EventArgs e) {

m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.notYetStarted);

}

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

private void buttonAbort_Click(object sender, System.EventArgs e) {

m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.requesAbort);

}

Потоки и пользовательский интерфейс

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

Обычно окна связываются с потоком, который является их владельцем; это справедливо для операционных систем Windows СЕ, Pocket PC и Microsoft Smartphone (а также для таких настольных операционных систем, как Windows XP и более ранние версии Windows). Для каждого окна имеется поток, которому оно принадлежит и который им управляет. Один и тот же поток может владеть несколькими окнами. Поток играет роль "генератора сообщений" по отношению к этим окнам и пересылает им сообщения, когда окно должно быть перерисовано, когда нажимается клавиша, когда выполняется щелчок на кнопке и так далее.

Хотя и можно организовать приложение таким образом, чтобы пользовательский интерфейс обслуживался несколькими потоками (например, по одному потоку на одно окно верхнего уровня), это почти никогда не принесет никакой пользы. Это только усложняет структуру приложения, ничуть не ускоряя его работу. Если вы считаете, что для пользовательского интерфейса необходимо задействовать несколько потоков, задайте себе вопрос, а для чего это в действительности вам надо и нельзя ли при этом использовать один основной поток пользовательского интерфейса и несколько рабочих фоновых потоков, что сделает модель гораздо более понятной.

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

Даже если ваша оконная модель и не связана с какими-либо специфическими потоками, обычно целесообразнее иметь только один поток выполнения, который "берет на себя попечительство" над пользовательским интерфейсом.

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

Ни вариант .NET Framework для настольных компьютеров, ни вариант .NET Compact Framework для мобильных устройств не поддерживают доступ к большинству свойств и методов элементов пользовательского интерфейса из потоков, которым они не принадлежат. Хотя такой код и будет нормально компилироваться, результаты его выполнения будут непредсказуемыми. Для обеспечения межпоточных вызовов в .NET Framework и .NET Compact Framework поддерживается метод Control.Invoke(). В версии 1.1 .NET Compact Framework поддерживается лишь использование механизма Control.Invoke() для вызова функций без параметров. Более подробную информацию относительно применения этого метода вы найдете в справочной документации MSDN. Не составляет труда организовать на приемлемом уровне обмен данными между фоновым потоком и потоком пользовательского интерфейса, предусмотрев для этого выполняющийся в потоке пользовательского интерфейса код, который периодически опрашивает объект, специально предназначенный для управления выполнением фоновых потоков, с целью определения того, имеются ли данные, ожидающие реакции пользовательского интерфейса. Обычно сделать это гораздо проще, чем погружаться во все тонкости межпоточного вызова методов.

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

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

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

Данное приложение несложно адаптировать для выполнения на Pocket PC. Наш выбор Microsoft Smartphone в качестве целевой платформы был сделан исключительно в интересах разнообразия.

Рис. 9.2. Окно интегрированной среды разработки Visual Studio, предcтавляющее проектируемый пользовательский интерфейс приложения типа Smartphone

Рис. 9.3. Экранные снимки эмулятора Smartphone, полученные в процессе вычисления приложением простых чисел

НА ЗАМЕТКУ

Если вы используете 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.

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

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и создайте проект C# Smart Device Application.

2. Выберите в качестве целевой платформы Smartphone. (Для вас будет автоматически создан проект, и на экране появится конструктор форм для Smartphone.)

3. Используя рис. 9.2 в качестве образца для компоновки формы, добавьте в нее следующие элементы управления:

• TextBox (textBox1); задайте в качестве значения свойства Text длинную текстовую строку (например, 12345678901234).

• Label (label1); измените размеры элемента управления Label таким образом, чтобы он занимал большую часть области формы. В нем придется отображать текст, состоящий из нескольких строк.

• Timer (timer1).

4. Выделите компонент MainMenu в нижней части окна конструктора форм и добавьте следующие пункты меню:

• Перейдите к крайнему слева меню (содержащему текст "Type Here" ("Набирайте здесь")) и введите Exit в качестве текста меню. Используя окно Properties, измените имя элемента меню с menuItem1 на menuItemExit.

• Справа от меню Exit, которое вы только что добавили (там, где находится текст "Type Here"), введите Prime Search в качестве текста меню. Примечание: при необходимости обратитесь к рис. 9.2.

• Над меню Prime Search, которое вы только что добавили (там, где находится текст "Type Here"), введите Start в качестве текста меню. Используя окно Properties, измените имя элемента меню с menuItem2 на menuItemStart. Примечание: при необходимости обратитесь к рис. 9.2.

• Ниже меню Start, которое вы только что добавили (там, где находится текст "Type Here"), введите Abort в качестве текста меню. Используя окно Properties, измените имя элемента меню с menuItem2 на menuItemStart. Примечание: при необходимости обратитесь к рис. 9.2.

5. Добавьте в проект новый класс. Назовите его FindNextPrimeNumber.сs. Замените содержимое кода класса в окне редактора кодом из листинга 9.5.

6. Перейдите обратно в окно Form1.cs [Design] и дважды щелкните на элементе меню Exit. В результате этого будет автоматически сгенерирована функция void menuItemExit_Click(), а фокус переместится в окно редактора кода. Введите для этой функции код из листинга 9.4.

7. Перейдите обратно в окно Form1.cs [Design] и дважды щелкните на элементе меню Start. В результате этого будет автоматически сгенерирована функция private void menuItemStart_Click(), а фокус переместится в окно редактора кода. Введите для этой функции код из листинга 9.4.

8. Перейдите обратно в окно Form1.cs [Design] и дважды щелкните на названии меню Abort. В результате этого будет автоматически сгенерирована функция private void menuItemAbort_Click(), а фокус переместится в окно редактора кода. Введите для этой функции код из листинга 9.4.

9. Перейдите обратно в окно Form1.CS [Design] и дважды щелкните на элементе управления timer1 в нижней части окна конструктора. В результате этого будет автоматически сгенерирована функция private void timer1_Tick(). Введите для этой функции код из листинга 9.4.

10. Введите в класс Form1.cs остальную часть кода из листинга 9.4.

11. Нажмите клавишу <F5> для компиляции кода и развертывания приложения в эмуляторе Smartphone.

Запустив приложение, нажмите сначала кнопку телефона для вызова меню Prime Search, а затем — клавишу <1> для выбора пункта меню Start В результате этого начнется поиск простых чисел. В процессе выполнения поиска элемент управления timer1 будет несколько раз в секунду вырабатывать событие таймера, заставляющее пользовательский интерфейс обновлять отображаемый на форме текст с информацией о текущем состоянии. В результате динамического обновления этого текста, происходящего несколько раз в секунду, пользователь получает регулярное подтверждение того, что его запрос обрабатывается. Процесс поиска продолжается до тех пор, пока не будет найдено простое число или пока пользователь не выберет пункт Abort меню Prime Search и не нажмет кнопку <2>. Чтобы увеличить продолжительность поиска, перед тем, как его начать, введите в текстовом поле формы произвольное большое число. На моем эмуляторе поиск для начального числа 12345678901234 длился более 20 секунд. В том виде, как он есть, приведенный ниже код не препятствует запуску нового поиска в то время, когда предыдущий еще не закончился. Будет неплохо, если вы усовершенствуете приложение, введя в него проверку этого условия и прекращая выполнение текущего поиска, если к моменту запуска нового он еще не был закончен. Рекомендуется также, чтобы вы заглянули в код, представленный в листинге 9.5. и посмотрели, как ключевое слово lock используется для того, чтобы исключить параллельное вхождение различных потоков в критический раздел, не являющийся безопасным в отношении многопоточного выполнения.

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

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

//Весь этот код должен находиться внутри класса Form1.cs

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

//Объект, который будет выполнять все фоновые вычисления

FindNextPrimeNumber m_findNextPrimeNumber;

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

//Обновить текст, информирующий о состоянии...

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

void setCalculationStatusText(string text) {

label1.Text = text;

}

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

//Пункт меню для "выхода" из приложения

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

private void menuItemExit_Click(object sender, System.EventArgs e) {

this.Close();

}

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

//Пункт меню для начала фоновых вычислений

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

private void menuItemStart_Click(object sender, System.EventArgs e) {

//Число, с которого мы хотим начать поиск

long startNumber = System.Convert.ToInt64(textBox1.Text);

//Установить фоновое выполнение

m_findNextPrimeNumber = new FindNextPrimeNumber(startNumber);

//Запустить выполнение задачи в фоновом режиме

m_findNextPrimeNumber.findNextHighestPrime_Async();

//Установить таймер, используемый для контроля длительности вычислений

timer1.Interval = 400;

//400 мс timer1.Enabled = true;

}

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

//Пункт меню для "отмены" выполняющейся задачи

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

private void menuItemAbort_Click(object sender, System.EventArgs e) {

//He делать ничего, если вычисления не выполняются

if (m_findNextPrimeNumber == null) return;

//Установить поток в состояние прекращения выполнения

m_findNextPrimeNumber.setProcessingState(FindNextPrimeNumber.ProcessingState.reguestAbort);

//Немедленно известить пользователя

//o готовности прекратить выполнение...

setCalculationStatusText("Waiting to abort...");

// setCalculationStatusText("Ожидание прекращения выполнения...");

}

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

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

//позволяет отслеживать состояние выполнения

//фоновых вычислений

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

private void timer1_Tick(object sender, System.EventArgs e) {

//Если к моменту вызова искомое простое число еще

//не было найдено, отключить таймер

if (m_findNextPrimeNumber == null) {

timer1.Enabled =false;

return;

}

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

//Если выполнение было отменено, освободить объект,

//осуществляющий поиск, и выключить таймер

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

if (m_findNextPrimeNumber.getProcessingState ==

FindNextPrimeNumber.ProcessingState.aborted) {

timer1.Enabled = false;

m_findNextPrimeNumber = null;

setCalculationStatusText("Prime search aborted");

// setCalculationStatusText("поиск простого числа отменен");

return;

}

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

//Удалось ли найти правильный ответ?

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

if (m_findNextPrimeNumber.getProcessingState ==

FindNextPrimeNumber.ProcessingState.foundPrime) {

timer1.Enabled = false;

//Отобразить результат

setCalculationStatusText("Found! Next Prime = " + m_findNextPrimeNumber.getPrime().ToString());

// setCalculationStatusText("Чиcлo найдено! Следующее простое число = " +

// m_findNextPrimeNumber.getPrime().ToString());

m_findNextPrimeNumber = null;

return;

}

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

//Вычисления продолжаются. Информировать

//пользователя о состоянии выполнения

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

//Получить два выходных значения

long numberCalculationsToFar;

long currentItem;

m_findNextPrimeNumber.getExecutionProgressInfo(out numberCalculationsToFar,out currentItem);

setCalculationStatusText("In progress. Looking at: " +

currentItem.ToString() + ". " +

numberCalculationsToFar.ToString() +

" calculations done for you so far!");

// setCalculationStatusText("Вычисления продолжаются. Поиск в области: " +

// currentItem.ToString() + ". " +

// "Для вас выполнено " +

// numberCalculationsToFar.ToString() +

// " расчетов!");

}

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

using System;

public class FindNextPrimeNumber {

//Перечисляем возможные состояния

public enum ProcessingState {

notYetStarted,

waitingToStartAsync,

lookingForPrime,

foundPrime,

requestAbort,

aborted

}

long m_startPoint;

long m_NextHighestPrime;

//Поиск какого количества элементов выполнен?

long m_comparisonsSoFar;

//Для какого элемента сейчас выполняется поиск простого числа?

long m_CurrentNumberBeingExamined;

//Вызывается для обновления информации о состоянии выполнения

public void getExecutionProgressInfo(out long numberCalculationsSoFar, out long currentItemBeingLookedAt) {

//ПРИМЕЧАНИЕ. Мы используем блокирование потока для уверенности в том,

//что эти значения не считываются во время выполнения операции

//их записи. Поскольку доступ к m_comparisonsSoFar

//и m_CurrentNumberBeingExamined могут осуществлять

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

//операция записи/считывания должна синхронизироваться с "блокировкой",

//что будет гарантировать "атомарность" этих операций

lock (this) {

numberCalculationsSoFar = m_comparisonsSoFar;

currentItemBeingLookedAt = m_CurrentNumberBeingExamined;

}

}

ProcessingState m_processingState;

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

//Простейший конечный автомат

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

public void setProcessingState(ProcessingState nextState) {

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

//Простейший защитный код, гарантирующий

//невозможность перехода в другое состояние, если задача

//либо успешно завершена, либо успешно отменена

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

if ((m_processingState == ProcessingState.aborted) ||

(m_processingState == ProcessingState.foundPrime)) {

return;

}

//Разрешить изменение состояния

m_processingState = nextState;

}

public ProcessingState getProcessingState {

get {return m_processingState;}

}

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

//Возвращает простое число

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

public long getPrime() {

if (m_processingState != ProcessingState.foundPrime) {

throw new Exception("простое число еще не найдено!");

}

return m_NextHighestPrime;

}

//Конструктор класса

public FindNextPrimeNumber(long startPoint) {

setProcessingState(ProcessingState.notYetStarted);

m_startPoint = startPoint;

}

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

//Создает новый рабочий поток, который будет вызывать функцию

// "findNextHighestPrime()"

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

public void findNextHighestPrime_Async() {

System.Threading.ThreadStart threadStart;

threadStart = new System.Threading.ThreadStart(findNextHighestPrime);

System.Threading.Thread newThread;

newThread = new System.Threading.Thread(threadStart);

//Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.waitingToStartAsync);

newThread.Start();

}

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

//Основной рабочий поток. Этот поток запускает поиск очередного

//простого числа и выполняется до тех пор, пока не произойдет

//одно из следующих двух событий:

// (а) найдено очередное простое число

// (b) от внешнего (по отношению к данному) потока поступила

// команда прекратить выполнение

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

public void findNextHighestPrime() {

//Если поступила команда прекратить выполнение, то поиск

//даже не должен начинаться

if (m_processingState == ProcessingState.requestAbort) {

goto finished_looking;

}

//Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.lookingForPrime);

long currentItem;

//Проверить, является ли число нечетным

if ((m_startPoint & 1) == 1) {

//Число является нечетным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 2;

} else {

//Число является четным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 1;

}

//Приступить к поиску простого числа

while (m_processingState == ProcessingState.lookingForPrime) {

//B случае нахождения простого числа возвратить его

if (isItemPrime(currentItem) == true) {

m_NextHighestPrime = currentItem; //Обновить состояние

setProcessingState(ProcessingState.foundPrime);

}

currentItem = currentItem + 2;

}

finished_looking:

//Выход. К этому моменту либо от другого потока поступила

//команда прекратить поиск, либо было найдено и записано

//следующее наибольшее простое число

//Если поступил запрос прекратить выполнение,

//сообщить, что выполнение процесса прекращено

if (m_processingState == ProcessingState.requestAbort) {

setProcessingState(ProcessingState.aborted);

}

}

//Вспомогательная функция, которая проверяет, является

//ли число простым

private bool isItemPrime(long potentialPrime) {

//Если число — четное, значит, оно не является простым

if ((potentialPrime & 1) == 0) {

return false;

}

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

//значение квадратного корня из числа

long end_point_of_search;

end_point_of_search = (long)System.Math.Sqrt(potentialPrime) + 1;

long current_test_.item = 3;

while (current_test_item <= end_point_of search) {

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

//Проверить, не поступила ли команда прекратить выполнение!

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

if (m_processingState != ProcessingState.lookingForPrime) {

return false;

}

//Если число делится без остатка,

//значит, оно не является простым

if (potentialPrime % current_test_item == 0) {

return false;

}

//увеличить число на два

current_test item = current_test_item + 2;

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

//Увеличить количество проверенных элементов

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

//ПРИМЕЧАНИЕ. Мы используем блокирование потока для уверенности в том,

//что эти значения не считываются во время выполнения операции

//их записи. Поскольку доступ к m_comparisonsSoFar

//и m_CurrentNumberBeingExamined могут осуществлять

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

//операция записи/считывания должна синхронизироваться с "блокировкой",

//что будет гарантировать "атомарность" этих операций

lock(this) {

m_CurrentNumberBeingExamined = potentialPrime;

m_comparisonsSoFar++;

}

}

//Число является простым

return true;

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

} //Конец класса

Резюме

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

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

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

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

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

ГЛАВА 10

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

Введение: работа с XML

XML быстро становится излюбленным текстовым форматом, применяемым для хранения и передачи данных. Причины его повышенной по сравнению с обычными текстовыми файлами популярности имеют два аспекта: 1) иерархичность — данные могут легко сохраняться с использованием отношений "родительский-дочерний" между ними, и 2) полуструктурированность — XML допускает значительную гибкость в управлении структурной информацией, применяемой к данным, обмен которыми осуществляется. XML-данные могут либо жестко привязываться к определенной схеме (сама схема также может задаваться в виде XML-документа), либо передаваться как таковые в свободной форме без каких-либо формальных указаний относительно содержимого документа.

XML имеет много сходства с другим популярным форматом кодирования информации — HTML. HTML — это аббревиатура от HyperText Markup Language — язык гипертекстовой разметки, что, говоря простыми словами, означает использование "текстовых дескрипторов, описывающих то, как выглядит документ". Аналогичным образом, XML — это extensible Markup Language — расширяемый язык разметки документов, что в переводе на обычный язык означает использование "текстовых дескрипторов, описывающих данные". Язык XML является продуктом накопления опыта в процессе эволюции HTML, и оба эти языка происходят от более старого абстрактного формата SGML (Standard Generalized Markup Language — стандартный обобщенный язык разметки). Полуструктурированный иерархический текстовый формат HTML на практике доказал свою большую гибкость по сравнению со многими существующими до этого двоичными форматами. Популярные адаптированные варианты HTML, а затем и XML продемонстрировали, что компактностью двоичных форматов часто имеет смысл пожертвовать ради гибкости, расширяемости и переносимости текстовых форматов. Синтаксис дескрипторов и атрибутов, используемый в HTML для описания внешнего вида и содержимого документов, рассматривался многими разработчиками как мощная, расширяемая модель описания данных. Недостатки HTML обусловлены его быстрой эволюцией; поскольку в течение ряда лет этот формат претерпел естественные эволюционные изменения, в его синтаксисе имеются несоответствия, которые при последовательном подходе к разработке языка считались бы недопустимыми.

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

Как и HTML, язык XML имел успех постольку, поскольку была достигнута договоренность о его использовании для обмена информацией между различными системами. Важность широкого принятия этой методики невозможно переоценить. После того как формат получает всеобщее одобрение, вступают в силу сетевые эффекты, и популярная технология очень быстро становится доминирующей. На протяжении последних лет сфера применения XML постоянно расширяется, и теперь он используется в качестве базового формата для многих высокоуровневых коммуникационных форматов, включая SOAP (Simple Object Access Protocol — простой протокол доступа к объектам; лежит в основе Web служб), WSDL (Web Service Description Language — язык описания Web служб), XSL (eXtensible Schema Language — расширяемый язык описания схем), RSS (Really Simple Syndication — подлинно простое объединение данных; механизм распространения данных) и многие другие форматы. Некоторые XML-форматы носят универсальный характер, тогда как другие являются специфическими для определенной отрасли или технологии, принятой в компании. В настоящее время при проектировании новых форматов хранения и обмена данными вопрос часто заключается не в том, следует ли использовать XML, а в том, какой уровень абстракции поверх XML следует использовать. Вероятнее всего, установленные на вашем мобильном устройстве приложения, взаимодействующие с сетью, используют для нужд связи, хранения и обмена данными именно XML. Вы можете использовать данные в XML- форматах других систем, но вам также может потребоваться разработка собственных XML-форматов, которые должны будут использовать другие люди. Существуют различные подходы к организации работы с XML-документами, соответствующие различным уровням абстракции. Каждый из них характеризуется своими достоинствами и недостатками. По этим причинам очень важно твердо знать, как работать с XML, чтобы это наилучшим образом отвечало вашим запросам.

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

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

XML или не XML?

При всех тех возможностях, которые кроются в XML, легко предположить, что этот язык должен был бы привлекаться всегда, когда требуется осуществлять обмен данными или их хранение. Тем не менее, это не так. Гибкость XML придает ему мощь, но это дается за счет увеличения размера документов. Если требуется осуществить обмен данными сравнительно небольшого объема, то XML великолепно подходит для этой цели. Так, при загрузке 20 строк форматированных записей базы данных размер XML-файла может достигать 20 Кбайт, тогда как при использовании для передачи данных двоичного формата они могут быть сжаты до 2 Кбайт или менее.

Разницей в длительности загрузки 20 Кбайт и 2 Кбайт данных обычно можно пренебречь по сравнению с тем временем, которое затрачивается на установление соединения с сервером, обмен необходимыми подтверждениями и другие операции по настройке соединения. В обоих случаях абсолютное время ожидания пользователем завершения передачи данных сравнительно невелико, поэтому различия в объеме сохраняемых данных не имеют превалирующего значения при выборе проектного решения в отношении формата хранения данных.

Для сравнительно небольших объемов данных использование XML является вполне оправданным, поскольку это позволяет вам воспользоваться при обмене данными всеми преимуществами этого гибкого формата. Однако, что если объем данных увеличится в 10 раз и для выбора варианта проектного решения вам придется отвечать на вопрос: что лучше использовать — 200 Кбайт данных XML или 20 Кбайт двоичных данных? Начиная с таких объемов данных, длительность ожидания пользователем завершения процесса передачи данных между устройством и сервером становится все более заметной, и для принятия взвешенного решения требуется выполнить объективные измерения для каждого варианта реализации.

Важным фактором, который обязательно должен учитываться, является скорость передачи данных в сетях, используемых вашим мобильным устройством. Для некоторых данных при работе в сетях Wi-Fi проблемы длительности процесса обмена данными вообще не существует, тогда как в случае сетей мобильных телефонов, использующих протокол GRPS, может потребоваться тщательный анализ временных и стоимостных факторов. Если бы объем передаваемых данных был еще на порядок больше и вам пришлось бы выбирать между 2 Мбайт XML-данных и 200 Кбайт двоичных данных, то от вашего решения, какой формат данных использовать, зависело бы еще больше, поскольку теперь уже, скорее всего, задержки на установку соединения будут пренебрежимо малы по сравнению с длительностью фактической передачи данных. И при всем этом нельзя сбрасывать со счетов тот факт, что синтаксический анализ XML-данных потребует, как правило, большего времени по сравнению с анализом двоичных данных, специально оптимизированных под многократные загрузки.

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

Сравнение XML с другими текстовыми форматами

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

Различные способы хранения данных в виде текста

Предположим, что в нашем приложении требуется сохранять некоторые пользовательские данные. Эти данные состоят из трех элементов: идентификационного номера ID, имени и адреса. Приложению требуется сохранять эти данные для собственных нужд, но оно также может передавать их другому приложению. Тремя наиболее распространенными способами хранения таких данных в виде текста являются XML, значения с запятыми в качестве разделителей и значения в виде INI-файлов.

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

Как и в случае HTML, в XML данные сохраняются в виде текста, заключенного между дескрипторами, которые дополняют передаваемые данные контекстом:

<UserInfo>

<UserID> 12 </UserID>

<UserName> Bob </UserName>

<UserAddress> Someplace, Somewhere </UserName>

</UserInfo>

Следует отметить, что в XML те же данные можно сохранить с использованием атрибутов, например:

<UserInfo UserID="12" UserName="Bob" UserAddress="Someplace, Somewhere">

</UserInfo>

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

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

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

12, Bob, "SomePlace, Somewhere"

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

В прошлом популярным способом сохранения данных были INI-файлы. В INI-файлах данные сохраняются в виде пар "имя-значение":

[UserInfo]

UserID=12 UserName=Bob

UserAddress=Someplace, Somewhere

Существуют и другие распространенные форматы, например PropertyBag, которые по своим структурным свойствам и гибкости занимают промежуточное положение между XML и INI-файлами и были популярными среди разработчиков на Visual Basic 5 и 6. Что выделяет XML и ставит его выше многих предыдущих форматов — так это дополнительное структурирование данных. Эта структура делает возможным создание иерархических данных без расположения их в определенном порядке. Такой формат оказывается несколько более детализированным, чем многие другие текстовые форматы, но зато и гораздо более гибким. Эта гибкость значительно облегчает учет различий в версиях данных, а также сопровождение и передачу данных между различными системами.

Иерархическая структура XML-данных

Очень важно хорошо понимать иерархическую структуру XML. Представляйте себе XML-документ в виде дерева объектов, у каждого из которых могут иметься дополнительные дочерние объекты. Для демонстрации этого изменим приведенный выше пример таким образом, чтобы внести в него дополнительную иерархию:

<UserInfo>

<UserID> 12 </UserID>

<Name>

<FirstName> Иво </FirstName>

<LastName> Салмре </LastName>

</Name>

<Address>

<Street>10 НекаяУлица</Street>

<City>Сиэтл</City>

<State>WA</State>

</Address>

</UserInfo>

Здесь мы сделали узлы Name и Address подузлами UserInfo.

Другие возможности XML

В XML имеется гораздо больше возможностей, чем те, о которых было рассказано выше, включая стандартизованные схемы, типизированные данные и средства проверки действительности документов. В приведенных выше примерах были представлены лишь самые тривиальные образцы фрагментов XML. Хорошее описание всех тонкостей XML вы найдете как в документации .NET Framework, так и, как обычно, в Web. Данная книга и приводимые в ней примеры фокусируют внимание на практических аспектах использования XML на мобильных устройствах и ни в коей мере не могут рассматриваться в качестве исчерпывающего источника информации обо всех возможных сферах применениях XML.

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

Различные способы работы с XML

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

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

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

2. Использовать высокоуровневые универсальные методы синтаксического анализа с произвольным доступом, основанные на модели XML DOM. DOM (Document Object Model — объектная модель документов) обеспечивает возможность работы с XML-данными, хранящимися в памяти в виде иерархического дерева объектов. В результате использования высокоуровневого API-интерфейса для работы с XML вы получаете в высшей степени надежный код, удобный в сопровождении. Такой подход является оптимальным для небольших XML-документов, а также документов, при работе с которыми требуется постоянный произвольный доступ ко всем частям дерева XML документа, или документов, которые должны быть заново целиком сохранены в файле на диске.

3. Использовать низкоуровневый API-интерфейс XML, обеспечивающий выполнение лишь однонаправленных операций чтения-записи данных. Применение низкоуровневых API-интерфейсов позволяет максимально повысить производительность, но возлагает дополнительную нагрузку на программистов. Эти API-интерфейсы поддерживают выполнение операций чтения записи данных только в прямом направлении и позволяют считывать или записывать данные XML-дерева в виде потока XML-элементов без сохранения всего документа в памяти. В случае мобильных устройств, для которых память всегда является дефицитным ресурсом, и особенно при работе с большими объемами данных или данными, предназначенными только для чтения, только такой подход и обеспечивает достижение приемлемой производительности. Он представляет собой хорошую основу, являющуюся промежуточной между использованием высокоуровневых АРI-интерфейсов и развертыванием собственной методики. Такой путь является разумным, если привлечение высокоуровневых API-интерфейсов для удовлетворения ваших нужд требует интенсивных дополнительных вычислений и приводит к чрезмерному расходу памяти.

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

Простой пример, иллюстрирующий применение модели XML DOM и однонаправленного чтения-записи XML-документов

Ниже мы сравниваем использование высокоуровневой модели DOM и подхода, основанного на использовании однонаправленных операций чтения-записи XML- данных, на примере работы с простыми XML-документами. В обоих случаях генерируется и используется один и тот же XML-документ. Важно подчеркнуть что, ввиду крайней малости объема используемых XML-данных, приемлемую производительность обеспечивают оба подхода. Реальные различия в производительности скажутся лишь при увеличении объема данных. Чтобы представить мысленную картину того, как это могло бы выглядеть, вообразите, что узел данных UserInfo повторен сотни или тысячи раз. При желании вы можете создать файл данных, соответствующий такой ситуации, и использовать его для тестирования своих алгоритмов с целью сравнения результативности обоих подходов.

Пример: содержимое XML-файла

<AllMyData>

<UserInfo>

<UserID>14</UserID>

<Name>

<FirstName>Иво</FirstName>

<LastName>Caлмpe</LastName>

</Name>

</UserInfo>

</AllMyData>

Обращаю ваше внимание на тот факт, что в качестве узла наивысшего уровня я решил использовать не узел UserInfo, а размещенный над ним дополнительный узел. Такая практика поощряется, поскольку XML допускает существование на самом верхнем уровне только одного узла, который называется "корневым" ("root node"). Оставив в качестве корневого узел UserInfo, мы значительно ограничили бы свои возможности в отношении сохранения другой информации наивысшего уровня в файле без пересмотра проекта.

Использование типового узла наивысшего уровня позволяет свободно добавлять другие узлы нижележащего уровня по мере расширения потребностей. Так, для сохранения важной информации, не зависящей от пользователя, мы могли бы теперь в дополнение к узлу UserInfo ввести узлы ServerInfo и ApplicationInfo. Кроме того, пользователей может быть несколько, и для каждого из них требуется ввести свой узел UserInfo. Описанная выше структура поддерживает включение нескольких разделов UserInfo, следующих один за другим, что было бы невозможным, если бы узел UserInfo был корневым

XML DOM

XML DOM работает с представлением данных в виде дерева объектов в памяти. Каждый XML-элемент представляется хранящимся в памяти объектом. Можно считать, что подход XML DOM в значительной степени основан на концепции состояния в том смысле, что все данные, необходимые для воссоздания XML-документа после его считывания, загружаются как состояние. XML-деревья могут создаваться в памяти, а затем сериализоваться в файлы или через сетевые потоки. Аналогичным образом, любое XML-содержимое или XML-документ, полученный с использованием любого потока данных, могут быть использованы для заполнения дерева XML DOM в памяти.

Создание дерева объектов в памяти является удобным способом работы с данными среднего объема, которые требуется всего лишь последовательно обновлять. XML-файл размером 20 Кбайт можно довольно быстро загрузить в память и после работы с ним в памяти как с деревом объектов вновь сохранить в файловой системе. Коль скоро объемы интересующих нас данных невелики, модель XML DOM предоставляет отличные возможности для создания XML-документов, обработки их в памяти и вывода XML-данных в файл или сетевой поток.

Применимость DOM-подхода ограничивается как объемом памяти, доступной для размещения сгенерированного анализатором дерева объектов, так и наличием резервов вычислительной мощности, необходимых для разбора всего дерева XML-данных. Недостатком подхода, основанного на XML DOM, является его монолитность; прежде чем вы сможете получить доступ к XML-данным, вы должны выполнить синтаксический анализ документа и разместить в памяти все содержимое файла или потока. Если вам необходимо работать лишь с небольшим объемом данных, содержащихся в файле большого размера, то доступ к этим данным будет сопряжен с большими накладными расходами.

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

■ XML DOM — простая и вместе с тем предлагающая богатые возможности программная модель. Представление XML-документа деревом объектов, хранящимся в памяти, упрощает работу с данными, к которым требуется произвольный доступ.

■ XML DOM отлично подходит для работы с данными небольшого или среднего объема. Коль скоро файл данных имеет достаточно небольшие размеры, его содержимое не займет слишком много места в памяти.

■ XML DOM — наилучший выбор, если необходимо работать (имея возможность вносить изменения) сразу со всеми находящимися в памяти XML-данными. XML DOM является чрезвычайно мощным инструментом, если вашему приложению необходимо работать с данными в режиме произвольного доступа, а данные после их обработки должны быть заново сохранены в файле на диске или потоке.

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

■ Модель программирования XML DOM вынуждает вас выполнять синтаксический анализ и загрузку XML-данных в дерево объектов, хранящееся в памяти, прежде чем вы сможете получить к ним доступ. Слишком расточительно создавать в памяти крупное по размерам дерево всего документа, если вашему приложению требуется доступ лишь к небольшой части входящих в него XML-данных.

■ Использование модели XML DOM приведет к постепенному снижению производительности по мере роста размеров XML-документов. Поскольку в случае крупных файлов многие объекты будут создаваться в условиях ограниченных ресурсов памяти устройства, это иногда может стать причиной нехватки памяти. Кроме того, все созданные объекты впоследствии должны быть удалены из памяти сборщиком мусора, что обременит ваше приложение дополнительными накладными расходами.

■ Не стоит останавливать свой выбор на XML DOM, если данные будут использоваться только в режиме чтения. DOM привносит дополнительные накладные расходы, но упрощает обратную запись данных из памяти на носитель. Если данные будут использоваться только в режиме чтения или вы планируете записывать их в другом формате, то потеряете в производительности, ничего не получая взамен.

В листинге 10.1 содержится пример кода, предназначенного для чтения и записи представленных выше XML-данных с использованием модели XML DOM.

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

using System;

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

//Демонстрирует сохранение и загрузку файлов с

//использованием объектной модели документов XML

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

public class SaveAndLoadXML_UseDOM {

//XML-дескрипторы, которые мы будем использовать в нашем документе

const string XML_ROOT_TAG = "AllMyData";

const string XML_USERINFO_TAG = "UserInfo";

const string XML_USERID_TAG = "UserID";

const string XML_NAMEINFO_TAG = "Name";

const string XML_FIRSTNAME_TAG = "FirstName";

const string XML_LASTNAME_TAG = "LastName";

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

//Загружает пользовательское состояние

//

// [in] fileName: Имя файла, используемого для сохранения данных

// [out] userId: Загруженный идентификатор пользователя

// [out] firstName: Загруженное имя пользователя

// [out] lastName: Загруженная фамилия пользователя

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

public static void XML_LoadUserInfo(string fileName, out int userId, out string firstName, out string lastName) {

//Начинаем с нулевых значений

userId = 0;

firstName = "";

lastName = "";

//Предполагаем, что данные еще не загружены

bool gotUserInfoData = false;

System.Xml.XmlDocument xmlDocument = new System.Xml.XmlDocument();

xmlDocument.Load(fileName);

//Получить корневой узел

System.Xml.XmlElement rootElement;

rootElement = (System.Xml.XmlElement)xmlDocument.ChildNodes[0];

//Убедиться в том, что корневой узел согласуется с ожидаемым текстом,

//ибо противное означает, что мы имеем дело с каким-то другим XML-файлом

if (rootElement.Name != XML_ROOT_TAG) {

throw new Exception("Тип корневого узла не совпадает с ожидаемым!");

}

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

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

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

foreach(System.Xml.XmlElement childOf_RootNode in rootElement.ChildNodes) {

//Если это узел UserInfo, то мы хотим просмотреть его содержимое

if (childOf_RootNode.Name == XML_USERINFO_TAG) {

gotUserInfoData = true; //Пользовательские данные найдены

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

//Загрузить каждый из подэлементов

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

foreach(System.Xml.XmlElement child_UserDataNode in childOf_RootNode.ChildNodes) {

//Идентификатор пользователя (UserID)

if (child_UserDataNode.Name == XML_USERID_TAG) {

userId = System.Convert.ToInt32(child_UserDataNode.InnerText);

}

//ФИО пользователя (UserName)

else if (child_UserDataNode.Name == XML_NAMEINFO_TAG) {

foreach(System.Xml.XmlElement child_Name in child_UserDataNode.ChildNodes) {

//Имя (FirstName)

if (child_Name.Name == XML_FIRSTNAME_TAG) {

firstName = child_Name.InnerText;

}

//Фамилия (LastName)

else if (child_Name.Name == XML_LASTNAME_TAG) {

lastName = child_Name.InnerText;

}

}//Конец цикла разбора UserName

}//Конец оператора if, осуществляющего проверку UserName

}//Конец цикла разбора UserInfo

}// Конец оператора if, осуществляющего проверку UserInfo

}//Конец цикла разбора корневого узла

if (gotUserInfoData == false) {

throw new Exception ("Данные пользователя в XML-документе не найдены!");

}

}

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

//Сохраняет пользовательское состояние

//

// [in] fileName: Имя файла, используемого для сохранения данных

// [in] userId:Идентификатор пользователя, которыймы хотим сохранить

// [in] firstName: Имя пользователя, которое мы хотим сохранить

// [in] lastName: Фамилия пользователя, которую мы хотим сохранить

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

public static void XML_SaveUserInfo(string fileName, int userId, string firstName, string lastName) {

System.Xml.XmlDocument xmlDocument = new System.Xml.XmlDocument();

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

//Добавить элемент документа высшего уровня

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

System.Xml.XmlElement rootNodeForDocument;

rootNodeForDocument = xmlDocument.CreateElement(XML_ROOT_TAG);

xmlDocument.AppendChild(rootNodeForDocument);

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

//Добавить данные в элемент UserInfo

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

System.Xml.XmlElement topNodeForUserData;

topNodeForUserData = xmlDocument.CreateElement(XML_USERINFO_TAG);

rootNodeForDocument.AppendChild(topNodeForUserData);

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

//Добавить значение UserID в наш документ

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

//Создать подузел для информации о пространстве имен

System.Xml.XmlElement subNodeForUserID;

subNodeForUserID = xmlDocument.CreateElement(XML_USERID_TAG);

subNodeForUserID.InnerText = System.Convert.ToString(userId);

//Присоединить подузел UserID к узлу высшего уровня

topNodeForUserData.AppendChild(subNodeForUserID);

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

//Добавить все значения NameInfo в наш документ

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

//Создать подузел для информации о пространстве имен

System.Xml.XmlElement subNodeForNameInfo;

subNodeForNameInfo = xmlDocument.CreateElement(XML_NAMEINFO_TAG);

//Имя (FirstName)

System.Xml.XmlElement subNodeFirstName;

subNodeFirstName = xmlDocument.CreateElement(XML_FIRSTNAME_TAG);

subNodeFirstName.InnerText = firstName;

//Фамилия (LastName)

System.Xml.XmlElement subNodeLastName;

subNodeLastName = xmlDocument.CreateElement(XML_LASTNAME_TAG);

subNodeLastName.InnerText = lastName;

//Присоединить подузлы имени и фамилии к родительскому

//узлу NameInfo

subNodeForNameInfo.AppendChild(subNodeFirstName);

subNodeForNameInfo.AppendChild(subNodeLastName);

//Присоединить подузел NameInfo (вместе с его дочерними узлами)

//к узлу высшего уровня

topNodeForUserData.AppendChild(subNodeForNameInfo);

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

//Сохранить документ

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

try {

xmlDocument.Save(fileName);

}

catch (System.Exception ex) {

System.Windows.Forms.MessageBox.Show("Ошибка при сохранении XML-документа - " + ex.Message);

}

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

} //Конец класса

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

private void button1_Click{object sender, System.EventArgs e) {

const string FILENAME = "TestFileName.XML";

//Сохранить, используя XML DOM

SaveAndLoadXML UseDOM.XML_SaveUserInfo(FILENAME, 14, "Ivo", "Salmre");

//Сохранить, используя объект однонаправленной записи XMLWriter

//SaveAndLoadXML_UseReaderWriter.XML SaveUserInfo(FILENAME,

// 18, "Ivo", "Salmre");

int userID;

string firstName;

string lastName;

//Загрузить, используя XML DOM

SaveAndLoadXML_UseDOM.XML_LoadUserInfo(FILENAME, out userID, out firstName, out lastName);

//Загрузить, используя объект однонаправленного чтения XMLReader

//SaveAndLoadXML_UseReaderWriter.XMILoadUserInfo(FILENAME,

// out userID, out firstName, out lastName);

System.Windows.Forms.MessageBox.Show('Готово!" + userID.ToString() + ", " + lastName + ", " + firstName);

}

Модель однонаправленного чтения-записи XML-данных

В отличие от подхода XML DOM, обеспечивающего произвольный доступ к XML-данным и интенсивно использующего информацию о состоянии, объекты XMLReader и XMLWriter обеспечивают лишь возможности однонаправленного доступа. Они поддерживают минимальный объем информации о состоянии, которого достаточно для чтения и записи XML-данных, и не пытаются создавать в памяти дерево XML-данных или работать с ним. В этом случае говорят о моделях однонаправленного доступа, поскольку они поддерживают программный курсор, указывающий на текущую позицию в XML-файле, и позволяют работать только с находящимися в этом месте данными; курсор может перемещаться только в прямом направлении, но не в обратном. Объект XMLReader предлагает много возможностей, но в приложениях используется в основном для прохождения узлов XML-документа. При чтении XML-документа XMLReader каждый раз считывает только один узел и связанные с ним атрибуты; это напоминает чтение обычного файла по одной строке за один раз. Когда разработчик заканчивает просмотр узла и его атрибутов, он отдает объекту XMLReader команду перейти к следующему элементу, в результате чего XMLReader сбрасывает содержащуюся в нем информацию, которая относится к содержимому текущего узла. Однонаправленность доступа является необходимой платой за достижение наилучшей производительности и снижение накладных расходов.

Следует отметить, что XML DOM строится поверх классов XMLReader и XMLWriter. XML DOM использует XMLReader для синтаксического анализа XML-документа и создает в памяти дерево на основе считанных данных. При записи XML-документа DOM итеративно проходит узлы находящегося в памяти дерева и выводит их через XMLWriter в поток или файл. Как следствие, все, что можно сделать с использованием XML DOM, можно сделать, используя XMLReader и XMLWriter. XML DOM делает все возможное для того, чтобы с наибольшей эффективностью выполнять функции универсального XML-анализатора с произвольным доступом, максимально использующего информацию о состоянии.

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

Чем 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-данных

■ Такие модели однонаправленного чтения данных, как XMLReader, обеспечивают наиболее быстрые и надежные способы чтения XML-данных даже в случае гигантских файлов. Минимальным требованием является поддержка каркасом информации о состоянии в процессе выполнения синтаксического анализа XML-документа. Объем этой информации не растет с увеличением размера анализируемого XML-документа, и поэтому ограничения на размеры XML-документов, которые вы хотите просматривать для извлечения необходимых данных, практически отсутствуют. Единственным долговременным генерируемым состоянием являются объекты, которые создаются вашим приложением, исходя из нужд анализа.

■ Такие модели однонаправленной записи данных, как модель XMLWriter, обеспечивают наиболее быстрые и простые способы записи корректно сформированных XML-документов. Коды для записи XML-данных при помощи объекта XMLWriter работают быстро и отличаются простотой. Даже в случае сложных XML-документов ваш код, реализующий навигацию между вашими собственными внутренними структурами данных, скорее всего, окажется более сложным, чем код, с помощью которого осуществляется запись XML-данных из памяти. Использовать для вывода XML-дескрипторов объект XMLWriter для гораздо проще, чем самостоятельно написать предназначенный для этого пользовательский код. Существует довольно мало причин, если таковые вообще находятся, по которым следовало бы поступать иначе.

■ Модели однонаправленной обработки прекрасно подходят для извлечения определенных данных или записи коротких потоков XML-данных. Если вас интересует извлечение из XML-документа только определенных данных и вам известно, где именно в иерархии данных файла они находятся, то использование объекта XMLReader и собственного конечного автомата для перехода к нужным данным не вызывает особых затруднений. Аналогичным образом, если вам заранее известно, каким должен быть формат XML-данных, выводимых для записи, работа с объектом XMLWriter не будет для вас сложной.

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

■ Модели однонаправленной обработки данных не поддерживают произвольный доступ к элементам документа. Вам дается только один "выстрел", чтобы успеть сделать что-либо с данными по мере их чтения. Если ваш алгоритм нуждается в динамическом перекрестном использовании данных или внесении взаимосвязанных изменений в данные, относящиеся к различным частям XML-документа, то для этого вам придется самостоятельно написать довольно сложный код, интенсивно использующий информацию о состоянии. Поскольку модель XML DOM поддерживает хранящееся в памяти дерево документа, она позволяет легко совершать обход этого дерева для поиска нужных узлов и внесения необходимых изменений.

■ Модели однонаправленной обработки данных требуют выполнения значительного объема работы для реконструкции всей структуры дерева. Если вы хотите вывести для записи тот же самый документ, который был считан, то вам придется продублировать значительную часть той функциональности XML DOM, при помощи которой это можно было бы сделать. Объекты XMLReader отлично приспособлены для извлечения определенных порций данных. Объекты XMLWriter отлично приспособлены для быстрого вывода вашим приложением определенных элементов XML-данных. Если же вам необходимо считать XML-документ и внести в него значительные изменения перед тем, как записать его обратно, то ваш друг — DOM.

■ Модели однонаправленной обработки требуют использования более сложных программных моделей, реализующих навигацию и операции поиска в сложных документах. Написание кода универсального синтаксического анализатора, который работал бы с произвольными иерархиями XML, может вызывать большие трудности. Чтобы найти искомую информацию, вам придется использовать очень сложное состояние, позволяющее определять, в каком узле дерева документа вы находитесь. Так, если вы осуществляете поиск дескриптора <Name>, находящегося внутри определенного дескриптора <Customer>, и в вашем XML-документе имеются дескрипторы <Name>, соответствующие объектам <Customer>, <Employee> и <Vendor>, которые могут присутствовать в XML-дереве на иерархических уровнях различной глубины, то для того, чтобы иметь возможность различать эти случаи и тем caмым гарантировать, что вы получаете корректную информацию, вам придется написать код, отслеживающий, в каком месте документа в настоящее время осуществляется просмотр. Если документ следует единственной корректно- определенной схеме, то, возможно, это не так уж плохо. С другой стороны, если документ может быть подготовлен с использованием одной из нескольких возможных схем, то задача становится алгоритмически сложной. В случае особо сложных документов следует рассмотреть вариант выполнения обработки на сервере, ибо там предоставляются не только более мощные вычислительные возможности, но и более мощные API-интерфейсы, предназначенные для проведения поиска в XML-документах (например, XPATH, поддерживающий запросы данных документа).

Ниже приведен простой код, предназначенный для чтения и записи представленных ранее данных с использованием модели однонаправленной обработки XML- документов с помощью объектов XMLReader и XMLWriter. Особый интерес для вас может представлять конечный автомат, используемый в объекте XMLReader для отслеживания текущего места в документе; заметьте, что даже для столь простого XML-документа, как наш, этот код вовсе не тривиален. В противоположность этому код, предназначенный для вывода XML-документов при помощи объекта XMLWriter, отличается простотой.

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

using System;

public class SaveAndLoadXML UseReaderWriter {

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

const string XML_ROOT_TAG = "AllMyData";

const string XML_USERINFO_TAG = "UserInfo";

const string XMI_USERID_TAG = "UserID";

const string XML_NAMEINFO_TAG = "Name";

const string XML_FIRSTNAME_TAG = "FirstName";

const string XML_LASTNAME TAG = "LastName";

//Набор состояний, отслеживаемых по мере чтения данных

private enum ReadLocation {

inAllMyData,

inUserInfo,

inUserID,

inName,

inFirstName,

inLastName,

}

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

//Сохраняет пользовательское состояние

//

// [in] fileName: Имя файла, используемого для сохранения данных

// [in] userId: Идентификатор пользователя, который мы хотим сохранить

// [in] firstName: Имя пользователя, которое мы хотим сохранить

// [in] lastName: Фамилия пользователя, которую мы хотим сохранить

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

public static void XML_SaveUserInfo(string fileName, int userId,string firstName, string lastName) {

System.Xml.XmlTextWriter xmlTextWriter;

xmlTextWriter =new System.Xml.XmlTextWriter(fileName, System.Text.Encoding.Default);

//Записать содержимое документа!

//<Root>

xmlTextWriter.WriteStartElement(XML_ROOT_TAG);

//<Root>

xmlTextWriter.WriteStartElement(XML_USERINFO_TAG);

//<Root><UserID>

//<Root><UserInfo>

xmlTextWriter.WriteStartElement(XML_NAMEINFO_TAG);

//<Root><UserInfo><Name>

xmlTextWriter.WriteStartElement(XML_FIRSTNAME_TAG);

//<Root><UserInfo><Name><FirstName>

xmlTextWriter.WriteString(firstName); //Запись значения

xmlTextWriter.WriteEndElement(); //Закрыть дескриптор имени

//<Root><UserInfo><Name>

xmlTextWriter.WriteStartElement(XML_LASTNAME_TAG);

//<Root><UserInfo><Name><LastName>

xmlTextWriter.WriteString(lastName); //Запись значения

xmlTextWriter.WriteEndElement(); //Закрыть дескриптор фамилии

//<Root><UserInfo><Name>

xmlTextWriter.WriteEndElement(); //Закрыть дескриптор ФИО

//<Root><UserInfo>

//<Root><UserInfo>

xmlTextWriter.WriteStartElement(XML_USERID_TAG);

//<Root><UserInfo><UserID>

//Запись значения

xmlTextWriter.WriteString(userId.ToString());

xmlTextWriter.WriteEndElement();

//Закрыть дескриптор UserID

//<Root><Userlnfo>

xmlTextWriter.WriteEndElement(); //Закрыть дескриптор UserInfo

//<Root>

xmlTextWriter.WriteEndElement(); //Закрыть дескриптор документа

//

xmlTextWriter.Close();

}

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

//Загружает пользовательское состояние

//

// [in] fileName: Имя файла, используемого для сохранения данных

// [out] userId: Загруженный идентификатор пользователя

// [out] firstName: Загруженное имя пользователя

// [out] lastName: Загруженная фамилия пользователя

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

public static void XML_LoadUserInfo(string fileName, out int userId, out string firstName,out string lastName) {

ReadLocation currentReadLocation;

//Начинаем с нулевых значений

userId = 0;

firstName = "";

lastName = "";

System.Xml.XmlTextReader xmlReader = new System.Xml.XmlTextReader(fileName);

xmlReader.WhitespaceHandling = System.Xml.WhitespaceHandling.None;

bool readSuccess;

readSuccess = xmlReader.Read();

if (readSuccess == false) {

throw new System.Exception("Отсутствуют XML-данные для чтения!");

}

//Убедиться в том, что мы распознали корневой дескриптор

if (xmlReader.Name != XML_ROOT_TAG) {

throw new System.Exception("Корневой дескриптор отличается от ожидаемого!");

}

//Отметить текущее местоположение в документе

currentReadLocation = ReadLocation.inAllMyData;

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

//Цикл прохождения документа и чтение необходимых данных

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

while (readSuccess) {

switch (xmlReader.NodeType) {

//Вызывается при входе в новый элемент

case System.Xml.XmlNodeType.Element: {

string nodeName = xmlReader.Name;

LoadHelper_NewElementEncountered(nodeName, ref currentReadLocation);

break;

}

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

//Здесь мы можем извлечь некоторый фактический текст и

//получить данные, которые пытаемся загрузить

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

case System.Xml.XmlNodeType.Text: {

switch (currentReadLocation) {

case ReadLocation.inFirstName: {

firstName = xmlReader.Value;

break;

}

case ReadLocation.inLastName: {

lastName = xmlReader.Value;

break;

}

case ReadLocation.inUserID: {

userId = System.Convert.ToInt32(xmlReader.Value);

break;

}

}

break;

}

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

//Вызывается, когда встречается конец

//элемента

//

//Мы можем захотеть переключить состояние в зависимости от вида

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

//вернуться назад к его предку

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

case System.Xml.XmlNodeType.EndElement: {

bool continueParsing;

continueParsing = LoadHelper_EndElementEncountered(ref currentReadLocation);

if (continueParsing ==false) {

goto finished_reading_wanted_data;

}

break;

}

default: {

//He страшно, если имеются XML-узлы других типов, но

//в нашем примере работы с XML-документом мы должны

//оповестить об этом факте...

System.Windows.Forms.MessageBox.Show("Встретился непредвиденный XML-тип " + xmlReader.Name);

break;

}

} //Конец оператора Case, используемого для определения текущего

//типа XML-элeмeнтa, oбpaбaтывaeмoгo анализатором

//Перейти к следующему узлу

readSuccess = xmlReader.Read();

}

//Если мы оказались в этом месте программы, не покинув

//XML-дескриптора UserInfo, то с XML-данными, которые

//мы считываем, что-то не так

throw new Exception("He найден элемент UserInfo в XML-документе!");

finished_reading_wanted_data:

//Закрыть файл, поскольку работа с ним закончена!

xmlReader.Close();

}

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

//Вспомогательный код, ответственный за принятие решения

//относительно того, в какое состояние необходимо перейти,

//когда встречается закрывающий дескриптор

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

private static bool LoadHelper_EndElementEncountered(ref ReadLocation currentReadLocation) {

switch (currentReadLocation) {

//Если мы покидаем узел Name, то должны вернуться

//обратно в узел UserInfo

case ReadLocation.inName: {

currentReadLocation = ReadLocation.inUserInfo;

break;

}

//Если мы покидаем узел FirstName, то должны вернуться

//обратно в узел Name

case ReadLocation.inFirstName: {

currentReadLocation = ReadLocation.inName;

break;

}

//Если мы покидаем узел LastName, то должны вернуться

//обратно в узел Name

case ReadLocation.inLastName: {

currentReadLocation = ReadLocation.inName;

break;

}

//Если мы покидаем узел UserID, то должны вернуться

//обратно в узел UserInfo

case ReadLocation.inUserID: {

currentReadLocation = ReadLocation.inUserInfo;

break;

}

//Если мы покидаем узел UserInfo, то мы только что

//закончили чтение данных в узлах UserID, FirstName

//и LastName.

//

//Можно выйти из цикла, поскольку у нас уже есть вся

//информация, которую мы хотели получить!

case ReadLocation.inUserInfo: {

return false; //Анализ должен быть прекращен

}

}

return true; //Продолжить анализ

}

private static void LoadHelper_NewElementEncountered(string nodeName,ref ReadLocation currentReadLocation) {

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

//Мы вошли в новый элемент!

//

//B какое состояние переход возможен, зависит от того, в

//каком состоянии мы находимся в данный момент

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

switch (currentReadLocation) {

//Если мы находимся в узле AllMyData, то переход возможен

//в узлы, которые указаны ниже

case (ReadLocation.inAllMyData): {

if (nodeName == XMI_USERINFO_TAG) {

currentReadLocation = ReadLocation.inUserInfo;

}

break;

}

//Если мы находимся в узле UserInfo, то переход возможен

//в узлы, которые указаны ниже

case (ReadLocation.inUserInfo): {

if (nodeName == XML_USERID_TAG) {

currentReadLocation = ReadLocation.inUserID;

} else if (nodeName == XML_NAMEINFO_TAG) {

currentReadLocation = ReadLocation.inName;

}

break;

}

//Если мы находимся в узле Name, то переход возможен

//в узлы, которые указаны ниже

case (ReadLocation.inName): {

if (nodeName == XML_FIRSTNAME_TAG) {

currentReadLocation = ReadLocation.inFirstName;

} else if (nodeName == XML_LASTNAME_TAG) {

currentReadLocation = ReadLocation.inLastName;

}

break;

}

}

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

} //Конец класса

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

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

Лучше всего обрабатывать XML-данные на сервере еще до того, как они поступят на устройство. Если приложение ориентировано на использование данных, прошедших предварительную сортировку, фильтрацию и преобразования, то выполнение этой работы на сервере, прежде чем данные попадут на устройство, может принести вам реальные дивиденды в плане производительности. Эта задача заслуживает того, чтобы вы направили на нее часть своей творческой энергии.

Избегайте выполнения сложных преобразований данных на устройстве

Во многих случаях XML-данные удобно преобразовать к другому виду, облегчающему их непосредственный просмотр пользователем. В качестве простого примера можно привести заполнение элементов управления ListBox или ListView данными из XML-документа. Более сложным примером является генерация HTML документов на основе XML-данных. В каждом из этих случаев XML-данные подвергаются определенному преобразованию, позволяющему представить их в удобочитаемом виде. Преобразования часто имеют сложную природу и требуют больших затрат процессорного времени. Старайтесь находить способы, позволяющие выполнять как можно больший объем такой работы на сервере еще до того, как данные попадут на устройство. Чем больший объем трудоемких преобразований будет выполнен на сервере, тем меньшая нагрузка будет возлагаться на устройство

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

Избегайте выполнения сложного поиска данных на устройстве

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

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

Пересылка необязательной информации на устройство занимает дополнительное время как при передаче данных, так и при выполнении синтаксического анализа данных на устройстве. Если вы имеете дело с 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; руководствуйтесь этими же советами и тогда, когда возникает проблема выбора зависящей от состояния или требовательной к ресурсам библиотеки. Вы можете использовать такую библиотеку, но всегда оценивайте, с какими дополнительными расходами это будет сопряжено, и проводите соответствующие измерения.

Резюме

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

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

При работе с XML очень важно учитывать объем обрабатываемых данных и специфику их назначения. В случае небольших ХМL-документов (например, размером 20 Кбайт) часто оказывается удобным подход, основанный на модели XML DOM, в котором предполагается загрузка в память всего XML-дерева. Модель XML DOM обеспечивает произвольный доступ к данным документа и упрощает обратный вывод документа для его записи на накопитель или в поток. Существенным недостатком модели XML DOM является загрузка в память одновременная всех XML-данных, что делает эту модель в высшей степени зависимой от состояния. При работе с крупными документами этот недостаток может иметь критическое значение.

Разумной низкоуровневой альтернативой при работе с крупными XML-документами являются XML-библиотеки функций, предназначенных для однонаправленной обработки данных. В .NET Compact Framework предлагаются классы XMLReader и XMLWRiter, тогда как в других средах выполнения для однонаправленного доступа к XML-данным могут предоставляться средства модели SAX. Указанный подход позволяет добиться максимально возможной производительности, поскольку соответствующие средства зависят от состояния в меньшей степени и поэтому не нуждаются в загрузке в память дерева данных, представляющего документ. В случае сложных документов осложняется и работа с использованием объектов XMLReader; для отслеживания текущей позиции в иерархии документа может оказаться полезным подход, основанный на использовании конечных автоматов. Объекты XMLWriter упрощают вывод XML-данных с целью их записи в файл. При работе с большими объемами XML- данных на мобильных устройствах использование модели однонаправленной обработки данных может оказаться единственно разумным подходом.

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

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

ГЛАВА 11

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

М-р Брэддок: "Скажи-ка мне, ради чего тогда надо было так тяжко трудиться последние четыре года?"

Бенджамин Брэддок: "Ты меня достал…"

"Выпускник" (The Graduate) (1967)

Элен Робинсон: "Я не хочу, чтобы ты брался за что- либо без четко составленного плана".

"Выпускник" (1967)

Введение

Несомненно, "Выпускник" — один из лучших фильмов всех времен и народов, но какое это имеет отношение к разработке пользовательских интерфейсов мобильных приложений?

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

Наиболее бросающимся в глаза аспектом производительности приложения является пользовательский интерфейс. То, насколько быстро приложение реагирует на команды пользователя, и с какой скоростью выполняются задачи, требующие перерисовки экрана, оказывает огромнейшее влияние на пользовательское восприятие приложения. Замедленное выполнение, мерцание пользовательского интерфейса и любые остановки при выполнении тех операций, которые должны были бы осуществляться без какой-либо задержки, формируют у пользователя отрицательное отношение к вашему приложению. Поскольку мобильными устройствами люди часто пользуются, держа их в руках, и поэтому относятся к ним, как к простым механическим инструментам, от них ожидается еще большая способность к отклику, чем от настольных компьютеров; ни с чем похожим на мерцание циферблата наручных часов, периодическое исчезновение из поля зрения карты города или страниц записной книжки в обычных условиях сталкиваться не приходится. Многие разработчики беззаботно погружают приложение в неэффективный интерфейс, в результате чего создается впечатление, что само по себе неплохое приложение работает очень медленно. Добиться удовлетворительной производительности пользовательского интерфейса на мобильных устройствах вполне возможно, но это требует большого внимания к деталям. Что необходимо — так это стратегия, которая могла бы гарантировать, что будут решаться именно те проблемы, от которых зависит быстродействие пользовательского интерфейса и комфортность работы с приложением.

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

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

Можно выделить следующие аспекты вашей работы, от которых зависит эффективное функционирование создаваемых вами пользовательских интерфейсов:

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

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

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

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

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

■ Какие стандартные или пользовательские элементы управления следует применять для отображения данных и организации взаимодействия с пользователем?

■ Имеет ли смысл создать собственные нестандартные элементы управления, или же лучше расширить свойства уже существующих элементов управления с тем, чтобы они соответствовали вашим конкретным нуждам?

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

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

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

■ Существует ли необходимость в форсировании немедленного обновления или перерисовки элементов управления ради поддержания в пользователе уверенности в том, что его команды воспринимаются и исполняются, если при этом страдает общая производительность приложения?

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

Ниже приведены некоторые из основных стратегий проектирования, ориентированных на создание высокопроизводительных пользовательских интерфейсов.

Использование встроенных средств повышения производительности

Если среда выполнения мобильного приложения, которую вы используете, предлагает для создания высокопроизводительных кодов пользовательских интерфейсов специальные возможности, вы обязательно должны ими воспользоваться. Более того, вы должны очень внимательно изучить перечень событий, свойств и методов, относящихся к используемым вами элементам управления, и попытаться найти среди них те, которые особенно подходят для повышения производительности интерфейса. Лучшим способом узнать как можно больше об этих возможностях каркаса пользовательского интерфейса является исследование членов его классов окон, форм и элементов управления. Кроме того, полезно внимательно изучить перегруженные версии методов, предназначенных для решения наиболее часто возникающих задач программирования, и выяснить, не найдутся ли методы, позволяющие выполнять операции в пакетном режиме вместо того, чтобы повторно вызывать один и тот же метод в цикле. Как несложно догадаться, выполнение операций в пакетном режиме обычно происходит гораздо быстрее. Для такого исследования вам, как правило, потребуется каких- нибудь несколько минут, но вы сами удивитесь, как много нового для себя вы сможетe обнаружить; очень часто плохое функционирование кода пользовательского интерфейса объясняется просто тем, что для достижения тех или иных целей используются далеко не самые эффективные свойства или методы, или тем, что вызываются методы, приостанавливающие операции с пользовательским интерфейсом на время выполнения его обновлений.

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

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

• .BeginUpdate()/EndUpdate(). Оба эти метода присутствуют как в TreeView, так и в ListView, и предназначены для приостановки и возобновления автоматической перерисовки элемента управления на экране. Вызов метода BeginUpdate() указывает на то, что элемент управления не должен автоматически перерисовываться всякий раз, когда в него добавляются или из него удаляются элементы данных, тогда как вызов метода EndUpdate() восстанавливает режим автоматической перерисовки элемента управления. Выполнение необязательных операций перерисовки экрана может отрицательно сказываться на производительности приложения. Если в процессе работы вашего приложения возникает необходимость в помещении в элемент управления или исключении из него многочисленных данных, то соответствующий участок кода целесообразно окружить парой вызовов BeginUpdate() и EndUpdate().

• .AddRange(). Для коллекции узлов элемента управления TreeView предусмотрен метод AddRange() (например, treeView1.Nodes.AddRange()), обеспечивающий групповое добавление узлов в TreeView. Такой "пакетный" режим обработки является гораздо более предпочтительным по сравнению с простым итеративным добавлением каждого узла по отдельности.

Используя эти эффективные встроенные механизмы, вы можете добиться существенного выигрыша в отношении как производительности, так и бесперебойности работы пользовательского интерфейса. Если с каким-либо элементом управления приходится работать особенно часто, то стоит просмотреть список его свойств и методов, чтобы выяснить, не найдутся ли среди них такие, использование которых позволит увеличить производительность.

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

Приведенный в листинге 11.1 пример предназначен для количественной оценки эффективности трех различных методик работы с элементами управления TreeView среды .NET Compact Framework. Используя Visual Studio .NET, создайте новый проект C# для мобильного приложения, выбрав в качестве целевой платформы устройство Pocket PC. Убедившись в том, что вы находитесь в режиме конструктора, добавьте в пустую форму элемент управления TreeView и пять кнопок, как показано на рис. 11.1.

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

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

Представленный в листинге 11.1 код состоит из набора обработчиков событий для различных кнопок, которые имеются на вашей форме. Фактические имена используемых функций будут происходить от имен, присвоенных соответствующим кнопкам. В своем коде я использовал для кнопок следующие имена: UnOptimizedFill, UnOptimizedClear, UseBeginEndUpdateForFill, UseBeginEndUpdateForClear и FillArrayBeforeAttachingToTree. Если вы используете заданные по умолчанию имена, которые предложит вам Visual Studio .NET, то у вас будут кнопки с именами button1, button2, button3, button4 и button5 и функции обработчиков событий с другими именами, которые надо будет соответственно изменить.

Рис. 11.1. Конструктор форм среды Visual Studio .NET с размещенными на форме элементами управления TreeView и Button

В любом случае, проще всего сначала создать и связать с кнопками пустые обработчики событий, выполняя для этого двойные щелчки на каждой из кнопок в конструкторе форм Visual Studio .NET, а затем вставить приведенный в листинге код обработчиков в созданные для вас определения функций.

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

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

//Примечание #1: В этом примере используется класс PerformanceSampling,

// определенный ранее в данной книге. Убедитесь в том, что

// вы включили этот класс в свой проект.

//Примечание #2: Этот код необходимо включить в класс Form, содержащий

// элемент управления TreeView и кнопки Button, к которым

// подключены приведенные ниже функции xxx_Click.

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

//Количество элементов, которые необходимо поместить в элемент

//управления TreeView

const int NUMBER_ITEMS = 800;

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

//Код для кнопки "Fill: Baseline"

//

//Использование неоптимизированного подхода для заполнения данными элемента

//управления TreeView

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

private void UnOptimizedFill_Click(object sender, System.EventArgs e) {

//Очистить массив для создания одинаковых условий тестирования

if (treeView1.Nodes.Count > 0) {

treeView1.BeginUpdate();

treeView1.Nodes.Clear();

treeView1.EndUpdate();

treeView1.Update();

}

//Для повышения корректности тестирования предварительно выполнить

//операцию сборки мусора

System.GC.Collect();

//Запустить таймер

PerformanceSampling.StartSample(0, "TreeViewPopulate");

//Заполнить данными элемент управления TreeView

for (int i = 0; i < NUMBER_ITEMS; i++) {

treeView1.Nodes.Add("TreeItem" + i.ToString());

}

//Остановить таймер и отобразить результат

PerformanceSampling.StopSample(0);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(0));

}

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

//Код для кнопки "Clear: Baseline"

//

//Использование неоптимизированного подхода для заполнения данными элемента

//управления TreeView

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

private void UnOptimizedClear_Click(object sender, System.EventArgs e) {

//Для повышения корректности тестирования предварительно выполнить

//операцию сборки мусора

System.GC.Collect();

//Запустить таймер

PerformanceSampling.StartSample(1, "TreeViewClear");

treeView1.Nodes.Clear();

PerformanceSampling.StopSample(1);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(1));

}

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

//Код для кнопки "Fill: BeginUpdate"

//

//Подход, в котором используется метод BeginUpdate()

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

private void UseBeginEndUpdateForFill_Click(object sender, System.EventArgs e) {

//Очистить массив для создания одинаковых условий тестирования

if (treeViewl.Nodes.Count > 0) {

treeView1.BeginUpdate();

treeView1.Nodes.Clear();

treeView1.EndUpdate();

treeView1.Update();

}

//Для повышения корректности тестирования предварительно выполнить

//операцию сборки мусора

System.GC.Collect();

//Запустить таймер

PerformanceSampling.StartSample(2, "Populate - Use BeginUpdate");

//Заполнить данными элемент управления

TreeView treeView1.BeginUpdate();

for (int i = 0; i < NUMBER_ITEMS; i++) {

treeView1.Nodes.Add("TreeItem" + i.ToString());

}

treeView1.EndUpdate();

//Остановить таймер и отобразить результат

PerformanceSampling.StopSample(2);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(2));

}

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

//Код для кнопки "Clear: BeginUpdate"

//Подход, в котором используется метод BeginUpdate()

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

private void UseBeginEndUpdateForClear_Click(object sender, System.EventArgs e) {

//Для повышения корректности тестирования предварительно выполнить

//операцию сборки мусора

System.GC.Collect();

//Запустить таймер

PerformanceSampling.StartSample(3, "Clear - Use BeginUpdate");

treeView1.BeginUpdate();

treeView1.Nodes.Clear();

treeView1.EndUpdate();

//Остановить таймер и отобразить результат

PerformanceSampling.StopSample(3);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(3));

}

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

//Код для кнопки "Fill: Use Array"

//

//Подход, в котором используется массив

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

private void FillArrayBeforeAttachingToTree_Click(object sender, System.EventArgs e) {

//Очистить массив для создания одинаковых условий тестирования

if (treeView1.Nodes.Count > 0) {

treeView1.BeginUpdate();

treeView1.Nodes.Clear();

treeView1.EndUpdate();

treeView1.Update();

}

//Для повышения корректности тестирования предварительно выполнить

//операцию сборки мусора

System.GC.Collect();

//Запустить таймер

PerformanceSampling.StartSample(4, "Populate - Use Array");

//Распределить память для нашего массива узлов дерева

System.Windows.Forms.TreeNode [] newTreeNodes = new System.Windows.Forms.TreeNode[NUMBER_ITEMS];

//Заполнить массив

for(int i = 0; i < NUMBER_ITEMS; i++) {

newTreeNodes[i] = newSystem.Windows.Forms.TreeNode("TreeItem" + i.ToString());

}

//Связать массив с элементом управления

TreeView treeView1.BeginUpdate();

treeView1.Nodes.AddRange(newTreeNodes);

treeView1.EndUpdate();

//Остановить таймер и отобразить результат

PerformanceSampling.StopSample(4);

System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(4));

}

Результаты, полученные с использованием различных методик добавления данных в элемент управления TreeView и их исключения из него, приведены в таблицах 11.1 и 11.2.

Таблица 11.1. Физическое устройство Pocket PC: добавление 800 элементов данных (время в секундах)

Номер теста

Не оптимизированный подход

Использование методов BeginUpdate()/EndUpdate()

Использование массива

1

40,785

12,484

10,388

2

40,533

12,322

10,419

3

40,878

13,343

11,686

Среднее

40,732

12,716

10,831

Экономия времени по сравнению с базовым значением

Базовое значение (0%)

68,78%

73,41%

Из табл. 11.1 видно, что экономия времени, достигаемая за счет окружения кода, предназначенного для добавления в элемент управления TreeView и исключения из него данных, вызовами методов BeginUpdate() и EndUpdate(), составила примерно две трети (68,78%). Наряду с этим, благодаря тому, что мерцание элементов управления вследствие их обновления происходит реже, повышается и привлекательность интерфейса, оцениваемая с позиций конечного пользователя. Использование метода AddRange() (столбец "Использование массива") для заполнения данными элемента управления TreeView позволило уменьшить накладные расходы еще на 5%; это улучшение также является ощутимым.

Было довольно-таки неожиданно обнаружить, что использование пары вызовов BeginUpdate() и EndUpdate() привело не только к значительному увеличению скорости добавления данных в элемент управления TreeView, но и оказало достаточно сильное влияние на скорость их удаления. Результаты, полученные с использованием двух различных подходов для удаления данных из элемента управления TreeView, сравниваются в табл. 11.2.

Таблица 11.2. Очистка 800 элементов данных (время в секундах)

Номер теста

Не оптимизированный подход

Использование методов BeginUpdate()/EndUpdate()

1

18,791

8,656

2

15,910

8,964

3

16,821

8,516

Среднее

17,174

8,712

Экономия времени по сравнению с базовым значением

Базовое значение (0 %)

49,27 %

Как видно из табл. 11.2, одного лишь окружения кода, предназначенного для удаления данных из элемента управления TreeView, вызовами методов BeginUpdate() и EndUpdate() оказалось достаточным для того, чтобы достигнуть 50%-ной экономии времени.

На основании полученных результатов можно сделать следующие выводы:

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

2. Было бы неправильно предполагать, будто такие концептуально простые операции, как, например, очистка элемента управления от данных, будут сами по себе выполняться быстро и поэтому не следует прилагать никаких усилий к их ускорению.

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

Выполняйте тесты с использованием реальных объемов данных, которые будут отображаться в вашем приложении

Обычная ошибка, которую допускают при написании кодов пользовательских интерфейсов. заключается в том, что в процессе проектирования и тестирования интерфейса используются данные меньшего объема, чем тот, с которым приходится сталкиваться при развертывании мобильного приложения. Алгоритм, который прекрасно справляется с извлечением из базы данных 20 элементов данных и их передачей пользовательскому интерфейсу, вовсе не обязательно сделает хорошо то же самое для 200 элементов данных. Если вы тестируете интерфейс, используя лишь небольшие наборы данных, то тем самым оставляете открытыми двери для множества неприятных сюрпризов, ожидающих вас на последующих стадиях разработки или при развертывании приложения, когда настанет черед работать с реальными объемами данных. Гораздо лучше выявлять все проблемы производительности еще на ранней стадии, когда для их преодоления могут быть найдены наиболее конструктивные решения; вносить изменения в проект впоследствии всегда труднее, это может нарушать стабильность работы приложения и почти всегда приводит к менее удовлетворительным результатам.

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

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

Отсроченный выбор — это благо! Откладывайте, откладывайте, откладывайте…

Многие приложения служат для того, чтобы предоставить пользователям возможность исследовать большие объемы динамических данных в сжатом виде. Эти данные могут храниться в локальном файле или базе данных или же динамически извлекаться из сети по мере необходимости.

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

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

■ Способ 1. Начните с просмотра данных, сгруппированных по районам (Neighbourhoods), а затем перейдите к просмотру данных, сгруппированных по ценам, чтобы определить, информация о домах какой стоимости должна быть отображена. Этому способу навигации соответствуют следующие переходы по иерархическим узлам TreeView: Neighbourhoods→Price→ListOfUnits.

■ Способ 2. Начните с группировки по ценам (Price), а затем перейдите к просмотру данных, сгруппированных по типам, и, наконец, по районам, в результате чего будет отображен соответствующий список домов. Этому способу навигации соответствуют следующие переходы по иерархическим узлам TreeView: Price→HouseType→Neighbourhood→ListOfUnits.

■ Способ 3. Начните с типов домов (HouseType), а затем последовательно перейдите к просмотру данных, сгруппированных по интервалам цен и районам. Этому способу навигации соответствуют следующие переходы по иерархическим узлам TreeView: HouseType→Price→Neighbourhood→ListOfUnits.

На рис. 11.2 показано, как может выглядеть навигация по узлам иерархии TreeView. Имеется три узла верхнего уровня: Neighbourhood, Price и House- Type У каждого родительского узла имеются подузлы, по которым пользователи могут переходить вглубь иерархии, получая, в конечном счете, множество объектов недвижимости, информацию о которых они хотят просмотреть.

Несмотря на всю полезность метафоры дерева для отбора домов на основании иерархических категорий, при ее использовании могут возникать проблемы, обусловленные заметным ростом количества узлов дерева даже при средних объемах данных. Простая иерархия, включающая 10 узлов типа Neighbourhood, каждый из которых включает по 4 узла типа HouseType, включающие каждый по 4 узла типа Price, каждый из которых, в свою очередь, включает по 6 узлов типа House. в сумме дает для нашего дерева 960 концевых узлов, или листьев.

Это число следовало бы дополнительно умножить на количество способов навигации, которые мы хотим использовать:

960 для навигации по схеме Neighbourhoods→HouseType→Price→ListOfUnits

960 для навигации по схеме Price→Neighbourhoods→HouseType→ListOfUnits

960 для навигации по схеме HouseTypeOPrice→Neighbourhood→ListOfUnits

Рис. 11.2. Простой пример того, как может выглядеть иерархия узлов элемента управления TreeView для задачи поиска объектов недвижимости

Если мы решим заранее заполнить данными элемент управления TreeView, не дожидаясь, какую навигационную схему изберет пользователь, то нам, в конечном счете, придется задействовать огромное количество узлов дерева, большинство из которых не будут посещены пользователем во время сеансов работы с приложением. Создание таких членов TreeView занимает много времени, а каждый из отдельных узлов TreeView сам по себе потребляет системные ресурсы. Несомненно, хранение тысяч элементарных узлов иерархии TreeView приведет к ухудшению производительности приложения. Если исходить из того, что не все из описанных отдельных узлов будут посещены пользователем, то можно значительно повысить производительность, используя более разумный подход. Чего нам хотелось бы — так это сохранить метафору пользовательского интерфейса TreeView, но избежать создания сотен или тысяч узлов, которые так никогда и не будут посещены. Способ, позволяющий это реализовать, состоит в том, чтобы создавать нужные узлы TreeView лишь тогда, когда становится ясным, что пользователь собирается их посетить. Этого можно добиться, используя некий "умный" код, который 1) заполняет элемент управления TreeView информацией лишь до той точки, до которой он перед этим был развернут, и 2) обрабатывает событие, указывающее на ожидаемое развертывание определенного узла элемента управления TreeView, который, таким образом, должен быть заполнен достоверными данными. Это позволяет сэкономить время и ресурсы, которые иначе пришлось бы расходовать мобильному приложению для заполнения информацией огромного количества узлов, и, в конечном счете, делает приложение более привлекательным с точки зрения конечного пользователя.

Возможны и более сложные подходы, например, заблаговременное продвижение на одну ступень вглубь иерархического дерева 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.3 представлен пример простого приложения с элементами управления TreeView (treeview1) и Button (button1). Щелчок на кнопке во время выполнения приложения устанавливает или сбрасывает состояние элемента управления TreeView. После установки состояния элемента управления TreeView щелчком на кнопке он предоставляет три узла верхнего уровня, которые можно динамически заполнять данными. Этими узлами являются узлы Neighbourhoods, Price и HouseType.

Рис. 11.3. Выполнение приложения, динамически заполняющего данными элемент управления TreeView, на эмуляторе Pocket PC

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

В листинге 11.2 содержится код, который должен быть вставлен в класс Form для данного примера. Для создания приложения необходимо выполнить следующие действия:

1. Начните новый проект Smart Device в Visual Studio .NET и выберите в качестве целевой платформы Pocket PC.

2. Добавьте в форму Form в окне конструктора элементы управления TreeView и Button.

3. Дважды щелкните на кнопке Button в окне конструктора форм; в результате этого будет создан и подключен к кнопке приведенный ниже обработчик событий button1_Click.

4. Введите приведенный ниже код button1_Click, ответственный за заполнение данными элемента управления TreeView.

5. Введите оставшуюся часть приведенного ниже кода, включая константы, определения которых содержатся перед кодом обработчика прерываний button1_Click.

6. Вручную подключите обработчик событий для события BeforeExpand элемента управления TreeView, о чем говорилось в разделе выше.

7. Скомпилируйте пример и запустите его на выполнение.

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

//Фиктивный текст для размещения в заполнителях дочерних узлов

const string dummy_node = "_dummynode";

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

const string node_needToBePopulated = "_populateMe";

//Текст, который мы будем использовать для наших узлов высшего уровня

const string nodeText_Neighborhoods = "Neighborhoods";

const string nodeText_Prices = "Prices";

const string nodeText_HouseType = "HouseTypes";

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

//Обработчик события щелчка для кнопки

//

//Настраивает наш элемент управления TreeView для отображения процесса

//последовательного заполнения дерева

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

private void button1_Click(object sender, System.EventArgs e) {

TreeNode tnNewNode;

//Отключить обновление интерфейса до тех пор, пока дерево

//не будет заполнено

treeView1.BeginUpdate();

//Избавиться от устаревших данных

treeView1.Nodes.Clear();

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

//Узел "Neighborhoods"

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

//Добавить узел "Neighborhoods" верхнего уровня.

tnNewNode = treeView1.Nodes.Add("Neighborhoods");

//Установить для узла метку, указывающую на то, что узел

//будет заполняться динамически

tnNewNode.Tag = node_needToBePopulated;

//Этот фиктивный дочерний узел существует лишь для того, чтобы

//узел имел, по крайней мере, один дочерний узел и поэтому

//был расширяемым.

tnNewNode.Nodes.Add(dummy_node);

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

//Узел "Price"

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

tnNewNode = treeView1.Nodes.Add("Price");

//Установить для узла метку, указывающую на то, что узел

//будет заполняться динамически

tnNewNode.Tag = node_needToBePopulated;

//Этот фиктивный дочерний узел существует лишь для того, чтобы

//узел имел, по крайней мере, один дочерний узел и поэтому

//был расширяемым.

tnNewNode.Nodes.Add(dummy_node);

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

//Узел "HouseType"

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

tnNewNode = treeView1.Nodes.Add("HouseType");

//Установить для узла метку, указывающую на то, что узел

//будет заполняться динамически

tnNewNode.Tag = node_needToBePopulated;

//Этот фиктивный дочерний узел существует лишь для того, чтобы

//узел имел, по крайней мере, один дочерний узел и поэтому

//был расширяемым.

tnNewNode.Nodes.Add(dummy_node);

//Восстанавливаем обновление интерфейса

treeView1.EndUpdate();

}

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

//Обработчик событий BeforeExpand для нашего элемента управления TreeView

//ПРИМЕЧАНИЕ: Этот обработчик событий необходимо будет

// вручную подключить к функции InitializeComponent()

// формы.

//

//Вызывается при запросе пользователем расширения узла, у которого имеется,

//по крайней мере, один дочерний узел. Этот вызов осуществляется до

//отображения дочерних узлов данного узла и дает нам возможность

//динамически заполнить данными элемент управления TreeView.

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

private void TreeView1BeforeExpand (object sender, System.Windows.Forms.TreeViewCancelEventArgs e) {

//Получить узел, который будет расширяться

System.Windows.Forms.TreeNode tnExpanding;

tnExpanding = e.Node;

//Если узел не отмечен как "нуждающийся в заполнении данными",

//то он устраивает нас в том виде, "как он есть".

if (tnExpanding.Tag !=(object) node_needToBePopulated) {

return; //Разрешить беспрепятственное продолжение выполнение

}

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

//Требуется динамическое заполнение дерева данными.

//Мы знаем, что узел должен быть заполнен данными; определить,

//что это за узел

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

if (tnExpanding.Text == nodeText Neighborhoods) {

PopulateTreeViewNeighborhoods(tnExpanding);

return; //добавление элементов закончено!

} else {

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

//добавить.

System.Windows.Forms.MessageBox.Show("НЕ СДЕЛАНО: Добавьте код для динамического заполнения этого узла");

//Снять отметку с этого узла, чтобы мы не могли вновь выполнить

//этот код

tnExpanding.Tag = "";

}

}

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

//Эта функция вызывается для динамического добавления дочерних узлов

//в узел "Neighborhood"

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

void PopulateTreeViewNeighborhoods(TreeNode tnAddTo) {

TreeView tvControl;

tvControl = tnAddTo.TreeView;

tvControl.BeginUpdate();

//Очистить имеющийся фиктивный узел

tnAddTo.Nodes.Clear();

//Объявить четыре узла, которые мы хотим сделать дочерними узлами

//того узла, который был передан.

TreeNode[] newNeighborhoodNodes;

newNeighborhoodNodes = new TreeNode[4];

newNeighborhoodNodes[0] = new TreeNode("Capitol Hill");

newNeighborhoodNodes[1] = new TreeNode("Chelsea");

newNeighborhoodNodes[2] = new TreeNode("Downtown");

newNeighborhoodNodes[3] = new TreeNode("South Bay");

//Добавить дочерние узлы в элемент управления

TreeView tnAddTo.Nodes.AddRange(newNeighborhoodNodes);

tvControl.EndUpdate();

}

Приведенный код демонстрирует, что, проявив немного изобретательности и написав совсем небольшой объем дополнительного кода, можно отложить заполнение сложного пользовательского интерфейса данными до тех пор, пока они не понадобятся пользователю. Независимо от того, работаете ли вы в .NET Compact Framework или в любой другой среде выполнения для мобильных устройств, откладывание заполнения данными расширяемых элементов управления пользовательских интерфейсов до того момента, когда возникнет действительная необходимость в них, является чрезвычайно мощным методом.

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

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

Довольно часто причина низкой производительности приложения кроется в том, что события, генерируемые кодом, ошибочно обрабатываются так, как если бы они были сгенерированы в результате действий пользователя.

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

В листинге 11.3 содержится код, который необходимо вставить в класс Form. Для создания приложения потребуется выполнить следующие действия:

1. Начните новый проект Smart Device в Visual Studio .NET, выбрав в качестве целевой платформы Pocket PC.

2. Добавьте в форму Form элементы управления TextBox, Label, ListBox и Button.

3. Дважды щелкните на кнопке Button в окне конструктора форм; в результате этого будет создан и подключен к кнопке приведенный ниже обработчик событий button1_Click. Введите соответствующий код из листинга 11.3, который будет реагировать на это событие.

4. Дважды щелкните на элементе управления TextBox в окне конструктора форм; в результате этого будет создан и подключен к текстовому окну приведенный ниже обработчик событий textBoxl_TextChanged. Введите соответствующий код из листинга 11.3, который будет реагировать на это событие.

5. Скомпилируйте пример и запустите его на выполнение.

6. Введите текст в текстовое поле; обратите внимание, что каждое нажатие клавиши приводит к выполнению приведенного ниже кода обработки события textBox1_TextChanged.

7. Щелкните на кнопке Button; обратите внимание, что это также приводит к выполнению приведенного ниже кода обработки события textBox1_TextChanged.

НА ЗАМЕТКУ

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

Выполнение того же кода на настольном компьютере сопровождается только однократным запуском указанного события. Вероятно, поведение последующих версий NET Compact Framework будет изменено таким образом, чтобы оно совпадало с поведением .NET Framework (однократный запуск события). События — коварная вещь. Будьте очень внимательны в своих предположениях относительно того как и когда запускаются события.

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

int m_eventTriggerCount;

private void textBox1_TextChanged(object sender, System.EventArgs e) {

m_eventTriggerCount++;

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

label1.Text = "Events: #" + m_eventTriggerCount.ToString();

//Внести каждое событие в список

listBox1.Items.Add(m_eventTriggerCount.ToString() + textBox1.Text);

}

private void button1_Click(object sender, System.EventArgs e) {

//Запускает событие TextChanged так же,

//как если бы текст был введен пользователем

textBox1.Text = "Hello World";

}

Как видно из листинга 11.3, программная установка свойства Text элемента управления TextBox запускает тот же код обработки событий, который запускался бы при вводе текста пользователем. В зависимости от того, какие допущения вами сделаны, результаты могут как совпадать, так и не совпадать с ожидаемыми. Программисты часто пишут коды, предназначенные для заполнения пользовательских интерфейсов данными после их извлечения из внешнего источника. При этом устанавливаются свойства Checked переключателей RadioButton и флажков CheckBox, заполняются значения текстовых полей TextBox, заполняются элементами списки ListBox и ComboBox и так далее. Во многих случаях программисты предполагают, что выполнение всех этих установочных действий не приводит к запуску событий пользовательского интерфейса. Обычно в намерения программиста не входит, чтобы эти события запускались, поскольку пользовательский интерфейс всего лишь подготавливается к тому, чтобы пользователь мог им воспользоваться. Очень часто программисты, которые разрабатывают приложение, хотят, чтобы код обработки событий приложения запускался лишь тогда, когда происходит внешнее событие, например, поступает сигнал таймера, пользователь выполняет щелчок на кнопке или вводит текст в элемент управления и тому подобное.

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

Сложность работы с кодами, управляемыми событиями, связана с тем, что невозможно заранее знать, когда именно будет вызван код того или иного обработчика события. Просматривая исходный код приложения, вы можете точно сказать, когда вызываются библиотечные функции или другие части кода приложения, но ничто не укажет вам на то, когда именно среда выполнения запустит событие. По этой причине большинство разработчиков просто делают относительно этого некоторые предположения, которые даже не удосуживаются тщательно проверять. Кроме того, по мере увеличения объема приложения за счет дальнейшего добавления пользовательского кода и соответствующего усложнения его внутренней структуры в нем появляется все больше кода, предназначенного для генерации и обработки событий пользовательского интерфейса; из-за этого также могут возникать весьма тонкие взаимодействия, обнаружить которые простым просмотром исходного текста кода очень трудно. Так, код, реагирующий на выбор элемента в списке ListBox, может запускать код, инициирующий обновление свойств элементов управления CheckBox и TextBox, как показано в приведенном ниже примере:

textboxUserName.Text = selectedRecord.Username;

checkboxDeliverPackageToHomeAddress.Checked = selectedRecord.DeliverToHome;

Этот код кажется простым, но если с элементами управления CheckBox или TextBox связаны события, то они могут запускаться и в свою очередь запускать код приложения, который изначально предназначался только для обработки действий пользователя. В свою очередь, этот код может изменять другие элементы пользовательского интерфейса, что вызовет появление каскада событий, запуск которых вовсе не входил в намерения разработчика приложения.

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

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

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

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

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

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

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

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

1. Начните новый проект Smart Device в Visual Studio .NET, выбрав в качестве целевой платформы Pocket PC.

2. Добавьте в форму Form элементы управления TextBox, RadioButton, ListBox и Button (на рис. 11.4 показано, как должна выглядеть форма).

3. Дважды щелкните на кнопке Button в окне конструктора форм. В результате этого будет создан и подключен к кнопке приведенный ниже обработчик событий button1_Click. Введите соответствующий код из листинга 11.4, который будет реагировать на это событие.

4. Дважды щелкните на элементе управления TextBox в окне конструктора форм. В результате этого будет создан и подключен к текстовому окну приведенный ниже обработчик событий textBox1_TextChanged. Введите соответствующий код из листинга 11.4, который будет реагировать на это событие.

5. Дважды щелкните на элементе управления RadioButton1 в окне конструктора форм. В результате этого будет создан и подключен к переключателю приведенный ниже обработчик событий radioButton1_Click. Введите соответствующий код из листинга 11.4, который будет реагировать на это событие.

6. Измените имя второй кнопки с button2 на buttonShowEventLog и дважды щелкните на кнопке Button в окне конструктора форм. В результате этого будет создан и подключен к кнопке приведенный ниже обработчик событий buttonShowEventLog_Click. Введите соответствующий код из листинга 11.4, который будет реагировать на это событие

7. Введите оставшуюся часть приведенного ниже кода, включая операторы #if и #endif и переменные уровня класса.

8. В самом начале файла класса формы Form добавьте оператор #define EVENTINSTRUMENTATION. Это позволит вам использовать условную компиляцию кода.

9. Скомпилируйте пример и запустите его на выполнение. Щелкните на кнопке Button1, введите текст в текстовом поле TextBox и щелкните на кнопке ShowEventLog, чтобы увидеть список событий, которые были запущены.

10. Завершив выполнение приложения, удалите символы комментария в строке m_userInterfaceUpdateOccuring = true; кода обработчика событий Button_Click и повторно запустите приложение на выполнение. Обратите внимание, что установка этого флага предотвратила нежелательное выполнение кода приложения при запуске обработчиков событий в результате программного доступа к свойствам элементов управления.

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

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

//Поместить данную директиву #define в начале определения

//класса, если требуется регистрация событий

//#define EVENTINSTRUMENTATION

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

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

//Флаг, указывающий обработчикам событий, должен ли из них осуществляться

//выход без выполнения каких-либо действий

//-----------------------------------------------------------------------

bool m_userInterfaceUpdateOccuring;

//Счетчики событий

private int m_radioButton1ChangeEventCount;

private int m_textBox1ChangeEventCount;

//-------------------------------------------------------------------------

//Код, который следует включать лишь в том случае, если приложение

//выполняется в режиме контроля запуска событий. Этот код характеризуется

//относительно высокими накладными расходами, и его следует компилировать и

//выполнять только тогда, когда выполняется диагностика.

//-------------------------------------------------------------------------

#if EVENTINSTRUMENTATION

private System.Collections.ArrayList m_instrumentedEventLog;

//------------------------------------------------------------------------

//Заносит записи о возникновении событий в массив, который мы

//можем просмотреть

//Примечание: Не делается никаких попыток ограничить размерность массива

// регистрационных записей, поэтому, чем дольше выполняется

// приложение, тем больше становится размер массива

//------------------------------------------------------------------------

private void instrumented_logEventOccurrence(string eventData) {

//Создать журнал событий, если он еще не был создан

if (m_instrumentedEventLog == null) {

m_instrumentedEventLog = new System.Collections.ArrayList();

}

//Зарегистрировать событие

m_instrumentedEventLog.Add(eventData);

}

//------------------------------------------------------------------------

//Отобразить список возникших событий

//Примечание: Этот вариант реализации довольно груб.

// Целесообразнее отображать список событий

// в отдельном диалоговом окне, которое специально выводится

// для этого на экран.

//------------------------------------------------------------------------

private void instrumentation_ShowEventLog() {

System.Windows.Forms.ListBox.ObjectCollection listItems;

listItems = listBoxEventLog.Items;

//Очистить список элементов

listItems.Clear();

//При отсутствии событий - выход

if (m_instrumentedEventLog == null) {

listItems.Add("0 Events");

return;

}

//Отобразить поверх списка общее количество

//подсчитанных нами событий

listItems.Add(m_instrumentedEventLog.Count.ToString() + " Events");

//Перечислить элементы списка в обратном порядке, чтобы первыми

//отображались самые последние из них

string logItem;

for(int listIdx = m_instrumentedEventLog.Count - 1; listIdx >= 0; listIdx--) {

logItem=(string) m_instrumentedEventLog[listIdx];

listItems.Add(logItem);

}

}

#endif

//------------------------------------------------------

//Событие изменения состояния переключателя RadioButton1

//------------------------------------------------------

private void radioButton1_CheckedChanged(object sender, System.EventArgs e) {

//Если обновление данных в пользовательском интерфейсе осуществляется

//приложением, то мы не хотим обрабатывать его так же, как если бы

//это событие было запущено пользователем. Если это именно так,

//то выйти из функции без выполнения каких-либо действий.

if (m_userInterfaceUpdateOccuring == true) {

return;

}

//Подсчитать, сколько раз выполнена обработка данного события

m_radioButtonlChangeEventCount++;

#if EVENTINSTRUMENTATION

//Зарегистрировать наступление события

instrumented_logEventOccurrence("radioButton1.Change:" + //Событие

m_radioButton1ChangeEventCount.ToString() + ":" +       //Количество раз

radioButton1.Checked.ToString());                       //Значение

#endif

//-------------------------------------------------------------

//Событие щелчка на кнопке Button1

//Имитирует обновление пользовательского интерфейса программным

//кодом, что может приводить к запуску обработчика события

//-------------------------------------------------------------

private void button1_Click(object sender, System.EventArgs e) {

//Указать на то, что мы не хотим, чтобы обработчики сразу же

//обрабатывали события, поскольку мы обновляем

//пользовательский интерфейс.

//m_userInterfaceUpdateOccuring = true;

radioButton1.Checked = true;

textBox1.Text = "Hello World";

//Обновление пользовательского интерфейса завершено

m_userInterfaceUpdateOccuring = false;

}

//------------------------------------------------------------------

//Обработчик события изменения состояния элемента управления TextBox

//------------------------------------------------------------------

private void textBox1_TextChanged(object sender, System.EventArgs e) {

//Если обновление данных в пользовательском интерфейсе осуществляется

//приложением, то мы не хотим обрабатывать его так же, как если бы

//это событие было запущено пользователем. Если это именно так,

//то выйти из функции без выполнения каких-либо действий.

if (m_userInterfaceUpdateOccuring == true) {

return;

}

//Подсчитать, сколько раз выполнена обработка данного события

m_textBox1ChangeEventCount++;

#if EVENTINSTRUMENTATION

//Занести событие в журнал

instrumented_logEventOccurrence("textBox1.Change:" + //Событие

m_textBox1ChangeEventCount.ToString() + ":" +       //Количество раз

textBox1.Text.ToString());                          //Значение

#endif

}

private void buttonShowEventLog_Click(object sender, System.EventArgs e) {

#if EVENTINSTRUMENTATION

instrumentation_ShowEventLog();

#endif

}

Не допускайте, чтобы пользователю оставалось лишь догадываться о ходе выполнения приложения

Важным аспектом производительности приложения является его интерактивность. Наилучшим вариантом было бы полное отсутствие каких-либо задержек во взаимодействии пользователя с пользовательским интерфейсом, однако в некоторых случаях это оказывается просто невозможным. Если необходимо выполнить работу, результатов которой пользователь должен дожидаться в течение длительного времени, то следует приложить некоторые усилия к тому, чтобы сделать условия такого ожидания настолько комфортными, насколько это возможно. Считайте, что эта задача столь же важна, как и проектирование помещения, в котором пациенты вынуждены дожидаться своей очереди при посещении врача. Было бы замечательно, если бы к врачу можно было зайти вообще безо всякой очереди, но это не представляется возможным (Если вам известны исключения, дайте мне об этом знать!) Условия ожидания были бы значительно худшими, если бы не было человека в регистратуре, который делает отметку о вашем визите, если бы вам не сообщали, сколько примерно времени вам придется ждать, если бы окружающая обстановка не было комфортной или если бы вам не предоставляли возможность полистать или почитать какой-нибудь журнал, дабы скоротать время ожидания. Прекрасным и эстетически привлекательным элементом интерьера, помогающим занять ваше внимание, служит, в частности, аквариум. Многое дает и регистрация вашего прихода. Условия визита еще более улучшатся, если регистратор сообщит вам, как долго продлится ваше ожидание, а также предложит газету и прохладительный напиток, чтобы вы чувствовали себя более комфортно. (Опять-таки, если вам известна клиника, где именно так все и происходит, обязательно сообщите мне об этом.)

Конечного пользователя очень раздражает, если ему приходится ждать, не зная, сколько времени может понадобиться задаче для ее завершения. Разумеется, надеяться на то, что мобильное устройство предложит вам чашечку ароматного кофе или вступит с вами в приятную беседу, не приходится, однако совершенно очевидно, что существуют и более простые вещи, которые способны улучшить условия ожидания, возникающего в процессе работы с мобильными приложениями. С вычислительной точки зрения индикаторы выполнения и курсоры ожидания не играют никакой роли, однако они чрезвычайно важны с точки зрения информирования пользователя о том, что происходит, и поддерживают в нем чувство сопричастности к решению задачи. В главе 7 содержится общее описание различных возможных уровней интерактивного взаимодействия пользователя с приложением и приводится соответствующий иллюстративный пример. Чтобы дополнить этот обзор более подробным рассмотрением некоторых деталей, ниже еще раз перечисляются различные уровни комфортности условий, в которых оказываются конечные пользователи, когда им приходится дожидаться, пока приложение не выполнит определенную работу.

■ Наихудшие условия: полное отсутствие связи с пользователем. Картина приложения, которое не реагирует на запросы и не дает пользователю ни малейшего намека на то, что работа для него выполняется, очень напоминает зависание или блокирование приложения. Раздражение пользователя быстро нарастает и он начинает лихорадочно щелкать кнопками или давить на экран, чтобы добиться от приложения хоть какого-нибудь ответа. В результате этого остается ряд случайных непреднамеренных событий, которые приложению придется обрабатывать, когда управление будет вновь передано пользовательскому интерфейсу. Если предыдущие попытки успеха не принесли, то спустя короткое время, пользователь, вероятнее всего, попытается закрыть приложение, переключиться на другое приложение или извлечь из устройства батарею для перезарядки. (В случае мобильных телефонов это не составляет никакого труда.) Ситуация еще более усугубляется, когда мобильное приложение не предоставляет пользователю никакой визуальной индикации того, что работа завершена. Если предположить, что в течение всего времени, пока приложение было занято вычислениями, пользователь терпеливо ждал, не нажимая никаких кнопок и не вынимая батарею, то как он узнает о том, что к приложению вернулась способность реагировать на запросы? Старайтесь всегда избегать ситуаций, в которых приложение выглядит вполне нормально и, казалось бы, должно отвечать на запросы, но на самом деле этого не происходит.

■ Улучшенные условия: отображение курсора ожидания в течение того времени, пока приложение не в состоянии отвечать на запросы. Отображение курсора ожидания преследует две важные цели. Во-первых, он извещает конечных пользователей о том, что работа для них выполняется, а во-вторых, его исчезновение указывает на то, что работа завершена и приложением вновь можно пользоваться. Если учесть, что отображение курсора ожидания обычно не составляет никакого труда, то нежеланию приложить даже столь незначительные усилия к тому, чтобы улучшить интерактивные свойства приложения, не может быть никаких оправданий. Любая операция, для выполнения которой требуется более нескольких десятых долей секунды, тормозит пользовательский интерфейс до такой степени, что пользователь сможет это почувствовать, и поэтому нет ни малейших оснований для того, чтобы в этой ситуации не дать пользователю понять, что приложение выполняет нужную для него работу. Используя курсор ожидания, вы на несколько секунд "покупаете" понимание и терпение со стороны пользователя устройства, но если выполнение работы занимает более нескольких секунд, то вам следует прибегнуть к более информативному индикатору выполнения, нежели простой курсор ожидания. Кроме того, если почти любое действие пользователя сопровождается появлением курсора ожидания, вам следует позаботиться об оптимизации мобильного приложения и выполнении части обработки в фоновом режиме; задержки могут быть приемлемыми в некоторых ситуациях, но далеко не во всех.

■ Лучшие условия; отображение индикатора выполнения или сопроводительного текста, поясняющего, что именно происходит в данный момент. Если операция, завершения которой вынужден дожидаться пользователь, длится более нескольких секунд, следует подумать об использовании индикатора выполнения или текстовых пояснений, которые информируют пользователя о том, что происходит в данный момент, отображают процентную долю оставшейся работы или оценку времени, оставшегося до завершения операции. Отображение курсора ожидания не препятствует отображению текста, информирующего пользователя о том, как продвигается работа. Пояснительный текст, который говорит пользователю о том, какая именно работа для него выполняется, можно отображать позади курсора ожидания. Полезной будет любая информация, указывающая на степень выполнения работы. Информативный текст полезен, в частности, тем, что помогает поддерживать в пользователе чувство причастности к вычислительному процессу. Так, алгоритм, загружающий информацию с сервера, может отображать такую последовательность обновляющихся сообщений: "Поиск сервера", "Сервер найден. Выполняется регистрация", "Загружается информация (10%)", "Загружается информация (60%)", "Готово!" Информация такого рода порождает в пользователе ощущение участия в процессе загрузки. Обратите внимание на важность последнего сообщения, говорящего о том, что выполнение операции завершилось успешно. Кроме того, если в процессе загрузки возникают какие-либо трудности, то текстовая информация, которая содержится в указанных обновляемых сообщениях, может помочь пользователю в преодолении возникших проблем.

При написании кода, предоставляющего пользователю периодически обновляемую информацию о степени завершения задач, которые выполняются в течение длительного времени, может потребоваться явная перерисовка элемента управления. Если не предусмотрено явное обновление форм и элементов управления, то они, как правило, лишь помещают сообщения, требующие перерисовки экрана, в очередь, непринудительное обновление сообщений на экране происходит только тогда, когда у системы находится время для их обработки. Поскольку ваш вычислительный процесс может выполняться в том же потоке, что и код пользовательского интерфейса, выполнение полезной работы будет препятствовать обработке сообщений, помещенных в очередь, до тех пор, пока управление не будет возвращено пользовательскому интерфейсу. Для разрешения этой проблемы в .NET Compact Framework для каждого элемента управления предусмотрен метод Update(). Вызов этого метода приводит к немедленной перерисовке элемента управления. В листинге 11.5 представлен простой рабочий алгоритм, который периодически обновляет в элементе управления Label текст, информирующий о степени выполнения приложения. Если только не осуществить вызов label1.Update() при обновлении текста в Label, то новый текст будет отображен лишь после завершения работы.

■ Еще более лучшие условия: отображение информации о ходе выполнения задачи с одновременным предоставлением пользователю возможности отменить операцию. Для выполнения некоторых задач может требоваться значительное время, и пользователь может захотеть отменить такую задачу, не дожидаясь ее завершения. Может так оказаться, что синхронизация задачи с сервером будет осуществляться в течение нескольких минут, но пользователю мобильного устройства в это время надо будет войти в лифт или спуститься в метро, где доступ к сети невозможен. Возможно и такое, что конечному пользователю мобильного устройства надо срочно получить информацию из другой части приложения и ждать, пока завершится текущая задача, он не может. Если выполнение задачи затягивается, и она блокирует пользовательский интерфейс, то неплохим решением будет предусмотреть для пользователя возможность отмены операции, которая выполняется для него. Это можно обеспечить, организовав в алгоритме периодический опрос состояния флажка, который устанавливается, если пользователь нажимает кнопку отмены выполнения операции. Как объяснялось в главе, посвященной многопоточному выполнению, это удобно реализовать с помощью конечного автомата, управляющего состоянием фоновой задачи.

Если длительная задача выполняется в высокоприоритетном потоке (том же, в котором выполняется код пользовательского интерфейса), то предоставление пользователю возможности отменить ее выполнение, хотя и осложняется, по-прежнему остается осуществимым. Как и в случае обновления пользовательского интерфейса в процессе выполнения интенсивных вычислений, реакция на пользовательские запросы, в том числе и на щелчок на кнопке отмены выполнения, возможна лишь при условии обработки сообщений потока пользовательского интерфейса. В .NET Compact Framework предусмотрено решение для подобных ситуаций, но аналогичные концепции используются, вероятно, и в каркасах приложений для других устройств. Вызов статического метода System.Windows.Forms.Application.DoEvents() приводит к принудительной обработке всех сообщений, находящихся в очереди данного потока, до того, как выполнение сможет быть продолжено. Это означает, что будут обработаны и сообщения, требующие перерисовки пользовательского интерфейса, в том числе ожидающие обработки щелчки на кнопках и нажатия клавиш. Если вызывать метод DoEvents() достаточно часто (несколько раз в секунду), то можно обеспечить сохранение интерактивности пользовательского интерфейса без малейшего ущерба для выполнения текущей задачи.

Может показаться, что метод DoEvents() является панацеей от всех бед, но это не так. Вызывая метод DoEvents(), необходимо проявлять осторожность, поскольку при этом могут порождаться в высшей степени нежелательные тонкие эффекты. Так как вызов метода DoEvents() приводит к обработке всех сообщений, прежде чем управление будет возвращено вызвавшему его коду, то это может сопровождаться вызовом обработчиков событий таймера и повторными вхождениями в выполняющиеся в данный момент обработчики событий. В результате этого может сложиться такая ситуация, при которой мы будем иметь множество вложенных вызовов обработчиков событий, связанных с элементами пользовательского интерфейса, и таймеров, если метод DoEvents() вызывается внутри обработчика события и новое сообщение о событии помещается в очередь еще до завершения обработки первого события. Собираясь использовать метод DoEvents(), вы должны использовать при написании кода обработчиков событий своего приложения технологию "безопасного программирования" (defensive programming), которая предполагает тщательную проверку выполнения всех допустимых условий. Настоятельно рекомендуется помещать все подобные проверки в самом начале кода обработчиков событий, чтобы осуществить немедленный выход из функции в случае, если вхождение в нее является повторным. Прежде чем осуществить вхождение в блок кода, в котором выполняется задача, требующая длительного времени, и в процессе этого вызывается метод DoEvents(), убедитесь в том, что для всех элементов управления, генерация которыми событий должна быть запрещена, значение свойства Enabled установлено в false; благодаря этой мере пользователи будут лишены возможности выполнять щелчки на указанных элементах управления, тем самым загромождая очередь событий. Ситуации, в которых возможность повторного вхождения в обработчики событий является желательной, встречаются крайне редко, ибо в этом случае код становится чрезвычайно запутанным и трудно поддается отладке. Если вы можете выбирать между использованием метода DoEvents() и созданием фонового потока для выполнения основных вычислений, то я бы рекомендовал почти всегда отдавать предпочтение хорошо продуманному последнему решению. Каким бы сложным с концептуальной точки зрения ни казалось использование нескольких потоков, модель их выполнения обычно оказывается более простой и предсказуемой, чем смесь кодов каркаса и приложения, вызываемая при использовании метода DoEvents(). Ничто из вышесказанного не является чем-то специфическим для мобильных устройств; те же самые проблемы возникают и в случае настольных компьютеров, однако мы акцентируем на них внимание, исходя из повышенных потребностей конечных пользователей в отношении интерактивного взаимодействия с приложением в случае мобильных устройств. Тем не менее, иногда применение метода DoEvents() может оказаться полезным, и я описываю здесь этот подход, одновременно предостерегая вас: "Caveat emptor!" ("Пусть покупатель будет бдителен!"), то есть действуйте на свой страх и риск. Если вы покупаете билет на DoEvents(), то должны быть готовы ко всем подъемам и спускам на этом маршруте.

■ Наилучшие условия: найдите такой способ выполнения задачи, которые никоим образом не приводят к блокированию действий пользователя. Если ваше мобильное приложение способно вытолкнуть выполнение работы в фоновый поток, предоставляя пользователю возможность продолжить работу с другими задачами и своевременно уведомляя его о завершении первой задачи, то можете считать, что Чаша Грааля интерактивных возможностей приложения — в ваших руках. Действуя подобным образом, вы должны тщательно продумать модель выталкивания выполнения работы в фоновый поток. Вам необходимо решить, каким образом следует информировать пользователя о ходе выполнения работы, сохранив для него возможность управления выполнением фоновой задачи, но при этом не создавать никаких ощутимых неудобств в отношении взаимодействия пользователя с высокоприоритетным потоком пользовательского интерфейса. В качестве примера удачного применения этой стратегии в случае приложений для настольных компьютеров можно привести поддержку в Microsoft Word печати документов в фоновом режиме с одновременным предоставлением пользователю возможности продолжения работы по редактированию активного документа в высокоприоритетном потоке. Это средство очень полезно и кажется простым, но, чтобы все это работало, проектировщикам пришлось хорошенько потрудиться

Листинг 11.5. Вызов метода Update() элемента управления для отображения пояснительного текста, информирующего о ходе выполнения задачи

//--------------------------------------------------------------------

//Этот код принадлежит форме, содержащей по одному элементу управления

//Button (button1) и Label (label1)

//--------------------------------------------------------------------

private void button1_Click(object sender, System.EventArgs e) {

//Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.WaitCursor;

string testString;

for (int loop3 = 0; loop3 < 100; loop3 = loop3 + 10) {

label1.Text = loop3.ToString() + "% выполнено...";

//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

//Чтобы отобразить информацию о процессе обновления,!

//удалите символы комментария в строке ниже         !

//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

//label1.Update();

testString = "";

for(int loop2 = 0; loop2 < 1000; loop2++) {

testString = testString + "тест";

}

}

label1.Text = "Готово!";

//Удалить курсор ожидания

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default;

}

Выбор подходящих форматов и размеров растровых изображений

С растровыми изображениями приходится иметь дело как при низкоуровневой работе с графикой, так и при высокоуровневом проектировании пользовательского интерфейса. В описаниях большинства каркасов пользовательских интерфейсов упоминается элемент управления PictureBox, способный отображать битовые образы, а низкоуровневые графические библиотеки имеют дело главным образом с операциями на битовом уровне. Растровые изображения используются во многих разновидностях приложений, представляющих значительный интерес; достаточно привести в качестве примера приложения, в которых используются карты городских улиц, изображения медицинского назначения, фотографии объектов недвижимости или изображения игровых полей. В процессе работы с данными растровых изображений важно заботиться как о способах файлового представления изображений, так и об объемах памяти, занимаемых данными изображений. Для хранения и потоковой передачи данных существуют различные файловые форматы, у каждого из которых характеризуется своими достоинствами и недостатками. Независимо от того, файлы какого формата вы используете, в памяти растровые изображения обычно представляются в виде матрицы, соответствующей пиксельным размерам изображения; этот несжатый формат удобен тем, что обеспечивает быстрое использование изображений как графическим оборудованием, так и базовой операционной системой.

Размеры изображения имеют существенное значение

Приступая к работе с растровыми изображениями для мобильных устройств, вы, прежде всего, должны задаться вопросом о том, каковы должны быть физические пиксельные размеры изображений, которые вы намерены переносить на устройства и загружать в память.

Для упрощения расчетов предположим, что мы имеем дело с изображениями в форме квадрата. Тогда 1-мегапиксельному изображению будет соответствовать матрица размером 1000×1000 пикселей. Такое разрешение значительно превышает возможности экранов большинства мобильных устройств, и до недавнего времени было слишком высоким даже для экранов настольных компьютеров (размеры которых обычно составляет 1024×768 = 786432 пикселя). Вместе с тем, даже недорогие современные цифровые камеры позволяют получать фотографии, состоящие из более чем 2-мегапикселей, однако не столь уж большой редкостью являются ныне 4- и 6-мегапиксельные камеры, причем этот пиксельный показатель с каждым годом возрастает.

Физические дисплеи с большим количеством пикселей потребляют больше электроэнергии по сравнению с экранами, обладающими низкой разрешающей способностью, их стоимость выше, они занимают больше места и являются более хрупкими. Кроме того, с увеличением размеров экрана возрастают требования к памяти устройства и его вычислительным возможностям в отношении графики. Несомненно, с течением времени количество пикселей на экранах мобильных устройств будет только расти, но есть все основания полагать, что это будет происходить с запаздыванием по отношению к тем величинам разрешений, которые будут становиться доступными для цифровых камер и настольных дисплеев. Если допустить, что размеры дисплея мобильного устройства составляют 500×500 пикселей, то экран в состоянии отображать в общей сложности 250000 пикселей. Это составляет всего лишь ¼ объема 1-мегапиксельного изображения и 1/16 объема 4-мегапиксельного. Если подойти к рассмотрению этого вопроса с другой стороны, то можно заметить, что для размещения 4- мегапиксельного изображения на дисплее Pocket PC с размерами 240×320 (76800 пикселей) потребуется отбросить 98% пикселей изображения, не попадающих в область экрана. Аналогичным образом, в случае 2-мегапиксельного изображения для размещения его на том же экране Pocket PC потребуется отбросить 96% пикселей, тогда как в 1-мегапиксельном изображении лишними окажутся 92% пикселей.

Почему мы об этом говорим? На то имеется несколько причин:

■ Размер загружаемого файла. Если избыточные пиксели вашему приложению не нужны, то имеет ли смысл их загружать? Загрузка большего файла потребует больше времени, да и в деньгах это часто будет стоить дороже. Уменьшенные размеры экранов специально учитываются Web-приложениями для мобильных устройств, которые с этой целью используют изображения с низким разрешением. To же самое имеет смысл делать и в случае мобильных приложений с развитыми функциональными возможностями, развернутых на устройствах.

■ Объем памяти, необходимый для храпения изображения на устройстве. Если ваше мобильное приложение загружает крупное изображение, то его необходимо где-то хранить. В типичных случаях для этого используется либо виртуальная файловая система в ОЗУ, либо флэш-память. В любом случае для чтения и записи изображений, размеры которых превышают необходимые, требуется дополнительное время, и они зря занимают память, которую иначе можно было бы использовать для хранения большего количества изображений или других данных. Что бы вы выбрали: иметь на своем устройстве только одно 4-мегапиксельное изображение или десяток изображений по размерам экрана?

■ Внутреннее представление изображения в памяти. Пожалуй, это наиболее значимый из рассматриваемых нами аспектов. Если ваше мобильное приложение загружает в память 4-мегапиксельное изображение, то оно создает в памяти битовый образ, состоящий из 4 миллионов пикселей. Скажите, часто ли вам приходилось объявлять и использовать в своих приложениях целочисленные массивы, содержащие по 4 миллиона элементов? Объем памяти, необходимый для хранения такого массива, настолько огромен, что почти во всех случаях оказывается значительно больше объема загруженного кода и всей остальной памяти, относящейся к приложению. Независимо от эффективности используемого метода сжатия файлов, хранящийся в памяти битовый образ остается битовым образом и представляет собой отображение битов изображения в памяти устройства. Кроме того, если используемый вами файловый формат изображения предполагает привлечение сложных математических алгоритмов, обеспечивающих высокую степень сжатия данных, то эти же алгоритмы должны будут применяться и для распаковки изображений, что довольно-таки ощутимо скажется на производительности вашего приложения. Загрузка крупных растровых изображений в память — это прямая дорога к исчерпанию всей свободной памяти, доступной на устройстве, результатом чего будет либо полное падение производительности вашего приложения, либо его аварийное завершение вследствие нехватки памяти.

Мораль сей басни такова: не имеет никакого смысла использовать изображения с числом пикселей, превышающим размер экрана. Эти изображения будут медленно переноситься на устройство, потребуют использования больших объемов памяти для их загрузки и сохранения, и в любом случае должны будут урезáться до размеров, соответствующих размерам экрана мобильного устройства. Лучше всего согласовываться с размерами экранов доступных устройств и выбирать такие размеры изображений, которые соответствуют размерам рабочего пространства. Если в приложении предусмотрен элемент управления PictureBox, размеры которого должны составлять 120×120 пикселей, то использовать следует изображения с такими же размерами.

Размеры большинства реальных изображений значительно превышают те, при которых еще возможна эффективная работа с мобильными устройствами. Каким же образом можно устранить такую нестыковку? Здесь мы имеем дело с ситуацией, которая предоставляет великолепные условия для выполнения части работы вне устройства, чтобы тем самым улучшить производительность самого устройства. Если изображения, которые представляют интерес, являются статическими и известны уже на стадии проектирования, то их необходимо уменьшить до размеров, соответствующих фактическим значениям разрешения экранов устройств, на которых вы собираетесь их отображать. Если же приложение работает с динамическими изображениями, то они должны масштабироваться на сервере. При необходимости сервер может осуществлять загрузку крупных изображений и их масштабирование до размеров, соответствующих размерам экрана устройства, в динамическом режиме, однако с многих точек зрения гораздо эффективнее выполнить эту работу только один раз и кэшировать результаты на сервере для их последующего многократного использования. Поскольку изображения, приведенные в соответствие с устройствами, имеют небольшие размеры, то для хранения их на сервере вместе с исходными полномасштабными изображениями потребуется выделить лишь незначительное по объему дополнительное место в хранилище. Проще всего это сделать на том этапе, когда изображения загружаются на сервер.

Любые попытки загрузки крупных изображений в мобильное приложение приводят к созданию жесткого дефицита памяти. Избегайте подобных действий, поскольку от загрузки изображений, размер которых превышает разрешение экрана устройства, конечные пользователи ничего не выигрывают. Вместо этого следует убедиться в том, что разрешение цифровых изображений, поступающих на устройства, согласуются с размерами области экрана, на которой они будут отображаться. Такой подход будет гораздо более результативным.

Уменьшение размера файла: достижение баланса между степенью сжатия и разрешением изображения

Для уменьшения размеров файлов цифровых изображений используют три способа:

1. Снижение разрешения. Суть этого способа заключается в уменьшении фактического количества пикселей, составляющих изображение. Если в Windows XP войти в программу Paint, выбрать в меню Рисунок пункт Растянуть/наклонить и уменьшить изображение до 50% его первоначальной ширины, то количество пикселей в изображении уменьшится наполовину. Уменьшив далее изображение до 50% его первоначальной высоты, вы еще раз уменьшите его разрешение в два раза. Теперь количество пикселей в полученном изображении будет составлять 25% от первоначального (0,5×0,5 = 0,25). Уменьшение количества пиксельных данных, подлежащих сохранению, означает уменьшение общего размера изображения.

2. Выбор наиболее подходящего формата файлов. Различные разновидности распространенных файловых форматов отличаются друг от друга своей способностью сжимать различные изображения. Одни форматы хорошо подходят для фотографий (множество цветовых оттенков, мало резких границ), другие больше всего пригодны для сохранения компьютерной графики (резкие границы изображений, небольшое количество цветовых оттенков). В некоторых форматах сжатие изображений вообще не применяется. Выбор наиболее подходящего формата позволит обеспечить наилучшее качество изображения при минимальном размере.

Некоторые файловые форматы обеспечивают дополнительную возможность выбора глубины цвета сохраняемого изображения. Глубина цвета представляет собой количество битов, используемых для описания изображения. Если можно обойтись меньшим количеством цветов, то выбор меньшей глубины цвета позволит уменьшить размер файла.

3. Увеличение степени сжатия. Во многих случаях алгоритмы сжатия с потерей качества предоставляют возможность выбора приемлемой степени сжатия, обеспечивающей получение изображений желаемого качества.

Чтобы добиться снижения размера файла изображения, начните с разрешения. Уменьшите размер изображения, приведя его в соответствие с размерами экрана вашего устройства; благодаря этому вы сможете избавиться от ненужных данных. Далее, выберите подходящий формат файла, который обеспечивает наилучшее качество изображения при минимально возможном размере файла и минимальной глубине цвета. Наконец, если применяется метод сжатия с потерями, поэкспериментируйте с параметрами сжатия.

Так много файловых форматов и так мало времени…

Существует множество файловых форматов, которые можно использовать для работы с цифровыми изображениями. Каждый из них характеризуется своими преимуществами и недостатками. Ниже приводятся описания наиболее распространенных форматов, которые часто поддерживаются на мобильных устройствах.

Формат JPG/JPEG

В полном соответствии со своим названием файлы JРЕG (Joint Photographic Expert Group — Объединенная группа экспертов в области фотографии) являются непревзойденными при хранении фотографических и реальных изображений. JPEG — это формат сжатия, допускающий регулирование потери качества изображений, что в общем случае позволяет обеспечивать отличное сжатие файлов за счет лишь незначительного ухудшения качества изображения. Во всех JPEG-фотографиях, полученных обычными цифровыми камерами, используется сжатие с потерями. Именно благодаря этому удается сжимать потрясающие 3-мегапиксельные изображения до размера 600 Кбайт. В более сложных программах рисования можно регулировать степень сжатия JPEG-файлов, что позволяет добиваться наилучшего баланса между качеством и размером изображения. При использовании формата JPEG фотографии, адаптированные к разрешению экрана Pocket PC, могут быть сжаты до размера менее 20 Кбайт, но, несмотря на это, будут отлично выглядеть.

Поскольку формат JPEG предполагает работу с реальными изображениями, его использование обычно не позволяет получить наилучшие результаты в случае таких сгенерированных компьютером растровых изображений, как текст на экранных снимках, резкие линии и резкие границы перехода между областями различного цвета. При работе с изображениями такого рода целесообразнее, как правило, использовать форматы без потерь.

Формат PNG

Формат PNG (Portable Network Graphics — переносимая сетевая графика) является, можно сказать, новичком среди файловых форматов, однако этот новичок быстро завоевывает признание в качестве превосходного формата файлов, предназначенных для хранения изображений. Попытки создания формата PNG были реакцией на возникновение некоторых проблем, связанных с защитой прав на интеллектуальную собственность в отношении формата GIF. Файлы формата PNG обеспечивают отличное сжатие без потерь в случае цифровых изображений. Если ваша платформа поддерживает изображения PNG и вам необходимо сжатие без потерь, то это именно тот формат, который вам нужен. Формат PNG во многих случаях обеспечивает значительно лучшее сжатие, чем формат GIF, и при доступности обоих форматов предпочтение следует отдавать именно ему.

Формат GIF

Формат GIF (Graphics Interchange Format — формат графического обмена) можно считать предшественником формата PNG. GIF-файлы также предлагают сжатие без потерь, но ограничены использованием 256 цветов. Из-за этого ограничения формат GIF не годится для хранения фотографических изображений. GIF-файлы интенсивно использовались при создании Web-страниц в Internet в первые годы своей популярности и по этой причине продолжают находить широкое применение и в наши дни.

Формат BMP

Битовые образы (bitmaps) хранят несжатые данные изображений. Формат сохраняемых в BMP-файлах данных аналогичен формату хранения битовых образов в памяти. Помимо того, что не требуется выполнять дополнительную работу по распаковке файлов, использование BMP-файлов не имеет никаких преимуществ, если не считать их широкой доступности.

В том, что касается разработки приложений для .NET Compact Framework, JPG- файлы больше всего подходят для фотографических изображений, а PNG-файлы — для битовых образов, требующих максимально достоверной передачи изображений. Ситуации, в которых требуется полная, с точностью до пикселя, достоверность передачи изображений, обычно встречаются тогда, когда некоторое изображение будет использоваться с определением одного цвета пикселей в качестве прозрачного. Области прозрачности могут применяться при создании сложных рисунков, когда одни рисунки "просматриваются" через другие, о чем будет более подробно говориться далее в главе 13.

Как поступать в тех случаях, когда источником изображения с высоким разрешением является само мобильное устройство

Многие современные мобильные телефоны выпускаются с установленными в них цифровыми камерами, позволяющими получать фотографии. При этом размеры некоторых изображений могут превышать 1 мегапиксель (1000×1000 пикселей), и можно не сомневаться, что эта тенденция будет только усиливаться. Как и фотографии, получаемые с помощью цифровых фотокамер, разрешение таких изображений значительно превосходит те пределы, выше которых нормальный вывод изображений на экраны устройств становится невозможным; эти изображения предназначены для просмотра на экранах с большими размерами (настольные компьютеры) или для вывода на печать. Загружать и удерживать в памяти битовые образы таких размеров слишком расточительно, однако из-за проблем задержек и устойчивости связи бессмысленно пытаться отсылать картинку на сервер для ее уменьшения, чтобы получить ее обратно на устройстве в уменьшенном виде. Решение, которое позволяет работать с изображениями, характеризующимися высоким разрешением, и вместе с тем сохраняет возможность эффективного управления памятью устройства, состоит в следующем:

1. Загрузите изображение с высоким разрешением в память. Примечание. Если изображение достаточно велико, то такая загрузка на деле может оказаться невозможной; в этом случае должно быть каким-то образом получено изображение с более низким разрешением, причем это может делаться даже на стадии получения самого изображения. Изображение с более низким разрешением может храниться вместе с полномасштабным изображением.

2. Сразу же создайте в памяти копию изображения, уменьшенного до размеров, с использованием которых оно будет отображаться на экране. Благодаря этому количество пикселей в битовом образе изображения, хранящемся в памяти, значительно уменьшится.

3. При первой же возможности удалите исходное изображение, имеющее высокое разрешение, и освободите занимаемую им память.

Если предоставляемый вашей средой выполнения каркас приложения поддерживает сохранение изображений, то может оказаться целесообразным сохранить и кэшировать уменьшенное изображение для последующего использования, чтобы вашему приложению не пришлось сталкиваться с проблемами вре´менных всплесков используемых объемов памяти и процессорного времени в связи с загрузкой большого изображения. Очень важно свести объем памяти, постоянно используемой вашим приложением, к минимуму, а это означает, что не следует хранить в памяти дополнительные пиксельные данные, которые вы не сможете отобразить. При работе с цифровыми фотографиями это позволит сэкономить мегабайты памяти программы и в случае мобильных устройств заметным образом положительно скажется на производительности вашего приложения.

Различные подходы к реализации пользовательских интерфейсов в управляемых средах выполнения

Существуют два способа интеграции управляемой среды выполнения с графикой и моделью пользовательского интерфейса хоста. Среда выполнения может использовать готовые библиотеки элементов пользовательского интерфейса, поддерживаемые операционной системой, или же привлечь для выполнения этой работы собственные библиотеки.

.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 переносится на другую платформу (в процессе ее проектирования такая возможность заранее предполагалась), то она должна будет либо использовать возможности пользовательского интерфейса базовой операционной системы, либо предоставить свою реализацию этих элементов управления в виде библиотек на основе собственного или управляемого кода. По своим возможностям встроенной поддержки элементов управления пользовательского интерфейса операционные системы различных устройств существенно отличаются друг от друга, так что объем работы, которую при этом придется выполнить, и выбор стратегии проектирования оказываются в высшей степени зависящими от характеристик конкретной целевой операционной системы.

Стратегии проектирования высокопроизводительного графического кода

Код, предназначенный для обработки графики, целесообразно рассматривать отдельно от кода высокоуровневого пользовательского интерфейса. Обычно в коде пользовательского интерфейса используются высокоуровневые абстракции, предлагаемые операционной системой или средой программирования. Примерами подобных абстракций могут служить такие понятия, как элементы управления Button, ListBox, ListView, Panel или Grid. На самом нижнем уровне элементы управления реализуются в виде последовательностей инструкций рисования и низкоуровневого взаимодействия с операционной системой и пользователями. Разработчикам приложений почти никогда не приходится иметь дело с элементами управления на этом самом низком уровне абстракции. Обычно, используя элементы управления пользовательского интерфейса, разработчик полагается на уже организованное для него оптимизированное выполнение базовых операций, связанных с рисованием и поддержкой элементов управления; задача разработчика заключается лишь в том, чтобы наиболее эффективным способом использовать эти элементы управления на более высоком уровне абстракции. В отличие от этого, при работе с графикой разработчик должен специально продумать, как должны решаться низкоуровневые задачи рисования и каким образом можно обеспечить их наиболее эффективное выполнение.

С позиций абстрагирования код высокоуровневого пользовательского интерфейса аналогичен организации связи в сети с использованием запросов и ответов по протоколу HTTP; в то же время, графический код аналогичен организации связи на уровне сокетов или же пакетов. Как и в случае сетевых коммуникаций, во всех возможных случаях лучше использовать высокоуровневые абстракции. Высокоуровневые абстракции легко использовать, они эффективны для большинства задач и надежно протестированы. Эффективная работа с низкоуровневыми программными средствами, например, графическими библиотеками, требует более глубокого понимания того, что при этом происходит, и соответствующего активного вмешательства в ход событий, и должна сопровождаться тщательным анализом того, какую пользу с точки зрения эффективности это может принести приложению. Графический код выглядит и работает иначе, чем код пользовательского интерфейса.

Поскольку конечной целью всей низкоуровневой работы с графикой является предоставление отдельных частей многофункционального пользовательского интерфейса, между низкоуровневым графическим кодом и кодом пользовательского интерфейса в какой-то точке должно быть налажено взаимодействие. Можно почти не сомневаться, что создаваемая вами графика будет сосуществовать с такими высокоуровневыми компонентами пользовательского интерфейса, как элементы управления Button, Menu или ListView. Управление всем пользовательским интерфейсом посредством только низкоуровневого графического кода может быть оправданным лишь в самых редких случаях по той простой причине, что приложение ничего не выиграет, если будет самостоятельно прорисовывать элементы управления и обрабатывать низкоуровневое взаимодействие с пользователем. Вместо этого следует прибегать к гораздо более эффективному подходу, в соответствии с которым разработчики используют для обслуживания пользовательского интерфейса готовые библиотеки проверенных на практике функций и привлекают графические функции для управления лишь теми элементами пользовательского интерфейса, которые испытывают в этом крайнюю необходимость. Для этого следует использовать тщательно продуманные модели, описывающие, каким образом код высокоуровневого пользовательского интерфейса и низкоуровневый графический код должны сочетаться друг с другом.

Четырехминутный практикум по работе с графикой в .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().

Способы интеграции графики с кодом пользовательского интерфейса

Существует несколько способов интеграции низкоуровневого графического кода с высокоуровневым кодом пользовательского интерфейса. Очень важно выбрать такой способ, который лучше всего соответствует характеру задач, стоящих перед вашим приложением. Тремя наиболее распространенными способами сопряжения кодов графики и пользовательского интерфейса являются следующие:

1. Отображение растровых изображений в элементе управления PictureBox.

2. Рисование непосредственно в форме.

3. Реализация пользовательских элементов управления.

Перечисленные способы описываются ниже с использованием иллюстративных примеров их применения.

Отображение растровых изображений в элементе управления PictureBox

Рисование графики на внеэкранных битовых картах и отображение полученных битовых образов в элементе PictureBox на форме является самым простым и наиболее мощным способом работы с пользовательской графикой. В силу своей простоты такой подход великолепно подходит для работы почти с любыми видами деловой графики и даже для многих игр.

Чтобы использовать этот подход, вашему приложению достаточно создать объект Bitmap и соответствующий ему объект Graphics, а затем использовать этот объект Graphics для рисования всего, что необходимо, на битовой карте, прежде чем назначить ее свойству Image элемента управления PictureBox. Элемент управления PictureBox позаботится обо всем остальном. Он проверяет, обновлено ли изображение на экране, и при необходимости перерисовывает его; если элемент управления PictureBox временно перекрывался, частично или полностью, другим элементом управления или окном, PictureBox самостоятельно перерисует его, когда он вновь окажется открытым. PictureBox осуществляет проверку того, что выводимое изображение идентично тому, которое хранится в битовой карте; предусматривать в приложении какую-либо дополнительную логику для этого не требуется.

В силу своей простоты такая методика прекрасно подходит для отображения графических данных, которые не претерпевают ежесекундных изменений. Он также обеспечивает достаточную эффективность, поскольку элементу управления PictureBox известно, когда он должен сам себя перерисовать. Элементы управления PictureBox могут предоставлять также некоторые события (например, Click), к которым ваше приложение может подключаться, что позволяет наделять их некоторой дополнительной интерактивностью, что делает этот подход еще более полезным

На рис. 11.5 представлено приложение, в котором имеются элементы управления Button и PictureBox. В результате нажатия кнопки Button создается внеэкранная битовая карта, на ней рисуется эллипс и некоторый текст к нему, после чего эта карта назначается элементу управления PictureBox. В листинге 11.6 приведен выполняющий описанные операции рисования код, который необходимо вставить в код обработчика события щелчка на кнопке. Для создания и запуска данного приложения необходимо выполнить следующие действия:

Рис. 11.5. Рисование на внеэкранной битовой карте и передача ее в элемент управления PiсtureBох

1. Начните новый проект Smart Device в Visual Studio .NET и выберите в качестве целевой платформы Pocket PC.

2. Добавьте в форму Form в окне конструктора форм элементы управления PictureBox и Button.

3. Дважды щелкните на кнопке Button1 в окне конструктора форм; в результате этого будет создан и подключен к кнопке приведенный ниже обработчик событий button1_Click. Введите приведенный в листинге 11.6 код, который реагирует на это событие.

4. Скомпилируйте пример и запустите его на выполнение. Щелкните на кнопке Button1.

С применения подхода, основанного на элементе управления PictureBox, рекомендуется начинать в тех случаях, когда существует необходимость в отображении графических данных. Если такой подход в состоянии удовлетворить нужды вашего приложения — отлично! Пытаться использовать другие, более сложные подходы имеет смысл лишь в тех случаях, когда только что описанный подход вас не устраивает.

Листинг 11.6. Создание изображения на внеэкранной растровой поверхности и передача его в элемент управления PictureBox

//--------------------------------------------------------------------

//Создать рисунок на растровой поверхности. Переслать его в PictureBox

//--------------------------------------------------------------------

private void button1_Click(object sender, System.EventArgs e) {

//Создать новую битовую карту

System.Drawing.Bitmap myBitmap;

myBitmap = new System.Drawing.Bitmap(pictureBox1.Width, pictureBox1.Height);

//--------------------------------------------------------------------------

//Создать объект Graphics, чтобы иметь возможность рисовать на битовой карте

//--------------------------------------------------------------------------

System.Drawing.Graphics myGfx;

myGfx = System.Drawing.Graphics.FromImage(myBitmap);

//Закрасить нашу битовую карту желтым цветом

myGfx.Clear(System.Drawing.Color.Yellow);

//Создать перо

System.Drawing.Pen myPen;

myPen = new System.Drawing.Pen(System.Drawing.Color.Blue);

//-----------------

//Нарисовать эллипс

//-----------------

myGfx.DrawEllipse(myPen, 0, 0, myBitmap.Width - 1, myBitmap.Height -1);

//Создать сплошную кисть

System.Drawing.Brush myBrush;

//-----------------------

//Нарисовать текст кистью

//-----------------------

myBrush = new System.Drawing.SolidBrush(System.Drawing.Color.Black);

//Примечание: Мы используем объект Font из формы

myGfx.DrawString("Hello!",this.Font, myBrush, 2, 10);

//------------------------------

//Важно! Очистить все после себя

//------------------------------

myGfx.Dispose();

myPen.Dispose();

myBrush.Dispose();

//-------------------------------------------------------------------

//Указать объекту pictureBox, на необходимость отображения растрового

//изображения, которое мы только что создали и нарисовали.

//-------------------------------------------------------------------

pictureBox1.Image = myBitmap;

}

Рисование непосредственно в форме

Для рисования в форме существует два способа:

1. Создайте объект Graphics для формы и используйте этот объект для создания нужных рисунков.

2. Подключитесь к функции OnPaint() для формы и получите объект Graphics, который можно будет использовать для рисования.

Создание объекта Graphics для формы и рисование на нем обычно применяются лишь изредка, поскольку в этом случае любой созданный вами рисунок не существует постоянно. Форма с удовольствием предоставит вашему приложению свою поверхность для рисования всего, что вам заблагорассудится, но не будет запоминать нарисованное. Это означает, что если форма по какой-либо причине будет перерисована, то все, что нарисовал ваш код, исчезнет. Поэтому данный метод не годится для графики, которую вы хотите сохранять на экране в течение длительных периодов времени. Так, описанный способ плохо подходит для вычерчивания диаграмм, которые пользователь будет просматривать на своем мобильном устройстве, поскольку ваше приложение не в состоянии контролировать, когда именно отображаемая картинка будет частично или полностью перекрыта другим изображением. Вместе с тем, данный метод может оказаться полезным в тех случаях, когда все экранное изображение все время полностью перерисовывается, как это происходит, например, в играх. Если изображение перерисовывается несколько раз в секунду, то не имеет никакого значения, является ли оно постоянно существующим или нет.

Эта методика рисования проиллюстрирована в листинге 11.7. Для создания и запуска данного приложения необходимо выполнить следующие действия:

1. Начните новый проект Smart Device в Visual Studio .NET и выберите в качестве целевой платформы Pocket PC.

2. Добавьте в форму Form кнопку Button.

3. Дважды щелкните на кнопке Button1 в окне конструктора форм; в результате этого будет создан и подключен к кнопке приведенный ниже обработчик событий button1_Click. Введите приведенный в листинге 11.7 код, который реагирует на это событие.

4. Скомпилируйте пример и запустите его на выполнение. Щелкните на кнопке Button1.

Листинг 11.7. Создание объекта Graphics для формы

//----------------------------------------------------------

//Создает объект Graphics для формы и осуществляет рисование

//----------------------------------------------------------

private void button1_Click(object sender, System.EventArgs e) {

//Создать объект Graphics для формы

System.Drawing.Graphics myGfx;

myGfx = this.CreateGraphics();

//Создать кисть

System.Drawing.Brush myBrush;

myBrush = new System.Drawing.SolidBrush(System.Drawing.Color.DarkGreen);

//Заполнить прямоугольник

myGfx.FillRectangle(myBrush, 4, 2, 60, 20);

//-------------------------

//Важно: Выполнить очистку!

//-------------------------

myBrush.Dispose();

myGfx.Dispose();

}

Подключение к запросам Paint для формы обеспечивает возможность принять активное участие в работе низкоуровневого механизма перерисовки данной формы. Когда операционной системе необходимо содействие в восстановлении внешнего вида пользовательского интерфейса, она требует, чтобы окна и элементы управления были перерисованы. В данном случае операционную систему можно уподобить хранителю музея, который осматривает каждое произведение искусства, созданное вашим приложением.

Простое поддержание экспонатов в нормальном состоянии он может обеспечивать самостоятельно, но в более сложных случаях, когда требуется вернуть картинам их первоначальный вид, он вынужден приглашать художников-специалистов. Решение о том, когда именно ваше приложение должно перерисовать элементы своего интерфейса, принимает операционная система; вместе с тем, вы можете обратить внимание операционной системы на тот факт, что форма или элемент управления нуждаются в перерисовке, вызвав функцию Invalidate().

Функции перерисовки вызываются операционной системой тогда, когда ваше приложение нуждается в "ретушировании". Если у вас имеется более или менее статическое графическое изображение, которое вы хотите перерисовывать только тогда, когда в этом возникает необходимость, то это очень удобно реализовать, подключаясь к функции Paint. В то же время, вы должны проанализировать, не удастся ли вам решить те же задачи, используя элемент управления PictureBox; в этом случае вам вообще не приходится иметь дело с какими бы то ни было низкоуровневыми запросами перерисовки.

В листинге 11.8 приведен пример реализации функции перерисовки экрана, которая при поступлении запроса на перерисовку формы рисует прямоугольник и фрагмент текста. Эту функцию следует поместить в код формы. Выполните следующие три эксперимента с использованием этого кода, которые помогут вам лучше понять, как и когда именно функция рисования вызывается операционной системой:

■ Поместите на форму кнопку, которая выполняет вызов this.Update(). Заметьте, что, как правило, это не приводит к немедленному вызову функции OnPaint. Вызов Update() лишь требует, чтобы форма или элемент управления перерисовывались, если имеются области, ставшие недействительными.

■ Поместите не форму кнопку, которая выполняет вызов this.Invalidate(). В результате этого вызова запросы OnPaint перемещаются в начало очереди и обрабатываются сразу же. как только у операционной системы появляется такая возможность, что обычно наступает очень быстро. Выполнение один за другим вызовов this.Invalidate(); this.Update(); приводит к немедленной перерисовке формы.

■ Поместите на форму кнопку, которая отображает элемент управления MessageBox. Начните перемещать окно сообщений (MessageBox) в разные места формы, наблюдая за тем, когда именно инициируются вызовы OnPaint(). В ходе моих экспериментов помещение элемента управления MessageBox над цветным прямоугольником не приводило к вызову OnPaint() (вероятно, в этом случае операционная система сама заботилась о перерисовке формы, не нуждаясь в помощи со стороны приложения), однако такой вызов осуществлялся, когда окно сообщений помещалось над текстом. Таким образом, можно сделать вывод, что операционная система иногда способна самостоятельно выполнять для вас элементарную перерисовку экрана, не нуждаясь в вызовах OnPaint().

Ключевым обстоятельством, которое должно быть вам абсолютно понятным, если вы используете подключение к функциям Paint, является то, что вы не в состоянии контролировать, когда именно будут вызываться эти функции. Вы можете сделать это принудительно, объявив область экрана недействительной, но не имеете никакой возможности контролировать внешние факторы, которые могут инициировать запросы перерисовки экрана. Поэтому крайне важно, чтобы операции перерисовки осуществлялись как можно быстрее и с малыми накладными расходами. Если перерисовка экрана осуществляется очень медленно, то будет создаваться впечатление, что ваше приложение работает в замедленном режиме.

Листинг 11.8. Подключение к функции Paint формы

//Кисти, которые мы хотим кэшировать, чтобы избавить себя

//от необходимости все время создавать их и уничтожать

System.Drawing.Brush m_brushBlue;

System.Drawing.Brush m_brushYellow;

//Ради интереса подсчитаем, сколько раз осуществлялся вызов

int m_paintCount;

//-----------------------------------------------------------------------------

//Мы перекрываем обработчики событий Paint наших базовых классов. Это означает,

//что каждый раз, когда форма вызывается для перерисовки самой себя, будет

//вызываться эта функция.

//-----------------------------------------------------------------------------

protected override void OnPaint(PaintEventArgs e) {

//ВАЖНО: Вызвать базовый класс и дать ему возможность

//выполнить всю необходимую работу по рисованию

base.OnPaint(e);

//Увеличить на 1 значение счетчика вызовов

m_paintCount = m_paintCount + 1;

//------------------------------------------------------------------------

//Важно:

//Вместо того чтобы создавать объект Graphics, мы получаем его на время

//данного вызова. Это означает, что освобождать память путем вызова

//метода .Dispose() объекта - не наша забота

//------------------------------------------------------------------------

System.Drawing.Graphics myGfx;

myGfx = e.Graphics;

//-------------------------------------------------------------------

//Поскольку эту операцию рисования необходимо выполнить быстро,

//кэшируем кисти, чтобы избавить себя от необходимости создавать их и

//уничтожать при каждом вызове

//-------------------------------------------------------------------

if (m_brushBlue == null) {

m_brushBlue = new System.Drawing.SolidBrush(System.Drawing.Color.Blue);

}

if (m_brushYellow == null) {

m_brushYellow = new System.Drawing.SolidBrush(System.Drawing.Color.Yellow);

}

//-------------------

//Выполнить рисование

//-------------------

myGfx.FillRectangle(m_brushBlue, 2, 2, 100, 100);

myGfx.DrawString("PaintCount: " + m_paintCount.ToString(), this.Font, mbrushYellow, 3, 3);

//Выход: Объекты, для которых мы должны были бы вызывать метод

//.Dispose(), отсутствуют.

}

Обработчики событий или перекрытые функции?

Существует еще один способ подключения к запросам 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), я предпочитаю прибегать к подходу, основанному на использовании обработчиков событий, поскольку этот код автоматически генерируется для меня после двойного щелчка на элементе управления в окне конструктора форм.

Реализация пользовательских элементов управления

Инкапсуляция графического кода в пользовательских элементах управления является неплохим способом упаковки графических функциональных возможностей, который обеспечивает повторное использование графики. Реализация таких пользовательских элементов управления весьма напоминает перекрытие функции Paint формы. Этот низкоуровневый подход предназначен для визуализации и поддержки отдельных компонентов пользовательского интерфейса вручную.

Пользовательские элементы управления оказываются полезными в тех случаях, когда вы хотите расширить интерактивность рабочей среды пользователей, имеющих дело с графическими данными. Если нужна диаграмма, которая динамически изменяется и обновляется при выполнении пользователем щелчков на различных ее участках, или сетка, пересчитывающая данные в процессе работы с ними пользователя, то наилучшим решением может быть пользовательский элемент управления. Если все, что вам надо, — это вывод графических данных, которые пользователь будет только просматривать в режиме чтения, то создание пользовательского элемента управления является излишним усложнением. Как и в случае продемонстрированного выше подключения к функции OnPaint(), прежде чем окунаться в реализацию низкоуровневого пользовательского элемента управления, имеет смысл проанализировать, нельзя ли просто обойтись использованием элемента управления PictureBox. Если перед вами стоит задача создания диаграмм с привлекательным внешним видом, которые будут использоваться только в режиме чтения, то вам вполне хватит элемента PictureBox. Если впоследствии вы решите, что приложение действительно нуждается в интерактивном пользовательском элементе управления, то хорошей стартовой площадкой для этого вам послужит тот же класс, который вы использовали для создания статического изображения диаграммы. Начинайте с самого простого и переходите к низкоуровневым парадигмам лишь тогда, когда высокоуровневые парадигмы не могут обеспечить то, что вам необходимо. Используя такой подход, вы сделаете работу быстрее и без той головной боли, которая всегда сопровождает отладку низкоуровневого кода.

Для создания пользовательских элементов управления бывают веские причины, основной из которых является интерактивность. Для большинства элементов управления предусмотрено событие Click, которое позволяет известить приложение о том, что на элементе управления был выполнен щелчок.

В случае гистограмм для разработчика приложения может оказаться желательным знать не только о самом факте щелчка на гистограмме, но и о том, какой именно из столбцов был выделен пользователем. С этой целью пользовательский элемент управления мог бы предусмотреть событие ColumnClick, которое запускается всякий раз, когда щелчок выполняется на связанном с этим элементом столбце. Это событие может предоставлять разработчику конкретную информацию о столбце гистограммы, на котором был выполнен щелчок, в соответствии с чем и будет работать код, отвечающий на это событие. Этот элемент управления может также обеспечивать обратную связь с пользователем устройства, например, путем подсветки выделенного столбца, извещающей пользователя о том, что его выбор воспринят.

Пользовательские элементы управления являются мощной абстракцией, которую вы можете использовать в своих приложениях, но важно не пытаться применять их искусственно, без всякой на то необходимости. Если требуется обеспечить высокую степень интерактивности при взаимодействии конечного пользователя с приложением и/или для разработчика важно иметь возможность работать с детализированными событиями, то решение, основанное на пользовательских элементах управления, заслуживает рассмотрения. В листингах 11.9 и 11.10 представлена очень простая реализация пользовательского элемента управления в .NET Compact Framework. В листинге 11.9 содержится код, предназначенный для самого элемента управления, тогда как в листинге 11.10 — код, который используется для динамического создания экземпляра элемента управления, помещения его в форму и подключения к нему обработчика события. На рис. 11.6 показано выполняющееся на устройстве Pocket PC приложение, в котором присутствует данный нестандартный элемент управления.

НА ЗАМЕТКУ

Существует возможность сделать пользовательский элемент управления видимым на стадии проектирования!

В данном примере пользовательский элемент управления для простоты создается во время выполнения. Чтобы отобразить его для разработчика на стадии проектирования, в результате чего этот элемент управления будет виден в окне конструктора форм подобно любому другому стандартному элементу управления, в приложение следует кое-что добавить. Обсуждение этого вопроса выходит за рамки данной книги, однако соответствующая информация содержится в документации по .NET Compact Framework.Окно сообщения, появляющееся в ответ на запуск события щелчка на пользовательском элементе управления

Рис. 11.6. Окно сообщения, появляющееся в ответ на запуск события щелчка на пользовательском элементе управления

Для создания и запуска данного приложения потребуется выполнить следующие действия:

1. Начните новый проект Smart Device в Visual Studio NET и выберите в качестве целевой платформы Pocket PC.

2. Добавьте в проект новый класс и назовите его myButton. Перейдя в окно редактора кода класса введите код, представленный в листинге 11.9.

3. Перейдите в окно конструктора форм для формы Form1. Добавьте в форму кнопку. Дважды щелкните на кнопке для перехода в окно редактора кода и введите код, представленный в обработчике события button1_Click в листинге 11.10.

4. Введите за кодом обработчика события button1_Click оставшуюся часть кода, представленного в листинге 11.10.

5. Скомпилируйте пример и запустите его на выполнение. Щелкните на кнопке Button1.

Листинг 11.9. Простой пользовательский элемент управления, который изменяет цвета и запускает событие, определяемое пользователем

//Простейший пользовательский элемент управления

public class myButton : System.Windows.Forms.Control {

//--------------------------------------

//Объекты, необходимые нам для рисования

//--------------------------------------

System.Drawing.Brush m_RectangleBrush;

System.Drawing.Brush m_TextBrush;

System.Drawing.Color m_RectangleColor;

//----------------------------------------------------

//Событие, которое мы хотим предоставить на обработку.

//Это - общедоступный делегат.

//----------------------------------------------------

public event System.EventHandler EventButtonTurningBlue;

//Конструктор

public myButton() : base() {

//ПРИМЕЧАНИЕ: Мы должны написать функцию Dispose() и

//деструктор, который освобождает память от этих объектов

//Создать необходимые кисти

m_RectangleColor = System.Drawing.Color.Black;

m_RectangleBrush = new System.Drawing.SolidBrush(m_RectangleColor);

m_TextBrush = new System.Drawing.SolidBrush(System.Drawing.Color.White);

}

//-----------------------------------------------

//Внутренним откликом на щелчок является

//повторение трех различных цветов кнопки в цикле

//-----------------------------------------------

protected override void OnClick(System.EventArgs e) {

//--------------------------------------------------------

//Важно: Вызвать базовую реализацию. Это

//обеспечит возможность вызова любого обработчика событий,

//подключенного к данному элементу управления

//--------------------------------------------------------

base.OnClick(e);

//------------------------------------------------------

//Выбрать цвет новой кисти, исходя из цвета старой кисти

//------------------------------------------------------

if (m_RectangleColor == System.Drawing.Color.Black) {

m_RectangleColor = System.Drawing.Color.Blue;

//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

//Запустить событие                                   !

//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

if (EventButtonTurningBlue!= null) {

//Возбудить событие без передачи аргумента

EventButtonTurningBlue(this, null);

}

}

else

if (m_RectangleColor == System.Drawing.Color.Blue) m_RectangleColor = System.Drawing.Color.Red;

else m_RectangleColor = System.Drawing.Color.Black;

//-----------------------

//Освободить старую кисть

//-----------------------

m_RectangleBrush.Dispose();

//----------------------------------------------------------------

//Создать новую кисть, которую мы собираемся использовать для фона

//----------------------------------------------------------------

m_RectangleBrush = new System.Drawing.SolidBrush(m_RectangleColor);

//------------------------------------------------------------

//Сообщить операционной системе, что наш элемент управления

//должен быть перерисован, как только представится возможность

//------------------------------------------------------------

this.Invalidate();

}

//----------------------------------------------------------------

//Ради интереса подсчитаем, сколько раз осуществлялась перерисовка

//----------------------------------------------------------------

int m_paintCount;

protected override void OnPaint(System.Windows.Forms.PaintEventArgs e) {

//--------------------------------------------

//ВАЖНО: Вызвать базовый класс и позволить ему

//выполнить работу по рисованию

//--------------------------------------------

base.OnPaint(e);

//Увеличить на единицу значение счетчика вызовов

m_paintCount = m_paintCount + 1;

//-------------------------------------------------------------------

//Важно:

//Вместо того чтобы создавать объект Graphics, мы получаем его

//на время данного вызова. Это означает, что освобождать память путем

//вызова метода .Dispose() объекта - не наша забота

//-------------------------------------------------------------------

System.Drawing.Graphics myGfx;

myGfx = e.Graphics;

//Нарисовать прямоугольник

myGfx.FillRectangle(m_RectangleBrush, 0, 0, this.Width,this.Height);

//Нарисовать текст

myGfx.DrawString("Button! Paint: " + m_paintCount.ToString(), this.Parent.Font, m_TextBrush, 0, 0);

} //конец функции

} //конец класса

Листинг 11.10. Код, который должен быть помещен в форму для создания экземпляра пользовательского элемента управления

//--------------------------------------------------------------

//Этот код будет подключен в качестве нашего обработчика событий

//--------------------------------------------------------------

private void CallWhenButtonTurningBlue(object sender, System.EventArgs e) {

System.Windows.Forms.MessageBox.Show("Button is about to turn blue!");

}

//Наша новая кнопка

myButton m_newControl;

//----------------------------------------------

//Эта функция подключается для обработки событий

//щелчка на кнопке Button1

//----------------------------------------------

private void button1_Click(object sender, System.EventArgs e) {

//----------------------------------------------

//Для простоты мы допускаем существование только

//одного экземпляра элемента управления.

//----------------------------------------------

if (m_newControl != null) {

return;

}

//Создать экземпляр нашей кнопки

m_newControl = new myButton();

//Указать ему его местоположение внутри родительского объекта

m_newControl.Bounds = new Rectangle(10, 10, 150, 40);

//-------------------------------

//Присоединить обработчик событий

//-------------------------------

m_newControl.EventButtonTurningBlue += new System.EventHandler(this.CallWhenButtonTurningBlue);

//Добавить его в список элементов управления данной формы.

//Это сделает его видимым

this.Controls.Add(m_newControl);

}

Где рисовать — на экране или вне экрана?

Создание привлекательной графики — в равной степени и искусство, и ремесло; под этим подразумевается, что одинаково важная роль принадлежит как используемым методикам, так и планированию. Для того чтобы нарисовать на экране одиночный прямоугольник или одиночный фрагмент текста, требуется очень мало времени. Рисование же сложной диаграммы или игрового поля на лету в видимой области экрана, скорее всего, заставят пользователя дожидаться появления результатов в течение некоторого времени. Рассмотрим случай сложной диаграммы, на рисование которой уходит 1,5 секунды. Эта длительность заметно превышает порог человеческого восприятия, и глаз человека в состоянии различить довольно много событий, которые могут произойти на протяжении такого временного промежутка. Если рисование диаграммы состоит из стадий рисования фонового изображения, вычерчивания и сопровождения надписями осей диаграммы, размещения точек, соответствующих фактическим данным, и генерации таблицы ключей, в которой каждый набор данных идентифицируется определенным цветом, то процесс построения диаграммы, происходящий на глазах у пользователя, будет представлять собой весьма неприглядную картину. Результат будет еще более плачевным, если получаемая графика предназначена для динамической игры; в этом случае пользователь столкнется с мерцанием экрана, сопровождающим перерисовку элементов игры при их перемещениях на экране.

Другая причина, по которой не рекомендуется делать процесс рисования видимым для пользователя, заключается в том, что область растровых изображений пользовательского интерфейса обычно не является постоянной. В отличие от внеэкранных битовых карт, принадлежащих вашему коду, экран является разделяемым ресурсом, который совместно используется окнами и элементами управления всех выполняющихся приложений, а также операционной системой. Большинством операционных систем поддержка изображений, которые пользователь может рисовать на поверхности пользовательского интерфейса, не предусматривается. Это означает, что любые изображения, созданные вами в области пользовательского интерфейса, будут утеряны, если окно, в котором ваш код выполнял рисование, будет перекрыто окном другого приложения.

Гораздо менее уязвимым с точки зрения эстетики процесса рисования и подверженности ошибкам является рисование на внеэкранном буфере с последующим копированием результатов на передний план после того, как создание рисунка будет завершено. Кроме того, решения этого типа отличаются лучшей переносимостью, их проще проектировать, сопровождать и отлаживать. Вместо того чтобы погружаться во все тонкости модели рисования, используемой операционной системой, вы можете организовать все так, что изображение будет в максимально возможной степени при надлежать вашему приложению, выполняющему операции рисования в собственном строго определенном окружении и взаимодействующему непосредственно с пользовательским интерфейсом лишь тогда, когда эта работа будет закончена. Подход, основанный на использовании внеэкранных буферов для объектов рисования, почти всегда является наиболее оптимальным для выполнения графических операций любой степени сложности, даже если при этом вам и придется использовать вывод курсора ожидания на период визуализации изображения.

Как уже обсуждалось в предыдущих разделах, в .NET Compact Framework имеются два неплохих способа переноса внеэкранных рисунков в пользовательский интерфейс. Во-первых, это использование элемента управления PictureBox и задание посредством его свойства Image того битового образа, рисование которого вы только что завершили (например, pictureBox1.Image = myNewBitmap).

Второй способ заключается в получении объекта Graphics для того элемента интерфейса, в котором он будет прорисовываться (обычно таковым является объект Form) и вызове метода Graphics.DrawImage() для переноса изображения:

//Получить объект Graphics для формы

System.Drawing.Graphics gfx;

gfx = this.CreateGraphics();

//Нарисовать изображение в объекте с использованием

//начальной точки с координатами x=10, y=15);

gfx.DrawImage(myBitmap, 10, 15);

Следует подчеркнуть, что для метода Graphics.DrawImage() предусмотрено несколько перегруженных версий. Та, которая фигурировала выше, является самой простой и работает быстрее остальных; она просто копирует биты из одного битового образа в другой. Другие перегруженные версии обладают более развитыми возможностями, что позволяет им выполнять такие, например, операции, как перенос в целевое изображение строго определенной области исходного изображения, растягивание или сжатие копируемых изображений или использование масок прозрачности, позволяющих делать прозрачными отдельные области изображения, через которые могут "просматриваться'' другие изображения. Каждая из этих разновидностей метода выполняет определенное преобразование при копировании изображения из объекта-источника в объект назначения. В общем случае, чем сложнее преобразование изображения, которое требует выполнить ваш код, тем дороже оно обходится с точки зрения производительности.

Для поддержания производительности приложения на приемлемом уровне лучше всего стремиться к тому, чтобы исходное и целевое растровые изображения в максимальной степени совпадали друг с другом. По возможности стремитесь к тому, чтобы при переносе изображений создавались их точные битовые копии, а пиксели не растягивались и не сжимались. Маски прозрачности следует использовать лишь тогда, когда в этом есть необходимость. Хотя к .NET Compact Framework это и не относится, но другие среды выполнения могут предлагать вам выбрать количество цветов, которые должны использоваться в изображении, и указать битовую глубину цвета, используемую для поддержания этой информации. Совпадение этой информации для исходного и целевого изображений способно существенно улучшить производительность. Общая задача заключается в сведении к минимуму любых расхождений между исходным и конечным изображениями, чтобы операция переноса изображения была максимально приближена к операции простого копирования битов в память. Оптимизация таких операций для достижения высокой производительности обычно обеспечивается на всех платформах.

Определите собственный процесс визуализации

Нетривиальным рисункам свойственна сложная структура. Сначала создают прототип, позволяющий строить диаграммы. В этот прототип добавляются средства, позволяющие не только строить диаграммы, но и снабжать надписями оси. Далее добавляются метки делений, позволяющие задавать, где располагаются точки данных и соединяющие их линии. Затем добавляется поддержка одновременного отображения нескольких наборов данных. После этого добавляется таблица цветовых ключей, идентифицирующих различные наборы данных. Далее добавляется поддержка нескольких цветов. Затем добавляется возможность рисования изображений поверх фонового изображения. Наконец, добавляется возможность присвоения диаграммам названий. Код, предназначенный для построения диаграмм, совершенно неожиданно для вас разрастается до огромных размеров, причем каждая отдельная его часть предусматривает выполнение узкоспециализированной задачи, рассматриваемой в отрыве от контекста обеспечения высокой производительности приложения в целом. Тем же недостатком "нашествия возможностей" страдает и код игр, когда в список того, что должно быть сделано для визуализации игрового поля, постоянно добавляются все новые и новые члены.

В силу указанных причин очень важно не пожалеть времени и постараться рационализировать используемый вами процесс визуализации. Тем самым вы выжмете из своей системы максимально возможную производительность и приобретете дополнительную гибкость в добавлении новых средств. Эта задача должна быть разбита на этапы, позволяющие анализировать любые изменения, вносимые вами в модель визуализации, и рационализировать их на уровне системы, настроенной на обеспечение максимальной общей производительности. Эта работа не является трудной; для этого требуется только записать, какой ряд последовательных действий необходимо выполнить и какие ресурсы используются на каждом шаге.

Рассмотрим следующий пример.

Не рационализированный процесс построения графиков

1. Создать пустую битовую карту (150×150 пикселей).

2. Скопировать фоновое изображение на пустую битовую карту. (Фоновое изображение имеет размеры 150×150 пикселей, непосредственное копирование.)

3. Вычертить координатные оси. (Создаются и уничтожаются перья Red Pen, Blue Pen и Yellow Pen.)

4. Рассчитать количество делений на каждой из осей.

5. Вычертить все линии делений.

6. Вывести текст для каждого деления. (Создается и уничтожается кисть White Brush, создается и уничтожается шрифт 8 пунктов.)

7. Нарисовать данные для каждого из наборов данных, для которых строятся графики. (Создаются и уничтожаются перья Red Pen, Orange Pen, Yellow Pen и Green Pen.)

8. Нарисовать линии между точками.

9. Вычертить квадраты вокруг каждой точки.

10. Нарисовать название графика. (Создается и уничтожается кисть White Brush.)

11. Нарисовать таблицу цветовых ключей, идентифицирующих наборы данных.

12. Нарисовать рамку. (Создается и уничтожается перо White Pen.)

13. Нарисовать шаблонные линии для каждого набора данных. (Создаются и уничтожаются перья Red Pen, Orange Pen, Yellow Pen и Green Pen.)

14. Нарисовать текстовые подписи для каждого набора данных. (Создаются и уничтожаются кисти Red Brush, Orange Brush, Yellow Brush и Green Brush, создается и уничтожается шрифт 8 пунктов.)

Взглянув на описанную выше модель, можно заметить, что мы много раз создаем и уничтожаем одни и те же перья, кисти и шрифты. Можно без особого труда рационализировать эту модель, избавившись от лишних операций распределения ресурсов.

Рассмотрим более рациональный вариант организации процесса построения графиков.

Создание ресурсов

1. Создать битовую карту (150×150 пикселей), если до этого память для нее не была распределена.

2. Создать необходимые перья: Red Pen, Orange Pen, Yellow Pen, Green Pen и Blue Pen.

3. Создать необходимые кисти: White Brush, Red Brush, Orange Brush, Yellow Brush и Green Brush.

4. Создать необходимые шрифты: шрифт 8 пунктов.

5. Очистить битовую карту.

6. Скопировать фоновое изображение на битовую карту.

7. Вычертить координатные оси.

8. Рассчитать количество делений на каждой из осей.

9. Вычертить все линии делений.

10. Нарисовать текст для каждого деления.

11. Нарисовать данные для каждого из наборов данных, для которых строятся графики.

12. Нарисовать линии между точками.

13. Вычертить квадраты вокруг каждой точки.

14. Нарисовать название графика.

15. Нарисовать таблицу цветовых ключей, идентифицирующих наборы данных.

16. Нарисовать рамку.

17. Нарисовать шаблонные линии для каждого набора данных.

18. Нарисовать текстовые подписи для каждого набора данных.

19. Освободить память, занимаемую перьями, кистями и шрифтами.

Отсрочка — зло, используйте предварительные вычисления

При проектировании высокоуровневого кода пользовательских интерфейсов целесообразно попытаться отложить выполнение некоторых операций на как можно более поздний срок; заполнение элементов управления большими объемами данных, которые, возможно, пользователь никогда не будет просматривать, является бессмысленной тратой процессорного времени. В данном случае стратегия откладывания работы на более поздний срок удачна по той причине, что данные, которыми заполняется интерфейс, являются динамическими, а их возможные объемы часто могут оказываться настолько большими, что заполнять ими интерфейс было бы слишком расточительно. Если же объем информации ограничен и наперед известен, то имеет смысл попытаться заранее вычислить или инициализировать эти данные. Именно с такой ситуацией приходится часто сталкиваться в случае графических данных.

Работа с графикой часто состоит из множества небольших повторяющихся задач, последовательно выполняющихся одна за другой. Если это так, то разумно попытаться использовать заблаговременное вычисление некоторых элементов. Любая задача рисования, которую можно выполнить заранее, сэкономит вам время. Справедливость этого утверждения вдвойне возрастает, если некоторая работа может быть сделана на стадии проектирования, еще до того, как приложение вообще начнет выполняться.

Если такая возможность имеется, исследуйте шаги процесса визуализации изображений и исключите из них те, которые могут быть выполнены до начала его выполнения, и тогда производительность вашего приложения от этого только выиграет.

Чтобы проиллюстрировать это положение рассмотрим два типичных случая.

Пример 1: предварительная визуализация объектов бизнес-диаграммы

На рис. 11.7 приведена довольно красочная картинка, на которой некие (фиктивные) данные отображаются в виде гистограммы. Гистограмма представляет относительные темпы роста экономики различных стран за определенный период времени. Чтобы облегчить визуальное восприятие данных пользователем, было решено представить данные, относящиеся к каждой из стран, в виде столбцов, раскрашенных символами валюты данной страны. Кроме того, для диаграммы предусмотрено фоновое изображение; в данном случае таковым является простой градиентный фоновый цвет, плавно меняющийся от темного к светлому оттенку, но вместо него может быть использовано любое изображение

Приступая к построению гистограммы, мы должны, вероятно, начать с создания пустой битовой карты. Далее на этой карте будут нарисованы фоновый градиент, оси, название гистограммы, метки делений на обеих осях, подписи к делениям и столбцам, добавлен сплошной цвет для каждого столбца гистограммы, на столбцы гистограммы нанесены символы валюты, а поверх них проставлены точные процентные значения. Нарисовать предстоит довольно много. Учитывая тот факт, что суть задачи, заключающаяся в построении гистограммы для отображения экономических показателей для каждой страны, нам известна, мы можем применить ряд оптимизирующих шагов, которые позволят значительно сократить объем работы, которую необходимо выполнить для визуализации гистограммы.

Рис. 11.7. Гистограмма, представляющая темпы роста экономики различных стран

Первое, что мы можем сделать в плане оптимизации, — это определить все то, что будет оставаться неизменным в любой диаграмме, и превратить эти объекты в готовый фон. Сказанное иллюстрируется на рис. 11.8. Мы решили заранее нарисовать на фоновой битовой карте градиентную заливку фоновым цветом, вертикальные и горизонтальные линии и часть названия диаграммы. Было решено не включать в фоновое изображение следующие данные: собственно столбцы гистограммы, названия стран и их позиции на гистограмме, числовые метки для каждого деления на вертикальной шкале, текст над каждым из столбцов гистограммы и заполнение самих столбцов. Все эти объекты должны быть динамически сгенерированы во время выполнения приложения.

Рис. 11.8. Заблаговременно подготовленное фоновое изображение для гистограммы

Теперь нам предстоит принять очень важное решение относительно того, какому варианту отдать предпочтение: однократно прорисовывать фоновый битовый образ при каждом запуске приложения или же создать это изображение на стадии проектирования, скомпилировать в виде ресурса приложения и только загружать его на стадии выполнения. Если такое растровое изображение является статическим или необходимо иметь всего лишь несколько его различных вариантов, то, вероятно, имеет смысл подготовить их на настольном компьютере и включить в приложение как двоичный ресурс. Дополнительным преимуществом проведения такой подготовительной работы на стадии проектирования является то, что мы можем поручить ее профессиональному художнику-графику, который выполнит работу на высоком эстетическом уровне. Как бы то ни было, в любом случае мы сэкономим массу процессорного времени, поскольку каждый раз, когда будет требоваться повторная визуализация диаграммы, мы уже будем располагать ее заблаговременно подготовленной сложной частью, кэшированной для нужд приложения.

Дополнительная оптимизация возможна также на стадии визуализации диаграммы. Исходя из предположения, что отображаемый текст является действительно динамическим, связанные с ним вычисления и перерисовка экрана должны осуществляться средствами графического вывода текста, предоставляемыми каркасом приложения. При этом, однако, все еще остается неразрешенным непростой вопрос о том, каким образом следует визуализировать декорированные столбцы диаграммы.

В соответствии с нашими планами относительно исходного варианта реализации мы могли бы нарисовать прямоугольники для каждого столбца и вывести над каждым из них соответствующий текст, но это было бы нерациональной тратой времени. Существует также проблема визуализации лишь части линий текста. Задача визуализации символов $$$ на 38 процентов высоты или символов €€€ на 76 процентов высоты средствами каркаса приложения может оказаться не столь уж простой. Учитывая сложность реализации этого подхода, от использования символов валюты можно было бы вообще отказаться, но это был бы позорный поступок с нашей стороны, поскольку наличие обозначений валюты на столбцах упрощает установление соответствия между странами и столбцами и поэтому снижает вероятность неправильного истолкования данных пользователем. Поэтому от всех этих "украшений" мы не отказываемся, но и платить за них лишнее не собираемся.

В качестве оптимизации первого порядка мы могли бы создать битовые образы строк символов валюты для каждой страны, то есть растровое изображение 30×10 пикселей для строки $$$ и аналогичные изображения для других видов валют. Вероятно, такие битовые образы можно было бы очень быстро копировать поверх нашего фонового изображения, предусмотрев для этого цикл, который выполнялся бы столько раз, сколько необходимо, с последующим отсечением верхушки символов в соответствующих точках, чтобы обеспечить нужную высоту столбцов. В действительности, мы можем поступить еще лучше. Почему бы не заготовить заранее битовые образы, представляющие для каждой валюты столбцы максимальной высоты? Всего нам нужно четыре таких заготовки: одна для США (US), одна для Японии (Japan), одна для Великобритании (UK) и одна для стран Европейского Союза (EU). Когда нашему приложению необходимо нарисовать любой из этих столбцов, оно просто использует соответствующий битовый образ и копирует его часть на поверхность нашего рисунка. Как и в случае фонового изображения, если имеется возможность создавать изображения на стадии проектирования, то можно прибегнуть к услугам дизайнеров, которые придадут изображениям максимально привлекательный внешний вид. Пример таких заранее заготовленных столбцов представлен на рис. 11.9.

Рис. 11.9. Заранее заготовленные декорированные столбцы гистограмм

Какой дополнительный объем памяти потребуется для реализации такого подхода? Предположим, что максимальная высота столбцов составляет 180 пикселей, а их ширина — 32 пикселя. Пусть, далее, для хранения информации о цвете каждого пикселя требуется 4 байта. Тогда для хранения в памяти битового образа одного столбца диаграммы потребуется 180×32×4 = 23040 байт, или 22,5 Кбайт. В зависимости от ситуации такой объем может быть для нас как приемлемым, так и неприемлемым. Насколько велик этот объем по сравнению с теми объемами памяти, которые требуются для хранения других объектов? Если предположить, что размеры фонового изображения составляют 200×200 пикселей, то для него потребуется 200×200×4 = 156,25 Кбайт памяти.

Для построения окончательного изображения диаграмм нам потребуется еще одна битовая карта такого же размера, на которую будут копироваться графические данные заднего и переднего планов; в результате этого суммарный необходимый объем памяти достигает 312,5 Кбайт, что не так уж мало, но вполне приемлемо для большинства мобильных устройств. Битовые образы всех четырех столбцов суммарно потребуют 22,5×4=90 Кбайт, что значительно меньше того, что требуется для фонового изображения и пустой битовой карты, на которой все наши изображения будут объединены в одно целое. Учитывая тот факт, что, затрачивая 90 Кбайт дополнительной памяти, мы избавляемся от необходимости многократно создавать в памяти копии небольших изображений или каждый раз рисовать текст поверх столбцов, такую оптимизацию, по всей видимости, можно считать эффективной.

Пример 2: предварительная визуализация объектов для сюжетной игры

Любопытно отметить, что оптимизация визуализации изображений для сюжетных игр имеет много общего с оптимизацией этого процесса, которую мы рассмотрели на примере диаграмм. На рис. 11.10 представлено изображение для сюжетной игры, которую я написал для .NET Compact Framework, чтобы продемонстрировать концепции графики.

HA ЗАМЕТКУ

Те, кого интересует исходный текст этого приложения, могут найти его на Web-сайте. Приложение было написано на языке VB.NET и названо "HankTheCaveMan" ("Пещерный человек Хэнк"). Оно позволяет продемонстрировать многие из концепций графики, которые обсуждаются в этой главе. Полный исходный код приложения доступен для загрузки на сайте обмена исходными кодами www.gotdotnet.com вместе с бесчисленным множеством других примеров и информации.

Рис. 11.10. Сюжетная игра, написанная для .NET Compact Framework

Существует три слоя изображений для игр, которые должны визуализироваться на экране:

1. Фоновая картинка. В играх предусматривается статическая фотография, используемая в качестве фонового изображения.

2. Статический передний план. К этой категории относятся изображения, находящиеся на переднем плане, которые не изменяются от кадра к кадру. На нашем игровом поле такими элементами являются настилы и лестницы. Эти изображения являются важными элементами переднего плана и изменяются при переходе с одного уровня игры на другой, но не изменяются при смене кадров при визуализации игры.

3. Динамический передний план. К этой категории относятся активные экранные изображения, которые могут изменяться от кадра к кадру. В нашей игре они представляют пещерного человека, пещерную женщину, два валуна, птицу и четыре факела. Эту разновидность графических элементов обычно называют "спрайтами". Кроме того, к динамическому переднему плану относятся индикатор запаса энергии, который находится в верхней части игрового поля слева, и индикатор Score/Bonus (Счет/Бонус), расположенный в верхней части игрового поля справа. В программе все эти элементы представлены объектами одной коллекции

Циклу визуализации предшествует загрузка фонового изображения и создание на нем рисунка настилов и лестниц. Эти изображения комбинируются в памяти и xpaнятся как наше фоновое изображение. Настилы и лестницы не изменяются при переходе от кадра к кадру, поэтому нет смысла визуализировать их вместе с каждым кадром. Поскольку фоновое изображение уже и так должно загружаться, мы не занимаем лишнюю память, рисуя на нем статическое игровое поле.

В основе механизма визуализации лежат простые принципы. С каждым активным элементом на экране ассоциирован объект, в котором хранится позиция элемента на игровом поле, а также инструкции относительно того, как его визуализировать. В цикле визуализации хранится целевая битовая карта. Она имеет те же размеры, что и фоновое изображение. Объект Graphics для нее создается и сопровождается на протяжении всего времени существования приложения. Все необходимые для рисования шрифты, кисти и перья также хранятся в глобальной области памяти, так что любой нуждающийся в этих объектах код, предназначенный для визуализации изображений, может просто воспользоваться ими, а не распределять для них дополнительную память.

Когда выполняется визуализация кадра, то сначала в целевую битовую карту копируется фоновое изображение. После этого каждому из объектов визуализируемой коллекции направляется запрос на то, чтобы он визуализировал себя на целевой битовой карте. Некоторые из этих объектов являются текстовыми; такие объекты для прорисовки своего текста на целевой битовой карте вызывают метод Graphics.DrawString(). Одним из нетекстовых объектов является "энергетическая шкала", которая состоит из двух прямоугольников — внешней рамки и внутреннего закрашенного прямоугольника. Остальные объекты являются многокадровыми растровыми изображениями, то есть несколько таких изображений представляют различные возможные состояния спрайта; это обеспечивает возможность анимации объектов путем быстрого переключения между их различными изображениями.

С Хэнком (пещерным человеком) ассоциированы 8 изображений; 2 — для бега влево, 2 — для бега вправо, 2 — для подъема и 2 — для спуска. Для каждого спрайта предусмотрена внутренний конечный автомат, который следит за тем, какое изображение должно отображаться в процессе визуализации. Изображения имеют небольшие размеры; размеры изображения Хэнка составляют 21×35 пикселей, или, округляя в большую сторону до ближайшего кратного 4 (чтобы учесть возможное выравнивание границ размещения объектов в памяти), 24×36 = 864 пикселя. Всего для одного изображения требуется 864×4 байт/пиксель, что составляет примерно 3,5 Кбайт. Для загрузки всех 8 изображений Хэнка в память потребуется порядка 28 Кбайт, что вполне приемлемо.

Каждый из этих небольших спрайтов визуализируется с использованием одной и той же маски прозрачности при их копировании на фоновое изображение. Это означает, что один из цветов битового изображения спрайта назначен в качестве прозрачного и позволяет фоновому изображению "проступать" через скопированный на него спрайт. Это работает не так быстро, как непосредственное копирование в память непрозрачных прямоугольных изображений, но результат выглядит гораздо привлекательнее из-за того, что изображение лишается своих прямоугольных очертаний.

Как уже отмечалось, описанная модель визуализации игры имеет много общего с процедурой рисования диаграмм. В данной игре вне цикла визуализации выполняется максимально возможный объем работы. Кроме того, при любой удобной возможности в ней используется предварительное создание изображений. В цикле визуализации выполняются лишь простые операции побитового копирования фонового изображения, а также рисуются несколько небольших спрайтов, частично прозрачных для фона, немного текста и несколько простых прямоугольников. Поскольку в игре не распределяется память и исключены напрасные траты процессорного времени внутри цикла визуализации, все это может происходить очень быстро.

Кэшируйте часто используемые ресурсы

При написании кода для обработки графики часто оказывается так, что приложению необходимо многократно использовать одни и те же ресурсы. К числу распространенных классов, допускающих повторное использование, относятся битовые изображения (Bitmap), перья (Pen), кисти (Brush) и шрифты (Font). Было бы слишком расточительно многократно загружать или создавать одни и те же ресурсы; на повторную загрузку ресурса из хранилища или его повторный запрос у операционной системы затрачивается дополнительное процессорное время. Не меньшим расточительством является и одновременная загрузка эквивалентных ресурсов в память; например, хранить в памяти несколько экземпляров одного и того же битового изображения — напрасная трата ресурсов, если вместо этого можно обойтись совместным использованием единственного экземпляра. Наконец, освобождение памяти, занимаемой ресурсами, также ложится бременем на систему и снижает ее производительность. Чтобы избежать подобного снижения производительности, иногда оказывается полезным применять в приложении глобальный диспетчер ресурсов, который берет на себя все заботы, связанные с загрузкой, кэшированием и удалением часто используемых ресурсов.

В листинге 11.11 представлен пример, демонстрирующий три подхода к загрузке и обслуживанию ресурсов в памяти.

■ Подход 1, основанный на принципе "открытия задвижки " (Litch-based approach). Любой код, которому требуется общий ресурс, обращается к статическому свойству класса GraphicsGlobals для получения его значения. Если ресурс уже загружен, он возвращается запросившему его объекту. Если ресурс еще не был загружен, то он создается, кэшируется и после этого возвращается пользователю. Такой подход обладает двумя преимуществами: 1) запрашивающий объект не должен заботиться ни о каком инициализирующем коде; в результате запроса всегда будет возвращен действительный ресурс, и 2) управляемый ресурс может быть освобожден, если приложение считает, что в течение некоторого времени в нем не будет надобности; при необходимости он будет заново создан в результате следующего запроса. Единственным недостатком такого подхода являются незначительные дополнительные накладные расходы, связанные с необходимостью вызова функции для доступа к свойству всякий раз, когда требуется ресурс; обычно этими накладными расходами можно пренебречь.

■ Подход 2, основанный на групповой обработке ресурсов (batch-based approach). Если некоторые ресурсы используются одинаковым образом и имеют сравнимые времена существования, то они могут быть инициализированы сразу все вместе. Код, в котором должны будут использоваться эти глобальные ресурсы, может непосредственно получить доступ к переменным, но предварительно он должен удостовериться в том, что они уже были инициализированы. Когда приложение перейдет в состояние, в котором эти ресурсы в течение некоторого времени использоваться не будут, эти ресурсы должны быть освобождены, и для них должен быть вызван метод Dispose().

■ Подход 3, основанный на использовании коллекций (collection-based approach). Если некоторые ресурсы всегда используются в виде группы, как, например, в случае битовых изображений, образующих анимационную последовательность, то имеет смысл загружать их вместе и возвращать в виде массива или коллекции ресурсов. Если загрузка ресурсов обходится слишком дорого или требует использования значительных объемов памяти, то может оказаться целесообразным хранить их экземпляры, кэшированные централизованным образом, чтобы исключить повторное создание одних и тех же ресурсов. Как и в рассмотренном выше случае, когда необходимость в этих ресурсах отпадает, их необходимо освобождать и вызывать для них метод Dispose(), следуя предварительно намеченной стратегии

Листинг 11.11. Три полезных способа кэширования графических ресурсов

using System;

using System.Drawing;

internal class GraphicsGlobals {

//==========================================================================

//Подход 1: Создать ресурс по требованию

// и кэшировать его для последующего использования.

//

//Внешний код получает доступ к общедоступным свойствам для их просмотра, но

//сами переменные остаются внутренними переменными класса

//==========================================================================

private static Pen s_bluePen;

public static Pen globalBluePen {

get {

//Если перо еще не было создано

if (s_bluePen == null) {

s_bluePen =new System.Drawing.Pen(System.Drawing.Color.Blue);

}

return s bluePen;

}

} //Конец свойства

//=========================================================

//Подход 2:

//Загрузить глобально и кэшировать все

//используемые объекты Pen, ImageAttribute, Font и Brush.

//

//Внешний код получает доступ ко всем общедоступным членам,

//так что никакие функции доступа не нужны.

//=========================================================

public static Pen g_blackPen;

public static Pen g_whitePen;

public static System.Drawing.Imaging.ImageAttributes g_ImageAttribute;

private static bool s_alreadyInitialized;

public static Font g_boldFont;

public static Font g_smallTextFont;

public static Brush g_greenBrush;

public static Brush g_yellowBrush;

public static Brush g_redBrush;

public static Brush g_blackBrush;

//==============================================================

//Эта функция должна быть вызвана до попыток доступа к любому из

//вышеперечисленных глобальных объектов

//==============================================================

public static void InitializeGlobals() {

if (s_alreadyInitialized == true) {

return;

}

g_blackPen = new System.Drawing.Pen(Color.Black);

g_whitePen = new System.Drawing.Pen(Color.White);

g_ImageAttribute = new  System.Drawing.Imaging.ImageAttributes();

g_ImageAttribute.SetColorKey(Color.White, Color.White);

g_boldFont = new Font(FontFamily.GenericSerif, 10, FontStyle.Bold);

g_smallTextFont = new Font(FontFamily.GenericSansSerif, 8, FontStyle.Regular);

g_blackBrush = new SolidBrush(System.Drawing.Color.Black);

g_greenBrush = new SolidBrush(System.Drawing.Color.LightGreen);

g_yellowBrush = new SolidBrush(System.Drawing.Color.Yellow);

g_redBrush = new SolidBrush(System.Drawing.Color.Red);

s_alreadyInitialized = true;

}

//=========================================================

//Подход 3: Возвратить массив связанных ресурсов.

// Кэшировать ресурсы локально, чтобы при многократных

// запросах не загружались (понапрасну) их дубликаты.

//=========================================================

private static Bitmap m_CaveMan_Bitmap1;

private static Bitmap m_CaveMan_Bitmap2;

private static Bitmap m_CaveMan_Bitmap3;

private static Bitmap m_CaveMan_Bitmap4;

private static System.Collections.ArrayList m_colCaveManBitmaps;

//--------------------------------------------------

//Создать и загрузить массив изображений для спрайта

//--------------------------------------------------

public static System.Collections.ArrayList g_CaveManPictureCollection() {

//Изображения загружаются лишь в том случае, если мы их еще не загрузили

if (m_CaveMan_Bitmap1 == null) {

//-----------------------------------------------------------------

//Загрузить изображения. Эти изображения хранятся в виде

//встроенных ресурсов в нашем двоичном приложении.

//

//Загрузка изображений из внешних файлов осуществляется аналогичным

//образом, но выполнить ее проще (нам достаточно лишь указать

//имя файла в конструкторе растровых изображений).

//------------------------------------------------------------------

//Получить ссылку на нашу двоичную сборку

System.Reflection.Assembly thisAssembly = System.Reflection.Assembly.GetExecutingAssembly();

//Получить имя сборки

System.Reflection.AssemblyName thisAssemblyName = thisAssembly.GetName();

string assemblyName = thisAssemblyName.Name;

//Загрузить изображения в виде двоичных потоков из нашей сборки

m_CaveMan_Bitmap1 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(

assemblyName + ".Hank RightRunl.bmp"));

m_CaveMan_Bitmap2 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(

assemblyName + ".Hank_RightRun2.bmp"));

m_CaveMan_Bitmap3 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(

assemblyName + ".Hank_LeftRun1.bmp"));

m_CaveMan_Bitmap4 = new System.Drawing.Bitmap(

thisAssembly.GetManifestResourceStream(

assemblyName + ".Hank_LeftRun2.bmp"));

//Добавить их в коллекцию

m_colCaveManBitmaps = new System.Collections.ArrayList();

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap1);

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap2);

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap3);

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap4);

}

//Возвратить коллекцию

return m_colCaveManBitmaps;

}

} //Конец класса

Старайтесь избегать распределения памяти для объектов при выполнении повторяющихся или непрерывно продолжающихся операций рисования

Выполнение лишних операций размещения и уничтожения объектов в памяти является одной из наиболее распространенных причин ухудшения производительности графического кода. Графический код часто выполняется внутри циклов или многократно вызывается. Кроме того, поскольку графические объекты используют значительные объемы памяти, а также системные ресурсы, с их обслуживанием связаны сравнительно большие накладные расходы. Если ваше мобильное приложение распределяет и освобождает память всякий раз, когда необходимо визуализировать изображения, то вы неминуемо столкнетесь с проблемами нехватки памяти, что обусловит необходимость частого выполнения операций по сборке мусора, замедляющих работу приложения. В связи с этим необходимо предельно внимательно анализировать любые участки кода, требующие распределения памяти для объектов в процессе визуализации графики. Особенно это касается объектов, связанных с графическими ресурсами, но остается справедливым и по отношению к объектам другой природы (например, коллекциям, массивам, строкам), которые могут фигурировать в таком коде.

В частности, вы должны анализировать с этой точки зрения распределение памяти для следующих объектов.

■ Объекты Bitmap. Часто возникают ситуации, в которых в качестве временного хранилища для изображения или части изображения, создаваемых вашим приложением, удобно использовать объект Bitmap. Если вашему приложению требуется пространство для рисования, то в этом нет ничего необычного; единственное, чего следует избегать — так это создания и уничтожения многих битовых изображений в циклах рисования. Обычно гораздо лучше иметь одно рабочее пространство, многократно используемое в качестве общего ресурса, чем нести дополнительные затраты, связанные с непрерывным созданием и уничтожением временных изображений. Размер такой временной памяти должен быть равен размеру наибольшего временного изображения, которое может понадобиться вашим процедурам (но не более того). Если временную память необходимо очищать, прежде чем использовать ее для рисования, то это можно сделать легко и быстро при помощи вызова Graphics.Clear(). Кроме того, как продемонстрировано в приведенном выше примере кода, часто используемые растровые изображения имеет смысл загружать и кэшировать в памяти. Следите за тем, чтобы в каждый момент времени загружался только один экземпляр растрового изображения. Загрузка нескольких экземпляров идентичных изображений приведет к напрасному расходованию больших объемов памяти.

■ Объекты Graphics. Если требуется постоянно перерисовывать растровое изображение, как это, например, приходится делать при перерисовке кадров игрового поля, то, вероятно, наряду с целевым экранным изображением целесообразно кэшировать также объекты Graphics внеэкранных изображений. Поступая таким образом, вы избавитесь от необходимости непрерывного размещения этих объектов в памяти и их удаления. Не распределяйте в циклах рисования память для объектов Graphics растровых изображений или форм более одного раза; в идеальном случае следует вообще избегать размещения и удаления таких объектов внутри циклов. To же самое касается и любых других битовых карт, в которых вы должны выполнять рисование; кэшируйте их объекты Graphics, а не создавайте их каждый раз заново. Учтите, что объекты Graphics нужны только для тех битовых карт, которые вы используете для создания изображений; если битовая карта используется лишь в качестве источника информации об изображении, то объект Graphics для нее вам вообще не нужен.

■ Объекты Font, Brush, Pen, ImageAttribute. Распространенной ошибкой разработчиков, причины которой вполне объяснимы, является их чрезмерное увлечение управлением временем жизни ресурсов на микроуровне, не сопровождающееся глубоким анализом их использования на макроуровне. В процессе создания графического изображения вам может потребоваться пройти, скажем, через 30 отдельных этапов, в ходе которых рисуются линии, закрашиваются эллипсы, создается текст и копируются битовые образы. Выполнение каждой из этих операций требует использования некоторой комбинации перьев, кистей, шрифтов, то есть объектов Pen, Brush, Font, а если в дело включаются еще и маски прозрачности, то и объектов ImageAttribute. В случае мобильных устройств ситуация усугубляется тем, что в .NET Compact Framework, в отличие от .NET Framework, статические версии базовых кистей и перьев не предусмотрены. Так, в версии NET Framework, ориентированной на настольные компьютеры, существуют, например, объекты System.Drawing.Pens.Blue и System.Drawing.Brushes.DarkOrange, но в NET Compact Framework эти объекты приходится распределять. Решение этой проблемы заключается в создании собственного глобального набора объектов Pen и Brush, который вы будете использовать для нужд рисования во всем приложении. Вы должны тщательно просмотреть все циклы рисования в приложении, обращая особое внимание на случаи повторного создания идентичных ресурсов и избавляясь от подобной избыточности в коде. Если в вашем приложении непрерывно выполняются операции рисования, то такие объекты, как шрифты, перья, кисти и маски прозрачности, должны либо однажды распределяться в цикле рисования, либо глобально кэшироваться.

■ Типы, которые преобразуются (или, как еще говорят, "'упаковываются") в объекты. Наиболее распространенным типом значений, используемым в графических кодах, является структура System.Drawing.Rectangle. Обычно работа с типами, соответствующими значениям, отличается высокой эффективностью, поскольку их можно размещать в стеке (а не в глобальном пуле свободной памяти, или куче, как объекты). В то же время, значения также могут рассматриваться как объекты и размещаться в массивах или коллекциях или передаваться всюду, где допускается использование объектного типа. Тщательно следите за тем, чтобы не происходило неявное постоянное распределение и освобождение памяти, обусловленное "упаковкой" значений в объекты и их обратной "распаковкой".

Заботясь о том, чтобы в графическом коде приложения не выполнялось непрерывное создание и уничтожение часто используемых объектов, вы не должны забывать о необходимости следить за использованием глобальной памяти своего мобильного приложения. Если в графических функциональных возможностях нуждаются лишь отдельные части приложения, то следует подумать об освобождении занимаемых ими ресурсов, как только приложение входит в состояние, в котором в течение некоторого времени графические ресурсы ему не будут нужны. Хорошей практикой проектирования считается использование конечного автомата и определение тех графических ресурсов, от которых при выходе приложения из определенных состояний можно освободиться.

Резюме

От того, что вы напишете код, обеспечивающий отличную реакцию пользовательского интерфейса, алгоритмы вашего приложения работать быстрее не станут. Это никоим образом не ускорит победный марш разработки приложения "до полного завершения". Более того, код приложения может даже усложниться. Единственная причина, по которой следует заботиться о высокой реактивности интерфейса и стремиться к высокой производительности его кода, заключается в том, чтобы создать для пользователя более комфортные условия, но разве ради этого не стоит потрудиться? Если вы хотите, чтобы пользователь поставил самую высокую оценку вашему приложению, вы не должны жалеть времени на доводку и отшлифовку таких вещей, как способность интерфейса к отклику. Как и в случае других аспектов производительности, выполнение этой работы нельзя откладывать до завершающих этапов процесса разработки. В конце разработки вы еще смогли бы добавить что-то наподобие курсоров ожидания в тех точках, где приложение может тормозиться, но это все равно, что красиво покрасить фасад плохо построенного дома — это лучше, чем вообще ничего, но, в сущности, не так уж и много. Никогда не забывайте о необходимости обеспечения высокой интерактивности пользовательского интерфейса и всегда в явном виде включайте это требование в качестве критерия прохождения каждой контрольной точки разработки. Лучше всего решать подобные проблемы сразу же после их выявления, пока они не успели накрепко зацементироваться в структуру приложения.

В основе высокой производительности пользовательского интерфейса лежит активное управление условиями взаимодействия с ним конечного пользователя. Ваше мобильное приложение должно обеспечивать такие условия, при которых пользователь в процессе навигации в пределах приложения чувствует его ответную реакцию и не испытывает раздражения. Пользовательский интерфейс инициирует сложнейшую систему взаимодействий между кодом приложения и библиотеками времени выполнения, поверх которых приложение построено. Этот процесс сопровождается созданием элементов управления, используемых для заполнения форм, генерацией событий, а также многочисленными видами взаимодействия различного уровня между кодом и средой выполнения. Высокая производительность обеспечивается использованием оптимизированных в этом отношении средств среды выполнения, структурированием кода пользовательского интерфейса таким образом, чтобы пользователь не чувствовал себя изолированным от вычислительного процесса при выполнении задач, требующих длительного времени, а также целенаправленной количественной оценкой эффективности кода пользовательского интерфейса и включения в него средств контроля хода выполнения, которые позволят вам разобраться в том, что именно происходит за кулисами пользовательского интерфейса.

Изучайте свойства и методы элементов управления, которые вы используете. Для элементов управления часто предусматриваются специальные возможности оптимизации производительности. Внимательно анализируйте события, на которые реагирует ваше приложение. В частности, вы должны постараться хорошо представлять себе и экспериментально проверять, когда именно запускаются события, на которые приложению приходится реагировать. В процессе просмотра кода события могут казаться вам простыми и понятными, но они представляют ту область, в которой вы, как разработчик, вынуждены передавать управление выполнением приложения операционной системе. Именно операционная система и каркас пользовательского интерфейса определяют, когда именно будет выполняться код вашего обработчика события; это может случаться гораздо чаще, чем вы думаете, или происходить неожиданным для вас образом при обработке сообщений операционной системой. Между событиями, свойствами и методами элементов управления могут существовать такие тонкие виды взаимодействия, о которых вы даже не догадываетесь. Непредусмотренная и не являющаяся необходимой обработка событий пользовательского интерфейса порождает проблемы производительности и усложняет работу с приложением. Будьте особенно внимательны в тех случаях, когда существует возможность повторного входа в обработчик событий.

При работе с растровыми изображениями существенное значение имеют их размеры. Современные цифровые изображения с высоким разрешением занимают очень много места как на диске, так и в памяти. Цифровые фотографии, а также битовые образы, генерируемые на настольных компьютерах, представляют собой изображения, разрешение которых намного превышает возможности мобильных устройств. Никогда не забывайте о размерах экранов устройств, с которыми вы работаете, и размерах переносимых на них битовых образов; они должны соответствовать друг к другу. Для изображений, размеры которых довольно велики, неплохо использовать сжатые форматы хранения данных. В случае изображений, допускающих применение сжатие с потерями, рекомендуется использовать формат JPEG, тогда как в случае изображений, требующих полной достоверности, более подходящим является формат PNG. Помните, что, независимо от эффективности используемого алгоритма сжатия, занимаемый загруженным изображением объем памяти определяется размерами самого изображения.

Обработку графики следует продумывать независимо от кодирования высокоуровневого пользовательского интерфейса и оптимизировать отдельно. Оптимизация графического кода, предназначенного для рисования изображений, требует применения иных методик, нежели настройка кода высокоуровневого пользовательского интерфейса, и требует особого искусства. Поскольку графические изображения, генерируемые вашим мобильным приложением, обычно должны сосуществовать с элементами высокоуровневого пользовательского интерфейса, следует продумать, каким образом следует организовать взаимодействие графического кода с пользовательским интерфейсом; для этого существует несколько различных моделей. Для такого взаимодействия целесообразно использовать самый высокий из возможных уровней абстракции. Если вы генерируете статические изображения, то одним из приемлемых и концептуально несложных способов реализации указанного подхода может быть создание битового образа в памяти и его назначение свойству Image элемента управления PictureBox. Если требуется непрерывное обновление изображения, то приложение может создавать изображение во внеэкранном буфере и периодически копировать кадры на поверхность формы подобно кинопроектору. Пользовательские элементы управления особенно удобно использовать в тех случаях, когда требуется высокая степень интерактивности взаимодействия пользователя с создаваемой графикой, например, диаграммой, позволяющей переходить с одного уровня детализации данных, которые она представляет, на другой. Кроме того, пользовательские элементы управления могут генерировать пользовательские события, которые ваше приложение может перехватывать. Каждая из вышеперечисленных стратегий интеграции пользовательского интерфейса характеризуется своими видами взаимодействий, для которых она больше всего приспособлена; при этом очень важно явно сформулировать, какие именно задачи должна решать графика в мобильном приложении, и выбрать наиболее подходящую стратегию решения этих задач.

Работая с графическим кодом, вы должны хорошо представлять себе систематическую картину того, каким образом в приложении осуществляется визуализация изображений. При этом очень важно "не оказаться крохобором в мелочах, бездумно транжирящим крупные суммы" в обращении с ресурсами. Если имеются такие объекты Bitmap, Graphics, Pen, Brush, Font или ImageAttribute, которые будут использоваться во всех операциях рисования в приложении, то вы должны разработать систему, в задачи которой входит создание и кэширование указанных ресурсов. Применение предварительно создаваемых изображений сопряжено с дополнительным расходом ценной памяти, однако оно чрезвычайно ускоряет операции рисования; при разумном подходе это позволяет создавать приложения с привлекательным интерфейсом, сохраняющие высокую производительность. Исключайте случаи одновременной загрузки двух идентичных ресурсов — подобная расточительность никому не нужна.

Целесообразно также подумать над тем, нельзя ли представить приложение в виде таких различных состояний, чтобы распределение графических ресурсов или освобождение кэшируемых ресурсов, когда необходимость в них отпадает, можно было осуществлять для каждого состояния независимо от других.

Создание многофункциональных графических интерфейсов для мобильных устройств — вполне осуществимая задача, решение которой способствует повышению комфортности условий работы пользователя с вашим приложением. При построении графических пользовательских интерфейсов очень важно придерживаться подхода, являющегося одновременно творческим, аналитическим и систематическим. Сочетание творческого воображения художника, умеющего представлять себе то, чего еще не существует, аналитических способностей инженера, умеющего решать технические задачи, и проницательного взора бухгалтера, который не допустит неоправданных затрат, — вот что необходимо для того, чтобы ваше мобильное приложение было оценено конечными пользователями как высокопроизводительное, а взаимодействие с его привлекательным интерфейсом доставляло им одно удовольствие. Работа с графикой потребует от вас напряжения всех сил, но одновременно доставит огромное удовольствие; никогда не забывайте о производительности, и тогда выше вас — только небо!

ГЛАВА 12

Производительность: подведение итогов

Итоговые замечания по поводу производительности

Примите поздравления! Наконец-то вы добрались до конца части книги, которая посвящена вопросам производительности. Если вы внимательно читали весь предыдущий материал, то у вас сейчас должны быть все основания, чтобы чувствовать себя уверенно в отношении большинства аспектов программирования мобильных приложений, знание которых обеспечивает создание высокопроизводительного кода. Вы будете в состоянии самостоятельно исследовать возможные пути использования тех необычайных возможностей, которые предлагают мобильные устройства.

Поскольку тема производительности — многоплановая, она рассматривалась в предыдущих главах с самых различных сторон и с углублением в детали тех отдельных областей и уровней проектирования, которые оказывают на производительность мобильных приложений наиболее заметное влияние. Начало этому обсуждению было положено общим обзором аспектов производительности с точки зрения философии и практических методов проектирования.

Далее мы перешли к рассмотрению того, насколько выбор проектного решения может влиять на удачность или неудачность реализации обычных видов функциональности мобильных приложений, и познакомились с конкретными стратегиями, обеспечивающими достижение высокой производительности в этих областях. Теперь настало время подытожить все ранее сказанное о производительности, сведя все нити рассуждений в один пучок завершающих мыслей и практических рекомендаций, следование которым позволит вам действовать наилучшим образом.

Производительность и управление памятью

Ваши успехи в разработке мобильных приложений будут в огромной степени зависеть от того, каким образом вы организуете управление памятью как на микроскопическом, так и на макроскопическом уровнях. При проектировании модели использования памяти мобильного приложения и написании алгоритмов очень важно отдавать себе отчет в том, к каким действиям будет вынужден прибегать сборщик мусора в соответствии с теми или иными проектными решениями, которые вы примете. Хотя работу сборщика мусора вы непосредственно контролировать не можете, она заметно влияет на общую производительность приложений на основе управляемого кода.

С аналогичными трудностями сталкиваются и разработчики приложений на основе собственных кодов, однако они должны управлять памятью самостоятельно. Полная сборка мусора обходится недешево; чтобы восстановить память, занимаемую ненужными объектами, среда времени выполнения должна просмотреть все объекты высшего уровня, спускаясь вниз по деревьям подобъектов для отыскания всех объектов, которые по-прежнему используются приложением. Выполнение каждой операции по очистке памяти от "мусора" требует некоторых минимальных накладных расходов, объем которых зависит от количества объектов, которые необходимо просмотреть; многократное выполнение этой операции во многих случаях приводит к ощутимому замедлению работы приложений.

Частота выполнения сборки мусора напрямую зависит от того, насколько быстро ваш код расходует память приложения. Дефицит памяти в приложениях может быть обусловлен двумя факторами: 1) суммарным объемом поддерживаемого состояния приложения, включая всевозможные формы, глобальные объекты, пользовательские данные и любые другие объекты, содержащиеся внутри глобальных родительских объектов, и 2) временными объектами, которые создаются и разрушаются в процессе выполнения ваших алгоритмов. Если посмотреть на график изменения объема памяти, расходуемой приложением в процессе своего выполнения, то он будет иметь пилообразную форму. Высота зубьев этой пилы определяется тем, какой объем памяти вы оставляете для использования вашими алгоритмами, где имеется в виду память, не входящая в состав постоянно распределенной памяти приложения. Наклон же зубьев зависит от того, насколько эффективны процедуры распределения памяти для объектов, используемые в ваших алгоритмах. Чем более экономичны алгоритмы в отношении размещения новых объектов, тем более пологий наклон имеют зубья. В конечном счете, объем занимаемой приложением памяти начинает превышать некоторое пороговое значение, что приводит к запуску механизма сборки мусора, осуществляющего освобождение памяти от неиспользуемых объектов.

На рис. 12.1, 12.2, 12.3 и 12.4 проиллюстрированы четыре основных типа потребления памяти.

Рис. 12.1 схематически иллюстрирует поведение приложения в отношении потребления памяти в соответствии с наихудшим сценарием, который характеризуется высоким объемом постоянно распределенной памяти и неэкономным расходованием памяти в процессе работы алгоритмов. В этом случае постоянно распределенная память мобильного приложения занимает почти всю память, имеющуюся в системе. В результате этого в случае непрерывного размещения и уничтожения объектов, осуществляемого неэффективными алгоритмами, в памяти остается совсем мало места. Очень важно не забывать о том, что область памяти, занимаемая объектом, не может быть повторно использована сразу же после уничтожения ссылки на объект; чтобы восстановить память с целью сделать ее доступной для дальнейшего использования, должна быть выполнена операция сборки мусора. Непрерывное размещение и удаление объектов является причиной увеличения крутизны наклона зубьев пилообразного графика потребления памяти. Нехватка места для размещения объектов в памяти делает необходимой ее частую очистку от "мусора", что каждый раз сопровождается дополнительными накладными расходами.

В результате этого производительность резко ухудшается, поскольку сборщик мусора вынужден выполняться практически непрерывно, чтобы приложение могло хоть как-то работать.

Рис. 12.1. Наихудший случай: чрезмерное потребление памяти состоянием приложения, неэкономичные алгоритмы

На рис. 12.2 представлен промежуточный в отношении производительности случай. Хотя этому варианту поведения системы, как и предыдущему, также свойственно неэкономное размещение объектов в памяти алгоритмами приложения, тем не менее, объем постоянно распределенной памяти в этом случае гораздо меньше. Это означает, что, несмотря на то, что наклон линии, отображающей процессы непрерывного размещения и уничтожения объектов, остается крутым, имеется гораздо больше свободного пространства, способного дольше хранить "мусор". Таким образом, необходимость в сборке мусора будет возникать гораздо реже, в результате чего производительность значительно улучшается по сравнению с предыдущим случаем.

Рис. 12.3 иллюстрирует еще одну промежуточную модель управления памятью, обратную той, которая рассматривалась выше. Кривая потребления памяти характеризуется высоким уровнем постоянно распределенной памяти, соответствующей глобальным объектам и системным данным, но рабочая память используется алгоритмами приложения гораздо более эффективным образом. Хотя ее объем и невелик, однако она экономнее расходуется для размещения объектов алгоритмами, что устраняет необходимость в ее непрерывном восстановлении посредством механизма сборки мусора.

На рис 12.4 представлен наиболее оптимальный вариант расходования памяти.

Рис. 12.2. Промежуточный случай: эффективно организованное состояние приложения, неэкономичные алгоритмы

Рис. 12.3. Промежуточный случай: чрезмерное потребление памяти состоянием приложения, экономичные алгоритмы

Рис. 12.4. Наиболее оптимальный случай: эффективное состояние приложения, и экономичные алгоритмы

Количество постоянно хранимых в памяти объектов ограничено, так что алгоритмы получают в свое распоряжение гораздо большее рабочее пространство. При этом временные объекты создаются алгоритмами весьма экономно. В результате этого сборка мусора должна выполняться сравнительно редко, а это означает увеличение производительности приложения и уменьшение вероятности его "зависания".

Создавая свои мобильные приложения, вы должны стремиться к реализации модели использования памяти, которую отражает рис. 12.4. Приложение должно поддерживать информацию о состоянии, обеспечивающую все то, что требуется пользовательским данным, но реализовываться это должно по возможности наиболее эффективным способом. Кроме того, приложение должно сохранять в памяти те ресурсы, которые обычно требуется создавать и уничтожать в процессе устойчивого выполнения вашего приложения.

Хорошая организация управления памятью предполагает достижение баланса множества факторов и эффективное использование памяти, с которой работает приложение. Не имеет смысла стремиться к снижению объема информации о глобальном состоянии до минимума, если приложению для нормального выполнения потребуется постоянно создавать и уничтожать те же самые объекты в виде временных объектов. Точно так же, не стоит хранить в памяти состояние приложения в таком объеме, который приводит к образованию дефицита рабочего пространства, в результате чего эффективное выполнение алгоритмов приложения становится невозможным без непрерывного освобождения памяти посредством механизма сборки мусора. Все, что для этого требуется — это обеспечение разумного компромисса между двумя вышеупомянутыми противоречащими друг другу требованиями.

Производительность и многопоточное выполнение

В качестве общего правила руководствуйтесь тем, что от введения нескольких потоков ваше приложение работать быстрее не станет. Суть еще одного правила состоит в том, что организация управления параллельными потоками выполнения значительно усложнит код вашего приложения и затруднит его понимание, сопровождение и отладку. Поэтому очень важно не поддаваться "очарованию потоками" и не пытаться придумывать для них все новые способы применения в тех случаях, когда они абсолютно не нужны.

В то же время для использования фоновых потоков в приложениях существуют веские причины. Наиболее привлекательной областью применения потоков является сохранение способности вашего мобильного приложения к интерактивному взаимодействию с пользователем в тех случаях, когда выполнение задачи занимает длительное время или же о длительности ее выполнения заранее ничего сказать невозможно. Длительное выполнение характерно для тех задач, которые связаны с интенсивными вычислениями или интенсивной алгоритмической обработкой. Задачи, время выполнения которых является неопределенным, требуют доступа к ресурсам, которыми вы непосредственно управлять не можете. (Так, спрогнозировать длительность задержек в случае доступа к информации через сеть практически невозможно.) Для такого рода операций отличные возможности предоставляет работа в асинхронном режиме.

Суть простейшей и наиболее эффективной модели многопоточного выполнения состоит в том, чтобы иметь один основной поток, взаимодействующий с пользователем, и ряд фоновых потоков, предназначенных для выполнения асинхронных задач. Основной высокоприоритетный поток может производить периодический опрос с целью выяснения того, не завершилось ли выполнение фоновых задач или не поступила ли промежуточная информация о состоянии выполнения той или иной задачи, которую следует довести до ведома пользователя. Такие потоки фоновой обработки могут либо создаваться по требованию, либо существовать в виде пула потоков, ожидающих появления работы, которую необходимо выполнить. Создание потоков по требованию концептуально проще создания диспетчера пула потоков. Если готовой инфраструктуры, которая позволяла бы управлять фоновым выполнением, не существует, то в случае мобильных приложений я порекомендовал бы создавать для этой цели потоки по требованию. В состав каркасов приложений могут входить встроенные средства, позволяющие выполнять задачи в асинхронном режиме, и эту возможность необходимо всегда проверять, прежде чем браться за создание собственной модели многопоточного выполнения; какой смысл заново изобретать колесо, если оно давным-давно существует.

Производительность и уровни абстракции API-интерфейсов

Очень важно выбрать для работы подходящий уровень абстракции. Высокоуровневые абстракции API-интерфейсов предоставляют упрощенную, удобную в работе и хорошо проверенную программную модель, но это часто влечет за собой дополнительные накладные расходы. Низкоуровневые API-интерфейсы позволяют наилучшим образом контролировать производительность приложений, но это дается за счет дополнительного усложнения кода. Примерами функциональности, предоставляемой каркасами приложений, могут служить средства для работы в сети и синтаксические XML-анализаторы, имеющие несколько уровней абстракции, из которых разработчик может выбрать наиболее удобный для работы. При создании приложений всегда старайтесь использовать самый высокий уровень абстракции из тех, которые являются подходящими для решения стоящих перед вами задач.

Весьма показательным примером может служить работа с XML. Теоретически, разработчик может добиться абсолютного максимума производительности, выполняя синтаксический анализ необходимых данных путем непосредственного использования файловых потоков ввода-вывода. Однако такой подход будет крайне неразумным, чреватым ошибками и ничем не оправданным, если существуют хорошо спроектированные и проверенные высокоуровневые API-интерфейсы, которые позволяют выполнить данную задачу без заметного ущерба для производительности.

Идеальнее всего, если разработчику для загрузки и сохранения своих данных в виде XML-дерева удается использовать объектную модель документов (Document Object Model — DOM). Эта модель прекрасно подходит для работы с XML-данными среднего объема. Однако разработчики не должны забывать о том, что XML DOM в значительной мере основана на использовании состояний; при загрузке XML-данных в память они в действительности сохраняются в памяти в виде дерева объектов, представляющих XML-документ. В случае крупных документов создание такого дерева может приводить к дефициту памяти. В противоположность этому сама модель XML DOM строится поверх классов XMLReader и XMLWriter, которые не имеют состояния и осуществляют лишь однонаправленный доступ к данным; эти классы осуществляют синтаксический анализ или генерируют XML-данные, основываясь на состоянии лишь в самой минимальной степени. Эти классы удерживают в памяти ровно столько информации, сколько необходимо для того, чтобы иметь возможность осуществлять разбор XML-данных или записывать их в поток; они и не генерируют, и не используют хранящиеся в памяти деревья данных.

При работе с крупными XML-документами на мобильных устройствах с ограниченными ресурсами памяти наиболее подходящей является модель однонаправленного доступа к данным без сохранения состояния. Это остается справедливым даже при условии привлечения программистом низкоуровневых API-интерфейсов для синтаксического разбора XML-данных. Чтобы выбрать наиболее подходящий уровень абстракции API-интерфейса, необходимо хорошо себе представлять, какие объемы данных перемещаются и какие накладные расходы связаны с привлечением высокоуровневых абстракций.

Связь производительности с организацией пользовательского интерфейса и работы с графикой

Первые и самые глубокие впечатления от вашего приложения конечные пользователи получают при знакомстве с его пользовательским интерфейсом и графикой.

О приложении можно говорить, что оно имеет отличный внешний вид и прекрасный интерактивный интерфейс лишь постольку, поскольку таковым его воспринимают конечные пользователи. Для представления данных и взаимодействия с конечным пользователем существует практически бесчисленное количество способов, поэтому перед вами, как проектировщиком, простирается весьма широкий набор возможных для выбора вариантов. Такая ситуация может как вдохновлять, так и обескураживать вас, поэтому некоторые рекомендации здесь будут вполне уместными. При заполнении пользовательского интерфейса данными очень важно учитывать, какие данные могут действительно понадобиться пользователю, и не тратить время на разработку элементов управления с огромными списками или деревьями данных, до которых пользователь, скорее всего, не будет даже пытаться добраться; в противном случае вы зря потратите и время и ресурсы. Лучше затратьте это время на проектирование таких пользовательских интерфейсов, которые дают пользователю возможность легко переходить к нужным данным, и откладывайте вывод необязательных элементов управления пользовательского интерфейса до тех пор, пока в них не возникнет реальная необходимость. Возможно, прежде чем вы получите модель, которая вас устроит, вам придется много экспериментировать, поэтому будьте готовы к неоднократным переделкам интерфейса.

Вы должны тщательно исследовать пользовательский интерфейс, чтобы хорошо понимать тонкости его взаимодействия с кодом мобильного приложения. Особенно важно разобраться в том, как каркас пользовательского интерфейса активизирует код обработки событий приложения. Очень часто одного лишь просмотра кода еще не достаточно для того, чтобы с уверенностью сказать, когда именно будут запускаться те или иные события и каким образом код обработки событий взаимодействует со свойствами и методами, которые могут вызываться вашим приложением. Организация в коде средств контроля его выполнения и осуществление периодических проверок того, когда именно вызываются обработчики событий пользовательского интерфейса, помогут вам значительно глубже разобраться в характере взаимодействия каркаса этого интерфейса с вашим кодом.

Находящиеся в памяти битовые образы и сохраненные изображения — это та арена, на которой графика и пользовательский интерфейс взаимодействуют между собой. Сохраненные изображения часто удобно использовать в приложении либо в качестве части пользовательского интерфейса, либо в качестве данных. При использовании изображений очень важно контролировать их размеры, чтобы в целом они соответствовали характерным размерам интерфейса; изображения, размеры которых больше необходимых, требуют больших объемов памяти для хранения и используют значительно больше системной памяти в процессе загрузки. Вы должны отдельно исследовать вопрос о том, какой формат хранения изображений следует использовать, чтобы он был наиболее оптимальным для интересующей вас задачи. Для фотографических изображений самым употребительным форматом является JPG, тогда как для изображений, полученных методами компьютерной графики, — формат PNG.

Графический код — это код, с помощью которого приложение может создавать рисунки. Эта возможность используется для представления нестандартных красочных изображений пользователям, а также для реализации высокоинтерактивных нестандартных элементов управления пользовательского интерфейса. Часто для интеграции графического кода в пользовательский интерфейс имеется несколько возможностей, начиная с простейших (например, отображение рисунков на элементах управления PictureBox), и заканчивая самыми сложными (например, создание нестандартных элементов управления). Выбор оптимальной модели встраивания графики в приложение имеет столь же важное значение, что и рассматривавшийся нами ранее выбор наиболее подходящего уровня абстракции API-интерфейсов; всегда старайтесь использовать самую простую из возможных моделей.

Существуют отличные способы оптимизации программных кодов, предназначенных для рисования графики. Чтобы разглядеть эти возможности в своем коде, вы должны придерживаться целостного подхода к рассмотрению задач рисования, возникающих в вашем мобильном приложении. Графический код часто состоит из множества мелких шагов, объединенных в цепочки или выполняющихся в циклах. Чтобы добиться максимальной производительности при работе с графикой, вы должны пытаться находить в процессе проектирования приложения: 1) области, для которых графическую работу можно выполнить заблаговременно, например, заранее готовя отдельные части нужных изображений, или 2) способы, позволяющие свести к минимуму количество операций, размещающих в памяти объекты или системные ресурсы. Если обычные перья, кисти, пиктограммы или иные ресурсы используются более одного раза, их следует создавать и сохранять в кэш-памяти

Старайтесь постоянно информировать пользователя о ходе выполнения приложения

Игнорируя проблемы производительности, вы накликаете на себя беду. Закрывать глаза на проблемы производительности, которые могут возникать в вашем приложении, и не замечать их — это самый верный способ создания самому себе трудностей в процессе дальнейшей разработки. Лучше всего разрешать проблемы производительности сразу же, как только они возникли, и именно в этот момент их легче всего диагностировать. В еще большей степени, чем приложения для настольных компьютеров, мобильные приложения можно рассматривать как состоящие из ряда способных блокировать друг друга взаимосвязанных систем, которые должны совместно использовать одни и те же системные ресурсы. Поскольку в случае мобильных устройств пул доступной памяти имеет гораздо меньший объем, а понятия свопинга редко используемых областей памяти в дисковый файл подкачки для них не существует, любой лишний элемент может стать причиной возникновения крупномасштабных проблем в рамках всего приложения..Так, хранение крупных растровых изображений в памяти непосредственно уменьшает ресурсы, которые можно было бы использовать для хранения дерева XML-данных или скомпилированного кода функции. Случаи, когда приложение исчерпывает всю доступную память, диагностировать легко. Установить источник проблем гораздо сложнее, если в приложении нехватка памяти нарастает постепенно, все чаще и чаще активизируя сборщик мусора, чтобы поддерживать приложение в работоспособном состоянии.

Взаимозависимость отдельных частей вашего приложения означает необходимость выполнения соответствующего анализа как на интегральном, так и на компонентном уровнях. Каждая отдельная часть приложения (коды, обеспечивающие загрузку и сохранение данных, обработку графики, обмен данными с сетью и так далее) должна быть исследована с целью выяснения того, какое состояние для нее требуется, и какие временные объекты она создает в процессе работы приложения; совершенно очевидно, что чем меньше эта часть, тем легче во всем разобраться. Упомянутые компоненты должны быть встроены вместе в приложение сразу же, как только это станет возможным, чтобы посмотреть, как функционирует система в целом. Размер данных, используемых для тестирования, должен быть близким к тому, с которым вашему приложению придется работать в реальных условиях.

Очень важно, чтобы в тех случаях, когда проблемы производительности уже проявились, вы не пытались расширять возможности мобильного приложения и добавлять в него новый код, питая ложные надежды на то, что в будущем у вас еще будет время заняться этими проблемами. Добавлять новые средства и код в приложение следует лишь тогда, когда вы располагаете резервами производительности для поддержки этих средств. Если вы чувствуете, что "уткнулись в глухую стену", то прежде, чем вводить в приложение дополнительные элементы, потребляющие ресурсы, попытайтесь сделать состояние приложения более экономичным и свести к минимуму алгоритмическую чехарду с созданием и уничтожением объектов. Дополнительные резервы производительности — это та валюта, которой вы сможете расплачиваться за новые возможности; если у вас есть долги, то сначала рассчитайтесь с ними и лишь после этого позволяйте себе дальнейшие траты.

Заключительные замечания и рекомендации

Написание конкурентоспособных приложений для мобильных устройств требует достижения разумного компромисса между взаимно противоречащими мелями проекта, применения хорошо продуманных механизмов, позволяющих избежать выполнения ненужной работы, и, что самое главное, сознательного стремления к использованию подходов, обеспечивающих поддержание производительности приложения на высочайшем уровне. Ниже представлены некоторые итоговые рекомендации, обобщающие накопленный к настоящему времени передовой опыт в данной области, которые помогут вам в решении очерченных выше задач.

■ Принимайте осознанные заблаговременные решения, касающиеся управления памятью приложения. Не допускайте, чтобы используемая в вашем приложении модель памяти формировалась просто как пассивный или произвольный продукт других проектных решений. Явным образом указывайте в проекте, какие именно объекты должны удерживаться в памяти и когда именно память должна освобождаться от них.

■ Определяйте дискретные состояния приложения и указывайте ресурсы, требуемые в каждом из этих состояний. В реализации этой разновидности управления памятью вам может очень пригодиться конечный автомат. Ваше мобильное приложение должно поддерживать список состояний и варианты поведения приложения при смене состояний, что позволит вам регулировать использование памяти.

■ Не бойтесь помещать в кэш-память часто используемые ресурсы. Вы должны поставить перед собой задачу поддерживать объем постоянно используемой памяти приложения на как можно более низком уровне, но только не за счет отбрасывания полезных объектов. Если вам приходится то и дело заново создавать и уничтожать одни и те же критические объекты, то лучше кэшировать их, чтобы избежать этого напрасного перелопачивания памяти. Подумайте о создании класса диспетчера ресурсов, ответственного за распределение, кэширование, освобождение и передачу ресурсов остальным частям приложения. Этот класс может отделить задачу диспетчеризации ресурсов от их размещения в памяти и уничтожения. Предусмотрев один центральный диспетчер ресурсов, вы можете настроить его в соответствии с запросами приложения в его различных состояниях, тем самым избавив остальную часть кода от каких бы то ни было забот о стратегиях распределения и освобождения ресурсов.

■ Используйте курсор ожидания и обеспечивайте обратную связь с пользователями для любой задачи, выполнение которой длится более одного мгновения. Если выполнение любой задачи занимает более половины секунды, следует использовать курсор ожидания. Если выполнение задачи длится более двух секунд или может занять неопределенное время, пользователь должен получать регулярно обновляемую информацию о состоянии ее выполнения.

■ В процессе разработки и тестирования, приложения используйте реальные размеры данных и модели сетевых соединений. Важно тестировать мобильное приложение в условиях программной среды, близких к тем, с которыми будут сталкиваться конечные пользователи в процессе работы. Это касается как вероятных объемов данных, с которыми будут работать конечные пользователи, так и параметров подключения к сети (например, скорость передачи данных и длительности задержки) в реальных условиях. Если ваше приложение характеризуется определенными пороговыми значениями некоторых параметров состояния, при превышении которых приложение начинает работать значительно хуже, предусмотрите явные запреты, препятствующие переходу приложения в такие состояния; разрешая приложению переходить в состояния, в которых нормальное функционирование приложения нарушается, вы оказываете конечным пользователям "медвежью услугу".

■ Осмотрительно выбирайте размеры применяемых вами растровых изображений. В наши дни размеры обычных цифровых изображений значительно превышают те, которые еще допустимы при выводе изображений на экраны мобильных устройств. При больших размерах изображений вы будете напрасно терять время на их пересылку по сети, место, необходимое для их хранения на устройстве, и память, занимаемую ими при загрузке. Лишние 0,5 Мбайт данных изображения, загруженных в память, эквивалентны сотням или даже тысячам других удерживаемых в памяти элементов, не являющихся изображениями; 500 Кбайт пикселей по занимаемому объему равносильны 500000 целочисленных элементов данных. При любом удобном случае прежде, чем загружать изображение, уменьшайте его размеры, сообразуясь с возможностями экрана целевого устройства. Если это сделать невозможно или в память должны загружаться изображения с высоким разрешением, подумайте, нельзя ли сразу же создать в памяти копии этих изображений с низким разрешением, после чего уничтожить их объемистый в отношении используемой памяти оригинал, чтобы за приложением не было закреплено большое количество лишней памяти.

■ Изыскивайте возможности предварительной обработки данных. Это пожелание касается графического кода, XML-кода и вообще любого другого сколько-нибудь значащего фрагмента кода, подлежащего выполнению. Чем больше данных вы заранее рассчитаете и придадите им удобный для использования формат, тем меньше времени на их обработку будет потрачено во время выполнения.

Обеспечение высокой производительности является важнейшим аспектом создания высококачественных мобильных приложений. Необходимой производительности можно добиться, действуя творчески и в соответствии со строго определенными целями. Описанных в предшествующих главах принципов и стратегий проектирования вам поначалу должно хватить для того, чтобы к самостоятельному разрешению проблем производительности вы подходили творчески и со знанием дела.

ГЛАВА 13

Шаг 2: проектирование подходящего пользовательского интерфейса

"Упрощение — это удаление ненужного, дабы нужное могло заговорить."

Ганс Гофман (Hans Hofmann) (1880–1966), американский художник и преподаватель, немец по происхождению

(Encarta 2004. Quotations)

Мыслите категориями устройств!

Следующим после производительности приложения фактором, от которого в наибольшей степени зависит, как пользователь будет воспринимать ваше мобильное приложение, является пользовательский интерфейс. Интуитивно понятный, оперативно реагирующий на запросы, надежный и внешне привлекательный интерфейс значит очень многое. Подобно любому другому виду творчества проектирование хорошего пользовательского интерфейса потребует от вас сочетания творческого и рационального начал.

Творчество потребуется вам для нахождения новых решений, которые позволят вам представить функциональные возможности своего приложения в рамках ограниченного пространства, предлагаемого мобильными устройствами. Дисплеи настольных компьютеров становятся поистине гигантскими как с точки зрения их физических размеров, так и с точки зрения эффективной разрешающей способности. На мобильные устройства накладывают отпечаток условия их применения; пользователи должны иметь возможность без труда носить устройства с собой, а способ их использования должен быть таким, чтобы это не мешало окружающим. Способ доставки информации и интерактивные возможности, которые вы хотите предоставить пользователям, ставят задачи просеивания и неординарной организации информации.

В дополнение к трудностям размещения необходимой информации на ограниченной площади экрана мобильного устройства существует ряд человеческих и социальных факторов, с которыми надо считаться. В наши дни отовсюду доносятся назойливые звонки мобильных телефонов, которые могут мешать чьей-то беседе, нарушать нормальный ход собраний или просто раздражать окружающих в местах скопления людей. Вы только представьте себе, что будет, если все люди в комнате начнут одновременно разговаривать по телефону; в результате комната была бы заполнена сплошной какофонией. (К сожалению, в наши дни эта проблема уже выходит из разряда чисто теоретических!)

Представьте, что было бы в заполненном людьми лифте или вагоне метро, где каждый человек пытался бы получить доступ к расписанию встреч, деловой или личной информации, хранящейся в мобильном телефоне, если бы для этого необходимо было оперировать обеими руками; каждому мешали бы торчащие локти его соседей, и перебранка была бы неизбежной. Находясь в толпе, с устройством еще хоть как-то можно справиться, пользуясь одной рукой, но если для этого требуются две руки, то задача существенно усложняется. Как характер доставляемой информации, так и условия использования приложения оказывают значительное влияние на то, каким образом должен быть спроектирован пользовательский интерфейс. Решение проблем подобного рода требует творческого подхода.

Обеспечение последовательности подхода к проектированию пользовательского интерфейса требует соблюдения определенной дисциплины. Одним из признаков неудачно спроектированного пользовательского интерфейса являются различные рода нарушения его единообразия в процессе использования приложения. Вынуждая пользователя переводить взгляд на различные участки экрана или нажимать различные физические кнопки для простой навигации в пределах пользовательского интерфейса, вы доставите ему много неудобств. Как и во всем, что касается многих других аспектов проектирования для мобильных устройств, эта проблема не является специфической для устройств, но усугубляется в этом случае тем, что устройства предлагают пользователю пространственно ограниченное рабочее поле, требующее концентрации внимания в пределах ограниченного пространства; в этих условиях любые недостатки навигации существенно усиливаются и весьма затрудняют работу с приложением. Соблюдение строго определенного подхода, гарантирующего согласованность и простоту использования приложения, имеет очень большое значение.

Строгое следование определенному подходу требуется также и при реализации кода пользовательского интерфейса, что будет гарантировать гибкость кода и его открытость для проведения экспериментов и дальнейшего усовершенствования. Коду пользовательского интерфейса свойственно быстро разрастаться и становиться запутанным. В результате незначительных тактических улучшений кода, накладывающихся друг на друга, основа кода становится хрупкой и начинает сопротивляться внесению изменений. Дисциплинированный подход необходим для того, чтобы не дать коду пользовательского интерфейса превратиться в монолит, состоящий из сложных и тесно переплетающихся между собой подсистем. Чтобы этого не произошло, вы должны описать и реализовать пользовательский интерфейс в виде жизнеспособного набора дискретных состояний. Реализация каждого состояния пользовательского интерфейса должна быть изолированной от других состояний, дабы возврат к предыдущим этапам ее разработки не сопровождался дестабилизацией остальных состояний.

В соответствии с ранее приводившимися в этой книге рекомендациями, привлечение подхода, основанного на использовании конечного автомата для описания и реализации пользовательского интерфейса мобильного приложения, сторицей себя окупит при проведении экспериментов, а также в процессе усовершенствования и сопровождения кода. Дисциплинированный подход к написанию программ нисколько не уменьшает их гибкость, напротив — он только усиливает ее.

Проектирование пользовательских интерфейсов мобильных приложений — увлекательный процесс. На этом пути вас могут подстерегать непредвиденные трудности, для разрешения которых вам придется мыслить по-новому. Перед разработчиками, воспитанными на проектировании приложений для настольных компьютеров или Web-браузеров, пользовательские интерфейсы мобильных устройств поставят ряд сложных проблем, которые необходимо будет преодолеть. Как разработчик мобильных приложений, вы должны научиться мыслить категориями, свойственными мобильным устройствам

Один размер для всего не годится

Еще несколько лет назад лозунг "пишется однажды — выполняется везде" был чрезвычайно популярным; мы все бросились писать приложения, которые бесшовно выполнялись под управлением различных настольных операционных систем, легко переносились на сотовые телефоны и без всякой переделки могли выполняться чуть ли не в наручных часах. В настоящее время представляется, что пользы от этой идеи примерно столько же, сколько от идеи об "универсальном ботинке" , если она и осуществима, то продукт во всех случаях не будет дотягивать до принятых стандартов.

Представьте, насколько нелепо было бы мечтать о некоем едином универсальном ботинке, способном надеваться на ногу любого размера и исправно служить во всех случаях. Это означает, что его мог бы носить и шестилетний ребенок с его маленькой ножкой, и взрослый человек, и использовать его можно было бы в любых ситуациях, от покорения ледяной вершины до бальных танцев. Как-то я пытался танцевать в лыжных ботинках, и могу засвидетельствовать, что ничего хорошего из этого не получилось; как я танцую даже в подходящей обуви — это уже другой вопрос, рассмотрение которого выходит за рамки данной книги. Во всяком случае, концепция универсального пользовательского интерфейса рассыпалась по двум причинам 1) выпускаемые устройства имеют различные размеры и форму и 2) различные классы устройств оптимизированы для решения различных задач.

Тот факт, что выпускаемые устройства отличаются друг от друга своими размерами и форм-факторами самым непосредственным образом влияет на применимость любого заданного пользовательского интерфейса на том или ином устройстве. Так, по своим физическим размерам визуальный пользовательский интерфейс смартфона значительно уже интерфейса Pocket PC. В то же время, каждый из этих интерфейсов значительно уже интерфейса планшетного компьютера. Эти различия вовсе не произвольны и обусловлены тем, какой именно способ ношения устройства предполагается (например, в кармане брюк, кармане пиджака, в рюкзаке или портфеле), и в каких ситуациях оно должно использоваться. Размеры экрана устройства оказывают заметное влияние на способ представления информации, который вы должны выбрать. Важно и то, что механизмы ввода также меняются от устройства к устройству. Такие устройства, как смартфоны, снабжены расширенной 12-клавишной клавиатурой, но экранные указатели для них не предусмотрены, тогда как устройства PDA (персональные помощники) в качестве основного механизма ввода оборудуются сенсорным экраном.

В некоторых устройствах для ввода данных используются сенсорные экраны, тогда как в других устройствах от них отказываются в пользу жестких дисплеев, используемых только в режиме чтения, поскольку они более долговечны и не будут повреждены связкой ключей, когда вы положите устройство в карман, или раздавлены дорожной кладью при перелете. Есть еще и устройства с полной клавиатурой и пером, чтобы с ними можно было работать и стоя, и сидя за столом.

Разнообразие размеров и механизмов ввода мобильных устройств поражает своей широтой, в результате чего предложить для них какую-то одну типовую модель, в равной степени пригодную для всех случаев, практически невозможно. Модели сред выполнения, в которых делаются попытки динамической адаптации пользовательского интерфейса, исходя из возможностей целевого устройства, обычно не приводят к хорошим результатам, поскольку в них не может быть учтено то, какие из аспектов пользовательского интерфейса приложения являются наиболее важными и каким образом можно лучше всего передать все богатство их функциональных возможностей на том конкретном устройстве, на котором они выполняются.

Каждая категория устройств характеризуется своим оптимальным набором задач и моделей использования, для которых она предназначена. Мобильные телефоны используются главным образом для того, чтобы вести телефонные разговоры, просматривать ранее введенную информацию и вводить небольшие объемы новой информации, обычно — в виде одной-двух текстовых строк или простых наборов чисел. Интерфейсы устройств категории Pocket PC в состоянии предложить гораздо большие возможности дисплея для исследования информации, однако, так как в основном они выпускаются без встроенной клавиатуры, они не приспособлены для ввода текста в свободной форме. Устройства Pocket PC Phone достаточно удобны для ведения телефонных разговоров, но если такое устройство используется пользователем только для этого, то его выбор был неверным.

Устройствами с форм-фактором планшетного компьютера часто можно пользоваться даже стоя, поскольку они обеспечивают свободный ввод информации с помощью пера, но ввод текста в подобных условиях все равно остается затруднительным. Лэптопы хорошо приспособлены для ввода и исследования информации, но не для быстрых телефонных звонков или немедленного извлечения информации. Это обусловлено относительно длительным периодом загрузки этих устройств и способом их транспортировки; вы не можете вынуть полнофункциональный лэптоп из кармана, включить его и набрать телефонный номер в течение восьми секунд, равно как и оставить его без присмотра на длительное время для приема телефонных звонков из-за ограниченного срока действия батарей без перезарядки. Очень важно, чтобы пользовательский интерфейс вашего приложения согласовывался с общими внешними характеристиками устройства, на котором оно выполняется.

Хотя универсальная переносимость приложений в общем смысле и недостижима, однако использование и совместная работа приложений на устройствах различных классов вполне возможны. Во многих случаях основная логика приложения может совместно использоваться реализациями, предназначенными для различных целевых мобильных устройств. Может оказаться целесообразным абстрагировать общую логику приложения в виде двоичных компонентов, совместно используемых различными вариантами реализации, учитывающими специфику устройств, но может оказаться и так, что будет эффективнее воспользоваться одним и тем же исходным кодом в проектах приложения для различных устройств; выбор остается за вами.

В отличие от основной логики приложения ситуация с кодом пользовательского интерфейса выглядит иначе. Чтобы создать отличные условия для работы с приложением на устройстве, вы должны запланировать адаптацию пользовательского интерфейса для каждого типа устройств, на которых будет выполняться ваше приложение. Планируйте создание адаптированных вариантов реализации, учитывающих как положительные физические факторы, так и ограничения целевых устройств, настроенных на модели использования, присущие этим устройствам, и соответствующих метафорам навигации, предлагаемым специфическими для каждого из устройств моделями. Не существует ничего такого, что могло бы служить эдаким "универсальным ботинком", пригодным для ног любого размера; к тому же, программное обеспечение в силу своей природы гораздо сложнее любого ботинка. Всегда настраивайтесь на специализацию!

Одна рука или две?

Важной характеристикой вашего мобильного приложения является то, какой способ его использования предполагается — с помощью одной руки или двух? Обычно этот выбор определяется типом оборудования мобильного устройства, на которое ориентировано ваше приложение.

Например, если приложение предназначено для смартфонов, то оно должно проектироваться с учетом специфики оперирования устройством одной рукой, и с соблюдением этих условий должно проводиться и тестирование. Обратной стороной принятия такого решения является то, что если сценарий использования вашего приложения заранее требует выполнения операций одной рукой, то вы обязаны выбрать устройство, нацеленное именно на эту парадигму использования. Когда мы говорим об оперировании одной рукой, то подразумеваем, что для ввода информации и навигации в пределах приложения используется та же рука, которой удерживается устройство.

Для успешного манипулирования устройством при помощи одной руки очень важно минимизировать количество кнопок, которые необходимо использовать в процессе навигации по приложению. Например, если приложение предлагает пользователю выполнить пятишаговую операцию, то для подобной навигации по пользовательскому интерфейсу должна быть предусмотрена возможность осуществления соответствующих действий путем пятикратного нажатия одной и той же кнопки, если пользователя устраивают значения по умолчанию. Если же это потребует от пользователя нажатия пяти разных кнопок, то он должен будет переводить взгляд между экраном и телефонной клавиатурой. Это очень сильно отвлекает внимание, прерывает ход мыслей и увеличивает вероятность ошибок при вводе. Для повышения эффективности работы не менее важно правильно выбирать значения по умолчанию, чтобы пользователю оставалось только подтверждать их приемлемость.

Уменьшение количества щелчков на кнопках, необходимых для выполнения часто повторяющихся задач, до абсолютного минимума также имеет большое значение; благодаря этому уменьшается вероятность ошибок и сокращается время, которое пользователь должен затратить на выполнение коротких задач, а именно таковые обычно и приходится решать с использованием мобильных устройств.

Если общее время сеанса работы с устройством составляет примерно 20 секунд, то скостить лишний пяток секунд только за счет предоставления простой и эффективной модели навигации — совсем неплохо.

При работе над проектами, предполагающими манипулирование устройством при помощи одной руки, необходимо уделять большое внимание метафоре представления навигационных средств на целевом мобильном телефоне. Так, метафора диалоговых окон, имеющих вкладки, для навигации по приложению с помощью одной руки обычно не используется, поскольку на большинстве таких устройств для отображения всех вкладок не хватает места.

Хорошие способы навигации между различными вкладками на устройствах, предназначенных для оперирования одной рукой, отсутствуют и в тех случаях, когда экранный дисплей не является сенсорным; обычно, когда для навигации используются вкладки, устройство держат в одной руке, тогда как вторая рука используется для надавливания на экран пальцем или пером. Вместо того чтобы использовать в целях навигации вкладки, пользовательские интерфейсы смартфонов, в которых возможность переключения между несколькими экранами при помощи одной руки предусматривается, предлагают выбрать нужный вариант из последовательно отображаемых списков, а для возврата к предыдущему экрану выделяют отдельную кнопку. Навигация в прямом направлении осуществляется путем нажатия цифровых клавиш, представляющих нумерованные списки вариантов выбора, а для навигации в обратном направлении применяется клавиша возврата. Пользователи будут путаться в клавишах и раздражаться, если специфическая для данного устройства метафора навигации при работе с вашим мобильным приложением не срабатывает так, как ожидается.

Другим существенным фактором навигации в пределах приложения является то, каким пользователи видят все устройство в целом. В процессе использования смартфонов их пользователи склонны воспринимать устройство как "одно приложение" в большей степени, чем пользователи Pocket PC или Tablet PC. На смартфонах концепция запуска приложений или переключения между ними отражена слабо; вместо этого пользователь представляет себе все происходящее как переключение между различными экранами устройства. Вследствие такого размытия границ приложения важность следования привычным моделям навигации в подобных ситуациях еще более возрастает. В общем случае можно полагать, что чем меньше размеры устройства, тем в большей степени пользователь будет воспринимать его как единое приложение и поэтому рассчитывать на единообразное поведение всех средств навигации, используемых на этом устройстве.

В отличие от смартфонов устройства Pocket PC ориентированы на то, что ими будут манипулировать двумя руками. Одна рука держит устройство, тогда как второй рукой осуществляют навигацию и выбор нужного варианта. Если приложение предназначено для выполнения на устройствах типа Pocket PC, оборудованных сенсорным экраном и пером в качестве средств ввода, то проект целесообразно сориентировать на оптимальное использование форм-факторов механизмов ввода и вывода. Как ранее уже отмечалось, выбор устройства может определяться тем, создание какой пользовательской среды вы хотите обеспечить своим приложением.

Работая с устройствами, в которых применяется сенсорный экран, необходимо тщательно продумывать размещение элементов пользовательского интерфейса. Необходимо позаботиться о том, чтобы пользователь, работающий пером, не закрывал важные участки экрана, когда его рука скользит над экраном в процессе выбора предлагаемых вариантов; в случае смартфонов такой проблемы не существует, поскольку оперирование только одной рукой гарантирует, что экран всегда остается на виду. В отличие от пользовательских интерфейсов смартфонов метафора вкладок часто служит весьма удобной моделью пользовательского интерфейса для приложений Pocket PC, поскольку размеры экрана в этом случае достаточно велики для того, чтобы отобразить на них навигационные вкладки, а сенсорная природа экрана обеспечивает возможность быстрого перехода с одной вкладки на другую.

Вы должны решить, должно ли ваше приложение быть управляемым одной рукой или двумя. Иногда выбор оборудования определен заранее, в других случаях этот выбор является частью проекта разработки программного обеспечения. Как бы то ни было, выбор устройства диктует и выбор вами "одноручного" или "двуручного" варианта приложения. Очень важно, чтобы вы явно формулировали это решение и делали его обязательным целевым фактором, который надо учитывать при проектировании и тестировании пользовательского интерфейса.

Возрастание роли навигационных средств при уменьшении экранного пространства

Как ранее уже отмечалось, приложения для мобильных устройств используются часто, но на протяжении коротких рабочих сеансов; сравните это с приложениями для настольных компьютеров, сеансы работы с которыми обычно длятся намного дольше. В силу кратковременности рабочих сеансов пользователи мобильных приложений должны получать в свое распоряжение средства навигации, обеспечивающие быстрый доступ к нужной информации. Вообще говоря, чем меньше размеры устройства, тем короче длительность рабочих сеансов и тем выше потребность в средствах быстрой навигации.

Для отображения информации, которая на большом экране может быть представлена вся сразу, в мобильных приложениях должны предусматриваться специальные навигационные средства.

В табл. 13.1 приводятся сравнительные характеристики дисплеев настольных компьютеров, а также устройств Pocket PC и Smartphone. Большинство современных дисплеев для настольных компьютеров имеют размеры свыше 1024×768 пикселей, тем самым предоставляя для отображения информации большое экранное пространство.

Таблица 13.1. Относительные размеры экранов различных устройств

Тип устройства

Типичное разрешение

Количество пикселей

Относительный размер

Настольные компьютеры/лэптопы

1024×768

786432

100%

Pocket PC

240×320

76800

9,77%

Смартфоны

176×220

38720

4,92%

Размеры типичного дисплея Pocket PC обеспечивают менее 10% площади экрана, предоставляемой дисплеями настольных компьютеров с низким и средним разрешением или дисплеями лэптопов. Величина этого показателя для лэптопов составляет 5%.

Это не столь ужасающе, как могло бы показаться, по следующим причинам:

1. Нa дисплеях настольных компьютеров обычно используется больше кнопок, рисунки имеют большие размеры, а для представления информации отводится большее экранное пространство по сравнению с их мобильными собратьями. Как правило, в этом случае на любом информационном экране имеется больше элементов управления, а их группы располагаются на большем расстоянии друг от друга.

2. В случае мобильных устройств от пользователей требуется большая концентрация внимания, и от многих универсальных средств, предоставляемых приложениями для настольных компьютеров, обычно приходится отказываться, перенося акцент на то, что требуется для пользовательских сценариев работы в мобильных условиях.

3. В реальных условиях человек может концентрировать свое внимание в любой момент времени лишь на небольшой части большого экрана. Это означает, что объем информации, которую человек перерабатывает единовременно, сравнительно невелик. Нам только кажется, что мы видим сразу весь экран; на самом деле наш взгляд постоянно блуждает по экрану, выхватывая необходимые участки. Вместе с тем, отсюда следует, что задача переключения между информационными экранами чаще всего возникает в случае мобильных приложений.

Полезной для нас метафорой будет рассмотрение приложения в виде текстового документа и анализ того, как этот факт отражается на различных устройствах:

■ Экраны приложений для настольных компьютеров способны отображать несколько взаимосвязанных абзацев информации. Каждый абзац выражает отдельную идею и представляется на части экрана вместе с элементами управления своего пользовательского интерфейса, которые можно уподобить отдельным предложениям, образующим абзац. Хотя пользователи и не в состоянии воспринять информацию одновременно из всех параграфов, они могут подсознательно и без каких-либо усилий с большой частотой переводить взгляд с одного "абзаца" на другой.

■ Продолжая предыдущую аналогию, можно сказать, что на экране Pocket PC приложение способно отображать только один абзац информации в любой заданный момент времени. Абзац состоит из шести-восьми предложений, каждое из которых аналогично расположенным на экране элементам управления. Навигация между различными абзацами осуществляется с помощью вкладок, находящихся в нижней части экрана. При проектировании пользовательских интерфейсов для экранов с размерами экрана Pocket PC очень важно распределить функциональность между логическими абзацами, определить, какие абзацы являются наиболее значимыми и должны быть представлены в первую очередь, и решить, каким образом пользователь будет переходить от одного абзаца к другому при помощи вкладок. В идеальном случае пользователю должно быть достаточно одного взгляда, чтобы оценить подробное содержимое одного из абзацев информации и суметь понять в общих чертах, какая информация содержится в остальных абзацах. Для переключения между различными "абзацами" информации пользователь должен принимать осознанное решение, обычно — путем выбора вкладки TabControl, расположенной в нижней части сенсорного экрана устройства.

■ Экран приложения на смартфоне отображает несколько "предложений" информации в любой заданный момент времени — вероятнее всего, от одного до двух "предложений". Этого объема достаточно для отображения коротких параграфов, но более крупные темы, требующие "абзацев" большего размера, часто приходится разбивать на два взаимосвязанных информационных экрана. Навигационная метафора основывается либо на одномерном перемещении между экранами с продвижением в прямом или обратном направлении, либо на явном списке экранов. Пользовательский интерфейс может находиться в одном из двух режимов:

• Детальное представление. Пользователь видит информацию в объеме короткого "абзаца", имея возможность переходить к соседним "абзацам" в прямом и обратном направлениях. Так выглядит типичный экран приложения, выполняющегося на смартфоне.

• Общее представление. Пользователю предлагается общий список "абзацев", из которых он может выбрать тот, к которому хочет перейти. Так выглядит навигационный экран на смартфоне, когда используются списки.

Размеры пользовательского интерфейса смартфона не позволяют выводить одновременно общее и детальное представления. Проектируя пользовательские интерфейсы для экранов такого размера, чрезвычайно важно тщательно продумывать, какие понятия на уровне отдельных "предложений" целесообразно отображать, какие "предложения" должны одновременно находиться на экране и выводиться первыми, каким образом должны осуществляться переходы между различными экранами и в каких случаях следует предлагать общее представление.

Списки или вкладки?

Элементы управления List и TabView представляют две распространенные навигационные метафоры пользовательских интерфейсов для мобильных устройств, у каждой из которых есть свои достоинства.

В смартфонах списки используются для представления сразу целого набора вариантов навигации. По самому определению список — это одномерная последовательность вариантов выбора. Списки являются неплохой метафорой пользовательского интерфейса для устройств с относительно небольшими узкими экранами, особенно если устройство снабжено цифровой клавиатурой, которая обеспечивает возможность установки соответствия между физическими пронумерованными кнопками и вариантами выбора, предлагаемыми на экране. Пользователь может сравнительно быстро перемещаться по спискам, просматривая опции на экране и нажимая соответствующие кнопки. Пользователи очень быстро запоминают комбинации клавиш, предназначенных для осуществления переходов между сериями списков ограниченного состава, которые представляют распространенные задачи. Навигация такого рода во многом напоминает голосовые телефонные меню, но работает быстрее в силу своей визуальной, а не слуховой природы; пользователи должны последовательно нажимать соответствующие кнопки для переходов по меню до тех пор, пока не окажутся в нужном им списке. Очень важно, чтобы смысл списков был хорошо понятен, и они были не слишком длинными.

В отличие от одномерной навигационной модели смартфонов, в соответствии с которой пользователь добирается до интересующих его экранов, осуществляя переходы посредством меню, экранное пространство устройств типа Pocket PC достаточно велико для того, чтобы отобразить одновременно одну страницу желаемого пользовательского интерфейса и навигационные опции. Именно по этой причине в приложениях для Pocket PC для отображения пользовательского интерфейса часто применяются вкладки.

Применение вкладок дает возможность эффективно использовать экранное пространство для попеременного отображения их содержимого. Это может приводить к появлению многочисленных элементов управления и обработчиков событий внутри класса и большого объема запутанного кода, многочисленные составные части которого взаимодействуют между собой сложным образом.

Один из полезных способов, позволяющих справиться с этой сложностью, состоит в том, чтобы создать отдельный файл нового класса для каждого элемента управления вкладкой и предусмотреть, чтобы обработчики событий, назначенные элементам управления на вкладке, для выполнения соответствующей обработки обращались к этим классам; тем самым мы обеспечиваем весьма удобную инкапсуляцию, позволяющую изолировать вкладки друг от друга.

На рис. 13.1 представлен основанный на использовании вкладок интерфейс Pocket PC, позволяющий осуществлять навигацию по интерфейсу калькулятора для Pocket PC, предназначенного для выполнения научных расчетов; каждая вкладка предлагает определенную группу сходных по своему назначению функциональных средств, и пользователи могут легко переходить от одной вкладки к другой в зависимости от того, какие расчеты им нужно произвести.

Рис. 13.1.  Предоставление доступа к большому количеству функциональных средств, объединенных в группы, за счет использования вкладок

Пользовательские интерфейсы мобильных телефонов и важность соблюдения единообразия в использовании клавиш

При разработке пользовательских интерфейсов для мобильных телефонов и других устройств с экранами аналогичных размеров очень важно следить за тем, чтобы в процессе навигации по приложению пользователю приходилось как можно реже менять клавиши в процессе выполнения обычных задач. Пользователи будут раздражаться, если в ходе обычной работы с приложением после нажатия кнопки, находящейся вверху слева, вдруг потребуется нажимать кнопку, находящуюся вверху справа; это особенно касается устройств, которыми необходимо оперировать одной рукой. Важность этой простой концепции однокнопочной навигации трудно переоценить, поскольку очень часто ею пренебрегают, в результате чего пользователь вынужден работать с неудобным интерфейсом, который постоянно его раздражает. Пользовательские интерфейсы устройств типа смартфонов часто следуют "прямолинейной" схеме одномерной навигации, в которой одна кнопка означает — "Да, вперед", а другая — "Нет, назад". Тщательно учитывайте специфику навигационной модели мобильного телефона, для которого предназначено ваше приложение; при проектировании и тестировании своего приложения уделяйте большое внимание тому, чтобы оно следовало этой модели.

Сенсорные экраны и важность использования крупных кнопок

При создании пользовательских интерфейсов для устройств с сенсорными экранами часто допускают ошибку, состоящую в том, что элементы управления имеют слишком маленькие размеры. Практическим следствием этого является то, что в процессе использования мобильного приложения пользователь лишь с большим трудом может нажать нужную кнопку или ввести точные данные. Пользователей это очень раздражает, поскольку, теряя возможность надежной координации своих действий, они чувствуют себя крайне неуверенно. Не заставляйте пользователей испытывать стыд за свою неловкость! Проблемы, связанные с недостаточно большими размерами элементов управления, возникают по нескольким причинам:

■ Проектирование и тестирование интерфейсов с использованием программных эмуляторов устройств.  При работе с программным эмулятором устройства на настольном компьютере не составляет труда следить за точным положением указателя мыши и выполнять щелчок в нужном месте экрана. Точно выполнить на эмуляторе необходимые действия с небольшими элементами управления пользовательского интерфейса при помощи мыши гораздо легче, чем сделать то же самое на экране физического устройства с помощью пера.

■ Наличие смещения между сенсорной поверхностью и поверхностью дисплея, а также погрешности калибровки.  Поверхность сенсорного экрана обычно располагается хотя и на небольшом, но не пренебрежимо малом расстоянии от элементов физического дисплея. В зависимости от угла, под которым рассматривается экран, и угла наклона пера относительно поверхности экрана могут возникать неточности, и в действительности щелчок может регистрироваться со смещением от того места, в котором пользователь намеревался его выполнить. В различных устройствах эта проблема может проявляться в разной степени, причем описанный эффект смещения становится более заметным в случае упрочненных устройств, в которых в результате введения защитных слоев соответствующие расстояния несколько возрастают, что только усугубляет последствия указанного эффекта. Кроме того, причиной неточностей могут быть погрешности калибровки сенсорного экрана. Отсюда следует, что точность управления пером может быть меньше той, на которую вы надеетесь.

■ Реальные условия использования.  Возможно, в офисных условиях вам и удастся точно щелкнуть на небольшой кнопке, но что если вам надо воспользоваться приложением, когда вы едете в автобусе, такси, идете по улице или сидите в вагоне поезда? При работе в реальных условиях на пользователя воздействует множество отвлекающих факторов, вибрация и короткие, но неожиданные толчки, которые делают работу с небольшими кнопками на сенсорных экранах весьма затруднительной.

■ Желание "уместить все на одном экране".  Попытки размещения на единственном экране чрезмерного количества информации приводят к скученности элементов управления и уменьшению их размеров. Чем более плотно располагаются элементы управления, тем выше вероятность их неправильного выбора.

■ Привлечение встроенных программных механизмов ввода. В таких устройствах, как Pocket PC, предлагается всплывающая программная клавиатура, которой пользователь может воспользоваться для ввода информации. Это средство доказало свою полезность, однако оно является универсальным, и поэтому в нем предусмотрено множество клавиш, которые должны быть все отображены на небольшом экранном пространстве. Если ваши запросы носят более специфический характер, то механизмы ввода, предусматриваемые пользовательским интерфейсом, вам придется оптимизировать.

На рис. 13.2 показано то же самое приложение, в котором используется программная клавиатура (software input panel — SIP) Хотя программная клавиатура представляет собой в целом неплохой механизм для ввода букв, цифр и символов, укрупненные элементы управления пользовательского интерфейса, предназначенные специально для калькулятора, применяемого при проведении научных расчетов, предлагают более точный и легкий в использовании интерфейс. Типовая программная клавиатура удобна для ограниченного ввода информации общего назначения, но ее можно и необходимо улучшать в тех случаях, когда задаче требуется более специфический ввод. Проектируя пользовательские интерфейсы для устройств с сенсорными экранами, вы должны делать размеры элементов управления настолько большими, а их целевое назначение настолько специализированным, насколько это возможно.

Оптимизируйте ввод обычных данных

При всякой удобной возможности старайтесь облегчить пользователю задачу быстрого и точного ввода обычной информации. Поскольку полнофункциональная клавиатура, при помощи которой можно было бы ввести данные, в распоряжении пользователей мобильных телефонов оказывается редко, ваше содействие им в отношении ввода данных будет весьма уместным.

Рис. 13.2. Сравнение различных разновидностей механизмов ввода в пользовательском интерфейсе

Один из способов организации ввода данных состоит в том, чтобы пользователь осуществлял ввод вручную, буква за буквой (например, "6 января 2006" или "6/1/2006"), однако такой ввод будет занимать слишком много времени и сопровождаться неминуемыми ошибками, не говоря уже о проблеме учета различий в национальных стандартах форматов дат. Лучше предоставить пользователю окна списков для выбора дня, месяца и года, тем самым избавляя его от необходимости вводить эти данные. Еще лучше использовать всплывающие элементы управления или диалоговые окна, отображающие календарь, что позволит быстро выбрать дату, которая и заполнит соответствующее поле ввода. (Примечание. С учетом того, что необходимость во вводе дат возникает очень часто, можно ожидать, что в будущих версиях .NET Compact Framework календарь будет добавлен, однако общая проблема ввода сложных данных будет по-прежнему оставаться актуальной.)

При проектировании пользовательских интерфейсов для мобильных устройств иногда допускают ошибку, пытаясь сэкономить экранное пространство и память программы за счет использования элементов TextBox для ввода сложных данных; это вынуждает пользователя вручную вводить, например, такие сложные данные, как даты. В лучшем случае достижение такой "эффективности" — это пиррова победа; затраты экранного пространства, памяти программы и ваших усилий, обеспечивающие экономию времени пользователя и повышение точности ввода, никогда не будут напрасными.

Описанный подход проиллюстрирован рис. 13.2, на котором можно видеть как кнопки, так и выпадающие списки, которые облегчают ввод данных для калькулятора, предназначенного для выполнения научных расчетов. Например, вместо того чтобы побуквенно вводить выражение sin(), обозначающее тригонометрическую функцию, пользователю достаточно просто выбрать нужную функцию в выпадающем списке. Часто встречающиеся переменные x, у и z представлены кнопками на форме вместе с другими распространенными математическими символами. Ввод сложных математических формул с помощью этого интерфейса выполняется гораздо быстрее, чем при вводе вручную посредством стандартной экранной клавиатуры. Несомненно, описанный интерфейс может быть дополнительно оптимизирован.

Убедитесь в том, что для механизмов автоматизированного ввода предусмотрены параллельные механизмы ввода вручную

В специализированных мобильных приложениях часто применяется нестандартное оборудование, позволяющее ускорить ввод данных. Хорошим примером такого оборудования может служить устройство для считывания штрих-кодов, подключенное к мобильному устройству, что позволяет очень быстро считывать данные с этикеток со штрих-кодами, наклеенных на физические объекты. Если мобильное приложение должно взаимодействовать с физическим окружением, то использование сканеров штрих-кодов и даже устройств для распознавания речи способно существенно расширить сферу применимости приложения и повысить производительность труда пользователя. Подобные механизмы ввода реальных данных следует изучать и использовать при любой возможности, если только это представляется интересным. Не следует, однако, впадать в крайность и полагаться только на такие механизмы. Этикетки, на которые нанесены штрих-коды, и считывающие устройства могут загрязняться или повреждаться, а использование устройств для распознавания речи может затрудняться повышенным уровнем шумов в окружающей среде и нерегулярными ежедневными изменениями характеристик человеческого голоса, что увеличивает вероятность погрешностей. Поэтому очень важно всегда предусматривать механизм ручной подстраховки, который можно применять для ввода данных вручную в тех случаях, когда автоматизированные механизмы ввода дают сбой. По той же причине, по которой кассирам в супермаркетах предоставляется возможность ввести код продукта вручную, если неоднократные попытки считывания кода сканером оказались безуспешными, в вашем мобильном приложении, отвечающем самому последнему слову техники, должен быть предусмотрен специальный пользовательский интерфейс, обеспечивающий быстрый ввод данных вручную в тех случаях, когда сделать это при помощи средства автоматизированного ввода не удается. О мобильном приложении, которое 90% времени работает нормально, но остальные 10% времени не в состоянии функционировать из-за неполадок, нельзя сказать, что оно работает нормально и надежно; вместе с тем, если 10% времени приложение вынуждено требовать ввода вручную, но прекраснейшим образом функционирует 90% времени, то оно может считаться вполне работоспособным.

Тестирование на эмуляторах и физических устройствах

Программные эмуляторы устройств — вещь замечательная. Они позволяют вам ускорить процессы проектирования, тестирования и отладки приложения, избавляя от необходимости настройки физических устройств, переключения внимания с компьютера на устройство и множества других помех, неизбежно связанных с включением в работу дополнительного оборудования. Точно так же программные эмуляторы отлично подходят для демонстрации приложения; их изображения можно легко проецировать на большой экран, и вы можете свободно хранить в своем лэптопе, который берете с собой на время переездов, множество различных эмуляторов, что избавляет вас от необходимости возить с собой связку кабелей и чемодан, набитый электроникой.

(Их особенно "любит" охрана в аэропортах.) Вместе с тем, для чего эмуляторы совершенно не годятся — так это для тестирования производительности вашего мобильного приложения или удобства работы с его пользовательским интерфейсом. В связи с этим вы должны тестировать свои приложения только на физических устройствах. Как бы вы ни старались, результаты тестирования, полученные с использованием эмулятора, не могут считаться надежными. Ниже приводится несколько причин того, почему это так.

■ Эмуляторы не приходится физически удерживать в руках. В процессе использования большинства мобильных устройств их удерживают в руке и осуществляют все необходимые манипуляции либо пальцем той же руки (при работе одной рукой), либо второй рукой. Проделать то же самое с изображением на экране невозможно.

■ Мышь и клавиатура настольного компьютера/лэптопа могут ввести вас в заблуждение. Ввод букв в текстовом поле при помощи клавиатуры — это не то же самое, что ввод данных с использованием 12-кнопочной клавиатуры телефона. Выполнить щелчок мышью — это не то же самое, что надавить пальцем или пером в нужной точке экрана.

■ Размеры вашей руки никак не учитываются при работе с компьютерным экраном. При использовании эмулятора для элементов управления пользовательского интерфейса трудно подобрать наиболее оптимальное расположение, поскольку курсор мыши имеет очень небольшие размеры и не закрывает экран при его перемещении над кнопками. Курсор мыши вообще физически ни с чем не связан. В отличие от этого перо, используемое совместно с сенсорным экраном, имеет заметные размеры и физически связано с вашей рукой, которая имеет еще большие размеры; поэтому, когда вы пытаетесь надавить на кнопку, вы непроизвольно закрываете значительную часть экрана.

■ Настольные компьютеры и лэптопы обеспечивают более высокую точность указания, чем мобильные устройства. В случае настольных компьютеров вы имеете дело с плоской поверхностью экрана, где указатель отображается на той же поверхности, что позволяет вам физически увидеть, когда именно вы должны нажать кнопку. В то же время, на сенсорном экране мобильного устройства указатель мыши не отображается. "Щелчок", который осуществляется путем надавливания на экран, происходит примерно в той точке, в которой, по мнению пользователя, он должен быть выполнен, но на фактическое положение этой точки оказывает влияние смещение, зависящее от угла, под которым пользователь смотрит на экран, наличие некоторого промежутка между элементами дисплея и сенсорной поверхностью, и калибровка самой сенсорной поверхности. На практике это означает, что существует физический предел размеров элемента управления пользовательского интерфейса, ниже которого пользователь уже может "промахнуться" при надавливании на элемент.

■ Эмулятор можно легко сбросить, и он не используется для других целей в промежутках между выполнением тестовых запусков вашего приложения. Эмулированный смартфон — это вовсе не тот самый телефон, который вы используете для телефонных переговоров и ведения расписания встреч. Тот факт, что физическое устройство часто предназначается не только для определенного способа его использования, но и для выполнения других функций, имеет очень большое значение. Вам необходимо убедиться в нормальной работе приложения в условиях, когда устройство функционирует в течение 24 часов 7 дней в неделю, а также попытаться понять, каким образом другие приложения, выполняющиеся на устройстве, могут влиять на ваше приложение. Добиться точной имитации такого рода реальных условий эксплуатации приложения очень трудно.

Учет перечисленных выше факторов играет важную роль в процессе проектирования приложений для мобильных устройств, но не может заменить тестирование приложения на реальном оборудовании. По существу, единственным способом реального тестирования пользовательского интерфейса вашего приложения может быть его тестирование на том оборудовании, для выполнения на котором оно предназначено.

На рис. 13.3 иллюстрируется, каким образом переход от эмулятора к физическому устройству может повлиять на пригодность пользовательского интерфейса. В качестве примера взята программа для изучения иностранных слов, в которой анимированный персонаж перемещается по экрану в зависимости от того, правильно или неправильно пользователь ответил на заданный вопрос, выбрав по своему усмотрению ответ из нескольких предложенных вариантов. Когда для проектирования и тестирования приложения используется эмулятор устройства, все выглядит прекрасно: варианты выбора отлично размещаются на экране, а навигация в пределах приложения не составляет никакого труда.

Вместе с тем, тестирование на реальном устройстве позволяет выявить ряд существенных проблем. По мере того как пользователь перемещает руку над экраном для выбора нужного варианта ответа, он невольно закрывает ею вопрос и игровое поле. Таким образом, выбирая вариант ответа, самого вопроса пользователь не видит.

Рис. 13.3. Сравнение удобства использования пользовательского интерфейса на эмуляторе и физическом устройстве

Кроме того, чтобы увидеть результаты своего выбора, пользователь должен убрать руку с экрана; если он не сделает это достаточно быстро, то может пропустить часть действия, происходящего в это время на экране, что в некоторой мере лишит его удовольствия от общения с приложением. Совершенно очевидно, что такую ситуацию нельзя считать самой оптимальной, но это становится очевидным лишь при условии, что тестирование выполняется на физическом устройстве, поскольку при работе с эмулятором, выполняющемся на экране ПК, рука пользователя экрана не закрывает.

На рис. 13.4 проиллюстрированы два возможных способа улучшения рассматриваемого нами интерфейса. Оба способа обеспечивают для пользователя лучшие условия обзора игрового поля, причем предпочтение следует отдать экрану справа, поскольку он позволяет видеть вопрос в процессе выборе варианта ответа; в то же время, в реальных условиях этот фактор может не иметь большого значения. Проблемы, связанные с тем, каким именно образом располагаются руки пользователя в промежутках между выполнением операций выбора нужного варианта, и каковы условия физического равновесия устройства, когда оно удерживается в руке, являются важными факторами оптимального дизайна. В данном случае, именно из этих соображений и после длительного тестирования, я выбрал вариант интерфейса, представленный на рисунке слева.

Рис. 13.4. Более удобные альтернативные варианты компоновки экрана, основанные на результатах тестирования приложения на физическом устройстве

Привлечение программных эмуляторов устройств может значительно сократить сроки разработки и отладки приложения, и эту возможность следует использовать при всяком удобном случае, но это не избавляет вас от необходимости тщательного тестирования того, насколько удобно будет пользоваться интерфейсом на физическом устройстве. При этом вы будете каждый раз удивляться, как много пищи для размышлений может дать такое тестирование.

Проектируйте код пользовательского интерфейса мобильного приложения таким образом, чтобы его можно было легко тестировать и модифицировать

Проектирование пользовательского интерфейса — это итеративный процесс. Вы должны быть готовы к тому, что проект придется пересматривать несколько раз в процессе разработки и тестирования приложения по мере того, как будет становиться все более понятным, насколько приложение удобно в использовании. Если код пользовательского интерфейса тесно переплетен с логикой приложения, то выполнить это будет очень трудно; внесение изменений в пользовательский интерфейс потребует кропотливого изучения всей логики приложения с той целью, чтобы выявить все его части, которые могут влиять на пользовательский интерфейс. Вследствие этого изменить поведение интерфейса вам будет весьма трудно. Отыскивать в коде пользовательского интерфейса, насыщенном различного рода взаимозависимостями, ошибки, появляющиеся в результате его изменения, и устранять их, не нарушая работоспособности приложения, очень трудно, поскольку они будут разбросаны по всему приложению, а не сконцентрированы в одном месте и надежно инкапсулированы.

В высшей степени целесообразно проектировать логику приложения таким образом, чтобы отделить ее от пользовательского интерфейса. Обе части должны взаимодействовать между собой посредством небольшого и четко определенного набора интерфейсов. На рис. 13.5 показано, как реализовать эту идею за счет использования двух механизмов.

1. Использование конечного автомата для контроля функционирования элементов управления.  Конечный автомат великолепно подходит для управления всеми нуждами пользовательского интерфейса мобильного приложения. Экран мобильного приложения является ценным и дефицитным ресурсом, и этот ресурс требует весьма бережливого отношения. Необходимо следить за эффективным использованием экранного пространства в процессе того, как пользователь переводит приложение из одного состояния в другое. При наличии конечного автомата, который показывает, скрывает и перемещает элементы управления по экрану в соответствии с необходимостью, эту задачу можно решить весьма эффективно. Абстрагирование всех режимов работы пользовательского интерфейса в одном конечном автомате обеспечивает максимальную гибкость процесса внесения изменений в модель экранного дисплея, избавляя вас от необходимости просматривать и изменять множество кода, распределенного между различными функциями и обработчиками событий пользовательского интерфейса.

2. Использование косвенных функций для обновления пользовательского интерфейса. Изменение информации, отображаемой на экране мобильного устройства, может осуществляться двумя способами: 1) непосредственно, путем использования встроенного кода (например, Label1.Text = newText) и 2) косвенно (например, UpdateDownloadStatusText(newText);). Преимущество косвенного подхода заключается в том, что он позволяет вашему коду отделить фактически используемый элемент управления от того обновления, которое вы хотите выполнить. Косвенная функция UpdateDownloadStatusText(newText); сегодня может обновлять элемент Label1, но, возможно, завтра вы решите, что лучше будет отобразить текст поверх растрового изображения или вывести его в виде текста, прокручиваемого в узкой полоске экрана. На рис 13.5 показана стрелка, направленная вниз от пользовательского интерфейса (ПИ) к блоку функций обновления ПИ, а также стрелки, направленные вверх от блока логики приложения. Стрелка, направленная вниз от пользовательского интерфейса, представляет код обновления дисплея, который выполняется в результате обработки событий, генерируемых пользовательским интерфейсом. Например, обычной реакцией на щелчок на кнопке может быть обновление текста в ярлыке или окне списка. Вместо того чтобы выполнять это обновление непосредственно в обработчике событий кнопки, можно поступить гораздо более гибко и воспользоваться вызовом обобщенной функции UpdateXXXXXXX(), которая и выполнит всю работу. Введение промежуточной функции позволяет разорвать прочную связь между обоими элементами управления и при необходимости использовать другую реализацию одного из них. Проектируя пользовательский интерфейс своего мобильного приложения, вы должны избегать тесного связывания как элементов управления с логикой приложения, так и отдельных элементов управления, являющихся частью пользовательского интерфейса, между собой. Наличие единственного уровня косвенности позволяет устранить такое тесное связывание.

Использование конечного автомата и косвенных функций обновления элементов управления пользовательского интерфейса не только позволяет вам легко пересматривать уровень представления вашего мобильного приложения, но и существенно облегчает перенос приложения между устройствами различных классов. Тесная связь между кодом пользовательского интерфейса и логикой приложения затрудняет задачу переноса приложения на устройства с другим форм-фактором. И наоборот, хорошо определенный набор функций, который управляет взаимодействиями между логикой вашего приложения и его уровнем представления, намного облегчает адаптацию приложения при переходе от одного класса устройств к другому. Этот фактор очень важен, если вы заинтересованы в обеспечении гибкости сопровождения новых типов устройств в будущем. Как обсуждалось ранее в этой главе, концепция "пишется однажды — выполняется везде" не особенно благоприятствует тому, чтобы единственное приложение в двоичной форме могло обеспечивать богатый интерфейс на различных классах устройств, но это вовсе не означает, что вы не имеете возможности проектировать свое мобильное приложение таким образом, чтобы обеспечивалась его легкая переносимость. Вы можете и должны это делать.

Рис. 13.5. Надежное отделение логики приложения от пользовательского интерфейса

Модель состояний для компоновки пользовательского интерфейса и управления им

Чтобы проиллюстрировать плодотворность концепции пользовательского интерфейса, управляемого конечным автоматом, целесообразно привести простой пример. Этот пример продемонстрирует эффективность подхода, основанного на конечном автомате, как фактора, облегчающего внесение изменений в пользовательский интерфейс по мере эволюции проекта. В продолжение сценариев, иллюстрируемых рисунками 13.3, 13.4 и 13.5, код рассматриваемого примера реализует основные компоненты пользовательского интерфейса приложения для Pocket PC, предназначенного для изучения в игровой форме слов иностранного языка. По мере того как пользователь приложения отвечает на вопросы, выбирая правильный, по его мнению, ответ из нескольких предложенных вариантов, в секторе игрового поля осуществляются некоторые действия, соответствующие тому, какой ответ был дан пользователем — правильный или неправильный.

Сектор игрового поля занимает примерно 60% доступной поверхности экрана; его назначение состоит в том, чтобы развлекать пользователя и поддерживать в нем интерес к изучению иностранных слов. Чтобы упростить задачу, код пользовательского интерфейса приложения на данном этапе будет представлять игровое поле в виде растрового прямоугольника желтого цвета, отображаемого в рамке. Вместо этого вы можете заполнить рамку загружаемым растровым изображением, чтобы придать игровому полю более реалистический вид и наблюдать за происходящими в нем изменениями, вызываемыми взаимодействием пользователя с приложением. В данном приложении концепции пользовательского интерфейса иллюстрируются на примере игры с множественным выбором, но эти концепции в равной степени применимы к любому приложению, начинай от бизнес-приложений и заканчивая сценарными играми; модель пользовательского интерфейса на основе конечного автомата отличается поразительной универсальностью.

Как показано на рис. 13.6, пользовательский интерфейс мобильного приложения имеет четыре состояния:

1. Начальный экран. Мы хотим, чтобы при первоначальном запуске приложения отобразился экран, который приглашает их в игру, предоставляет необходимые инструкции и позволяет легко начать игру. Я остановился на очень простом варианте экрана, отображающем лишь "стартовую" кнопку и игровое поле. Возможно, вы захотите добавить текстовые инструкции или запустить анимацию на начальном экране, чтобы сразу же разжечь интерес пользователя к игре. В любом случае пользователь должен только щелкнуть на кнопке Start, после чего он сразу попадает в следующее состояние игры.

2. Формулировка вопроса. В этом состоянии мобильное приложение предлагает пользователю перевести предложенное слово. В нашем коде мы решили отображать вопрос в элементе управления TextBox, но это вовсе не является обязательным. Например, вопрос может отображаться в элементе управления Label или выводиться поверх растрового изображения игрового поля, если оно имеется. Если целевое устройство поддерживает синтезатор речи, то вопрос может задаваться даже голосом. Мы решили использовать текстовое поле, работающее в режиме только для чтения, поскольку его возможности нас полностью устраивают и позволяют без труда отображать большие объемы информации за счет использования полос прокрутки, если это потребуется. В дополнение к отображению вопроса приложение предлагает пользователю выбрать один из двух способов ответа на него. Пользователь может выбрать вариант Challenge Me! (Ну-ка, спрашивай!), если считает, что знает правильный ответ, или Can't Think of It (Ума не приложу), если нуждается в дальнейших подсказках; для каждого из этих двух вариантов выбора могут быть предусмотрены различные правила подсчета очков. Чтобы не усложнять пробный код, в нашей реализации оба варианта обрабатываются по одному и тому же принципу и перемещают пользователя в следующее состояние приложения независимо от того, какой вариант был выбран; возможно, вы захотите добавить код, который будет по- разному подсчитывать очки для этих вариантов, или просто исключите одну кнопку, если решите этого не делать. В нашей реализации мобильного приложения для представления обоих вариантов было решено использовать элементы управления Button, но, как и ранее, такое решение не является обязательным; точно так же для предоставления этих вариантов выбора можно использовать переключатели или выпадающий список, если эти метафоры являются более подходящими для целевого устройства. Какую метафору пользовательского интерфейса выбрать, зависит от природы приложения, а также от типа устройства, на котором оно будет выполняться.

3. Предоставление пользователю нескольких вариантов ответа. В этом состоянии приложения наша игра для мобильных устройств предлагает пользователю несколько вариантов ответа на заданный ему вопрос. Для пользовательского интерфейса Pocket PC мы вновь решили использовать элементы управления Button; для смартфонов более подходящими были бы, пожалуй, нумерованные окна списков. Кроме того, в этом состоянии мы решили динамически уменьшать размер элемента управления TextBox, чтобы кнопки всех вариантов выбора уместились на экране. Пользователи могут угадывать правильный ответ до тех пор, пока он не будет получен. В нашей реализации в случае выбора неправильного ответа соответствующая кнопка затеняется (для ее свойства Enabled устанавливается значение false). В логику нашего приложения также можно включить код для отображения того, что в действительности означает неверно выбранное вами слово. Поскольку, в силу ограниченности размеров текстового окна, для отображения этой информации места недостаточно, мы могли бы вывести этот текст поверх растрового изображения игрового поля; этот вариант реализации мы также оставляем на усмотрение читателя.

4. Предоставление пользователю окончательной оценки всем его попыткам ответа на вопрос и ожидание от него запроса на вывод следующего вопроса. В этом состоянии игра предоставляет пользователю возможность просмотреть выбранные им варианты ответа для закрепления знаний. Поскольку работа со словом завершена, никакой необходимости в том, чтобы отображать вопрос или предлагать варианты ответов пользователю, больше нет. По этой причине приложение скрывает все кнопки, используемые для отображения вариантов ответа, и использует полученное дополнительное пространство для расширения области текстового окна. Увеличение размеров текстового окна предоставляет в наше распоряжение достаточно много свободного места, чтобы в нем можно было отобразить текст, воспроизводящий все попытки пользователя правильно ответить на вопрос. Например, мы могли бы отобразить все слова, предложенные в качестве различных вариантов ответа, вместе с их правильным переводом; также можно было бы отобразить пример предложения, демонстрирующего использование слова, которое является правильным ответом.

Представленный в листинге 13.1 код демонстрирует несколько полезных концепций построения гибких пользовательских интерфейсов мобильных устройств. Проектируя этот пользовательский интерфейс, я начал с идеи размещения элементов поверх игрового поля. Зная, что окончательный выбор подходящего пользовательского интерфейса определится лишь после его тестирования в реальных условиях и внесения соответствующих изменений, при написании кода было желательно использовать принципы централизации и абстрагирования кода таким образом, чтобы процесс его модифицирования не вызывал особых затруднений и не заставлял вносить сложные изменения в разных местах кода пользовательского интерфейса или логики приложения. Именно поэтому я решил поместить основную часть кода динамической компоновки в функцию конечного автомата, которая называется StateChangeForGameUI(). Любые изменения размеров или позиционирование элементов управления управляются этим кодом. Если нам необходимо немного подправить компоновку элементов или даже радикально изменить ее, мы знаем, что все необходимое осуществляется здесь; благодаря этому снижается объем работы по отслеживанию сложной и разбросанной по всему коду логики компоновки, а приложение становится более надежным. Возложив всю ответственность за поддержание компоновки пользовательского интерфейса на одну функцию (конечный автомат), мы значительно облегчили выполнение экспериментов с различными возможными вариантами компоновки, поскольку теперь это не сможет дестабилизировать работу остальной части кода пользовательского интерфейса и логики приложения.

На рис. 13.6 и 13.7 показаны две возможные конфигурации нашей мобильной обучающей словарной игры. Важно подчеркнуть, что при переходе от одной модели компоновки к другой меняется не только положение элементов пользовательского интерфейса на экране, но и их взаимное относительное положение. На рис. 13.6 текстовое окно динамически изменяет свои размеры, находясь над другими элементами экрана.

Рис. 13.6. Отображение пользовательского интерфейса в верхней части формы

На рис. 13.7 текстовое окно динамически изменяет свои размеры, располагаясь ниже всех остальных кнопок, находящихся на экране. Так как в обоих случаях привязка расположения текстового окна к окружающим его элементам осуществляется по-разному, в приложении для каждого из этих случаев предусмотрена своя логика. Столь же легко реализовать и другие возможные варианты расположения и упорядочения элементов управления; поскольку код, ответственный за позиционирование, надежно абстрагирован и централизован в одном конечном автомате, мы можем получить любое желаемое расположение элементов на экране, выполняя ту логику пользовательского интерфейса, которая для этого нужна. Остальная часть логики пользовательского интерфейса и приложения нашими экспериментами не затрагивается.

Не менее важен тот факт, что для обновления содержимого пользовательского интерфейса мы создали абстрагированные функции. Весь код, связанный с обновлением содержимого пользовательского интерфейса, сосредоточен в конечном автомате или в отдельных функциях, предназначенных для решения этой задачи; непосредственное обновление содержимого пользовательского интерфейса в коде обработчиков событий для элементов управления ни в одном случае не выполняется.

Рис. 13.7. Отображение пользовательского интерфейса в нижней части формы

Такое сочетание абстрагирования и централизации значительно упрощает изменение конфигурации пользовательского интерфейса с целью использования тех или иных элементов управления в соответствии с необходимостью. Это важно не только с точки зрения того, чтобы интерфейс принял очертания, наиболее подходящие для устройств любого заданного класса, но и с точки зрения переносимости приложения с одного устройства на другое. Например, если наше мобильное приложение необходимо перенести на смартфон, то в нем, вероятно, следует использовать другой набор элементов управления пользовательского ввода-вывода. Поскольку в смартфонах сенсорный экран отсутствует, кнопки не являются наилучшим решением для выбора правильного варианта ответа из нескольких предложенных; в этом случае гораздо лучше использовать списки.

Переделка кода, приведенного в листинге 13.1, для использования списка вместо кнопок множественного выбора не составляет особого труда. Потребовалось бы внести еще и другие изменения в код пользовательского интерфейса, но в силу того, что логика приложения и код пользовательского интерфейса надежно инкапсулированы, а взаимодействие между ними централизовано в известном наборе функций, работа по переносу приложения не должна доставить особых затруднений. Тщательно продуманная инкапсуляция, абстрагирование и централизация обеспечивают возможность создания отличных пользовательских интерфейсов для любых классов устройств с гораздо большей легкостью, чем в случае децентрализованного кода и без использования конечного автомата.

Пример кода, демонстрирующий две различные модели компоновки для одного и того же приложения

Приведенный в листинге 13.1 код вносится в форму в проекте Pocket PC. Для создания и запуска приложения потребуется выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму перечисленные ниже элементы управления. Примечание. Пусть вас не волнуют точные размеры и расположение этих элементов управления; разместите их так, чтобы вам было удобно работать с ними на экране. Размеры и расположение элементов управления динамически изменяются во время выполнения приведенным ниже кодом пользовательского интерфейса.

• TextBox; переименуйте его в textBoxAskQuestion, установите значение true для его свойств MultiLine и ReadOnly.

• PictureBox; переименуйте его в pictureBoxGameBoard.

• Button; переименуйте его в buttonShowAnswers_AdvancedVersion.

• Button; переименуйте его в buttonShowAnswers_SimpleVersion.

• Button; переименуйте его в buttonAskQuestion.

• Button; переименуйте его в buttonAnswer0.

• Button; переименуйте его в buttonAnswer1.

• Button; переименуйте его в buttonAnswer2.

• Button; переименуйте его в buttonAnswer3.

• Button; переименуйте его в buttonAnswer4.

• Button; переименуйте его в buttonAnswer5.

4. Дважды щелкните на пустом участке формы в окне конструктора форм и введите приведенный ниже код Form_Load в автоматически сгенерированную и подключенную функцию обработчика событий.

5. Поочередно переходя от одной из вышеперечисленных кнопок Button к другой, щелкните на кнопке в окне конструктора форм. Введите приведенный ниже код button<ИмяКнопки>_Click в автоматически сгенерированную и подключенную функцию обработчика событий.

6. Введите оставшуюся часть приведенного ниже кода.

7. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения приложения в верхней правой части формы появится кнопка OK, с помощью которой вы сможете легко закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения

8. В самом верху файла кода формы введите в качестве первой строки #define PLAYFIELD_ON_BOTTOM.

9. Дважды запустите приложение: один раз с подключенной директивой условной компиляции #define PLAYFIELD_ON_BOTTOM, а второй — с предварительным отключением этой же директивы при помощи символов комментария (то есть //#define PLAYFIELD_ON_BOTTOM), и отметьте для себя различия между двумя моделями компоновки. Запустите оба варианта на физическом устройстве и выясните, какая модель является более предпочтительной с точки зрения внешнего вида приложения и удобства работы с ним, а также возможностей обзора игрового поля.

10. Попробуйте изменить компоновку элементов управления по своему усмотрению. Вероятно, часть элементов управления пользовательского интерфейса имело бы смысл поместить выше игрового поля, а часть — ниже. Возможно, некоторые элементы должны располагаться поверх игрового поля, тогда как другие — справа или слева от него. Внося соответствующие изменения в код конечного автомата, вы легко сможете проверить и уточнить свои предположения.

Листинг 13.1. Использование конечного автомата для экспериментов с двумя различными вариантами компоновки пользовательского интерфейса

//--------------------------------------------------------------------------

//Конечный автомат, который управляет отображением кнопок, закрываемых рукой

//--------------------------------------------------------------------------

private enum GameUIState {

startScreen = 1,

waitForNextQuestion = 2,

waitForUserToStateKnowledge = 4,

waitForUserToAnswerMultipleChoice = 8

}

//Текущее состояние игры

private GameUIState m_GameUIState;

//==========================================================================

//Конечный автомат, используемый для управления пользовательским интерфейсом

//==========================================================================

private void StateChangeForGameUI(GameUIState newGameUIState) {

m_GameUIState = newGameUIState;

switch (newGameUIState) {

case GameUIState.startScreen:

buttonAskQuestion.Visible = true;

buttonAskQuestion.Text = "Start";

//Скрыть текстовое окно

textBoxAskQuestion.Visible = false;

SetAnswerButtonVisibility(false);

SetDifficultyButtonVisibility(false);

break;

case GameUIState.waitForNextQuestion:

setQuestionText("List answer details here... \r\n" +

"Lots of space to write...\r\n" +

"Waiting for user to select next question...");

textBoxAskQuestion.Visible = true;

buttonAskQuestion.Text = "Next";

buttonAskQuestion.Visible = true;

//Убедиться в том, что кнопка отображается на переднем плане

buttonAskQuestion.BringToFront();

SetAnswerButtonVisibility(false);

SetDifficultyButtonVisibility(false);

#if PLAYFIELD ON_BOTTOM //ПОЛЕ ИГРЫ располагается под пользовательскими

//элементами управления

textBoxAskQuestion.Height = pictureBoxGameBoard.Top - 2;

#else //ПОЛЕ ИГРЫ располагается над пользовательскими

//элементами управления

textBoxAskQuestion.Top = pictureBoxGameBoard.Top + pictureBoxGameBoard.Height + 2;

textBoxAskQuestion.Height = this.Height - textBoxAskQuestion.Top;

#endif

break;

case GameUIState.waitForUserToStateKnowledge:

SetTextForVocabularyQuestion();

textBoxAskQuestion.Visible = true;

buttonAskQuestion.Visible = false;

SetAnswerButtonVisibility(false);

SetDifficultyButtonVisibility(true);

#if PLAYFIELD_ON_BOTTOM //ПОЛЕ ИГРЫ располагается под пользовательскими

//элементами управления

textBoxAskQuestion.Height = buttonShowAnswers_AdvancedVersion.Top - 2;

#else //ПОЛЕ ИГРЫ располагается над пользовательскими

//элементами управления

textBoxAskQuestion.Top = buttonShowAnswers_AdvancedVersion.Top + buttonShowAnswers_AdvancedVersion.Height + 2;

textBoxAskQuestion.Height = this.Height - textBoxAskQuestion.Top;

#endif

break;

case GameUIState.waitForUserToAnswerMultipleChoice:

buttonAskQuestion.Visible = false;

SetDifficultyButtonVisibility(false);

//Сделать кнопки доступными, чтобы пользователь мог щелкать на них

SetAnswerButtonEnabled(true);

SetAnswerButtonVisibility(true);

#if PLAYFIELD_ON_BOTTOM //ПОЛЕ ИГРЫ располагается под пользовательскими

//элементами управления

textBoxAskQuestion.Height = buttonAnswer0.Top - 2;

#else //ПОЛЕ ИГРЫ располагается над пользовательскими

//элементами управления.

//Разместить текстовое окно таким образом, чтобы экран использовался

//эффективно

textBoxAskQuestion.Top = buttonAnswer5.Top + buttonAnswer5.Height + 2;

textBoxAskQuestion.Height =this.Height - textBoxAskQuestion.Top;

#endif

break;

//======================================================================

//Задать статическую компоновку нашего пользовательского интерфейса.

//Сюда входят все элементы, позиции которых остаются фиксированными.

//Изменения в остальные свойства внесет конечный автомат

//пользовательского интерфейса

//======================================================================

private void SetStartControlPositionAndState() {

pictureBoxGameBoard.Width = 240;

pictureBoxGameBoard.Height = 176;

//Установить размеры кнопок множественного выбора вариантов ответов

const int answerButtons_dx = 117;

const int answerButtons_dy = 18;

buttonAnswer0.Width = answerButtons_dx;

buttonAnswer0.Height = answerButtons_dy;

buttonAnswer1.Size = buttonAnswer0.Size;

buttonAnswer2.Size = buttonAnswer0.Size;

buttonAnswer3.Size = buttonAnswer0.Size;

buttonAnswer4.Size = buttonAnswer0.Size;

buttonAnswer5.Size = buttonAnswer0.Size;

buttonShowAnswers_AdvancedVersion.Width = answerButtons_dx;

buttonShowAnswers_AdvancedVersion.Height = 24;

buttonShowAnswers_SimpleVersion.Size = buttonShowAnswers_AdvancedVersion.Size;

//Расстояние (в пикселях) между соседними кнопками

const int dx_betweenButtons = 3;

const int dy_betweenButtons = 2;

const int answerbuttons_beginX = 3;

//Создать задний план для нашего изображения, чтобы мы видели

//его в процессе тестирования

System.Drawing.Bitmap gameBoard;

gameBoard = new System.Drawing.Bitmap(pictureBoxGameBoard.Width, pictureBoxGameBoard.Height);

System.Drawing.Graphics gameboard_gfx;

gameboard_gfx = System.Drawing.Graphics.FromImage(gameBoard);

gameboard_gfx.Clear(System.Drawing.Color.Yellow);

System.Drawing.Pen myPen = new System.Drawing.Pen(System.Drawing.Color.Blue);

gameboard_gfx.DrawRectangle(myPen, 2, 2, gameBoard.Width-4, gameBoard.Height-6);

myPen.Dispose();

gameboard_gfx.Dispose();

pictureBoxGameBoard.Image = gameBoard;

//Разместить текстовое окно, в котором содержатся задаваемые вопросы,

//a также подробные ответы для пользователей

textBoxAskQuestion.Left = 0;

textBoxAskQuestion.Width = 240;

buttonAskQuestion.Width = 64;

buttonAskQuestion.Height = 20;

#if PLAYFIELD_ON_BOTTOM //ПОЛЕ ИГРЫ располагается под пользовательскими

//элементами управления

const int answerbuttons_beginY = 42;

const int showanswers_beginY = 77;

//--------------------------------------------------------

//Задать кнопки выбора вариантов Easy или Hard режима игры

//--------------------------------------------------------

buttonShowAnswers_AdvancedVersion.Top = showanswers_beginY;

buttonShowAnswers_SimpleVersion.Top = showanswers_beginY;

//------------------------------

//Задать набор вариантов ответов

//------------------------------

//Задать элемент управления, по которому будут выравниваться

//все остальные элементы управления

buttonAnswer0.Top = answerbuttons_beginY;

//Поместить PictureBox под элементами управления

pictureBoxGameBoard.Top = (answerButtons_dy + dy_betweenButtons) * 3 + answerbuttons beginY;

buttonAskQuestion.Top = 0;

buttonAskQuestion.Left = 174;

textBoxAskQuestion.Top = 0;

#else //ПОЛЕ ИГРЫ располагается над пользовательскими

//элементами управления

const int answerbuttons_beginY = 174;

//--------------------------------------------------------

//Задать кнопки выбора вариантов Easy или Hard режима игры

//--------------------------------------------------------

buttonShowAnswers_AdvancedVersion.Top = answerbuttons_beginY;

buttonShowAnswers_SimpleVersion.Top = answerbuttons_beginY;

//-----------------------------

//Задать набор вариантов ответа

//-----------------------------

//Задать элемент управления, по которому будут выравниваться

//все остальные элементы управления

buttonAnswer0.Top = answerbuttons_beginY;

pictureBoxGameBoard.Top = 0;

buttonAskQuestion.Top = answerbuttons_beginY;

buttonAskQuestion.Left = 174;

#endif

buttonShowAnswers_AdvancedVersion.Left = answerbuttons_beginX;

buttonShowAnswers_SimpleVersion.Left = buttonShowAnswers_AdvancedVersion.Left + answerButtons_dx + dx betweenButtons;

pictureBoxGameBoard.Left = 0;

pictureBoxGameBoard.Width = 240;

pictureBoxGameBoard.Height = 172;

buttonAnswer0.Left = answerbuttons_beginX;

buttonAnswer1.Left = buttonAnswer0.Left + answerButtons_dx + dx_betweenButtons;

buttonAnswer1.Top = buttonAnswer0.Top;

//следующий ряд

buttonAnswer2.Left = buttonAnswer0.Left;

buttonAnswer2.Top = buttonAnswer0.Top + answerButtons_dy + dy_betweenButtons;

buttonAnswer3.Left = buttonAnswer2.Left + answerButtons_dx + dx_betweenButtons;

buttonAnswer3.Top = buttonAnswer2.Top;

//следующий ряд

buttonAnswer4.Left = buttonAnswer2.Left;

buttonAnswer4.Top = buttonAnswer2.Top + answerButtons_dy + dy_betweenButtons;

buttonAnswer5.Left = buttonAnswer4.Left + answerButtons_dx + dx_betweenButtons;

buttonAnswer5.Top = buttonAnswer4.Top;

}

//-------------------------------------------------------------

//Вспомогательная функция, которая позволяет задавать состояние

//видимости кнопок, отображающих ответы из словаря

//-------------------------------------------------------------

private void SetAnswerButtonVisibility(bool visibleState) {

buttonAnswer0.Visible = visibleState;

buttonAnswer1.Visible = visibleState;

buttonAnswer2.Visible = visibleState;

buttonAnswer3.Visible = visibleState;

buttonAnswer4.Visible = visibleState;

buttonAnswer5.Visible = visibleState;

}

//-----------------------------------------------------------------

//Вспомогательная функция, вызываемая для задания свойств видимости

//некоторых элементов управления

//-----------------------------------------------------------------

private void SetDifficultyButtonVisibility(bool visibleState) {

buttonShowAnswers_AdvancedVersion.Visible = visibleState;

buttonShowAnswers_SimpleVersion.Visible = visibleState;

}

//-------------------------------------------------------------

//Вспомогательная функция, которая позволяет задавать состояние

//видимости кнопок, отображающих ответы из словаря

//-------------------------------------------------------------

private void SetAnswerButtonEnabled(bool enabledState) {

buttonAnswer0.Enabled = enabledState;

buttonAnswer1.Enabled = enabledState;

buttonAnswer2.Enabled = enabledState;

buttonAnswer3.Enabled = enabledState;

buttonAnswer4.Enabled = enabledState;

buttonAnswer5.Enabled = enabledState;

}

//-----------------------------------------------------------------

//Задает текст в текстовом окне и кнопках,

//необходимых для формулирования вопросов.

//

//B случае практической реализации эта функция должна просматривать

//вопросы динамически

//-----------------------------------------------------------------

private void SetTextForVocabularyQuestion() {

setQuestionText("What is the English word for 'der Mensch'?");

buttonAnswer0.Text = "Four";

buttonAnswer1.Text = "Person";

buttonAnswer2.Text = "Three";

buttonAnswer3.Text = "To Jump";

buttonAnswer4.Text = "Newspaper";

buttonAnswer5.Text = "Brother";

}

//Вызывается для оценки варианта ответа, выбранного пользователем

private void evaluateMultipleChoiceAnswer(Button buttonClicked, int selection) {

//Примечание: в практической реализации правильный номер ответа

//определяется динамически и не всегда соответствует "кнопке № 1"

//Если выбранный пользователем вариант ответа не является правильным,

//отменить доступ к нажатой кнопке

if  (selection ! = 1) {

//Выбранный вариант ответа является неправильным

buttonClicked.Enabled = false;

} else {

//Пользователь выбрал правильный ответ, продолжить игру

StateChangeForGameUI(GameUIState.waitForNextQuestion);

}

}

//Абстракция, задающая текст вопросов

void setQuestionText(string textIn) {

textBoxAskQuestion.Text = textIn;

}

//----------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Пользователь желает увидеть следующий вопрос

//----------------------------------------------------------------

private void buttonAskQuestion_Click(object sender, System.EventArgs e) {

SetTextForVocabularyQuestion();

StateChangeForGameUI(GameUIState.waitForUserToStateKnowledge);

}

//---------------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ:

//Пользователь желает ответить на отображенный вопрос и сообщить, какой

//наиболее сложный уровень является для него приемлемым

//---------------------------------------------------------------------

private void buttonShowAnswers_AdvancedVersion_Click(object sender, System.EventArgs e) {

//Установить состояние игры для отображения вариантов выбора

StateChangeForGameUI(GameUIState.waitForUserToAnswerMultipleChoice);

}

//---------------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ:

//Пользователь желает ответить на отображенный вопрос и сообщить, какой

//наиболее легкий уровень является для него приемлемым

//---------------------------------------------------------------------

private void buttonShowAnswers_SimpleVersion_Click(object sender, System.EventArgs e) {

//Установить состояние игры для отображения вариантов выбора

StateChangeForGameUI(GameUIState.waitForUserToAnswerMultipleChoice);

}

//ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

private void buttonAnswer0_Click(object sender, System.EventArgs e) {

evaluateMultipleChoiceAnswer(buttonAnswer0, 0);

}

//ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

private void buttonAnswer1_Click(object sender, System.EventArgs e) {

evaluateMultipleChoiceAnswer(buttonAnswer1, 1);

}

//ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

private void buttonAnswer2_Click(object sender, System.EventArgs e) {

evaluateMultipleChoiceAnswer(buttonAnswer2, 2);

}

//ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

private void buttonAnswer3_Click(object sender, System.EventArgs e) {

evaluateMultipleChoiceAnswer(buttonAnswer3, 3);

}

//ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

private void buttonAnswer4_Click(object sender, System.EventArgs e) {

evaluateMultipleChoiceAnswer(buttonAnswer4, 4);

}

//ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

private void buttonAnswer5_Click(object sender, System.EventArgs e) {

evaluateMultipleChoiceAnswer(buttonAnswer5, 5);

}

//-------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Вызывается при загрузке формы

//-------------------------------------------------

private void Form1_Load(object sender, System.EventArgs e) {

//Задать статические свойства нашего визуального интерфейса

SetStartControlPositionAndState();

//Задать динамические свойства, исходя из того, в какое состояние

//игры мы входим

StateChangeForGameUI(GameUIState.startScreen);

}

Размещение элементов управления

В случае мобильных приложений расположение элементов пользовательского интерфейса играет большую роль как в отношении удобства пользования ими, так и в отношении возможности представить полностью всю информацию, которая необходима. Лишь в редких случаях имеет смысл простой перенос пользовательского интерфейса с настольного компьютера на мобильное устройство; лично я не могу привести ни одного примера, когда бы это сработало на практике. Экранное разрешение и модели использования в этих двух случаях настолько радикально отличаются друг от друга, что попытки втиснуть пользовательский интерфейс и модель использования приложения, свойственные настольным компьютерам, в форм-фактор мобильного устройства — это рецепт неудачи. В лучшем случае вы получите неуклюжее посредственное приложение. Гораздо целесообразнее проанализировать, ранжировать по приоритетам и явно выписать перечень всех сценариев настольного компьютера, выполнение которых на мобильном устройстве является необходимым, а также сценариев, уникальных для мобильного устройства, которые вы хотели бы поддерживать, и лишь после этого создавать пользовательский интерфейс приложения, подчинив его вытекающим из всего вышесказанного требованиям.

To же самое можно сказать и о простом переносе приложения с одного устройства на другое, если их форм-факторы различны; такой "буквальный" перенос пользовательского интерфейса имеет смысл осуществлять лишь в редких случаях. Даже если большая часть логики приложения и может быть перенесена в неизменном виде, гораздо лучше составить явный перечень ключевых сценариев и специфических для устройства моделей использования и начать создавать пользовательский интерфейс, который удовлетворяет этим запросам, с нуля.

Экранное пространство — ценная вещь

Чем меньше экран устройства, тем больше внимания необходимо уделять его эффективному использованию. Рациональное управление экранным пространством не имеет ничего общего с попытками разместить как можно больше элементов управления в пределах экрана; на самом деле почти всегда следует стремиться к обратному.

Физические возможности мобильных устройств ограничены, и поэтому вы не сможете разместить большинство элементов управления приложений для настольных компьютеров на экране мобильного устройства даже в том случае, если уменьшите шрифты наполовину, сведете размеры элементов управления до тех минимальных пределов, при которых ими еще можно пользоваться, и расположите их как можно ближе друг к другу так, как если бы они являлись элементами игры "Tetris". Ясно, что требуется совершенно иной подход. Наилучшие интерфейсы для мобильных устройств не страдают загруженностью экрана деталями, они разрежены и элегантны; как это ни парадоксально, создается впечатление, что имеющимся свободным пространством они могли бы еще и с кем-то поделиться. Вместо того чтобы пытаться разместить на экране мобильного устройства все элементы управления сразу, целесообразнее подойти к проблеме с другой стороны и задаться вопросом: "Каков тот абсолютный минимум информации и элементов управления, которые должны присутствовать на экране, чтобы пользователь имел возможность сделать следующий шаг?" Приступая к проектированию компоновки пользовательского интерфейса мобильного приложения, попытайтесь найти ответы на следующие вопросы:

■ Каков тот минимальный набор информации, которая должна отображаться на экране, и тот минимальный набор элементов управления, которые требуются для навигации? Можно ли дополнительно уменьшить этот набор путем разделения доступного экрана между несколькими менее насыщенными состояниями пользовательского интерфейса, которые могут отображаться по отдельности?

■ Должны ли размеры элементов управления изменяться при переходе от одного состояния пользовательского интерфейса к другому? Часто оказывается желательным сократить или увеличить размеры элемента пользовательского интерфейса, чтобы скрыть или показать более подробную информацию, если это позволяют размеры экрана.

■ Не будет ли эффективнее привлечь пользовательский элемент управления для отображения той информации, которая в настоящее время представляется несколькими элементами управления?  Такое решение должно быть тщательно взвешено. Создание специализированного элемента управления может оказаться неплохим способом повышения эффективности использования пространства пользовательского интерфейса, но при этом следует проанализировать, насколько такое решение будет удовлетворительным с учетом следующих факторов: 1) разработка пользовательского элемента управления требует намного больших усилий, чем использование уже существующих и протестированных элементов управления, и 2) создание новой метафоры пользовательского интерфейса может затруднить его использование. Конечные пользователи уже знают, как использовать существующие элементы управления, тогда как к любым вновь введенным вами концепциям им придется привыкать. Тем не менее, в некоторых случаях такая работа является оправданной и может давать впечатляющие результаты.

Местоположение, местоположение и еще раз местоположение

Не все участки экрана равнозначны. Элемент управления, размещенный вверху, внизу, слева, справа или посередине экрана будет обладать различными свойствами применимости. Эти свойства часто меняются при переходе от одного класса устройств к другому. Так, элементы управления Pocket PC, принимающие текстовый ввод, следует размещать в верхней части экрана, поскольку в этих устройствах предусмотрена всплывающая программная клавиатура (SIP), которая, если вам необходимо ввести текст, отображается в нижней части экрана. Расположением элементов управления, которые вы размещаете на экране, должны управлять следующие два фактора:

1. Стиль и практика применения, существующие для вашего целевого мобильного устройства. Для большинства программируемых мобильных устройств существуют рекомендации, относящиеся к стилю компоновки пользовательского интерфейса. Эти рекомендации важно учитывать как для того, чтобы ваше приложение хорошо сочеталось с методами ввода, предусмотренными в устройстве (например, кнопки, сенсорный экран, всплывающая клавиатура), так и для того, чтобы все используемые на устройстве приложения имели унифицированный внешний вид и вели себя одинаковым образом с точки зрения пользователя. Если вы еще не успели прочитать эти рекомендации, обязательно сделайте это. Подобные рекомендации будут иметь для вас гораздо более высокую ценность, чем любой другой совет, касающийся общих вопросов компоновки интерфейсов.Примечание. Тот факт, что для каждого из различных классов устройств существуют свои рекомендации относительно стиля компоновки пользовательского интерфейса, является дополнительной причиной того, что модели, основанные на принципе "пишется однажды — выполняется везде", обычно не срабатывают. Все дело в том, что очень трудно создать единую унифицированную среду пользовательского интерфейса, которая бы автоматически и одинаково хорошо соответствовала стилевым рекомендациям для различных устройств.

2. Тестирование применимости модели на реальных устройствах. Окончательным арбитром применимости вашего пользовательского интерфейса является реальный пользователь, который использует его на реальном устройстве (не на эмуляторе). Поскольку мобильными устройствами пользуются, удерживая их в руках, например, на улице, в поезде, самолете или в битком набитом людьми лифте, ничто не способно заменить тестирование приложения на том реальном оборудовании, для которого оно предназначено, и в реальных условиях его использования.

Выбирайте соответствующие элементы управления для соответствующих устройств

Наряду с необходимостью следовать соответствующему стилю и рекомендациям относительно компоновки интерфейса для данного мобильного устройства очень важно правильно выбрать набор элементов управления, который хорошо подходит для вашего целевого устройства. Мобильная среда выполнения может поддерживать самые разнообразные элементы управления пользовательского интерфейса, однако лишь некоторые из них будут пригодны для использования на интересующем вас устройстве. Например, поскольку в смартфонах отсутствуют сенсорные экраны или указатели мыши, которыми вы могли бы воспользоваться для произвольного доступа к таким навигационным элементам управления, как вкладки, обычные кнопки и переключатели, то перечисленные элементы не могут служить полезной метафорой пользовательского интерфейса для этих устройств. Вместо этого для смартфонов хорошо подойдут списки и меню. Вообще говоря, чем меньше размеры устройства, тем специфичнее требования к элементам управления, которые могут применяться на этом устройстве.

Когда целесообразнее использовать различные формы, а когда — осуществлять смену элементов управления

Для облегчения навигации в пределах пользовательского интерфейса можно использовать два способа: 1) вызывать новые формы в ответ на действия пользователя, и 2) показывать или скрывать элементы управления на единственной форме. Оба эти способа могут служить механизмами показа пользователю нового экрана, заполненного информацией.

Вы не сделаете ничего плохого, если для манипулирования информацией, требующей нескольких экранов, используете одну-единственную форму, и будете показывать на ней и скрывать элементы управления в соответствии с необходимостью. Вы должны хранить такие многоэкранные элементы пользовательского интерфейса в одной форме в том случае, если они представляют родственные понятия и вам может потребоваться настройка связей между ними. Переместить информацию с одного "экрана" на другой легче, если управление ими реализовано в пределах одного и того же класса.

Разделять же функциональность между различными формами следует тогда, когда она действительно состоит из различных частей, а вероятность того, что в процессе настройки пользовательского интерфейса вы захотите переносить его элементы из одной формы в другую, мала. Эта мера позволяет уменьшить скученность элементов управления на экране.

Если экран вашего целевого мобильного устройства достаточно большой, то в качестве промежуточного решения, позволяющего добиться определенного компромисса, могут использоваться вкладки. Обычно каждую отдельную вкладку следует концептуально рассматривать как отдельную форму. Использование вкладок обладает тем замечательным преимуществом, что при этом вы не должны отображать или скрывать каждый экран вручную; это автоматически делает за вас среда выполнения. Рассмотрите возможность помещения кода обработчиков событий для содержимого каждой из вкладок в отдельные классы. Тем самым будет обеспечена надежная инкапсуляция кода, делающая его менее запутанным.

Разработка улучшенных пользовательских интерфейсов средствами .NET Compact Framework

.NET Compact Framework предлагает некоторые усовершенствованные средства, представляющие интерес для разработчиков. Поскольку эти понятия специфичны для .NET Compact Framework, они сознательно вынесены в отдельный раздел. Аналогичные возможности могут предлагать и другие среды выполнения для мобильных устройств, поэтому данный материал стоит прочитать, даже в тех случаях, когда вы работаете в одной из них.

Динамическое создание элементов управления

Возможность динамического создания элементов управления может оказаться полезной. Как показывают рис. 13.8 и листинг 13.2, в .NET Compact Framework сделать это не сложно. Динамические элементы управления удобно использовать в нескольких ситуациях:

■ Когда форма загружается очень медленно.  Если форма содержит множество элементов управления или она достаточно тяжеловесна, то для ее инициализации требуется проделать большой объем работы. При создании и загрузке формы инициализируются все элементы управления, размещенные на ней во время проектирования. Все, что для этого необходимо, выполняется в функции InitializeComponent(); содержимым этой функции управляет конструктор форм, и при желании вы можете исследовать упомянутую функцию. Если вы хотите ускорить загрузку формы, то можете отложить создание элемента управления до тех пор, пока в нем не возникнет необходимости. Примечание. Вы также можете воспользоваться кодом, автоматически сгенерированным для вас в функции InitializeComponent(), и попытаться вручную оптимизировать его. Поступая таким образом, вы должны поместить собственный код в функцию с отдельным именем, которое исключит вероятность того, что по случайности она будет перекрыта функцией среды разработки. Вы также должны понимать, что теперь при проектировании своей формы вы можете лишиться помощи конструктора форм. Как и в случае любой оптимизации, вы обязательно должны получать количественную оценку ее эффективности, чтобы быть уверенным в том, что добились с ее помощью те результаты, на которые рассчитывали.

■ Когда на стадии проектирования точное количество необходимых элементов управления не известно.  Например, если вашему приложению требуется массив переключателей, количество которых зависит от количества элементов, возвращаемых в результате запроса к базе данных, то вам приходится создавать этот массив во время выполнения, когда количество переключателей становится известным.

■ Когда для элемента управления, который вы хотите использовать, не существует реализации на стадии проектирования.  При работе с .NET Compact Framework создание экземпляров пользовательских элементов управления на стадии проектирования может представлять значительные трудности; на разработку этого часто может уходить больше времени, чем если воспользоваться для элементов управления их версиями времени выполнения. Если вы создаете пользовательский элемент управления для собственных нужд разработки, то может оказаться нецелесообразным затрачивать усилия на создание его версии, используемой только на этапе разработки, только ради того, чтобы она появилась в окне конструктора форм. Создавая данный элемент управления во время выполнения, вы избавляете себя от затраты этих усилий.

Чтобы обеспечить работоспособность динамического элемента управления после его создания, вы должны выполнить три дополнительных типа операций:

1. Инициализация элемента управления. Вы должны установить размер и местоположение элемента управления, а также другие свойства, значения которых должны быть заданы до его отображения.

2. Подключение всех событий, которые вы хотите обрабатывать. Большинство элементов управления могут приносить пользу лишь тогда, когда к ним присоединяется код, обрабатывающий события, которые они могут генерировать. По отношению к каждому из подключаемых событий вы должны предпринять ряд действий:

а. Вам нужна функция, которая является приемником события (то есть вызывается при его запуске).

б. Вы должны создать обработчик события (иначе называемый делегатом) с подходящей сигнатурой функции, который указывает на вашу функцию приемника события.

в. Вы должны зарегистрировать этот обработчик событий в элементе управления.

Сказанное может показаться вам слишком сложным, но на практике все оказывается проще и осуществляется с помощью всего лишь одной строки кода. Например, в приведенном ниже коде выполняются все три действия, описываемые пунктами а, б и в.

newButton.Click += new System.EventHandler(this.ClickHandlerForButtons);

Более подробно, по составляющим:

а. this.ClickHandlerForButtons — это функция приемника событий.

б. new System.EventHandler() — это делегат, указывающий на приемник событий.

в. newButton.Click +=… — добавляет обработчик событий в список обработчиков событий, которые вызываются при запуске события.

Полезно заглянуть в код функции InitializeComponent() формы, откуда можно скопировать код регистрации обработчика события. Важно подчеркнуть, что одна функция может служить приемником произвольного числа самых различных событий. Данная возможность оказывается удобной при работе с массивами элементов управления, поскольку события нескольких элементов управления могут отображаться в единственную функцию.

3. Задание, путем использования свойства Parent нового элемента управления, в качестве родительской той формы, на которой этот элемент должен отображаться. Фактически, в результате выполнения именно этого последнего шага элемент управления создается и размещается на форме. Если значением свойства Parent элемента управления является null, то элемент управления не принадлежит форме.

Пример создания динамического элемента управления

На рис. 13.8 и в листинге 13.2 представлен пример приложения, иллюстрирующего создание кнопок Button и подключение к ним обработчиков событий Click. Вы можете легко адаптировать пример для создания любых желаемых элементов управления.

Рис. 13.8. Динамическое создание элементов управления во время выполнения

Представленный в листинге 13.2 код принадлежит форме в проекте Pocket PC. Для создания и запуска приложения потребуется выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и создайте приложение C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму кнопку Button и переименуйте ее в buttonCreateNewButtons.

4. Дважды щелкните на кнопке, которую вы только что добавили в окне конструктора форм. На экране отобразится окно редактора кода вместе со скелетом функции privatevoidbuttonCreateNewButtons_Click(object sender, System.EventArgs e). Введите в эту функцию приведенный ниже код.

5. Перейдя в окно редактора кода, введите оставшуюся часть приведенного ниже кода, включая те его части, которые расположены выше и ниже кода функции, который вы только что ввели.

6. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

7. Запустите приложение. Вы должны заметить, что каждый раз, когда вы щелкаете на кнопке buttonCreateNewButtons, на форме появляется новая кнопка (как показано на рис. 13.8). Щелчки на любой из вновь созданных кнопок должны приводить к запуску приведенного ниже кода обработчика событий и отображению окна сообщений с текстом, соответствующим той кнопке, на которой был выполнен щелчок

Листинг 13.2. Динамическое создание элементов управления на форме во время выполнения

//-------------------------------------

//Счетчик количества создаваемых кнопок

//-------------------------------------

private int m_nextNewButtonIndex;

//---------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Обработчик щелчка на кнопке, которая

// имеется на нашей форме.

//

//Эта функция создает новую кнопку, присоединяет ее к нашей форме

//и подключает обработчик события щелчка для нее

//---------------------------------------------------------------

private void buttonCreateNewButtons_Click(object sender, System.EventArgs e) {

//Впоследствии мы начнем создавать новые кнопки, начиная

//снизу экрана, поэтому ограничиваем их количество восемью

if (m_nextNewButtonIndex > 8) {

return;

}

//----------------------------------------------------

//Создать кнопку (еще не присоединенную к нашей форме)

//установить ее местоположение, размеры и текст

//----------------------------------------------------

const int newButtonHeight = 15;

System.Windows.Forms.Button newButton;

newButton = new System.Windows.Forms.Button();

newButton.Width = 100;

newButton.Height = newButtonHeight;

newButton.Left = 2;

newButton.Top = (newButtonHeight + 2) * m_nextNewButtonIndex;

newButton.Text = "New Button " + m_nextNewButtonIndex.ToString();

//--------------------------------------------------

//Присоединить обработчик к событию щелчка на данном

//элементе управления.

//--------------------------------------------------

newButton.Click += new System.EventHandler(this.ClickHandlerForButtons);

//-----------------------------------------

//Присоединить эту кнопку к форме. По сути,

//это создаст кнопку на форме!

//-----------------------------------------

newButton.Parent = this;

//Увеличить счетчик в соответствии с созданием очередной кнопки

m_nextNewButtonIndex++;

}

//-----------------------------------------------------

//Обработчик событий, который мы динамически подключаем

//к нашим новым кнопкам

//-----------------------------------------------------

private void ClickHandlerForButtons(object sender, System.EventArgs e) {

Button buttonCausingEvent;

buttonCausingEvent = (System.Windows.Forms.Button)sender;

//Вызвать окно сообщений, извещающее о том,

//что мы получили событие

System.Windows.Forms.MessageBox.Show("Click event from: \n\r'" + buttonCausingEvent.Text + "'");

}

Создание пользовательских элементов управления и перекрытие поведения существующих элементов управления

В .NET Compact Framework допускается два вида наследования элементов управления: 1) создание пользовательского элемента управления с нуля, и 2) перекрытие поведения существующих элементов управления System.Windows.Forms.*, не связанного с их перерисовкой/визуализацией.

Прежде всего, следует сказать несколько слов о том, чего .NET Compact Framework (версия 1.1) не поддерживает: она, в отличие от .NET Framework, не позволяет разработчикам перекрывать визуальные характеристики перерисовки стандартных элементов управления. (Например, вы не можете использовать для наследования элементы управления Button, TreeView, TextBox или другие стандартные элементы управления, перекрывая при этом способ их перерисовки.) Это сделано в интересах функционирования внутренних механизмов.

Разработчик, желающий придать нестандартный внешний вид элементу управления в .NET Compact Framework, должен породить его от базового класса Control (System.Windows.Forms.Control), который допускает пользовательскую визуализацию элементов управления. В наибольшей степени такая возможность полезна в случае тех элементов управления, которые предлагают совершенно новые возможности взаимодействия с пользователем, а не тех, которые обеспечивают видоизмененное поведение существующих элементов управления. Элементарный пример того, как создать с нуля элемент управления с нестандартной визуализацией, приводится в главе 11; этот пример послужит вам отличной отправной точкой для создания аналогичного собственного элемента управления, если в этом возникнет необходимость.

Несмотря на то что .NET Compact Framework не поддерживает перекрытие поведения внутренних элементов управления, связанного с их визуализацией, она поддерживает перекрытие их функционального поведения. Существует два способа расширения возможностей внутренних элементов управления: 1) добавление дополнительных методов, свойств и событий, которые обеспечивают предоставление добавочной высокоуровневой функциональности, и 2) перекрытие существующих свойств и методов, для создания специфических возможностей. Хорошим примером, иллюстрирующим использованием обоих способов, является создание элемента TextBox, который осуществляет фильтрацию, принимая лишь входные данные определенного формата. Пример решения такой задачи представлен в листингах 13.3 и 13.4.

Пример элемента управления TextBox с фильтром

Если при вводе данных должны быть выдержаны определенные требования форматирования, то часто оказывается полезным создать пользовательский элемент управления, который вынуждает соблюдать необходимые критерии. В качестве типичного для США примера можно привести ввод номера карточки социального страхования. Эти номера имеют формат ###-##-####, представляющий три цифры, разделитель в виде дефиса, за которым следуют еще две цифры, дефис и последние четыре цифры. Существует много других случаев, когда навязывание формата ввода данных оказывается полезным, например, почтовые коды (ZIP-коды). В разных странах предусмотрены свои форматы кодов, одни из которых — цифровые, а другие — буквенно-цифровые. Так, в почтовые коды Канады и Великобритании входят как цифры, так и буквы. Во всех подобных случаях, когда требуется строго определенный ввод, возможность включения фильтра в элемент управления TextBox представляет большую ценность. Было бы очень кстати, если бы у этого элемента управления было свойство, позволяющее информировать пользователя о том, соответствует ли введенный в настоящее время текст требованиям определения достоверного и завершенного ввода. В нашем примере кода будет реализована как фильтрация входных данных, так и проверка их достоверности.

На рис. 13.9 показано, как выглядит приложение во время выполнения. Имеющаяся на форме кнопка предназначена для создания экземпляра элемента управления TextBox с фильтром.

Рис. 13.9. Текстовое окно с фильтрацией во время выполнения

Ввод текста в текстовом окне приводит к запуску кода фильтрации и форматирования, предусмотренного для этих целей в классе SocialSecurityTextBox. В этом классе вызываются две функции:

1. Первой из вызываемых функций является перекрытый метод SocialSecurityTextBox.OnKeyPress(). Это дает нам возможность перехватывать и осуществлять предварительную фильтрацию поступающих событий нажатий клавиш. В нашем случае, поскольку мы не хотим, чтобы среди входных данных присутствовали буквы, мы должны отфильтровывать соответствующие символы при их вводе пользователем. Благодаря тому, что мы не передаем их методу OnKeyPress() базового класса, текстовое окно вообще "не видит" нажатий этих клавиш. Мы могли бы использовать более строгие критерии фильтрации, исключив, например, любой возможный дополнительный цифровой ввод, который пользователь пытался бы выполнить после ввода обязательных цифр, однако не будем усложнять этим пример. Стоит подчеркнуть, что при фильтрации событий нажатий клавиш необходимо следить за тем, чтобы не переусердствовать и не потерять при этом нажатия таких клавиш, как символ забоя, который используется для удаления предыдущего символа.

2. Второй из вызываемых функций является перекрытый метод SocialSecurity — TextBox.OnTextChanged(). Этот метод вызывается тогда, когда содержимое свойства Text претерпевает изменения, например, когда было зарегистрировано нажатие клавиши. При этом у нас появляется возможность применить наш форматирующий код и принудительно согласовать любой введенный текст с определенным нами форматом. Из введенных символов мы оставляем лишь цифры, одновременно гарантируя наличие символов дефиса (-) между третьей и четвертой, а также пятой и седьмой по счету цифрами. При этом следует предпринять некоторые меры предосторожности, ибо если будет происходить обновление свойства Text текстового окна внутри метода OnTextChanged, то это приведет к тому, что наш метод OnTextChanged будет вызываться рекурсивно. В данном случае нам не нужны осложнения, поэтому в самом начале функцию мы проверяем, не является ли данный вызов рекурсивным, и если это так, то осуществляется выход из функции без выполнения каких-либо действий. Далее мы проверяем длину обрабатываемого текста; если она составляет 11 символов, то номер карточки социального страхования получен полностью, иначе — нет. Для указания этого факта используется обновление внутреннего состояния. Наконец, мы вызываем метод OnTextChanged нашего базового класса текстового окна; в результате этого будут вызываться все обработчики событий, прослушивающие события TextChanged.

Приведенный в листинге 13.3 код представляет собой независимый класс, и его можно ввести в том виде, как он есть. Код, приведенный в листинге 13.4, принадлежит форме проекта Pocket PC. Для создания и запуска приложения необходимо выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму элемент управления Button. (Ему будет присвоено имя button1.)

4. Добавьте в форму элемент управления Label. (Ему будет присвоено имя label1.)

5. Добавьте в проект новый класс. Присвойте ему имя SocialSecurityTextBox, удалите весь предшествующий код, который отображается в окне текстового редактора для этого класса, и введите код, представленный в листинге 13.3.

6. Вернитесь к форме Form1 в окне конструктора форм.

7. Дважды щелкните на кнопке, которую вы добавили в окне конструктора форм. На экране отобразится окно редактора кода вместе со скелетом функции private void button1_Click(object sender, System.EventArgs е).Введите в эту функцию ее код, представленный в листинге 13.4.

8. Перейдя в окно редактора кода, введите оставшуюся часть приведенного ниже кода, включая те его части, которые расположены выше и ниже кода функции, который вы только что ввели.

9. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

10. Запустите приложение. Вы должны заметить, что после щелчка на кнопке button1 в верхней части формы появляется новое текстовое окно. Это текстовое окно разрешает вводить лишь цифры, форматируя их по шаблону ###-##-####. По мере ввода надпись на экране обновляется, сообщая о том, ввели ли вы требуемое количество цифр.

Данный пример легко видоизменить для поддержки других форматов ввода. Кроме того, в него может быть добавлен код, поддерживающий пользовательские события; например, наш унаследованный элемент управления TextBox может возбуждать событие после ввода всех необходимых данных, согласующихся с шаблоном ввода.

Листинг 13.3. Фильтрующее текстовое окно, принимающее текст в формате ###-##-####

using System;

//----------------------------------------------------------------------

//Этот класс является элементом управления, производным от TextBox.

//Он наследует все графические свойства TextBox, но добавляет фильтрацию

//содержимого текстового окна, тем самым гарантируя,

//что вводимый текст будет соответствовать следующему формату:

//###-##-####.

//Этот формат соответствует формату номеров карточек социального

//страхования, которые используются в США.

//----------------------------------------------------------------------

public class  SocialSecurityTextBox: System.Windows.Forms.TextBox {

private bool  m_inputIsFullValidEntry;

//------------------------------------

//Указывает, получен ли номер карточки

//социального страхования полностью

//------------------------------------

public bool  IsFullValidInput {

get {return m_inputIsFullValidEntry;}

}

//Объект StringBuilder, который мы будем часто использовать

System.Text.StringBuilder m_sb;

//Максимальная длина обрабатываемых строк

const int  SSNumberLength = 11;

//-----------

//Конструктор

//-----------

public  SocialSecurityTextBox() {

//Распределить память для нашего объекта StringBuilder и предоставить

//место для нескольких дополнительных рабочих символов по умолчанию

m_sb = new System.Text.StringBuilder(SSNumberLength + 5);

m_inputIsFullValidEntry = false;

}

//---------------------------------------------------------------------

//Форматировать поступающий текст с целью установления его соответствия

//нужному формату:

//

// Формат номера карточки социального страхования : ###-##-####

// символы: 01234567890

//

// [in] inString : Текст, который мы хотим форматировать

// [in/out] selectionStart: Текущая точка вставки в тексте;

// она будет смещаться в связи с удалением

// и добавлением нами символов

//----------------------------------------------------------------------

private string formatText_NNN_NN_NNNN(string inString, ref int selectionStart) {

const int  firstDashIndex = 3;

const int secondDashIndex = 6;

//Удалить старые данные и поместить входную строку

//в объект StringBuilder, чтобы мы могли с ней работать.

m_sb.Length = 0;

m_sb.Append(inString);

//------------------------------------------------------------

//Просмотреть каждыйсимвол в строке, пока не будет

//достигнута максимальная длина нашего форматированного текста

//------------------------------------------------------------

int  currentCharIndex;

currentCharIndex = 0;

while ((currentCharIndex < m_sb.Length) && (currentCharIndex < SSNumberLength)) {

char  currentChar;

currentChar = m_sb[currentCharIndex];

if ((currentCharIndex == firstDashIndex) || (currentCharIndex == secondDashIndex))

//-------------------------------

//Данным символом должен быть "-"

//-------------------------------

{

if (currentChar != '-') {

//Вставить дефис

m_sb.Insert(currentCharIndex, "-");

//Если мы добавили символ перед точкой вставки,

//она должна быть смещена вперед

if (currentCharIndex <= selectionStart) {

selectionStart++;

}

}

//Этот символ годится, перейти к следующему символу

currentCharIndex++;

} else

//-------------------------

//Символ должен быть цифрой

//-------------------------

{

if (System.Char.IsDigit(currentChar) == false) {

//Удалить символ

m_sb.Remove(currentCharIndex, 1);

//Если мы добавили символ перед точкой вставки,

//она должна быть смещена назад

if (currentCharIndex < selectionStart) {

selectionStart--;

}

//He увеличивать значение счетчика символов, ибо мы должны

//просмотреть символ, занявший место того символа,

//который мы удалили

} else {

//Символ является цифрой, все нормально.

currentCharIndex++;

}

}

}

//Если превышена длина строки, усечь ее

if (m_sb.Length > SSNumberLength) {

m_sb.Length = SSNumberLength;

}

//Возвратить новую строку

return m_sb.ToString();

}

bool m_in_OnChangeFunction;

protected override void OnTextChanged(EventArgs e) {

//------------------------------------------------------------------

//Если мы изменим свойство .Text, то будет осуществлен повторный

//вход в обработчик. В этом случае мы не хотим предпринимать никаких

//действий и должны просто выйти из функции без передачи события

//куда-то еще.

//------------------------------------------------------------------

if (m_in_OnChangeFunction == true) {

return;

}

//Заметьте, что сейчас мы находимся в функции OnChanged,

//поэтому мы можем обнаружить повторное вхождение (см. код выше)

m_in_OnChangeFunction = true;

//Получить текущее свойство .Text

string oldText = this.Text;

//Получить текущий индекс

SelectionStart int selectionStart = this.SelectionStart;

//Форматировать строку, чтобы она удовлетворяла нашим потребностям

string newText = formatText_NNN_NN_NNNN(oldText, ref selectionStart);

//Если текст отличается от исходного, обновить

//свойство .Text

if (System.String.Compare(oldText, newText) != 0) {

//Это приведет к повторному вхождению

this.Text = newText;

//Обновить местоположение точки вставки

this.SelectionStart = selectionStart;

}

//Мы принудительно обеспечили соответствие введенного текста

//правильному формату, поэтому, если длина строки согласуется с длиной

//номера карточки социального страхования, то мы знаем что она имеет

//формат ###-##-####.

if (this.Text.Length == SSNumberLength) {

//Да, мы имеем полный номер карточки социального страхования

m_inputIsFullValidEntry = true;

} else {

//Нет, мы пока не получили полный номер карточки социального страхования

m_inputIsFullValidEntry = false;

}

//Вызвать наш базовый класс и сообщить всем объектам, которых это

//может интересовать, что текст изменился

base.OnTextChanged(e);

//Заметьте, что сейчас мы покидаем наш код и хотим отключить

//проверку повторных вхождений в него.

m_in_OnChangeFunction = false;

}

protected override void OnKeyPress(System.Windows.Forms.KeyPressEventArgs e) {

//Поскольку нам известно, что никакие буквы при вводе нам не нужны,

//то просто игнорировать их, если они встречаются.

char keyPressed = e.KeyChar;

if (System.Char.IsLetter(keyPressed)) {

//Сообщить системе о том, что событие обработано

e.Handled =true;

return;

}

//Обработать нажатие клавиши обычным способом

base.OnKeyPress(e);

} //Конец функции

} //Конец класса

Листинг 13.4 Код формы для создания пользовательского элемента управления TextBox

//-----------------------------------------------------------------

//Переменная для хранения нашего нового элемента управления TextBox

//-----------------------------------------------------------------

SocialSecurityTextBox m_filteredTextBox;

//--------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Создать экземпляр нашего пользовательского

// элемента управления и поместить его в форму

//--------------------------------------------------------------

private void  button1_Click(object sender, System.EventArgs e) {

//Создать, позиционировать и разместить элемент управления

m_filteredTextBox = new SocialSecurityTextBox();

m_filteredTextBox.Bounds = new  System.Drawing.Rectangle(2, 2, 160, 20);

//Подключить обработчик событий

m_filteredTextBox.TextChanged += new  EventHandler(this.textBox_TextChanged);

//Задать родительский объект

m_filteredTextBox.Parent =this;

//Выделить элемент управления

m_filteredTextBox.Focus();

//Сделать данную кнопку недоступной, чтобы поверх данного объекта

//не был создан второй объект

SocialSecurityTextBox button1.Enabled = false;

}

//----------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Этот обработчик подключается динамически при

// создании элемента управления

//----------------------------------------------------------------

private void textBox_TextChanged(object sender, System.EventArgs e) {

if  (m_filteredTextBox.IsFullValidInput == true) {

label1.Text = "FULL SOCIAL SECURITY NUMBER!!!";

} else {

label1.Text = "Not full input yet...";

}

}

Использование прозрачных областей растровых изображений

Растровые изображения с масками прозрачности полезны по многим причинам. При написании игр растровые изображения с областями прозрачности могут использоваться разработчиками для вывода на экран игрового поля и перемещения по нему изображений, форма которых не является прямоугольной. В картографических приложениях растровые изображения с масками прозрачности могут использоваться для вывода изображений поверх карт, генерируемых другими источниками; в качестве хорошего примера можно привести отображения на карте маркера, отмечающего текущее местоположение объекта. Наконец, встраивание изображений непрямоугольной формы в другую графику может с успехом использоваться для создания привлекательных пользовательских интерфейсов и бизнес-графики.

Растровые изображения, или битовые образы, являются, по сути, двумерными массивами целых чисел, где каждое число представляет цвет пикселя в определенной точке. В силу этого растровые изображения по самой своей природе имеют прямоугольную форму. Представление не являющегося прямоугольным изображения на прямоугольной битовой карте можно обеспечить, объявляя один цвет фоновым и заполняя пиксели, лежащие за пределами интересующего нас непрямоугольного изображения, этим цветом. Работа с правильными прямоугольными массивами обладает целым рядом преимуществ, не самым последним из которых является легкость копирования части одного изображения на часть другого; в случае прямоугольных областей для этого требуются самые простые алгоритмы. В результате копирования прямоугольной части одного растрового изображения на другое происходит простая замена информации об изображении, относящейся к соответствующей прямоугольной области. Это означает, что прямоугольные битовые карты, содержащие непрямоугольные изображения с единственным цветом фона, копируются в место назначения в виде непрозрачных прямоугольников изображений переднего и заднего планов. Результат выглядит совсем не привлекательно. В качестве альтернативного решения можно исходить из фонового изображения и создать на нем рисунок всех непрямоугольных изображений, используя функции рисования (например, DrawLine(), FillCircle()) или устанавливая пиксельные данные по одному пикселю за один раз. Оба эти способа приводят к хорошим визуальным результатам, но работают медленно и требуют написания сложных функций. Что нам необходимо сделать — так это скопировать одно растровое изображения на другое, не копируя фоновый цвет.

На рис. 13.10 представлено простое растровое изображение для игры; битовая карта является прямоугольной, но само изображение, которое мы хотим нарисовать — нет. Чтобы нарисовать это изображение без его прямоугольного фона, мы должны сообщить функции, осуществляющей копирование, о том, что копировать пиксели, цвет которых совпадает с установленным нами фоновым цветом, не следует. В .NET Compact Framework это достигается за счет использования класса ImageAttributes.

Класс ImageAttributes имеет метод SetColorKey(), используя который ваш код может устанавливать цвет маскирования. Указанный класс может передаваться в качестве параметра в одну из перегруженных версий функции Graphics.DrawImage(); получение этого параметра поддерживается только одной из перегруженных версий этой функции.

Функция DrawImage() получает в качестве параметров исходную битовую карту изображения, которое мы хотим копировать, размеры и местоположения областей, из которых и в которые должно осуществляться копирование, и объект ImageAttributes, указывающий, какая цветовая маска будет определять прозрачность в исходном изображении. Далее, на битовую карту назначения копируется информация обо всех пикселях исходного растрового изображения за исключением тех, цвет которых согласуется с цветом маски, определенным в объекте ImageAttributes.

Пиксели исходного растрового изображения, которые имеют тот же цвет, что и маска, не копируются. Благодаря этому существовавшие до этого пиксели изображения назначения "проступают" сквозь прозрачные области той битовой карты, которую мы копируем. Такая операция копирования выполняется медленнее, чем простое копирование прямоугольного изображения, но все же достаточно быстро, что делает этот вариант привлекательным при работе с непрямоугольными изображениями.

Рис. 13.10. Простое растровое изображение с передним планом непрямоугольной формы и одноцветным фоном

Если известно, что необходимость в рисунках возникнет вновь или будет возникать регулярно, то имеет смысл глобально кэшировать объект ImageAttributes, который может использоваться по всему приложению в вашем коде рисования изображений неправильной формы с прозрачным фоном; это избавит вас от необходимости многократно распределять память для объектов ImageAttributes, а затем освобождать ее, и избавит от накопления "мусора" в памяти вашего приложения.

Пример использования растровых изображений с областями прозрачности

На рис. 13.11 показан пример того, как использование прозрачных областей дает возможность получать изображения, отвечающие повышенным запросам. На первом из снимков представлено изображение заднего плана. В данном случае оно состоит из черного текста на белом фоне. На втором снимке представлено другое изображение, в качестве которого используются графические объекты в виде синего фона с нарисованными поверх него прямоугольником и двумя эллипсами желтого цвета. На третьем снимке показано второе изображение, нарисованное поверх первого, но с использованием желтого цвета в качестве прозрачного. Результат таков, что когда второе изображение копируется на первое, то все пиксели желтого цвета не копируются, в результате чего исходные пиксели первого изображения, находящиеся в соответствующих позициях, видны в конечном изображении.

Рис. 13.11. Приложение, иллюстрирующее процесс рисования с использованием прозрачного фона

Приложение, представленное на рис. 13.11, можно создать с помощью кода, приведенного в листинге 13.5. Для создания и запуска приложения потребуется выполнить перечисленные ниже действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму элемент управления Button (ему будет присвоено имя button1) и переименуйте его в buttonDrawBackground.

4. Дважды щелкните на кнопке в окне конструктора форм и введите для нее код функции buttonDrawBackground_Click(), листинг которой приводится ниже.

5. Добавьте в форму элемент управления Button и переименуйте его в buttonDrawForeground.

6. Дважды щелкните на кнопке в окне конструктора форм и введите для нее код функции buttonDrawForeground_Click(), листинг которой приводится ниже.

7. Вернитесь к форме Form1 в окне конструктора форм.

8. Добавьте в форму элемент управления Button и переименуйте его в buttonDrawBackgroundPlusForeground.

9. Дважды щелкните на кнопке в окне конструктора форм и введите для нее код функции buttonDrawBackgroundPlusForeground_Click(), листинг которой приводится ниже.

10. Введите оставшуюся часть кода, приведенного в листинге ниже.

11. Вернитесь в окно конструктора форм.

12. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения

13. Полученные вами результаты должны воспроизводить те, которые показаны на рис. 13.11.

Дополнительные эффекты с использованием прозрачных изображений

Выбор желтого цвета в качестве прозрачного был сделан совершенно произвольно. Точно так же в качестве прозрачного цвета можно было выбрать синий цвет и позволить скопироваться в изображении переднего плана всему, что имеет желтый цвет, а синий цвет трактовать как прозрачный. Кроме того, не сложно поменять местами битовые карты переднего и заднего планов, сделав желтые и синие прямоугольники и эллипсы задним планом, а черный и белый текст — передним; в этом случае нам потребовалось бы выбрать в качестве прозрачного черный или белый цвет, и, в зависимости от нашего решения, прозрачными были бы либо текст, либо его фон. Прозрачность — мощная штука, и ее можно с большим успехом применять в растровых изображениях самых различных видов.

Листинг 13.5. Код формы, демонстрирующий использование прозрачности

//----------------------------------------------------------------

//Размеры наших битовых образов и экранного изображения PictureBox

//----------------------------------------------------------------

const int bitmap_dx = 200;

const int bitmap_dy = 100;

//-------------------------------------------------

//Создает и прорисовывает изображение заднего плана

//-------------------------------------------------

System.Drawing.Bitmap m_backgroundBitmap;

void CreateBackground() {

if  (m_backgroundBitmap == null) {

m_backgroundBitmap =new Bitmap(bitmap_dx, bitmap_dy);

}

//Делаем битовую карту белой

System.Drawing.Graphics gfx;

gfx = System.Drawing.Graphics.FromImage(m_backgroundBitmap);

gfx.Clear(System.Drawing.Color.White);

//Рисуем текст черным

System.Drawing.Brush myBrush;

myBrush = new System.Drawing.SolidBrush(System.Drawing.Color.Black);

for (int у = 0; у < bitmap_dy; у = у + 15) {

gfx.DrawString("I am the BACKGROUND IMAGE...hello", this.Font, myBrush, 0, у);

}

//Очистить

myBrush.Dispose();

gfx.Dispose();

}

//-------------------------------------------------

//Создает и прорисовывает изображение заднего плана

//-------------------------------------------------

System.Drawing.Bitmap m_foregroundBitmap;

void CreateForeground() {

if (m_foregroundBitmap == null) {

m_foregroundBitmap = new Bitmap(bitmap_dx, bitmap_dy);

}

//Делаем всю битовую карту синей

System.Drawing.Graphics gfx;

gfx = System.Drawing.Graphics.FromImage(m_foregroundBitmap);

gfx.Clear(System.Drawing.Color.Blue);

//Рисуем несколько фигур желтым

System.Drawing.Brush yellowBrush;

yellowBrush = new System.Drawing.SolidBrush(System.Drawing.Color.Yellow);

gfx.FillEllipse(yellowBrush, 130, 4, 40, 70);

gfx.FillRectangle(yellowBrush, 5, 20, 110, 30);

gfx.FillEllipse(yellowBrush, 60, 75, 130, 20);

//Очистить

yellowBrush.Dispose();

gfx.Dispose();

}

//-----------------------------------------------------------------

//Устанавливает размеры и местоположение PictureBox с левой стороны

//-----------------------------------------------------------------

private void SetPictureBoxDimensions() {

pictureBox1.Width = bitmap_dx;

pictureBox1.Height = bitmap_dy;

pictureBox1.Left = 20;

}

//---------------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Отобразить изображение ЗАДНЕГО ПЛАНА в PictureBox

//---------------------------------------------------------------------

private void buttonDrawBackground_Click(object sender, System.EventArgs e) {

SetPictureBoxDimensions();

CreateBackground();

pictureBox1.Image = m_backgroundBitmap;

}

//-----------------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Отобразить изображение ПЕРЕДНЕГО ПЛАНА в PictureBox

//-----------------------------------------------------------------------

private void buttonDrawForeground_Click(object sender, System.EventArgs e) {

SetPictureBoxDimensions();

CreateForeground();

pictureBox1.Image = m_foregroundBitmap;

}

//-----------------------------------------------------------------------

//ОБРАБОТЧИК СОБЫТИЙ: Наложить изображение ПЕРЕДНЕГО ПЛАНА на изображение

// ЗАДНЕГО ПЛАНА. Использовать МАСКУ ПРОЗРАЧНОСТИ, чтобы желтый

// цвет в изображении ПЕРЕДНЕГО ПЛАНА стал прозрачным и через

// него можно было видеть содержимое изображения

// ЗАДНЕГО ПЛАНА

//-----------------------------------------------------------------------

private void buttonDrawBackgroundPlusForeground_Click(object sender, System.EventArgs e) {

SetPictureBoxDimensions();

CreateForeground();

CreateBackground();

//Получить объект Graphics изображения ЗАДНЕГО ПЛАНА, поскольку

//именно поверх него мы собираемся рисовать. System.Drawing.Graphics gfx;

gfx = System.Drawing.Graphics.FromImage(m_backgroundBitmap);

//-------------------------------------------------------

//Создать класс ImageAttributes. Этот класс позволяет нам

//задать прозрачный цвет на наших операций рисования

//-------------------------------------------------------

System.Drawing.Imaging.ImageAttributes trasparencyInfo = new System.Drawing.Imaging.ImageAttributes();

//----------------------

//Задать прозрачный цвет

//----------------------

trasparencyInfo.SetColorKey(System.Drawing.Color.Yellow, System.Drawing.Color.Yellow);

//Задать прямоугольник рисунка

System.Drawing.Rectangle rect = new System.Drawing.Rectangle(0, 0, m_backgroundBitmap.Width, m_backgroundBitmap.Height);

//-----------------------------------------------------------------------

//Нарисовать изображение ПЕРЕДНЕГО ПЛАНА поверх изображения ЗАДНЕГО ПЛАНА

//и использовать прозрачный цвет в ImageAttributes для создания окна

//прозрачности, через которое виден задний план

//-----------------------------------------------------------------------

gfx.DrawImage(m_foregroundBitmap, rect, 0, 0, m_foregroundBitmap.Width,

m_foregroundBitmap.Height, System.Drawing.GraphicsUnit.Pixel, trasparencyInfo);

//Очистить

gfx.Dispose();

//Показать результат в виде растрового изображения

pictureBox1.Image = m_backgroundBitmap;

}

Встраивание изображений в виде ресурсов приложений

Во многих приложениях растровые изображения используются для того, чтобы предоставить пользователям красочный интерфейс. Нестандартные кнопки с нарисованными поверх них изображениями, графические изображения, используемые в иллюстративной графике, логотипы и другие изображения заднего плана — все это улучшает визуальный облик мобильного приложения. Вместо того чтобы заново создавать сложные рисунки, в играх интенсивно используют заранее заготовленные изображения. Поэтому очень часто удобно иметь изображения, встроенные в двоичный код приложения. Далее эти изображения автоматически развертываются вместе с приложением; такая практика гораздо более надежна, чем работа с множеством файлов изображений наряду с файлом приложения. Встраивание изображений не сопровождается увеличением общего размера приложения по сравнению с использованием отдельных файлов; в обоих случаях мы имеем дело с бинарными потоками изображений, к которым ваше приложение получает доступ по мере необходимости.

Чтобы использовать двоичные ресурсы, встроенные в приложение, вам необходимо следующее:

1. Изображения должны быть скомпилированы и включены в состав вашего приложения. Это можно указать во время проектирования в среде разработки.

2- Ваше приложение должно знать, где найти ресурсы во время выполнения. Для обращения к двоичным ресурсам, встроенным в откомпилированные сборки .NET, используется синтаксис, аналогичный путям доступа к файлам, позволяющий указывать местоположение ресурсов в загруженных сборках вашего приложения во время выполнения.

Далее мы остановимся на обоих этих моментах.

Как встроить изображение в приложение

В Visual Studio .NET процесс включения двоичных ресурсов в приложение осуществляется сравнительно несложно:

1. Запустите Visual Studio .NET.

2. Создайте проект C# Smart Device Application.

3. Выберите в меню Project (Проект) команду Add Existing ltem (Добавить существующий элемент).

4. В открывшемся диалоговом окне Add Existing Item измените установку фильтра Files of Type (Тип файлов) на Image Files (Файлы изображений).

5. Найдите файл изображения, который вы хотите добавить, и выделите его. (Примечание. Я настоятельно рекомендую выбирать файлы размером менее 300 Кбайт, иначе вы будете создавать в своем приложении гигантские файлы изображений, которые по своим размерам, скорее всего, будут превышать само приложение; растровые изображения с чрезмерно большим разрешением могут приводить к нехватке памяти устройства при их загрузке во время выполнения.) В данном примере мы будем полагать, что загружается файл MyImage.PNG.

6. Перейдя в окно Visual Studio .NET Solution Explorer, выделите только что добавленный файл изображения (MyImage.PNG), щелкните на нем правой кнопкой мыши и выберите в открывшемся контекстном меню пункт Properties (Свойства).

7. В открывшемся диалоговом окне Properties найдите свойство Build Action (Действие при сборке). По умолчанию для него устанавливается значение Content (Содержимое); это означает, что файл изображения будет копироваться на устройство вместе с приложением при его развертывании.

8. Измените значение свойства Build Action на Embedded Resource (Встроенный ресурс); это означает, что двоичное содержимое файла MyImage.PNG будет встраиваться в исполняемый образ приложения всякий раз, когда оно будет компилироваться.

Имена встроенных ресурсов чувствительны к регистру

Независимо от того, чувствителен ли к регистру используемый вами язык программирования (для C# регистр имеет значение, для VB.NET — нет), в именах встроенных ресурсов строчные и прописные буквы различаются. Тщательно следите за правильным использованием регистра букв в именах файлов, которые вы делаете встроенными ресурсами; при поиске потоков ресурсов во время выполнения ваше приложение будет использовать буквы в том же регистре, в котором вы их указали. Если потоки ресурсов не удается найти из-за несовпадения имен, то во время выполнения генерируется исключение. Ошибки подобного рода являются распространенными, и их поиск может заставить вас понервничать, если вы не знаете о том, что надо сразу же проверять, правильно ли указаны регистры букв.

Как получить доступ к встроенному ресурсу приложения

Приведенный в листинге 13.6 код демонстрирует, как загрузить растровое изображение из потока встроенного ресурса в ваше приложение. В соответствии с предыдущим изложением в качестве изображения для примера используется файл MyImage.PNG. Этот код следует поместить в форму с элементами управления Button и PictureBox. Как и в предыдущих примерах, для подключения события button1_click к кнопке button1 следует дважды щелкнуть на кнопке в окне конструктора форм, в результате чего будет автоматически сгенерирован костяк функции.

Листинг 13.6. Код формы, демонстрирующий загрузку встроенных ресурсов

System.Drawing.Bitmap m_myBitmapImage;

//------------------------------------------------------------------

//Загрузить изображение, которое хранится в виде встроенного ресурса

//в нашей сборке

//------------------------------------------------------------------

public void LoadImageFromResource() {

//Если изображение уже загружено,

//то не имеет смысла делать это повторно.

if (m_myBitmapImage !=null) {

return;

}

//----------------------------------------------------

//Получить ссылку на двоичную сборку нашего приложения

//----------------------------------------------------

System.Reflection.Assembly thisAssembly = System.Reflection.Assembly.GetExecutingAssembly();

//-------------------

//Получить имя сборки

//-------------------

System.Reflection.AssemblyName thisAssemblyName = thisAssembly.GetName();

string assemblyName = thisAssemblyName.Name;

//-----------------------------------------------------------------------

//Извлечь поток изображения из нашей сборки и создать соответствующую

//ему битовую карту в памяти.

//ПРИМЕЧАНИЕ: Имя потока ресурса ResourceStream ЧУВСТВИТЕЛЬНО К РЕГИСТРУ,

// поэтому имя изображения должно В ТОЧНОСТИ совпадать с именем

// файла изображения, который вы добавили в проект

//-----------------------------------------------------------------------

m_myBitmapImage = new System.Drawing.Bitmap(thisAssembly.GetManifestResourceStream(assemblyName + ".MyImage.PNG"));

}

//-----------------------------------------------------------

//Загрузить изображение и отобразить его в объекте PictureBox

//-----------------------------------------------------------

private void button1_Click(object sender, System.EventArgs e) {

LoadImageFromResource();

pictureBox1.Image = m_myBitmapImage;

}

Форматы хранения изображений и прозрачность растровых изображений

При использовании изображений в приложении очень важно правильно выбрать для них формат хранения. Для крохотных битовых образов (например, 8×8 пикселей) применение сжатия смысла не имеет, поскольку они и так малы. В случае более крупных изображений можно сэкономить довольно много места по сравнению с несжатыми форматами (например, *.BMP), используя сжатые форматы с потерями (например, *.JPG) или без потерь (например, *.PNG). Несжатые фоновые изображения с размерами порядка размеров экрана могут значительно увеличить общий размер приложения. Особое внимание следует уделять выбору форматов хранения для изображений, в которых один цвет будет считаться прозрачным во время выполнения; в таких случаях необходимо использовать только форматы со сжатием без потерь. Сжатие с потерями часто позволяет сэкономить много места, но этого удается достигнуть лишь ценой ослабления контроля за каждым отдельным пикселем изображения; вы получаете лишь приближенное изображение. Растровые изображения с областями прозрачности требуют точного указания цвета каждого пикселя.

Резюме

Создание отличного пользовательского интерфейса — это трудная, однако увлекательная задача проектирования. Во-первых, вы должны либо адаптировать идею своего проекта к привычным схемам использования и форм фактору выбранного вами целевого устройства, либо выбрать подходящий тип мобильных устройств, который соответствует проектным целям. Мобильные устройства значительно отличаются от настольных компьютеров и лэптопов своим интерфейсом и стереотипом использования. Также и различные классы устройств значительно отличаются друг от друга. Попытки разработки пользовательского интерфейса, способного хорошо работать на различных устройствах, — это гарантия того, что он будет плохо работать на каждом из них. Чтобы обеспечить наилучшие условия работы для пользователя, определяйте для себя целевые мобильные устройства и оптимизируйте интерфейс мобильного приложения применительно к каждому конкретному случаю.

В процессе принятия проектных решений очень важно учитывать, будут ли пользователи работать с интерфейсом вашего приложения с помощью одной или двух рук. Часто это решение диктуется особенностями оборудования, которое выбрано вами в качестве целевого; например, с сенсорными экранами обычно работают, используя две руки, а с мобильными телефонами — обычно одну. Явно укажите в своем основном документе проекта, для какого варианта использования предназначено приложение, и следите за учетом этого требования на протяжении всего процесса проектирования и разработки. При проектировании интерфейсов, которыми пользователь будет оперировать одной рукой, важно учитывать единообразие способов и простоту навигации в пределах интерфейса при помощи щелчков; не заставляйте пользователя при перемещении по часто встречающимся навигационным маршрутам менять кнопки. В процессе навигации по вашему приложению пользователь не должен быть вынужденным переводить взгляд с экрана устройства на клавиатуру; это отвлекает его и нарушает плавность течения его мыслей.

Огромное влияние на проект будут оказывать размеры экрана, являющегося целевым для вашего мобильного приложения. Для небольших экранов целесообразно использовать пользовательские интерфейсы, основанные на списках; в случае экранов большего размера, при работе с которыми применяются сенсорная площадка или мышь, лучшим решением для навигации между экранами будет метафора диалоговых окон-вкладок. Распределите функциональность своего мобильного приложения между несколькими специализированными экранами. Тщательно продумайте, какую информацию вы хотите отобразить на каждом из экранов и как облегчить навигацию между ними. Приложения для настольных компьютеров обычно отображают несколько абзацев информации одновременно. В приложениях для Pocket PC чаще встречается вариант отображения одного абзаца информации с одновременным отображением ссылок на другие абзацы. В смартфонах обычно отображаются сводные списки, с помощью которых пользователь может углубляться в структуру списков и просматривать каждую порцию информации по отдельности.

Поскольку мобильные устройства обычно не имеют полноценной клавиатуры, в большинстве случае быстрый ввод текста не является их сильной стороной. Поэтому, если требуется ввод данных, целесообразно не жалеть усилий на оптимизацию производительности труда пользователя при вводе распространенных разновидностей данных. Часто можно облегчить пользователю ввод таких специфических данных, как даты, числа, валюта, адреса или любые другие данные, отличающиеся от свободного текста, за счет разработки специализированных интерфейсов с крупными кнопками или адаптированных элементов управления. Обеспечить ускоренный ввод специфических данных могут также такие внешние устройства, как устройства для считывания штрих-кодов или устройства для распознавания речи и визуальных образов, однако ваше мобильное приложение должно предлагать пользователю и параллельные возможности ввода той же информации на случай сбоя упомянутых внешних устройств, что неизбежно случается.

Процесс разработки чрезвычайно ускоряется при использовании программных эмуляторов устройств, но эмуляторы не в состоянии заменить реальные устройства при тестировании удобства использования приложения. Эмулятора, выполняющегося на лэптопе, совершенно недостаточно для того, чтобы оценить истинные эксплуатационные характеристики приложения при его выполнении на физическом мобильном устройстве. Навигационные возможности, средства ввода, вес устройства, удобство работы и условия обзора данных — вот те параметры, точная оценка которых возможна только при тестировании приложения на реальном оборудовании.

В процессе написания кода пользовательского интерфейса для мобильного приложения очень важно структурировать код таким образом, чтобы внесение изменений в ранее разработанные участки кода, если это потребуется, не составляло труда. Получение окончательного варианта пользовательского интерфейса будет сопровождаться постоянным возвратом к пересмотру ранее принятых вами схем компоновки и навигации. Чтобы эти изменения можно было легко вносить, ваш код должен быть гибким. Для изоляции обработки событий одних элементов управления от обновления других могут эффективно использоваться централизация управления кодом пользовательского интерфейса в конечном автомате и интерфейсные функции, что позволит существенно повысить гибкость вашего проекта. Крайне важно избегать распределения ответственности за управление пользовательским интерфейсом между различными частями приложения; чем больше степень централизации кода, управляющего пользовательским интерфейсом, тем проще его будет модифицировать, если в этом возникнет необходимость. Использование вспомогательных классов для группирования родственных функций пользовательского интерфейса, например, всех обработчиков событий элементов управления, расположенных на данной вкладке, также способствует изоляции кода пользовательского интерфейса от остального кода. Надежно абстрагированный интерфейс между функциональной логикой приложения и логикой уровня представления крайне важен для повышения гибкости проекта. Дополнительным преимуществом создания надежно инкапсулированного кода пользовательского интерфейса является то, что это значительно облегчает перенос вашего мобильного приложения на мобильные устройства других классов.

.NET Compact Framework предлагает некоторые улучшенные возможности пользовательского интерфейса, которые могут пригодиться вам при разработке интерфейсов для многофункциональных мобильных приложений. .NET Compact Framework предоставляет разработчикам возможность создавать пользовательские элементы управления двух видов: 1) пользовательские элементы управления, которые являются производными от класса System.Windows.Forms.Control и реализуют собственные возможности визуализации с нуля, и 2) пользовательские элементы управления, которые реализуют соответствующие свойства поверх существующих элементов управления путем произведения этих свойств от таких не являющихся абстрактными элементов управления, как System.Windows.Forms.Control.TextBox, и расширения свойств последних. Полезны обе разновидности пользовательских элементов управления. Чрезвычайно полезна возможность динамического создания пользовательских элементов управления во время выполнения; создание версии элемента управления .NET Compact Framework во время проектирования может оказаться трудоемкой задачей, и если только создание пользовательских элементов не является одним из сегментов вашей деятельности на рынке, то лучше отказаться от этого шага и просто создавать экземпляры пользовательских элементов управления динамически во время выполнения.

Возможность устанавливать прозрачные цвета при копировании растровых изображений позволяет приложению создавать богатые графические образы, которые могут вам пригодиться в приложениях развлекательного, производственного и научного характера.

Ключом к созданию рисунков с использованием прозрачности при работе с .NET Compact Framework является использование класса System.Drawing.Imaging.ImageAttributes; этот класс позволяет вашему коду устанавливать ключевой цвет, который будет трактоваться как прозрачный при копировании исходного растрового изображения в изображение назначения. Области прозрачности могут оказаться полезными при работе со всеми разновидностями растровых изображений, от текста и фигур, динамически рисуемых на битовых картах, до заранее подготовленных изображений, загружаемых во время выполнения. Используемые растровые изображения могут храниться в виде части двоичного образа вашего приложения; разворачивать приложение значительно легче, если количество файлов, от которых оно зависит, невелико.

Разработка пользовательского интерфейса для мобильного устройства — это трудная, но благодарная работа, которая может доставить массу удовольствия. Она требует проявления незаурядного творчества и понимания того, какая существенная информация должна быть представлена пользователю, и какая метафора средств навигации будет наиболее подходящей. Также чрезвычайно интересно проводить различного рода эксперименты, что позволит вам очень быстро учиться по мере того, как вы будете на практике испытывать самые различные концепции. Как уже отмечалось в предыдущих разделах данной книги, то, насколько производительным приложение кажется пользователю, является очень важным аспектом приложения, которое можно считать удобным в работе. Если вы настроены на поддержание высокой производительности приложения, творчески мыслите и пишете код, предусматривая в нем встроенные средства обеспечения гибкости, то работа и эксперименты в процессе проектирования пользовательских интерфейсов приложений для мобильных устройств значительно расширят ваш опыт и доставят огромное удовольствие.

ГЛАВА 14

Шаг 3: разработка подходящей модели данных

Автор данной книги настаивает, что точно так же, как существует мало анекдотов о библиотекарях, отсутствуют и краткие, но содержательные высказывания в адрес баз данных или доступа к данным. Слишком уж утилитарен этот предмет. И пусть читатель попробует доказать автору, что он не прав.

Иво Салмре

Введение в модели доступа к данным, используемые в мобильных приложениях

После того как вы приняли решение относительно сферы применения вашего приложения, настроились на использование методологии разработки, ориентированной на обеспечение высокой производительности, и определились с моделью пользовательского интерфейса, важно подобрать для мобильного приложения подходящую модель доступа к данным.

Модель доступа к данным описывает, каким образом приложение удовлетворяет свои потребности в извлечении и хранении долгосрочной информации. Как уже обсуждалось в данной книге, модели памяти определяют, каким образом приложение управляет данными и ресурсами, находящимися в памяти; точно так же, вашему мобильному приложению потребуется модель доступа к данным, которая определяет, каким образом осуществляется обмен данными между приложением и долговременными хранилищами.

Практически любое более или менее значимое приложение работает с данными, существующими в течение длительного времени. Эти данные могут либо находиться в структурированной базе данных на сервере или устройстве, либо храниться в индивидуально управляемых файлах с использованием менее формализованных способов.

В приложениях научно-производственного характера, а также приложениях, предназначенных для повышения производительности труда, операции, связанные с вводом, манипулированием, анализом и отображением данных, занимают центральное место. Мощные игры также работают с данными и часто хранят их в течение промежутков времени, разделяющих игровые сеансы. В целом, можно полагать, что чем сложнее и полезнее приложение, тем больше ему приходится работать с долговременными данными.

Что касается доступа к данным, то между мобильными приложениями и их настольными и серверными аналогами имеется важное отличие, суть которого заключается в том, что связь между мобильным устройством и серверами баз данных, находящимися вне устройства, обычно устанавливается лишь на короткие промежутки времени. Если настольному приложению не удается получить доступ к серверу, то обычно это означает нарушение нормального режима работы, которое требуется устранить. В то же время, отсутствие доступа к серверу в случае мобильных приложений — это их обычное состояние; исключительными ситуациями для них являются, скорее, сеансы связи с сервером, поскольку либо необходимость в них возникает реже, либо их стоимость высока. Из-за этого фактора управление данными, создание их динамических представлений и внесение изменений пользователем могут представлять некоторые трудности. Данные характеризуются как длительностью их существования в памяти, так и длительностью их долговременного хранения; при проектировании мобильного приложения следует учитывать обе эти характеристики. Модель данных вашего мобильного приложения представляет состояние, которым требуется управлять, чтобы создать для пользователя комфортные условия работы с приложением.

Распространенной ошибкой разработчиков является простой перенос на мобильные устройства моделей доступа к данным, которые применяются на настольных компьютерах и серверах, в неизменном виде, без тщательного анализа того, как это повлияет на использование памяти. Тот факт, что с подобной ошибкой приходится сталкиваться часто, вполне объясним, поскольку с точки зрения синтаксиса все программные модели аналогичны друг другу, и во многих случаях код, выполняющийся на настольных компьютерах и серверах, легко переносится на устройства. В то же время, простой перенос стратегий доступа к данным с настольных компьютеров и серверов на мобильные устройства позволяет получить удовлетворительные результаты лишь в редких случаях. Причину этого можно описать двумя словами — "состояние памяти". Более высокая степень абстрагирования часто достигается за счет создания объектов на дополнительных уровнях абстракции. Как создание, так и уничтожение этих объектов приводят к более жестким условиям использования памяти и занимают процессорное время.

Для мобильных приложений вопрос о выборе модели доступа к данным оказывается непосредственно связанным с вопросом о выборе модели управления памятью в гораздо большей степени, чем в случае приложений для настольных компьютеров. Если памяти, необходимой для обслуживания потребностей обеих моделей, едва хватает, то это может серьезно сказаться на производительности приложения. Аналогично средствам для работы с XML-данными, существуют низкоуровневые API-интерфейсы, не использующие состояния, и высокоуровневые программные модели доступа к памяти, предлагающие более развитые возможности, но кумулятивно изменяющие состояние в процессе выполнения. Использование высокоуровневых моделей доступа к данным позволяет сократить сроки написания кода, однако за это приходится платить увеличением объема памяти, используемой для хранения информации о состоянии. Если эта информация действительно нужна и используется мобильным приложением, а объем данных, которыми при этом приходится оперировать в памяти, можно поддерживать на низком уровне, то привлечение стратегий доступа к данным, основанных на использовании состояний, является оправданным. И наоборот, если объем данных, которые приходится хранить в памяти, велик или необходимость в дополнительных возможностях, предоставляемых высокоуровневой моделью программирования, отсутствует, то разработчик, выбравший этот путь, будет только напрасно тратить драгоценную память мобильного устройства. Часто хранение тех же данных можно организовать гораздо более эффективным образом за счет отказа от универсальной программной модели доступа к данным и использования наборов типов, специально предназначенных для работы с конкретными данными, которыми необходимо управлять. Неэкономное использование памяти окажет значительное отрицательное влияние на производительность мобильного приложения; при этом проблемы производительности проявятся либо немедленно, либо впоследствии, когда вы попытаетесь ввести в приложение дополнительную функциональность, поскольку для организации поддержки новых средств вам просто не хватит резерва производительности. По возможности, старайтесь избегать излишнего усложнения приложения.

Впервые приступая к реализации стратегий доступа к данным на мобильных устройствах, разработчики, профессиональная деятельность которых была до этого связана с настольными компьютерами и серверами, обычно делают вывод, что мобильные устройства просто не в состоянии обеспечить тот уровень производительности, который требуется. На самом деле это почти всегда не соответствует действительности. Что необходимо сделать — так это тщательно проанализировать требования к доступу данных, предъявляемые мобильным приложением, и спроектировать такую модель данных, которая наилучшим образом соответствовала бы этим требованиям. Например, если данные в основном только считываются, то можно добиться выигрыша в эффективности, сохраняя данные в памяти с использованием нестандартного формата, оптимизированного для уменьшения суммарного объема данных и увеличения скорости проведения поиска, а не для обновления данных; в случае настольных компьютеров эта мера может привести лишь к незначительному увеличению производительности приложения, тогда как в случае мобильных устройств достигаемое при этом улучшение результатов может быть разительным.

Выбор подходящих абстракций для хранения данных в памяти

Чтобы данные, возвращенные в результате запроса к базе данных или считанные из файла, можно было просматривать и манипулировать ими, они должны храниться в памяти. Существует два основных способа работы с такими данными, находящимися в памяти:

1. Применение универсальной абстрактной модели.  Для работы с данными, извлекаемыми из баз данных, во многих программных каркасах предлагаются абстрактные модели. В .NET Compact Framework такой моделью является ADO.NET, использование которой описывается далее в этой главе; другие каркасы поддерживают другие модели. Достоинством абстрактных моделей является их гибкость. Данные, извлеченные из баз данных, хранятся в обобщенных таблицах и строках объектов. В каждой строке содержатся поля, соответствующие определенным столбцам. Таблицу образует сетка, состоящая из строк и столбцов. Таблицы можно группировать в наборы, причем для описания отношений между столбцами различных таблиц применяются дополнительные таблицы. Если выполняется обобщенный запрос к базе данных и заранее не известно, какого рода данные будут получены в ответ на этот запрос, то сохранение их в подобного рода обобщенном формате является необходимостью. Современные развитые модели доступа к данным могут также отслеживать внесение локальных изменений. Впоследствии эти изменения могут быть отвергнуты, приняты или иным образом приведены в соответствие с данными, хранящимися в базе данных. Кроме того, различные программные каркасы для доступа к данным поддерживают выполнение транзакций и локальное создание гибких представлений данных. Существуют также обобщенные модели связывания данных, которые обеспечивают связывание табличных данных с элементами пользовательского интерфейса. Эти универсальные модели программирования доступа к данным обладают высокой гибкостью, устойчивы к изменению формата базы данных и обеспечивают абстракции, предназначенные для просмотра типов данных, с которыми приходится работать, во время выполнения. Подобная гибкость дается за счет введения дополнительных объектов. Эти объекты содержат метаданные (метаданные — суть информация об информации), хранят отношения между различными элементами данных и отслеживают вносимые изменения. При использовании таких высокоуровневых технологий доступа к данным, хранимым в памяти, ваше приложение фактически создает в памяти базу данных; обладая значительными возможностями, этот подход предъявляет высокие требования к вычислительным ресурсам и памяти

2. Применение пользовательской модели, приспособленной для работы с вашими данными. Противоположностью абстрактной модели для работы с данными является "подход для бедных", основанный на создании пользовательской реализации, которая содержит лишь то, что требуется для хранения и использования данных. При применении пользовательской стратегии доступа к данным ваше мобильное приложение самостоятельно распоряжается абстракциями, предлагаемыми встроенной в память базой данных обобщенных строк, столбцов, таблиц и отношений, и выбирает способ хранения данных в формате, который больше всего подходит для решаемой задачи. Обычно для этой цели применяется массив простых типов, которые содержат данные. Эта пользовательская модель во многом лишена гибкости универсального подхода и вынуждена брать на себя заботу об обновлении данных и управлении отношениями между ними. Его преимущество состоит в том, что за счет использования исключительно тех объектов, без которых нельзя обойтись, у приложения появляется возможность значительно снизить объем памяти, занимаемой информацией о состоянии. Если данные, с которыми ведется работа, можно легко представить в виде единственной таблицы, а отношения между ними не отличаются сложностью, то приспособленный для конкретных целей пользовательский формат является отличным решением.

Выбор наиболее подходящей модели определяется объемом и сложностью используемых данных. Было бы непозволительной ошибкой строить собственную модель данных, если они связаны между собой сложной системой отношений, которая нуждается в управлении и в представлениях в памяти мобильного приложения. Вместе с тем, если ваши данные состоят из нескольких простых полей в единственной таблице базы данных, а данные предназначены только для чтения, то было бы глупо останавливать свой выбор на сложной модели данных с поддержкой состояния, если простой массив данных позволяет отлично справиться с задачей. Вполне вероятно, что потребности в данных вашего приложения занимают промежуточное положение между этими двумя крайними случаями, и вам придется испытать несколько различных моделей, чтобы, в конечном счете, выбрать ту из них, которая в наибольшей степени соответствует вашим запросам. Как ранее обсуждалось, этот выбор аналогичен принятию разработчиками мобильных приложений решения о том, какую технологию следует применить при работе с XML-данными. Разработчик должен выбирать между потенциальной простотой проектирования и реализации и эффективностью выполнения приложения.

Выбор подходящей модели данных, требующих долговременного хранения

Модель долговременного хранения данных описывает, куда направляется информация после того, как приложение завершает работу. Даже мобильные устройства, которые включены постоянно и выполняют приложения на фоне, нуждаются в безопасном и структурированном хранилище долговременных данных. Типичным примером такого приложения в случае мобильных телефонов является электронная записная книжка (Personal Information Manager — PIM). Пользователь, разместивший в телефоне свою адресную книгу, рассчитывает на возможность доступа к этим данным вне зависимости от того, в каком состоянии находится телефон. Если это только вообще возможно, для таких данных должна автоматически создаваться резервная копия на сервере или настольном компьютере, чтобы их можно было быстро восстановить в случае сбоя долговременного запоминающего устройства телефона. Выбирая модель долговременного хранения данных мобильного приложения, вы должны ответить на два основных вопроса:

1. Должны ли данные храниться в файле или в базе данных? Если объем подлежащих хранению данных небольшой, то для этого, вероятно, лучше всего воспользоваться текстовым файлом. Если необходимо обеспечить максимально благоприятные условия для переноса файла с одного устройства на другое, то отличным выбором будет XML. В то же время, если ваше приложение работает с большими объемами данных, к которым требуется произвольный доступ, если необходимо обеспечить безопасность данных или если вы хотите использовать расширенные запросы, транзакции и синхронизацию данных, то наилучшим решением будет база данных. Основной недостаток использования баз данных состоит в том, что это влечет за собой дополнительные накладные расходы, а также необходимость дополнительной настройки, которая может потребоваться для развертывания приложения.

2. Точно так же как и в случае настольных приложений, можно либо обращаться непосредственно к базам данных, выполняющимся на сервере, либо хранить базы данных локально. Преимуществом баз данных, размещаемых на устройстве, является их доступность; вы можете обратиться к такой базе данных в любой момент, независимо от наличия соединения с сервером. Если необходимо получать доступ к большим объемам данных, то использование локальной базы данных может оказаться гораздо более эффективным, нежели пересылка результатов запросов на устройство через сравнительно медленное беспроводное соединение. К недостаткам локальных баз данных относятся дополнительная сложность развертывания приложения и необходимость в дополнительном объеме памяти для базы данных. Важно также знать, что различные мобильные устройства обладают различными возможностями поддержки локальных баз данных. Так, на момент написания данной книги база данных SQL СЕ поддерживалась на Pocket PC, но не поддерживалась на смартфонах. Если ваше приложение не может рассчитывать на использование базы данных на локальном устройстве, то вам, вероятнее всего, придется предусмотреть пользовательский механизм локального кэширования данных, которые являются для вас наиболее важными, к которым чаще всего производится обращение или доступ к которым стоит слишком дорого.

Какой способ хранения данных лучше использовать: флэш-память или файл в ОЗУ?

Для долговременного хранения информации на мобильных устройствах обычно используется одна из двух стратегий: флэш-память или файл в системном ОЗУ. Флэш-память — это память, в которой данные могут храниться в течение длительного времени, не требуя постоянного подвода питания. Конструктивно флэш-память может выполняться либо в виде съемной карты (например, Secure Digital, Compact Flash), либо в виде встроенного элемента устройства. В настоящее время флэш-память большой емкости встречается довольно часто; карты емкостью 512 Кбайт уже не являются диковинкой, причем их емкость продолжает расти. Кроме того, флэш-память потребляет меньше электроэнергии по сравнению с ОЗУ, поскольку не должна непрерывно выполнять электрическое обновление. В то же время, доступ к флэш-памяти осуществляется медленнее, чем к энергозависимой памяти; особенно это касается записи данных. Кроме того, биты информации, которые хранятся во флэш-памяти, из-за процессов старения обычно могут обновляться лишь ограниченное число раз; в типичных случаях значение этого показателя составляет несколько сотен тысяч записей, и хотя это число очень большое, оно, однако, не является бесконечным. Несмотря на то что в отношении повышения гибкости флэш-памяти достигнут существенный прогресс, она уступает в этом ОЗУ. В настоящее время флэш-память можно использовать вместо жесткого диска, но не вместо энергозависимого программного ОЗУ.

Следует отметить, что SIM-карты в мобильных телефонах для GSM-связи также имеют флэш-память, предусмотренную для хранения ограниченного объема данных. Это пространство традиционно использовалось для хранения адресной книги мобильного телефона, но в современных телефонах большая часть этих данных хранится в памяти телефона, которая обеспечивает более быстрый и гибкий доступ. SIM-карты по-прежнему оказываются полезными в качестве памяти для хранения такой специфической "секретной" информации, как криптографические сертификаты и ключи, однако, в силу доступности других разновидностей универсальной флэш-памяти, для хранения информации общего назначения они используются все реже и реже.

Флэш-память можно считать аналогичной жесткому диску, в котором отсутствуют подвижные элементы. Ключи памяти USB, которые можете вставлять в ПК, также представляют собой флэш-память. Как и для жестких дисков, для флэш-памяти обычно также предусматривается построенная поверх нее файловая система, что обеспечивает быстрый структурированный доступ к данным.

Другой распространенный способ долговременного хранения информации на устройствах предусматривает использование файловых систем на основе ОЗУ. В отличие от файловых систем, основанных на флэш-памяти, файловые системы ОЗУ используют часть доступной памяти устройства. Хранилища в ОЗУ характеризуются меньшим временем доступа как при чтении, так и при записи данных, но потребляют значительно больше электроэнергии по сравнению с флэш-памятью. Файловые системы, хранимые в ОЗУ, требуют питания даже тогда, когда устройство выключено; если извлечь батарею или она разрядится, то содержимое файловой системы будет утеряно. Это делает файловые системы в ОЗУ более уязвимыми по сравнению с флэш-системами. На многих устройствах, включая системы Windows CE/Pocket PC, файлы, как правило, сохраняются в файловых системах ОЗУ с использованием алгоритмов сжатия. Тем самым эффективно увеличивается емкость файловой системы, но увеличивается время обработки, поскольку чтение и запись потоков данных должны сопровождаться работой алгоритма сжатия. Файловые системы ОЗУ работают быстро — значительно быстрее, чем флэш-память, но все же медленнее, чем осуществляется обработка данных, хранящихся непосредственно в памяти.

Устройства могут поддерживать файловые системы одновременно и во флэш-памяти, и в ОЗУ точно так же, как настольные системы могут поддерживать несколько жестких дисков. Используемые модели долговременного хранения данных могут существенно различаться между собой даже для близких по типу мобильных устройств. Так, на Pocket PC и смартфонах используются разные модели долговременных хранилищ. По умолчанию на Pocket PC используется файловая система на основе ОЗУ; именно по этой причине на устройствах Pocket PC устанавливаются значительно более мощные батареи, чем на смартфонах. На смартфонах главным образом используются файловые системы на основе флэш-памяти. Как Pocket PC, так и смартфоны поддерживают динамическую вставку карт флэш-памяти в процессе работы; благодаря этому устройства имеют возможность доступа к музыкальным файлам, рисункам и любым другим данным, хранящимся на картах

Емкость и эффективность организации хранения файлов на устройствах различных классов является еще одной причиной того, что стратегии, в основе которых лежит принцип "пишется однажды — выполняется везде", в случае мобильных устройств редко когда приводят к удовлетворительным результатам. Насколько эффективно осуществляется обмен данными с памятью, зависит от характеристик используемой на устройстве запоминающей среды и ее емкости. Очень важно знать, какие форматы хранения данных поддерживаются целевым устройством, и тщательно анализировать, каким образом приложение использует эти возможности. Знание этих факторов позволяет оптимизировать доступ к данным, хранящимся на устройстве, и стратегию их хранения исходя из требований производительности и устойчивости работы приложения. Кроме того, ясное понимание механизмов долговременного хранения данных облегчает перенос мобильного приложения с одного устройства на другое.

Специфика .NET Compact Framework: ADO.NET

ADO.NET — мощная многоуровневая программная модель, предназначенная для работы с реляционными данными любого вида. ADO.NET доступна на настольных компьютерах и серверах как часть .NET Framework, а на устройствах — как часть .NET Compact Framework. Поддержка ADO.NET в .NET Compact Framework основана на подмножестве программной модели, предназначенной для настольных компьютеров и серверов.

Ключевым новшеством в модели данных ADO.NET для серверов, настольных компьютеров и устройств является полное отделение объекта ADO.NET DataSet от источника данных. Как только данные попали в ADO.NET DataSet, их можно сериализовать в виде XML-данных и сохранить в локальном файле или передать по сети на сервер, настольный компьютер или мобильное устройство.

Между объектом ADO.NET DataSet и базами данных, предоставившими данные, не требуется поддерживать постоянное соединение; это обстоятельство является замечательным с точки зрения масштабируемости серверов, поскольку необходимость в поддержании постоянного соединения отрицательно воздействует на этот их аспект.

Для работы с базами данных использование в приложении объекта ADO.NET не является обязательным

Объекты DataSet — замечательная абстракция, но они не всегда являются наилучшим способом организации доступа к данным. Если требуется только считывать данные, то имеет смысл работать непосредственно с данными, предоставляемыми объектом ADO.NET DataReader, сохраняя их в наиболее эффективном для задачи, которую вы пытаетесь решить, формате. Более подробно по этому поводу говорится далее в этой главе.

Элементарные сведения об объектах ADO.NET DataSet

ADO.NET предлагает множество мощных концепций, которые поначалу кажутся сложными и обескураживают пользователей, привыкших работать с другими моделями доступа к данным. На самом же деле использовать ADO.NET довольно просто, но это требует от разработчика вдумчивого отношения к этой модели и означает отказ от понятия курсора данных как центрального механизма для работы с данными.

Чтобы вы смогли лучше во всем разобраться, целесообразно сравнить ADO.NET с ее предшественницей — технологией ADO. Как говорит само название, объект ADO.NET DataSet теснее связан с математической идеей "набора данных" (data set), чем с традиционной идеей ADO о "наборе записей" (record set), который представляет строки записей в таблице и предоставляет курсор, позволяющий переходить от одной записи к другой. Объекты ADO.NET DataSet "не имеют курсора" в том смысле, что в этом случае понятие текущей записи и курсора, осуществляющего переключение контекста при переходе от записи к записи, отсутствует. В ADO.NET DataSet все записи просто существуют в виде набора и допускают произвольные переходы между записями без использования курсора, отслеживающего текущую запись. Кроме того, объекты DataSet не являются специфичными по отношению к таблицам; объект ADO.NET DataSet может содержать любое количество таблиц данных, равно как и любое количество информации об отношениях между таблицами. Прежние объекты ADO RecordSet позволяют проходить по одной таблице, содержащую информацию, тогда как объекты ADO.NET DataSet позволяют исследовать одну или несколько таблиц данных.

Создание мостика между подходом, основанным на наборах данных, и моделью, в которой для работы с данными используются строки, обеспечивается объектами ADO.NET DataView и DataTable. Один объект DataSet может содержать любое количество объектов DataTable. Таблица данных (data table) фактически является массивом объектов, аналогичным таблице в базе данных. Объекты DataView — это объекты, предоставляющие методы фильтрации и сортировки поверх объектов DataTable, что позволяет добираться среди содержимого объекта DataSet до данных, которые представляют непосредственный интерес для вашего приложения. Объекты DataView могут также предоставлять отсортированное представление данных (data view), в котором данные упорядочиваются наиболее удобным для использования в приложении и отображения способом. С одной таблицей DataTable может быть связано произвольное количество объектов DataView, для каждого из которых определены свои критерии сортировки и фильтрации, позволяющие создавать пользовательские представления данных.

На настольных компьютерах и серверах .NET Framework поддерживает как "типизированные", так и "нетипизированные" объекты DataSet. В .NET Compact Framework специально поддерживаются только "нетипизированные" объекты DataSet. Может показаться, что тем самым создаются определенные ограничения, однако в действительности это не так, поскольку типизированные объекты DataSet являются просто классами, построенными поверх нетипизированных объектов DataSet, которые жестко связывают имена типизированных полей с лежащими в их основе элементами нетипизированных объектов DataSet. Поскольку типизированный объект DataSet строится поверх нетипизированного класса DataSet, то он, по сути, представляет собой удобную в использовании, но несколько медленнее работающую абстракцию. Приложения, в которых нетипизированные объекты DataSet используются корректным образом, путем поиска и кэширования объектов DataColumn используемых ими столбцов (columns) (в отличие от поиска полей по именам при каждом их использовании), демонстрируют такую же или даже еще лучшую производительность по сравнению с теми, в которых используются типизированные объекты DataSet.

Очень короткий пример использования объектов DataSet, DataTables и XML

Чтобы продемонстрировать основы работы с объектами ADO.NET DataSet, полезно обратиться к примеру. В документации .NET Framework содержится исчерпывающее описание ADO.NET и объектов DataSet. В примере будут показаны лишь самые элементарные операции создания и использования объектов DataSet с целью установления контекста для обсуждения использования ADO.NET на мобильных устройствах.

Приведенный в листинге 14.1 код позволяет создать приложение, представленное на рис. 14.1. Для создания приложения потребуется выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму элемент управления Button. (Ему будет автоматически присвоено имя button1.)

4. Добавьте в форму элемент управления TextBox. (Ему будет автоматически присвоено имя textBox1.)

5. Установите для свойства MultiLine элемента управления TextBox значение true и измените размеры текстового окна таким образом, чтобы оно заняло почти всю форму.

6. Установите для свойства ScrollBar элемента управления TextBox значение vertical.

7. Дважды щелкните на элементе управления Button в окне конструктора форм и введите код функции button1_Click(), приведенный в листинге.

8. Введите весь оставшийся код, приведенный в листинге 14.1.

9. Вернитесь в окно конструктора форм.

10. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

11. Запустите приложение и щелкните на кнопке Button; полученные вами результаты должны воспроизводить те, которые представлены на рис. 14.1.

Рис. 14.1. Простой пример, демонстрирующий создание объекта ADO.NET DataSet

Листинг 14.1. Простой пример создания и использования объекта ADO.NET DataSet

//Объект DataSet, который мы собираемся загрузить

System.Data.DataSet m_myDataSet;

//Константы, которые будут использоваться

const string FILE_EMPTY_DATASET = "EmptyDataSet.xml";

const string FILE_1TABLE_DATASET = "1TableDataSet.xml";

const string dividerLine = "-----------------------------\r\n";

const string nextLine = "\r\n";

//-------------------------------------------------------

//Загрузить содержимое файла и присоединить его к тексту,

//содержащемуся в элементе управления textBox1

//-------------------------------------------------------

private void  addFileContentsToTextBox(string fileName) {

//Открыть файл и считать его содержимое

System.IO.StreamReader myStreamReader;

myStreamReader = System.IO.File.OpenText(fileName);

string fileText = myStreamReader.ReadToEnd();

//Закрыть файл

myStreamReader.Close();

//Присоединить содержимое к тексту, находящемуся в текстовом окне

textBox1.Text = textBox1.Text +

dividerLine + "FILE: '" + fileName + "'" + nextLine +

dividerLine + fileText + nextLine;

}

//-------------------------------------------------------

//1. Создает набор данных,

// сохраняет набор данных в виде XML,

// отображает результаты в текстовом окне

//2. Добавляет таблицу данных в набор данных,

// добавляет два типизированных столбца в таблицу данных,

// добавляет две строки в таблицу данных,

// сохраняет набор данных в виде XML,

// отображает результаты в текстовом окне

//-------------------------------------------------------

private void  button1_Click(object sender, System.EventArgs e) {

//Очистить текстовое окно от содержимого

textBox1.Text = "";

//===========================================

//1. Создать новый набор данных

//===========================================

m_myDataSet = new System.Data.DataSet("HelloWorld-DataSet");

//Записать содержимое ADO.NET DataSet в виде XML и отобразить

//файл в текстовом окне

m_myDataSet.WriteXml(FILE_EMPTY_DATASET);

addFileContentsToTextBox(FILE_EMPTY_DATASET);

//==================================================

//2. Добавить таблицу данных в набор данных ADO.NET,

// а также 2 строки данных в таблицу данных

//==================================================

System.Data.DataTable myTestTable;

myTestTable = m_myDataSet.Tables.Add("TestTable");

//----------------------------

//Добавить 2 столбца в таблицу

//----------------------------

//Добавить столбец данных в таблицу DataTable набора DataSet

myTestTable.Columns.Add("TestColumn0", typeof(System.DateTime));

//Добавить строковый столбец в таблицу DataTable набора DataSet

myTestTable.Columns.Add("TestColumn1", typeof(string));

//--------------------------------

//Добавить строки данных в таблицу

//--------------------------------

//Добавить строку данных в таблицу данных

object[] rowOfData;

rowOfData = new object[2];

//Столбец 0 — это тип даты

rowOfData[0] = System.DateTime.Today;

//Столбец 1 — это строковый тип

rowOfData[1] = "а string of data today";

myTestTable.Rows.Add(rowOfData);

//Добавить вторую строку данных в таблицу данных

object[] rowOfData2;

rowOfData2 = new object[2];

//Столбец 0 — это тип даты

rowOfData2[0] = System.DateTime.Today.AddDays(1);

//Столбец 1 — это строковый тип

rowOfData2[1] = "tomorrow's string";

myTestTable.Rows.Add(rowOfData2);

//Записать содержимое набора ADO.NET DataSet в виде XML и отобразить

//файл в текстовом окне

m_myDataSet.WriteXml(FILE_1TABLE_DATASET);

addFileContentsToTextBox(FILE_1TABLE_DATASET);

} //Конец функции

Отслеживание изменения данных

Объекты ADO.NET DataSet автоматически отслеживают изменения, вносимые в содержащиеся в них данные, включая создание, удаление и изменение строк данных в таблицах данных. Затем эти изменения могут быть приняты или отвергнуты, а принятые изменения переданы в базу данных в соответствии с необходимостью. Если источник данных рассредоточен по нескольким базам данных, то возможно даже обновление данных с использованием распределенных транзакций.

Важно понимать, что объектам ADO.NET DataSet ничего не известно о базах данных, в которых данные хранятся постоянно; для восполнения этого пробела используются классы DataAdapter. Класс ADO.NET DataAdapter предназначен для перемещения данных между объектами ADO.NET DataSet и долговременными хранилищами. Все классы ADO.NET DataAdapter состоят из пользовательского кода; любая логика, необходимая для подключения к источнику данных, с которым ведется работа, получения этих данных и их обновления, пишется разработчиком. По сути дела, объекты ADO.NET DataSet представляют собой небольшие базы данных в памяти, и классы DataAdapter пишутся для того, чтобы обеспечить синхронизацию данных DataSet с базой данных; находится ли эта база данных на устройстве или на сервере, известно лишь коду адаптера данных (data adapter).

Объекты DataAdapter могут существовать либо на стороне клиента, либо на стороне сервера. Если адаптер данных находится на сервере, то для предоставления ему данных объекта ADO.NET DataSet их копия должна быть передана с клиента на сервер. Обычно передача набора данных DataSet с клиента на сервер осуществляется путем сериализации объекта DataSet в XML, передачи его на сервер и последующей реконструкции DataSet из XML. Для всего этого в ADO.NET предусмотрена встроенная поддержка. Данная модель хорошо приспособлена для работы с Web-службами. Во многих случаях желательно избавить клиента от необходимости знать что-либо о конечных базах данных, к которым осуществляется доступ; это позволяет упростить архитектуру приложения за счет централизации доступа к базе данных на сервере. В подобных случаях данные объекта ADO.NET DataSet обычно передаются с клиентского устройства Web-службе, выполняющейся на сервере. Web-служба повторно загружает XML-данные в объект ADO.NET DataSet, а затем передает их в адаптер данных ADO NET, который и выполняет все необходимые обновления на сервере. Следует отметить, что объекты ADO.NET DataSet обладают такими встроенными механизмами, которые позволяют передавать на сервер лишь те данные DataSet, которые претерпели изменения (так называемые "диффграммы" ("diffgram"), или диаграммы отличий), это избавляет от необходимости перемещения полностью всех данных, содержащихся в DataSet, если изменились только несколько строк.

Две модели использования ADO.NET

ADO.NET предлагает многоуровневый подход для работы с данными, что дает возможность выбрать тот уровень программной абстракции, который в наилучшей степени соответствует потребностям вашего мобильного приложения и требованиям производительности.

Высокоуровневый подход, основанный на использовании объектов ADO.NET DataSet

На самом высоком уровне абстракции доступа к данным платформа .NET Compact Framework предлагает наряду с объектами ADO.NET DataSet также объекты DataTable и DataView. Схема различных логических связей для приложений такого рода представлены на рис. 14.2. Как обсуждалось выше, центральное место в этой модели занимают объекты ADO NET DataSet.

Рис. 14.2. Подход к организации работы с данными, основанный на использовании объектов ADO.NET DataSet

Низкоуровневый подход, основанный на использовании объектов подключения к данным ADO.NET

Хотя объекты ADO.NET DataSet и предлагают необычайно широкие возможности для работы с данными, создание дополнительных объектов для абстрагирования и управления данными приложения и отношениями между ними приводит к увеличению накладных расходов. Иногда эти накладные расходы оказываются недопустимо высокими или нежелательными; в подобных случаях следует подумать об использовании альтернативного низкоуровневого варианта.

Альтернативный подход, в котором используются низкоуровневые абстракции ADO.NET, проиллюстрирован на рис. 14.3. В основе этого подхода лежит создание пользовательской модели управления данными поверх объектов подключения к данным (data connection objects), предоставляемых поставщиками данных (data providers) ADO.NET. Так, для обеспечения доступа к собственной базе данных SQL Server предлагает класс System.Data.SqlClient.SqlConnection, тогда как SQL СЕ для тех же целей предоставляет класс System.Data.SqlServerCe.SqlCeConnection. Обычно эти классы используются совместно с классами DataAdapter для обмена данными с объектами DataSet, но могут использоваться и сами по себе для получения и передачи данных с использованием ваших собственных форматов данных. Эта модель может обеспечить значительную экономию памяти, если мобильное приложение не нуждается в тех широких возможностях в отношении доступа к данным, которые предлагает универсальная модель на основе объектов ADO.NET DataSet. Схема различных взаимосвязей, соответствующая данному случаю, представлена на рис. 14.3.

В случае выбора низкоуровневого подхода ваше приложение берет на себя непосредственную ответственность за управление данными, загружаемыми в память, отслеживание любых изменений, вносимых в данные, и передачу этих изменений обратно в долговременное хранилище в соответствии с необходимостью. Снижение накладных расходов при работе на более низком уровне абстракции достигается за счет повышения ответственности разработчика за проектирование и поддержание эффективной модели данных.

Рис. 14.3. Альтернатива использованию объектов ADO.NET DataSet

Модель программирования, основанная на использовании объектов ADO.NET DataSet, предоставляет замечательные возможности для работы с реляционными данными, однако ее применение уместно не в любом контексте. Важно понимать, когда следует использовать ADO.NET для удовлетворения потребностей приложения в доступе к данным, а когда — не следует.

В каких случаях следует использовать объекты ADO.NET DataSet

Объекты ADO.NET DataSet следует использовать в тех случаях, когда приложению требуются широкие возможности манипулирования данными в памяти или когда возникает необходимость в использовании сложного реляционного способа прослеживания данных. Поскольку, по существу, ADO.NET поддерживает для вас в памяти небольшую реляционную базу данных, которая отслеживает вносимые изменения, то использование этого протокола предоставляет широкие возможности для автоматического управления набором в высшей степени динамичных данных, а также навигации по связям между отдельными порциями данных. Объекты ADO.NET DataSet оказываются удобными в тех случаях, когда 1) объем данных, с которыми вы должны работать, не слишком велик по сравнению с емкостью памяти мобильного устройства, и 2) данные имеют динамическую природу, что диктует необходимость отслеживания и распространения изменений.

Объекты ADO.NET DataSet обеспечивают обмен данными с долговременным хранилищем. Такой обмен осуществляется одним из трех способов: 1) использование классов DataAdapter, осуществляющих соединение с базами данных посредством объектов подключения к данным, 2) сериализация объектов DataSet в файлы и потоки XML и наоборот, и 3) сериализация посредством пользовательского кода, который считывает данные из объектов DataSet или помещает данные в указанные объекты. Краткие описания каждого из упомянутых способов передачи данных приводятся ниже.

Использование классов DataAdapter для организации взаимодействия с базами данных

Тип ADO.NET System.Data.Common.DataAdapter — это абстрактный класс, то есть он предоставляет шаблон для порождения других классов DataAdapter, специфических по отношению к базе данных, которые, собственно говоря, и используются. Вместе с .NET Compact Framework поставляются два адаптера данных:

1. SqlDataAdapter. Класс System.Data.SqlClient.SqlDataAdapter используется при работе с базами данных SQL Server, выполняющимися на серверах.

2. SqlCeDataAdapter. Класс System.Data.SqlServerCe.SqlCeDataAdapter используется при работе с базами данных SQL СЕ, выполняющимися на мобильных устройствах.

Для подключения к другим источникам данных могут использоваться адаптеры данных, предлагаемые сторонними производителями. Кроме того, вы можете написать собственный класс DataAdapter, если имеется пользовательский источник данных, к которому вы хотите подключиться.

Независимо от выбранного вами типа адаптера данных объекты DataAdapter работают посредством присоединенных к ним объектов Command. В отличие от класса DataAdapter у класса Command нет корневого класса, от которого могли бы быть произведены другие классы Command, специфические по отношению к базам данных; понятие класса Command существует лишь как понятие, которое используется при работе с различными адаптерами данных. Для объектов SqlDataAdapter существуют связанные с ними объекты SqlCommand, для объектов SQL СЕ SqlCeDataAdapter — объекты SqlCeCommand, и так далее. В свою очередь, с объектами Command связываются объекты Connection, которые отображают команды (commands) на конкретный экземпляр той или иной базы данных; например, для выполнения команд при работе через конкретное соединение с базой данных SQL Server объект SqlCommand будет использовать объект SqlConnection. Указанные объекты Command исполняют запросы и другие команды баз данных, которые должны выполняться для извлечения данных из баз данных или помещения их в базы данных, используемые вашим приложением. Объектам Command известно, как осуществлять те или иные действия при работе с той или иной базой данных, когда они выполняют SQL-команды для выборки, обновления, вставки или удаления данных. Так, для выполнения этих команд у класса SQLDataAdapter имеются следующие четыре свойства: SelectCommand, UpdateCommand, InsertCommand и DeleteCommand. Каждое из этих свойств имеет тип SqlCommand. Аналогичным образом, у объекта SqlCeDataAdapter также имеются четыре свойства с теми же именами, но типом этих свойств является SQLCeCommand.

Краткое подведение итогов. Адаптеры данных играют роль посредников при осуществлении связи между объектами ADO.NET DataSet и базами данных. Как правило, для выполнения этих функций адаптеры данных используют объекты Command. Объекты Command являются специфическими по отношению к каждому типу баз данных. В свою очередь, объекты Command обычно ассоциируются с объектами Connection, владеющими соединениями с конкретным сервером. В типичных случаях объект Command является владельцем таких SQL-операторов, как Select * from Customers, а объекты Connection — владельцами логического соединения с базой данных, через которое им передаются эти команды.

При создании .NET-приложений для настольных компьютеров и серверов Visual Studio .NET предлагает инструментальные средства времени проектирования, которые облегчают настройку конфигураций адаптеров данных и ассоциированных с ними классов Command; это значительно упрощает процесс доступа к базам данных. В отличие от этого, для создания и использования адаптера данных в .NET Compact Framework вы должны сами написать код, обеспечивающий конфигурирование объектов DataAdapter и Command для работы с используемыми вами источниками данных. Возможно, в будущем автоматизированные средства будут поддерживать также .NET Compact Framework и объекты DataAdapter и DataCommand для работы с популярными базами данных, но пока что вы можете полагаться только на самих себя. Поскольку предусмотренные для настольных компьютеров и серверов инструментальные средства для работы с базами данных автоматически генерируют исходный код для приложений, часто имеет смысл воспользоваться сгенерированным ими кодом и адаптировать его для выполнения на мобильных устройствах; хотя этот код и будет существенно отличаться от того, что вам нужно, он послужит вам неплохой отправной точкой.

Использование файлов и потоков XML для сохранения и передачи данных

Сохранение содержимого объектов ADO.NET DataSet в виде XML-файлов можно считать вариантом "базы данных для бедных". Данные приложения сохраняются в текстовом файле с использованием формата, который позволяет осуществить последующую повторную загрузку данных в память в виде объекта ADO.NET DataSet. Это аналогично получению объекта DataSet, возвращаемого через запрос Web-службы. В противоположность сохранению данных в базе данных использование текстового XML-файла для хранения данных лишает ваше приложение богатых возможностей транзакций и гарантий целостности данных, предлагаемых современными базами данных. Несмотря на ограниченность этой модели в отношении хранения больших объемов данных и возможности обновления данных посредством механизма транзакций, она может хорошо послужить при хранении данных небольшого объема (например, XML-файлы размером 20 Кбайт) или при перемещении данных на сервер посредством XML-потоков. Сохранение объектов DataSet в виде постоянно существующих XML-файлов можно рассматривать как простой способ упаковки небольших или средних объемов информации о состояния приложения для ее последующего повторного использования.

При записи содержимого объекта DataSet в файл или поток XML важно внимательно изучить опции, предлагаемые перечислением System.Data.XmlWriteMode. Исходя из соображений производительности, при сохранении объектов DataSet в виде постоянно существующих XML-файлов рекомендуется одновременно сохранять XML-схему (то есть использовать System.Data.XmlWriteMode.WriteSchema). Запись схемы данных вместе с самими данными обеспечивает существенное ускорение повторной загрузки XML-данных в объект DataSet; в противном случае схема должна будет динамически определяться во время повторной загрузки данных, а это потребует выполнения дополнительной работы. В листинге 14.2 представлен простой пример сохранения объекта DataSet в XML-файле. В этом примере предоставляется возможность задавать параметр WriteSchema.

Чтобы выполнить пример, дополните код, приведенный в листинге 14.1, кодом из листинга 14.2 и добавьте элемент управления Button, который вызывает функцию writeDataSetToFile.

Листинг 14.2. Использование параметра XMLWriteMode при сохранении объекта ADO.NET DataSet

//-----------------------------------------------------------------------

//Необходимость в этой функции возникает по той причине, что .NET Compact

//Framework не поддерживает перегрузку:

//

//"public void WriteXml(string, XmlWriteMode);"

//

//в качестве функции-члена "public" (только "private")

//-----------------------------------------------------------------------

void  writeDataSetToFile(System.Data.DataSet ds, string  filename, System.Data.XmlWriteMode xmlWriteMode) {

//Создать объект XmlWriter для записи наших XML-данных

System.Xml.XmlWriter xmlWriter;

xmlWriter = new System.Xml.XmlTextWriter(filename, System.Text.Encoding.Default);

//ПРИМЕЧАНИЕ: Эта перегруженная версия не является общедоступной (public)!

//ds.WriteXml(filename, xmlWriteMode);

//Вместо этого используем следующую функцию:

ds.WriteXml(xmlWriter, xmlWriteMode);

xmlWriter.Close(); //Важно закрыть файл!

}

Сериализация объектов ADO.NET DataSet с помощью пользовательского кода

Как ранее уже обсуждалось, объекты ADO.NET DataSet обладают встроенной поддержкой сохранения содержимого в виде XML-файлов. В то же время, этот XML-формат не является произвольным и должен соответствовать определенной схеме XML, предназначенной специально для использования с объектами ADO.NET DataSet. Если вашему приложению необходимо выполнять запись или считывание информации с использованием другой схемы XML или любого другого формата, то для этого вы должны сами написать код соответствующей пользовательской логики. Модель, основанная на использовании объектов DataSet, обладает достаточной гибкостью для того, чтобы обеспечить поддержку сохранения данных в любом желаемом виде. Поскольку объекты ADO.NET DataSet поддерживают в памяти простую базу данных, не зависящую от формата хранения, вы можете сохранить этот объект в любом формате (например, в пользовательском формате XML, двоичном, простом текстовом), который отвечает вашим потребностям. Следует лишь отметить, что прежде чем взваливать на себя дополнительную работу по проектированию, необходимо убедиться в том, что для этого имеются серьезные основания.

Если вы пишете пользовательский код десериализации для заполнения данными объекта DataSet, то код вашего приложения должен программным путем построить таблицы, столбцы и определения отношений, а затем заполнить таблицы импортируемыми данными. Аналогичным образом, при пользовательском сохранении объекта DataSet логика вашего приложения должна обеспечить итерирование по всем таблицам и сохранение данных с использованием любого желаемого механизма. Для чтения и записи данных с использованием нескольких различных источников можно привлечь гибридную модель; например, объект DataSet может автоматически заполняться данными при помощи объекта SQLDataAdapter, подключенного к базе данных SQL, а впоследствии эти данные могут быть сериализованы с применением пользовательского формата, локального для устройства. Объектам ADO.NET DataSet безразлично, каким именно образом данные были в них помещены и откуда они поступили.

Работа с нетипизированными объектами DataSet

В .NET Framework для настольных компьютеров и серверов предлагается концепция "типизированных объектов DataSet". Типизированный объект DataSet — это строго типизированный набор интерфейсных классов, реализованных посредством механизма наследования поверх объектов DataSet, DataTable и других объектов данных ADO.NET. Такие унаследованные классы обеспечивают доступ к базовым таблицам и строкам объектов DataSet с использованием строго типизированных членов класса, имена которых совпадают с именами обрабатываемых таблиц и столбцов. Например, вместо того чтобы осуществлять поиск столбцов по именам в соответствии с поздним связыванием (например, myDataRow["CustomerFirstName"]) или требовать использования индексов столбцов (myDataRow[2]), разработчик может использовать раннее связывание свойства (myDataRow.CustomerFirstName). Именно такое связывание на стадии проектирования и есть то, что делает объект DataSet "типизированным". Исходный код для типизированных классов DataSet автоматически генерируется средой времени проектирования Visual Studio .NET.

НА ЗАМЕТКУ

Важно отметить, что строго типизированные объекты DataSet ничуть не эффективнее нетипизированных объектов DataSet. Часто ошибочно полагают иное, поскольку раннее связывание интуитивно представляется более эффективным. Однако раннее связывание типизированных объектов DataSet просто перекладывается на основные нетипизированные объекты DataSet. Типизированные классы DataSet не работают быстрее, их просто легче использовать. Строго типизированные интерфейсные классы позволяют использовать во время проектирования такие возможности, как автоматическое завершение ввода операторов, что облегчает разработку программных кодов на основе объектов DataSet. Они также обеспечивают возможность выявления некоторых видов синтаксических ошибок на стадии проектирования, а не на стадии выполнения. Ничего сверх этого в плане производительности они не дают.

.NET Compact Framework не поддерживает компиляцию кода типизированных объектов DataSet, автоматически сгенерированного для настольных компьютеров, Это означает, что наиболее распространенным методом работы с объектами ADO.NET DataSet с использованием .NET Compact Framework является работа непосредственно с нетипизированным классом DataSet и подчиненными ему классами DataTable, DataColumn и DataRow. Кроме некоторого усложнения вашего кода и необходимости внимательно следить за тем, чтобы не допустить опечаток в именах столбцов и полей (распространенная ошибка), использование нетипизированных объектов DataSets не обладает никакими другими недостатками. Наиболее высокая производительность достигается тогда, когда вы работаете с нетипизированными классами непосредственно, а не через какие-либо интерфейсные уровни.

Перенос типизированных объектов ADO.NET DataSet на мобильные устройства

В Visual Studio .NET предусмотрена поддержка преобразования описаний схемы данных в исходный код типизированных объектов DataSet на стадии проектирования. К сожалению, не все из присутствующих в этом исходном коде типов, свойств и методов поддерживаются в .NET Compact Framework.

Если вы возьмете исходный код типизированного объекта DataSet, сгенерированный для настольного компьютера, и перенесете его путем копирования в проект .NET Compact Framework, то при компиляции этого проекта получите несколько сообщений об ошибках. Эти ошибки компиляции можно разбить на три категории:

1. Некоторые ошибки этого типа обусловлены наличием содержащих метаданные атрибутов классов и функций, которые не поддерживаются в .NET Compact Framework; эти метаданные можно эффективно исключить из кода, поставив перед ними символы комментария.

Например, атрибут [System.ComponentModel.ToolboxItem(true)] не поддерживается, и его можно поместить в комментарий.

2. Некоторые ошибки этого типа обусловлены отсутствием типов исключений; вместо таких исключений можно генерировать более общие исключения.

Например, поскольку в .NET Compact Framework не определено исключение new StrongTypingException(), то вместо него можно использовать исключение new Exception().

3. Некоторые ошибки этого типа обусловлены автоматически сгенерированным кодом, в котором используется функциональность, не поддерживаемая в .NET Compact Framework; функции, использующие эту функциональность, можно исключить с помощью символов комментария.

Скомпилировать в .NET Compact Framework код типизированных объектов DataSet, предназначенный для настольных компьютеров, не составляет особого труда; это даст вам великолепную возможность позаимствовать некоторые полезные концепции типизированных объектов DataSet и использовать их в своем мобильном приложении.

Вместо того чтобы отталкиваться от кода для настольного компьютера и отбрасывать ненужные части, гораздо надежнее справиться с задачей поддержки доступа к типизированным объектам DataSet, создавая собственные типизированные классы DataSet, DataTable и DataRow с нуля путем порождения строго типизированных классов из этих основных типов ADO.NET и импортирования лишь отдельных частей кода, автоматически сгенерированного для настольного проекта, в соответствии с необходимостью. Гораздо надежнее самостоятельно создать указанную поддержку с нуля и добавить лишь тот код, в котором есть необходимость, чем исходить из кода для настольных компьютеров и пытаться исключать из него отдельные фрагменты до тех пор, пока он не заработает. Вы получите более понятный, лучше разработанный и более легкий в сопровождении код, если создадите его с самого начала. Код для настольных компьютеров следует рассматривать лишь как полезное учебное пособие и не копировать его фрагменты непосредственно в код мобильного приложения.

Меры по обеспечению максимальной производительности при работе с объектами ADO.NET DataSet

При работе с объектами DataSet очень важно не забывать об эффективности кода. Почти с одинаковой легкостью можно написать как эффективный код, так и код, производительность которого будет крайне низка. Распространенной ошибкой разработчиков, приводящей к низкой производительности кода, является поиск таблиц и столбцов по их строковым именам, а не при помощи более эффективных механизмов индексирования. Этот момент приобретает еще большее значение при доступе к полям строк данных, поскольку эта операция часто выполняется в итерационных циклах, включающих значительное количество строк. Обращение к отдельным элементам при осуществлении такого доступа может осуществляться тремя способами, перечисленными ниже в порядке, соответствующем увеличению производительности:

1. Поиск полей с использованием строковых имен. Например: myRow["myColumnName"]; этот способ является самым медленным, поскольку для нахождения нужного поля строка имени искомого столбца должна сравниваться со всеми имеющимися именами столбцов.

2. Поиск полей с использованием целочисленных индексов. Например: myRow[2]; Ввиду использования целых чисел этот способ представляет собой определенное улучшение по сравнению с поиском по строковым именам. Чтобы использовать этот механизм, ваш код должен организовать предварительный просмотр и кэширование целочисленных индексов столбцов

3. Поиск полей, с использованием объектов столбцов. Например: myRow[myColumnObject], где myColumnObject представляет объект типа System.Data.DataColumn. Этот способ обеспечивает значительное улучшение производительности по сравнению с обоими предыдущими механизмами. Чтобы использовать этот механизм, ваш код должен кэшировать объект столбца (column object), который представляет интересующее вас поле.

В листинге 14.3 приведен код, который позволяет тестировать производительность трех различных подходов, описанных выше. Этот код имитирует типичную задачу обработки данных, включающую поиск и изменение записей.

Вычисления соответствуют описанному ниже сценарию.

Агенты транспортной компании, работающие на выезде, используют мобильные устройства для внесения изменений в информацию о маршруте следования клиентов. В силу внезапного изменения погодных условий, например из-за снегопада, возникает необходимость во внесении изменений в маршрут следования группы пассажиров, дожидающихся отправки на вокзале или в аэропорте или находящихся в данный момент в движущемся поезде или на борту самолета. Требуется обновить информацию о пунктах пересадки пассажиров и пересмотреть маршруты следования. Простейший способ решения этой задачи состоит в том, чтобы вооружить сотрудников транспортной компании мобильными устройствами, в которых содержится информация о маршрутах движения транспортных средств. При наличии соответствующего мобильного приложения несколько агентов могут выйти к клиентам и решить их проблемы, избавляя их от необходимости стоять в очереди, причем во многих случаях можно успеть полностью оформить все необходимые проездные документы еще до окончания текущего рейса поезда или самолета. В мобильных устройствах содержится загруженный список клиентов и подробная информация о маршрутах их следования. Чтобы ускорить процесс поиска соответствующих записей и уменьшить вероятность ошибок, мобильные устройства оборудованы устройствами для считывания номера кредитной карточки пассажира, который используется в качестве ключа для проведения соответствующего поиска. После того как запись о клиенте будет найдена, сведения о его маршруте могут быть обновлены с учетом новой информации.

В нашем тестовом коде применяется упрощенная версия этого сценария, и в таблице данных будут содержаться только имя клиента, дата рейса и номер кредитной карточки. Разумеется, в действительности приходится осуществлять доступ к гораздо более многочисленным данным, но в нашем упрощенном варианте все основные составляющие задачи учтены, есть данные, хранящиеся на устройстве, и мы должны иметь возможность производить среди них поиск и вносить изменения. Поскольку для реальных сценариев характерно выполнение значительно большего числа операций поиска, их производительность может быть оценена путем экстраполяции результатов выполнения нашего тестового приложения.

В табл. 14 1 представлены результаты выполнения теста на физическом устройстве Pocket PC. Как и следовало ожидать, поиск по текстовому содержимому (столбец А) оказался самым медленным и потребовал 32,82 секунды. Поиск с использованием целочисленного индекса (столбец Б) привел к вполне ощутимому улучшению результатов на 8% и потребовал 30,28 секунд. Поиск с использованием объектов DataColumn (столбец В) принес 28%-ное улучшение по сравнению с текстовым поиском. Выигрыш довольно значительный и явно свидетельствует в пользу кэширования объектов DataColumn при выполнении циклических операций поиска данных в таблицах данных.

Таблица 14.1 Производительность тестового приложения при выполнении 500 итераций с использованием 201 строки данных на физическом устройстве Pocket PC

Номер теста

(А) Текстовый индекс, с

(Б) Целочисленный индекс, с

(В) Индексирование по объектам DataColumn, с

1

32,538

30,09

23,554

2

33,063

30,387

23,491

3

32,87

30,372

23,582

Среднее

32,82

30,28

23,54

Относительная производительность

100%

92%

72%

Приведенный в листинге 14.3 код необходимо включить в форму в проекте Pocket PC. Для создания и выполнения приложения потребуется выполнить следующие действия.

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму элемент управления Button. Присвойте ему имя buttonRunTest.

4. Дважды щелкните на элементе управления Button в окне конструктора форм. В автоматически сгенерированной и подключенной функции обработчика событий введите код функции buttonRunTest_Click() из листинга 14.3.

5. Введите весь оставшийся код в тот же класс.

6. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

7. Запустите приложение, нажав клавишу <F5>. Для запуска всех трех вариантов тестирования на выполнение следует щелкать на кнопке. После каждого прогона приложения должно появляться окно сообщений, содержащее результаты тестирования.

Листинг 14.3. Сравнение производительности различных вариантов доступа к данным с использованием объектов DataSet

System.Data.DataSet m_myDataSet; //Объект Dataset для теста

//Индексы столбцов и таблицы, подлежащие кэшированию

private bool m_indexesLookedUp = false;

private const int INVALID_INDEX = -1;

private int m_IndexOfTestColumn_CreditCard = INVALID_INDEX;

private int m_IndexOfTestColumn_TravelDate = INVALID_INDEX;

private int m_IndexOfTestTable = INVALID_INDEX;

//Столбцы данных и таблица, подлежащие кэшированию

System.Data.DataColumn m_TestColumn_CreditCard;

System.Data.DataColumn m_TestColumn_TravelDate;

private System.Data.DataTable m_TableCustomerInfo;

//3 вида тестов, которые мы можем выполнять

public enum testType {

textColumnLookup, cachedIndexLookup, cachedColumnObject

}

//Эти константы определяют размерные характеристики тестов

const int DUMMY_ROWS_OF_DATA = 100;

const int NUMBER_TEST_ITERATIONS = 500;

//Табличная информация

const string TABLE_NAME_PASSENGERINFO = "CustomerTravelInfo";

const string COLUMN_NAME_DATE_OF_TRAVEL = "DateOfTravel";

const string COLUMN_NAME_PASSENGER_NAME = "PassengerName";

const string COLUMN_NAME_PASSENGER_CREDIT_CARD = "PassengerCreditCard";

const string TEST_CREDIT_CARD = "IvoCard-987-654-321-000";

//--------------------

//Создает набор данных

//--------------------

private void createDataSet() {

//1. Создать новый объект DataSet

m_myDataSet = new System.Data.DataSet("TravelService Dataset");

//2. Добавить объект DataTable в объект ADO.NET DataSet

System.Data.DataTable myTestTable;

myTestTable = m_myDataSet.Tables.Add(TABLE_NAME _PASSENGERINFO);

//Добавить 2 столбца в таблицу

//Добавить столбец данных в таблицу DataTable набора данных DataSet

myTestTable.Columns.Add(COLUMN_NAME_DATE_OF_TRAVEL,typeof(System.DateTime));

//Добавить столбец строк в таблицу DataTable набора данных

DataSet myTestTable.Columns.Add(COLUMN_NAME_PASSENGER NAME,typeof(string));

//Добавить столбец строк в таблицу DataTable набора данных DataSet

myTestTable.Columns.Add(COLUMN_NAME_PASSENGER_CREDIT_CARD,typeof(string));

//Данные для размещения в строках данных

object[] objArray;

objArray = new object[3];

//--------------------------------

//Добавить строки данных в таблицу

//--------------------------------

System.Text.StringBuilder buildTestString;

buildTestString = new System.Text.StringBuilder();

for (int addItemsCount = 0; addItemsCount < DUMMY_ROWS_OF_DATA; addItemsCount++) {

//Выбрать день отъезда пассажира

objArray[0] = System.DateTime.Today.AddDays(addItemsCount);

//Выбрать имя пассажира

buildTestString.Length = 0;

buildTestString.Append("TestPersonName");

buildTestString.Append(addItemsCount);

objArray[1] = buildTestString.ToString();

//Связать с пассажиром текстовый номер кредитной карточки

buildTestString.Length = 0;

buildTestString.Append("IvoCard-000-000-0000-");

buildTestString.Append(addItemsCount);

objArray[2] = buildTestString.ToString();

//Добавить элементы массива в строку набора данных

myTestTable.Rows.Add(objArray);

}

//Добавить элемент, поиск которого мы хотим проводить при выполнении теста

objArray[0] = System.DateTime.Today;

objArray[1] = "Ms. TestPerson";

objArray[2] = TEST_CREDIT_CARD;

//Добавить элементы массива в строку набора данных

myTestTable.Rows.Add(objArray);

} //Конец функции

//---------------------------------------------------------------

//Найти и кэшировать все индексы набора данных, которые нам нужны

//---------------------------------------------------------------

private void cacheDataSetInfo() {

//Выйти из функции, если индексы уже загружены

if (m_indexesLookedUp == true) {

return;

}

//Кэшировать индекс таблицы

m_IndexOfTestTable = m_myDataSet.Tables.IndexOf(TABLE_NAME_PASSENGERINFO);

//------------------------------------------

//Итерировать по всем столбцам нашей таблицы

//и кэшировать индексы нужных столбцов

//------------------------------------------

m_TableCustomerInfo = m_myDataSet.Tables[m_IndexOfTestTable];

int dataColumnCount = m_TableCustomerInfo.Columns.Count;

System.Data.DataColumn myColumn;

for (int colIdx = 0; colIdx < dataColumnCount;) {

myColumn = m_TableCustomerInfo.Columns[colIdx];

//Предпринимать поиск, только если это еще не сделано

if (m_IndexOfTestColumn_CreditCard == INVALID_INDEX) {

//Проверить, совпадает ли имя

if (myColumn.ColumnName == COLUMN_NAME_PASSENGER_CREDIT_CARD) {

//Кэшировать индекс

m_IndexOfTestColumn_CreditCard = colIdx;

//Кэшировать столбец

m_TestColumn_CreditCard = myColumn;

goto next_loop_iteration; //Опустить другие операции сравнения...

} //Endif: сравнение строк

} //Endif

if (m_IndexOfTestColumn_TravelDate == INVALID_INDEX) {

//Проверить, совпадает ли имя

if (myColumn.ColumnName == COLUMN_NAME_DATE_OF_TRAVEL) {

//Кэшировать индекс

m_IndexOfTestColumn_TravelDate = colIdx;

//Кэшировать столбец

m_TestColumn_TravelDate = myColumn;

goto next_loop_iteration; //Опустить другие операции сравнения.

} //Endif: сравнение строк

} //Endif

next_loop_iteration:

colIdx++;

}

m_indexesLookedUp =true;

}

//--------------

//Выполнить тест

//--------------

void changeDayOfTravel_test(testType kindOfTest) {

//Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.WaitCursor;

//Начать с известной даты...

System.DateTime newDate;

newDate = System.DateTime.Today;

changeDayOfTravel_textColumnLookup(ТЕST_CREDIT_CARD, newDate);

//ДОПУСТИМО ТОЛЬКО ДЛЯ ТЕСТОВОГО КОДА!!!

//Вызов сборщика мусора в коде ЗАМЕДЛИТ работу вашего приложения!

System.GC.Collect();

const int testNumber = 0;

//Настроить соответствующим образом в зависимости от вида выполняемого теста

switch (kindOfTest) {

case testType.textColumnLookup:

PerformanceSampling.StartSample(testNumber, "Text based Column lookup.");

break;

case testType.cachedIndexLookup:

PerformanceSampling.StartSample(testNumber, "Cached Column Index lookup.");

break;

case testType.cachedColumnObject:

PerformanceSampling.StartSample(testNumber, "Cached Column objects");

break;

default:

throw new Exception("Unknown state!");

}

//Выполнить тест!

for (int testCount = 0; testCount < NUMBER_TEST_ITERATIONS; testCount++) {

//Передвинуть дату вперед на один день

newDate = newDate.AddDays(1);

int numberRecordsChanged = 0;

//Какой вид теста мы выполняем?

switch (kindOfTest) {

case testType.textColumnLookup:

//НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Просмотреть все имена, используя СТРОКИ

numberRecordsChanged =

changeDayOfTravel_textColumnLookup(ТЕST_CREDIT_CARD, newDate);

break;

case testType.cachedIndexLookup:

//ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированные индексы

numberRecordsChanged =

changeDayOfTravel_cachedColumnIndex(ТЕST_CREDIT_CARD, newDate);

break;

case testType.cachedColumnObject:

//НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированные объекты

//столбцов

numberRecordsChanged =

changeDayOfTravel_CachedColumns(TEST_CREDIT_CARD, newDate);

break;

}

//Убедиться в том, что тест выполняется, как и ожидалось...

if (numberRecordsChanged != 1) {

System.Windows.Forms.MessageBox.Show("No matching records found. Test aborted!");

return;

}

}

//Получить время, которое потребовалось для выполнения теста

PerformanceSampling.StopSample(testNumber);

//Обычный курсор

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default;

//Отобразить результаты выполнения теста

string runInfo = NUMBER_TEST_ITERATIONS.ToString() + "x" +

DUMMY_ROWS_OF_DATA.ToString() + ": ";

System.Windows.Forms.MessageBox.Show(runInfo +

PerformanceSampling.GetSampleDurationText(testNumber));

}

//ФУНКЦИЯ ПОИСКА, ОБЛАДАЮЩАЯ НИЗКОЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

private int changeDayOfTravel_ textColumnLookup(string creditCardNumber, System.DateTime newTravelDate) {

int numberRecordsChanged = 0;

//Найти имя таблицы

System.Data.DataTable dataTable_Customers;

//НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск в таблице, используя

//сравнение строк!

dataTable_Customers = m_myDataSet.Tables[TABLE_NAME_PASSENGERINFO];

foreach (System.Data.DataRow currentCustomerRow in dataTable_Customers.Rows) {

string currentCreditCard;

//НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск в таблице, используя

//сравнение строк!

currentCreditCard = (string)currentCustomerRow[COLUMN_NAME_PASSENGER_CREDIT_CARD];

//Проверить, является ли данная кредитная карточка искомой

if (creditCardNumber == currentCreditCard) {

//Изменить дату отъезда

//НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск столбца, используя

//сравнение строк!

System.DateTime currentTravelDate =

(System.DateTime)currentCustomerRow[COLUMN_NAME_DATE_OF_TRAVEL];

if (currentTravelDate != newTravelDate) {

//НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск столбца, используя

//сравнение строк!

currentCustomerRow[COLUMN_NAME_DATE_OF_TRAVEL] = newTravelDate;

numberRecordsChanged++;

}

} //endif: сравнение строк

} //end foreach

return numberRecordsChanged; //Количество обновленных записей

}

//ФУНКЦИЯ, ХАРАКТЕРИЗУЮЩАЯСЯ НЕСКОЛЬКО ЛУЧШЕЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

private int changeDayOfTravel_cachedColumnIndex(string creditCardNumber, System.DateTime newTravelDate) {

int numberRecordsChanged = 0;

//Поиск имени таблицы

System.Data.DataTable dataTable_Customers;

//ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: использовать кэшированный индекс

dataTable_Customers = m_myDataSet.Tables[m_IndexOfTestTable];

foreach (System.Data.DataRow currentCustomerRow in dataTable_Customers.Rows) {

string currentCreditCard;

//ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: использовать кэшированный индекс столбца!

currentCreditCard =

(string)currentCustomerRow[m_IndexOfTestColumn_CreditCard];

//Проверить, совпадает ли номер кредитной карточки...

if (creditCardNumber == currentCreditCard) {

//Изменить дату отъезда

//ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

System.DateTime currentTravelDate =

(System.DateTime)currentCustomerRow[m_IndexOfTestColumn_TravelDate];

if (currentTravelDate != newTravelDate) {

//ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс

//столбца!

currentCustomerRow[m_IndexOfTestColumn_TravelDate] = newTravelDate;

numberRecordsChanged++;

}

}

}

return numberRecordsChanged; //Количество обновленных записей

}

//ФУНКЦИЯ, ОБЛАДАЮЩАЯ НАИЛУЧШЕЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

private int changeDayOfTravel_CachedColumns(string creditCardNumber, System.DateTime newTravelDate) {

int numberRecordsChanged = 0;

//Найти имя таблицы

System.Data.DataTable dataTable_Customers = m_TableCustomerInfo;

foreach (System.Data.DataRow currentCustomerRow in dataTable_Customers.Rows) {

string currentCreditCard;

//НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

currentCreditCard =

(string)currentCustomerRow[m_TestColumn CreditCard];

//Проверить, совпадает ли номер кредитной карточки...

if (creditCardNumber == currentCreditCard) {

//Изменить дату отъезда

//НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

System.DateTime currentTravelDate =

(System.DateTime)currentCustomerRow[m_TestColumn_TravelDate];

if (currentTravelDate != newTravelDate) {

//НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс

//столбца!

currentCustomerRow[m_TestColumn TravelDate] = newTravelDate;

numberRecordsChanged++;

}

}

}

return numberRecordsChanged; //Количество обновленных записей

}

//Событие щелчка на кнопке

private void buttonRunTest_Click(object sender, System.EventArgs e) {

createDataSet();

cacheDataSetInfo();

//НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать поиск по строкам

changeDayOfTravel_test(testType.textColumnLookup);

//ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать поиск по целочисленным индексам

changeDayOfTravel_test(testType.cachedIndexLookup);

//НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать поиск по объектам столбцов

changeDayOfTravel_test(testType.cachedColumnObject);

}

В каких случаях не следует использовать объекты ADO.NET DataSet

Если данные мобильного приложения большей частью применяются только для чтения, если приходится хранить большие объемы данных в памяти или если между данными существуют сравнительно простые отношения, то стоит подумать о привлечении пользовательской модели управления данными. Объекты ADO.NET DataSet можно эффективно реализовать, но предлагаемая ими модель управления данными является универсальной. Можно добиться существенного выигрыша в объеме занимаемой памяти и производительности, создав специализированную модель данных, которая наилучшим образом соответствует вашим потребностям. Ключевым фактором эффективного использования памяти является уменьшение количества объектов, которые должны размещаться для хранения ваших данных; как правило, чем меньше объектов, тем меньше нагрузка на память и тем выше производительность.

В табл. 14.2 и листинге 14.4 представлены результаты использования оптимизированного пользовательского формата для хранения строк данных. Тестовый код, приведенный в листинге 14.4, выполняет ту же задачу, что и код из листинга 14.3, но вместо объектов ADO.NET DataSet в нем используется простой типизированный массив данных. От такой замены производительность приложения выигрывает в двух отношениях:

1. Быстродействие. Как видно из табл. 14.2, применение пользовательского формата данных позволило уменьшить время выполнения приложения до 38% того времени, которое было зафиксировано для решения, базирующегося на ADO.NET с использованием текстового индекса. Сравнение с результатом, достигнутым в оптимизированном варианте поиска, в котором использовался объект DataColumn, свидетельствует о сокращении времени выполнения почти в два раза (12,32/23,54=52,3%).

2. Снижение нагрузки на память. Поскольку в решении, основанном на пользовательском формате данных, для хранения данных требуется лишь минимальное количество объектов, а накладные расходы, связанные с объектами ADO.NET DataSet, отсутствуют, наше приложение предъявляет к памяти менее жесткие требования. Это означает, что при прочих равных условиях объем работы по сборке мусора уменьшается, а рабочее пространство для кода приложения увеличивается. Хотя этот результат и не отражен в таблице, он положительно влияет на общую производительность приложения.

Разумеется, у решения, основанного на пользовательском формате данных, имеются и недостатки по сравнению с вариантами решений, в которых используются объекты ADO.NET DataSet. Самое главное — это то, что при необходимости обновления данных на сервере в нашем коде требуется организовать учет всех изменений данных. Это означает, что мы должны ввести, по крайней мере, один дополнительный столбец булевских значений, указывающих на то, в каких строках были сделаны изменения. Это не составляет особого труда в случае простых табличных данных, но значительно усложняется, если данные разбросаны по нескольким таблицам и связаны между собой целой системой различных отношений. Кроме того, ADO.NET предлагает объекты DataView, обеспечивающие сортировку и фильтрацию данных, чего мы лишены, если останавливаемся на варианте пользовательской реализации модели данных. Расширение возможностей связано с дополнительными накладными расходами, и поэтому вы должны тщательно взвешивать все за и против, выбирая между функциональностью Al)O.NET и потенциально более высокой эффективностью пользовательской реализации. В случае приложений для устройств повышение эффективности часто окупает дополнительные затраты труда на разработку пользовательской модели данных на стадии проектирования.

Таблица 14.2. Сравнение производительности варианта приложения с пользовательским форматом данных, выполняющегося на физическом устройстве Pocket PC, с предыдущими результатами

Номер теста

(А) Текстовый индекс, с

(Б) Целочисленный индекс, с

(В) Индексирование по объектам DataColumn, с

(Г) Пользовательский формат данных, с

(ADO.NET)

(ADO.NET)

(ADO.NET)

(Пользовательский)

1

32,538

30,09

23,554

12,268

2

33,063

30,387

23,491

12,335

3

32,87

30,372

23,582

12,358

Среднее

32,82

30,28

23,54

12,32

Относительная производительность

100%

92%

72%

38%

Приведенный в листинге 14.4 код необходимо включить в форму в проекте Pocket PC. Для создания и выполнения приложения потребуется выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в форму элемент управления Button. Присвойте ему имя buttonRunTest.

4. Дважды щелкните на элементе управления Button в окне конструктора форм. В автоматически сгенерированной и подключенной функции обработчика событий введите код функции buttonRunTest_Click() из листинга 14.4.

5. Введите весь оставшийся код в тот же класс.

6. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

7. Запустите приложение, нажав клавишу <F5>. Щелкните на кнопке для запуска теста. Результаты тестирования должны отобразиться в окне сообщений.

Листинг 14.4. Результаты тестирования производительности при использовании пользовательского формата данных вместо объектов DataSet

//Определение размерных характеристик теста

const int DUMMY_ROWS_OF_DATA = 100;

const int NUMBER_TEST_ITERATIONS = 500;

const string TABLE_NAME_PASSENGERINFO = "CustomerTravelInfo";

const string TEST_CREDIT_CARD = "IvoCard-987-654-321-000";

string [] m_data_creditCards;

string [] m_data_names;

System.DateTime [] m_data_travelDates;

//-------------------------------------------------------------

//Создает массив данных (вместо использования объектов DataSet)

//-------------------------------------------------------------

private void createDataSet() {

//=============================================

//1. Создать пространство для размещения данных

//=============================================

m_data_creditCards = new string[DUMMY_ROWS_OF_DATA + 1];

m_data_names = new string[DUMMY_ROWS_OF_DATA + 1];

m_data_travelDates = new System.DateTime[DUMMY_ROWS_OF_DATA + 1];

//----------------------

//Добавить строки данных

//----------------------

System.Text.StringBuilder buildTestString;

buildTestString = new System.Text.StringBuilder();

for (int addItemsCount = 0; addItemsCount < DUMMY_ROWS_OF_DATA; addItemsCount++) {

//Выбрать день отъезда пассажира

m_data_travelDates[addItemsCount] = System.DateTime.Today.AddDays(addItemsCount);

//---------------------

//Выбрать имя пассажира

//---------------------

//Очистить строку

buildTestString.Length = 0;

buildTestString.Append("TestPersonName");

buildTestString.Append(addItemsCount);

m_data_names[addItemsCount] = buildTestString.ToString();

//-------------------------------------------------------

//Связать с пассажиром текстовый номер кредитной карточки

//-------------------------------------------------------

//Строка значения третьего столбца набора данных

buildTestString.Length = 0;

buildTestString.Append("IvoCard-000-000-0000-");

buildTestString.Append(addItemsCount);

m_data_creditCards[addItemsCount] = buildTestString.ToString();

}

//Добавить элемент, поиск которого мы хотим выполнить в нашем тесте...

//Выбрать день для значения в первом столбце данных

m_data_travelDates[DUMMY_ROWS_OF_DATA] = System.DateTime.Today;

//Строка для второго столбца данных

m_data_names[DUMMY_ROWS_OF_DATA] = "Ms. TestPerson";

//Строка с идентификатором кредитной карточки

m_data_creditCards[DUMMY_ROWS_OF_DATA] = ТЕST_CRE DIT_CARD;

} //Конец функции

//-----------------

//Выполнить тест...

//-----------------

void changeDayOfTravel_test() {

//Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.WaitCursor;

//Начать с известной даты...

System.DateTime newDate;

newDate = System.DateTime.Today;

changeDayOfTravel_CustomArrays(ТЕST_CREDIT_CARD, newDate);

//ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ!!!

//HE СЛЕДУЕТ использовать вызовы сборщика мусора в готовом программном

//коде. Это ЗАМЕДЛЯЕТ работу приложения.

System.GC.Collect();

const int testNumber = 0;

//Запустить таймер теста

PerformanceSampling.StartSample(testNumber, "Custom Array implementation");

//Запустить тест!

for(int testCount = 0; testCount < NUMBER_TEST_ITERATIONS; testCount++) {

//Передвинуть дату вперед на один день

newDate = newDate.AddDays(1);

int numberRecordsChanged = 0;

//Просмотреть все имена, используя СТРОКИ

numberRecordsChanged = changeDayOfTravel_CustomArrays(TEST_CREDIT_CARD, newDate);

//Убедиться в нормальном выполнении теста...

if (numberRecordsChanged != 1) {

System.Windows.Forms.MessageBox.Show("No matching records found. Test aborted!");

return;

}

}

//Получить время выполнения теста

PerformanceSampling.StopSample(testNumber);

//Обычный курсор

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default;

//Отобразить результаты теста

string runInfo = NUMBER_TEST_ITERATIONS.ToString() + "x" +

DUMMY_ROWS_OF_DATA.ToString() + ": ";

System.Windows.Forms.MessageBox.Show(runInfo +

PerformanceSampling.GetSampleDurationText(testNumber));

}

private int changeDayOfTravel_CustomArrays(string creditCardNumber, System.DateTime newTravelDate) {

int numberRecordsChanged = 0;

//Просмотреть каждый элемент массива

for (int index = 0; index <= DUMMY_ROWS_OF_DATA; index++) {

string currentCreditCard;

currentCreditCard = m_data_creditCards[index];

//Обновить запись при наличии совпадения

if (creditCardNumber == currentCreditCard) {

//Изменить дату поездки

System.DateTime currentTravelDate = m_data_travelDates[index];

//Увеличить значение счетчика обновлений только при несовпадении данных

if (currentTravelDate != newTravelDate) {

m_data_travelDates[index] = newTravelDate;

numberRecordsChanged++;

}

}

}

//Возвратить количество обновленных записей

return numberRecordsChanged;

}

private void buttonRunTest_Click(object sender, System.EventArgs e) {

createDataSet();

changeDayOfTravel_test();

}

Пример использования базы данных на устройстве и управления пользовательскими данными

Чтобы проиллюстрировать методы представления и управления пользовательскими данными, считанными из базы данных в память, полезно вернуться к примеру из предыдущей главы. В настоящем примере мы вновь рассмотрим словарную игру, для которой разрабатывали пользовательский интерфейс в главе 13.

Ранее нас интересовали вопросы проектирования пользовательского интерфейса для этого мобильного приложения, а теперь мы будем исследовать хранение и представление в памяти самих слов, образующих словарь. Поскольку словарь, который мы хотели бы использовать для данного мобильного приложения, может оказаться очень большим, то, исходя из соображений быстродействия, эффективности и гибкости приложения, для хранения данных желательно использовать базу данных. По своей природе наши данные предназначены в основном только для чтения; время от времени пользователь может добавлять в словарь новые слова, но динамическое обновление существующих данных не является главным требованием. Кроме того, данные имеют простую структуру и их легко можно представить в виде одной таблицы базы данных.

В силу всех вышеуказанных причин — потенциально большое количество записей, низкая частота обновления и простота структуры данных — возможности подхода, основанного на использовании объектов ADO.NET DataSet, намного превышают уровень наших потребностей.

Мы вполне можем обойтись оптимизированным решением, используя низкоуровневые возможности класса SQL СЕ DataReader (System.Data. SqlServerCe.SqlCeDataReader) для выполнения запросов к локальной базе данных SQL СЕ нашего устройства. В результате запросов наше приложение будет получать однонаправленный курсор, указывающий на данные, которые отвечают критерию запроса. Далее эти данные можно загрузить в память и сохранить в пользовательском формате, специально подобранном таким образом, чтобы обеспечить наиболее эффективную работу со словарем. В интересах простоты и быстродействия соответствующие объекты будут размещаться в массивах. Тем самым будет достигнута существенная экономия времени и памяти по сравнению с общим подходом, основанным на использовании объектов DataSet, поскольку мы размещаем в памяти лишь те объекты, которые действительно будут использоваться в нашем приложении.

Следует обратить ваше внимание на два момента, которые используются в нашем примере с целью его упрощения, но вряд ли встретятся вам в реальных приложениях для мобильных устройств:

1. Содержимое базы данных формируется тем же приложением, которое загружает данные из базы данных. Если бы во время проектирования нам были известны все данные, которые потребуются приложению во время выполнения, то и потребность во внешней базе данных была бы небольшой; приложению достаточно заполнить структуры данных в памяти непосредственно в коде и отказаться от накладных расходов, с которыми сопряжена поддержка любой базы данных. В реальной версии данного приложения мы создали бы и заполнили данными базу данных, используя один из трех механизмов: а) загрузка в устройство файла уже наполненной базы данных, которую мы предварительно создали; б) синхронизация базы данных SQL СЕ с серверным вариантом SQL-сервера; и в) выполнение и завершение единственного приложения без сохранения данных созданной и наполненной им базы данных.

2. В память загружаются сразу все данные. Как выше уже отмечалось, словарь для нашего приложения может иметь очень большие размеры. Если бы наша база включала 20000 слов, то, вероятно, мы не захотели бы считывать в память все эти слова одновременно. Пользователь от этого ничего не выигрывает, поскольку в любой момент времени он одновременно работает только с небольшим набором из нескольких слов. Мы бы просто выбрали какой-то разумный предел, ограничивающий количество слов, которое наше приложение загружает в каждый момент времени; далее приложение может периодически обновлять встроенный в память кэш новыми словами. Например, мы хотим удерживать в словаре, хранящемся в памяти, не более 500 слов из полной базы данных словаря, насчитывающей 20 000 слов, из которых в любой момент времени только от 1 до 40 слов должны быть загружены в память. Было бы легко обновить код, осуществляющий считывание слов таким образом, чтобы для каждого слова, которое встречалось, вероятность загрузки составляла 1/40. Возможны и другие стратегии минимизации количества слов, хранимых в памяти, такие как группирование слов в родственные наборы, загружаемые целиком (например, простые слова, слова повышенной трудности, особо трудные слова). В любом случае мы хотим, чтобы наше мобильное приложение располагало системой управления памятью, которая гарантировала бы, что в любой момент времени в память загружается лишь ограниченное количество слов, так что независимо от того, какой размер имеет база данных, приложение нормально функционирует вполне предсказуемым образом.

Приведенный в листинге 14.5 код должен быть включен в форму в проекте Pocket PC. Код в листингах 14.6, 14.7 и 14.8 представляет отдельные, полностью определенные классы. Для создания и выполнения приложения необходимо выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в проект ссылку на класс SqlServerCE. Это можно сделать, щелкнув правой кнопкой мыши на узле References в элементе управления TreeView в окне Solution Explorer, а затем выбрав элемент System.Data. SqlServerCe.

Эта ссылка позволяет нашему приложению использовать классы из сборки System.Data.SqlServerCe, что открывает нам доступ к программной модели SQLCE

4. Добавьте в форму следующие элементы управления:

а. Кнопку (Button), переименовав ее в buttonCreateDataBase.

б. Кнопку (Button), переименовав ее в buttonLoadGameData

в. Текстовое окно (TextBox), оставив автоматически присвоенное ему имя textBox1.

5. Установите для свойства MultiLine элемента управления TextBox значение true.

6. Установите для свойства ScrollBar элемента управления TextBox значение vertical.

7. Для каждой из вышеупомянутых кнопок выполните следующие действия. Дважды щелкните на кнопке в окне конструктора форм. В автоматически сгенерированной и подключенной функции обработчика событий введите код функции button<ИмяКнопки>_Click() из листинга 14.5.

8. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

9. Добавьте в проект класс DatabaseAccess, удалите из него весь добавленный по умолчанию код в окне редактора класса, и введите вместо него код из листинга 14.6.

10. Добавьте в проект класс GameData, удалите из него весь добавленный по умолчанию код в окне редактора класса, и введите вместо него код из листинга 14.7.

11. Добавьте в проект класс VocabularyWord, удалите из него весь добавленный по умолчанию код в окне редактора класса, и введите вместо него код из листинга 14.8.

12. Запустите приложение, нажав клавишу <F5>. Пользовательский интерфейс приложения должен выглядеть примерно так, как показано на рис. 14.4. Щелкните на кнопке buttonCreateDatabase для создания и наполнения данными базы данных SQL СЕ. Щелкните на кнопке buttonGameData с целью загрузки содержимого базы данных в память для последующего использования; в результате этого в текстовом окне должны отобразиться слова из словаря.

Рис. 14.4. Пример управления данными не с помощью объектов DataSet

Листинг 14.5. Пример пользовательского управления данными — код, помещаемый в форму Form1.cs

//Создает базу данных

private void buttonCreateDatabase_Click(object sender, System.EventArgs e) {

DatabaseAccess.CreateAndFillDatabase();

}

//Загружает данные из базы данных и отображает их

private void buttonLoadGameData_Click(object sender, System.EventArgs e) {

//Очистить текстовое окно

textBox1.Text = "";

//Загрузить данные для слов

GameData.InitializeGameVocabulary();

//Обойти все слова и добавить их в текстовый список

System.Text.StringBuilder thisStringBuilder;

thisStringBuilder = new System.Text.StringBuilder();

foreach (VocabularyWord thisWord in GameData.AllWords) {

thisStringBuilder.Append(thisWord.EnglishWord);

thisStringBuilder.Append(" = ");

thisStringBuilder.Append(thisWord.GermanWordWithArticleIfExists);

thisStringBuilder.Append("\r\n"); //Новая строка

}

//Отобразить список слов в текстовом окне

textBox1.Text = thisStringBuilder.ToString();

}

Листинг 14.6. Пример кода управления данными для DatabaseAccess.cs

//------------------------------------------------------------

//Код доступа к базе данных

//

//Этот класс управляет доступом к базе данных наших приложений

//------------------------------------------------------------

using System;

internal class DatabaseAccess {

const string DATABASE_NAME = "LearnGerman.sdf";

const string CONNECT_STRING = "Data Source = " + DATABASE_NAME + "; Password = ''";

const string TRANSLATIONTABLE_NAME = "TranslationDictionary";

const string TRANSLATIONTABLE_ENGLISH_COLUMN = "EnglishWord";

const string TRANSLATIONTABLE_GERMAN_COLUMN = "GermanWord";

const string TRANSLATIONTABLE_GERMANGENDER_COLUMN = "GermanGender";

const string TRANSLATIONTABLE_ WORDFUNCTION_COLUMN = "WordFunction";

internal const int DS_WORDS_COLUMNINDEX_ENGLISHWORD = 0;

internal const int DS_WORDS_COLUMNINDEX_GERMANWORD = 1;

internal const int DS_WORDS_COLUMNINDEX_GERMANGENDER = 2;

internal const int DS_WORDS_COLUMNINDEX_WORDFUNCTION = 3;

static public System.Data.IDataReader GetListOfWords() {

System.Data.SqlServerCe.SqlCeConnection conn = null;

conn = new System.Data.SqlServerCe.SqlCeConnection(CONNECT_STRING);

conn.Open();

System.Data.SqlServerCe.SqlCeCommand cmd = conn.CreateCommand();

cmd.ConmandText = "select " +

TRANSLATIONTABLE_ENGLISH_COLUMN + ", " +

TRANSLATIONTABLE_GERMAN_COLUMN + ", " +

TRANSLATIONTABLE_GERMANGENDER_COLUMN + ", " +

TRANSLATIONTABLE_WORDFUNCTION_COLUMN + " " + "from " +

TRANSLATIONTABLE_NAME;

//Выполнить команду базы данных

System.Data.SqlServerCe.SqlCeDataReader myReader =

cmd.ExecuteReader(System.Data.CommandBehavior.SingleResult);

return myReader;

}

//------------------------------------------

//Создает базу данных в случае необходимости

//------------------------------------------

static public void CreateDatabaseIfNonExistant() {

if (System.IO.File.Exists(DATABASE_NAME) == false) {

CreateAndFillDatabase();

}

}

//---------------------------------------

//Создает и наполняет данными базу данных

//---------------------------------------

static public void CreateAndFillDatabase() {

//Удалить базу данных, если она уже существует

if (System.IO.File.Exists(DATABASE_NAME)) {

System.IO.File.Delete(DATABASE_NAME);

}

//Создать новую базу данных

System.Data.SqlServerCe.SqlCeEngine sqlCeEngine;

sqlCeEngine = new System.Data.SqlServerCe.SqlCeEngine(CONNECT_STRING);

sqlCeEngine.CreateDatabase();

//-------------------------------------

//Попытаться подключиться к базе данных

//и наполнить ее данными

//-------------------------------------

System.Data.SqlServerCe.SqlCeConnection conn = null;

try {

conn = new System.Data.SqlServerCe.SqlCeConnection(CONNECT_STRING);

conn.Open();

System.Data.SqlServerCe.SqlCeCommand cmd = conn.CreateCommand();

//Создает таблицу перевода

//Поля:

// 1. Слова на английском языке (English)

// 2. Слова на немецком языке (German)

// 3. Грамматический род (Gender)

// 4. Тип слова

cmd.CommandText = "CREATE TABLE " + TRANSLATIONTABLE_NAME + " (" +

TRANSLATIONTABLE_ENGLISH_COLUMN + " ntext" + ", " +

TRANSLATIONTABLE_GERMAN_COLUMN + " ntext" + ", " +

TRANSLATIONTABLE_GERMANGENDER_COLUMN + " int" + ", " +

TRANSLATIONTABLE_WORDFUNCTION_COLUMN + " int" + ")";

cmd.ExecuteNonQuery();

//Наполнить базу данных словами

FillDictionary(cmd);

} catch (System.Exception eTableCreate) {

System.Windows.Forms.MessageBox.Show("Error occurred adding table :" + eTableCreate.ToString());

} finally {

//Всегда закрывать базу данных по окончании работы

conn.Close();

}

//Информировать пользователя о создании базы данных

System.Windows.Forms.MessageBox.Show("Created langauge database!");

}

static private void FillDictionary(System.Data.SqlServerCe.SqlCeCommand cmd) {

//Глаголы

InsertEnglishGermanWordPair(cmd, "to pay", "zahlen",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Verb);

InsertEnglishGermanWordPair(cmd, "to catch", "fangen",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Verb);

//Добавить другие слова...

//Местоимения

InsertEnglishGermanWordPair(cmd, "What", "was",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Pronoun);

//Добавить другие слова...

//Наречия

InsertEnglishGermanWordPair(cmd, "where", "wo",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Adverb);

InsertEnglishGermanWordPair(cmd, "never", "nie",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Adverb);

//Добавить другие слова...

//Предлоги

InsertEnglishGermanWordPair(cmd, "at the", "am",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Preposition);

//Имена прилагательные

InsertEnglishGermanWordPair(cmd, "invited", "eingeladen",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Verb);

InsertEnglishGermanWordPair(cmd, "yellow", "gelbe",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Adjective);

InsertEnglishGermanWordPair(cmd, "one", "eins",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Adjective);

InsertEnglishGermanWordPair(cmd, "two", "zwei",

VocabularyWord.WordGender.notApplicable, VocabularyWord.WordFunction.Adjective);

//Имена существительные мужского рода

InsertEnglishGermanWordPair(cmd, "Man", "Mann",

VocabularyWord.WordGender.Masculine, VocabularyWord.WordFunction.Noun);

InsertEnglishGermanWordPair(cmd, "Marketplace", "Marktplatz",

VocabularyWord.WordGender.Masculine, VocabularyWord.WordFunction.Noun);

InsertEnglishGermanWordPair(cmd, "Spoon", "Löffel",

VocabularyWord.WordGender.Masculine, VocabularyWord.WordFunction.Noun);

//Имена существительные женского рода

InsertEnglishGermanWordPair(cmd, "Woman", "Frau",

VocabularyWord.WordGender.Feminine, VocabularyWord.WordFunction.Noun);

InsertEnglishGermanWordPair(cmd, "Clock", "Uhr",

VocabularyWord.WordGender.Feminine, VocabularyWord.WordFunction.Noun);

InsertEnglishGermanWordPair(cmd, "Cat", "Katze",

VocabularyWord.WordGender.Feminine, VocabularyWord.WordFunction.Noun);

//Имена существительные среднего рода

InsertEnglishGermanWordPair(cmd, "Car", "Auto",

VocabularyWord.WordGender.Neuter, VocabularyWord.WordFunction.Noun);

InsertEnglishGermanWordPair(cmd, "Book", "Buch",

VocabularyWord.WordGender.Neuter, VocabularyWord.WordFunction.Noun);

}

//----------------------------

//Помещает слово в базу данных

//----------------------------

static private void InsertEnglishGermanWordPair(

System.Data.SqlServerCe.SqlCeCommand cmd,

string englishWord, string germanWord,

VocabularyWord.WordGender germanWordGender,

VocabularyWord.WordFunction wordFunction) {

cmd.CommandText = "INSERT INTO " + TRANSLATIONTABLE_NAME + "(" +

TRANSLATIONTABLE ENGLISH_COLUMN + ", " +

TRANSLATIONTABLE_GERMAN_COLUMN + ", " +

TRANSLATIONTABLE_GERMANGENDER_COLUMN + ", " +

TRANSLATIONTABLE_WORDFUNCTION_COLUMN + ") VALUES ('" +

englishWord + "', '" + germanWord + "', '" +

System.Convert.ToString(((int) germanWordGender))+ "', '" +

System.Convert.ToString(((int) wordFunction)) + "' )";

cmd.ExecuteNonQuery();

}

} //Конец класса

Листинг 14.7. Пример кода управления данными для GameData.cs

//-----------------------------------------------------------------

//Код управления данными в памяти

//

//Этот код предназначен для управления представлением кода в памяти

//-----------------------------------------------------------------

using System;

internal class GameData {

//Массив списков для сохранения загружаемых данных

private static System.Collections.ArrayList m_vocabularyWords All;

private static System.Collections.ArrayList m_vocabularyWords_Nouns;

private static System.Collections.ArrayList m_vocabularyWords_Verbs;

private static System.Collections.ArrayList m_vocabularyWords_Adjectives;

private static System.Collections.ArrayList m_vocabularyWords_Adverbs;

private static System.Collections.ArrayList m_vocabularyWords_Prepositions;

public static bool isGameDataInitialized {

//Инициализация данных игры, если слова загружены

get {

return (m_vocabularyWords_All != null);

}

}

//Возвращает коллекцию всех имеющихся слов

public static System.Collections.ArrayList AllWords {

get {

//Загрузить данные, если они не были инициализированы

if (m_vocabularyWords_All == null) {

InitializeGameVocabulary();

}

return m_vocabularyWords_All;

}

}

//Возвращает коллекцию всех имеющихся имен существительных

public static System.Collections.ArrayList Nouns {

get {

//Загрузить данные, если они не были инициализированы

if (m_vocabularyWords_Nouns == null) {

InitializeGameVocabulary();

}

return m_vocabularyWords_Nouns;

}

}

//==========================================================

//Загружает данные из нашей базы данных

//==========================================================

static public void InitializeGameVocabulary() {

//Создать новый массив списков для хранения наших слов

m_vocabularyWords_All = new System.Collections.ArrayList();

m_vocabularyWords_Nouns = new System.Collections.ArrayList();

m_vocabularyWords Verbs = new System.Collections.ArrayList();

m_vocabularyWords_Adjectives = new System.Collections.ArrayList();

m_vocabularyWords_Adverbs = new System.Collections.ArrayList();

m_vocabularyWords_Prepositions = new System.Collections.ArrayList();

System.Data.IDataReader dataReader;

dataReader = DatabaseAccess.GetListOfWords();

VocabularyWord newWord;

//Обойти все записи

while (dataReader.Read()) {

//Поместить данные для только что считанного слова в класс

newWord = new VocabularyWord(

dataReader.GetString(DatabaseAccess.DS_WORDS_COLUMNINDEX_ENGLISHWORD),

dataReader.GetString(DatabaseAccess.DS_WORDS COLUMNINDEX_GERMANWORD),

(VocabularyWord.WordGender)dataReader.GetInt32(DatabaseAccess.DS_WORDS_COLUMNINDEX_GERMANGENDER),

(VocabularyWord.WordFunction)dataReader.GetInt32(DatabaseAccess.DS_WORDS_COLUMNINDEX_WORDFUNCTION));

//Добавить новое слово в массив списков

m_vocabularyWords_All.Add(newWord);

//Слова могут принадлежать нескольким группам, поэтому необходимо

//выполнить проверку с использованием операции логического И

//для проверки того, что слово относится к данной категории

if ((newWord.getWordFunction & VocabularyWord.WordFunction.Noun) ! = 0) {

m_vocabularyWords_Nouns.Add(newWord);

}

if ((newWord.getWordFunction & VocabularyWord.WordFunction.Verb) != 0) {

m_vocabularyWords_Verbs.Add(newWord);

}

if ((newWord.getWordFunction & VocabularyWord.WordFunction.Adjective) != 0) {

m_vocabularyWords Adjectives.Add(newWord);

}

if ((newWord.getWordFunction & VocabularyWord.WordFunction.Adverb) != 0) {

m_vocabularyWords Adverbs.Add(newWord);

}

if ((newWord.getWordFunction & VocabularyWord.WordFunction.Preposition) != 0) {

m_vocabularyWords_Prepositions.Add(newWord);

}

}

//Закрыть объект

DataReader dataReader.Close();

}

} //Конец класса

Листинг 14.8. Пример кода управления данными для VocabularyWord.cs

using System;

//------------------------------

//Хранит данные слова из словаря

//------------------------------

internal class VocabularyWord {

[System.FlagsAttribute] //Значения можно объединять с помощью операции

//логического ИЛИ

public enum WordFunction {

Noun = 1,

Verb = 2,

Pronoun = 4,

Adverb = 8,

Adjective = 16,

Preposition = 32,

Phrase = 64

}

public enum WordGender {

notApplicable = 0,

Masculine = 1,

Feminine = 2,

Neuter = 3,

}

private string m_englishWord;

private string m_germanWord;

private VocabularyWord.WordGender m_germanGender;

private VocabularyWord.WordFunction m_wordFunction;

public string EnglishWord{

get {

return m_englishWord;

}

}

public string GermanWord{

get {

return m_germanWord;

}

}

public WordFunction getWordFunction {

get {

return m_wordFunction;

}

}

public WordGender GermanGender{

get {

return m_germanGender;

}

}

//-----------------------------------------------------------------

//Возвращает слово на немецком языке, которому предшествует артикль

//{например, 'der', 'die', 'das'), если он существует

//-----------------------------------------------------------------

public string GermanWordWithArticleIfExists {

get {

if (m_germanGender == WordGender.notApplicable) {

return this.GermanWord;

}

return this.GenderArticle +" " + this.GermanWord;

}

} //Конец свойства

public string GenderArticle {

get {

switch (m_germanGender) {

case WordGender.Masculine:

return "der";

case WordGender.Feminine:

return "die";

case WordGender.Neuter:

return "das";

}

return "";

}

}

public VocabularyWord(string enlgishWord, string germanWord, WordGender germanGender, WordFunction wordFunction) {

m_englishWord = enlgishWord;

m_germanWord = germanWord;

m_germanGender = germanGender;

m_wordFunction = wordFunction;

}

} //Конец класса

Различные способы хранения долговременных данных

Существует много различных способов хранения данных мобильных приложений. Данные можно сохранять в двоичных файлах, текстовых файлах и базах данных. (Базу данных можно считать частным случаем двоичного файла.) Хранение данных может быть реализовано вне устройства или на устройстве. Долговременные данные могут синхронизироваться между устройствами и серверами. Ниже описаны преимущества и недостатки наиболее распространенных вариантов хранения данных, а также приведены рекомендации относительно того, как подходить к принятию решений относительно организации долговременного хранения данных при проектировании приложений для мобильных устройств.

Хранение данных в виде XML-файлов на устройстве

■ Преимущества. Текстовые файлы можно отлично использовать для хранения средних объемов долговременных данных. XML-файлы обеспечивают достижение разумного баланса между пользовательскими и структурными форматами и являются шагом вперед по сравнению с обычными текстовыми файлами. XML-файлы могут легко передаваться между настольными компьютерами, серверами и устройствами и без особого труда интерпретироваться различными приложениями. Учитывая простоту и гибкость XML файлов, найти для них конкурента очень трудно.

■ Недостатки. Текстовые файлы характеризуются увеличенными размерами, но размеры XML-файлов еще больше. Если ваше мобильное приложение работает с множеством данных, эффективное хранение которых необходимо организовать, то XML-файлы для этого не годятся. Кроме того, XML-файлы представляют собой форматированный текст, их содержимое можно легко прочитать и они не обеспечивают защиту данных; по этой причине следует избегать их использования для хранения критически важной информации, если только вы не располагаете надежным механизмом шифрования файлов.Примечание. Дополнительные рекомендации по использованию XML для эффективного хранения файлов содержатся в главе 10.

Хранение данных в базах данных SQL СЕ на устройствах

■ Преимущества. Наличие процессора базы данных на устройстве открывает очень широкие возможности. Встроенные базы данных обеспечивают приложению возможность локального хранения, управления и запроса больших объемов информации. Базы данных SQL СЕ могут защищаться паролями и поэтому обеспечивают безопасность хранения критически важной информации. Между базами данных SQL СЕ и серверными базами данных SQL можно устанавливать партнерские отношения, что обеспечивает широкие возможности их синхронизации между собой. Для приложений, которым приходится иметь дело с множеством данных, нуждающихся в локальном управлении, этот выбор, вероятно, является наилучшим.

■ Недостатки. Самый большой недостаток использования встроенных баз данных состоит в необходимости проверки того, установлен ли процессор базы данных на вашем целевом устройстве. Сама база данных SQL СЕ занимает значительный объем памяти устройства (1-3 Мбайт) и обычно должна устанавливаться на нем, так как нередко она не является частью образа устройства в ПЗУ. Из-за требований к объему памяти не все классы устройств поддерживают размещение процессора базы данных SQL СЕ. Например, в настоящее время размещение SQL СЕ поддерживается Pocket PC, но не поддерживается смартфонами. Кроме занимаемого объема памяти, играют роль и требования синхронизации. Перемещение данных, хранящихся в локальной базе данных устройства, на другой компьютер потребует от вас написания кода соответствующей логики; для перемещения данных между устройствами вам может понадобиться упаковка данных в виде ADO.NET DataSet или привлечение пользовательского формата данных.

Хранение данных в базах данных SQL вне устройства (на сервере)

■ Преимущества. Использование для хранения данных и обращения к ним базы данных, расположенной на сервере, является эффективным способом доступа к почти неограниченным объемам данных.

■ Недостатки. Для получения данных с сервера или обновления данных на сервере необходимо установить соединение. Если ваше мобильное приложение использует внешнюю базу данных в качестве основного источника данных, планируйте написание пользовательской логики для временного локального сохранения данных в случае разрыва соединения; нет ничего хуже, чем потерять данные в результате сбоя связи при попытке выполнить их обновление на сервере. Мобильным устройствам все время приходится сталкиваться с сетевыми сбоями, и ваше мобильное приложение должно уметь справляться с такими трудностями, возникающими при работе в реальных условиях.

Другим потенциальным недостатком обращения к данным на сервере является необходимость считаться с правилами доступа, принятыми в частных сетях, и с брандмауэрами. Большинство серверных баз данных, содержащих ценную информацию, находятся в защищенных средах позади брандмауэров. Брандмауэр может не дать вашему мобильному приложению соединиться с базой данных сервера, если устройство находится за пределами частной сети. Если требуется доступ к данным на защищенном сервере, то вы должны решить вопрос о том, как сделать такой доступ возможным.

Доступ к данным, хранящимся вне устройств, посредством Web-служб

■ Преимущества. Web-службы все чаще используются в качестве оболочек доступа к коммерческим источникам данных. Доступ к информации, хранящейся в базах данных, может обеспечиваться через Web-службы без предоставления непосредственного доступа к самим базам данных. Обычно Web-службы работают посредством сетевых протоколов HTTP или HTTPS; как правило, брандмауэры ведут себя дружественно по отношению к этим протоколам. Если сеть уже поддерживает выходной сервер, то создать Web-службу, размещенную на этом сервере, как правило, относительно просто.

Новейшие процессоры баз данных усиленно поддерживают возврат данных в виде XML, позволяя обходиться без промежуточного Web-сервера. Эти базы данных фактически предлагают собственные Web-службы. XML-данные, возвращенные непосредственно базой данных, не обязательно будут иметь формат данных ADO.NET XML DataSet, но любые возвращенные XML-данные можно синтаксически проанализировать и обработать на устройстве, если такой способ работы с ними является наилучшим.

В обоих случаях обмен данными с мобильными устройствами может осуществляться посредством потоков с использованием формата данных ADO.NET DataSet в виде XML или любого другого формата XML-данных. Выбирая между вариантами непосредственной связи с базой данных или изоляцией базы данных при помощи промежуточного Web-сервера, следует исходить из соображений безопасности, производительности, а также простоты разработки и развертывания приложения.

■ Недостатки. Как и в случае использования внешних баз данных, невозможно гарантировать, что сетевой доступ к Web-службам будет обеспечен в любой момент времени. Чтобы ваше приложение было полезным и надежным, для него всегда необходимо предусматривать стратегию на случай сбоя связи, позволяющую работать с локальными кэшированными данными, если сеть недоступна.

Еще одним недостатком является недостаточная эффективность связи. Поскольку в качестве основного коммуникационного механизма Web-службы используют XML, то предоставляемая ими информация занимает больший объем по сравнению с такими, например, специализированными форматами, как те, которые используются для синхронизации баз данных. Если имеется значительный объем данных, которые необходимо загрузить или выгрузить, то, вероятно, целесообразно рассмотреть возможность использования механизма непосредственного доступа к базе данных, основанного на наиболее эффективном из имеющихся протоколов.

SQL СЕ

С небольшими объемами данных, которые обладают простой структурой, еще можно справиться с помощью файлов XML, однако при превышении некоторого объема и сложности данных ваше приложение значительно выиграет, а его разработка намного упростится, если вы используете формальную базу данных. Хотя и не существует абсолютных правил относительно того, когда именно вместо XML-файлов следует воспользоваться базой данных, чем больше объем данных, тем целесообразнее становится переход к базе данных. Как правило, если ожидается, что количество строк данных, с которыми придется работать вашему мобильному приложению, больше ста, или информация должна храниться в нескольких таблицах, то, вероятно, имеет смысл использовать установленную на устройстве базу данных, например SQL СЕ.

По SQL СЕ существует хорошая документация в сети. Читателям, которые хотели бы получить более подробную информацию относительно SQL СЕ, можно порекомендовать провести поиск по ключевым словам "SQL Server СЕ" в библиотеке MSDN в сети (или в справочной документации по Visual Studio). Вместо того чтобы пытаться подробно пересказать уже имеющуюся в указанных источниках информацию, в этом разделе будет приведен краткий обзор SQL СЕ и описаны важные решения, которые должны быть приняты в процессе разработки кода мобильного приложения, предназначенного для работы с такими базами данных, установленными на устройстве, как SQL СЕ. Простой пример, демонстрирующий использование базы данных SQL СЕ, приводился ранее в данной главе в листингах 14.5, 14.6, 14.7 и 14.8.

Что такое SQL СЕ?

SQL СЕ, формальным названием которой является SQL Server СЕ, — это процессор базы данных для мобильных и встроенных устройств. Эта база данных располагает относительно богатыми функциональными возможностями в отношении хранения и запроса структурированных данных и их синхронизации с серверами. На одном устройстве могут быть созданы одновременно несколько баз данных SQL СЕ. Каждая из баз данных на устройстве представляется единственным двоичным файлом; эти файлы можно вручную копировать с одного устройства на другое и автоматически синхронизировать с базой данных на сервере. Содержимое базы данных SQL СЕ может быть зашифровано с помощью пароля, что обеспечит разумный уровень безопасности данных в том случае, если устройство украдено или утеряно или его содержимое тайком скопировано.

SQL СЕ представляет собой подмножество функциональных возможностей версий базы данных SQL Server, ориентированных на настольные компьютеры и серверы. SQL СЕ поддерживает хранение реляционных данных в таблицах, а также значительную часть типов данных SQL и синтаксиса запросов для добавления, извлечения и изменения данных. Следует подчеркнуть, что в настоящее время SQL СЕ не поддерживает сохраненные процедуры или именованные параметры в запросах.

Другие базы данных для мобильных устройств и модели лицензирования баз данных

Следует отметить, что устанавливаемые на устройствах базы данных, которые могут выполняться и на мобильных устройствах, выпускаются и другими поставщиками программного обеспечения. С концептуальной точки зрения они аналогичны SQL СЕ, но у каждой из них есть свои сильные и слабые стороны в отношении возможностей синхронизации данных, разнообразия функциональных средств и модели ценообразования. Важной характеристикой SQL СЕ является то, что ее можно свободно использовать и распространять вместе со своим приложением без необходимости получения на это специальной лицензии или выплат авторских отчислений. Для синхронизации с SQL- серверами требуется наличие специальной лицензии клиента SQL, точно так же, соответствующая клиентская лицензия требуется и для подключения настольного приложения непосредственно к SQL-серверу.

Исторически так сложилось, что компания Microsoft ранее выпустила еще одну базу данных для мобильных устройств, которая называлась CEDB (Windows СЕ Database). Эта база данных имеет ограниченные функциональные возможности, и ее использование в новых приложениях не рекомендуется; на будущих устройствах база данных CEDB может отсутствовать. Поскольку эта технология почти полностью устарела, никакого непосредственного механизма для доступа к этой базе данных в .NET Compact Framework не предусмотрено. Если вашему приложению требуется доступ к CEDB, вы должны вызывать встроенный код или использовать интерфейсные классы .NET, созданные сторонними производителями. Имеются две неплохие альтернативы использованию CEDB: для сравнительно небольших объемов данных можно использовать XML-файлы, тогда как для крупных объемов данных наилучшим выбором будет SQL СЕ.

Независимый и синхронизированный режимы работы базы данных SQL СЕ.

SQL СЕ может использоваться в одном из трех режимов:

1. Автономный режим. В этой модели использования база данных SQL СЕ служит в качестве автономной базы данных на устройстве. Аналогом этого на настольном компьютере является использование локальных процессоров баз данных SQL Server или Access для управления локальной базой данных. Одна из основных трудностей при использовании автономной базы данных SQL СЕ заключается в выборе правильной стратегии наполнения базы данных. Ваше приложение может либо динамически заполнять базу данных внешними данными, получаемыми устройством во время выполнения, либо использовать готовый файл базы данных, копируемый на устройство. Возможно и сочетание указанных моделей; данные могут динамически добавляться в существующий файл базы данных, который был загружен на устройство. Какая стратегия заполнения базы данных является наилучшей, зависит от природы вашего приложения. Если вы используете предварительно заполненную базу данных, то самый простой способ доставки этих данных заключается в создании эталонной копии базы данных на Pocket PC как части вашего процесса разработки и последующего копирования этой базы данных с устройства на машину, которая используется для осуществления разработки. Такая предварительно заполненная база данных может далее быть скопирована на все целевые устройства в процессе развертывания приложения.

2. Синхронизация с SQL-сервером через Web-cepвep (IIS). Этот механизм известен под названием удаленного доступа к данным (remote data access — RDA). Он представляет собой простой метод синхронизации, в соответствии с которым SQL- сервер, содержащий эталонную копию данных, никак специально не связан с базами данных SQL СЕ, которые с ним синхронизируются. Базы данных SQL СЕ получают доступ к серверным данным точно так же, как любое другое клиентское приложение базы данных, за исключением того, что доступ осуществляется через интерфейс Web-cepвepa. Поскольку серверная база данных не должна отслеживать, какие данные хранятся синхронизированными SQL СЕ-клиентами, стратегия RDA характеризуется низкими накладными расходами на сервере и хорошо масштабируется. Подобным образом с основным SQL-сервером может синхронизироваться неограниченное количество устройств с локальными базами данных SQL СЕ. Синхронизация данных реализуется с помощью специального механизма синхронизации SQL СЕ, который выполняется поверх Windows Internet Information Server (Web-сервер). Поскольку синхронизация основывается на Web-сервере, она при необходимости может осуществляться через общедоступную сеть. SQL-серверу ничего не известно о том, что клиентские базы данных должны синхронизироваться с его данными, поэтому ответственность за то, чтобы данные своевременно обновлялись на клиенте и сервере, лежит на мобильном приложении. Для получения более подробной информации относительно RDA прочитайте раздел справки "Using Remote Data Access" в материалах Microsoft "SQL Server СЕ Books Online"; эта документация поставляется как часть Visual Studio .NET (2003 или более поздняя версия). Резюмируя: RDA — суть низкие накладные расходы и отличная масштабируемость, но это дается за счет того, что данные приходится обновлять вручную. RDA — это прекрасный выбор в тех случаях, когда данные, которые должны синхронизироваться, главным образом используются только для чтения.

3. Синхронизация непосредственно с SQL-сервером. Этот механизм известен под названием репликации слиянием.

При репликации слиянием между локальной базой данных SQL СЕ устройства и SQL-сервером, с которым она синхронизируется, устанавливаются партнерские отношения. Это — мощная модель, поскольку SQL-cepверу доподлинно известно, какие данные хранятся в каждой партнерской клиентской базе данных SQL СЕ; обновление данных, как на устройстве, так и на сервере, может осуществляться гораздо более автоматизированным и систематическим образом, нежели в случае синхронизации посредством RDA. Поскольку SQL-сервер должен сохранять информацию о каждом партнерском SQL CE- клиенте, эта модель масштабируется хуже, чем модель RDA; поддержка огромного количества клиентов будет ложиться тяжким бременем на сервер. Независимо от этого, если требуется обеспечить наиболее надежную синхронизацию, данный выбор великолепно для этого подойдет. Для получения более подробной информации относительно репликации данных слиянием прочтите раздел "Using Replication" в материалах Microsoft "SQL Server СЕ Books Online".

Использование базы данных SQL СЕ несколькими приложениями

В настоящее время SQL СЕ обеспечивает одновременную поддержку только одного соединения с любой отдельной базой данных. Это правило действует как внутри приложения, так и вне его. Каждая база данных хранится в отдельном файле; эти файлы нельзя открыть одновременно, используя SQL СЕ. Это означает, что хотя на одном и том же устройстве могут быть открыты одновременно несколько баз данных, любая конкретная база данных в любой момент времени может иметь только одно соединение. Если приложение пытается открыть файл базы данных SQL СЕ, который ранее уже был открыт другим или этим же приложением, то процессор базы данных сгенерирует исключение, и второе соединение установлено не будет.

Если ваше приложение использует базу данных, которая не должна разделяться с другими приложениями, вам достаточно лишь убедиться в том, что ваш код не пытается установить одновременно более одного соединения с базой данных; соединением с базой данных следует управлять как глобальным ресурсом. Если ваше приложение работает с базой данных SQL СЕ, которая может использоваться совместно с другими мобильными приложениями, то вы должны учесть в своем проекте приложения два дополнительных момента:

1. Вы должны убедиться в том, что ваше мобильное приложение не удерживает открытым соединение с базой данных в течение большего времени, чем это крайне необходимо. Соединение следует устанавливать непосредственно перед тем, как возникнет потребность в доступе к базе данных, и по возможности освобождать сразу же после осуществления доступа к данным. Приложение должно проектироваться так, чтобы ему не требовался постоянный доступ к базе данных.

2. Вы должны предусматривать в коде защитные меры и быть готовыми к тому, что при любой попытке обращения к базе данных она уже могла быть до этого открыта. В вашем приложении должна быть предусмотрена модель, которая обеспечивает уведомление пользователя о том, что в настоящее время база данных уже используется другим локальным приложением, чтобы пользователь мог предпринять меры к закрытию другого приложения или вынудить его освободить соединение. Кроме того, в вашем мобильном приложении должна быть предусмотрена модель, позволяющая отложить доступ к базе данных на более поздний срок, когда установление соединения станет возможным; приложение не должно тормозиться из-за того, что не может подключиться к базе данных.

База данных SQL СЕ доступна не на всех типах устройств

Важно знать, что в настоящее время база данных SQL СЕ недоступна на смартфонах. Это связано с ограниченностью возможностей этих устройств в отношении, главным образом, размера базы данных, объема требуемой памяти и механизмов хранения данных. На устройствах Pocket PC имеются файловые системы на основе ОЗУ с питанием от батарей, обеспечивающие возможность быстрого доступа к файлам; смартфоны характеризуются тем, что для нужд долговременного хранения информации используется флэш-память, а объем рабочего ОЗУ небольшой, и оба эти фактора делают выполнение процессора базы на данном типе устройств менее желательным.

В случае создания вами двух отдельных версий приложения, одна из которых предназначена для Pocket PC, а вторая — для смартфонов, вам придется продумать два варианта проектных решений. Приложение для смартфонов должно удовлетворять другим требованиям в отношении пользовательского интерфейса по сравнению с приложением для Pocket PC и располагает совершенно иными возможностями в отношении хранения данных. В случае приложений для смартфонов объем данных, хранимых в долговременном хранилище, обычно будет меньше, чем в случае приложений для Pocket PC. Приемлемым вариантом может служить использование SQL СЕ на устройствах Pocket PC и XML-файлов на смартфонах.

Visual Studio .NET 2005 и SQL СЕ

В следующей версии SQL СЕ и .NET Compact Framework будет предложено два существенных усовершенствования, касающихся доступа к данным при работе с SQL СЕ.

1. Класс SqlCeResultSet даст разработчикам возможность перемещаться по данным и обновлять их непосредственно в базе данных SQL СЕ. Это упростит создание приложений, которые работают с базами данных вплотную, а не используют высокоуровневые абстракции наподобие объектов ADO.NET DataSet.

2. SQL СЕ будет поддерживать многопользовательский доступ. Это означает, что несколько приложений на одном устройстве смогут одновременно открывать одни и те же базы данных и работать с ними. Благодаря этому устранятся некоторые из описанных выше проблем, связанных с параллельным доступом к базам данных на устройстве.

Даст что-либо введение этих новых функциональных возможностей вам и вашему приложению? Ответ звучит так: "Возможно". Многие разработчики мобильных приложений выбирают в качестве целевых такие устройства, в ПЗУ которых уже содержатся необходимые среды выполнения, поскольку это упрощает развертывание приложения. (Для некоторых устройств такая возможность является единственной, но это уже тема следующей главы.) Если речь идет о таких приложениях, то должно пройти некоторое время, пока не наберется некоторое критическое количество устройств, ПЗУ которых содержат обновленные компоненты. Однако если у вас есть возможность установить обновленную среду выполнения и процессор базы данных, то это стоит сделать хотя бы ради того, чтобы иметь эти средства.

Резюме

Как и в случае задач повышения производительности, управления памятью и построения пользовательского интерфейса, создание удачной модели данных для мобильного приложения требует одновременно и планомерного подхода, и экспериментирования. Хорошая новость состоит в том, что многое из вашего опыта организации доступа к данным на настольных компьютерах вы сможете использовать при проектировании кода для доступа к данным в мобильных приложениях. Плохой же новостью является то, что вы сможете непосредственно использовать лишь небольшую часть уже имеющегося кода для настольных компьютеров, а для создания замечательных мобильных приложений вам придется учитывать специфику мобильных устройств.

При организации доступа к данным самое важное — это определить, каким образом ваша стратегия доступа к данным будет удовлетворять потребности пользователей при работе в автономном режиме. Реалии таковы, что соединение между вашим мобильным приложением и серверами баз данных будут часто разрываться, иногда по причине того, что "так было задумано", а иногда — из-за сбоев в сети. Работе в условиях периодически разрывающихся соединений специально посвящена следующая глава, но этот момент является ключевым и при проектировании стратегии доступа к данным. Если пользователю требуется немедленный доступ к данным, они должны кэшироваться локально на устройстве.

В зависимости от того, как будет использоваться ваше мобильное приложение, ему может потребоваться соединение с источниками данных посредством самых различных моделей подключения. Некоторые модели подключения, например Wi-Fi, отличаются высокой скоростью передачи данных и небольшой стоимостью, тогда как другие работают медленно и обладают высокой стоимостью. Дополнительные требования к разрабатываемому проекту могут появиться из-за необходимости поддержки соединений через общедоступные или виртуальные частные сети. В процессе проектирования модели доступа к данным для мобильного приложения важно представлять себе, какими могут быть сценарии подключения, и каким образом это может отразиться на ваших потребностях доступа к данным и их синхронизации. Важно продумать, какие данные будут храниться локально на устройстве, как будет организовано хранение этих данных и доступ к ним, и каким образом эти данные будут синхронизироваться с серверами.

В средах программирования доступа к данным часто предлагают многоуровневые подходы для организации работы с данными. Как и при работе с XML-ориентированными средами, существуют низкоуровневые модели однонаправленного доступа к данным, которые не имеют состояния, и построенные поверх них полнофункциональные модели, хранящие очень подробную информацию о своем состоянии. ADO.NET предлагает возможность выбора между этими типами моделей. Как разработчик, вы можете работать либо на высоком уровне абстракции, используя объекты ADO.NET DataSet для управления данными в памяти, либо на низком уровне, используя непосредственно классы DataReader и DataConnection, которые напрямую связываются с базами данных. Как и на заправках, полный сервис — это, разумеется, неплоxo, но за все услуги надо платить; в случае доступа к данным дополнительной платой за использование высокоуровневых служб будет необходимость хранения состояния в памяти, а это, в конечном счете, означает снижение производительности.

Если вы решите работать на низком уровне абстракции, то сможете хранить загруженные данные в наиболее эффективном для нужд вашего приложения формате, но тогда вам придется взять на себя все заботы по эффективному управлению данными.

В случае данных небольшого объема, данных, которые требуют интенсивной поддержки динамического обновления или данных, характеризующихся сложными взаимосвязями, вам будет очень полезна полнофункциональная модель, основанная на использовании объектов ADO.NET DataSet. При работе с объектами DataSet убедитесь в том, что вы используете наиболее эффективные способы доступа к данным. В случае работы с объектами DataRow в объектах DataTable это означает использование кэшированных индексов объектов DataColumn для доступа к полям.

Для достижения максимально возможной производительности при работе с большими объемами данных вы должны продумать для своего приложения пользовательскую модель данных, в наибольшей степени оптимизированную под решаемую задачу. Результатом этого может быть как непосредственное повышение производительности, так и снижение общего объема памяти, потребляемой вашим приложением. Если вы остановились на пользовательском низкоуровневом подходе, то по возможности постарайтесь воспользоваться наиболее простой и эффективной в отношении использования памяти моделью. Всегда осуществляйте мониторинг выполнения кода и тестируйте производительность вашего варианта проекта по сравнению с существующими высокоуровневыми моделями доступа к данным!

Существует две рекомендованных модели локального хранения долговременных данных на устройствах, одна из которых предполагает хранение данных в виде XML-файлов, а вторая — использование локальной базы данных устройства, например SQL СЕ. Каждый из этих вариантов доступен как при использовании высокоуровневой модели ADO.NET DataSet, так и при использовании адаптированных низкоуровневых механизмов для работы с данными. Коль скоро объем данных, с которыми приходится работать, остается сравнительно небольшим (например, порядка 50 Кбайт в случае XML-данных), то отличные и гибкие возможности вам предоставят XML-файлы. С увеличением же объемов данных все более привлекательным будет становиться использование процессоров баз данных. И вновь следует подчеркнуть, что единственным способом проверки того, что вы приняли верные проектные решения, является мониторинг выполнения кода и получение количественных показателей, которые можно сравнивать между собой.

Как и в случае проектирования пользовательских интерфейсов, лозунг "пишется однажды — выполняется везде" — не более чем призрачная цель при проектировании доступа к данным в мобильных приложениях. Для достижения максимально возможной производительности вы должны специальным образом настраивать модели доступа к данным и использования памяти применительно к конкретным устройствам, на которых будет выполняться приложение. Если вы создаете несколько версий приложения, ориентированные на различные классы устройств, то вам, вероятно, придется выбрать для каждого класса устройств свою модель хранения данных, зависящую от возможностей устройства и потребностей приложения.

В случае современных мобильных устройств, обладающих широчайшими возможностями, применение технологий доступа к данным является не только необходимым, но и чрезвычайно плодотворным. Выбор наиболее подходящей модели, способной удовлетворить потребности вашего приложения и в то же время оставаться достаточно гибкой, чтобы ее можно было настраивать в соответствии с требованиями реальной практики, является увлекательнейшей задачей проектирования.

ГЛАВА 15

Шаг 4: выбор подходящей коммуникационной модели

"Информация решает все…"

Маршалл Мак-Луган (Marshall McLuhan) (1911–1980), теоретик в области связи

(Encarta 2004, Quotations)

"И-Ти звонить семья…"

Пришелец, который просто хотел поговорить с родными (кинофильм "Пришелец" ("The Extra-Terrestrial"), 1982)

"Если что-то может пойти не так, то это обязательно произойдет, причем именно тогда, когда вы меньше всего этого ожидаете."

Закон Мэрфи

Введение в технологии связи с помощью мобильных приложений

Хотя между приведенными выше цитатами, на первый взгляд, нет ничего общего, каждая из них характеризует определенный аспект стратегий связи, используемых мобильными приложениями.

Суть пророческого высказывания Маршалла Мак-Лугана ("Информация решает все") состоит в том, что развитие технологий связи оказывает на человеческое общество радикальное влияние. В этой цитате утверждается, что облик общества в значительной мере определяется уровнем развития коммуникационных средств. Иначе говоря, технологии связи — это не просто средства, которые состоят на службе у общества, скорее, именно то, какие технологии связи применяются заметным образом воздействует на сам характер общества. Точно та же аналогия справедлива и в отношении программного обеспечения; приложение не просто использует средства связи, но сама его природа в значительной степени определяется тем, какие способы коммуникации в нем используются. Это вдвойне справедливо в отношении программного обеспечения, выполняющегося на мобильных устройствах. Способ коммуникации вашего мобильного приложения с внешним миром является его фундаментальной характеристикой. Применяемые приложением средства коммуникации — это не просто "набор технических средств", но фундаментальный атрибут поведения самого приложения.

В настоящее время разработчики мобильных приложений могут выбирать между многими технологиями связи, причем с каждым годом список этих технологий только увеличивается. В одних случаях коммуникационные средства встраиваются в оборудование, как это сделано, например, в мобильных телефонах, в других — это обеспечивается различными механизмами расширения, например съемными картами. Каждая очередная версия технологий связи не только работает быстрее и обходится дешевле по сравнению с предшествующими технологиями, но и представляет собой сложную систему со своими достоинствами и недостатками, которая борется за свое эволюционное выживание в коммуникационных джунглях. Очень важно хорошо понимать особенности различных разновидностей технологий связи, которые вы решаете использовать в проекте своего мобильного приложения. Например, поведение приложения, для удовлетворения коммуникационных потребностей которого используется технология Wi-Fi, в некоторых существенных аспектах будет иным, нежели поведение приложения, в котором для связи с мобильным GRPS-телефоном с целью доступа к сети используется протокол Bluetooth; в свою очередь, оба эти варианта значительно отличаются от работы в условиях кабельного подключения к сети и использования таких протоколов нательных сетей (body-area network), как ZigBee (для получения более подробной информации по этому вопросу посетите Web-сайт http://www.zigbee.org/).

Точно так же как не существует наилучшего универсального транспортного средства, не существует и единственного способа коммуникации, которое будет являться наиболее подходящим для вашего мобильного приложения во всех возможных ситуациях. Даже если не принимать во внимание денежные соображения, мул принесет вам гораздо больше пользы, чем вездеход, если необходимо взобраться вверх по крутому скалистому склону, а путешествие поездом будет гораздо эффективнее перелета на самолете, если необходимо добраться до соседнего города. То же самое можно сказать и в отношении средств коммуникации; самая дорогая, быстрая и современная технология связи вовсе не обязательно окажется наилучшим решением для вашего мобильного приложения. Важно понимать природу открывающихся перед вами возможностей выбора и принимать взвешенные решения, которые позволят полностью удовлетворить потребности вашего приложения в связи.

Что касается второй цитаты, то у нас есть все основания сомневаться в том, что семейный фильм 80-х годов о визите космического пришельца способен научить нас чему-либо в области мобильной связи. За цитатой скрывается простой намек: даже у представителей высокоразвитых цивилизаций иногда могут возникать трудности с тем, чтобы просто "сделать звонок домой". Чтобы связаться со своими родными, пришельцу потребовалось при помощи кабеля подключить обычный телефон через дешифратор к своему оборудованию; к счастью, нам (как мы надеемся!) будет немного легче. В любом случае для организации эффективной связи мы должны подготовить достаточно гибкий и надежный проект, позволяющий справляться с неожиданно возникающими проблемами.

Чтобы обеспечить доступ к сетевым ресурсам, в которых нуждается ваше мобильное приложение, вам придется преодолеть такие препятствия, как ненадежные соединения, недружественные брандмауэры и мобильные сети, которые, похоже, так и хотят извести вас всевозможными "усовершенствованными" пакетами, НТТР-заголовками или потоками, используемыми для передачи данных. Мобильные коммуникационные сети являются и будут оставаться более неоднородными по сравнению со стационарными сетями, и, как и в случае других аспектов проектирования мобильных приложений, весьма маловероятно, чтобы подход, основанный на принципе "пишется однажды — выполняется везде", привел вас к успеху при решении коммуникационных задач. Для того чтобы все работало так, как надо, вы должны провести множество экспериментов, во многом разобраться, создать качественный проект, надежно протестировать его и при этом, скорее всего, проявить, подобно упомянутому пришельцу, немалую долю изобретательности, ибо только тогда вы сможете быть уверены в том, что ваше приложение будет способно в любых ситуациях обеспечить связь "с домом".

Что касается третьей цитаты, то формулировка этого закона Мэрфи говорит сама за себя. Если существует хоть малейшая вероятность сбоя связи, то, как показывает практика, этот сбой обязательно наступит, причем это произойдет неожиданно и в самый неподходящий момент. Это вовсе не означает, что конечным пользователям вашего мобильного приложения остается только смириться с ненадежностью его работы. Тем не менее, отсюда следует, что вы должны приложить все усилия к тому, чтобы предусмотреть в логике работы приложения вероятность возникновения подобных сбоев и по возможности сгладить их отрицательные последствия. Устойчивая связь при ненадежных соединениях вполне возможна. Важно только заранее предполагать вероятность возникновения проблем подобного рода и прибегать к соответствующим защитным мерам.

Написание кодов программ для работы с мобильными сетями

Во всех случаях, представляющих практический интерес, приложения взаимодействуют с ресурсами, находящимися вне самого приложения. Приложения взаимодействуют с операционной системой, локальными ресурсами устройства и сетевыми ресурсами. Чем выше уровень взаимодействия, тем шире возможности приложения, но тем меньше вы можете их контролировать. Усиление взаимодействия с ресурсами вне устройства сопровождается увеличением вероятности возникновения сбоев при подключении к ним. Самое главное, о чем вы всегда должны помнить при написании кода, обеспечивающего взаимодействие через сеть, — это то, что вы не можете полностью контролировать конечный результат попытки установления соединения.

Ниже приводится краткое описание нескольких возможных уровней взаимодействия, перечисленных в порядке усиления степени зависимости мобильного приложения от ресурсов окружения.

■ Замкнутые вычислительные системы. При написании алгоритмов обработки данных, принадлежащих только вашему приложению, его судьба находится полностью в ваших руках. Все, что происходит в такой системе, происходит в результате выполнения кода, который вы знаете до мелочей и всегда можете проверить. Если ваш алгоритм распределяет и освобождает память, то часть контроля в процессе управления памятью он уступает среде выполнения, но вы по- прежнему можете быть достаточно уверены в том, что сохраняете контроль над всей системой. Такая ситуация в значительной мере соответствует замкнутой системе, поведение которой является для вас полностью предсказуемым.

■ Кооперативные вычисления совместно с операционной системой. При написании кода, взаимодействующего со средой выполнения и операционной системой, вы уступаете им несколько больше контроля в обмен на получение расширенных услуг с их стороны. В качестве типичного примера можно привести представление пользовательского интерфейса на современных вычислительных устройствах; пользовательский интерфейс является результатом совместной работы кода приложения и операционной системы. Базовая операционная система и среда выполнения приводят пользовательский интерфейс в действие и посылают вашему приложению события и сообщения, когда происходит нечто, что может представлять для него интерес. При разработке такого класса систем вы уже не располагаете возможностями столь полного контроля, как в случае замкнутых систем; теперь вы имеете дело с кооперативной системой, в которой комфортные условия работы пользователя обеспечиваются совместными усилиями вашего приложения и среды выполнения. Хотя вы и не можете точно сказать, что именно происходит в операционной системе, но вы все еще в состоянии делать достаточно надежные предположения относительно того, как будет вести себя приложение в целом. Например, в то время как ваше приложение уступает контроль над низкоуровневыми деталями функционирования пользовательского интерфейса, можно достаточно уверенно говорить о том, что оно по-прежнему сохраняет полный контроль над всем, что происходит с интерфейсом, и не разделяет этот ресурс ни с какими другими приложениями.

■ Кооперативные вычисления совместно с другими приложениями, выполняющимися на том же устройстве. Ваше мобильное приложение обладает полным контролем над своим пользовательским интерфейсом постольку, поскольку операционная система и среда выполнения устанавливают логические границы между индивидуальными ресурсами различных приложений; мое — это мое, а ваше — это ваше. Когда приложение начинает работать с глобальными ресурсами устройства, например, локальными файлами или базами данных, оно должно учитывать, что не только оно одно может использовать эти ресурсы. Роль честного посредника, распределяющего эти ресурсы, играет операционная система, но она не может гарантировать вашему приложению права исключительного полного доступа к данному ресурсу в любой момент времени. Кроме того, существует вероятность превышения допустимых пределов расхода ресурсов; например, если другие приложения исчерпали все доступное пространство файловой системы, то в вашем приложении должны быть предусмотрены адекватные способы выхода из подобных ситуаций. При работе с разделяемыми ресурсами очень важно предусматривать в коде соответствующие защитные меры, исходя из того непреложного факта, что любая попытка доступа к разделяемому ресурсу может оказаться неудачной. Необходимо также продумать, что будет происходить в тех случаях, когда к ресурсу будут пытаться получить доступ одновременно несколько приложений; одни типы ресурсов разрешают лишь одиночный доступ, другие допускают параллельный доступ, но не гарантируют согласования данных в процессе обновлений, тогда как третьи обеспечивают атомарное выполнение операций чтения и записи данных. Понимание поведения глобальных ресурсов устройства в условиях состязательного доступа к ним играет очень важную роль в обеспечении устойчивой работы приложения.

■ Кооперативные вычисления с интенсивным использованием сети. Если ваше приложение зависит от услуг, предоставляемых по сети, то появляются два дополнительных источника потенциальной неустойчивости. Доступ к сетевым ресурсам может оказаться невозможным из-за неготовности компьютера на другом конце сети к совместной работе. Что-то может нарушиться из-за того, что одно из звеньев сетевой цепочки, соединяющей два компьютера между собой, может повести себя не так, как ожидалось.

Ситуацию дополнительно осложняет тот факт, что сбой сетевых ресурсов может происходить во время сеанса связи; в случае локальных взаимодействий в пределах устройства такое происходит очень редко. Например, хотя наступление сбоя в процессе чтения из локальной файловой системы и возможно, но вероятность этого пренебрежимо мала; жесткий диск может разрушиться, но такое случается крайне редко, и если это произойдет, то у вас возникнут более крупные проблемы, чем просто невозможность считать данные из файла. Вероятность таких сбоев настолько мала, что многие операционные системы регулярно выполняют локальные операции чтения/записи, даже не уведомляя об этом выполняющиеся поверх операционную систему приложения. При чтении файлов через сеть вероятность возникновения сбоев в процессе выполнения этой операции резко возрастает, что часто наблюдается в случае беспроводных сетей и становится еще более заметным, если при чтении файлов мобильным устройством требуется осуществлять сетевой роуминг. Сбои не обязательно происходят постоянно, но случаются настолько часто, что к этому надо быть готовым и заранее предусматривать принятие соответствующих мер.

Ниже приводятся рекомендации по созданию отказоустойчивых сетевых мобильных приложений.

Не допускайте того, чтобы работа приложения всецело зависела от возможности подключения к сети

Точно так же как группа людей, действующих согласованно, может достигнуть гораздо большего, чем один человек, действующий в одиночку, возможности мобильного приложения, взаимодействующего с окружающими его сетями, намного превышают возможности изолированного приложения. Чтобы группа людей в некоторой организации могла успешно справляться с поставленными задачами, должны быть предусмотрены меры, позволяющие корректно разрешать ситуации, соответствующие перебоям в связи между членами группы и перебоям в работе каждого из них. Ни одно звено взаимодействия не должно быть критическим, иначе при его сбое наступит сбой в работе организации в целом. То же самое справедливо и в случае мобильных устройств.

Мобильные устройства значительно выигрывают от взаимодействия с внешним миром, но они никогда не должны всецело зависеть от такого рода взаимодействий. Несмотря на всю очевидность этой истины, ею часто пренебрегают.

Каждая удачная попытка доступа к сетевым ресурсам должна рассматриваться в вашем приложении скорее как счастливая случайность, а не как закономерная необходимость. Для большинства мобильных устройств сеансы взаимодействия с сетью осуществляются "почти по требованию" в том смысле, что хотя пользователь мобильного приложения, как правило, и может перейти в то физическое место, где сеть является доступной, но он не может рассчитывать на то, что устройство сможет оставаться постоянно подключенным к сети. В этом отношении мобильные устройства значительно отличаются от настольных компьютеров, имеющих постоянное кабельное подключение к сети, и лэптопов, подключение которых к сети в условиях стационарной работы не составляет большого труда. Если увидеть человека, склонившегося над клавиатурой своего лэптопа в зале ожидания железнодорожного вокзала, можно не так уж часто, то людей, манипулирующих клавишами своих мобильных телефонов, на том же вокзале встретится довольно много. И хотя количественные оценки этих показателей могут колебаться в зависимости от обстоятельств, различия между обеими ситуациями налицо.

Следствием подхода, в соответствии с которым сетевой доступ необходимо рассматривать лишь как нерегулярный, являются две полезные рекомендации, касающиеся проектирования мобильных приложений:

1. Полезные данные необходимо загружать и кэшировать заблаговременно, когда доступно сетевое соединение. Очень важно определить, какие виды информации будут наиболее полезными для вашего приложения при его работе в автономном режиме, и сделать все для того, чтобы соответствующие данные были заблаговременно загружены и доступны, когда в них возникнет потребность. В то время как при работе с локальными ресурсами устройства целесообразно откладывать их размещение в памяти до тех пор, пока они не потребуются, информацию, хранящуюся вне устройства, целесообразно заранее загружать и накапливать, чтобы подготовиться к работе приложения в автономном режиме. Например, подключение к локальной базе данных устройства может быть отложено до момента, когда в этом возникнет действительная необходимость. В отличие от этого, нужные данные следует загружать из внешней базы данных заблаговременно, когда будет доступно соединение с сетью. В идеальном случае загрузка данных должна выполняться как фоновая задача, которая не блокирует пользовательский интерфейс. Кроме того, предварительная загрузка информации позволяет существенно повысить производительность приложения, особенно в тех ситуациях, когда приложению или пользователю эти данные требуются часто, но иначе их пришлось бы каждый раз загружать по требованию.

2. Организуйте очередь данных, подлежащих выгрузке, и выгружайте их, как только становится доступным сетевое соединение. При работе с локальными приложениями пользователи устройства хотят ощущать их обратную реакцию. Если для обновления данных приложению, выполняющемуся на мобильном телефоне, требуется установить соединение с сервером, то это может сопровождаться определенной задержкой, и пользователь будет чувствовать себя неуверенно. Гораздо лучше организовать надежную очередизацию обновлений на клиенте и предложить пользователю пакетную выгрузку обновляемых данных на сервер, осуществляемую автоматически или вручную в те периоды времени, когда это становится возможным. Код, с помощью которого выполняется выгрузка данных, также должен быть достаточно отказоустойчивым, чтобы в случае невозможности установления надежного соединения с сервером эту работу можно было отложить на более позднее время.

Два примера коммуникационных стратегий

Синхронизация данных расписания встреч, списка контактов и электронной почты, хранящихся на мобильном устройстве

Хорошим примером применения двух описанных выше принципов является модель синхронизации, используемая Microsoft на устройствах Smartphone и Pocket PC Phone. На устройствах обоих типов имеется приложение электронной почты, допускающее периодическую синхронизацию электронной почты, данных расписания встреч (календаря) и списка контактов с сервером обмена сообщениями Exchange Server.

Запросы и предпочтения различных пользователей в отношении синхронизации этих данных различны. С целью минимизации потока данных мобильные приложения предоставляют пользователям возможность задавать, какие виды данных подлежат локальной синхронизации на устройстве. Например, я могу решить, что мне необходима синхронизация только расписания встреч и списка контактов, оставляя задачу синхронизации электронной почты для своего лэптопа. Можно также ограничивать объем синхронизируемой информации, указав, например, что данные обо всех предстоящих встречах должны синхронизироваться полностью, тогда как синхронизация данных о прошлых встречах должна охватывать информацию не более чем 2-недельной давности, а при загрузке электронных сообщений должны загружаться только первые 3 Кбайт данных.

Развернутое на устройстве приложение для работы с электронной почтой, информацией о контактах и расписанием встреч позволяет также указывать, с какой периодичностью и в каком режиме должна осуществляться синхронизация — автоматически или вручную. Наиболее подходящие для каждого пользователя установки определяются видом синхронизируемых данных и потребностями в их обновлении. У большинства пользователей расписание встреч изменяется реже, чем появляются новые входящие электронные сообщения, а список контактов изменяется еще реже. Лично я предпочитаю синхронизировать данные во время поездок на работу и с работы и, если это необходимо, на протяжении рабочего дня; другие люди, насколько мне известно, предпочитают синхронизировать свои данные чаще, используя автоматическое обновление. Модель синхронизации в значительной степени определяется тем, какой режим использования приложения является для пользователя привычным.

Для синхронизации этой информации устройства используют специальную службу, которая называется ActiveSync. Механизм ActiveSync периодически устанавливает через мобильную сеть соединение с Internet для подключения пользователя к серверу Exchange Server и последующей синхронизации данных. Процесс синхронизации состоит из двух операций:

1. Загрузка всех пакетных обновлений. Синхронизируются все локальные изменения, связанные с расписанием встреч, электронной почтой и списком контактов.

2. Загрузка данных, удовлетворяющих условиям локального фильтра. Соответствующим образом загружается информация о новых встречах и контактных лицах, а также заголовки электронной почты.

Эта модель позволяет сохранять разумный баланс между объемом обновляемых данных и пропускной способностью сети. Если бы информация о назначенных встречах загружалась по запросу индивидуально для каждой даты при ее выборе пользователем в календаре своего мобильного устройства, то во многих случаях сделать это было бы невозможно из-за отсутствия соединения с мобильной сетью или выключения сервера электронной почты. Но даже и при наличии соединения пользователь испытывал бы значительные неудобства от задержек при доступе к данным или их выгрузке. С другой стороны, если бы во время синхронизации с сервера загружалась вся возможная информация, то это происходило бы слишком медленно и неэффективно с точки зрения использования полосы пропускания. Совершенно очевидно, что достижение необходимого баланса указанных факторов требует вмешательства пользователя

Хорошо продуманное кэширование данных на устройстве, разумное их обновление в соответствии с потребностями пользователя и предоставление пользователю возможности самостоятельно определять, когда и какие именно данные должны синхронизироваться, создает все предпосылки для нормальной работы, не сопровождающейся неожиданными сбоями.

Отправка и получение SMS-сообщений с помощью мобильного телефона

SMS-сообщения — это короткие текстовые сообщения, пересылаемые между мобильными телефонами. SMS — многообещающая технология, используя которую пользователи мобильных телефонов могут легко обмениваться между собой несколькими строками текста. Устанавливая фиксированную плату за пересылку одного сообщения, операторы сетей мобильной связи получают огромные прибыли за счет предоставления лишь узкой полосы пропускания; SMS-сообщения с побитовой оплатой гораздо прибыльнее речевой связи! Таким образом, приложения для обработки SMS — это приложения-приманки, и вряд ли можно сомневаться в том, что изготовители мобильных телефонов и операторы сетей мобильной связи постарались отладить эту технологию идеальным образом.

Обмен SMS-сообщениями обладает одним большим достоинством и одним большим недостатком:

1. Преимущества SMS: разделение передачи и приема сообщений. Если SMS-сообщение пересылается с одного мобильного телефона на другой, то телефон, принимающий сообщение, во время его передачи не обязан быть подключенным к сети. Если вы совершаете перелет через Атлантику, и в этот момент кто-то отправляет вам SMS-сообщение, инфраструктура сети мобильной связи поместит сообщение в очередь на своих серверах и доставит его вам, когда вы приземлитесь и включите свои мобильный телефон. Точно так же будут развиваться события и в том случае, если принимающий телефон находится вне зоны досягаемости поскольку его владелец в данный момент находится в метро, лифте или катается на лыжах на той части склона, которая скрыта от сотового передатчика. По указанным причинам данный механизм прекрасно подходит для отправки кратких текстовых сообщений наподобие: "Встретимся в Лонгхорн Грилл в 17:00. Иво". Отправитель и получатель могут общаться между собой краткими предложениями, не соединяясь друг с другом.

2. Недостаток SMS: немые клиентские приложения, не имеющие возможности кэшировать сообщения в автономном режиме. В настоящее время большинство мобильных приложений не имеют автоматизированного механизма очередизации исходящих SMS-сообщений. Когда пользователь набирает сообщение и пытается его отправить, делая это обычно несколько раз, то при отсутствии доступа к сети сообщение не может быть отправлено. Эта ситуация служит примером модели синхронного приложения, в котором попытка соединения осуществляется немедленно и завершается либо удачно, либо неудачно, прежде чем управление возвращается пользователю. Гораздо более эффективной является модель клиентского приложения в соответствии с которой предпринимается попытка синхронной отправки сообщения, и если сделать это немедленно не удается, то сообщение помещается в очередь исходящих сообщений, отсылка которых будет произведена тогда, когда доступ к сети будет восстановлен. Когда SMS-сообщение, в конце концов, поступит на сервер, пользователь, отправивший сообщение, может быть извещен об этом по телефону.

Как и в предыдущем примере, отсюда можно извлечь важные уроки. Вы не задумывались над тем, почему в современных мобильных телефонах на клиентской стороне SMS-технологии действует подобное ограничение? Объясняется это тем, что создать асинхронную коммуникационную модель значительно сложнее; это требует написания для клиентской стороны логики, которая будет осуществлять фоновую отправку SMS- сообщений, обрабатывать повторные попытки отправки сообщений и формировать очередь исходящих сообщений, а в довершение всего неплохо было бы также предоставить пользовательский интерфейс, который после окончательной отправки SMS- сообщений, помещенных в очередь, известит об этом пользователя. Модели приложений, используемые предыдущими поколениями мобильных телефонов, отличались сравнительной простотой, и создание подобного рода систем считалось неоправданным, ибо вносило дополнительные сложности. Однако современные мобильные телефоны располагают как более мощными пользовательскими интерфейсами, так и моделями приложений, облегчающими выполнение фоновой обработки. Поэтому разумно предположить, что операционные системы и приложения будущих поколений мобильных телефонов будут поддерживать кэширование исходящих SMS-сообщений точно так же, как многие нынешние телефоны поддерживают синхронизацию с сервером кэшируемых исходящих сообщений электронной почты, контактной информации и расписания встреч.

Не допускайте того, чтобы поток пользовательского интерфейса блокировался на длительное время

По самой своей природе взаимодействие является синхронной операцией; ваше мобильное приложение должно передать некоторый блок данных на сервер или принять блок данных с сервера, причем для перемещения этого блока данных требуется некоторое время. Поскольку длительность прохождения данных до сервера, настольного компьютера или иного внешнего устройства ваше приложение непосредственно контролировать не может, важно не выполнять такого рода операции в том же потоке, в котором выполняется пользовательский интерфейс вашего приложения.

Разработчики приложений очень часто допускают ошибку, суть которой состоит в том, что для всех создаваемых коммуникационных систем сначала предусматривается их выполнение потоком пользовательского интерфейса в синхронном режиме, которое планируется заменить на более поздних стадиях разработки приложения выполнением коммуникационных задач фоновыми потоками. Как правило, такой подход не приводит к удовлетворительным результатам. Существует несколько причин, по которым разработчики попадают в эту ловушку:

■ Синхронные взаимодействия проще проектировать и отлаживать. Это истинная правда. Проектировать и отлаживать логику приложения, которая выполняется в синхронном режиме, значительно проще. По этой причине действительно рекомендуется, чтобы вы проектировали и отлаживали коммуникационную логику, выполняя ее синхронно с логикой пользовательского интерфейса вашего приложения. Коммуникационные процедуры, которые вы пишете, должны быть синхронными функциями. Однако, как только эти коммуникационные функции написаны, и их основная функциональность прошла тестирование, необходимо немедленно организовать их асинхронное по отношению к логике пользовательского интерфейса выполнение.

■ Синхронный код пишется гораздо быстрее. И это правда. Когда перед вами маячат сроки контрольного этапа, очень легко убедить себя в том, что единственный способ закончить работу вовремя — это срезать углы, организовав выполнение коммуникационной логики синхронно с выполнением логики пользовательского интерфейса.

■ Коль скоро мы не забываем о необходимости осуществления коммуникаций в асинхронном режиме и предусматриваем это в проекте приложения, то организовать впоследствии обмен данными в асинхронном режиме не составит никакого труда. Это — заблуждение. Несомненно, если вы не забываете о том, что, в конечном счете, коммуникационные операции должны будут выполняться асинхронно, то это облегчит вам переориентирование написанных вами функций синхронной связи на асинхронный режим выполнения в будущем, но одного этого еще мало. Истина состоит в том, что, как бы вы ни старались это предотвратить, в код, использующий синхронные процедуры, будут "намертво" встроены синхронные зависимости. Человек просто не в состоянии уследить за всеми неявными допущениями, которые вплетаются в логику приложения, и устранить возникающие из-за этого проблемы на более поздних этапах разработки приложения вам будет очень трудно.

Наилучшая методология проектирования коммуникационного кода, который должен обеспечивать постоянную способность пользовательского интерфейса к отклику, заключается в том, чтобы следовать приведенным ниже четырем рекомендациям:

1. Проектируйте свои коммуникационные процедуры в виде отдельных, надежно инкапсулированных функций. Лучший способ подготовить коммуникационные процедуры к асинхронному выполнению — это надежно их инкапсулировать. Коммуникационная процедура, которая пересылает данные на сервер, должна передавать статическую копию этих данных; для получения этих данных функции не должен требоваться доступ к каким-либо глобальным либо разделяемым состояниям. Аналогичным образом, коммуникационная процедура, осуществляющая считывание данных с сервера, не должна изменять никакое глобальное состояние приложения, пока не прочитает все данные. Очень важно соблюдать эти принципы, поскольку одновременная работа двух потоков с одним и тем же глобальным состоянием приложения — это верный путь к дополнительным сложностям, разрушению данных и снижению надежности приложения. Поток пользовательского интерфейса должен иметь исключительный доступ к данным, с которыми он работает, коммуникационным процедурам должна предоставляться копия этих данных, а взаимодействие между обеими системами должно осуществляться лишь в строго определенных и надежно протестированных точках.

2. Тестируйте коммуникационные процедуры, вызывая их в синхронном режиме. Как уже отмечалось ранее, тестировать и отлаживать коммуникационный код намного проще, если он выполняется в синхронном режиме потоком пользовательского интерфейса. По этой причине гораздо целесообразнее сначала выявить все ошибки в коде, выполняющемся синхронно с пользовательским интерфейсом, и лишь после этого переходить к тестированию кода при его выполнении фоновым потоком. Я рекомендую вам помещать на форму большую кнопку с надписью "Тестировать и сохранить код" и использовать ее для тестирования и отладки своих коммуникационных процедур. Причина, по которой я рекомендую использовать именно "большую кнопку", заключается в том, что такая кнопка выглядит уродливо и бросается в глаза, так что вы никогда не забудете удалить ее.

3. Ужесточайте условия тестирования своих коммуникационных процедур, вызывая их в асинхронном режиме в намеренно затрудненных ситуациях, используя тестовое приложение. Код, выполняемый фоновым потоком, всегда оказывается сложнее синхронно вызываемого кода. Кроме того, отслеживать все тонкие разновидности повреждения данных и логические ошибки в управлении состоянием, возникающие в условиях, когда несколько различных потоков взаимодействуют между собой самым непредсказуемым образом, весьма нелегко, что дополнительно осложняется наличием многофункционального кода приложения, который окружает отлаживаемый код. Лучший способ создания действительно надежных систем — это жесткое тестирование кода в упрощенном окружении, предназначенном для помещения кода в специально осложненные состояния, и мониторинг выполнения кода для выявления необычных ситуаций. Целесообразно создать специальное приложение, в котором несколько потоков кода выполняются асинхронно, и тщательно исследовать внутреннее состояние приложения для выявления любых возможных неожиданных результатов. Тестирование такого рода может указать вам на необходимость введения некоторых ограничений в выполняемый код, которые не позволят приложению переходить в состояния повышенного риска; так, код, предназначенный для выполнения фоновой задачи, может активно препятствовать выполнению нескольких экземпляров этой задачи параллельными потоками, если вы обнаружили, что надежность такого выполнения является проблематичной, а использование многопоточности не является обязательным. Тестированный, усовершенствованный и отлаженный подобным образом код можно включать в код приложения с гораздо большей уверенностью, нежели код, который считается заведомо корректным исключительно на основании голого оптимизма.

4. Проведя тестирование кода, немедленно преобразуйте коммуникационные процедуры, чтобы они могли выполняться в рабочем фоновом потоке вашего приложения. После отладки базового коммуникационного кода в синхронном режиме и его тестирования в асинхронном режиме он будет готов к помещению в асинхронную операцию, выполняемую в вашем приложении. Приложение должно основываться на понятной и согласованной модели выполнения кода рабочим фоновым потоком, и эту же модель следует применять для всех ваших асинхронных коммуникационных потребностей. Эту модель асинхронного выполнения всегда необходимо использовать и при встраивании коммуникационного кода в пользовательский интерфейс приложения. Не встраивайте синхронные вызовы коммуникационных процедур в пользовательский интерфейс, планируя впоследствии, когда у вас появится время, преобразовать их для выполнения в асинхронном режиме; чем больше кода вы сюда поместите, тем больше зависимостей будет создано.

Как правило, гораздо проще взять в качестве исходной асинхронную систему и выполнять ее в синхронном режиме, чем поступать наоборот. Чтобы синхронно выполнить асинхронную систему, ваше приложение должно просто вызвать асинхронный код и начать выполнять цикл ожидания, выход из которого и выполнение дальнейшего кода осуществляются после завершения выполнения асинхронного кода. Чтобы превратить синхронное взаимодействие в асинхронное, вы должны идентифицировать все состояния приложения, которые затрагиваются коммуникационными процедурами, и создать отдельные копии этих данных, вы должны создать модель для фонового выполнения, из которой будет вызываться код, вы должны перепроектировать способ, используемый коммуникационным кодом для взаимодействия с элементами пользовательского интерфейса, поскольку организовать надежный доступ к элементам управления пользовательского интерфейса из других потоков во многих случаях невозможно (эта ошибка, несомненно снижающая надежность приложения, является весьма распространенной при использовании .NET Compact Framework! Для организации взаимодействия с элементами управления пользовательского интерфейса из других потоков следует использовать вызов метода <ЭлементУправления>.Invoke()), вы должны разработать способ уведомления пользовательского интерфейса о возникновении проблем в процессе информационного обмена, вы должны предусмотреть корректную обработку сбойных ситуаций и, наконец, вы должны разработать модель для обмена командами и состояниями между пользовательским интерфейсом и коммуникационным кодом. Сделать все это уже после того, как разработка приложения почти закончена, очень трудно, и любые попытки преобразования синхронных операций в асинхронные в мобильном приложении потребуют, по крайней мере, существенных переделок и, как правило, привнесут в ваше приложение логические ошибки и сделают его работу ненадежной. С самого начала проектируя код, с помощью которого осуществляется информационный обмен с внешними источниками информации, в асинхронной форме, вы получите намного более удовлетворительные результаты.

НА ЗАМЕТКУ

Выполнение кода в фоновом потоке обсуждается в главе 9.

Работайте на самом высоком уровне абстракции, который соответствует вашим потребностям

Как и в случае кода для настольных компьютеров и серверов, целесообразно работать на самом высоком из допустимых уровней абстракции.

Например, если в процессе работы с Internet-протоколами у вас есть возможность работать на уровне Web-служб, используя запросы/ответы SOAP, то именно так вам и следует поступить; встроенные абстракции позволят вам сэкономить массу времени, превращая ваши Web-запросы в простые вызовы методов. Если для повышения производительности приложения или в интересах его пользовательской адаптации вам необходимо спуститься вниз на один уровень, то запросы и ответы HTTP или HTTPS обеспечат вам довольно высокий уровень абстракции и, как правило, дружественность по отношению к брандмауэрам. Если окажется, что запросы/ответы HTTP не в состоянии удовлетворить ваши потребности, у вас есть возможность использовать средства коммуникации на уровне сокетов и создаваемые поверх сокетов потоки.

Работа на уровне абстракции сокетов усложняет код, поскольку для взаимодействия с серверами вам придется спроектировать собственные коммуникационные протоколы, а не использовать простые и надежно тестированные механизмы запросов/ответов HTTP. Если ваше приложение должно связываться с сервером, который требует взаимодействия на уровне сокетов, то рекомендуется рассмотреть возможность создания прокси-компонента на стороне сервера, который взаимодействовал бы с интерфейсом сокета и, в свою очередь, предоставлял вашему приложению интерфейс HTTP или Web-служб. Поскольку взаимодействие сервера с сервером обычно характеризуется более высокой надежностью по сравнению с взаимодействием между устройством и сервером, то описанная мера позволяет значительно упростить код на стороне устройства и повысить надежность вашего мобильного приложения.

Работать на коммуникационных уровнях ниже уровня сокетов, а также непосредственно использовать стек протоколов TCP/IP имеет смысл лишь в крайних случаях. Если вашему приложению необходимо организовать информационный обмен на этом уровне, то для работы с протоколами вам, вероятнее всего, придется написать большой объем собственного кода на языке С. Дополнительная сложность кода и необходимость его тщательного тестирования почти никогда не стоят того выигрыша, который от этого получит приложение. Высокоуровневые протоколы надежно тестируются, и для того чтобы обеспечить ту же степень надежности при использовании собственных коммуникационных протоколов, вам надо будет проделать невероятно большой объем работы. То же самое справедливо и в отношении протоколов, отличных от протокола TCP/IP; возможно, протокол TCP/IP и не является самым идеальным коммуникационным механизмом для всех задач, но обеспечить своими силами тот же уровень тестирования и надежности кода, что и для этих стеков протоколов, очень трудно. Если только вы не намереваетесь предложить совершенно новый коммерческий протокол, проектирование и тестирование которого потребуют от вас огромных усилий, то нет никакого резона заново изобретать колесо, пытаясь получить идеальный протокол, который будет использоваться исключительно для ваших собственных нужд. Использовать 80% вполне пригодного "колеса", которое уже существует и прошло многолетнее тестирование, намного лучше, чем пытаться создать новое "колесо" самому. Прежде чем приниматься за изобретение нового коммуникационного протокола или переходить на использование более низкого уровня в стеке коммуникационных протоколов, вы должны удостовериться в том, что существующие высокоуровневые коммуникационные протоколы не в состоянии удовлетворить запросам вашего мобильного приложения.

Всегда исходите из того, что связь может быть нарушена в любой момент

При написании коммуникационного кода ключевую роль должно играть обеспечение его отказоустойчивости. Традиционные коммуникационные технологии часто описываются в виде многоуровневого стека, который начинается физическим уровнем, далее содержит канальные уровни и уровни протоколов и заканчивается уровнем приложения. Большинство этих уровней аналогичным образом работают и на мобильных устройствах. Как правило, для каждого уровня предусмотрены встроенные средства повышения отказоустойчивости, вызываемые при обнаружении ошибок или возникновении незначительных сбоев в процессе связи. В большинстве случаев вам не следует беспокоиться о специфике нижних коммуникационных уровней; ситуация здесь в значительной степени та же, что и при написании кода для настольных компьютеров и серверов. Единственное различие состоит в том, что в мобильных сетях нарушения связи случаются чаще, чем в кабельных или стационарных беспроводных сетях.

При написании отказоустойчивого коммуникационного кода очень важно тщательно следить за тем, как освобождаются ресурсы в случае возникновения каких-либо нарушений нормального режима работы. Организация связи представляет собой сложный процесс, включающий многоступенчатое установление множества соединений и распределение системных ресурсов. В случае возникновения сбоев в процессе связи важно вовремя освободить системные и иные ресурсы, удерживаемые вашим приложением, а если вы используете .NET Compact Framework, то обязательно осуществите профилактический вызов метода Dispose() для освобождения тех ресурсов, которые поддерживают данный метод.

Вызов метода Dispose() имеет очень большое значение, поскольку это приводит к немедленному освобождению соответствующих системных ресурсов еще до того, как сборщик мусора закроет ненужные дескрипторы и освободит заблокированные ресурсы. В данной ситуации вам может очень пригодиться ключевое слово С# using (например, using(myObject) {...ваш код...}), поскольку его использование гарантирует вызов метода Dispose() не только в случае успешного выполнения определяемого им блока кода, но и при возникновении исключений в этом блоке. Важно отметить, что некоторые классы .NET, такие как System.Net.Sockets.Socket, не имеют общедоступного метода Dispose(), однако для них предусмотрен метод Close(), который и следует вызывать для освобождения ресурсов, удерживаемых объектом. Вы должны внимательно изучить имеющуюся документацию по всем коммуникационным объектам, которые используете, чтобы иметь полную уверенность в том, что все правила и процедуры, используемые для восстановления ресурсов этих объектов, вам понятны.

Если при обработке сбойных ситуаций вы непреднамеренно оставите ресурсы открытыми, то тем самым создадите предпосылки для сбоя при последующей попытке установления соединения. Если необходимые операции по закрытию ресурсов не выполнены, то разрыв сетевого соединения в результате сбоя, вероятнее всего, приведет к ситуации, в которой последующие попытки установления соединения окажутся неудачными, поскольку необходимый локальный ресурс перед этим был оставлен открытым в состоянии исключительного доступа и поэтому не может быть повторно открыт.

Последующие попытки восстановления связи окажутся неудачными даже после восстановления соединения с физической сетью. В этом отношении мы имеем дело с той же ситуацией, какая возникает и при написании кода для настольных компьютеров и серверов, если не считать того, что нерегулярные сетевые сбои чаще всего происходят тогда, когда устройство является одновременно и мобильным, и беспроводным. Таким образом, обработке сбойных ситуаций необходимо уделять больше внимания, поскольку такие ситуации возникают чаще.

Коммуникационные классы могут предоставлять и другие функции, используемые для освобождения ресурсов, вызов которых может оказаться необходимым для корректного выхода из сбойной ситуации.

Если канал связи необходимо закрывать вручную, обеспечьте вызов соответствующего метода Close() или Dispose(), поместив этот вызов в интерфейсную оболочку, предназначенную для обработки ошибок в случае возникновения сбоев. Сбои в работе вашего приложения могут быть обусловлены не только разрывом соединения, но и другими причинами, например, несоответствием результатов синтаксического анализа ответа сервера тому, что ожидается вашим код. В зависимости от вида приложения и используемых сетевых служб может оказаться важным соблюдение определенной процедуры завершения связи. Так, если ваше приложение связывается с пользовательской службой через сокеты, и при этом используется понятие входа и выхода из системы, то при входе приложения в непредвиденные состояния очень важно завершить сеанс связи корректным образом. Может оказаться так, что вместо простого вызова метода Close() ваше приложение сначала должно будет завершить сеанс связи, послав на сервер команду выхода из системы и вызвав метод Shutdown() для сокета, и только после этого вызвать метод Close(). Очень важно хорошо понимать особенности установления и разрыва соединений с теми службами, которые используются вашим приложением.

Возбуждение и перехват исключений, которые могут приводить к образованию висячих соединений, и проблемы производительности

Под "исключениями" понимается следующее: это исключительные обстоятельства, которые должны обрабатываться средой выполнения и кодом приложения. Возбуждение (или, другими словами, генерация) исключения запускает в среде выполнения сложный процесс, сопровождающийся развертыванием стека для поиска обработчиков исключений, уничтожением локальных переменных и другими операциями, связанными с большими накладными расходами. С точки зрения производительности этот процесс, как правило, требует больших вычислительных ресурсов по сравнению подходом, в котором отказываются от возбуждения исключений и вместо этого заблаговременно выявляют условия, которые могут приводить к возникновению ошибок. Как и в случае других аспектов производительности, окончательным критерием всегда должны служить результаты количественных экспериментов. Кроме того, поскольку возбуждение исключений нарушает обычный порядок выполнения операций в вашем приложении, может оказаться так, что важные операции, связанные с освобождением коммуникационных ресурсов, не будут выполнены. В результате этого часть коммуникационных ресурсов может остаться в "зависшем" состоянии, что может стать причиной дополнительных проблем в процессе дальнейшего выполнения приложения.

В самой идее использования обработки исключений в приложении нет ничего плохого, однако важно понимать, при каких обстоятельствах этого делать не следует. Никакие исключения не должны возбуждаться и обрабатываться в процессе нормального выполнения приложения. Нецелесообразно использовать в приложении код, генерирующий и обрабатывающий исключения, лишь для того, чтобы контролировать возникновение самых обычных ситуаций в ходе выполнения приложения, поскольку это приведет к неэффективным тратам вычислительных ресурсов и усложнению программы. При малейшей возможности старайтесь контролировать состояние информационного обмена с помощью обычного кода, а не посредством механизма возбуждения и обработки исключений. Если обработчики исключений запускаются при нормальном выполнении приложения, то первое, что вы должны сделать — это проанализировать код и посмотреть, нельзя ли организовать дополнительные логические проверки, при помощи которых можно было бы предотвратить возбуждение этих исключений.

Пример сравнения возможностей механизма исключений и обычного алгоритмического кода можно найти в главе 7

В листинге 15.1 представлен простой пример файлового ввода-вывода, иллюстрирующий некоторые различия между сбойными ситуациями, возникающими при обращении к локальным и удаленным файлам. Хотя вы и можете поместить этот код в форму мобильного приложения и запустить его на выполнение, вряд ли стоит это делать; этот листинг приведен в основном лишь для того, чтобы вы его изучили. Как видно из приведенных в коде комментариев, в случае доступа к серверу вероятность сбоя повышается не только для операции открытия файла, но и для файловых операций чтения/записи, что связано с возможностью потери доступа к сети. Вероятность сбоя повышается с увеличением количества коммуникационных уровней, отделяющих ваше устройство от данных, к которым оно пытается обратиться. Если используется беспроводная сеть, то сигнал может быть утерян вследствие перемещения устройства. Если доступ к данным осуществляется посредством виртуальной частной сети через брандмауэр, то сбой на данном сервере может наступить в любой момент. Если соединение проходит через сеть мобильной связи, то сбой может наступить по вине мобильной сети. Несмотря на то что каждый из этих уровней сам по себе может быть надежным, их объединение повышает вероятность сбоя. Поэтому при попытках переноса кода из систем с локальным доступом к файлам в системы, использующие доступ к удаленным серверам, следует быть очень внимательным. В коде, ориентированном на локальный доступ к файлам, могут быть заложены предположения, которые при доступе к удаленным источникам станут причиной сбоев. Чтобы этого не произошло, рекомендуется применять следующие меры предосторожности:

1. Помещайте код доступа к удаленным серверам в блоки try/catch. Любая операция, для выполнения которой требуется удаленное соединение, может закончиться сбоем. Все блоки кода, которые осуществляют доступ к ресурсам, расположенным вне устройства, необходимо помещать в блоки try/catch, которые будут обрабатывать сбойные ситуации.

2. При информационном обмене с удаленными источниками данных старайтесь укладываться в короткие сеансы связи и по окончании работы сразу же закрывайте соединение. Чем дольше вы держите открытыми удаленный сокет, файл, соединение с базой данных или иной удаленный ресурс, тем больше вероятность сбоя. Поэтому очень важно аккуратно инкапсулировать весь коммуникационный код, который открывает соединение, выполняет необходимую работу и закрывает соединение, прежде чем будет продолжено выполнение другой работы. Весьма неразумно оставлять в подвешенном состоянии открытые соединения с сетевыми ресурсами.

Листинг 15.1. Простой код файлового ввода-вывода, иллюстрирующий различия между локальной и удаленной передачей данных

private void button1_Click(object sender, System.EventArgs e) {

//Запись в локальный файл

WriteFile("\\testfile.txt");

//Замените имя сервера (MyFileServer) именем своего сервера

//и удалите символы комментария.

//Запись в файл, находящийся в общей сетевой папке (MyFileShare) на сервере:

//"\\MyFileServer\MyFileShare"

//WriteFile("\\\\MyFileServer\\MyFileShare\\testfile.txt");

System.Windows.Forms.MessageBox.Show("Success");

}

private void button2_Click(object sender, System.EventArgs e) {

//Чтение из локального файла

int numberLinesInFile;

numberLinesInFile = CountNumberLinesInFile("\\testfile.txt");

//Отобразить количество считанных строк

System.Windows.Forms.MessageBox.Show(

"Successfully read file " + numberLinesInFile.ToString() + " Lines.");

//Замените имя сервера (MyFileServer) именем своего сервера

//и удалите символы комментария.

/* //Записать файл из общей сетевой папки:

//"\\MyFileServer\MyFileShare"

numberLinesInFile = CountNumberLinesInFile(\\\\MyFileServer\\MyFileShare\\testfile.txt);

//Отобразить количество считанных строк

System.Windows.Forms.MessageBox.Show(

"Successfully read file " + numberLinesInFile.ToString() + " Lines.");

*/

}

private void WriteFile(string filename) {

//----------------------------------------------------------------------

//СОЗДАНИЕ ФАЙЛА:

//

//Для локальных файлов:

// Сбой может возникнуть, если:

// 1. Файл уже существует, и мы не можем осуществить запись поверх него.

// 2. Отсутствует свободное место в файловой системе.

//

//Для файлов на сервере:

// Сбой может возникнуть по вышеперечисленным причинам, а также

// из-за проблем подключения к серверу через сеть,

// проблем безопасности и так далее

//----------------------------------------------------------------------

System.IO.StreamWriter myStreamWriter = System.IO.File.CreateText(filename);

//-------------------------------------------------------------

//ЗАПИСЬ В ФАЙЛ:

//Для локальных файлов:

// Если мы успешно открыли файл, значит, сможем осуществить

// в него запись, лишь бы не исчерпали доступное

// дисковое пространство.

//Для файлов на сервере:

// Сбой может возникнуть по вышеперечисленным причинам, а также

// из-за разрыва нашего сетевого соединения с сервером

//-------------------------------------------------------------

myStreamWriter.WriteLine("Hello!");

myStreamWriter.WriteLine("MyTextFile!");

myStreamWriter.WriteLine("GoodBye!");

//----------------------------------------------------------

//ЗАКРЫТЬ ФАЙЛ:

//Аналогично предыдущему, вероятность сбоя при выполнении

//этой операции повышается при доступе к файлу, находящемуся

//в общей сетевой папке

//----------------------------------------------------------

myStreamWriter.Close();

}

private int CountNumberLinesInFile(string filename) {

int numberLinesInput = 0;

//------------------------------------------------------------------

//ОТКРЫТЬ ФАЙЛ:

//Для локальных файлов:

// В случае доступа к локальным файлам устройства можно генерировать

// исключение, если доступ к файлу оказывается невозможным

//Для файлов на сервере:

// В дополнение ко всем вышеперечисленным причинам возможных сбоев

// при открытии локального файла сбои также возможны

// из-за проблем доступа к сети, принятой на сервере

// политики безопасности и так далее

//------------------------------------------------------------------

System.IO.StreamReader myStreamReader = System.IO.File.OpenText(filename);

string inputLine;

//Организовать построчное чтение файла

do {

//--------------------------------------------------------------

//ВВЕСТИ СТРОКУ:

//Для локальных файлов:

// Если файл был успешно открыт, этот вызов

// никогда не завершится сбоем.

//

//Для файлов на сервере:

// Проблемы доступа к беспроводным сетям, с которыми мы можем

// столкнуться при попытке доступа к файлу, повышают вероятность

// сбоя для этого кода и генерации соответствующего исключения

//--------------------------------------------------------------

inputLine = myStreamReader.ReadLine();

//Если не было возвращено значение 'null', то мы

//не достигли конца файла. Увеличить значение счетчика строк.

if (inputLine != null) {

numberLinesInput++;

}

//Продолжать выполнение, пока в файле есть данные для чтения

} while(inputLine != null);

//----------------------------------------------------------

//ЗАКРЫТЬ ФАЙЛ:

//Аналогично предыдущему, вероятность сбоя при выполнении

//этой операции повышается при доступе к файлу, находящемуся

//в общей сетевой папке

//----------------------------------------------------------

myStreamReader.Close();

//Возвратить количество строк в файле

return numberLinesInput;

}

Имитация сбоев связи с целью тестирования отказоустойчивости приложения

Настоятельно рекомендуется тестировать всевозможные условия возникновения ошибок в процессе передачи данных, намеренно вводя нарушения связи и наблюдая за тем, как ведет себя приложение в этих условиях. Не менее важно тестировать, насколько удачными оказываются попытки возобновления доступа к сети после того, как ваше приложение устранило последствия предшествующего сбоя.

Имитация сбоев связи при помощи кода на стороне клиента

В листинге 15.2 представлен механизм, позволяющий тестировать устойчивость работы мобильного приложения после устранения последствий сбоев при связи. Листинг содержит условно компилируемый код, который можно активизировать, поместив в начале файла с исходным кодом директиву #define DEBUG_SIMULATE_FAILURES.

Приведенная ниже функция writeDataToSocket() вызывается в процессе нормальной передачи данных. Для тестирования реакции приложения на сбои при обмене данными можно установить переменную g_failureCode = SimulatedFailures.failInNextWriteSocketCode в любой момент в процессе выполнения приложения. Когда впоследствии будет вызываться коммуникационный код, он возбудит исключение при первом вызове, но не при последующих. Это позволяет имитировать при тестировании ситуации, в которых сетевое соединение внезапно обрывается, вызывая сбой при передаче данных, но затем восстанавливается. Подобное использование условной компиляции тестирующего кода является не совсем элегантным, но зато эффективным способом мониторинга выполнения кода при имитации реальных условий возникновения сбоев.

Коммуникационный код, который вы пишете, следует тщательно проектировать и внимательно проверять, но одного этого еще недостаточно; код необходимо тестировать в условиях намеренно введенных сбоев. Ничто не в состоянии заменить тестирование в реальных условиях, однако самостоятельно инициировать с этой целью варианты сбоя для всех возможных случаев очень трудно. Единственная реальная альтернатива состоит в том, чтобы попытаться сымитировать и исследовать ход выполнения программы для каждой разновидности возможных сбоев. С учетом того, что при возникновении сбоев код может вести себя самым неожиданным образом, единственный способ проверить его отказоустойчивость — это вызвать возникновение ошибок в контролируемых условиях и убедиться в том, что ваше приложение в состоянии устранить последствия этих ошибок и продолжить дальнейшее выполнение.

Листинг 15.2. Имитация сбоев связи с целью тестирования приложения

//-----------------------------------------------------------------

//Глобальная переменная, которую мы хотим использовать для указания

//необходимости генерации исключений в процессе передачи данных

//-----------------------------------------------------------------

#if DEBUG_SIMULATE_FAILURES

//Переменная для хранения информация о следующем сбое

static SimulatedFailures g_failureCode = SimulatedFailures.noFailurePending;

//Список сбоев, которые мы хотим имитировать

public enum SimulatedFailures {

noFailurePending, //Отсутствуют текущие сбои, подлежащие обработке

//Имитируемые сбои:

failInNextWriteSocketCode,

failInNextWebServiceCall,

failInNextFileIODuringFileOpen,

failInNextFileIODuringFileRead

//и так далее

}

#endif //DEBUG_SIMULATE_FAILURES

//-----------------------------------------------------

//Функция, которую мы используем для передачи данных...

//-----------------------------------------------------

private void writeDataToSocket(System.Net.Sockets.Socket mySocket, byte[] dataToSend) {

//------------------------------------------------------------------

//Этот код следует компилировать лишь при тестировании сетевых сбоев

//------------------------------------------------------------------

#if DEBUG_SIMULATE_FAILURES

//Если это сбой, который мы хотим тестировать, генерировать исключение

if (g_failureCode == SimulatedFailures.failInNextWriteSocketCode) {

//Сбросить этот сбой, чтобы он не возник

//при следующем вызове этой функции

g_failureCode = SimulatedFailures.noFailurePending;

throw new Exception("Test communications failure: " + g_failureCode.ToString());

}

#endif

//Передать данные обычным образом...

mySocket.Send(dataToSend);

} //конец функции

Имитация сбоев связи при помощи кода на стороне сервера

Подобно тому, как для имитации сбойных ситуаций можно использовать тестирующий код на устройстве, целесообразно ужесточить условия тестирования приложения в отношении передачи данных путем имитации сбоев и задержек с помощью кода на стороне сервера. Используя мониторинг выполнения кода на сервере, можно вынудить сервер прервать обработку запроса или сформировать "зависание" на неопределенное время в процессе отправки ответа. В этих случаях ваше мобильное приложение, несмотря на сбои, должно предоставить конечному пользователю интерфейс, сохраняющий способность к отклику, и обеспечить возможность восстановления работы приложения. Выполнение тестирование путем имитации сбоев, генерируемых на стороне клиента, а также инициация сбоев и задержек при помощи кода на стороне сервера позволяют проверить выполнение этих требований. Например, в случае вызова Web-службы это легко сделать, передав вместе с запросом дополнительный параметр, указывающий на то, какой тип сбоя требуется тестировать. Значение параметра тестирования по умолчанию может указывать на режим обычного выполнения, тогда как другие значения могут указывать на необходимость генерации сбоя или формирования длительной задержки перед отправкой ответа. Клиент, вызывающий Web-службу, для которой предусмотрен мониторинг выполнения кода, может далее сделать запрос, который сгенерирует одну из этих сбойных ситуаций, предоставляя возможность тестировать ответ.

Информируйте пользователя о ходе выполнения процесса синхронизации данных

Чтобы пользователь чувствовал себя уверенно, он должен знать, что происходит с его данными. Подобно тому, как программы электронной почты предоставляют пользователю папку "Исходящие", в которой содержатся неотправленные письма, или как пользователю предоставляется возможность просматривать очередь принтера, чтобы увидеть, какие задачи дожидаются вывода на печать, ваше приложение должно предоставлять ясную картину состояния синхронизации пользовательских данных.

В предоставлении пользователям информации о синхронизации данных необходимо соблюдать меру. Вы должны обеспечить определенный баланс между теми удобствами, которые несет в себе предоставление пользователю отчетливой картины всего происходящего с данными, и теми неудобствами, которые может доставлять ему вывод информации о состоянии в те моменты, когда его это совершенно не интересует. По умолчанию, если процесс синхронизации данных осуществляется без заминок, не следует отвлекать пользователя выводом модальных диалоговых окон с сообщениями наподобие "Выгрузка данных идет успешно!" Точно так же, вряд ли пользователь будет доволен, если каждые 30 секунд на экране будет появляться мерцающий текст, выведенный крупным шрифтом, который гласит: "Делается повторная попытка установить соединение с сервером".

Поэтому во многих случаях целесообразно предусмотреть небольшой графический индикатор, вид которого сразу же укажет пользователю на то, как проходит передача данных. Какой тип графики следует использовать, и в каком месте экрана лучше всего поместить такой индикатор, зависит от особенностей пользовательского интерфейса конкретного устройства, с которым вы работаете. Одни устройства, такие как Pocket PC, предоставляют достаточно много места, чтобы можно было вывести на экран строку текста, кратко описывающего текущее состояние передачи. Экраны других устройств, например, смартфонов, имеют ограниченные размеры, и поэтому допускают вывод лишь нескольких слов или небольшого изображения. Как минимум, пользователю необходимо предоставлять в сжатом виде следующую информацию:

■ Информацию о незавершенных задачах обмена данными. Если имеются задачи, хранящиеся в локальной очереди, то пользователь должен об этом знать. Пользователю необходимо предоставлять возможность детализировать эти сведения, чтобы увидеть, какие именно задачи ожидают выполнения, и при необходимости попытаться вручную активизировать передачу данных, если он уверен, что такая попытка будет успешной.

■ Информацию о завершенных задачах обмена данными. Целесообразно уведомлять пользователя об успешном завершении выполняющихся задач. Будет неплохо, если вы предусмотрите какой-либо визуальный механизм, информирующий пользователя о том, что все идет нормально.

■ Информацию о возникновении проблем, делающих передачу данных невозможной. Если предпринятая в интересах пользователя попытка передачи данных закончилась сбоем, то пользователь должен быть об этом извещен. Возможно, исходя из этой информации, он предпримет определенные действия. Он может попробовать устранить проблему самостоятельно, выйдя, например, наверх из перехода в метро, чтобы попытаться повторно синхронизировать данные, или отменив незавершенную работу, поскольку необходимость в ней отпала. Как бы то ни было, конечному пользователю не помешает знать о том, что выполнявшаяся для него работа не была успешно завершена.

Разумеется, информация должна подаваться пользователю в приемлемом для него виде; сообщение наподобие: "Передача Patient312.xml через порт 8080 на сервер XYZ", скорее всего, большинству пользователей ни о чем не скажет, тогда как будучи отображенным в виде "Загрузка данных: диагностические данные пациента Боба Смита", оно станет намного более содержательным.

Конечная цель предоставления пользователям текущей информации о состоянии информационного обмена данными состоит в том, чтобы сделать их активными участниками этого процесса. Пользователи чувствуют себя намного увереннее, когда они знают, что именно происходит с их данными. Возможно, на основании этой информации пользователь предпримет определенные действия или же просто будет знать, что те или иные данные были переданы или не переданы. В любом случае пользователи будут беспокоиться значительно меньше, если будут иметь ясную картину того, насколько успешно продвигается выполнение интересующей их задачи.

Исходите из того, что скорость передачи данных и длительность задержек могут меняться

Некоторые сети работают значительно быстрее других. Кроме того, по мере увеличения количества устройств, пытающихся получить доступ, сеть начинает испытывать состояние перегрузки. Временные задержки при установлении соединений, отправке запросов, и получении ответов в зависимости от ситуации также могут меняться. Чтобы осуществить обмен данными, устройствам, работающим на периферийных участках сети, может потребоваться множество попыток передачи или получения пакетов информации. В силу всех вышеуказанных причин очень важно, чтобы ваше приложение надежно справлялось с реалиями изменяющейся полосы пропускания и интервалами задержки различной длительности. Тестирование в условиях контролируемой среды — это отличная вещь, которая позволит вам добиться значительного прогресса при написании вашего приложения, но важно учитывать и те особенности, с которыми вам придется столкнуться в процессе реальной работы, когда скорость передачи данных может все время меняться. Важно убедиться в том, что даже в условиях такой нестабильной связи пользователи вашего приложения никаких особых неудобств испытывать не будут.

Внедряйте необходимые коммуникационные средства безопасности уже на ранних стадиях проектирования приложения

Поскольку для обмена информацией мобильные устройства часто используют общедоступные сети и беспроводные каналы, важно продумать, какие средства защиты данных вам могут понадобиться, каким образом они должны быть встроены в ваше приложение и как это повлияет на процесс развертывания и производительность приложения. На сегодняшний день существует множество способов шифрования передаваемых данных; одними из наиболее популярных и простых в использовании являются безопасные протоколы HTTPS и SSL.

По существу, вы должны решить для себя следующее: 1) требуется ли вашему приложению безопасная передача данных, 2) с какими сетями будет взаимодействовать приложение, и 3) как будет реализован тот или иной уровень безопасности.

В большинстве отношений безопасная передача данных ничем не отличается от незащищенной передачи данных, но требует некоторой дополнительной настройки и сопровождается дополнительными накладными расходами. Если безопасная передача данных требуется при работе с общедоступными сетями, то, возможно, ваше приложение должно будет присоединять цифровые сертификаты к Web-запросам и проверять достоверность тех данных, которые оно получает. Применение средств шифрования и дешифрования при передаче данных требует выполнения дополнительных вычислений на обоих концах линии, что будет влиять на производительность; насколько велико это влияние, могут показать только тесты. И хотя базовый коммуникационный код в обоих случаях работает примерно одинаково, безопасная передача данных требует выполнения некоторых дополнительных шагов. Следствием этого будут дополнительные затраты времени на стадии проектирования и некоторое снижение производительности приложения. Если вашему приложению требуется безопасная передача данных, то проектирование и тестирование соответствующих средств безопасности следует начинать как можно раньше. Как и в случае асинхронной передачи данных, встраивание кода, обеспечивающего безопасную передачу данных, в уже почти завершенный алгоритм, является крайне нежелательным. Если требуется обеспечить шифрование сообщений, то наличие прошедшего тестирование кода, обеспечивающего безопасную передачу данных, избавит вас от необходимости внесения многочисленных изменений на последующих стадиях проектирования приложения.

Передача данных и выбор сети

Для передачи информации на устройство или с устройства мобильное приложение может использовать множество различных коммуникационных механизмов. Важно понимать, что какого-то одного наилучшего механизма не существует. У каждого из коммуникационных механизмов имеются собственные достоинства, недостатки и наиболее подходящие сценарии использования. Некоторые механизмы ориентированы на соединение равноправных узлов (peer-to-peer connection), другие — на нательные сети (body-area network), Internet или локальные сети. Анализируя потребности определенного вида связи, полезно составить список технологий, пригодных для использования в нужном вам решении, и набросать схему того, каким образом могло бы работать решение, основанное на той или иной технологии. Почти всегда вам придется выбирать из нескольких возможных вариантов, и принятие решения о том, какой из них будет для вас наилучшим, должно явиться результатом как творческого подхода, так и самого скрупулезного анализа. Некоторые наиболее распространенные коммуникационные механизмы описаны ниже.

Wi-Fi: локальные сети

Протокол Wi-Fi, известный также под названием протокола 802.11 (со всеми его разновидностями: 802.11.a, b, g и так далее), по существу является протоколом беспроводной связи на коротких дистанциях, основанным на протоколе Ethernet; этот коммуникационный механизм предназначен для использования в локальных вычислительных сетях. Имеется много причин, по которым стоит рекомендовать Wi-Fi к применению: он популярен, концептуально прост в использовании, поддерживает относительно широкую полосу пропускания (во многих случаях 100 Мбит/с и выше), прост в настройке, а стоимость передачи информации посредством Wi-Fi, как правило, невысока. Базовая станция Wi-Fi, соединенная с сетью, обычно обеспечивает беспроводной доступ в радиусе примерно несколько сотен футов, если она не оказывается закрытой, например, зданиями (рис. 15.1).

Рис. 15.1. Возможные перемещения мигрирующего пользователя сети Wi-Fi. Сети Wi-Fi обеспечивают широкую полосу пропускания. Для соединения с сетью Wi-Fi пользователь должен воспользоваться физической "горячей точкой Wi-Fi". В процессе синхронизации данных мобильного приложения пользователь, как правило, не перемещается между точками доступа Wi-Fi (то есть роуминг отсутствует).

С точки зрения программирования связь посредством Wi-Fi аналогична связи через кабель Ethernet. Этот вариант является великолепным универсальным решением проблемы под названием "Мне необходимо сетевое подключение". Вместе с тем, желая использовать Wi-Fi, вы должны провести следующий анализ:

■ Имеется ли у вас Wi-Fi? Не все мобильные устройства поддерживают Wi-Fi. Для большинства современных лэптопов встроенная поддержка Wi-Fi предусматривается. тогда как для большинства мобильных телефонов — нет. Некоторые мобильные устройства обеспечивают подключение карт Wi-Fi, причем обычно это делается посредством карт Compact Flash или Secure Digital. Можно ожидать, что в будущем протокол Wi-Fi будет поддерживаться большим количеством устройств, но это не будет встречаться сплошь и рядом.

■ Собираетесь ли вы использовать свою сеть Wi-Fi или также сети Wi-Fi других поставщиков? Если вам необходимо обеспечить сетевой доступ в пределах ограниченного местоположения, то разумно настроить собственные соединения Wi-Fi. Если же ваше мобильное приложение должно работать на большой территории, но ему не требуется постоянное подключение к сети, то не менее разумно использовать сети Wi-Fi сторонних поставщиков. На сегодняшний день пользователю мобильного приложения не составит особого труда найти "горячую точку Wi-Fi" ("Wi-Fi hot spot"), поддерживаемую одной из известных фирм, в гостинице или где-нибудь в городе. В то же время, несмотря на большой энтузиазм со стороны пользователей и большую шумиху, поднятую вокруг этого вопроса, вряд ли можно ожидать, что к сети Wi-Fi в ближайшее время будет организован надежный глобальный доступ. Даже при значительном расширении зон покрытия Wi-Fi к различным Wi-Fi-услугам будут применяться различные модели тарифных сеток и прав доступа, охватывающие как бесплатные, так и очень дорогие услуги. Для бесплатных сетей характерен низкий уровень предоставляемых гарантий. Некоторые Wi-Fi-сети обеспечивают самые широкие возможности доступа в Internet, тогда как другие предоставляют доступ только к локальным сетям. Отнюдь не все виды Wi-Fi-доступа являются равноценными. Проезжая по длинным участки трасс или по небольшому городку, вы увидите довольно много базовых станций Wi-Fi, однако пока еще они не установлены повсеместно.

■ Безопасность. Отправлять пакеты через Wi-Fi-соединения — это все равно что кричать с крыши здания; вас может услышать кто угодно. На самом деле, все не так уж и плохо, поскольку Wi-Fi-сети предлагают различные уровни встроенной поддержки шифрования, начиная от секретных ключей, совместно используемых базовой станцией Wi-Fi и устройствами, и заканчивая средствами защиты информации на основе сертификатов и открытых ключей шифрования (чрезвычайно надежная защита). Даже при передаче данных по нешифруемым открытым Wi-Fi-каналам можно без труда использовать протоколы SSL (Secure Socket Layer) или HTTPS (Secure HTTP) для шифрования передаваемых данных на уровне приложения. Если вам надо передавать важные данные, их обязательно следует шифровать.

■ Энергопотребление. Коммуникационный механизм Wi-Fi не относится к числу экономичных в плане расхода электроэнергии. Как устройства так и их аккумуляторные батареи становятся все меньшими и меньшими, и поэтому допустимая доля энергоресурса, которую можно расходовать на Wi-Fi-связь, не очень велика. Это означает, что существует некий практический нижний предел размеров, при которых устройство еще в состоянии эффективно пoддepживaть Wi-Fi. Несомненно, в этом отношении будут найдены какие-то аппаратные или программные решения, однако на сегодняшний день указанная проблема существует.

Несколько слов по поводу WiMax

Протокол WiMax, известный также под названием протоколов 802.16 и 802.20, — это развивающийся стандарт, который должен вобрать в себя все лучшее из того, что предлагают сети Wi-Fi и сети мобильной телефонной связи, предоставить возможности широкополосной передачи пакетов, свойственные сетям Wi-Fi, на большие расстояния и, в перспективе, обеспечить возможность роуминга между точками доступа (access points). В то время как протокол 802.11 (Wi-Fi) предназначен для беспроводных локальных сетей, новые стандарты предназначены для введения беспроводных региональных сетей, охватывающие значительно большие расстояния по сравнению с Wi-Fi. Как и в случае любого нового стандарта, для внедрения WiMax несомненно потребуется определенное время, однако этот протокол является весьма многообещающим в отношении скорости и стоимости передачи данных. Операторы традиционных стационарных сетей, операторы мобильных сетей и производители связного оборудования заинтересованы в развитии этого направления, и о том, какие изменения ожидают коммуникационный ландшафт, в настоящее время можно только догадываться. Автор данной книги не может дать иных прогнозов, кроме того, что, по его мнению, развитие этого процесса будет весьма интересным, и он растянется на ближайшие несколько лет. Как и в случае всех остальных механизмов беспроводной связи, которые мы здесь обсуждаем, работа с протоколом WiMax потребует от вашего приложения готовности работать в условиях нестабильного доступа к сети и неоднородных сетей, включая сети Wi-Fi, WiMax, 2.5 G, 3G и другие сетевые технологии.

Более подробную информацию об этих развивающихся стандартах вы сможете найти на Web-сайте:

http://grouper.ieee.org/groups/802/16/ и

http://grouper.ieee.org/groups/802/20/

Bluetooth: персональные сети

Bluetooth — это коммуникационный механизм персональных вычислительных сетей (Personal Area Network — PAN), предназначенный для объединения различных устройств, непосредственно окружающих пользователя, в единую сеть. PDA-устройства, лэптопы, мобильные телефоны, принтеры и, возможно, даже торговые автоматы и автономные центры интерактивной информации — все они могут выступать в роли целевых объектов сетей Bluetooth. Назначение стандарта Bluetooth состоит в том, чтобы позволить различным устройствам, оказавшимся вблизи друг друга, вступать друг с другом в различные отношения, зависящие от конкретной ситуации. Как видно на рис. 15.2, существует два вида вычислительных устройств, которые может объединять Bluetooth: персональные устройства, переносимые индивидуумом, и внешние устройства, с которыми может вступать в контакт владелец устройства, располагающего возможностями Bluetooth.

Часто неправильно считают, что стандарт Bluetooth подразумевает только "что-то одно", то есть представляет собой исключительно коммуникационный протокол и ничто другое, хотя на самом деле это не так. Несмотря на то что Bluetooth построен поверх базового сетевого стека, наиболее существенным аспектом Bluetooth являются построенные поверх него "профили". Сам по себе Bluetooth — это коммуникационный механизм, но почти вся наиболее интересная работа выполняется на уровне профилей Bluetooth. С практической точки зрения это означает, что если только два различных устройства не поддерживают одни и те же профили Bluetooth, то они мало что смогут сообщить друг другу. Например, Bluetooth-принтеру, который поддерживает профиль Bluetooth "Basic Printing Profile", может быть известно о существовании в той же комнате удаленного элемента управления "A/V Remote Control Profile", но эти два устройства не смогут общаться на понятном им обоим языке, если только они не разделяют общий набор профилей.

Рис. 15.2. Схематическое изображение персональной сети

Список поддерживаемых профилей вы можете найти на Web-сайте организации Bluetooth www.bluetooth.org.

На практике необходимость совпадения профилей обоих устройств не налагает столь сильных ограничений, как могло бы показаться на первый взгляд, по следующим двум причинам: 1) профили распространенных типов устройств, которые от возможности обмениваться между собой информацией могли бы только выиграть, обычно перекрываются друг с другом, и 2) несмотря на существование множества различных профилей, на практике лишь немногие из них доминируют в тех областях, которые представляют интерес с точки зрения использования мобильных устройств. Существуют распространенные профили для синхронизации информации, с которой работают PDA-устройства, а также профили для использования мобильного телефона в качестве сетевого концентратора.

Что немаловажно, существует также профиль, позволяющий использовать Bluetooth-устройство в качестве последовательного порта RS-232; название этого профиля соответствует его назначению — "Serial Port Profile". Благодаря этому такие устройства Bluetooth воспринимаются как СОМ-порты и могут поддерживать старые протоколы последовательной передачи данных. Многие устаревшие источники информации поддерживают традиционную связь через последовательный порт RS-232, и на протяжении ряда лет последовательные протоколы получили широкое распространение.

Обычным средством подключения этих устройств к компьютеру служил кабель RS-232. В качестве показательного примера, имеющего отношения к мобильным средствам связи, можно привести приемные устройства глобальной системы навигации и определения положения (Global Positioning System — GPS). В этой системе для передачи информации о глобальном местоположении от датчиков положения на вычислительное устройство в течение многих лет использовался последовательный протокол NMEA (National Marine Electronics Association — Национальная ассоциация судовой электроники). Теперь связь с этими устройствами является беспроводной, и вместо того чтобы изобретать совершенно новые протоколы, для многих последующих поколений этих устройств было решено по-прежнему использовать проверенные протоколы последовательной передачи данных, но осуществлять это посредством беспроводных соединений Bluetooth.

Программирование с использованием Bluetooth следует той же схеме, которая применяется при работе с перечисленными выше профилями. Разработчик, применяющий Bluetooth, может работать либо с низкоуровневыми API-интерфейсами Bluetooth, — возможно, посредством сокетов, если устройство поддерживает отображение данных между сокетами и Bluetooth, — либо с API-интерфейсами, специфичными для профилей. Например, если доступ к устройству Bluetooth осуществляется посредством профиля Serial Port Profile, то разработчик может вообще забыть о Bluetooth и просто работать с API-интерфейсами СОМ-порта. Выбор остается за вами, однако, как ранее уже отмечалось в данной главе, работать с более абстрактными высокоуровневыми API-интерфейсами почти всегда проще. Может даже оказаться, что использовать API- интерфейсы последовательного порта вам будет гораздо проще, чем углубляться во все детали обмена данными посредством протокола Bluetooth. При малейшей возможности упрощайте себе задачу и используйте более абстрактные API-интерфейсы.

Если вы программируете с использованием .NET Compact Framework версии 1.1, то для доступа к функциональным возможностям Bluetooth вам надо будет использовать собственный код (native code), если только независимыми производителями программного обеспечения уже не предусмотрены специальные встроенные интерфейсные оболочки, которые вы сможете использовать в управляемом коде (managed code). В NET Compact Framework версии 1.1 встроенная поддержка для работы как с Bluetooth, так и с последовательным СОМ-портом отсутствует. Вместе с тем, по адресу www.gotdotnet вы найдете образец кода, демонстрирующий, каким образом можно использовать вызовы собственного кода для решения таких низкоуровневых коммуникационных задач, как доступ к последовательному порту.

НА ЗАМЕТКУ

Поскольку стандарт Bluetooth специально разрабатывался для мобильных устройств, он, как правило, обеспечивает неплохие характеристики энергосбережения, но при необходимости вы сможете найти и другие, более специализированные коммуникационные механизмы. В дополнение к таким технологиям персональных сетей, как Bluetooth, существуют также такие технологии нательных сетей, характеризуемые низким энергопотреблением, как Zig-Bee (IEEE 802.15). Сетевые протоколы нательных сетей пригодны для работы с встроенными датчиками и другими видами устройств, для которых необходим низкий уровень энергопотребления.

Сети мобильной телефонной связи/сотовая связь

Основным преимуществом сетей мобильной телефонной связи являются большие радиусы зон покрытия. Границы зон покрытия этих сетей распространяются настолько далеко, что можно легко забыть о том факте, что подобные возможности на самом деле появились совсем недавно; теперь действительно можно говорить о "данных, которые доступны практически везде". Указанное преимущество этой разновидности связи несколько нивелируется тремя ее недостатками: как правило, недостаточной пропускной способностью, как правило, высокой стоимостью передачи данных и неоднородностью сетевых стандартов. Но даже несмотря на наличие этих недостатков, сети мобильной телефонной связи являются важным потенциальным каналом передачи данных вашего мобильного приложения, и чтобы уметь правильно воспользоваться услугами, которые предлагают сети мобильной связи, важно знать хотя бы кое-что об этих сетях.

Современные сети мобильной телефонной связи предлагают каналы как для речевой связи, так и для обмена данными. Используя каналы передачи данных, мобильные приложения могут отправлять и получать информацию в диапазоне средних и высоких скоростей передачи данных. Фактическая скорость передачи данных может в значительной степени зависеть от используемых сетевых технологий, а также от наличия других мобильных устройств, конкурирующих за право использования канала связи. Точно так же, как одна базовая станция (base station) мобильной связи (иначе — узел сотовой связи (cell tower)) не в состоянии поддерживать неограниченное количество телефонных разговоров, существует определенная фиксированная полоса пропускания, которая распределяется между различными пользователями. To же самое справедливо и для других технологий, например Wi-Fi, но важным отличительным признаком рассматриваемого нами случая является то, что, поскольку узел сотовой связи обслуживает территорию гораздо большего радиуса, чем базовая станция Wi-Fi, полоса пропускания может быть легко истощена большим количеством пользователей.

Мобильные сетевые технологии неоднородны как по регионам, так и по техническим поколениям. Для полноценного обсуждения этой темы потребовалась бы целая книга, материал которой успел бы, вероятнее всего, устареть еще до ее выхода. Некоторые из наиболее интересующих нас терминов описаны ниже для ознакомительных целей:

■ Мобильные сетевые технологии телефонные сети GSM и CDMA. Традиционно в Европе и на Среднем Востоке использовались стандарты мобильной технологии связи GSM, а в Северной Америке и Корее — CDMA. (Ранее в североамериканских сетях использовался стандарт TDMA, а в Японии — совершенно другие стандарты.) Эта линия раздела постепенно размывается по мере того, как все больше североамериканских операторов мобильных телефонных сетей начинают предлагать услуги GSM-связи; как правило, такие услуги сначала предоставляются в густонаселенных районах. Радиочастоты GSM, используемые в Европе и Северной Америке различаются между собой, поэтому для работы одновременно в обеих средах требуются "двухдиапазонные" ("dual-band") и "трехдиапазонные" ("tri-band") телефоны; к счастью, в наши дни такие телефоны — обычное явление, а в многофункциональных мобильных устройствах эта возможность обычно также предусмотрена. Предпринимаются попытки изготовления телефонов, совмещающих в себе возможности связи в соответствии с различными стандартами (например. CDMA и GSM); приживутся ли такие телефоны на рынке — пока не ясно. В то же время, устаревающие стандарты вытесняются более новыми, такими как CDMA2000 (третье поколение (3G) CDMA) или W-CDMA (3G-поколение GSM). Мобильные стандарты сближаются друг с другом, но должно пройти еще немало лет, прежде чем концепция телефона приемлемой стоимости, способного работать в любой точке земного шара, превратится в реальность.

■ Поколения технологий: 2.5G, 3G, выше 3G. Число перед буквой "G" обозначает "поколение" ("generation") мобильной сетевой технологии. Вообще говоря, чем больше это число, тем выше быстродействие сети. Для большинства задач, которые возникают в связи с передачей данных мобильных устройств, 2.5G — это первое поколение, представляющее практическую ценность. Применительно к сетям мобильной телефонной связи GSM на поколение 2.5G обычно ссылаются как на GRPS (General Packet Radio Service — общая служба передачи радиопакетов). Сети поколения 3G предлагают значительно более высокие скорости передачи данных, но пока еще они являются относительной новинкой, и широкое развертывание этих сетей наталкивается на трудности коммерческого характера. Для трубок 3G обычно обеспечивается роуминг, и они могут работать в средах 2.5G со скоростями передачи данных 2.5G. Другим названием услуг по передаче 3G-данных является UMTS (Universal Mobile Telecommunications System — универсальная система мобильных телекоммуникаций). При ссылке на технологии, простирающиеся дальше указанных (4G и так далее), обычно используют выражение "выше 3G" ("Beyond 3G"); на момент написания данной книги такие технологии только проектировались.Примечание. Обмен данными с мобильными устройствами возможен и при использовании 2G сетей; в 2G-сетях для передачи данных обычно применяется речевой канал, поэтому доступ к сети передачи данных напоминает обычный телефонный звонок. Мобильные телефонные сети 2G являются первым поколением цифровых сетей; 1G — суть аналоговая связь.

Если все это кажется вам немного запутанным, то только потому, что так оно и есть. Сегодняшняя глобальная сеть мобильной телефонной связи являет собой сплошную "кашу"! Более того, можно ожидать, что на протяжении еще ряда лет она будет представлять собой пеструю смесь различных систем и поколений технологий. Причины этого в основном носят финансовый характер; получение от государства разрешения на использование диапазона радиочастот, а также развертывание и эксплуатация сетей мобильной связи обходятся в огромные денежные суммы. Это означает, что развертывание новых сетей — дорогостоящее предприятие, осуществляемое, как правило, путем использования фрагментарного похода, основанного на принципе первоочередного завоевания "наиболее лакомых" секторов рынка. Обновление сетей также является дорогостоящим и нередко требует замены устаревших базовых станций и телефонных трубок. Переход к новому поколению технологий означает необходимость развертывания параллельных перекрывающихся сетей, что позволяет операторам связи поддерживать существующую клиентуру, приносящую деньги "в клювике", и одновременно внедрять новые услуги. Дополнительные сложности в эту экосистему вносит тот факт, многими операторами мобильной связи Wi-Fi рассматривается одновременно и как угроза благополучию, и как счастливая возможность вырваться вперед; владельцы различных каналов связи используют различные подходы к тому, чтобы обеспечить существующим клиентам возможность доступа к "горячим точкам Wi-Fi" при сохранении обычных механизмов оплаты. Ниже приведены некоторые рекомендации, касающиеся выбора той сети мобильной связи из числа доступных, которая будет больше всего соответствовать потребностям вашего мобильного приложения:

1. Абстрагируйте сетевую технологию. К счастью, являясь разработчиком мобильного приложения, вы можете абстрагироваться от большинства низкоуровневых деталей мобильных коммуникационных технологий. Соединение с Web-cepвeром через сокет остается одним и тем же в сетях 2.5G и 3G, и сокету совершенно безразлично, какая технология положена в основу радиосвязи — CDMA, GSM или еще что-нибудь другое. Важный урок состоит в том, чтобы использовать настолько высокий уровень технологической абстракции, насколько это возможно. В качестве высокого уровня абстракции неплохо использовать запросы и ответы HTTP; сокеты находятся одним уровнем ниже, но остаются нейтральными по отношению к выбору сети. Чем дальше вы отходите от интерфейса радиосвязи устройства, тем более переносимым будет ваше приложение. Нет никаких причин для того, чтобы надлежащим образом спроектированное приложение не могло выполняться в неизменном виде и в сетях GSM, и в сетях CDMA.

2. Предусматривайте возможность работы на пониженных скоростях передачи данных. Хотя 3G-ceти могут обеспечивать очень высокую пропускную способность, можно предположить, что в обозримом будущем ваши целевые мобильные устройства будут, вероятно, работать в смешанном окружении, состоящем из сетей 2.5G и более поздних. Для сетей 2.5G достаточно разумным является предположение о том, что скорость передачи данных будет составлять примерно 20 Кбит/с; 20 Кбит/с = 2,5 Кбайт/с. Вполне вероятно, что при работе с улучшенными сетями ваше приложение сможет обмениваться данными с более высокой скоростью, но не менее вероятно, что в силу загруженности сети скорость передачи данных будет еще меньше, приближаясь к значениям, характерным для модемов, работающих через аналоговые телефонные линии. В этом же направлении действует еще один фактор — временные задержки; можно почти не сомневаться, что канал передачи данных в мобильной сети 2.5G будет характеризоваться большими задержками, чем кабельное соединение с Internet, о чем важно не забывать, если вы рассчитываете на немедленный (менее 1 секунды) отклик. Если ваше мобильное приложение должно использовать сети мобильной телефонной связи, то очень важно обеспечить его надежную работоспособность при пониженных скоростях передачи данных и увеличенных временах задержки. При разработке проекта целесообразно руководствоваться правилом, суть которого заключается в следующем: если объем загружаемых данных превышает 20 Кбайт, то имеет смысл отслеживать длительность загрузки и в случае превышения определенного порогового значения прекращать эту операцию. Разумеется, фактическое значение критической длительности загрузки и длительность интервала ожидания зависят от природы приложения и характеристик используемых сетей с учетом интересов конечного пользователя. Конечный пользователь не должен ждать поступления данных в течение неопределенного времени, если их загрузка осуществляется фоновым потоком; измеряйте степень выполнения загрузки и соответствующим образом устанавливайте критические значения параметров.

3. Хорошо изучите действующие системы оплаты связи. Хотя в некоторых старых (в основном. 2G) системах передачи данных взимаемая плата зависит от длительности соединения, оплата услуг по предоставлению данных в большинстве сетей мобильной связи основывается на количестве переданных битов. Ставки оплаты для отечественных сетей и сетей с услугами роуминга могут значительно отличаться. Все эти факторы будут оказывать самое непосредственное влияние на те расходы, которые понесет пользователь вашего приложения, оплачивая услуги связи. Относительно того, какие тарифы оплаты связи можно считать приемлемыми, а какие — неприемлемыми, трудно дать какие-либо определенные рекомендации; это будет определяться природой вашего приложения. Выбирая технологию мобильной связи, целесообразно измерить характерные объемы загружаемых и выгружаемых данных и оценить соответствующие затраты применительно к различным коммуникационным моделям.

Сеть мобильной телефонной связи, Wi-Fi или и то, и другое?

Все большее количество мобильных телефонов с развитой функциональностью, поступающих на рынок, поддерживают Wi-Fi, причем эти возможности либо являются встроенными, либо делаются доступными посредством подключения съемных карт; двумя наиболее популярными форматами таких карт являются карты Compact Flash и Secure Digital Wi-Fi. В свою очередь, в лэптопах и специализированных мобильных вычислительных устройствах, имеющих встроенную поддержку Wi-Fi, съемные карты часто предусматриваются для обеспечения дополнительной возможности доступа к сетям мобильной телефонной связи.

Если учесть, что введение дополнительных возможностей означает увеличение цены и энергопотребления, то какой смысл в том, чтобы мобильные устройства могли осуществлять связь как через сети мобильной телефонной связи, так и через сети Wi-Fi? Ответ таков: "Все зависит от приложения", что является другой формулировкой ответа: "Все зависит от вашего проекта".

Во многих случаях одной из задач проекта должно быть обеспечение нормальной работы приложения, развернутого на устройствах, которые используют сети Wi-Fi или сети мобильной телефонной связи. Вообще говоря, чем более популярно и полезно приложение, тем более вероятно, что у пользователей возникнет желание выполнять его с использованием самого различного сетевого оборудования. Пользователи захотят воспользоваться преимуществами широкой полосы пропускания там, где она окажется доступной, но будут заинтересованы и в том, чтобы приложение удовлетворительно работало и с более медленными сетями. Коль скоро ваше приложение использует такие высокоуровневые сетевые технологии, как сокеты или HTTP, никаких технических проблем при этом возникать не будет, поскольку оба эти коммуникационные уровни абстрагируют лежащие в их основе сетевые протоколы.

При работе с различными сетями мобильной телефонной связи или Wi-Fi важно, чтобы вашему приложению была известна измеренная (а не теоретическая) величина пропускной способности, которую обеспечивает канал связи. Одно дело — "прекрасно работать, когда благожелательно настроенный пользователь согласен ждать результата неопределенное время", и совершенно другое, когда приложение "при любых обстоятельствах должно обеспечивать для пользователя комфортные условия работы". Если ожидается, что ваше приложение будет выполняться на устройствах, которые поддерживают связь как посредством Wi-Fi, так и посредством мобильных телефонных сетей, то для приложения целесообразно предусмотреть два режима выполнения — низкопроизводительный и высокопроизводительный. В режиме низкой производительности передаваться должны лишь наиболее существенные данные, тогда как остальные данные должны кэшироваться до тех пор, пока не сможет быть установлено высокоскоростное соединение.

В качестве примера рассмотрим действия эксперта по дорожно-транспортным происшествиям. Предположим, что в функции эксперта входит выезд на место происшествия и составление отчета, к которому в качестве вещественных доказательств прилагаются цифровые фотографии. Очень важно, чтобы сведения о дорожном происшествии поступали как можно быстрее; все его участники должны заполнить свои страховые заявки, в необходимых случаях должна быть оказана медицинская помощь, машины должны быть отбуксированы в разные места и так далее. Указанные причины и обуславливают важность немедленного составления отчета о происшествии. В долговременной перспективе важны также различного рода вещественные доказательства, и в этом отношении подробные фотографии, сделанные на месте происшествия, могут оказать неоценимую помощь. Встроенное в мобильный телефон, который эксперт всегда имеет при себе, специализированное приложение может значительно повысить эффективность этого процесса. По прибытии на место происшествия эксперт начинает готовить новый отчет об инциденте, используя мобильное устройство. Запустив мобильное приложение, он может ввести важную информацию, касающуюся дорожного происшествия, например, автомобильные номера машин-участниц инцидента, номера водительских прав, контактную информацию о пассажирах, и результаты первоначальной оценки происшедшего. Как только эта информация подготовлена, ее можно немедленно поместить на сервер, используя мобильное телефонное соединение. Поскольку эта информация является в основном текстовой, а ее объем сравнительно невелик, то процесс выгрузки данных займет мало времени, так что мобильная телефонная связь вполне подходит для этих целей. После того как эта информация введена в систему, можно сразу же приступать к растаскиванию автомобилей, поэтому в скорейшем завершении первого этапа сбора и отправки информации об инциденте заинтересованы все стороны. Теперь наш эксперт может приступить к работе, требующей большей тщательности: сделать подробные фотографии, записать в звуковые файлы показания очевидцев происшествия и собрать дополнительную информацию. Часть информации может быть немедленно выгружена на сервер, но основной ее объем можно кэшировать на устройстве, что позволит сэкономить и время, и деньги. Позже, когда эксперт вернется в офис или окажется в том месте, где предоставляется доступ к сети Wi-Fi, он сможет выгрузить на сервер цифровые фотографии, записанные с голоса показания и другие данные, занимающие большой объем.

При проектировании модели сетевого доступа важно не "переборщить" и не пытаться решать все вопросы вместо пользователя мобильного приложения. Можно собрать достаточный объем информации о доступных сетях и организовать автоматическое выполнение операций, требующих использования высокопроизводительных или низкопроизводительных каналов связи, но можно поступить и иначе. Попытки автоматизации использования сетевого доступа заслуживают внимания, однако выбор окончательного решения следует предоставлять пользователю. В конце концов, именно конечным пользователям мобильного приложения придется работать с ним в реальных условиях, и кто. как не они, способен принять наиболее оптимальное решение относительно целесообразности передачи тех или иных данных. Ваше приложение должно предоставлять конечным пользователям необходимую информацию и давать им возможность принимать решения по своему усмотрению. Лучший способ реализации такого подхода заключается в том, чтобы разрешить пользователям задавать предпочтительные установки режимов передачи данных, предоставить им возможность передавать данные по запросу и позволить отказываться от операций, выполнение которых в настоящее время они считают нецелесообразным. При этом важно не впасть в одну из крайностей, предоставляя в распоряжение пользователей либо недостаточные возможности контроля, либо чрезмерно сложный набор возможных вариантов. Соответствующие рекомендации приводятся ниже:

■ Разрешите пользователям задавать предпочтительные параметры связи. Если это возможно, предусмотрите в приложении набор регулируемых параметров передачи информации, изменением значений которых пользователи приложения могли бы настраивать его, исходя из пропускной способности сети и собственных потребностей. В качестве примера пользовательских установок можно привести возможность задания объема информации, подлежащей загрузке (например, небольшой, средний, произвольный), или указывать загрузку только текста, отказываясь от загрузки относящихся к нему изображений.

■ Предоставьте пользователям возможность передавать данные "по требованию". Во многих случаях наилучшими возможностями для принятия решений о необходимости установления связи располагает конечный пользователь мобильного приложения. Например, если требуется подключение к сети мобильной телефонной связи или Wi-Fi, то пользователь мобильного устройства может переместиться в то физическое место, где установление нужного вида связи становится возможным. Оказавшись в зоне, где, как ему известно, можно установить нужное соединение, пользователь сможет немедленно отдать приложению команду приступить к синхронизации данных. Посадив в водительское кресло именно конечного пользователя, вы делаете приложение значительно более гибким.

■ Предоставьте пользователям возможность отказываться от операций, выполнение которых в настоящее время они считают нецелесообразным. Как бы вы ни старались, почти невозможно предугадать, с какими трудностями придется столкнуться вашему приложению при выполнении коммуникационных операций, и каковы могут быть надежные способы их решения. Причиной того, что ваше приложение не сможет предоставить пользователю те условия связи, на которые тот рассчитывает, может быть перегрузка сети и, как следствие, ее низкая пропускная способность, возникновение проблем на прокси-сервере, а также множество других факторов. Ваш код должен надежно справляться с подобными ситуациями. Что немаловажно, вы должны давать конечным пользователям возможность принимать на себя управление ситуацией и прекращать попытки обмена информацией с удаленными источниками, откладывая выполнение операций на более поздний срок. Ваше приложение должно обеспечивать конечных пользователей необходимой информацией, позволяющей им принимать обоснованные решения относительно целесообразности дальнейшего поддержания связи; последующее поведение приложения должно определяться тем, что требуется пользователю. В качестве возможных способов оказания пользователю помощи в принятии обоснованных решений подобного рода можно привести отображение на экране количества попыток установления связи или "процента выполнения" операции, связанной с передачей данных, а также предоставление пользователю возможности отменить или отложить на более поздний срок осуществление такой операции, если она выполняется слишком медленно.

Один из возможных примеров цепочки мобильной связи, в которой используется как сеть мобильной телефонной связи, так и сеть Wi-Fi, представлен в схематическом виде на рис. 15.3.

Рис. 15.3. Маршрут передвижения пользователя мобильного телефона и сети Wi-Fi. Сети мобильной телефонной связи характеризуются более широкой зоной покрытия, но меньшей скоростью передачи данных по сравнению с сетями Wi-Fi. Для пользователя, перемещающегося на большие расстояния, сети мобильной телефонной связи обеспечивают возможность подключения к данным на сервере практически на всем протяжении маршрута. Если возникает необходимость в передаче большого объема данных, то пользователь должен специально приблизиться к "горячей точке Wi-Fi". Кроме того, возможностью подключения к сети Wi-Fi иногда можно пользоваться в "мертвых зонах" ("dead spots") сети мобильной телефонной связи (например, в метро).

На этом рисунке видно, что сети мобильной телефонной связи имеют широкие зоны покрытия с относительно малочисленными "мертвыми зонами", в которых связь не обеспечивается. В отличие от этого зоны покрытия Wi-Fi сетей характеризуются гораздо меньшими размерами, но зато обладают большей пропускной способностью. Пользователи мобильных устройств могут использовать сеть мобильной телефонной связи для частой передачи данных небольшими порциями, когда работают на выезде, а более крупные объемы данных помещать в очередь и передавать во время нахождения вблизи "горячей точки" широкополосной сети Wi-Fi.

Связь посредством лотка/кабельного соединения с ПК

Под связью посредством лотка понимается либо непосредственная, либо сквозная передача данных в сеть через промежуточный компьютер, когда устройство подключено к этому компьютеру с помощью физического кабеля. Вместо установления соединения непосредственно с сетью мобильное устройство связывается с настольным компьютером или лэптопом. Устройство либо синхронизирует данные с компьютером, либо использует его в качестве средства, обеспечивающего доступ к сети. Примечание. Возможность доступа к сети через хост-компьютер должна поддерживаться программным обеспечением, при помощи которого осуществляется синхронизация данных; так, начиная с Pocket PC 2002, различные версии программного обеспечения ActiveSync компании Microsoft поддерживают туннелированный доступ устройств к Internet через настольные компьютеры. В разных технологиях работы с устройствами подобная поддержка "сквозного" доступа в сеть будет обеспечиваться разным программным обеспечением.

Преимуществом связи посредством лотка является ее относительная простота. Часто все необходимое для этого программное обеспечение и кабели уже имеются у владельцев соответствующих мобильных устройств, а владельцы компьютеров тоже, как правило, сразу же заботятся о подключении их к сети Internet. Связь через лоток особенно удобно использовать в интересах прототипирования, тестирования и отладки приложения, поскольку она обеспечивает легкий доступ к сетевым устройствам в контролируемом окружении. Кроме того, связь через лоток не является дорогой, поскольку она не зависит ни от какой другой инфраструктуры сетевого доступа кроме тех, которые уже имеются на лэптопах и настольных компьютерах.

Основным недостатком обмена данными через лоток является то, что устройство оказывается привязанным к компьютеру, который поддерживает необходимое для синхронизации данных программное обеспечение. Решение, основанное на использовании определенного набора хост-компьютеров, неспособно обеспечить доступ к данным в соответствии с принципом "связь в любое время и в любом месте". Вместе с тем, если мобильному приложению, которое вы разрабатываете, требуется не доступ к сети в любой момент, а лишь периодическая синхронизация данных, которая может быть выполнена через сетевое соединение ПК, то коммуникационная модель, использующая связь через ПК, вам вполне подойдет. Как и в случае доступа к сети Wi-Fi, связь посредством лотка может быть использована для реализации других коммуникационных механизмов; например, при работе на выезде для передачи и получения небольших объемов данных можно использовать сети мобильной телефонной связи, тогда как крупные объемы данных можно кэшировать на устройстве для последующей их синхронизации через ПК, подключенный к сети.

Сетевой кабель

Использование кабеля Ethernet для связи мобильных устройств с сетями очень похоже на использование с этой целью сети Wi-Fi. Будучи в основном схожими между собой, эти две коммуникационные модели отличаются друг от друга в следующем:

■ Сетевые кабели привязывают вас к определенному месту в большей степени, чем сеть Wi-Fi. Диаметр зоны связи вокруг базовой станции Wi-Fi составляет несколько сотен футов, что значительно превышает приемлемую для большинства случаев длину кабеля; в этом смысле Wi-Fi предоставляет более "мобильную" форму доступа. нежели сетевой кабель. Что касается практической стороны дела, то в тех случаях, когда требуется гибкий сетевой доступ в пределах ограниченной территории, например, внутри одного здания, чаще дешевле использовать Wi-Fi, чем прокладывать кабельную проводку по всему зданию. С другой стороны, наличие сетевого кабеля гарантирует возможность постоянного доступа к сети; в тех местах, куда не доходит сигнал Wi-Fi, сетевой кабель может оказаться единственно возможным выходом.

■ Сетевые кабели обладают определенными преимуществами в отношении защиты информации по сравнению с Wi-Fi. Несмотря на то что сети Wi-Fi могут быть сконфигурированы для передачи данных по шифрованным каналам, они в любой ситуации будут оставаться широковещательными радиоканалами. Сценарий, предполагающий использование кабелей, способен защитить от прослушивания радиосигналов; эту защиту нельзя считать "пуленепробиваемой", но все же — это дополнительный уровень повышения безопасности. Примечание. Если вы устанавливаете соединение с общедоступной сетью или через нее, то этот дополнительный уровень безопасности обеспечивает лишь минимальную защиту; чтобы надежно защитить свои данные, вам придется прибегнуть к шифрованию. (Придерживаться этой рекомендации не помешает в любой ситуации.)

■ Для кабельного подключения к сети может потребоваться дополнительное оборудование. В то время как для большинства современных настольных компьютеров предусмотрены встроенные возможности как проводного, так и беспроводного подключения к сети, для большинства мобильных устройств это не так. Вследствие увеличения размеров, энергопотребления и стоимости изготовления соответствующего оборудования эта ситуация, по-видимому, еще просуществует какое-то время. Для поддержки кабельного сетевого подключения вам может понадобиться дополнительная внешняя карта (обычно Compact Flash или Secure Digital).

Как и в случае связи через лоток, подключение к сети посредством физического кабеля может оказаться очень полезным при прототипировании и отладке решений для мобильных устройств. В то же время, вы должны отчетливо понимать, что при использовании многих беспроводных коммуникационных механизмов скорость подключения и характеристики надежности будут намного ниже; и хотя кабельные сетевые соединения являются полезным средством, одного его недостаточно для разработки и тестирования приложений, которые будут выполняться в беспроводных сетях.

IrDA

С точки зрения абстракций низкого уровня IrDA (Infrared Data Association — Ассоциация по передаче данных через инфракрасные каналы) — это просто стандарт последовательной передачи данных по инфракрасному каналу; в рамках программных моделей более высокого уровня абстракции это понятие приобретает значительно более широкий смысл. Поверх IrDA была построена сложная многоканальная программная модель, и эту модель можно с успехом применять в качестве гибкого средства передачи данных (более подробные сведения по этому вопросу вы найдете по адресу: www.irda.org).

В силу своей дешевизны и необычайно широкой распространенности технология IrDA отлично подходит для организации связи между равноправными устройствами. Поскольку стоимость изготовления оборудования для IrDA невелика, оно имеет небольшие размеры и потребляет мало электроэнергии, оно интегрируется во многие мобильные устройства, включая устройства Pocket PC и смартфоны. Для осуществления передачи данных два устройства должны быть физически сориентированы друг относительно друга определенным образом, после чего между ними может быть установлена связь.

С точки зрения разработки мобильного приложения IrDA представляет интерес по двум причинам. Во-первых, как и Bluetooth, IrDA можно использовать для того, чтобы обеспечить возможность обмена данными между мобильным устройством с внешними сетями через другое устройство. Например, мое устройство PDA может связаться с источником данных посредством мобильного телефона; возможности такой опосредованной связи несколько ограничиваются тем фактом, что в процессе передачи данных устройства должны быть определенным образом физически ориентированы друг относительно друга — ограничение, отсутствующее в Bluetooth. Во-вторых, — и, пожалуй, это представляет даже больший интерес, — IrDA может привлекаться для организации совместного использования информации двумя различным устройствами; классическим примером этого может служить "переброска" ("beaming"), или "перекачка" ("squirting"), записи адресной книги с одного мобильного устройства на другое. Поскольку IrDA обеспечивает вполне приличную пропускную способность, с одного устройства на другое может быть "перекачано" довольно много информации.

Соединение равноправных узлов сети посредством IrDA

Сетям с соединениями равноправных узлов предшествовали сети с двухточечными соединениями, и это — парафия IrDA. Передача данных на основе IrDA предоставляет в наше распоряжение простой и относительно широкополосный механизм обмена данными между находящимися рядом с другом устройствами. Несмотря на отсутствие того "блеска новизны", который свойствен таким технологиям персональных сетей, как Bluetooth, у IrDA имеются и свои достоинства — она апробирована, тестирована и проста в использовании. Если ваши пользователи не имеют ничего против установки двух устройств друг напротив друга, то IrDA прекрасно подойдет для удовлетворения нужд вашего приложения, связанных с сетевыми технологиями, основанными на соединении равноправных узлов.

IrDA — это зрелая технология, которая часто остается незамеченной и незаслуженно мало используется разработчиками приложений. По моему мнению, это можно объяснить тем, что многие просто не знают, насколько простой в применении и гибкой является эта технология на самом деле. В .NET Compact Framework возможности программирования IrDA предоставляются посредством интерфейса сокетов, аналогичного тому, который используется при передаче данных посредством сервиса TCP/IP (Internet). Основное, что отличает использование сокетов в Internet-технологиях от использования сокетов в IrDA, — это понятие "именованного порта" ("named port").

Когда используются стек протоколов TCP/IP и сокеты, каждой машине назначаются собственный IP-адрес (например, 200.198.126.81) и номера портов, которые разрешается использовать для связи. Серверы открывают порты, которые они хотят прослушивать для получения запросов. Клиентское устройство может запросить связь с сервером путем указания IP-адреса машины и номера порта, к которому необходимо подключиться. В случае связи посредством двухточечных соединений технологии IrDA порт IrDA одного из устройств ориентируется в сторону другого устройства, в связи с чем отпадает необходимость в использовании схем адресации для установления местонахождения сервера. Если приложение желает предоставить интерфейс сокета IrDA для передачи контактной информации о своем владельце, оно может открыть сокет IrDA, которому присвоено имя OwnerContactInfo. Аналогичным образом, если приложение, играющее роль фотоальбома, должно обеспечивать возможность загрузки фотографий другими приложениями, оно может открыть сокет IrDA с именем PhotoDownloadService. Клиентские приложения на других устройствах, желающие подключиться к этим службам, запрашивают их по именам.

Сеанс связи между Web-браузером и сервером осуществляется примерно таким образом:

1. Сервер: открывает порт 80 для прослушивания поступающих запросов.

2. Браузер: "Привет, сервер номер 200.198.126.81. Я могу подключиться к порту 80?"

3. Сервер: "Да, можешь. Предлагаю соединение с портом, которое можно использовать для передачи данных."

4. Браузер: использует предложенное соединение и начинает обмен данными, в результате чего загружается несколько файлов

Аналогичный сеанс связи с использованием сокетов поверх IrDA осуществлялся бы примерно таким образом:

1. Принимающее устройство: создает именованный порт ReceiveAppXYZData.

2. Передающее устройство. "Привет, я хотело бы установить соединение с устройством, прослушивающим порт ReceiveAppXYZData."

3. Принимающее устройство: "Да, я прослушиваю этот порт. Давай установим соединение."

4. Передающее устройство: использует предоставленное соединение и начинает общение, в результате чего осуществляется передача данных.

Связь с использованием сокетов посредством IrDA является простым и эффективным способом обмена информацией, если два устройства физически располагаются рядом друг с другом.

Сокеты IrDA и .NET Compact Framework

Как ранее уже отмечалось, .NET Compact Framework предлагает интерфейс сокета для работы с IrDA Если вы знакомы с использованием сокетов для работы с сетью Internet (TCP/IP), то для того, чтобы использовать их для работы через IrDA, вам остается усвоить лишь несколько незначительных отличий. Использование сокетов IrDA для передачи данных между двумя устройствами иллюстрирует приведенный ниже код.

В настоящее время поддержка сокетов .NET для IrDA доступна лишь в .NET Compact Framework, тогда как в .NET Framework для настольных компьютеров она отсутствует

В версии 1.1 NET Compact Framework обеспечивается встроенная поддержка IrDA, но в версии 1.1 .NET Framework для настольных компьютеров она отсутствует. Это именно тот случай, когда путь к введению технологии, представляющей интерес для мобильных устройств, был проложен .NET Compact Framework. Возможно, будущие версии .NET Framework для настольных компьютеров обеспечат поддержку программирования сокетов IrDA, но до тех пор, пока это не произойдет, если вам понадобится связать между собой настольные компьютеры и .NET Compact Framework, то для доступа к функциональным возможностям IrDA на настольных компьютерах вам придется использовать вызовы функций в собственных кодах. В качестве положительного фактора можно отметить то обстоятельство, что такой собственный код для настольных компьютеров не будет слишком сложным, поскольку имеющиеся в Windows API-интерфейсы для работы с сокетами в собственных кодах поддерживают использование IrDA, причем код на С/С++ будет выглядеть примерно так же, как и коды на C# или VB.NET, которые вы использовали бы для устройства. Для более подробного изучения этого вопроса вам следует обратиться к разделам "IrDA Programming with Windows sockets" и "IrDA and Windows sockets reference" справочной документации Windows Platform SDK.

В приведенном в листингах 15.3, 15.4 и 15.6 коде показано, как организовать передачу содержимого файла с одного устройства на другое, используя IrDA. Для создания и запуска приложения необходимо выполнить следующие действия:

1. Запустите Visual Studio .NET (2003 или более позднюю версию) и выберите в качестве типа приложения C# Smart Device Application.

2. Выберите в качестве целевой платформы Pocket PC. (Для вас будет автоматически создан проект, и на экране появится окно конструктора форм Pocket PC.)

3. Добавьте в проект ссылку на System.NET.IrDA. По умолчанию ссылка на динамическую библиотеку System.NET.IrDA.DLL не включается в проект, поэтому ее необходимо добавить явно, чтобы соответствующее пространство имен стало доступным для вашего приложения.

Примечание. Библиотека System.NET.IrDA.DLL входит в основную часть .NET Compact Framework и присутствует на любом устройстве с установленной платформой .NET Compact Framework, только и того, что она не включается по умолчанию в проекты Visual .NET для устройств.

4. Добавьте в форму следующие элементы управления

а) кнопку; переименуйте ее в buttonTestFileSend.

б) кнопку; переименуйте ее в buttonTestFileReceive.

5. Выполните по отношению к каждой из вышеупомянутых кнопок следующие действия. Дважды щелкните на кнопке в окне конструктора форм. Включите в сгенерированную функцию обработчика событий код button<ИмяКнопки>_Click из листинга 15.3.Примечание. Не забудьте включить также остальную часть кода из листинга 15.3, не входящую в определения обеих указанных функций

6. Установите для свойства MinimizeBox формы значение false. Благодаря этому во время выполнения в верхней правой части формы появится кнопка OK, с помощью которой вы легко сможете закрыть форму и выйти из приложения. Эта возможность оказывается очень полезной при многократном тестировании приложения.

7. Добавьте в проект новый класс, присвойте ему имя IrDAFileSend и введите в новый класс код из листинга 15.4.

8. Добавьте в проект новый класс, присвойте ему имя IrDAFileReceive и введите в новый класс код из листинга 15.5.

9. Разверните и запустите приложение на двух различных устройствах Pocket PC (или смартфонах).

10. Щелкните на первом устройстве Pocket PC на кнопке TestFileReceive. Вы должны увидеть в заголовке окна приложения текст, говорящий о том, что ожидается поступление файла.

11. Щелкните на втором устройстве Pocket PC на кнопке TestFileSend. Вы должны увидеть в заголовке окна приложения текст, говорящий о том, что ожидается устройство, которому следует переслать файл.

12. Направьте IrDA-порты двух устройств друг на друга. Файл должен передаться с одного устройства на другое, а на обоих устройствах должны отобразиться окна сообщений, тексты которых указывают на успешное завершение передачи данных.

Результат: файл, находящийся на втором устройстве Pocket PC, передается на первое устройство. Чтобы это проверить, запустите на Pocket PC приложение File Explorer, перейдите в корневой каталог My Device и щелкните на имени файла myTestReceiveFile; это приведет к открытию и отображению файла в приложении PocketWord. После успешного тестирования приложения в синхронном режиме, попробуйте вызвать функции IrDA, обеспечивающие передачу и прием файла в асинхронном режиме. Вам придется написать код для потоков пользовательского интерфейса обоих устройств, который будет периодически опрашивать состояние классов IrDAFileSend или IrDAFileReceive, чтобы определить момент завершения пересылки файла.

В настоящее время код, использующий сокеты IrDA .NET Compact Framework, будет выполняться на таких физических устройствах, оборудованных аппаратурой IrDA, как Pocket PC и смартфоны, но не будет правильно выполняться на эмуляторах

Если вы попытаетесь создать сокет IrDA или соединиться с ним при помощи кода, выполняющегося на эмуляторах Pocket PC, смартфона или Windows СЕ, то, вероятнее всего, в процессе выполнения вашего приложения сгенерируется исключение. Это означает, что, в отличие от большинства других средств .NET Compact Framework, проектировать и тестировать код для IrDA следует с использованием реального физического устройства. Хотя эта трудность и не является непреодолимой, процесс проектирования и тестирования приложения из-за этого усложняется, поскольку для тестирования кода, обеспечивающего работу с IrDA, вам потребуется два физических устройства, одно из которых действует в качестве IrDA-сервера, а второе — IrDA-клиента. Вследствие этой дополнительной сложности код для обмена данными через IrDA рекомендуется писать и тестировать отдельно от остальной части приложения с использованием максимально упрощенной модели приложения, чтобы исключить любые возможные просчеты в организации процесса передачи данных. После устранения всех возможных неполадок из кода, обеспечивающего работу с IrDA, его можно будет перенести в полную версию приложения.

Листинг 15.3. Тестовый код, который необходимо поместить в класс формы для тестирования передачи и приема данных посредством механизма IrDA

//Имя, которое мы хотим присвоить сокету IrDA

const string myIrDASocketName = "IrDaTestFileTransmit";

private void buttonTestFileSend_Click(object sender, System.EventArgs e) {

//Создать простой текстовый файл, который мы хотим передать

const string fileName = "\\myTestSendFile.txt";

System.IO.StreamWriter textFileStream;

textFileStream = System.IO.File.CreateText(fileName);

textFileStream.WriteLine("Today...");

textFileStream.WriteLine("is а nice day");

textFileStream.WriteLine("to go swim");

textFileStream.WriteLine("in the lake");

textFileStream.Close(); IrDAFileSend irdaFileSend;

irdaFileSend = new IrDAFileSend(fileName, myIrDASocketName);

//Имеется 2 режима: 1 — Sync (синхронный), 2 — Async (асинхронный)

//1. Вызвать функцию в синхронном режиме

//и блокировать поток выполнения до тех пор,

//пока файл не будет передан

//1a. Вызвать функцию в синхронном режиме

//и блокировать поток выполнения до тех пор,

//пока файл не будет передан

this.Text = "Trying to send...";

//1b. Подождать, пока клиент не будет найден, а затем передать файл

irdaFileSend.LoopAndAttemptIRSend();

//1c. Информировать пользователя о том, что файл передан

System.Windows.Forms.MessageBox.Show("File sent!");

this.Text = "IrDA: Sent!";

//2. Вызвать функцию в асинхронном режиме и поручить

//передачу файла фоновому потоку

//irdaFileSend.LoopAndAttemptIRSendAsync();

//ПРИМЕЧАНИЕ: Если мы вызываем функцию в асинхронном режиме, то должны

//периодически проверять, не завершила ли она выполнение, путем

//вызова метода 'irdaFileSend.Status'

}

private void buttonTestFileReceive_Click(object sender, System.EventArgs e) {

//Если файл назначения уже существует, уничтожить его

const string fileName = "\\myTestReceiveFile.txt";

if (System.IO.File.Exists(fileName)) {

System.IO.File.Delete(fileName);

}

IrDAFileReceive irdaFileReceive;

irdaFileReceive = new IrDAFileReceive(fileName, myIrDASocketName);

//Имеется 2 режима: 1 - Sync (синхронный), 2 — Async (асинхронный)

//1. Вызвать функцию в синхронном режиме

//и блокировать поток выполнения до тех пор,

//пока файл не будет получен

//1a. Информировать пользователя о том, что мы ожидаем получения файла

this.Text = "Waiting to receive...";

//1b. Ожидать, пока не будет сделана попытка установления с нами связи

//и передачи файла

irdaFileReceive.WaitForIRFileDownload();

//1c. Информировать пользователя о том, что мы получили переданный файл

this.Text = "IrDA: received!";

System.Windows.Forms.MessageBox.Show("File received!");

//2. Вызвать функцию в асинхронном режиме и поручить

//получение файла фоновому потоку

//irdaFileReceive.WaitForIRFileDownloadAsync();

//ПРИМЕЧАНИЕ: Если мы вызываем функцию в асинхронном режиме, то должны

//периодически проверять, не завершила ли она выполнение, путем

//вызова метода 'irdaFileReceive.Status'

}

Листинг 15.4. Класс IrDAIrDAFileSend

//====================================================================

//Этот класс является клиентом IrDA. Он осуществляет поиск сервера

//IrDA, имя которого совпадает с именем службы IrDA, и после того, как

//он найден, направляет ему поток данных файла.

//====================================================================

class IrDAFileSend {

private string m_descriptionOfLastSendAttempt;

private string m_IrDAServiceName;

private string m_fileToSend;

private bool m_wasSenderStopped;

public enum SendStatus {

AttemptingToSend,

Finished_Successfully,

Finished_Aborted,

Finished_Error

}

private SendStatus m_SendStatus;

public SendStatus Status {

get {

//Блокировка выполнения параллельных операций чтения/записи в m_SendStatus

lock(this) {return m_SendStatus;}

}

}

private void setStatus(SendStatus newStatus) {

//Блокировка выполнения параллельных операций чтения/записи в m_SendStatus

lock(this) {m_SendStatus = newStatus;}

}

public string ErrorText {

get {return m_descriptionOfLastSendAttempt;}

}

//-----------

//КОНСТРУКТОР

//-----------

public IrDAFileSend(string fileToSend,string irdaServiceName) {

//Имя сокета IrDA, поиск которого мы хотим осуществить

m_IrDAServiceName = irdaServiceName;

//Файл, который мы хотим передать

m_fileToSend = fileToSend;

}

//--------------------------------------------------------------

//Запускает новый поток для осуществления попытки отправки файла

//--------------------------------------------------------------

public void LoopAndAttemptIRSendAsync() {

//Мы находимся в режиме передачи

setStatus(SendStatus.AttemptingToSend);

//Пользователь пока что не отменил выполнение операции

m_wasSenderStopped = false;

//Это функция, которую должен запустить на выполнение новый поток

System.Threading.ThreadStart threadEntryPoint;

threadEntryPoint = new System.Threading.ThreadStart(LoopAndAttemptIRSend);

//-----------------------------------

//Создать новый поток и запустить его

//-----------------------------------

System.Threading.Thread newThread = new System.Threading.Thread(threadEntryPoint);

newThread.Start(); //Вперед!

}

//-----------------------------------------------------

//Входит в цикл и пытается передать файл посредством IR

//-----------------------------------------------------

public void LoopAndAttemptIRSend() {

System.Net.Sockets.IrDAClient irDASender;

System.IO.Stream streamOutToIrDA;

System.IO.Stream streamInFromFile;

//Пользователь пока что не отменил выполнение операции

m_wasSenderStopped = false;

setStatus(SendStatus.AttemptingToSend);

//-----------------------------------------------------------------

//Непрерывное выполнение цикла, пока не удастся отправить сообщение

//-----------------------------------------------------------------

while(true) {

//Значения всех этих переменных должны быть нулевыми до и после

//вызова 'sendStream(...)', если не было сгенерировано исключение!

irDASender = null;

streamOutToIrDA = null;

streamInFromFile = null;

//Попытаться передать поток

bool bSuccess;

try {

bSuccess = sendStream(

out m_descriptionOfLastSendAttempt, ref streamOutToIrDA,

ref irDASender, ref streamInFromFile);

} catch (System.Exception eUnexpected) //Неожиданная ошибка!!!

{

setStatus(SendStatus.Finished_Error); //Отметить возникновение сбоя

m_descriptionOfLastSendAttempt =

"Unexpected error in IR send loop. " + eUnexpected.Message;

//------------------------------------------------

//Освободить все распределенные нами ранее ресурсы

//------------------------------------------------

if (streamOutToIrDA != null) {

try {

streamOutToIrDA.Close();

} саtch{};//Поглотить любую ошибку

streamOutToIrDA = null;

}

if (streamInFromFile != null) {

try {

streamInFromFile.Close();

} catch{};//Поглотить любую ошибку

streamInFromFile = null;

}

if (irDASender != null) {

try {

irDASender.Close();

} catch{}; //Поглотить любую ошибку

irDASender = null;

}

return; //Выход

}

//Проверить успешность выполнения

if (bSuccess == true) {

m_descriptionOfLastSendAttempt = "Success!";

setStatus(SendStatus.Finished_Successfully);

return;

}

//Проверить, не была ли операция отменена пользователем

if (m_wasSenderStopped == true) {

m_descriptionOfLastSendAttempt = "User Aborted.";

setStatus(SendStatus.Finished_Aborted);

return;

}

//B противном случае... Нам пока не удалось обнаружить сервер IrDA,

//имя которого совпадает с именем службы. Мы продолжим выполнение

//цикла и попытаемся найти сервер.

}

//Мы никогда не попадем в это место программы при выполнении

}

//Попытаться передать поток ввода-вывода (например, файл) посредством IR

//[возвращаемое значение]:

// true: успешная передача файла

// false: файл не был успешно передан

private bool sendStream(

out string errorDescription, ref System.IO.Stream streamOutToIrDA,

ref System.Net.Sockets.IrDAClient irDASender, ref System.IO.Stream streamInFromFile) {

errorDescription = "";

//----------------------------

//Создание нового клиента IRDA

//----------------------------

try {

//-------------------------------------------------------

//Возврат произойдет довольно быстро. Клиент будет выбран

//и возвращен, если прослушивающие клиенты отсутствуют.

//-------------------------------------------------------

irDASender = new System.Net.Sockets.IrDAClient(m_IrDAServiceName);

} catch (System.Exception eCreateClient) {

//B данном случае могло возникнуть несколько ситуаций:

//#1: отсутствуют прослушивающие устройства

//#2: прослушивающее устройство существует, но не реагирует

// (может отказаться от разговора)

errorDescription = eCreateClient.Message;

return false;

}

//B данном случае могло возникнуть несколько ситуаций:

//#1: Мы получили соединение от приемного устройства IR

//#2: IR-запрос был отменен (кто-то вызвал функцию STOP).

if (m_wasSenderStopped == true) {

irDASender.Close();

irDASender = null;

return false;

}

//==========================================

//ПЕРЕДАТЬ ДАННЫЕ!

//==========================================

//Открыть файл, который мы хотим передать

streamInFromFile = System.IO.File.OpenRead(m_fileToSend);

//Открыть сокет IrDA, которому мы хотим передать данные

streamOutToIrDA = irDASender.GetStream();

const int BUFFER_SIZE = 1024;

byte[] inBuffer = new byte[BUFFER_SIZE];

int bytesRead;

int iTestAll = 0;

int iTestWrite = 0;

do {

//Считать байты из файла

bytesRead = streamInFromFile.Read(inBuffer, 0, BUFFER_SIZE);

iTestAll = iTestAll + 1;

//Записать байты в наш выходной поток

if (bytesRead > 0) {

streamOutToIrDA.Write(inBuffer, 0, bytesRead);

iTestWrite = iTestWrite + 1;

}

} while (bytesRead > 0);

//Сбросить выходной поток

streamOutToIrDA.Flush(); //Закончить запись любых данных

streamOutToIrDA.Close(); //Закрыть поток

streamOutToIrDA = null;

//Освободить локальный файл

streamInFromFile.Close();

streamOutToIrDA = null;

//Освободить порт IrDA

irDASender.Close();

irDASender = null;

//Успешное завершение!!!

return true;

}

} //конец класса

Листинг 15.5. Класс IrDAFileReceive

//-------------------------------------------------------------------

//Обеспечивает прием файла через IrDA (инфракрасный порт).

//

//Этот класс НЕ является реентерабельным и не должен вызываться более

//чем одной функцией за один раз. Если необходимо иметь несколько

//сеансов связи через IR, это необходимо делать путем создания

//нескольких различных экземпляров данного класса.

//-------------------------------------------------------------------

public class IrDAFileReceive {

private bool m_wasListenerStopped;

private string m_IrDAServiceName;

private string m_fileNameForDownload;

private string m_errorDuringTransfer;

private System.Net.Sockets.IrDAListener m_irListener;

private ReceiveStatus m_ReceiveStatus;

public string ErrorText {

get {

return m_errorDuringTransfer;

}

}

//--------------------------

//Различные состояния приема

//--------------------------

public enum ReceiveStatus {

NotDone_SettingUp,

NotDone_WaitingForSender,

NotDone_Receiving,

Done_Success,

Done_Aborted,

Done_ErrorOccured

}

//------------------------------

// Возвращает состояние передачи

//------------------------------

public ReceiveStatus Status {

get {

//Обеспечить многопоточную безопасность для предотвращения

//параллельного выполнения операций чтения/записи

lock(this) {

return m_ReceiveStatus;

} //конец lock

} //конец get

} //конец свойства

private void setStatus(ReceiveStatus newStatus) {

//Обеспечить многопоточную безопасность для предотвращения

//параллельного выполнения операций чтения/записи

lock(this) {

m_ReceiveStatus = newStatus;

} //конец lock

}

//--------------------------------------------------

// [in] filename: желаемое имя для входного файла IR

//--------------------------------------------------

public IrDAFileReceive(string filename, string irdaServiceName) {

//Имя сокета IrDA, который мы хотим открыть

m_IrDAServiceName = irdaServiceName;

//Имя файла, в котором мы хотим сохранить полученные данные

m_fileNameForDownload = filename;

}

//----------------------------------------------------------

//Обеспечивает асинхронный прием файла через IR

//

// [in] filename: имя файла, в который осуществляется запись

//----------------------------------------------------------

public void WaitForIRFileDownloadAsync() {

//Заметьте, что сейчас мы находимся в режиме подготовки

setStatus(ReceiveStatus.NotDone_SettingUp);

//-------------------

//Создать новый поток

//-------------------

System.Threading.ThreadStart threadEntryPoint;

threadEntryPoint =

new System.Threading.ThreadStart(WaitForIRFileDownload);

System.Threading.Thread newThread = new System.Threading.Thread(threadEntryPoint);

//Запустить поток на выполнение

newThread.Start();

}

//------------------------------------------

//Открывает порт IR и ожидает загрузки файла

//------------------------------------------

public void WaitForIRFileDownload() {

System.IO.Stream outputStream = null;

System.Net.Sockets.IrDAClient irdaClient = null;

System.IO.Stream irStreamIn = null;

try {

//=========================================================

//Задать и загрузить файл!

//=========================================================

internal WaitForIRFileDownload(ref outputStream,ref irdaClient, ref irStreamIn);

} catch

//Поглотить любые возникающие ошибки

{

setStatus(ReceiveStatus.Done_ErrorOccured);

}

//=============================================

//Освободить все ресурсы

//=============================================

//Закрыть наш входной поток

if (irStreamIn != null) {

try {

irStreamIn.Close();

} catch {} //Поглотить любые возникающие ошибки

}

//Закрытие клиента IrDA

if (irdaClient != null) {

try {

irdaClient.Close();

} catch {} //Поглотить любые возникающие ошибки

}

//Закрыть файл, в который осуществлялась запись

if (outputStream != null) {

try {

outputStream.Close();

} catch {} //Поглотить любые возникающие ошибки

}

//Закрыть прослушивающее устройство, если оно выполняется

if (m_irListener != null) {

//Установить первым, чтобы код, выполняющийся другим потоком,

//был отменен, если он установлен

m_wasListenerStopped = true;

try {

m_irListener.Stop();

} catch {} //Поглотить любые возникающие ошибки

m_irListener = null;

}

}

private void internal_WaitForIRFileDownload(

ref System.IO.Stream outputStream,

ref System.Net.Sockets.IrDAClient irdaClient,

ref System.IO.Stream irStreamIn) {

//---------------------------------------------------------

//Открыть входной файл для направления в него потока данных

//---------------------------------------------------------

outputStream = System.IO.File.Open(m_fileNameForDownload, System.IO.FileMode.Create);

//==========================================

//ОБНОВЛЕНИЕ СОСТОЯНИЯ

//==========================================

setStatus(ReceiveStatus.NotDone_WaitingForSender);

//---------------------------------

//Открыть прослушивающее устройство

//---------------------------------

try {

m_wasListenerStopped = false;

m_irListener = new System.Net.Sockets.IrDAListener(m_IrDAServiceName);

m_irListener.Start();

} catch (System.Exception eListener) {

m_errorDuringTransfer = "Error creating listener - " + eListener.Message;

goto exit_sub_with_error;

}

//Проверить, не поступила ли команда отменить выполнение

if (m_wasListenerStopped == true) {

goto exit_sub_with abort;

}

//------------------

//Принять соединение

//------------------

try {

//--------------------------------------------------------------------

//Выполнение будет приостановлено здесь до тех пор, пока устройство не

//начнет передавать информацию, или не будет остановлен объект

//прослушивания, выполняющийся в другом потоке)

//--------------------------------------------------------------------

irdaClient = m_irListener.AcceptIrDAClient();

} catch (System.Exception eClientAccept) {

//Если прослушивание остановлено другим потоком, инициировавшим отмену

//выполнения, будет сгенерировано исключение и управление будет

//передано сюда.

if (m_wasListenerStopped == true) {

goto exit_sub_with_abort;

}

//Если прослушивание не было прекращено,

//то произошло иное исключение. Обработать его.

m_errorDuringTransfer = "Error accepting connection - " + eClientAccept.Message;

goto exit sub_with error;

}

//B этом месте возможны два состояния:

//#1: Мы получили соединение от передающего устройства IR

//#2: IR-запрос был отменен (кто-то вызвал функцию STOP)

// (в этом случае приведенный ниже код сгенерирует исключение)

//Проверить, не было ли отменено выполнение

if (m_wasListenerStopped == true) {

goto exit_sub_with_abort;

}

//==========================================

//ОБНОВЛЕНИЕ СОСТОЯНИЯ

//==========================================

setStatus(ReceiveStatus.NotDone_Receiving);

//-------------------------

//Открыть принимающий поток

//-------------------------

try {

irStreamIn = irdaClient.GetStream();

} catch (System.Exception exGetInputStream) {

m_errorDuringTransfer = "Error getting input stream - " + exGetInputStream.Message;

goto exit_sub_with_error;

}

//Приготовиться к получению данных!

const int BUFFER_SIZE = 1024;

byte[] inBuffer = new byte[BUFFER_SIZE];

int bytesRead = 0;

do {

//Считать байты из порта IR

bytesRead = irStreamIn.Read(inBuffer, 0, BUFFER_SIZE);

//Записать байты в наш выходной поток

if (bytesRead > 0) {

outputStream.Write(inBuffer, 0, bytesRead);

}

} while (bytesRead > 0);

outputStream.Flush(); //Закончить запись любых выходных данных

//==========================================

//ОБНОВЛЕНИЕ СОСТОЯНИЯ: УСПЕШНО ВЫПОЛНЕНО

//==========================================

setStatus(ReceiveStatus.Done_Success);

return; //Ошибки отсутствуют

//==========================================

//ОШИБКА...

//==========================================

exit_sub_with_abort:

//ОБНОВЛЕНИЕ СОСТОЯНИЯ: Отменено (но не из-за ошибки)

setStatus(ReceiveStatus.Done_Aborted);

return;

exit_sub_with_error:

//ОБНОВЛЕНИЕ СОСТОЯНИЯ: ОШИБКА!!!!

setStatus(ReceiveStatus.Done_ErrorOccured);

}

} //конец класса

Карты памяти

Прежде чем появились недорогие широко развертываемые сетевые технологии, существовало понятие "сетей доставки ‘на своих двоих’" ("sneakernet"). Именно так шутливо называли перенос данных с одного компьютера на другой путем их сохранения на физических носителях, например магнитных дисках; роль сетевых транспортных средств играли люди, а роль пакетов — физические носители информации. При наличии замечательных сетевых технологий, доступных сегодня, легко забыть о том, насколько полезными могут быть физически перемещаемые хранилища информации. Во многих случаях наиболее быстрым практическим способом переноса больших объемов данных с одного компьютера или мобильного устройства на другой компьютер/устройство является запись данных в памяти карты и физический перенос карты на другое устройство.

Современные съемные карты памяти обладают ошеломляющей емкостью; 256 Мбайт — обычное явление, 512 Мбайт — не столь уж большая редкость, а карты памяти емкостью 1 Гбайт доступны по вполне разумной цене. Емкость карт памяти продолжает расти по экспоненциальному закону. На рынок поступают карты памяти в самом различном исполнении, в том числе ключи памяти, присоединяемые к разъемам USB, карты Compact Flash, которые без труда подключаются к разъемам PCMCIA лэптопов через недорогие переходники, и карты Secure Digital Большинство этих средств хранения данных после вставки их в мобильное устройство или компьютер ведут себя просто как съемный жесткий диск.

У подхода, основанного на сетях с доставкой данных "на своих двоих", имеется множество достоинств, делающих его удобным для передачи больших объемов данных. Такие развернутые на устройствах базы данных, как SQL СЕ, могут храниться на картах памяти и заполняться большими объемами фактических данных вместе с другими необходимыми данными, например изображениями. Карты памяти могут загружаться данными на компьютере, после чего эти данные можно выгружать на мобильные устройства, в соответствии с необходимостью; таким образом, одновременное подключение к сети и сервера, и клиента данных в данном случае не требуется. Рассматривая карты памяти как коммуникационный механизм, можно считать, что они представляют собой решение, основанное на пакетной обработке данных; карты памяти обеспечивают групповое перемещение больших объемов данных, но не поддерживают тех возможностей оперативного обновления данных, которые предоставляет сеть. Полезной является модель, в соответствии с которой карты памяти используются для первоначального перемещения многочисленных данных, минуя сеть, тогда как последующее обновление данных осуществляется посредством передачи их по сети. Карты памяти представляют собой коммуникационный механизм, технический уровень которого невысок, но это не может служить основанием для полного отказа от их использования.

Принудительная перекачка информации на устройства

Тот факт, что значительная часть работы при обмене данными с использованием мобильных устройств сосредотачивается на мобильном устройстве, инициирующем сеанс связи с сервером, не является случайным. После установления соединения с сервером не составляет труда отправить данные на сервер или получить данные с сервера. В большинстве случае при связи с серверами используются такие абстракции, как сокеты или HTTP, построенные поверх протоколов Internet TCP/IP. В случае связи с использованием протоколов TCP/IP каждое устройство в сети имеет собственный IР-адрес. IP-адрес весьма напоминает телефонный номер, однако есть одна трудность, состоящая в том, что некоторые IP-адреса являются постоянными, другие — существуют длительное время, но есть и такие, срок действия которых весьма незначителен. Осознание непостоянства некоторых IP-адресов необходимо для понимания того, какие коммуникационные модели приемлемы для практического применения на мобильных устройствах, а какие — неприемлемы.

IР-адреса Internet-серверов изменяются редко. Кроме того, существуют механизмы поиска IP адресов по дружественным именам URL. Самой популярной службой поиска имен в Internet является DNS, название которой — это аббревиатура от Domain Naming System (система именования доменов); эта служба транслирует дружественные имена, например, www.microsoft.com или www.yahoo.com, в IР-адреса. DNS-серверы поддерживают реплицируемые базы данных, которые преобразуют имена в IР-адреса. Это работает хорошо, поскольку IP-адреса серверов изменяются редко.

Аналогичным образом все это работает и в пределах интрасетей. Имя сервера, настольного компьютера или лэптопа регистрируется и связывается с IP-адресом. Иногда эти адреса являются фиксированными, но обычно внутренние адреса назначаются компьютерам так называемыми DHCP-серверами. Аббревиатура DHCP происходит от Dynamic Host Configuration Protocol — протокол динамической конфигурации хоста, и, как нетрудно догадаться, роль DHCP-сервера заключаются в присвоении IР-адресов тем компьютерам-клиентам, которые это запрашивают. Опять-таки, предполагается. что эти IP-адреса изменяются не очень часто. Сервер, часто изменяющий свой IP-адрес, будет дополнительно нагружать сеть, поскольку этот адрес будет требовать постоянного обновления и вынуждать клиентские компьютеры к проведению поиска. Частое появление и исчезновение в сети устройств, вызванное их непрерывным перемещением между различными участками сети или частым включением и отключением, также будет приводить к частой смене их IР-адресов.

Если сфера использования мобильного устройства ограничивается сетью определенной топологии (например, одной корпоративной сетью), то все проблемы, связанные с его адресацией, можно преодолеть сравнительно легко. В этом случае можно поступить двояким образом: 1) ограничиться назначением мобильному устройству фиксированного IP адреса, что было бы самым простым, но при этом наименее гибким решением, или 2) создать пользовательский сервер отображения адресов, вызываемый устройствами для регистрации своих IP-адресов всякий раз, когда они изменяются; остальные устройства могут запрашивать у этого сервера адрес любого конкретного устройства.

Для устройств, которые могут мигрировать между различными сетями, проблема значительно усложняется. Статические IP-адреса использовать нельзя, поскольку они должны быть разрешены действующей сетью, но любой заданный адрес, который хотело бы использовать устройство, уже мог быть до этого назначен или зарезервирован в данной сети. При наличии прокси-серверов, трансляторов сетевых адресов (Network Address Translators — NAT) или брандмауэров (firewalls) возникают дополнительные проблемы. Прокси-серверы, NAT и брандмауэры разрешают лишь определенные виды исходящих запросов и передают ответы на них тем вычислительным устройствам, которыми эти запросы были направлены; поступления же нежелательных запросов на устройства, находящиеся внутри сети, они, как правило, не допускают. Находящиеся внутри сети устройства, которые посылают запросы серверу, не обязаны знать ничего об этих тонкостях, но о них должно быть известно любой стороне, пытающейся получить доступ к устройству извне сети.

Результатом всего вышеизложенного является то, что для мигрирующих мобильных устройств передача запросов другим устройствам весьма затрудняется; универсальной модели, которая могла бы удовлетворительно справиться с этой задачей, не существует. Вследствие этого возникает определенная асимметрия; получается так, что посылка запросов устройствами осуществляется гораздо проще, чем посылка запросов устройствам.

Не решаются ли все эти проблемы набором протоколов IPv6?

Ответ таков: "В перспективе — возможно", однако, как сказал известный экономист Мейнард Кинис (Maynard Keyneys): "В делах повседневных перспектива — плохой советчик. В перспективе нас всех ожидает смерть". Пройдет немало лет, пока IPv6 прочно утвердится в мире, но в любом случае такие компоненты сетевой безопасности, как брандмауэры, просуществуют еще очень долго. Как следствие, адресовать серверы по- прежнему будет проще, чем мобильные устройства. Для адресации мобильных устройств, непрерывно мигрирующих между различными сетевыми топологиями, будут требоваться специальные механизмы.

В некоторых случаях полезно иметь возможность принудительной перекачки информации на мобильное устройство. Как ранее уже отмечалось, в случае стационарных пользовательских сетевых топологий это не составляет особого труда; мобильное устройство может иметь фиксированный или специальным образом зарегистрированный IP-адрес, так что ему остается только открыть сокет и дожидаться поступления запросов. Для универсальных мобильных устройств, мигрирующих между различными сетями, это представляет определенные трудности. Имеется несколько путей преодоления этих проблем:

■ Мобильные телефоны могут использовать механизм SMS-сообщений. Большинство современных мобильных телефонов поддерживают широко популярный механизм сообщений SMS (Short Message Service), который очень хорошо приспособлен для передачи коротких потоков данных на устройства. Служба SMS предлагает удобную универсальную схему адресации — телефонный номер устройства. Как правило, SMS-сообщения являются текстовыми и предназначаются для прочтения пользователем, но это не исчерпывает всего круга их возможных применений. Поскольку длина SMS-сообщений ограничена примерно 160 символами, неплохой моделью, позволяющей использовать SMS-сообщения для закачки информации на устройства, является так называемая "двухтактная" ("push to pull") модель; прибытие определенного SMS-сообщения запускает локальное приложение, осуществляющее доступ к серверу и загрузку большего объема информации.

■ Сообщения электронной почты. Многие мобильные устройства с достаточно богатым набором функциональных возможностей поддерживают получение уведомлений по электронной почте с использованием либо специально назначенного для данного телефона почтового адреса, либо обычного электронного почтового адреса пользователя. Передача устройству определенных сообщений, которые должны интерпретироваться локальным приложением, открывает широкие возможности для принудительной закачки данных на устройство.

■ Опрос. Суть опроса (polling) заключается в периодическом опрашивании устройством сервера для выяснения того, не находится ли на сервере информация, которая еще не была передана на устройство.

Из трех вышеописанных механизмов опрос является наименее сложным и во многом — простейшим для реализации. Привлекать другие механизмы следует лишь в тех случаях, когда решение, основанное на механизме опроса, по тем или иным причинам использовать не удается.

В настоящее время при разработке приложений в рамках .NET Compact Framework версии 1.1 встроенная библиотечная поддержка получения или просмотра поступающих сообщений электронной почты или SMS-сообщений не предоставляется; для этого приходится писать функции в собственных кодах и выполнять сложные операции. Доступ к поступающим сообщениям электронной почты и SMS-сообщениям не является чем-то неосуществимым, однако требует выполнения большого объема работы. Эта работа будет оправдана лишь в том случае, если для удовлетворения потребностей вашего мобильного приложения возможностей менее элегантных, но более простых решений оказывается недостаточно. Написание низкоуровневого кода для обработки сообщений — вещь интересная, но вряд ли когда-либо эту работу можно выполнить в сжатые сроки; всегда оценивайте альтернативные возможности и принимайте взвешенные решения.

Организация доступа к поступающим SMS-сообщениям на устройствах Microsoft Smartphone

Для работы с SMS-сообщениями в операционной системе Microsoft Smartphone существует два способа: 1) работа на низком уровне путем создания собственного фильтра для проверки поступающих сообщений, или 2) работа на высоком уровне с использованием интерфейса прикладного программирования CEMAPI (СЕ Messaging API) для просмотра сообщений после того, как они поступили. В настоящее время оба эти способа требуют использования собственных кодов С/С++ для доступа к необходимым функциональным средствам операционной системы.

1. Создание собственного низкоуровневого фильтра для поступающих SMS-сообщений

Операционная система Smartphone предлагает опытным разработчикам два способа регистрации собственных фильтров, предназначенных для обработки SMS- сообщений. Это можно сделать путем создания и регистрации SMS-поставщика на устройстве или путем создания и регистрации компонента, реализующего интерфейс IMailRuleClient.

В принципе, оба эти подхода аналогичны разработке ISAPI-фильтра для сервера Internet Information Server; могут выполняться одновременно несколько фильтров, и запрос дескриптора передается первому из фильтров, критерии которого согласуются с поступающими запросами. (Например, в случае ISAPI-фильтров запросы Web-страницы *.ASP маршрутизируются на один дескриптор, а запросы Web-страницы *.ASPX — на другой, исходя из расширения файла.) Создание ISAPI-фильтра для Internet Information Server — задача нелегкая, требующая тщательного проектирования и тестирования. Точно так же как почти никому из Web-разработчиков не требуется использование собственных ISAPI-фильтров, создание собственных SMS-поставщиков или компонентов IMailRuleClient может понадобиться разработчикам мобильных приложений лишь в редких случаях. Тем не менее, если на первый план выходит гибкость, ее необходимо обеспечивать именно таким способом.

• SMS-поставщики

SMS-поставщики должны проверять заголовки поступающих SMS-сообщений и принимать решения относительно того, какому приложению следует доставить то или иное сообщение. Это относится как к двоичным, так и к текстовым SMS-сообщениям. Однако на практике многие "заблокированные" смартфоны не позволят вам реализацию собственного SMS-поставщика, поскольку это может нарушить политику безопасности, принятую изготовителем телефона.

Более подробную информацию относительно создания SMS-поставщиков вы сможете найти в справочной документации по Smartphone SDK, проведя поиск по термину "SMS Provider" или просмотрев раздел "Short Message Service" комплекта справочной документации "Smartphone Adaptation Kit for Mobile Operators".

• IMailRuleClient

Для устройств Smartphone 2003 и более поздних моделей можно реализовать и зарегистрировать компонент, реализующий интерфейс IMailRuleClient. Этому высокоуровневому, по сравнению с созданием SMS-поставщика, подходу следует отдавать предпочтение, поскольку он ориентирован на разработчиков приложений, а не на операторов сетей мобильной связи, выпускающих телефоны.

Интерфейс IMailRuleClient позволяет компоненту проверять входящие SMS-сообщения и отвечать на них. Такой подход может оказаться более легким в реализации по сравнению с написанием кода собственного SMS-поставщика, но для этого необходимо еще, чтобы компонент был подписан разрешенным криптографическим ключом, если этого требует изготовитель телефона. Более подробную информацию относительно интерфейса IMailRuleClient вы сможете найти, проведя в оперативной справочной документации MSDN поиск по ключевым словам "IMailRuleClient" или "CEMAPI".

2. Использование CEMAPI для высокоуровневого доступа к SMS-сообщениям

Интерфейс CEMAPI предлагает высокоуровневый механизм доступа к текстовым SMS- сообщениям, которые были маршрутизированы на почтовый ящик смартфона. CEMAPI предлагает набор интерфейсов для навигации по хранилищу сообщений устройства, а также создания и просмотра сообщений. Ваше мобильное приложение может периодически опрашивать папку входящих сообщений устройства с целью проверки того, не поступили ли новые сообщения, предназначенные для этого приложения. Для получения более подробной информации относительно порядка работы с папкой входящих сообщений Pocket PC или смартфона выполните в комплекте справочной документации Smartphone SDK поиск по ключевому слову "CEMAPI".

Web-службы

Промышленная поддержка Web-служб настолько обширна, что эту технологию просто невозможно игнорировать. Подобно технологиям, основанным на HTML, Web-службы создают оболочки вокруг коммерческих источников информации и предоставляют интерфейсы для доступа к ним со стороны других приложений-Web- службы позволяют приложениям обмениваться информацией с использованием общего высокоуровневого стандартизированного языка, основанного на XML.

Первоначальная задача HTML заключалась в том, чтобы обеспечить возможность связывания текстовых документов между собой в сети взаимными ссылками. Эта идея оказалась настолько плодотворной, что поверх модели представления документов были построены программные модели, сделавшие возможной динамическую генерацию документов; HTML вышел далеко за рамки первоначально отведенных для него границ. Сначала Web-службы предназначались для того, чтобы позволить различным серверам общаться друг с другом с использованием стандартного коммуникационного протокола на основе XML. Точно так же как и HTML, технологии Web-служб вышли далеко за первоначально запланированные рамки, и в настоящее время широко применяются также для связывания клиентских и серверных приложений между собой.

Вызов Web-службы приложением, развернутым на настольном компьютере, — довольно тривиальная задача. Современные настольные компьютеры большую часть времени работают, будучи подключенными к сети, и в настоящее время имеются все возможности доступа к быстродействующим сетям, обеспечивающим связь с высокой пропускной способностью и малыми временами задержек. Сфера применения Web-служб значительно расширяется за счет использования мобильных устройств, но для того, чтобы работа с Web-службами могла вестись эффективно, разработчики, настраивая мобильное приложение соответствующим образом для взаимодействия с Web-службами, должны учитывать различия в способах установки соединений, ширине полосы пропускания и временах задержки.

Очень краткое описание Web-служб

В настоящее время доступен огромный объем литературы, посвященной описанию технологий Web-служб. Эта информация представлена как в виде оперативной справочной документации, так и в виде книг. Для подробного ознакомления с Web- службами я рекомендую начать с комплекта оперативной справочной документации MSDN. Вместе с тем, с целью создания определенной методологической основы для последующего обсуждения методов вызова Web-служб с мобильных устройств вашему вниманию предлагается очень краткое описание Web-служб.

Web-службы используют специальным образом форматированные XML-сообщения для передачи и получения запросов, связанных с предоставлением определенных услуг вычислительного характера. "Вызов" Web-службы — это направляемый одним вычислительным устройством другому запрос выполнения определенного вида обработки, завершение которой обычно сопровождается возвращением результата. Web- службы характеризуются следующими признаками:

■ Использование протокола SOAP. SOAP — это простой протокол доступа к объектам (Simple Object Access Protocol), являющийся диалектом XML. Наиболее распространенная сфера применения SOAP — вызов методов на сервере и получение ответных результатов. SOAP упаковывает имя затребованного метода вместе с параметрами в XML и доставляет эти XML-данные на сервер для обработки. Сервер получает запрос SOAP в форме XML, анализирует его для извлечения имени и параметров метода, после чего вызывает этот метод. По завершении обработки метода сервером результат SOAP возвращается клиенту в виде XML. Клиент анализирует возвращенные XML-данные, извлекает результаты и предоставляет их вызывающей программе.

■ Использование WSDL-документов. WSDL — это язык описания Web-служб (Web Service Description Language). WSDL-документ — это диалект XML, предназначенный для описания служб. WSDL-документ детализирует, какими методами располагает Web-служба, какие параметры принимает каждый из методов, и что собой представляют возвращаемые методами значения. В типичных случаях WSDL-документы генерируются машиной и возвращаются по запросу от сервера Web-служб. Инструментальные программные средства разработки загружают WSDL-документы с серверов Web-служб и генерируют код на стороне клиента, позволяющий упростить вызов описанных Web-служб на этих серверах. С каждой Web-службой связан ее собственный WSDL-документ.

■ Возможное использование коммуникационных протоколов HTTP и HTTPS для генерации запросов и получения ответов. Хотя с теоретической точки зрения Web-службы могут выполняться с использованием самых различных коммуникационных транспортных средств, включая простой протокол электронной почты SMTP, на практике большинство запросов Web-служб пересылаются посредством протоколов HTTP или HTTPS. Это означает, что большинство Web-служб выполняются на Web-серверов тех же видов, которые обслуживают приложения на основе HTML. Это обстоятельство особенно полезно по той причине, что запросы HTTP и HTTPS обычно пропускаются брандмауэрами, благодаря чему доступ к Web-службам оказывается столь же простым, что и доступ к Web- страницам. Если данный Web-сервер доступен вашему мобильному приложению, то возможен и доступ к Web-службам, выполняющимся на этом сервере.

В дополнение к этим базовым характеристикам Web-служб разрабатываются дополнительные слои технологии, располагающиеся поверх SOAP и WSDL, которые позволят удовлетворить запросы более сложной природы. Например, такие спецификации, как WS-Reliability и WS-Security, обеспечивают потребности в надежной доставке информации и встроенных средствах безопасности. Постоянно создаются, обсуждаются, развиваются и стандартизируются и другие спецификации. На протяжении ближайших 10 лет технологии Web-служб будут интенсивно расширяться и развиваться. Инструментальные средства программирования и каркасы, использующие все преимущества этих стандартов, будут, как правило, отставать от вновь возникающих стандартов примерно на несколько лет.

Вызов Web-служб с мобильного устройства

Способность мобильных устройств взаимодействовать с теми же типами Web- серверов, с которыми могут взаимодействовать приложения настольных компьютеров и серверов, — это великое благо для разработчиков мобильных приложений. Любое устройство, которое может получать доступ к Web-страницам, располагает встроенными возможностями установки соединений, необходимыми для вызова Web-служб.

Одно дело — иметь возможность вызывать Web-службы, и совершенно другое — иметь возможность делать это легко. Обращаясь к аналогии, можно заметить, что загрузка HTML-документа не составляет труда, однако для визуального представления информации в виде, приемлемом для конечного пользователя, необходимо выполнить значительный объем работы по преобразованию HTML-документа. В связи с этим для облегчения работы с Web-службами предусмотрены программные библиотеки различных уровней. В порядке повышения уровня абстракции этими уровнями являются следующие:

■ Возможность выполнять HTTP/HTTPS-запросы. Теоретически, если ваше мобильное приложение способно направлять запросы Web-серверу, то оно способно также вызывать Web-службы.

■ Возможность генерировать и анализировать XML-документы. Поскольку языком общения с Web-службами является XML, способность генерировать и анализировать XML-документы значительно упрощает работу с Web-службами.

■ Возможность генерировать и анализировать сообщения SOAP. Сообщения SOAP представляют собой специальные грамматические конструкции, построенные поверх XML. Гораздо легче использовать библиотеку программ, которая позволяет вашему приложению работать на концептуальном уровне запросов и ответов SOAP, чем вручную создавать запросы и интерпретировать ответы, поступающие в виде XML.

■ Возможность автоматически генерировать прокси-код для приложений-клиентов Web-служб. Некоторые средства разработки программного обеспечения обеспечивают загрузку WSDL-документов, описывающих Web-службы, и автоматическую генерацию кода клиента Web службы, необходимого для создания запросов SOAP и анализа возвращенных ответов SOAP. Автоматическая генерация кода клиентов Web-служб упрощает вызов этих служб. Вместо того чтобы писать код для построения SOAP-запросов вручную, отправки этих запросов на серверы и анализа возвращаемых результатов, разработчики могут рассматривать запросы Web-служб как обычные вызовы методов. Например, Web-службу, осуществляющую сложение двух чисел, можно просто вызвать следующим образом:

MyWebService myWS = new MyWebService();

int result = myWS.AddTwoNumbers(2, 8);

Вся логика, необходимая для создания запросов SOAP, отправки их на сервер и анализа ответа SOAP, содержится в прокси-классе с именем MyWebService на стороне клиента Web-служб.

Все вышеописанные уровни абстракции поддерживаются в .NET Compact Framework в той же мере, что и в версии .NET Framework для настольных компьютеров и серверов. Во время написания данной книги некоторые из вышеперечисленных верхних уровней абстракции другими технологиями (например, J2ME, собственные коды) не поддерживались, но значение технологии Web-служб настолько велико, что простые процедуры вызова Web-служб, по всей видимости, будут предусмотрены почти во всех версиях программных каркасов для мобильных устройств. Вместе с тем, на развертывание сред выполнения для мобильных устройств должно уйти некоторое время (во многих случаях развертывание новых сред выполнения и библиотек должно сопровождаться внедрением нового оборудования), и если вы работаете с программными технологиями для мобильных устройств, которые в настоящее время встроенной поддержки Web-служб не имеют, то должны быть готовы к написанию дополнительного низкоуровневого кода, обеспечивающего генерацию запросов и анализ ответов.

Создание Web-службы с использованием .NET

Чтобы создать Web-службу для целей тестирования, вы должны запустить сервер Internet Information Server (IIS) либо на собственном локальном настольном компьютере, либо на сервере, доступном для тестируемого мобильного устройства. Для инсталляции IIS потребуется также наличие соответствующих серверных расширений, обеспечивающих функционирование вашего средства разработки; в конфигурировании этих расширений на IIS вам поможет инсталлятор Visual Studio .NET.

Для создания Web-службы необходимо выполнить следующие действия:

1. Запустите Visual Studio .NET и создайте новый проект C# ASP.NET Web service. Средство разработки попросит вас указать местоположение Web-службы. Указав, например, адрес http://localhost/WebService1, вы coздaдитe Web-cлyжбy на локальном компьютере, тогда как указание адреса http://MyWebServer/WebService1 приведет к созданию Web-службы с именем WebService1 на сервере с именем MyWebServer.

Результат: будет создан класс Service1, а на указанном вами Web-сервере будет развернут файл Service1.asmx.

2. Создайте в классе Service1 общедоступный Web-метод. Приведенный в листинге 15.6 код соответствует простому методу, предоставляющему себя в качестве Web-службы. Введите код в класс Service1, созданный вами на шаге 1.

3. Чтобы развернуть и запустить на выполнение проект Web-службы, нажмите клавишу <F5>. Для Web-службы будет автоматически создана Web-страница, показывающая, какие методы предоставляются Web-службой, и позволяющая вызывать эти методы через Web-браузер. Чтобы протестировать Web-службу, используйте Web-браузер для перехода по адресу Web-службы и класса, указанных вами на шагах 1 и 2 (например, http://MyWebServer/WebService1/Service1.asmx).

Листинг 15.6. Простая Web-служба

//Этот код следует вставить в класс Service1, содержащийся //в файле "Service1.asmx". //

//"[WebMethod]" - это атрибут метаданных, который указывает механизму Web- // службы на то, что данный метод должен быть доступным через Web

[WebMethod]

public int AddTwoNumbers(int x,int у) {

return x + у;

}

Вызов Web-службы с устройства средствами .NET Compact Framework

НА ЗАМЕТКУ

Для выполнения кода на физическом или эмулированном устройстве используется логическая машина отличная от машины разработки, даже если эмулятор и выполняется на той же физической машине, что и ваш Web-сервер, имена соответствующих машин будут разными. Вследствие этого вы не можете использовать URL //localhost/WebService1, чтобы задать с устройства местоположение Web-службы; вы должны использовать фактическое имя хост-машины (например, //myDevMachine1/WebService) так, как вызывали бы Web-службу с другого ПК.

Вызов Web-службы с устройства работает почти точно так же, как и вызов, выполняемый с настольного компьютера или сервера. Чтобы вызвать Web-службу с мобильного устройства, потребуется выполнить следующие действия:

1. Запустите Visual Studio .NET и создайте проект C# Smart Device Application.

2. Выберите в меню Project (Проект) пункт Add Web Reference (Добавить Web- ссылку). В результате этого на экране отобразится диалоговое окно, где вы можете найти Web-службу, на которую хотите сослаться. Введите URL-адрес Web- службы, которую вы создали перед этим (например, http://MyWebServer/ WebService1/Service1.asmx).

3. Перейдя в диалоговое окно Add Web Reference, введите в текстовом окне Web Reference Name (Имя Web-ссылки) текст MyTestWebService, а затем щелкните на кнопке Add Reference (Добавить ссылку). В результате этого будет загружен WSDL-документ, описывающий Web-службу, а в вашем проекте создан локальный прокси-класс, благодаря чему вы сможете легко вызвать Web-службу.

4. Поместите на форму вашего приложения кнопку и дважды щелкните на ней. В результате этого фокус ввода переместится в код обработчика событий кнопки.

5. Введите следующий код:

//Создать экземпляр локального прокси-объекта

MyTestWebService.Service1 myWebService;

myWebService = new MyTestWebService.Service1();

//Указать локальному прокси-объекту на необходимость вызова Web-службы

int sum = myWebService.AddTwoNumbers(2, 3);

//Отобразить результат вызова Web-службы!

System.Windows.Forms.MessageBox.Show(sum.ToString());

6. Запустите приложение и вызовите Web-службу.

Предыдущий пример соответствует тестированию синхронного вызова Web-служ- бы. Синхронные вызовы легко тестировать и отлаживать, но в реальных сценариях мы почти всегда предпочитаем вызывать Web-службу в асинхронном режиме. Автоматически сгенерированный класс обладает встроенными возможностями, которые позволяют это сделать. Для вызова Web-службы в асинхронном режиме следует вызвать метод myWebService.BeginAddTwoNumbers(…параметры…). Для каждого метода Web-службы в локальном прокси-классе предусмотрен метод Begin*, предназначенный для асинхронного вызова Web-службы, и метод End*, предназначенный для получения результатов этого вызова.

Трудности, связанные с использованием Web-служб на мобильных устройствах

Несмотря на то что использование Web-служб на мобильных устройствах во многом напоминает использование Web-служб на настольных компьютерах и серверах, между этими двумя случаями имеются важные различия. Описанию трудностей, которые либо являются специфичными, либо проявляются в более заметной степени в случае мобильных устройств, посвящен следующий раздел.

Требуются различные варианты поддержки cookie-файлов

Cookie-файл — это порция локальных клиентских данных устройства, принадлежащая определенному Web-сайту и управляемая им. "Принадлежащие" Web-сайту данные, которые содержатся в cookie-файле, передаются на сервер вместе с остальной частью HTTP-запроса. Например, каждый из серверов www.Mywebaddress.com и www.Yourwebaddress.com может поддерживать свой cookie-файл на машине-клиенте, осуществляющей доступ к этим Web-сайтам. Если вычислительное устройство и приложение поддерживают cookie-файлы на стороне клиента, то всякий раз, когда по Web- адресу или его подадресу (например, www.Mywebaddress.com/somepath/somepath1) высылается HTTP-запрос, вместе с ним на сервер передаются и данные, содержащиеся в соответствующем cookie-файле.

Cookie-файлы часто применяются для хранения информации о предпочтительных установках каждого из клиентов Web-сайтов. Передаваемая вместе с каждым запросом информация из cookie-файла представляет интерес для сервера постольку, поскольку она избавляет сервер (или совместно действующую группу серверов) от необходимости поддерживать "состояние сеанса" на стороне сервера и облегчает масштабирование Web-приложения, позволяя ему не сохранять информацию о состоянии в промежутках времени между запросами.

Не исключено, что Web-сайт, предоставляющий информацию о погоде в вашем городе или ваши четыре излюбленные биржевые сводки, использует cookie-файлы на стороне клиента либо для хранения информации об этом в явном виде, либо для хранения уникальных идентификаторов, позволяющих серверу находить соответствующую информацию в базе данных сервера. Cookie-файлы могут быть использованы для хранения как кратковременных данных рабочего сеанса, например, "списка покупок" в Web- магазине, так и долговременных данных, которые хранятся на протяжении нескольких различных сеансов, например, информации о наиболее часто посещаемых вами Web- страницах, посвященных биржевым сводкам или прогнозу погоды. Вместе с тем, использованию клиентских cookie-файлов свойственны некоторые серьезные ограничения.

■ Cookie-файлы являются специфическими для клиента и машины. Если Web-приложение использует cookie-файлы на стороне клиента, то при доступе пользователя к данному Web-приложению с другой машины они должны создаваться заново. Это означает, что информация о предпочтениях пользователя, хранящаяся в cookie-файлах, не переходит вместе с пользователем на другую машину.

■ Использовать cookie-файлы не всегда безопасно. Web-приложения не должны хранить в cookie-файлах ценную информацию, поскольку она будет пересылаться в обоих направлениях при каждом вызове, а ее копия будет сохраняться на клиентской машине, где она становится доступной для злонамеренных хакеров через точки уязвимости на стороне клиента. Критически важная информация должна надежно храниться на сервере и передаваться в другие места лишь по мере необходимости.

■ Передаваемые cookie-файлы дополнительно занимают часть полосы пропускания. Поскольку cookie-файлы передаются с каждым Web-запросом, они используют часть полосы пропускания канала связи. При передаче по сетям мобильной телефонной связи эта дополнительная нагрузка приводит к увеличению длительности и стоимости передачи. Чем больше размер cookie-файла, тем большая часть полосы пропускания тратится понапрасну.

■ Cookie-файлы имеют ограниченные размеры. Существуют определенные ограничения в отношении объема данных, которые могут храниться в cookie-файлах.

Кроме вышеперечисленных ограничений общего характера, использование cookie- файлов при работе с Web-службами характеризуется еще одним недостатком — сложностью. Сеанс связи с Web-службой можно рассматривать как последовательность определенных запросов, передаваемых между клиентом и сервером. Часто эти запросы можно рассматривать как вызовы методов с передачей параметров и последующим получением возвращаемых результатов. Использование cookie-файлов при вызове Web-служб представляет собой второй скрытый канал связи между клиентом и сервером, и это может приводить к некоторой путанице. В листинге 15.7 продемонстрирован вызов Web-службы без использования cookie-файлов, тогда как листинг 15.8 соответствует тому же примеру, в котором вместо передачи некоторых параметров используются cookie-файлы.

Листинг 15.7. Вызовы Web-служб с передачей параметров только явным образом

//0. Установить связь

int sessionID = someWebService.LogOn(userCredentials);

//

//...Выполнение другого многострочного кода...

//

//1. Вызвать Web-службу и создать новый заказ

int orderID = someWebService.CreateNewOrder(sessionID, userInfo, productInfo);

//

//...Выполнение другого многострочного кода...

//

//2. Подтвердить заказ серверу

someWebService.ConfirmPayment(sessionID, orderID, paymentInfo);

//

//...Выполнение другого многострочного кода...

//

//3. Подтвердить адрес доставки

someWebService.ConfirmShipping(sessionID, orderID, shippingAddress);

//

//...Выполнение другого многострочного кода...

//

//4. Завершить оформление заказа someWebService.FinalizeOrder(sessionID, orderID);

Анализ этого кода не должен вызвать у вас особых затруднений. На шаге 1 создается новый заказ и возвращается новый идентификатор заказа (orderID), который будет использоваться в последующих вызовах. Этот номер заказа передается в каждый последующий запрос, поэтому вам должно быть ясно, что каждый из вызовов Web-служб может идентифицировать обрабатываемый заказ при помощи переданного ему параметра orderID.

Вместо использования явного параметра orderID эту информацию можно передавать Web-службе при помощи cookie-файла, хранящегося на стороне клиента. В этом случае клиентский код должен выглядеть примерно так, как показано в листинге 15.8.

Листинг 15.8. Вызов Web-служб путем неявной передачи параметров посредством cookie-файлов

//0. Установить связь

//Хотя этого и не видно, с сервера будет передан клиентский cookie-файл!

int sessionID = someWebService.LogOn(userCredentials);

//1. Вызвать Web-службу и создать новый заказ

//Хотя этого и не видно, на сервер будет передан клиентский cookie-файл!

//Хотя этого и не видно, с сервера будет передан клиентский cookie-файл!

someWebService.CreateNewOrder(userInfo, productInfo);

//

//...Выполнение другого многострочного кода...

//

//2. Подтвердить заказ серверу

//Хотя этого и не видно, на сервер передается клиентский

//cookie-файл, содержащий "orderID". Лихо!

someWebService.ConfirmPayment(paymentInfo);

//

//...Выполнение другого многострочного кода...

//

//3. Подтвердить адрес доставки

//Хотя этого и не видно, на сервер передается клиентский

//cookie-файл, содержащий "orderID". Лихо!

someWebService.ConfirmShipping(shippingAddress);

//

//...Выполнение другого многострочного кода...

//

//4. Завершить оформление заказа

//Хотя этого и не видно, на сервер передается клиентский

//cookie-файл, содержащий "orderID". Лихо!

someWebService.FinalizeOrder();

Приведенный выше код довольно прост, однако, о чем говорится в комментариях, имеется и второй канал связи, скрытый от программиста. Скрытые параметры передаются в обоих направлениях между клиентом и сервером посредством cookie-файлов. Этот факт является убедительным аргументом в пользу того, чтобы не использовать cookie-файлы на стороне клиента при проектировании Web-служб. Гораздо лучше передавать все параметры, требуемые для запроса Web-службы, явным образом, чем использовать для хранения этой информации непрозрачный второй канал.

Многие платформы мобильных устройств либо вообще не поддерживают клиентские cookie-файлы, либо эта поддержка существенно отличается от той, которая предлагается программными каркасами на настольных компьютерах. В частности, в .NET Compact Framework, выполняющейся на устройствах Smartphone, Pocket PC и Windows СЕ, автоматическая передача cookie-файлов вместе с запросами Web-служб не поддерживается. Если вы хотите, чтобы некоторые cookie-файлы были переданы сервером на устройство и возвращены на сервер вместе с последующим запросом, то вы должны написать код для чтения содержимого cookie-файлов из заголовков одного из ответов HTTPWebResponse и записи содержимого cookie-файлов в заголовки последующего запроса HTTPWebRequest. Для этого в случае вызова Web-служб вы должны просмотреть и изменить прокси-код Web службы на стороне клиента, автоматически сгенерированный для вас Visual Studio .NET. Эта задача ни в коей мере не является неразрешимой, но потребует от вас выполнения дополнительной работы, к чему вы должны быть готовы. В этом и состоит важное отличие в поддержке Web-служб программными каркасами на устройствах и настольных компьютерах.

Несмотря на тот факт, что использовать cookie-файлы на стороне клиента при создании Web-служб не рекомендуется, они могут использоваться некоторыми службами, например для хранения информации о входе пользователя в систему. Если Web- служба работает нормально, если вызывается на настольном компьютере, но ее вызовы с мобильного устройства заканчиваются непонятными сбоями, то не исключено, что виновником этих сбоев являются cookie-файлы. Если есть такая возможность, уточните у автора Web-службы, используются ли в ней cookie-файлы; это всегда проще, чем пытаться самостоятельно восстановить причину происходящего. Если получить эту информацию от автора Web-службы не удается, вы можете попытаться исследовать ситуацию эмпирически путем изменения политики обработки cookie-файлов на настольном компьютере; соответствующие изменения можно задать в обозревателе Internet Explorer, выбрав в меню Tools (Сервис) пункт Options (Свойства обозревателя) и перейдя в открывшемся диалоговом окне на вкладку Privacy (Конфиденциальность). Кроме того, если у вас есть желание окунуться в разработку низкоуровневого кода клиентов Web-служб, вы можете изучить набор клиентских cookie-файлов, возвращенный вместе с ответом HTTPWebResponse на Web-запрос. Если в зависимостях клиентских cookie-файлов имеются ошибки, то вы можете действовать трояким образом: 1) обеспечить поддержку Web-службой модели доступа, не требующей использования cookie-файлов, что неплохо сделать в любом случае, 2) создать Web-службу в виде оболочки на стороне сервера, которая играет роль посредника между мобильными устройствами и проблематичной Web-службой, или 3) написать для устройства собственный код, который явным образом осуществляет сборку cookie-файлов, возвращенных вместе с ответами любой Web-службы, и упаковывает их в последующие Web-запросы.

Первый вызов Web-службы часто характеризуется увеличенным временем задержки

Во время первого обращения мобильного приложения к Web-службе часто выполняется значительный объем дополнительной работы, что проявляется в увеличении времени задержки. При первом вызове Web-службы должна быть выполнена следующая работа:

1. Может потребоваться загрузка кода. Если XML, Web-служба, сеть и другие классы на стороне клиента еще не были загружены в память, то не исключено, что их необходимо будет загрузить и компилировать, прежде чем они смогут быть использованы для вызова Web-служб. Для этого потребуется определенное время которое может исчисляться несколькими секундами.

2. Может потребоваться поиск адреса Web-службы. Например, если вызывается Web- служба по адресу www.myWebService.com, то для обнаружения местонахождения сервера этот адрес должен быть преобразован в IP-адрес (например, 200.134.81.26). Для нахождения этого адреса DNS-серверу направляется запрос на преобразование Web-адреса в IP-адрес. Выполнение этой операции требует определенного времени; запрос необходимо упаковать и переслать на DNS- сервер, после чего ваше мобильное приложение должно дождаться ответа и лишь после этого сможет установить фактическую связь с сервером, который предоставляет вызываемую вами Web-службу. Большинству мобильных устройств приходится локально кэшировать этот адрес, чтобы последующие запросы, направляемые на Web-сервер, не требовали повторного проведения поиска соответствующего имени сервером DNS. Выполнение процедуры разрешения имен требует заметного времени и может стать основной причиной задержки при первоначальном вызове Web-службы. Как правило, поиск локального сетевого имени (например, //myLocalServer) происходит быстрее, чем поиск имени во всемирной сети (например, www.myWebServer.com).

При измерении времени отклика Web-служб полезно определять две разновидности этой характеристики: 1) время отклика при выполнении первого вызова, и 2) среднее время отклика для последующих вызовов Web-службы.

Поскольку направляемые Web службам запросы связаны с ресурсами, находящимися вне сферы непосредственного контроля вашего приложения, никогда не помешает осуществлять эти вызовы в асинхронном по отношению к потоку выполнения пользовательского интерфейса режиме. Несмотря на это, будут встречаться случаи, когда пользователь мобильного приложения, который запрашивает информацию или пытается выполнить транзакцию, должен будет дожидаться ее завершения, прежде чем сможет продолжить работу. В этих случаях целесообразно сделать все возможное для того, чтобы ускорить передачу данных на сервер. Если вашему приложению известно, что пользователю потребуется вызвать Web-службу, то имеет смысл сделать фоновый "фиктивный вызов" той же Web-службы еще до того, как потребуется выполнять реальный запрос. В результате "фиктивного вызова" произойдет предварительная загрузка всех необходимых классов в память и кэширование IP-адресов, которые понадобятся во время выполнения последующих вызовов.

Передача больших объемов данных посредством запросов Web-служб неэффективна

Хотя и можно передать Web-службе массив, состоящий из 2000 целых чисел, или загрузить с Web-службы массив данных этого же типа, никто этого не делает. Web- службы оптимизированы для обеспечения максимальной гибкости и дружественности к протоколу HTTP. По этой причине для передачи информации Web-службы используют большие объемы связанных с этой информацией текстовых данных.

Например, число 32 можно представить в виде одного байта данных 00100000. Для передачи целого числа 32 в XML-формате его необходимо представить, скажем, как <int>32</int>, для чего требуется уже 14 байт данных, то же самое относится и к другим типам данных. Те самые свойства, благодаря которым Web-службы и XML обретают гибкость, делают их неэффективными в смысле объема передаваемых данных.

Если Web-служба должна передавать приложению большие объемы данных, то лучше всего организовать это так, чтобы она возвращала указатель на файл с двоичными данными, а не поток данных в виде XML. В качестве показательного примера можно привести Web-службу, возвращающую фотографические изображения.

Хотя Web-служба и может возвратить изображение в виде массива байтов или целых чисел в кодировке XML, гораздо эффективнее возвратить строку с URL-адресом, указывающим на двоичный файл (например, //somewebserver/someshare/somedir/somefile.jpg), который может быть загружен мобильным приложением. Именно так действуют Web-браузеры; они загружают текст в удобочитаемой форме и компонуют информацию в виде HTML-документа, содержащего ссылки на двоичные файлы изображения, которые должны быть встроены в макет. Очень важно тщательно продумывать, в каком виде следует перемещать данные, и оптимизировать этот процесс, если объемы данных велики.

"Болтливость" в мобильных сетях обходится весьма недешево

Каждый запрос, посланный на сервер, означает необходимость начала, проведения и завершения диалога с сервером; следовательно, этот процесс сопровождается дополнительными накладными расходами по организации связи. Пять отдельных вызовов Web-служб, каждый из которых требует передачи одного параметра, гораздо менее эффективны, чем один запрос, содержащий пять параметров. Кроме того, учитывая прерывистый характер сеансов мобильной связи, использование пяти мелких запросов вместо одного более крупного повышает вероятность сбоя в процессе диалога между устройством и сервером. Это означает необходимость написания сложной логики, позволяющей выполнять необходимые восстановительные операции, если посередине такого диалога что-то пойдет не так. Применение одиночных вызовов Web-служб позволяет уменьшить вероятность сбоев и упростить логику восстановления связи в подобных случаях.

НА ЗАМЕТКУ

При использовании Web-служб справедлив тезис, в соответствии с которым лучше передавать двоичные данные в результате выполнения второго запроса, чем пытаться сразу же передавать большой поток XML-данных. Поскольку объем двоичных данных при преобразовании их к формату XML значительно возрастает, это приводит к увеличению длительности их передачи. При длительных временах передачи возрастает вероятность сбоев. Улучшенная модель предполагает выполнение одного вызова Web-службы для передачи всех данных, которые могут быть эффективно переданы в виде XML, и ряда последующих вызовов для передачи таких двоичных файлов, как файлы изображений. В листинге 15.11 представлен код, позволяющий загрузить файл с Web-сервера и сохранить его на устройстве. Если необходимо передать содержимое нескольких двоичных файлов, имеет смысл поэкспериментировать с объединением всех двоичных данных в один сжатый файл; такой объединенный файл может быть передан в виде двоичных данных и распакован на другом конце канала связи.

В листинге 15.9 приведен пример неэффективной организации работы с Web-службой с использованием многократных запросов и ответов. В листинге 15.10 представлен пример пакетной организации того же диалога, когда вся необходимая обработка осуществляется при помощи одного цикла "запрос/ответ". При любом удобном случае старайтесь уменьшать количество запросов, объединяя несколько мелких запросов в один более емкий.

Листинг 15.9. Неэффективная организация диалога с Web-службой, в которой используется множество вызовов

//--------------------------

//Создать и обработать заказ

//--------------------------

//0. Установить связь

int sessionID = someWebService.LogOn(userCredentials);

//1. Вызвать Web-службу и создать новый заказ

int orderID = someWebService.CreateNewOrder(sessionID, userInfo, productInfo);

//2. Вызвать Web-службу и передать информацию о платеже

someWebService.ConfirmPayment(sessionID, orderID, paymentInfo);

//3. Вызвать Web-службу и передать информацию о доставке

someWebService.ConfirmShipping(sessionID, orderID, shippingAddress);

//4. Вызвать Web-службу и завершить оформление заказа

someWebService.FinalizeOrder(sessionID, orderID);

Листинг 15.10. Группирование запросов в одном вызове Web-службы

//----------------------------------------------------------

//Создать и обработать заказ посредством группового запроса,

//включающего:

// 0. Начало связи

// 1. Создание нового заказа

// 2. Подтверждение платежа

// 3. Подтверждение доставки

// 4. Завершение оформления заказа

//-----------------------------------------------------------

//Сделать все за один раз

someWebService.BatchCreateOrder(userCredentials, userInfo, paymentInfo, shippingAddress);

В листинге 15.11 показан пример кода, который загружает с сервера двоичный файл и сохраняет его локально на устройстве. Этот код может пригодиться вам при загрузке с сервера файлов, подобных файлам изображений.

Листинг 15.11. Код для загрузки файла с Web-сервера

//-----------------------------------------------------------

//Осуществляет синхронную загрузку файла с Web-сервера

//и сохраняет его в локальной файловой системе

// [in] httpWhereFrom: URL-адрес файла

// (например, "http://someserver/somefile.jpg")

// [in] filenameWhereTo: Место, куда необходимо записать файл

// (например, "\\localfile.jpg")

//-----------------------------------------------------------

public void downloadFileToLocalStore(string httpWhereFrom, string filenameWhereTo) {

System.IO.FileStream myFileStream = null;

System.IO.Stream myHTTPResponseStream = null;

System.Net.WebRequest myWebRequest = null;

System.Net.WebResponse myWebResponse = null;

//Если файл, который мы хотим записать, уже существует, удалить его

if (System.IO.File.Exists(filenameWhereTo) == true) {

System.IO.File.Delete(filenameWhereTo);

}

try {

//Создать Web-запрос

myWebRequest = System.Net.HttpWebRequest.Create(httpWhereFrom);

//Получить ответ

myWebResponse = myWebRequest.GetResponse();

//Получить поток для ответа

myHTTPResponseStream = myWebResponse.GetResponseStream();

//Создать локальный файл, в который необходимо направить поток ответа

myFileStream = System.IO.File.OpenWrite(filenameWhereTo);

//Этот размер буфера является настраиваемым

const int buffer_length = 4000;

byte [] byteBuffer = new byte[buffer_length];

int bytesIn;

//Считать файл и направить поток данных в локальный файл

do {

//Считать данные

bytesIn = myHTTPResponseStream.Read(byteBuffer, 0, buffer_length);

//Записать данные

if (bytesIn != 0) {

myFileStream.Write(byteBuffer, 0, bytesIn);

}

} while (bytesIn != 0);

} catch (Exception myException) //Сбой при загрузке!

{

//Что-то случилось. Освободить ресурс

attemptCleanup_ThrowNoExceptions(myFileStream, myHTTPResponseStream, myWebResponse);

//Теперь, когда ресурс освобожден, повторно сгенерируем исключение,

//чтобы сообщить приложению о том, что произошел сбой!

throw myException;

}

//Загрузка прошла успешно!

//Закрыть все ресурсы

try {

//Стандартная процедура закрытия ресурсов

myFileStream.Close();

myFileStream = null;

myHTTPResponseStream.Close();

myHTTPResponseStream = null;

myWebResponse.Close();

myWebResponse = null;

} catch (Exception myException) //Сбой в процессе закрытия ресурса!

{

//Что-то случилось. Освободить ресурс

attemptCleanup_ThrowNoExceptions(myFileStream, myHTTPResponseStream, myWebResponse);

//Теперь, когда ресурс освобожден, повторно сгенерируем исключение,

//чтобы сообщить приложению о том, что произошел сбой!

throw myException;

}

//Успешное выполнение!

}

//----------------------------------------------

//Пытается закрыть и освободить все объекты

//Перехватывает любое вырабатываемое исключение.

//----------------------------------------------

void attemptCleanup_ThrowNoExceptions(

System.IO.FileStream myFileStream,

System.IO.Stream myHTTPResponseStream,

System.Net.WebResponse myWebResponse) {

if (myFileStream != null) {

try {

myFileStream.Close();

} catch {} //He выполнять никаких действий.

}

if (myHTTPResponseStream != null) {

try {

myHTTPResponseStream.Close();

} catch {} //He выполнять никаких действий.

}

if (myWebResponse != null) {

try {

myWebResponse.Close();

} catch {} //He выполнять никаких действий.

}

} //конец функции

При работе с неоднородными сетевыми топологиями могут возникать трудности

Настольные компьютеры и серверы работают в условиях сравнительно стабильных сетевых топологий, независимо от того, работают они хорошо или плохо, их поведение характеризуется относительным постоянством. Отчасти это объясняется тем, что сети на основе настольных компьютеров существуют уже давно, и в этой области накоплен большой опыт, а отчасти просто тем, что отдельные узлы сети перемещаются сравнительно редко. Некоторые изменения в условиях работы могут чувствоваться при подключении лэптопов к различным участкам сетей Wi-Fi, однако, поскольку технология Wi-Fi призвана имитировать проводные соединения, эти изменения не очень заметны; некоторые наблюдаемые отличия могут объясняться различиями в ширине полосы пропускания, настройках прокси-серверов и конфигурационных параметров безопасности. Использование сетей мобильной телефонной связи для передачи данных может привнести дополнительные сложности, обусловленные уменьшением полосы пропускания и снижением надежности сети. Мобильные устройства, подключающееся к различным местным сетям операторов мобильной связи еще более разнообразят и усложняют результирующую картину. Используя надежно тестированные и повсеместно поддерживаемые Web-протоколы, Web-службы могут быть полезными при абстрагировании многих деталей сетей передачи данных, однако имеется несколько факторов, о которых вы должны всегда помнить, если ваше мобильное приложение предназначено для работы в широком диапазоне сетей различных типов:

■ Как правило скорость передачи данных будет меньше, а длительность установления соединений — больше, причем обе эти характеристики будут изменяться в более широких пределах. Скорость передачи данных по беспроводным сетям будет неизбежно меньше той, к которой вы привыкли при работе с кабельными сетями. Менее очевиден тот факт, что на формирование мобильного сетевого канала связи также требуется больше времени. Все эти факторы будут оказывать самое непосредственное влияние на эффективность выполнения запросов Web-служб в различных мобильных сетях. В одних сетях мобильной телефонной связи передача данных будет осуществляться быстрее, а времена ожидания будут меньше, чем в других. Важно, чтобы вы не забывали об этом, когда будете самостоятельно разрабатывать и тестировать Web-службы.

■ Может потребоваться настройка прокси-серверов вручную. Приложения, выполняющиеся в корпоративных сетях, часто получают доступ в Internet через прокси-сервер, который устанавливается между интрасетью и WWW (World Wide Web). В то время как прокси-соединения для настольных компьютеров и лэптопов часто настраиваются автоматически, в случае мобильных устройств это не всегда так. Если у вас возникают проблемы при вызове Web-служб из мобильного приложения, то обычно имеет смысл проверить, может ли получить доступ к тому же Web-серверу Web-браузер, установленный на том же устройстве. Если доступ к серверу с помощью браузера получить не удается, то, вероятно, вам потребуется вручную настроить параметры прокси-сервера на данном устройстве.

■ Может потребоваться настройка параметров GRPS-соединений и других мобильных сетевых соединений вручную. Во многих сетях мобильной связи используется понятие точек доступа, аналогичных прокси-серверам в корпоративных сетях, через которые осуществляется доступ к сети Internet. В сетях GSM 2.5G такие соединения известны под названием GRPS-соединений, и их настройка вручную может понадобиться для каждой локальной сети мобильной связи, к которой устройство подключается посредством функции роуминга. Может потребоваться на стройка имен пользователей, паролей и DNS-адресов. Как и в случае прокси- серверов, целесообразно убедиться в работоспособности соединения, проверив, что установленный на устройстве Web-браузер способен получить доступ в Internet. Если Web-браузер работает нормально, то, вероятнее всего, проблем с подключением вашего мобильного приложения к сети Internet, у вас не возникнет.

■ Различные сети мобильной телефонной связи могут вести себя необычным образом. Технология доступа в Internet через сети мобильной телефонной связи еще не отработана окончательно. В прежние времена (два-три года тому назад) телефоны поставлялись со встроенным оборудованием, обеспечивающим речевую связь, а также ограниченными по своим возможностям функциями передачи данных; операторы сетей мобильной телефонной связи могли легко тестировать качество оказания этих услуг, поскольку им было известно, какого типа запросы могут передаваться по их сетям. В наши дни развитие многоцелевого телефонного оборудования приобрело взрывной характер. Несмотря на устойчивые тенденции развития инфраструктуры сетей мобильной телефонной связи в направлении надежной поддержки смартфонов, играющих роль платформы для обычных приложений, это преобразование еще нельзя считать завершенным. В силу этого в серверной инфраструктуре еще могут присутствовать некоторые жестко запрограммированные элементы, ориентированные на работу со строго определенными клиентскими приложениями и протоколами. Например, несколько лет назад мы столкнулись с одной мобильной сетью, которая всегда отправляла HTTP-ответы в сжатом виде, и по этой причине они не могли быть прочитаны клиентскими приложениями, ожидающими данные в виде простого текста. В результате этого ответы Web-служб воспринимались приложением так, словно информация была перепутана и не имела ничего общего с XML-данными, получение которых ожидалось. Причина этого состояла в том, что Internet-браузеру на клиентских телефонах было известно о том, что данные будут поступать в сжатом виде, и он мог обеспечить распаковку данных, но эта возможность не была сделана доступной для других приложений. Потребовалась разработка временного способа преодоления этих трудностей, позволяющего обычным клиентским приложениям передавать модифицированные заголовки HTTP- запросов, которые в явном виде требовали отправки ответов в несжатой форме. Есть все основания полагать, что в настоящее время такие проблемы вряд ли могут возникать, однако некоторые "блохи" подобного рода могут все еще оставаться невыявленными. Поэтому в целях диагностики возникающих проблем рекомендуется применять многоэтапный подход. Если при попытках доступа к Web-службе возникают проблемы, я советую придерживаться следующей последовательности отладочных шагов: 1) попытайтесь вызвать Web-службу из приложения, развернутого на настольном компьютере; если сделать это не удается, то проблема не является специфической для устройства; 2) попытайтесь просмотреть несколько Web-страниц, используя клиентское устройство; если сделать это удается, то соединение с Internet работает нормально; 3) попытайтесь загрузить файлы с интересующего вас сервера, используя для этого объект System.Net.HTTPWebRequest платформы NET Compact Framework, как показано в листинге 15.11; если это срабатывает и содержимое загруженного файла правильно интерпретируется, то данные поступают в ваше приложение надлежащим образом; 4) попытайтесь вызвать Web-службу из приложения, развернутого на настольном компьютере, с отключением cookie-файлов на стороне клиента: 5) построчно просмотрите автоматически сгенерированный в вашем приложении клиентский код Web-службы для точной локализации ошибок. Выполнение отладки с целью выявления причин возникновения проблем подобного рода всегда доставляет много хлопот; применение унифицированного пошагового подхода приводит к наилучшим результатам.

Ничто не заменит тестирования в тех сетях, для развертывания в которых предназначено ваше приложение. Если мобильное приложение должно сохранять работоспособность при подключении к различным местным сетям посредством функции роуминга, то вы значительно выиграете, если подвергнете его тестированию в различных сетях мобильной связи, поскольку это позволит вам лучше понять, с какими возможными изменениями рабочих условий придется иметь дело вашему приложению.

Резюме

Обмен данными между приложениями играет существенную роль при решении большинства задач, представляющих практический интерес. В этом отношении мобильные устройства, которые находятся у пользователя всегда под рукой, занимают уникальное положение, поскольку с их помощью он может в любой момент получить необходимую ему информацию или услуги. Однако обеспечение подобной гибкости требует преодоления целого ряда трудностей. Как разработчик мобильного приложения, вы должны гарантировать его эластичную и гибкую работу в широком диапазоне значений полосы пропускания в условиях варьируемого времени ожидания, неустойчивости соединений и различных режимов связи.

Очень важно позаботиться об отказоустойчивости проектируемых коммуникационных механизмов и при этом не потерять из виду потребности пользователя. Решение этой задачи может оказаться значительно более сложным, чем создание эффективной коммуникационной модели для серверов, настольных компьютеров или лэптопов, которая, как правило, должна учитывать лишь небольшое количество переменных параметров связи.

Вы должны проектировать мобильное приложение таким образом, чтобы оно могло воспользоваться любыми преимуществами сетей, когда и как только они становятся доступными, но не зависело жестко от наличия сетевого доступа. Вместо этого доступ к сети должен рассматриваться вами как благоприятная возможность: используйте его с пользой для приложения, если он имеется, но не полагайтесь только на него.

Очень важно включать в процесс управления сетевым доступом конечных пользователей; они могут принимать относительно установления соединений такие решения, зависящие от конкретных обстоятельств, которые просто не могут быть автоматически предусмотрены в логике работы приложения. Лишь конечный пользователь может выйти из помещения, чтобы подключиться к сети, или предпринять необходимые действия в связи с тем, что устройство скоро выйдет из зоны покрытия сети, поскольку пользователь собирается спуститься в метро. При всяком удобном случае следует предоставлять конечным пользователям возможность инициировать или прекратить сетевую операцию. Кроме того, желательно, чтобы у пользователей была возможность устанавливать предпочтительные параметры синхронизации, исходя из собственных потребностей и знания существующих условий подключения к сети

При доступе к сетевому ресурсу поток выполнения вашего приложения теряет управление на время, которое невозможно точно спрогнозировать. По этой причине крайне желательно, чтобы любой доступ к сети, для которого не указан вполне определенный и причем короткий интервал ожидания, осуществлялся при помощи фонового потока. Непрерывное поддержание способности пользовательского интерфейса к отклику является единственным способом, позволяющим предоставить конечным пользователям возможность постоянного контролировать ситуацию в процессе работы с вашим приложением.

Организация защитных мер в коде и имитация нерегулярных сбоев в сети должны стать обычной практикой разработчика. Поскольку мобильные устройства могут входить в зоны покрытия сетей и покидать их, вероятность разрыва соединений для них гораздо выше, чем в случае настольных компьютеров или лэптопов. Важно, чтобы ваше мобильное приложение сохраняло свою работоспособность при любых сбоях связи. Очень важно, чтобы в случае разрыва соединения приложение соответствующим образом освобождало ресурсы, которые могли быть распределены при попытке установки соединения. Очень легко оставить открытыми соединение с сокетом или файл, что может привести к невозможности последующего доступа к сети. Мониторинг выполнения кода для генерации периодических тестовых исключений при выполнении коммуникационных задач — это отличный способ тестирования надежности кода, предназначенного для восстановления обычного состояния приложения после сбоев, и способности вашего приложения эластично возобновлять впоследствии связь, нарушенную в результате сбоев

Существуют множество потенциальных механизмов, способных обеспечить возможности коммуникации для мобильных приложений. Их диапазон простирается от персональных сетевых технологий, таких как Bluetooth, до широко разветвленных сетей, предоставляемых инфраструктурой мобильной телефонной связи.

Постоянно возрастает важная роль сетей Wi-Fi как поставщика широкополосной связи в зонах небольшого радиуса в окрестности "горячих точек". Кроме этих технологий, существуют и другие, менее известные, но заслуживающие внимания механизмы. Неплохие возможности сетевого доступа обеспечивают технологии, предполагающие помещение устройств в специальные лотки, обеспечивающие подключение к сети через ПК или кабели Ethernet. Съемные карты памяти обеспечивают возможность перемещения больших объемов информации путем использования физических носителей. Наконец, существует также технология IrDA, обеспечивающая двухточечную связь между устройствами, а также связь между устройствами и лэптопами. Эти коммуникационные среды охватывают широкий круг возможностей, но ни одна из них не является наилучшей для всех задач.

При решении вопроса о том, каким образом лучше всего удовлетворить коммуникационные потребности вашего мобильного приложения, оставаясь на позициях простоты, надежности и предоставления максимально возможных удобств конечному пользователю, следует придерживаться творческого подхода. Часто применение той или иной комбинации описанных выше технологий позволяет предоставить пользователям мобильного приложения ту гибкость, которая соответствует их потребностям в обмене информацией.

Web-службы предлагают полезный способ организации взаимодействия приложений с Internet и интрасетями. Путем использования данных в формате XML, обычно передаваемых посредством протоколов HTTP или HTTPS, Web-службы могут предоставить вашему мобильному приложению возможность воспользоваться всеми преимуществами существующей инфраструктуры Web для удовлетворения коммуникационных потребностей. Важно, однако, понимать, что платой за предоставляемые Web- службами полезные абстракции являются значительные накладные расходы. XML-формат порождает текстовые файлы большого размера и не способен обеспечить эффективный обмен данными через сеть в случае крупных XML-сообщений. Кроме того, для определения IP-адресов может требоваться использование серверов доменных имен, что служит источником дополнительных накладных расходов.

Описанные проблемы не являются специфическими для мобильных устройств, однако. учитывая тот факт, что сети мобильной связи работают медленнее и, как правило, характеризуется меньшей надежностью по сравнению с кабельными сетями, к разрешению этих трудностей необходимо относиться со всей серьезностью. Исключая тестовые сценарии, вызовы Web-служб должны всегда выполняться в асинхронном режиме, чтобы тем самым гарантировать постоянное сохранение способности пользовательского интерфейса к отклику. Следует стремиться к тому, чтобы количество отдельных вызовов Web-служб, необходимых для решения определенной задачи, было как можно меньшим, поскольку значительные времена задержки при установлении соединений в сетях мобильной связи делают многократные вызовы Web-служб весьма дорогостоящими. Такие двоичные данные, как изображения, не должны передаваться в виде XML; вместо этого Web-службы должны возвращать для таких данных их URL-адреса, чтобы мобильное устройство могло загрузить данные в виде двоичного файла.

Web-службы доказали свою полезность, и их использование для организации взаимодействия между различными системами будет только расширяться, но в интересах сохранения высокой производительности мобильных приложений действовать при этом надо осмотрительно.

Используемые мобильными приложениями коммуникационные средства предоставляют богатое разнообразие возможностей выбора для разработчиков программного обеспечения. Однако это же обстоятельство повышает и ответственность разработчика за правильность сделанного им выбора с точки зрения соответствия этого выбора запросам пользователей мобильного приложения и требованиям экономичности. Дополнительно к этому, проектируемые коммуникационные механизмы должны обеспечивать устойчивость приложения к сбоям связи и возможность выполнения соответствующих настроек, тем самым позволяя разумным образом сочетать автоматизацию работы приложения с контролем над ним со стороны конечного пользователя. В силу равнодоступности всех имеющихся в настоящее время способов связи, при создании мобильных приложений открывается простор для самых смелых инноваций. Как и любая другая сфера разработки программного обеспечения для мобильных устройств, данная область широко распахнута для исследований, и ничто не сможет служить лучшим залогом удовлетворения коммуникационных потребностей вашего мобильного приложения, чем эксперименты и новаторство.

ГЛАВА 16

Шаг 5: упаковка и развертывание мобильного приложения

Ничто не кончено, пока не закончено.

Йоги Берра (Yogi Berra), 1925

(Encarta 2004, Quotations)

Введение

При разработке программного обеспечения работа считается законченной, когда завершенный программный продукт попадает к тем, для кого он был предназначен. В случае мобильного программного обеспечения это означает развертывание созданного вами приложения на пользовательских устройствах. Окончательным мерилом качества продукта является полезность приложения и то удовольствие, которое работа с ним доставляет пользователям. Чтобы эти цели были достигнуты, мобильное приложение должно попасть на реальные целевые устройства, а это означает, что его необходимо предварительно упаковать, а затем развернуть на мобильных устройствах каждого пользователя.

В данной книге основное внимание уделено тому, чтобы пополнить запас технических знаний читателя и привить ему творческий способ мышления, необходимый для создания замечательных мобильных приложений. И хотя операции упаковки и развертывания приложений не имеют прямого отношения к "написанию мобильного кода", они играют очень важную роль, и данная глава представляет собой обзор решений, которые вам придется принимать для успешного развертывания вашего мобильного приложения.

Поскольку детали упаковки и развертывания приложений определяются спецификой используемых типов устройств и программных технологий, в этой главе приводится лишь краткий обзор вопросов, имеющих отношение к данной теме. Отдельные шаги процедуры упаковки различны для различных технологий: J2ME/J2SE, .NET Compact Framework и ряд технологий, основанных на использовании собственных кодов, требуют для упаковки и развертывания приложений выполнения разных последовательностей шагов. Для разных типов устройств, например, PDA, смартфонов или каких-либо специализированных устройств, предусмотрены различные процедуры инсталляции программного обеспечения, отличающиеся своими деталями. Выдавая своим пользователям телефоны, операторы сетей мобильной связи часто предлагают программное обеспечение, предусмотренное для динамической загрузки на эти устройства; у этих операторов имеются собственные стратегии установки и инициализации программного обеспечения. Комплекты документации, соответствующие различным технологиям устройств и операторам сетей мобильной связи, часто можно загрузить из Web.

В данной короткой главе внимание фокусируется лишь на наиболее общих вопросах, чтобы дать вам мысленные установки относительно того, каким образом следует решать проблемы упаковки и развертывания приложений. Дополнительные ссылки на статьи, посвященные специфике упаковки и развертывания приложений при работе с .NET Compact Framework, приводятся в приложении А; довольно неплохие статьи и примеры, которые помогут вам разобраться в деталях рассматриваемых процессов, можно найти среди сетевых ресурсов. Кроме того, существуют профессиональные инсталляционные средства, которые позволяют значительно уменьшить количество выполняемых вручную операций, необходимых для упаковки и подготовке к работе мобильных приложений; разумеется, имеет смысл ознакомиться и с этими средствами. Как бы то ни было, очень важно знать, с какими проблемами и возможностями приходится иметь дело в процессе развертывания мобильных приложений.

Чтобы развертывание мобильного приложения прошло успешно, вы должны дать ответы на следующие вопросы:

1. Если ваши целевые устройства не относятся к числу "открытых" ("open devices"), то выдвигает ли поставщик устройств какие-либо требования, которые должны быть обязательно удовлетворены?

2. Существуют ли дополнительные компоненты, которые также должны быть развернуты для того, чтобы приложение могло нормально функционировать на всех типах устройств, выбранных в качестве целевых?

3. Каким образом конечный пользователь будет устанавливать ваше приложение?

Все эти вопросы подробно рассматриваются в следующих разделах.

Нуждается ли ваше мобильное приложение в цифровой подписи?

Мобильные устройства можно разделить на три категории:

1. Устройства строго определенного назначения. К этой категории относятся устройства, поставляемые с уже установленным программным обеспечением, которое предоставляет пользователю фиксированный набор услуг. Средства, позволяющие добавлять дополнительное программное обеспечение после развертывания устройства, отсутствуют. Именно такими системами еще совсем недавно являлись мобильные телефоны первых моделей. Основной причиной того, что устройства с фиксированным набором функциональных возможностей встречаются и в наши дни, является стремление обеспечить гарантированные характеристики надежности и безопасности. Замкнутую систему можно досконально протестировать. Единственным способом включения программного обеспечения в такую систему является его запись в ПЗУ устройства на стадии изготовления или путем обновления ПЗУ Среди современных платформ мобильных устройств, представляющих наибольший интерес, системы строго определенного назначения не встречаются.

2. Открытые устройства. К таковым относятся устройства, для которых отсутствуют ограничения относительно того, какое программное обеспечение может на них устанавливаться. Пользователь может свободно размещать на устройстве любое желаемое программное обеспечение, не получая на это никакого разрешения. Большинство устройств PDA/Pocket PC являются открытыми системами, и таковыми же являются некоторые модели смартфонов.

3. Устройства с ограниченными возможностями расширения. Это устройства, на которых могут устанавливаться лишь приложения, для которых это разрешено. Чтобы на таком устройстве с ограниченным доступом могло выполняться какое-либо приложение, необходимо получить согласие на это третьей стороны, которая контролирует доступ к этому устройству. В случае мобильных телефонов в роли такой стороны обычно выступает оператор сети мобильной связи, выдавший устройство. Приложения, развертываемые на устройствах с ограниченным доступом, предварительно должны получить криптографическую подпись.

Криптографическая подпись (cryptographic signature) — это небольшая порция информации, присоединяемая к приложению. Подпись основана на использовании двух элементов: 1) уникальном двоичном хеш-коде, генерируемом путем применения к байтам приложения специального алгоритма, и 2) криптографическом ключе, владельцем которого является частное лицо или организация, подписывающие приложение; обычно этот ключ состоит из двух частей — закрытой секретной части и производной по отношению к ней открытой части, восстановление которых посторонними лицами затруднено. Подпись, которой снабжено подписанное приложение, верифицируется с использованием набора утвержденных ключей. Подпись используется для надежной идентификации стороны, подписавшей приложение. Если двоичный образ приложения в силу каких-либо причин изменяется, подпись становится недействительной. Аналогичным образом, если для подписания приложения использовать другой ключ, то изменится и результирующая подпись. На устройстве, предоставляющем ограниченные возможности инсталляции приложений, хранится список утвержденных ключей подписей. При попытке инсталляции приложения или его выполнения на устройстве осуществляется проверка того, что оно подписано уполномоченной на это стороной; если проверка дает отрицательный результат, то выполнение приложения запрещается. Возможен и такой вариант, при котором в случае отсутствия или несоответствия подписи устройство запрашивает пользователя, желает ли он продолжить выполнение операции, безопасность которой не гарантируется; выбор такого варианта поведения определяется изготовителем или дистрибьютором устройства.

НА ЗАМЕТКУ

Изготовитель может поставлять несколько версий устройства, одни из которых являются "открытыми", а другие относятся к устройствам с "ограниченным доступом". В качестве примера устройств такого типа можно привести устройства Microsoft Smartphone.

Некоторые изготовители и их партнеры, являющиеся операторами сетей мобильной связи, поставляют смартфоны как "открытые" устройства, на которых разрешается устанавливать любые приложения. Другие же поставщики поставляют их как устройства с "ограниченными возможностями расширения", позволяя устанавливать лишь разрешенные для этого приложения. Как правило, устройства, приобретаемые непосредственно у изготовителя, являются "открытыми". Обычно, если вы занимаетесь разработкой и тестированием приложений, то вам нужны открытые устройства, на которых ваше приложение можно беспрепятственно развернуть из инструмента разработки без какой-либо подписи. Приобретая устройство для целей разработки приложений, убедитесь в наличии такой возможности.

Если ваше мобильное приложение предназначено для выполнения на устройствах, ограничивающих круг приложений, которые могут использоваться на данном устройстве, то приложение необходимо снабдить подписью. Обычно эта процедура предполагает отправку приложения третьей стороне, являющейся владельцем ключей подписей, наличие которых проверяется устройством. Важно понимать, что модель, в которой применяются подписи, не зависит от того, каким именно способом приложение попало на устройство. Приложение может быть загружено из Web, установлено с использованием карты флэш-памяти или загружено с ПК; обычно для модуля устройства, проверяющего подписи, это не имеет никакого значения. Чтобы приложения могли выполняться, им приходится проходить одну и ту же процедуру проверки подписи.

Свяжитесь с компанией-оператором сети мобильной связи, выдающим телефоны, которые вы хотите использовать в качестве целевых устройств для своего приложения, и получите от нее подробные разъяснения относительно того, каким образом следует получить для приложения разрешение на выполнение и криптографическую подпись. Многие операторы, распространяющие смартфоны, поддерживают те или иные партнерские программы разработки приложений, к которым можете присоединиться и вы. Часто поставщики технологий располагают также программами сертификации и партнерского сотрудничества, участие в которых облегчает размещение приложений на устройствах по договоренности с операторами мобильных сетей. Так, с этой целью компания Microsoft ведет программу Mobile2Market (см. приложение А).

Почему поставщики некоторых устройств требуют, чтобы приложения были подписаны?

Операторы сетей мобильной связи являются основными дистрибьюторами мобильных устройств, требующими наличия цифровых подписей у приложений при установке и выполнении нового программного обеспечения. В основном это делается по следующим трем причинам:

1. Чтобы управлять коммерческой моделью использования приложений, выполняющихся на выданных ими устройствах. Операторы сетей мобильной связи нередко субсидируют часть стоимости телефонов, которые они выдают пользователям. Поэтому они нуждаются в механизме возврата средств, вложенных в телефонные трубки. Одни операторы предпочитают получать эту компенсацию в виде части дохода от выполнения приложений на их устройствах. Другие хотят, чтобы на устройствах развертывались лишь те приложения, которые они считают полезными для своего бизнеса. Третьи могут быть больше всего заинтересованы в том, чтобы на их устройствах развертывались лишь приложения, соответствующие определенным требованиям в отношении качества и содержимого.

2. Чтобы контролировать затраты на поддержку выдаваемых ими устройств. Операторов мобильных сетей, выдающих своим пользователям телефоны в больших количествах, волнует вопрос о стоимости их последующей поддержки. Каждый раз, когда у пользователя возникают проблемы с трубкой, и он обращается к своему сетевому оператору, все расходы, связанные с оказанием пользователю необходимой технической помощи, ложатся на поставщика. Целесообразность такой поддержки становится проблематичной, если выполнение развернутого на устройстве приложения случайно или преднамеренно приводит к несанкционированному использованию сети или препятствует использованию телефона для обычных операций. Оператор мобильной сети может захотеть быть полностью уверенным в том, что на выдаваемых им в больших количествах телефонах выполняются только одобренные высококачественные приложения, на которые распространяются условия поддержки.

3. Чтобы защитить свои сети. Операторы сетей мобильной связи заботятся о том, чтобы выполняющиеся на их устройствах приложения не могли, случайно или преднамеренно, нанести вред их дорогостоящим сетям связи. Для сетевых операторов нет ничего страшнее вирусов, распространяющихся среди множества телефонов и инициирующих атаку типа DoS (denial of service — отказ в обслуживании), которая приводит к невозможности коммерческого обслуживания сети.

Желание операторов сетей мобильной связи контролировать использование предоставляемых ими телефонов вступает в определенное противоречие с перспективами более быстрого внедрения инноваций, которые обеспечиваются использованием открытых платформ. Модель централизованного управления может привлекать своей стабильностью, однако открытые платформы предлагают возможность динамичного внедрения незапланированных новшеств. Эта ситуация аналогична противостоянию, которое существует между предсказуемой стабильностью плановой экономики и творческим хаосом капиталистической системы. Различные операторы мобильных сетей экспериментируют с различными моделями, и каждый из них пытается найти наиболее оптимальное соотношение между факторами контроля и свободы. Добавьте к этому еще и желание различных сторон предусмотреть настраиваемые для каждого отдельного приложения параметры безопасности (управляющие, например, возможностями доступа в сеть, отображения пользовательского интерфейса, доступа к файловой системе устройства и тому подобного), и вам станет понятно, что споры вокруг этого будут длиться еще не один год. В конечном счете, вероятно, предпочтение будет отдано чему-то более близкому к открытой модели, но с предусмотренными мерами безопасности, которые смогут гарантировать, что доступ к наиболее ценной функциональности мобильных устройств будет возможен лишь с согласия распространяющих эти устройства сетевых операторов. Вполне разумно предположить, что в эту схему будут вовлечены и другие категории поставщиков мобильных устройств. Организация, выдающая в пользование своим сотрудникам многофункциональные смартфоны, может разрешить использование на них лишь тех приложений, которые она считает заслуживающими доверия. В конце концов, последнее слово будет всегда оставаться за той стороной, от которой пользователь получает мобильное устройство. Те, кто покупает телефоны непосредственно у поставщиков, вероятнее всего, будут приобретать открытые устройства, тогда как тем, кто получает их от третьей стороны, будут предоставляться определенные возможности расширения функциональности устройств с некоторым уклоном, учитывающим интересы данной стороны.

Инсталляция сред выполнения и других необходимых компонентов

Если вы предполагаете для своего мобильного приложения использование устройств определенной конфигурации, то можете оптимизировать инсталляцию для такого устройства. С другой стороны, если предполагается, что круг устройств, для выполнения на которых предназначено мобильное приложение, должен быть как можно более широким, вы должны определить для них общий знаменатель и учесть те компоненты, которые могут отсутствовать на части устройств. Можно выделить два разных случая: 1) целевые устройства, на которых отсутствует среда выполнения, необходимая для вашего приложения, и 2) целевые устройства, на которых отсутствуют компоненты, которые используются вашим устройством.

Динамическое развертывание сред выполнения на мобильных устройствах

Возможность динамической установки основных библиотек времени выполнения, необходимых вашему приложению, важна в том случае, если целевыми являются несколько поколений устройств. Например, в то время как .NET Compact Framework v1.1 поддерживается на Pocket PC 2000, 2002, 2003 и более поздних моделях, эта платформа не устанавливалась предварительно в ПЗУ ни на одном из устройств Pocket PC 2000, что относится и к большинству устройств Pocket PC 2002

.NET Compact Framework стала стандартной частью платформы лишь начиная с поколения Pocket PC 2003. Если ваше приложение создавалось для выполнения поверх .NET Compact Framework v1.1 и вы хотите, чтобы оно выполнялось на максимально широком круге оборудования, то в случае некоторых устройств для этого может потребоваться динамическая установка среды времени выполнения. У вас имеются три различные возможности

1. Ограничиться возможностью выполнения приложения лишь на тех устройствах, на которых требуемая среда установлена. Конечно же, этот вариант решения является самым простым, но одновременно и наименее гибким.

2. Упаковать требуемую среду выполнения вместе с инсталляционными файлами приложения. Такой способ обеспечивает наиболее полные функциональные возможности, но одновременно с этим является и самым громоздким, поскольку вместе с программой установки приложения на устройство будут переноситься и те компоненты среды выполнения, в которых нет необходимости, а логика установки усложняется, так как для различных типов оборудования могут требоваться различные варианты сборки среды. Если на большинстве типов ваших целевых устройств необходимая версия среды выполнения уже установлена, то значительная часть работы окажется проделанной понапрасну.

3. Потребовать, чтобы пользователи устройств, на которых необходимая среда выполнения отсутствует, установили ее вручную. В идеальном случае логика инсталляции должна быть в состоянии самостоятельно обнаруживать наличие или отсутствие требуемых компонентов времени выполнения. Если лишь незначительная часть ваших целевых устройств требует динамической установки компонент, то, вероятно, достаточно проинформировать пользователей этих устройство том, что именно они должны сделать, и предложить им следовать дальнейшим инструкциям процедуры установки.

НА ЗАМЕТКУ

Лишь некоторые классы устройств поддерживают динамическую установку сред времени выполнения и компонентов.

Как уже отмечалось ранее, одни устройства являются открытыми и допускают установку программного обеспечения, тогда как другие допускают установку лишь определенного программного обеспечения и в силу этого могут не предусматривать динамическую установку сред времени выполнения. Кроме того, круг устройств, допускающих динамическую установку сред времени выполнения, ограничивается также техническими причинами. Например, на устройствах Microsoft Smartphone и Pocket PC работа с памятью, отводимой под файловые системы, осуществляется по-разному, вследствие чего поддержка установки .NET Compact Framework в файловой системе ОЗУ Pocket PC, если это необходимо, оказывается возможной, но при этом неосуществимой для устройств Microsoft Smartphone, которые требуют установки среды выполнения в ПЗУ (хотя приложения и могут храниться в файловой системе смартфона). Поэтому знание спецификаций и возможностей расширения функциональности целевых устройств имеет очень большое значение.

Не менее важным аспектом является правильное использование версий среды выполнения. Независимо от технологии используемых сред выполнения (например, .NET Compact Framework, J2ME, J2SE, собственные коды), время от времени появляются их обновленные версии, поэтому необходимо внимательно следить за тем, с какой именно версией вы работаете.

Многие среды выполнения обеспечивают совместимость с предыдущими версиями (обратную совместимость); например, версия 1.3 среды выполнения может выполнять код, написанный для версий 1.1 и 1.2. Если обратная совместимость не поддерживается, у вас имеются две возможности:

1. Вероятно, самым простым решением является создание отдельных версий вашего приложения для каждой поддерживаемой версии среды выполнения; это потребует ваших дополнительных усилий при разработке и тестировании приложения, однако обеспечит наилучшие условия работы для конечных пользователей.

2. Вторая возможность — это установка требуемой версии среды выполнения в соответствии с приведенным выше описанием.

Динамическая установка компонентов, необходимых приложению

Компонентами являются любые установленные на устройстве технологии, используемые вашим приложением, которые не входят в состав базовой среды выполнения или операционной системы. В случае корпоративных мобильных приложений к таковым, например, относятся процессоры локальных баз данных устройства. Другим примером могут служить графические элементы управления независимых производителей, которые может использовать ваше приложение. Собственно компоненты могут сопровождаться дополнительными файлами. Например, в приложении, использующем процессор базы данных мобильного устройства, могут иметься файлы предварительно заполненных баз данных, содержащие данные, которые приложение будет использовать во время выполнения.

В отличие от рассмотренного выше случая сред выполнения, обычно не следует ожидать, что основная масса целевых устройств поставляется с уже установленными компонентами, в которых может нуждаться ваше приложение. Как и в предыдущем случае, если требуемые приложению компоненты отсутствуют, у вас есть две возможности: 1) необходимые компоненты могут быть предоставлены программой инсталляции приложения и установлены ею в соответствии с необходимостью, и 2) инсталляционный пакет вашего приложения может поставляться без компонентов, но сообщать пользователям о том, откуда компоненты могут быть установлены в индивидуальном порядке. Ваш выбор будет определяться тем, насколько велика вероятность того, что необходимые компоненты уже установлены на устройствах пользователей, а также тем, насколько включение компонентов увеличивает размер инсталляционного пакета приложения.

Возможные варианты упаковки и установки

Существует несколько возможных вариантов доставки и установки приложения. Какой механизм является наилучшим — зависит от сложности вашего приложения, его зависимости от компонентов, а также от того, каким образом ваше мобильное приложение будет использоваться конечными пользователями.

Копирование и выполнение / загрузка и выполнение

Если для вашего приложения отсутствуют подлежащие поставке вместе с ним компоненты, от которых оно зависит, то удобнее всего воспользоваться самым простым вариантом инсталляции по принципу "копирования и выполнения". Как говорит само название этого метода, в этом случае инсталляция сводится к локальному копированию приложения на устройство, после чего его можно будет запускать на выполнение.

При таком подходе отсутствует локальная регистрация приложения на устройстве. Если требуется регистрация приложения на мобильном устройстве, чтобы оно появлялось в вариантах навигации, предлагаемых пользователю устройства, вам потребуется дополнительный код установки.

Установка под управлением устройства

Установка, осуществляемая под управлением устройства, весьма напоминает установку настольных приложений на ПК. В этом случае для локальной установки приложения на мобильном устройстве запускается специальное приложение. Если для выполнения приложений на данном мобильном устройстве требуется наличие у них цифровых подписей, то подписью должна быть снабжена и инсталляционная программа. Обычно пользователи загружают и выполняют программу установки, используя Internet-браузер. Вы также можете воспользоваться средствами установки, поставляемыми независимыми разработчиками.

Обычно локальные инсталляционные программы обладают достаточной гибкостью, позволяющей устанавливать необходимые компоненты, копировать нужные файлы и выполнять другие операции, которые должны предшествовать процедуре инсталляции или следовать за ней.

Установка под управлением настольного компьютера

Установка под управлением настольного компьютера обычно осуществляется путем инициации запуска инсталляционной программы для устройства с настольного компьютера. Эта модель является наиболее распространенной при наличии взаимодействия между настольным ПК и мобильным устройством, с которым он синхронизирован. Настольное приложение может запустить инсталляционную программу, которая связывается с мобильным устройством и устанавливает на нем необходимое программное обеспечение.

Установка под управлением настольного компьютера обладает двумя существенными преимуществами: 1) с процедурой запуска инсталляционных программ на ПК пользователи хорошо знакомы, и 2) настольные компьютеры, которые синхронизируются с мобильными устройствами, могут применять этот процесс синхронизации для принудительного перемещения обновленных приложений и данных на устройства.

Как и в предыдущих случаях, вы также можете воспользоваться инсталляционными программами независимых поставщиков.

Установка с использованием карт памяти

Установка, основанная на использовании карт памяти, выполняется непосредственно на самом устройстве и инициируется путем вставки карты памяти в устройство. Эта разновидность процедуры установки весьма напоминает установку программного обеспечения на настольных компьютерах с компакт-дисков, когда инсталляционная программа автоматически запускается после вставки компакт-диска или диска DVD в соответствующий привод. Использование этого вида инсталляции предполагает наличие файла с определенным именем и определенным местоположением на носителе, где его и пытается найти операционная система после того, как вы вставите карту памяти в устройство.

Особенно удобным этот вариант установки оказывается тогда, когда карта памяти в любом случае должна использоваться для хранения данных приложения. Если, например, в мобильном приложении используется база данных и для хранения информации объемом 200 Мбайт используется съемная карта памяти, то выбор такого варианта установки будет вполне естественным. 4 Мбайт инсталляционного пакета приложения, его среды выполнения и других необходимых компонентов легко приютятся рядом с 200 Мбайт данных, которые в любом случае должны быть перенесены на устройство через карту памяти.

При этом варианте установки вам также могут пригодиться инсталляционные программы независимых поставщиков.

Установка с использованием инструмента разработки

Если ваше приложение должно быть развернуто лишь на небольшом количестве устройств (например, 20), то вполне возможен вариант, при котором это может быть сделано для вас инструментом разработки. В инструментах разработки часто предусматриваются превосходные средства для загрузки приложений и необходимых компонентов, которыми вы можете воспользоваться, тем самым избавив себя от необходимости создания и отладки собственных сценариев установки.

Недостаток этого подхода состоит в том, что он фактически не обеспечивает масштабирования. Он не применим для развертывания приложений на устройствах с ограниченным доступом и приемлем только в случае небольшого количества устройств. Если не исключено, что впоследствии ваше приложение должно будет развертываться на большом количестве устройств, то вам придется подумать о механизме инсталляции, не требующем участия инструмента разработки. Если же вы создаете специализированное приложение, предполагаемое для использования немногочисленными устройствами, то этот вариант решения вас вполне устроит.

Установка приложений в ПЗУ

Еще одним вариантом установки, которым иногда можно воспользоваться при создании мобильных приложений для специализированного оборудования или при работе в непосредственном контакте с поставщиком мобильных устройств, является размещение приложения в образе ПЗУ устройства. Нестандартные мобильные устройства часто поставляются с определенным набором встроенных приложений.

Кроме того, для многих современных устройств предусматривается возможность перезаписи образу ПЗУ устройства, благодаря чему поставщик устройств может периодически обновлять возможности устройств. Обычно для осуществления такой перезаписи необходимо иметь криптографический ключ, позволяющий "разблокировать" образ ПЗУ устройства.

Несмотря на отсутствие каких-либо препятствий технического характера, установка приложений в ПЗУ требует тесного взаимодействия с поставщиком устройств (что само по себе может служить препятствием).

Резюме

Лучшее, что можно посоветовать разработчикам приложений, предназначенных для развертывания на большом количестве мобильных устройств, — это тестировать развертывание приложения уже на самых ранних стадиях цикла разработки и после этого включить соответствующие требования в число критериев прохождения каждой контрольной точки разработки. Разработка технологий подготовки к установке и установки приложений всегда требует выполнения большего объема работы, чем первоначально предполагается; кроме того, эта работа менее привлекательна по сравнению с созданием самого приложения, и поэтому ее часто откладывают на "потом", предпочитая заняться более интересными вещами. To же самое можно сказать и о приложениях для настольных компьютеров и серверов, но в случае мобильных устройств это оказывается вдвойне справедливым. Неоднородная природа мобильных устройств, потенциальная потребность в привлечении третьих сторон, поставляющих устройства, и необходимость тестирования процедур установки на различных типах устройств вынуждают уделять этой проблеме самое пристальное внимание. Начинайте готовить установочный пакет на самых ранних стадиях разработки, делайте это как можно чаще и тестируйте процедуру установки на целевом оборудовании, на котором планируется развертывать приложение.

ГЛАВА 17

Послесловие

Любую достаточно развитую технологию трудно

отличить от магии.

Артур Кларк (Arthur С. Clark), автор научно-фантастической повести "Космическая одиссея 2001 года" и один из праотцов спутниковой связи

(Encarta 2004, Quotations)

Если вы дочитали книгу до этого места — благодарю вас за то, что вы не пожалели на это своего времени! Надеюсь, что чтение книги доставило вам удовольствие, и она не только вдохновила вас, но и кое-чему научила. Если же вы просто перелистываете страницы, раздумывая над тем, стоит ли покупать эту книгу, то я надеюсь, что вы все-таки ее купите и прочтете!

Меня часто спрашивают, как будет далее развиваться ситуация в связи с широким распространением мобильных устройств. Не вдаваясь особенно в детали (что заведомо обречено на провал), я хотел бы поделиться с вами следующими соображениями:

■ "Персональный компьютер" никуда не исчезнет и не будет вытеснен мобильными устройствами. Мне часто приходится слышать такие рассуждения: "За прошлый год было продано 500 миллионов мобильных телефонов и 100 миллионов ПК. ПК скоро отойдут и будут вытеснены мобильными телефонами, подключенными к Internet". Когда говорят такое, то неявно предполагают, что мобильные телефоны служат тем же целям, что и персональные компьютеры: вместе с тем, это далеко не так. В силу присущих только персональным компьютерам интерактивных возможностей, необычайной широты сферы их применения, богатства красок экрана и тех удобств в работе, которые они предлагают, их уход с рынка представляется просто немыслимым. Вы только попытайтесь себе представить, как будет выглядеть написание книги с использованием мобильного телефона или проектирование сложной электронной таблицы на PDA; это в равной степени и невозможно, и не вызовет у вас ни капли энтузиазма. Персональные компьютеры с их большими экранами, богатыми возможностями ввода и вывода и поистине ошеломляющей вычислительной мощью и накопительной емкостью, играют очень важную роль, предоставляя пользователям доступ к необозримым океанам информации. Вместе с тем, персональные компьютеры эволюционируют и порождают новые технологические ветви. По-видимому, персональные компьютеры постепенно отойдут, будучи вытесненными с одной стороны лэптопами, а с другой — персональными/домашними серверами. Возможно, количество настольных ПК и уменьшается, но значение персональных компьютеров как таковых в наши дни продолжает расти. Да, действительно, будучи всегда под рукой и предоставляя пользователям удобные возможности для обмена данными с персональными компьютерами, мобильные устройства играют все более значимую роль, но персональные компьютеры при этом никуда не деваются.

■ Мобильные устройства станут нашими постоянными спутниками. В прежние времена люди постоянно носили с собой карманные часы. Эти устройства могут служить одним из первых примеров персональных технологий, продукты которых постоянно сопровождают своего владельца и предоставляют ему информацию по первому требованию. Их форм-фактор был вполне подходящим, а приносимая польза была неоспоримой; людям всегда надо знать, который сейчас час. Устройство умещалось в кармане и ненавязчиво предлагало ценную информацию, По мере того как развитие технологии позволило уменьшить их размеры, а массовое производство — снизить цены, часы перекочевали из карманов на запястья. Поскольку никакой необходимости в том, чтобы часы оставались соразмерными карманам, не было, они уменьшились. Приход цифровых технологий привел к дальнейшему снижению цен и расширению функциональных возможностей часов, но эти устройства в основном работали в режиме только чтения. Как ранние, так и современные модели цифровых часов предлагают некоторые службы, с которыми пользователи могут взаимодействовать, но в силу особенностей форм-фактора эти службы предназначались главным образом только для считывания информации. Помните, как неудобно было нажимать кнопки калькулятора часов? Мобильные телефоны принесли с собой возможности двухстороннего взаимодействия в условиях портативности устройств, размеры которых первоначально были ощутимо большими, но постепенно уменьшились до весьма изящного форм-фактора, позволяющего им удобно располагаться в кармане. Пусть даже это и было предоставлено в качестве дополнительного средства, но во всех мобильных телефонах имеются часы, что вновь возвращает нас к карманным часам, но предлагающим значительно более широкие функциональные возможности. Технология улучшалась, цены падали, а количество выпускаемых устройств возросло до ошеломляющей величины. Перестав выполнять узкоспециализированные функции часов и телефонов, устройства превратились в самые настоящие мобильные вычислительные платформы, но не уменьшились до форм-фактора, позволяющего носить их на запястьях, поскольку существующий форм-фактор более приспособлен для двухстороннего взаимодействия с пользователем. Подобно карманным часам минувших дней, мобильные телефоны постоянно сопровождают нас, предлагая информацию по первому требованию, но взаимодействие пользователя с ними теперь уже носит ярко выраженный двухсторонний характер. Мобильные устройства, и в особенности — мобильные телефоны, становятся нашими постоянными спутниками, и мы можем в любой момент воспользоваться ими для получения информации или услуг. Благодаря своим размерам, их ношение не доставляет никаких неудобств, заряда батарей хватает на несколько дней, размеры экрана позволяют отображать довольно большой объем разнообразной информации, а их потрясающие коммуникационные возможности позволяют нам получать широкий спектр услуг. Что сегодня более всего необходимо — так это хорошее программное обеспечение, как на устройствах, так и на серверах, с которым общаются устройства. Будучи расширяемыми вычислительными платформами, мобильные устройства в состоянии предоставлять своим пользователям информацию и услуги, в которых те нуждаются, в любой момент, как посредством сети, так и в автономном режиме. Точно так же как сегодня многим из нас даже трудно представить себе, как раньше можно было обходиться без мобильных телефонов и сети Internet, многофункциональные мобильные устройства завтрашнего и послезавтрашнего дней предложат нам новые ценные услуги, которые очень быстро станут непременным атрибутом нашей повседневной жизни. Подобно тому как в прежние времена люди машинально доставали из кармана часы, чтобы, бросив на них мимолетный взгляд, определить, который теперь час, вскоре и мы привыкнем машинально и почти не задумываясь посматривать на мобильные телефоны, время от времени вводя в них некоторые данные, и засовывать их обратно в карман после того, как получим нужную информацию или услуги. Возможно, появятся и такие экзотические форм-факторы, как дисплеи типа "рыбий глаз" или наушники-компьютеры, но, по своим деньгам, я бы сделал ставку на карманные часы.

■ Мобильные устройства будущего будут способны получать больше информации о своем окружении. Наличие в устройстве информации о времени и дате в наши дни воспринимается компьютерными программистами как само собой разумеющаяся вещь. Знание местоположения, окружения и контекста пользователя устройства — вот какими способностями будут обладать устройства ближайшего будущего. Такими способностями устройства будут наделяться постепенно и по частям, поскольку многие аспекты этого еще должны быть изучены, а задача достаточно сложна. Возможности определения устройством всей этой информации зависят не от какого-то одного, а от множества мелких факторов, которые, будучи раскрытыми перед разработчиками приложений в понятной для них форме, позволят мобильным устройствам намного превзойти свои нынешние возможности.

■ На мобильных устройствах будет устанавливаться много мелких и средних специализированных приложений. Настольные компьютеры полностью отдаются под власть крупных, всеобъемлющих приложений, которые окружают своих пользователей данными, приглашая исследовать их использовать в работе. Мобильные приложения оказываются наиболее эффективными тогда, когда дают пользователям возможность сфокусировать свое внимание на решении определенной задачи, предоставляя им сразу же только те данные и услуги, в которых они непосредственно нуждаются, и требуя для этого лишь минимальной навигации в пределах пользовательского интерфейса. Многофункциональные мобильные устройства лучше всего приспособлены для работы не с одним крупным приложением, а с множеством мелких или средних, каждое из которых позволяет сосредоточиться на решении ограниченного набора отдельных задач. Трудности использования данной модели связаны с тем, что поддерживать единообразие пользовательского интерфейса во всех таких приложениях весьма непросто. Пользователи, особенно пользователи завтрашнего дня, ничего не будут знать о концепции использования множества приложений на устройстве; они будут воспринимать устройство лишь как нечто, предлагающее совокупность богатых возможностей, пользоваться которыми должно быть удобно. Вы достигнете успеха лишь тогда, когда пользователь не будет замечать никаких следов "сшивки" отдельных кусков программного обеспечения, а будет видеть лишь единый, цельный, отшлифованный продукт.

■ Мы находимся в начале пути. Мобильные устройства только совсем недавно уменьшились в размерах, подешевели, приобрели множество функций и получили возможность подключаться к компьютерным сетям, чтобы их можно было использовать в качестве платформы для программных приложений. По этой причине большинство современных программных технологий для мобильных устройств фокусировались на переносе подходящим образом переработанных версий технологий, используемых на настольных компьютерах и серверах, на мобильные платформы. Этот первый шаг был необходим, но его следует рассматривать лишь как начало. Именно теперь, когда технологии с настольных компьютеров и серверов перенесены на устройства, и начинается самая интересная работа. Она будет заключаться в разработке новых средств и программных моделей, которые развиваются на мобильных устройствах. Эти новшества приживутся на мобильных устройствах и в соответствующем виде перейдут на лэптопы, настольные компьютеры и серверы. Такие идеи, как возможность получения устройством информации об окружении, коммуникационных возможностях и привычках того, кто пользуется устройством, являются вполне естественными направлениями для начала внедрения на мобильных устройствах таких инноваций, которые впоследствии пробьют себе дорогу и на более крупные и менее мобильные платформы. Нас ожидает волнующий этап.

Мобильные устройства предлагают ни с чем не сравнимые возможности доставки информации и услуг непосредственно пользователям с применением способов, которые действительно описывается словами "в любое время и в любой момент". Трудно переоценить потенциал усовершенствований в отношении увеличения производительности человеческого труда, повышения комфортности условий работы пользователя, повышения качества услуг, оказываемых пожилым людям и лицам с ограниченными физическими возможностями и, что самое главное, расширения возможностей общения людей между собой. Программное обеспечение дает разработчикам возможность полностью проявить свой творческий потенциал, а наличие отработанных технических подходов позволяет превращать идеи в полезные инновации. Надеюсь, что эта книга помогла вам хоть немного разобраться в ситуации в этой области и вооружила вас всем необходимым для того, чтобы вы смогли в полной мере воспользоваться всем тем, что может вам предложить разработка программного обеспечения для мобильных устройств.

ПРИЛОЖЕНИЕ А

Дополнительные ресурсы по .NET Compact Framework

Сетевые ресурсы

Пространство Web огромно, и вы найдете в нем множество заслуживающих внимания ресурсов, посвященных разработке высококачественных мобильных приложений. Но наряду с ними существуют огромные объемы разрозненной информации, которую приходится тщательно просеивать. Ниже перечислены сайты, которые послужат вам неплохими отправными точками для начала соответствующего поиска. К сожалению, в силу динамической природы Web некоторые URL со временем могут изменяться. Там, где это возможно, я указываю авторов и названия статей; если какой-то URL уже прекратил свое существование, у вас будет достаточно информации, чтобы отыскать соответствующий ресурс.

Обмен программами

■ www.GotDotNet.com — сайт, развернутый компанией Microsoft для обмена кодом в рамках сообщества программистов. Это мой излюбленный сайт по обмену кодом, поскольку здесь можно увидеть, какой код чаще всего загружают другие люди. Посетив GotDotNet, начните поиск с раздела "User Samples" и образцов программ, относящихся к рубрике ".NET Compact Framework", и щелкните на заголовке "Downloads". На экран будет выведен список размещенных на сайте примеров программ, отсортированный в соответствии с их популярностью.

■ www.OpenNETCF.org — сайт, развернутый независимыми профессионалами и любителями для обмена кодом, новостями, статьями и обсуждения вопросов, касающихся .NET Compact Framework. На сайте вы найдете лицензию на использование исходных кодов, поддерживающую коммерческое использование исходных кодов, приведенных на сайте, с которой также стоит ознакомиться. Кроме того, на этом сайте публикуются материалы довольно серьезных коллективных проектов, находящихся в стадии разработки.

Сетевые телеконференции

Для .NET Compact Framework существует много активных форумов, действующих по принципу "спрашивайте — ответим". Доступ к ним можно получить либо с помощью программы для работы с группами новостей, либо через Web-сайт http://msdn.microsoft.com/newsgroups/.

Можно указать еще несколько форумов, посвященных данной тематике:

■ microsoft.public.dotnet.framework.compactframework

■ microsoft.public.pocketpc.developer

■ microsoft.public.pocketpc.developer.networking

■ microsoft.public.smartphone.developer

Как и в случае любого форума или обсуждения, вопросы и ответы, которые вы встретите там, могут быть как интересными, так и не представляющими никакого интереса. Форумы — великолепное место для поиска подсказок и идей, которые помогут вам преодолеть проблемы, тормозящие дальнейшую работу, но там вы найдете исключительно информацию, которая предоставляется "без обещания компенсации возможного ущерба и без гарантий достоверности".

Общие вопросы разработки мобильных приложений

Самые последние замечательные новости о .NET Compact Framework и других технологиях разработки мобильного программного обеспечения, используемых компанией Microsoft, появляются на следующих Web-сайтах:

http://msdn.microsoft.com/mobility/

http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/faq/default.aspx

Для разработки приложений Microsoft Smartphone с использованием Visual Studio Net 2003 вам потребуется установить пакет SDK для Windows Mobile 2003-based Smartphones, доступный для загрузки по следующему адресу:

http://msdn.microsoft.com/mobility/windowsmobile/downloads/

Для просмотра постоянно обновляемого документа Wiki, содержащего ответы на наиболее часто задаваемые вопросы, посетите следующий сайт:

http://wiki.opennetcf.org/ow.asp?CompactFrameworkFAQ

Особенности взаимодействия с собственным кодом

Вызов собственного кода (native code) из VB.NET или C# не представляет особых сложностей, но вам следует знать о некоторых частных правилах и устоявшихся приемах. Лучше всего изучать это на примерах.

■ Основы работы с собственными кодами в среде .NET Compact Framework

An Introduction to P/Invoke and Marshalling on the Microsoft .NET Compact Framework

Авторы: Jon Box, Dan Fox; Quilogy

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfintrointerp.asp

■ Тонкости работы с собственными кодами в среде .NET Compact Framework

Advanced P/Invoke on the Microsoft .NET Compact Framework

Авторы: Jon Box, Dan Fox; Quilogy

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfadvinterop.asp

■ Передача асинхронных сообщений из собственного кода в управляемый код при помощи .NET Compact Framework

Asynchronous Callbacks from Native Win32 Code Автор: Maarten Struys; PTS Software

http://msdn.microsoft.corn/library/default.asp?url=/library/en-us/dnnetcomp/html/AsynchCallbacks.asp

Работа с операторами мобильных сетей

Компания Microsoft предлагает рекомендации и программу сотрудничества по вопросам создания, сертификации и развертывания приложений на мобильных телефонах, публикуемые операторами мобильных сетей.

■ Сокращенная ссылка, которая переадресует вас на более подробное содержимое, указанное далее:

Сокращенный URL-адрес Mobile2Market

http://www.mobile2market.com

■ Сертификация от Mobile2Market и маркетинговая программа

http://msdn.microsoft.com/mobility/windowsmobile/partners/mobile2market/default.aspx

■ Список операторов мобильных сетей, рекомендации по отдельным операторам и контактная информация

http://msdn.microsoft.com/mobility/windowsmobile/partners/mobile2market/smartphoneapps/default.aspx

Развертывание и установка

Инсталляционные технологии постоянно развиваются, и то, какую из них следует использовать, зависит от типа разрабатываемого приложения и вида целевого оборудования. Как и в случае изучения способов взаимодействия с собственными кодами, лучше всего изучать то, что вам необходимо, на конкретных примерах.

Инструкции по развертыванию и установке приложений .NET Compact Framework хорошо изложены в документации продукту MSDN, которая поставляется вместе с Visual Studio .NET. С неплохим примером развертывания приложения на устройствах вы можете ознакомиться в оперативной справочной документации, последовательно выбрав следующие разделы: Visual Studio .NET→Developing with Visual Studio .NET→Designing Distributed Applications→Developing for Devices→Samples and Walkthroughs→Smart Device Walkthroughs→Generating Custom CAB Files for Device Projects (Visual Studio .NET→Разработка с помощью Visual Studio .NET→Проектирование распределенных приложений→Разработка для устройств→Примеры и анализ→Анализ интеллектуальных устройств→Генерация пользовательских CAB-файлов для проектов, ориентированных на устройства).

■ Пошаговый разбор создания инсталляционного приложения для Pocket PC

Developing and Deploying Pocket PC Setup Applications

Автор: Ralph Arvesen; Vertigo Software, Inc.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfdeployment.asp

■ Подробное описание динамической установки .NET Compact Framework на устройствах на тот случай, если это вам когда-либо понадобится

Creating an MSI Package That Detects and Updates the .NET Compact Framework

Автор: Stan Adermann; Microsoft Corporation

http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/dnnetcomp/html/netcfdepl.asp

Профессиональные инструментальные средства разработки инсталляционных программ. В настоящее время некоторые изготовители инсталляционных средств для настольных компьютеров и серверов расширили свои предложения, которые теперь охватывают и мобильные устройства. Вне всякого сомнения, вам стоит ознакомиться с предложениями InstallShield для мобильных устройств,

http://www.installshield.com

Примечание. Я указал здесь InstallShield, учитывая широкую известность и популярность этого средства установки. Если вы используете другие инсталляционные программы, то, безусловно, вам стоит посетить соответствующие Web-сайты, чтобы узнать, поддержку каких мобильных устройств они предлагают.

Оптимизация производительности

В указанной ниже статье вы найдете превосходные советы и описания эффективных практических методов настройки производительности приложений, а также подробное изложение методик получения данных профилирования приложений с помощью .NET Compact Framework, которые вы сможете применить для анализа производительности приложений. Эта прекрасная статья поможет вам сохранять "дух производительности" в процессе разработки мобильных приложений.

■ Developing Well-Performing .NET Compact Framework Applications

Авторы: Dan Fox, Jon Box; Quilogy

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfperf.asp

ПРИЛОЖЕНИЕ Б

Примеры программ на языке Visual Basic .NET

Почему именно VB.NET и С#?

Споры между разработчиками программ на языках VB.NET и С# никогда не прекращается, и это неплохо! Представителям обоих лагерей есть чему поучиться друг у друга. Что касается меня, то, поработав с обоими языками в течение многих лет, и в частности, имея опыт работы в составе группы разработчиков на Visual Basic, могу поделиться следующими наблюдениями. Каждый из этих языков может быть использован для решения практически любой задачи программирования — все дело в акцентах. Я обнаружил, что Visual Basic .NET с его традиционным для Visual Basic акцентом на продуктивности программирования великолепно приспособлен для разработки конечных приложений.

С другой стороны, преимуществом С# является его строгость, что делает его более приспособленным для проектирования каркасов приложений. По всей видимости, оба языка в равной степени хорошо приспособлены для проектирования повторно используемых компонент, которые занимают промежуточное положение между независимыми приложениями и обширными библиотеками программ. Кроме того, оба языка предлагают опции, отличные от используемых по умолчанию, которые сближают подходы, основанные на использовании каждого из них. Так, в Visual Basic .NET имеется директива Option Strict On, которую я настоятельно рекомендую помещать в начале любого модуля, который вы пишете, в качестве меры, позволяющей вылавливать многие виды распространенных синтаксических и логических ошибок. Помимо этого, оба языка учатся друг у друга, заимствуя каждый с выходом очередной новой версии нечто полезное, что впервые было предложено в другом языке; это порождает хороший дух соперничества между этими двумя языками.

В Visual Basic .NET мне особенно нравятся возможности, относящиеся к обработке событий; ключевые слова AddHandler и Handles (используемые в приведенных ниже кодах) гораздо более элегантны и декларативны, чем их текущие варианты, используемые в С#. Поскольку удобнее всего работать с примерами, которые написаны на наиболее привычном языке, я поместил в данное приложение VB.NET-версии почти всех листингов, приведенных в основной части книги.

Не включены в приложение только листинги примеров, которые, либо в силу малости их размера, либо в силу того, что они должны быть одинаково хорошо понятны разработчикам, принадлежащим любому лагерю, автор счел слишком тривиальными, чтобы тратить время на их трансляцию. Везде, где только возможно, соблюдается практика записи кода, принятая в Visual Basic, в том смысле, что приведенный ниже код является не результатом прямой трансляции кода, написанного на языке C#, а скорее его "VB-версией"; в то же время, оба вида примеров функционально эквивалентны друг другу, и тем, для кого представляет интерес сравнение возможностей языков Visual Basic и C#, чтобы решить для себя, какой из них выбрать, сделать это не составит труда. Удачного программирования!

Примеры к главе 5 (конечные автоматы)

Листинг 5.1. Простой код конечного автомата для игры с множественным выбором

Option Explicit On

Class MyStateMachineClass

Private Enum GameState

StartScreen

AskQuestion

CongratulateUser

ScoldUser

End Enum

Private m_CurrentGameStateAs GameState

'---------------------------------------------------------------------

'Конечный автомат, воздействующий на пользовательский интерфейс и

'управляющий переходами приложения в другие состояния в соответствии с

'текущим режимом работы пользователя

'---------------------------------------------------------------------

Private Sub StateChangeForGame(ByVal newGameUIState _

As GameState)

'Определить, в какое состояние переходит приложение

Select Case (newGameUIState)

Case GameState.StartScreen

'Если переход в данное состояние осуществляется из состояния,

'для которого это запрещено, возбудить исключение

If ((m_CurrentGameState <> GameState.CongratulateUser) _

AndAlso (m_CurrentGameState <> GameState.ScoldUser)) Then

Throw New System.Exception("Запрещённое изменение состояния!")

End If

'ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

' 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

' элементов управления пользовательского интерфейса

' 2. Настройка переменных/состояний игры, соответствующих

' данному режиму работы

' SetUpGameStateForStartScreen()

Case GameState.AskQuestion

'Если переход в данное состояние осуществляется из состояния,

'для которого это запрещено, возбудить исключение

If ((m_CurrentGameState <> GameState.StartScreen) _

AndAlso (m_CurrentGameState <> GameState.CongratulateUser) _

AndAlso (m_CurrentGameState <> GameState.ScoldUser)) Then

Throw New System.Exception("Запрещённое изменение состояния!")

End If

'ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

' 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

' элементов управления пользовательского интерфейса

' 2. Настройка переменных/состояний игры, соответствующих

' данному режиму работы

'

' SetUpGameStateForAskQuestion()

Case GameState.CongratulateUser

'Если переход в данное состояние осуществляется из состояния,

'для которого это запрещено, возбудить исключение

If (m_CurrentGameState <> GameState.AskQuestion) Then

Throw New System.Exception("Запрещённое изменение состояния!")

End If

'ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

' 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

' элементов управления пользовательского интерфейса

' 2. Настройка переменных/состояний игры, соответствующих

' данному режиму работы

'

' SetUpGameStateForCongratulateUser()

Case GameState.ScoldUser

'Если переход в данное состояние осуществляется из состояния,

'для которого это запрещено, возбудить исключение

If (m_CurrentGameState <> GameState.AskQuestion) Then

Throw New System.Exception("Запрещённое изменение состояния!")

End If

'ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

' 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

' элементов управления пользовательского интерфейса

' 2. Настройка переменных/состояний игры, соответствующих

' данному режиму работы

' SetUpGameStateForScoldUser()

Case Else

Throw New System.Exception("Наизвестное состояние!")

End Select

'Сохранить запрошенное новое состояние в качестве текущего

m_CurrentGameState = newGameUIState

End Sub

End Class

Листинг 5.2. Неявное изменение состояния приложения (неудачный подход)

'Код, выполняющийся при загрузке формы

Private Sub Form1_Load(ByVal senderAs System.Object,ByVal _

e As System.EventArgs) Handles MyBase.Load

TextBox1.Visible = True

ListBox1.Visible = False

End Sub

'Данные

Private m_someImportantInfoAs String

'Пользователь щелкнул на кнопке и хочет перейти к выполнению

'следующего шага данного приложения. Скрыть текстовое окно и отобразить

'окно списка в отведенном для этого месте.

Private Sub Button1_Click(ByVal senderAs System.Object,ByVal _

e As System.EventArgs) Handles Button1.Click

m_someImportantInfo = TextBox1.Text

TextBox1.Visible = False

ListBox1.Visible =True

End Sub

Листинг 5.3. Явное изменение состояния приложения (удачный подход)

Private m_someImportantInfo As String

'Определить состояния, в которых может находиться приложение

Enum MyStates

step1

step2

End Enum

'----------------------------------------------------

'Главная функция, которая

'вызывается всякий раз, когда возникает необходимость

'в изменении состояния приложения

'----------------------------------------------------

Sub ChangeApplicationState(ByVal newStateAs MyStates)

Select Case newState

Case MyStates.step1

TextBox1.Visible = True

ListBox1.Visible = False

Case MyStates.step2

m_someImportantInfo = TextBox1.Text

TextBox1.Visible = False

ListBox1.Visible = True

End Select

End Sub

'----------------------------------------------------------------------

'Пользователь щелкнул на кнопке и хочет перейти к выполнению

'следующего шага данного приложения. Скрыть текстовое окно и отобразить

'окно списка в отведенном для этого месте.

'----------------------------------------------------------------------

Private Sub button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)

'Вызвать главную функцию для изменения состояния

ChangeApplicationState(MyStates.step2)

End Sub

'-------------------------------------

'Код, выполняющийся при загрузке формы

'-------------------------------------

Private Sub Forml_Load(ByVal sender As Object, _

ByVal eAs System.EventArgs)

'Вызвать главную функцию для изменения состояния

ChangeApplicationState(MyStates.step1)

End Sub

Листинг 5.4. Код программы нахождения простых чисел, предназначенный для выполнения фоновым потоком

Option Strict On

Imports System

Public Class FindNextPrimeNumber

'Определить возможные состояния

Public Enum ProcessingState

notYetStarted

waitingToStartAsync

lookingForPrime

foundPrime

requestAbort

aborted

End Enum

Private m_startTickCount As Integer

Private m_endTickCount As Integer

Private m_startPoint As Long

Private m_NextHighestPrime As Long

Private m_processingState As ProcessingState

'---------------------------

'Простейший конечный автомат

'---------------------------

Public Sub setProcessingState(ByVal nextState As ProcessingState)

'------------------------------------------------------------

'Простейший защитный код, гарантирующий

'невозможность перехода в другое состояние в случае успешного

'завершения задачи или успешной отмены ее выполнения

'------------------------------------------------------------

Dim currentState As ProcessingState

currentState = getProcessingState()

If ((currentState = ProcessingState.aborted) _

OrElse (currentState = ProcessingState.foundPrime)) Then

Return

End If

'Безопасное параллельное выполнение потоков

SyncLock (Me)

'Разрешить изменение состояния

m_processingState = nextState

End SyncLock

End Sub

Public Function getProcessingState() As ProcessingState

Dim currentState As ProcessingState

'Безопасное параллельное выполнение потоков

SyncLock (Me)

currentState = m_processingState

End SyncLock

Return currentState

End Function

Public Function getTickCountDelta() As Integer

If (getProcessingState() = _

ProcessingState.lookingForPrime) Then

Throw New Exception( _

"Продолжается поиск простого числа! Окончательное время еще не вычислено")

End If

Return m_endTickCount - m_startTickCount

End Function

'------------------------

'Возвращает простое число

'------------------------

Public Function getPrime() As Long

If (getProcessingState() <> ProcessingState.foundPrime) Then

Throw New Exception("Простое число еще не найдено!")

End If

Return m_NextHighestPrime

End Function

'Конструктор класса

Public Sub New(ByVal startPoint As Long)

setProcessingState(ProcessingState.notYetStarted)

m_startPoint = startPoint

End Sub

'-----------------------------------------------------------

'Создает новый рабочий поток, который будет вызывать функцию

'findNextHighestPrime()

'-----------------------------------------------------------

Public Sub findNextHighestPrime_Async()

Dim threadStartAs System.Threading.ThreadStart

threadStart = _

New System.Threading.ThreadStart( _

AddressOf findNextHighestPrime)

Dim newThread As System.Threading.Thread

newThread = New System.Threading.Thread(threadStart)

'Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.waitingToStartAsync)

newThread.Start()

End Sub

'------------------------------------------------------------------

'Основной рабочий поток. Этот поток запускает поиск очередного

'простого числа и выполняется до тех пор, пока не произойдет

'одно из следующих двух событий:

' (а) найдено очередное простое число

' (b) от внешнего (по отношению к данному) потока поступила команда

' прекратить выполнение

'------------------------------------------------------------------

Public Sub findNextHighestPrime()

'Если поступила команда прекратить выполнение, то поиск даже

'не должен начинаться

If (getProcessingState() = ProcessingState.requestAbort) Then

GoTo finished_looking

End If

'Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.lookingForPrime)

m_startTickCount = System.Environment.TickCount

Dim currentItemAs Long

'Проверить, является ли число нечетным

If ((m_startPointAnd 1) = 1) Then

'Число является нечетным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 2

Else

'Число является четным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 1

End If

'Приступить к поиску простого числа

While (getProcessingState() = ProcessingState.lookingForPrime)

'В случае нахождения простого числа возвратить его

If (isItemPrime(currentItem) = True) Then

m_NextHighestPrime = currentItem

'Обновить состояние

setProcessingState(ProcessingState.foundPrime)

End If

currentItem = currentItem + 2

End While

finished_looking:

'Выход. К этому моменту либо от другого потока поступила

'команда прекратить поиск, либо было найдено и записано

'следующее наибольшее простое число

'Зафиксировать время

m_endTickCount = System.Environment.TickCount

'Если поступил запрос прекратить выполнение,

'сообщить, что выполнение процесса прекращено

If (getProcessingState() = ProcessingState.requestAbort) Then

setProcessingState(ProcessingState.aborted)

End If

End Sub

'Вспомогательная функция, которая проверяет, является

'ли число простым

Private Function isItemPrime(ByVal potentialPrime As Long) As Boolean

'Если число - четное, значит, оно не является простым

If ((potentialPrime And 1) = 0) Then

Return False

End If

'Продолжать поиск до тех пор, пока не будет превышено значение

'квадратного корня из числа

Dim end_point_of_searchAs Long end_point_of_search = _

CLng(System.Math.Sqrt(potentialPrime) + 1)

Dim current_test_itemAs Long = 3

While (current_test_item <= end_point_of search)

'---------------------------------------------------------

'Проверить, не поступила ли команда прекратить выполнение!

'---------------------------------------------------------

If (getProcessingState() <> ProcessingState.lookingForPrime) Then

Return False

End If

'Если число делится без остатка,

'значит, оно не является простым

If (potentialPrimeMod current_test_item = 0) Then

Return False

End If

'Увеличить число на два

current_test_item = current test_item + 2

End While

'Число является простым

Return True

End Function

End Class

Листинг 5.5. Тестовая программа, которая вызывает на выполнение приведенный выше код фонового потока, осуществляющего поиск простого числа

'----------------------------------------------------------

'Код, обрабатывающий событие щелчка на кнопке Button1 формы

'Вызвать из этого потока функцию поиска простого числа!

'(Это приведет к блокированию потока)

'----------------------------------------------------------

Private Sub Button1_Click(ByVal senderAs System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

Dim testItem As Long

testItem = System.Convert.ToInt64("123456789012345")

Dim nextPrimeFinder As FindNextPrimeNumber

nextPrimeFinder = New FindNextPrimeNumber(testItem)

nextPrimeFinder.findNextHighestPrime()

Dim nextHighestPrime As Long

nextHighestPrime = nextPrimeFinder.getPrime()

MsgBox(CStr(nextHighestPrime))

'Сколько времени заняли вычисления?

Dim calculation_time As Integer

calculationtime = nextPrimeFinder.getTickCountDelta()

MsgBox(CStr(calculation time) + " мс")

End Sub

'------------------------------------------------------------------------

'Код, обрабатывающий событие щелчка на кнопке Button2 формы

'Вызвать функцию поиска простого числа из другого потока!

'(Данный поток блокироваться не будет)

'Для отслеживания состояния выполнения задачи используем конечный автомат

'------------------------------------------------------------------------

Private Sub Button2_Click(ByVal senderAs System.Object, _

ByVal eAs System.EventArgs) Handles Button2.Click

Dim testItem As Long

testItem = System.Convert.ToInt64("123456789012345")

Dim nextPrimeFinderAs FindNextPrimeNumber

nextPrimeFinder = New FindNextPrimeNumber(testItem)

'-----------------------------------

'Выполнить обработку в другом потоке

'-----------------------------------

nextPrimeFinder.findNextHighestPrime_Async()

'Войти в цикл и ожидать до тех пор, пока не будет найдено простое число

'или выполнение не будет прекращено

While ((nextPrimeFinder.getProcessingState() <> _

FindNextPrimeNumber.ProcessingState.foundPrime) And _

(nextPrimeFinder.getProcessingState() <> _

FindNextPrimeNumber.ProcessingState.aborted))

'ТОЛЬКО В ТЕСТОВОМ КОДЕ:

'Отобразить окно сообщений и предоставить пользователю возможность

'убрать его с экрана.

'Это позволяет организовать паузу

MsgBox("Поиск продолжается... Щелкните на кнопке OK")

'Мы могли бы прекратить поиск путем следующего вызова функции:

'nextPrimeFinder.setProcessingState(

' FindNextPrimeNumber.ProcessingState.requestAbort)

End While

'Осуществить корректный выход в случае прекращения поиска

If (nextPrimeFinder.getProcessingState() = _

FindNextPrimeNumber.ProcessingState.aborted) Then

MsgBox("Поиск прекращен!")

Return

End If

Dim nextHighestPrime As Long

nextHighestPrime = nextPrimeFinder.getPrime()

MsgBox(CStr(nextHighestPrime))

'Сколько времени заняли вычисления?

Dim calculation_time As Integer

calculation_time = nextPrimeFinder.getTickCountDelta()

MsgBox(CStr(calculation_time) + " мс")

End Sub

Примеры к главе 7 (производительность: введение)

Листинг 7.1. Пример кода для измерения временных интервалов, который вы можете использовать для хронометрирования работы своих приложений

Option Strict On

Imports System

Friend Class PerformanceSampling

'Значение этого параметра может быть задано произвольным, но количество

'тестовых интервалов, равное 8, представляется достаточным для большинства

'случаев

Const NUMBER_SAMPLERS As Integer = 8

Private Shared m_perfSamplesNames(NUMBER_SAMPLERS) As String

Private Shared m_perfSamplesStartTicks(NUMBER_SAMPLERS) As Integer

Private Shared m_perfSamplesDuration(NUMBER_SAMPLERS) As Integer

'---------------------------------------------------------------------------

'Определить начальное значение счетчика тактов системных часов для интервала

'---------------------------------------------------------------------------

Friend Shared Sub StartSample(ByVal sampleIndex As Integer, _

ByVal sampleName As String)

m_perfSamplesNames(sampleIndex) = sampleName

m_perfSamplesStartTicks(sampleIndex) = System.Environment.TickCount()

End Sub

'--------------------------------------------------------------------------

'Определить конечное значение счетчика тактов системных часов для интервала

'--------------------------------------------------------------------------

Friend Shared Sub StopSample(ByVal sampleIndex As Integer)

Dim stopTickCountAs Integer = System.Environment.TickCount

'Счетчик тактов системных часов сбрасывается в ноль каждые 24,9 дня

'(что соответствует примерно 2 миллиардам мс)

'Эта маловероятная возможность будет принята нами во внимание

If (stopTickCount >= m_perfSamplesStartTicks(sampleIndex)) Then

'Обычно будет выполняться этот код

m_perfSamplesDuration(sampleIndex) = _

stopTickCount - m_perfSamplesStartTicks(sampleIndex)

Else

'Значение счетчика тактов "завернулось" через ноль, и мы

'должны это учесть

m_perfSamplesDuration(sampleIndex) = stopTickCount + _

(Integer.MaxValue - m_perfSamplesStartTicks(sampleIndex)) + 1

End If

End Sub

'-------------------------------------------

'Возвратить длительность тестового интервала

'(в миллисекундах)

'-------------------------------------------

Friend Shared Function GetSampleDuration(ByVal sampleIndex _

As Integer) As Integer

Return m_perfSamplesDuration(sampleIndex)

End Function

'Возвращает длительность истекшего тестового

' интервала в секундах

Friend Shared Function GetSampleDurationText(ByVal _

sampleIndexAs Integer) As String

Return m_perfSamplesNames(sampleIndex) + ": " + _

System.Convert.ToString( _

(m_perfSamplesDuration(sampleIndex) / CDbl(1000.0)) ) + " секунд."

End Function

End Class

Листинг 7.2. Тестовая программа, демонстрирующая использование приведенного выше кода для измерения временных интервалов

Private Sub Button1_Click(ByVal senderAs System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

Const TEST_SAMPE_INDEXAs Integer = 2 'Выбрать любой допустимый индекс

'Начать измерение

PerformanceSampling.StartSample(TEST_SAMPE_INDEX, "TestSample")

'Отобразить окно сообщений

MsgBox("Для прекращения измерения нажмите кнопку OK")

'Прекратить измерение

PerformanceSampling.StopSample(TEST_SAMPE_INDEX)

'Отобразить результаты

MsgBox(PerformanceSampling.GetSampleDurationText( _

TEST_SAMPE_INDEX))

End Sub

Листинг 7.3. Демонстрация трех различных уровней организации обратной связи с пользователем

'Поместить надписи на кнопках

Private Sub Form2_Load(ByVal senderAs System.Object, _

ByVal e As System.EventArgs) Handles MyBase.Load

button1.Text = "Плохая обратная связь"

button2.Text = "Хорошая обратная связь"

button3.Text = "Улучшенная обратная связь"

End Sub

'---------------------------------------------------------------------------

'Пример слабых интерактивных возможностей интерфейса:

' - Визуальная индикация начала выполнения работы отсутствует

' - Визуальная индикация окончания выполнения работы отсутствует

' - Пользовательский интерфейс не способен к отклику в процессе работы

' - 0 завершении выполнения задачи пользователь вынужден только догадываться

'---------------------------------------------------------------------------

Private Sub Button1_Click(ByVal senderAs System.Object, _

ByVal eAs System.EventArgs) Handles Button1.Click

'Имитировать выполнение работы путем создания паузы продолжительностью

'4 секунды

System.Threading.Thread.Sleep(4000)

End Sub

'------------------------------------------------------------------------

'Пример лучших интерактивных возможностей интерфейса:

' + Визуальная индикация начала выполнения работы

' (появление курсора ожидания)

' + Визуальная индикация окончания выполнения работы

' (исчезновение курсора ожидания)

' - Пользовательский интерфейс не способен к отклику в процессе работы

' + По завершении выполнения задачи конечный пользователь узнает об этом,

' а пользовательский интерфейс восстанавливает способность к отклику

'------------------------------------------------------------------------

Private Sub Button2_Click(ByVal senderAs System.Object, _

ByVal eAs System.EventArgs) Handles Button2.Click

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.WaitCursor

'Имитировать выполнение работы путем создания паузы продолжительностью

'4 секунды

System.Threading.Thread.Sleep(4000)

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.Default

End Sub

'-------------------------------------------------------------------------

'Пример еще лучших интерактивных возможностей интерфейса:

' + Визуальная индикация начала выполнения работы

' (появление курсора ожидания)

' + Отображение дополнительного текста, сообщающего пользователю

' о том, что происходит

' + Визуальная индикация окончания выполнения работы

' (исчезновение курсора ожидания)

' - Пользовательский интерфейс не способен к отклику в процессе работы

' + По завершении выполнения задачи конечный пользователь узнает об этом,

' а пользовательский интерфейс восстанавливает способность к отклику

' + Текстовые сообщения информируют пользователя о том, что происходит

'-------------------------------------------------------------------------

Private Sub Button3_Click(ByVal senderAs System.Object, _

ByVal e As System.EventArgs) Handles Button3.Click

'Предоставить пользователю текст, информирующий его обо всем происходящем

Label1.Text = "Ждите! Работа выполняется!"

'Заставить ПИ обновить текст

'(иначе он сделает это только тогда, когда будет перерисовывать сообщение,

'а это может произойти и после выхода из данной функции)

Label1.Update()

'Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors WaitCursor

'Имитировать выполнение работы путем создания паузы продолжительностью

'2,8 секунды

System.Threading.Thread.Sleep(2800)

'Необязательное дополнительное обновление состояния

Label1.Text = "Ждите! Работа близка к завершению!"

Label1.Update()

'Имитировать выполнение работы путем создания паузы продолжительностью

'1,2 секунды

System.Threading.Thread.Sleep(1200)

'Известить пользователя текстовым сообщением о завершении работы

'(текст обновляется всякий раз, когда ПИ выполняет обычное обновление

'экрана)

Label1.Text = "Работа успешно завершена!"

'Избавиться от курсора ожидания

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.Default

End Sub

Листинг 7.4. Сравнение производительности двух алгоритмов, в одном из которых используются исключения, а во втором — нет

'==================================================================

'Примечание. В этом примере используется класс PerformanceSampling,

' определенный ранее в этой главе. Убедитесь в том, что

' этот класс включен в проект

'ТЕСТОВАЯ ФУНКЦИЯ:

'Сложить n1 и n2 и возвратить результат

'в n3

' Возвращаемое значение:

' TRUE: если результат положителен

' FALSE: если результат отрицателен

'==================================================================

Function returnFalseIfLessThanZero_Add2Numbers( _

ByVal n1As Integer, ByVal n2 As Integer, _

ByRef n3 As Integer) As Boolean

n3 = n1 + n2

'Результат меньше 0?

If (n3 < 0) Then

Return False

End If

Return True

End Function

'========================================================================

'ТЕСТОВАЯ ФУНКЦИЯ:

'Сложить n1 и n2 и возвратить результат

'в n3

'Если n3 меньше 0, то функция ПЕРЕДАЕТ УПРАВЛЕНИЕ ОБРАБОТЧИКУ ИСКЛЮЧЕНИЙ.

'В противном случае возвращается TRUE

'========================================================================

Function exceptionIfLessThanZero_Add2Numbers( _

ByVal n1As Integer, ByVal n2As Integer, _

ByRef n3 As Integer) As Boolean

n3 = n1 + n2

'Результат меньше 0?

If (n3 <0) Then

Throw New Exception("Результат меньше 0!")

End If

Return True

End Function

'=======================================================

'Осуществляет многократные вызовы простой функции и

'измеряет общее время выполнения

'Вызываемая функция НЕ приводит к возбуждению исключений

'=======================================================

Private Sub buttonRunNoExceptionCode_Click(ByVal senderAs System.Object, _

ByVal eAs System.EventArgs) Handles buttonRunNoExceptionCode.Click

Const TEST_NUMBERAs Integer = 0

Dim numberItterations As Integer

numberItterations = _

CInt(textBoxNumberAttempts.Text)

'Отобразить количество итераций, которые предстоит выполнить

ListBox1.Items.Add("=>" + numberItterations.ToString() + " итераций")

Dim count_SumLessThanZero As Integer

Dim dataOut As Integer

'----------------

'Запустить таймер

'----------------

PerformanceSampling.StartSample(TEST_NUMBER, "Исключения отсутствуют")

'------------------------------------------------------

'Выполнить цикл, в котором осуществляется вызов функции

'------------------------------------------------------

count_SumLessThanZero = 0

Dim sumGreaterThanZero As Boolean

Dim i As Integer

While (i < numberItterations)

'=========================

'Вызвать тестовую функцию!

'=========================

sumGreaterThanZero = _

returnFalseIfLessThanZero_Add2Numbers(-2, -3, dataOut)

If (sumGreaterThanZero = False) Then

count_SumLessThanZero = count_SumLessThanZero + 1

End If

i = i + 1

End While

'-----------------

'Остановить таймер

'-----------------

PerformanceSampling.StopSample(TEST_NUMBER)

'--------------------------------

'Показать результаты пользователю

'--------------------------------

If (count_SumLessThanZero = numberItterations) Then

MsgBox("Тест выполнен")

ListBox1.Items.Add( _

PerformanceSampling.GetSampleDurationText(TEST_NUMBER))

Else

MsgBox("При выполнении теста возникали осложнения")

End If

End Sub

'==================================================

'Осуществляет многократные вызовы простой функции и

'измеряет общее время выполнения.

'Вызываемая функция ВОЗБУЖДАЕТ исключения

'==================================================

Private Sub buttonRunExceptionCode_Click_Click(ByVal senderAs System.Object, _

ByVal e As System.EventArgs) Handles buttonRunExceptionCode_Click.Click

Const TESTNUMBERAs Integer = 1

'Получить количество итераций Dim numberItterationsAs

Integer numberItterations = _

CInt(textBoxNumberAttempts.Text)

'Отобразить количество итераций, которые надлежит выполнить

ListBox1.Items.Add("=>" + numberItterations.ToString() + " итераций")

Dim count_SumLessThanZero As Integer

Dim dataOut As Integer

'----------------

'Запустить таймер

'----------------

PerformanceSampling.StartSample(TEST_NUMBER, "Перехват исключения")

'------------------------------------------------------

'Выполнить цикл, в котором осуществляется вызов функции

'------------------------------------------------------

count_SumLessThanZero = 0

Dim sumGreaterThanZero As Boolean

Dim i As Integer

While (i < numberItterations)

Try

'=========================

'Вызвать тестовую функцию!

'=========================

sumGreaterThanZero = _

exceptionIfLessThanZero_Add2Numbers(-2, -3, dataOut)

Catch

count_SumLessThanZero = count_SumLessThanZero + 1

End Try

i = i + 1

End While 'конец цикла

'-----------------

'Остановить таймер

'-----------------

PerformanceSampling.StopSample(TEST_NUMBER)

'--------------------------------

'Показать результаты пользователю

'--------------------------------

If (count_SumLessThanZero = numberItterations) Then

MsgBox("Тест выполнен")

ListBox1.Items.Add( _

PerformanceSampling.GetSampleDurationText(TEST_NUMBER))

Else

MsgBox("При выполнении теста возникали осложнения")

End If

End Sub

Примеры к главе 8 (производительность и память)

Листинг 8.1. Применение отложенной загрузки, кэширования и освобождения графических ресурсов

Option Strict On

Public Class GraphicsGlobals

Private Shared s_Player_Bitmap1 As System.Drawing.Bitmap

Private Shared s_Player_Bitmap2 As System.Drawing.Bitmap

Private Shared s_Player_Bitmap3 As System.Drawing.Bitmap

Private Shared s_Player_Bitmap4 As System.Drawing.Bitmap

Private Shared s_colPlayerBitmaps As _

System.Collections.ArrayList

'----------------------

'Освободить все ресурсы

'----------------------

Public Shared Sub g_PlayerBitmapsCollection_CleanUp()

'Если не загружено ни одно изображение, то и память освобождать не от чего

If (s_colPlayerBitmapsIs Nothing) Then Return

'Дать указание каждому из этих объектов освободить

'любые удерживаемые ими неуправляемые ресурсы

s_Player_Bitmap1.Dispose()

s_Player_Bitmap2.Dispose()

s_Player_Bitmap3.Dispose()

s_Player_Bitmap4.Dispose()

'Обнулить каждую из этих переменных, чтобы им не соответствовали

'никакие объекты в памяти

s_Player_Bitmap1 = Nothing

s_Player_Bitmap2 = Nothing

s_Player_Bitmap3 = Nothing

s_Player_Bitmap4 = Nothing

'Избавиться от массива

s_colPlayerBitmaps = Nothing

End Sub

'-----------------------------------------

'Функция: возвращает коллекцию изображений

'-----------------------------------------

Public Shared Function g_PlayerBitmapsCollection() _

As System.Collections.ArrayList

'---------------------------------------------------------------

'Если изображения уже загружены, их достаточно только возвратить

'---------------------------------------------------------------

If Not (s_colPlayerBitmaps Is Nothing) Then

Return scolPlayerBitmaps

End If

'Загрузить изображения как ресурсы из исполняемого двоичного файла

Dim thisAssemblyAs System.Reflection.Assembly = _

System.Reflection.Assembly.GetExecutingAssembly()

Dim thisAssemblyNameAs System.Reflection.AssemblyName = _

thisAssembly.GetName()

Dim assemblyNameAs String = thisAssemblyName.Name

'Загрузить изображения

s_Player_Bitmap1 =New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream(assemblyName _

+ ".Hank_RightRun1.bmp"))

s_Player_Bitmap2 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream(assemblyName _

+ ".Hank_RightRun2.bmp"))

s_Player_Bitmap3 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream(assemblyName _

+ ".Hank_LeftRun1.bmp"))

s_Player_Bitmap4 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream(assemblyName _

+ ".Hank_LeftRun2.bmp"))

'Добавить изображения в коллекцию

s_colPlayerBitmaps = New System.Collections.ArrayList

s_colPlayerBitmaps.Add(s_Player_Bitmap1)

s_colPlayerBitmaps.Add(s_Player_Bitmap2)

s_colPlayerBitmaps.Add(s_Player_Bitmap3)

s_colPlayerBitmaps.Add(s_Player_Bitmap4)

'Возвратить коллекцию

Return s_colPlayerBitmaps

End Function

Private Shared s_blackPen As System.Drawing.Pen

Private Shared s_whitePen As System.Drawing.Pen

Private Shared s_ImageAttribute As _

System.Drawing.Imaging.ImageAttributes

Private Shared s_boldFont As System.Drawing.Font

'------------------------------------------------

'Вызывается для освобождения от любых графических

'ресурсов, которые могли быть кэшированы

'------------------------------------------------

Private Shared Sub g_CleanUpDrawingResources()

'Освободить память от черного пера, если таковое имеется

If Not (s_blackPenIs Nothing) Then

s_blackPen.Dispose()

s_blackPen = Nothing

End If

'Освободить память от белого пера, если таковое имеется

If Not (s_whitePenIs Nothing) Then

s_whitePen.Dispose()

s_whitePen = Nothing

End If

'Освободить память от атрибута ImageAttribute, если таковой имеется.

'Примечание. Метод Dispose() для этого типа не предусмотрен,

'поскольку все его данные являются управляемыми

If Not (s_ImageAttribute Is Nothing) Then

s_ImageAttribute = Nothing

End If

'Освободить память от полужирного шрифта, если таковой имеется

If Not (s_boldFontIs Nothing) Then

b_boldFont.Dispose()

s_boldFont = Nothing

End If

End Sub

'-----------------------------------------

'Эта функция позволяет получить доступ

'к черному перу, находящемуся в кэш-памяти

'-----------------------------------------

Private Shared Function g_GetBlackPen() As System.Drawing.Pen

'Если перо еще не существует, создать его

If (s_blackPen Is Nothing) Then

s_blackPen = New System.Drawing.Pen( _

System.Drawing.Color.Black)

End If

'Возвратить черное перо

Return s_blackPen

End Function

'----------------------------------------

'Эта функция позволяет получить доступ

'к белому перу, находящемуся в кэш-памяти

'----------------------------------------

Private Shared Function g_GetWhitePen() As System.Drawing.Pen

'Если перо еще не существует, создать его

If (s_whitePen Is Nothing) Then

s_whitePen = New System.Drawing.Pen( _

System.Drawing.Color.White)

End If

'Возвратить белое перо

Return s_whitePen

End Function

'-----------------------------------------------

'Эта функция позволяет получить доступ

'к полужирному шрифту, находящемуся в кэш-памяти

'-----------------------------------------------

Private Shared Function g_GetBoldFont() As System.Drawing.Font

'Если перо еще не существует, создать его

If (s_boldFont Is Nothing) Then

s_boldFont = New System.Drawing.Font( _

System.Drawing.FontFamily.GenericSerif, 10, System.Drawing.FontStyle.Bold)

End If

'Возвратить полужирный шрифт

Return s_boldFont

End Function

'-----------------------------------------------------

'Эта функция позволяет осуществлять доступ

'к находящемуся в кэш-памяти объекту imageAttributes,

'который мы используем для изображений с прозрачностью

'-----------------------------------------------------

Private Shared Function g_GetTransparencyImageAttribute() As _

System.Drawing.Imaging.ImageAttributes

'Если объект не существует, создать его

If (s_ImageAttributeIs Nothing) Then

'Создать атрибут изображения

s_ImageAttribute = _

New System.Drawing.Imaging.ImageAttributes

s_ImageAttribute.SetColorKey(System.Drawing.Color.White, _

System.Drawing.Color.White)

End If

'Возвратить его

Return s_ImageAttribute

End Function

End Class

Листинг 8.2. Общий код, используемый во всех приведенных ниже вариантах тестов

'Желаемое число повторений теста

Const LOOP_SIZE As Integer = 8000

'---------------------------------------------------------

'Эта функция переустанавливает содержимое нашего тестового

'массива, что обеспечивает возможность многократного

'выполнения тестового алгоритма

'---------------------------------------------------------

Private Sub ResetTestArray(ByRef testArray() As String)

If (testArray Is Nothing) Then

ReDim testArray(6)

End If

testArray(0) = "big_blue_duck"

testArray(1) = "small_yellow_horse"

testArray(2) = "wide_blue_cow"

testArray(3) = "tall_green_zepplin"

testArray(4) = "short_blue_train"

testArray(5) = "short_purple_dinosaur"

End Sub

Листинг 8.3. Тестовый пример, демонстрирующий неэкономное распределение памяти (типичный первоначальный вариант реализации интересующей нас функции)

Private Sub Button2_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button2.Click

'Вызвать сборщик мусора, чтобы быть уверенными в том, что

'тест начнется с чистого состояния.

'ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

'сборщика мусора в программах вручную будут приводить к снижению

'общей производительности приложений!

System.GC.Collect()

Dim testArray() As String = Nothing

'--------------------------------------------------

'Просмотреть элементы массива и

'найти те из них, в которых средним словом является

'"blue". Заменить "blue" на "orange"

'Запустить секундомер для нашего теста!

'--------------------------------------------------

PerformanceSampling.StartSample(0, "WastefulWorkerClass")

Dim workerClass1 As WastefulWorkerClass

Dim outerLoop As Integer

For outerLoop = 1 To LOOP_SIZE

'Присвоить элементам массива значения, которые мы хотим использовать

'при тестировании

ResetTestArray(testArray)

Dim topIndex = testArray.Length - 1

Dim idx As Integer

For idx = 0 To topIndex

'------------------------------------------

'Создать экземпляр вспомогательного класса,

'который расчленяет строку на три части

'Это неэкономный способ!

'------------------------------------------

workerClass1 = New WastefulWorkerClass(testArray(idx))

'Если средним словом является "blue", заменить его на "orange"

If (workerClass1.MiddleSegment = "blue") Then

'Заменить средний сегмент

workerClass1.MiddleSegment = "orange"

'Заменить слово

testArray(idx) = workerClass1.getWholeString()

End If

Next 'внутренний цикл

Next 'внешний цикл

'Получить время окончания теста

PerformanceSampling.StopSample(0)

MsgBox(PerformanceSampling.GetSampleDurationText(0))

End Sub

Листинг 8.4. Рабочий класс для первого тестового примера

Option Strict On

Imports System

Public Class WastefulWorkerClass

Private m_beginning_segment As String

Public Property BeginSegment() As String

Get

Return m_beginning_segment

End Get

Set(ByVal Value As String)

m_beginning_segment = Value

End Set

End Property

Private m_middle_segment As String

Public Property MiddleSegment() As String

Get

Return m_middle_segment

End Get

Set(ByVal Value As String)

m_middle_segment = Value

End Set

End Property

Private m_end_segment As String

Public Property EndSegment() As String

Get

Return m_end_segment

End Get

Set(ByVal Value As String)

m_end_segment = Value

End Set

End Property

Public Sub New(ByVal in_word As String)

Dim index_segment1 As Integer

'Осуществляем поиск символов подчеркивания ("_") в строке

index_segment1 = in_word.IndexOf("_", 0)

'В случае отсутствия символов "_" все, что нам нужно, это первый сегмент

If (index_segment1 = -1) Then

m_beginning_segment = in_word

m_middle_segment = ""

m_end segment = ""

Return

Else

'Если присутствует символ "_", отсечь его

'Если первым символом является "_", то первым сегментом будет ""

If (index_segment1 = 0) Then

m_beginning_segment = ""

Else

'Первый сегмент

m_beginning_segment = in_word.Substring(0, index_segment1)

End If

'Найти второй символ "_"

Dim index_segment2 As Integer

index_segment2 = in_word.IndexOf("_", index_segment1 + 1)

'Второй символ "_" отсутствует

If (index_segment2 = -1) Then

m_middle_segment = ""

m_end_segment = in_word.Substring(index_segment1 + 1)

Return

End If

'Установить последний сегмент

m_middle_segment = in_word.Substring(index_segment1 + 1, _

index_segment2 - index_segment1 - 1)

m_end_segment = in_word.Substring(index_segment2 + 1)

End If

End Sub

'Возвращает все три сегмента, объединенные символами "_"

Public Function getWholeString() As String

Return m_beginning_segment + "_" + m_middle_segment + "_" + _

m_end_segment

End Function

End Class

Листинг 8.5. Тестовый пример, демонстрирующий уменьшение объема памяти, распределяемой для объектов (типичный образец улучшения первоначального варианта реализации интересующей нас функции)

Private Sub Button3_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button3.Click

'Вызвать сборщик мусора, чтобы тест

'начинался с чистого состояния.

'ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

'сборщика мусора в программах вручную будут приводить к снижению

'общей производительности приложений!

System.GC.Collect()

Dim testArray() As String = Nothing

'--------------------------------------------------

'Просмотреть элементы массива и

'найти те из них, в которых средним словом является

'"blue". Заменить "blue" на "orange"

'Запустить секундомер!

'--------------------------------------------------

PerformanceSampling.StartSample(1, "LessWasteful")

'-------------------------------------------------------

'БОЛЕЕ ЭКОНОМНЫЙ СПОСОБ: Распределить память для объекта

'до вхождения в цикл

'-------------------------------------------------------

Dim workerClass1 As LessWastefulWorkerClass

workerClass1 = New LessWastefulWorkerClass

Dim outerLoop As Integer

For outerLoop = 1 To LOOP_SIZE

'Присвоить элементам массива значения, которые мы хотим использовать

'при тестировании ResetTestArray(testArray)

Dim topIndex As Integer = testArray.Length -1 Dim idx As Integer

For idx = 0 To topIndex

'---------------------------------------------------------

'Теперь вместо повторного распределения памяти для объекта

'нам достаточно лишь повторно воспользоваться им

'---------------------------------------------------------

'workerClass1 = new WastefulWorkerClass(

' testArray(topIndex))

workerClass1.ReuseClass(testArray(idx))

'Если средним словом является "blue", заменить его на "orange"

If (workerClass1.MiddleSegment = "blue") Then

'Заменить средний сегмент

workerClass1.MiddleSegment = "orange"

'Заменить слово

testArray(idx) = workerClass1.getWholeString()

End If

Next ' внутренний цикл

Next 'внешний цикл

'Остановить секундомер!

PerformanceSampling.StopSample(1)

MsgBox(PerformanceSampling.GetSampleDurationText(1))

End Sub

Листинг 8.6. Рабочий класс для второго тестового примера

Option Strict

On Imports System

Public Class LessWastefulWorkerClass

Private m_beginning_segment As String

Public Property BeginSegment() As String

Get

Return m_beginning_segment

End Get

Set(ByVal Value As String)

m_beginning_segment = Value

End Set

End Property

Private m_middle_segment As String

Public Property MiddleSegment() As String

Get

Return m_middle_segment

End Get

Set(ByVal Value As String)

m_middle_segment = Value

End Set

End Property

Private m_end_segment As String

Public Property EndSegment() As String

Get

Return m_end_segment

End Get

Set(ByVal Value As String)

m_end_segment = Value

End Set

End Property

Public Sub ReuseClass(ByVal in_word As String)

'----------------------------------------------

'Для повторного использования класса необходимо

'полностью очистить внутреннее состояние

'----------------------------------------------

m_beginning_segment = ""

m_middle_segment = ""

m_end_segment = ""

Dim index_segment1 As Integer

'Осуществляем поиск символов подчеркивания ("_") в строке

index_segment1 = in_word.IndexOf("_", 0)

'В случае отсутствия символов "_" все, что нам нужно, это первый сегмент

If (index_segment1 = -1) Then

m_beginning_segment = in_word

Return

Else

'Если присутствует символ "_", отсечь его

If (index_segment1 = 0) Then

Else

m_beginning_segment = in_word.Substring(0, _

index_segment1)

End If

Dim index_segment2 As Integer

index_segment2 = in_word.IndexOf("_", index_segment1 + 1)

If (index segment2 = -1) Then

m_end_segment = in_word.Substring(index_segment1 + 1)

Return

End If

'Установить последний сегмент

m_middle_segment = in_word.Substring(index_segment1 + 1, _

index_segment2 - index_segment1 - 1)

m_end_segment = in_word.Substring(index_segment2 + 1)

End If

End Sub

Public Function getWholeString() As String

Return m_beginning_segment + " " + m_middle_segment + " " + _

m_end_segment

End Function

End Class

Листинг 8.7. Тестовый пример, демонстрирующий значительное уменьшение объема памяти, распределяемой для объектов (типичный образец существенной алгоритмической оптимизации первоначального варианта реализации интересующей нас функции)

Private Sub Button5 Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button5.Click

'Вызвать сборщик мусора, чтобы тест

'начинался с чистого состояния.

'ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

'сборщика мусора в программах вручную будут приводить к снижению

'общей производительности приложений!

System.GC.Collect()

Dim testArray() As String = Nothing

'--------------------------------------------------

'Просмотреть элементы массива и

'найти те из них, в которых средним словом является

'"blue". Заменить "blue" на "orange"

'--------------------------------------------------

'Запустить секундомер перед началом выполнения теста

PerformanceSampling.StartSample(2, "DefferedObjects")

'-------------------------------------------------------

'БОЛЕЕ ЭКОНОМНЫЙ СПОСОБ: Распределить память для объекта

'до вхождения в цикл

'-------------------------------------------------------

Dim workerClass1 As LessAllocationsWorkerClass

workerClass1 = New LessAllocationsWorkerClass

Dim outerLoop As Integer

For outerLoop = 1 To LOOP_SIZE

'Присвоить элементам массива значения, которые мы хотим использовать

'при тестировании

ResetTestArray(testArray)

Dim topIndex As Integer = testArray.Length - 1 Dim idx As Integer

For idx = 0 To topIndex

'------------------------------------------------------------

'Более экономный способ:

'Теперь вместо повторного распределения памяти для объекта

'нам достаточно лишь повторно воспользоваться им

'Кроме того: в этом варианте реализации дополнительные строки

'НЕ создаются

'workerClass1 = new WastefulWorkerClass(

'      testArray[topIndex])

'------------------------------------------------------------

workerClass1.ReuseClass(testArray(idx))

'Если средним словом является "blue", заменить его на "orange"

'-------------------------------------------------------------

'Более экономный способ:

'При таком способе сравнения не требуется создавать

'никаких дополнительных строк

'-------------------------------------------------------------

If (workerClass1.CompareMiddleSegment("blue") = 0) Then

'Заменить средний сегмент

workerClass1.MiddleSegment = "orange"

'Заменить слово

testArray(idx) = workerClass1.getWholeString()

End If

Next 'внутренний цикл

Next 'внешний цикл

'Остановить секундомер!

PerformanceSampling.StopSample(2)

MsgBox(PerformanceSampling.GetSampleDurationText(2))

End Sub

Листинг 8.8. Рабочий класс для третьего тестового примера

Option Strict On

Imports System

Public Class LessAllocationsWorkerClass

Public WriteOnly Property MiddleSegment() As String

Set(ByVal Value As String)

m_middleSegmentNew = Value

End Set

End Property

Private m_middleSegmentNew As String

Private m_index_1st_undscore As Integer

Private m_index_2nd_undscore As Integer

Private m_stringIn As String

Public Sub ReuseClass(ByVal in_word As String)

'----------------------------------------------

'Для повторного использования класса необходимо

'полностью очистить внутреннее состояние

'----------------------------------------------

m_index_1st_undscore = -1

m_index_2nd_undscore = -1

m_middleSegmentNew = Nothing

m_stringIn = in_word 'Это не приводит к созданию копии строки

'Осуществляем поиск символов подчеркивания ("_") в строке

m_index_1st_undscore = in_word.IndexOf("_", 0)

'В случае отсутствия символов "_" все, что нам нужно, это первый сегмент

If (m_index_1st_undscore = -1) Then

Return

End If

'Найти второй символ "_"

m_index_2nd_undscore = in_word.IndexOf("_", _

m_index_1st_undscore + 1)

End Sub

Public Function CompareMiddleSegment(ByVal compareTo As String) As Integer

'В случае отсутствия второго символа "_" отсутствует и средний сегмент

If (m_index_2nd_undscore < 0) Then

'Если мы сравниваем с пустой строкой, то это означает

'совпадение

If ((compareTo = Nothing) OrElse (compareTo = "")) Then

Return 0

End If

Return -1

End If

'Сравнить средний сегмент с первым и вторым сегментами

Return System.String.Compare(m_stringIn, m_index_1st_undscore + 1, _

compareTo, 0, _

m_index_2nd_undscore - m_index_1st_undscore - 1)

End Function

Public Function getWholeString() As String

'Если полученный средний сегмент не является новым,

'возвратить исходный сегмент

If (m_middleSegmentNew = Nothing) Then

Return m_stringIn

End If

'Создать возвращаемую строку

Return m_stringIn.Substring(0, m index_1st_undscore + 1) + _

m_middleSegmentNew + m_stringIn.Substring( _

m_index_2nd_undscore, _

m_stringIn.Length - m_index_2nd_undscore)

End Function

End Class

Листинг 8.9. Сравнение эффективности использования строк и класса stringBuilder в алгоритмах

Const COUNT_UNTIL As Integer = 300

Const LOOP_ITERATIONS As Integer = 40

'---------------------------------------------------------

'НЕ ОЧЕНЬ ЭФФЕКТИВНЫЙ АЛГОРИТМ!

'Для имитации создания типичного набора строк используются

'обычные строки

'---------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Вызвать сборщик мусора, чтобы тест

'начинался с чистого состояния.

'ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

'сборщика мусора в программах вручную будут приводить к снижению

'общей производительности приложений!

System.GC.Collect()

Dim numberToStore As Integer

PerformanceSampling.StartSample(0, "StringAllocaitons")

Dim total_result As String

Dim outer_loop As Integer

For outer_loop = 1 To LOOP_ITERATIONS

'Сбросить старый результат

total_result = ""

'Выполнять цикл до максимального значения x_counter, каждый раз

'присоединяя очередную тестовую строку к рабочей строке

Dim x_counter As Integer

For x_counter = 1 To COUNT_UNTIL

total_result = total_result + numberToStore.ToString() + ", "

'Увеличить значение счетчика

numberToStore = numberToStore + 1

Next

Next

PerformanceSampling.StopSample(0)

'Отобразить длину строки

MsgBox("String Length: " + total_result.Length.ToString())

'Отобразить строку

MsgBox("String : " + total_result)

'Отобразить длительность интервала времени, ушедшего на вычисления

MsgBox(PerformanceSampling.GetSampleDurationText(0))

End Sub

'---------------------------------------------------------

'ГОРАЗДО БОЛЕЕ ЭФФЕКТИВНЫЙ АЛГОРИТМ!

'Для имитации создания типичного набора строк используется

'конструктор строк (String Builder)

'---------------------------------------------------------

Private Sub Button2_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button2.Click

'Вызвать сборщик мусора, чтобы тест

'начинался с чистого состояния.

'ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

'сборщика мусора в программах вручную будут приводить к снижению

'общей производительности приложений!

System.GC.Collect()

Dim sb As System.Text.StringBuilder = _

New System.Text.StringBuilder

Dim total_result As String

Dim numberToStore As Integer

PerformanceSampling.StartSample(1, "StringBuilder")

Dim outer_loop As Integer

For outer_loop = 1 To LOOP_ITERATIONS

'Очистить конструктор строк

sb.Length = 0

'Очистить строку со старым результатом

total_result = ""

'Выполнять цикл до максимального значения x_counter, каждый раз

'присоединяя очередную тестовую строку к рабочей строке

Dim x_counter As Integer

For x_counter = 1 To COUNT_UNTIL

sb.Append(numberToStore)

sb.Append(", ")

'Увеличить значение счетчика

numberToStore = numberToStore + 1

Next

'Имитируем выполнение некоторых операций над строкой...

total_result = sb.ToString()

Next

PerformanceSampling StopSample(1)

'Отобразить длину строки

MsgBox("Длина строки: " + total_result.Length.ToString())

'Отобразить строку

MsgBox("String : " + total_result)

'Отобразить длительность интервала времени, ушедшего на вычисления

MsgBox(PerformanceSampling.GetSampleDurationText(1))

End Sub

Примеры к главе 9 (производительность и многопоточное выполнение)

Листинг 9.1. Код для управления выполнением одиночной задачи фоновым потоком

Option Strict On

Imports System

Public Class ThreadExecuteTask

'Перечисляем возможные состояния

Public Enum ProcessingState

'-------------------

'Начальное состояние

'-------------------

'Перечисляем возможные состояния

notYetStarted

'-----------------

'Рабочие состояния

'-----------------

'Ожидание запуска фонового потока

waitingToStartAsync

'Выполнение кода в фоновом потоке

running

'Запросить отмену выполнения вычислений

requestAbort

'--------------------

'Состояния завершения

'--------------------

'Состояние завершения: выполнение фонового потока

'успешно завершено

done

'Состояние завершения: выполнение потока отменено

'до его завершения

aborted

End Enum

Private m_processingState As ProcessingState

Public Delegate Sub ExecuteMeOnAnotherThread(_

ByVal checkForAborts As ThreadExecuteTask)

Private m_CallFunction As ExecuteMeOnAnotherThread

Private m_useForStateMachineLock As Object

Public Sub New(ByVal functionToCall As ExecuteMeOnAnotherThread)

'Создать объект, который мы можем использовать в конечном автомате

'в целях блокировки

m_useForStateMachineLock = New Object

'Обозначить готовность к началу выполнения

m_processingState = ProcessingState.notYetStarted

'Сохранить функцию, которую необходимо вызвать

'в новом потоке

m CallFunction = functionToCall

'----------------------------------------------------------

'Создать новый поток и вызвать в нем функцию на выполнение:

' this.ThreadStartPoint()

'----------------------------------------------------------

Dim threadStart As System.Threading.ThreadStart threadStart = _

New System.Threading.ThreadStart(AddressOf ThreadStartPoint)

Dim newThread As System.Threading.Thread

newThread = New System.Threading.Thread(threadStart)

'Обозначить готовность к началу выполнения (в целях определенности

'это важно сделать еще до того, как будет запущен поток!)

setProcessingState(ProcessingState.waitingToStartAsync)

'Дать ОС команду начать выполнение нового потока в асинхронном режиме

newThread.Start()

'Возвратить управление функции, вызывающей этот поток

End Sub

'-------------------------------------------------

'Эта функция является точкой входа, вызываемой для

'выполнения в новом потоке

'-------------------------------------------------

Private Sub ThreadStartPoint()

'Установить состояние обработки, соответствующее выполнению

'функции в новом потоке!

setProcessingState(ProcessingState.running)

'Запустить на выполнение пользовательский код и передать указатель в наш

'класс, чтобы этот код мог периодически проверять, не поступил ли запрос

'на прекращение выполнения

m_CallFunction (Me)

'Если выполнение не было отменено, изменить состояние таким образом,

'чтобы оно соответствовало успешному завершению

If (m_processingState <> ProcessingState.aborted) Then

'Обозначить завершение выполнения

setProcessingState(ProcessingState.done)

End If

'Выйти из потока...

End Sub

'----------------

'Конечный автомат

'----------------

Public Sub setProcessingState(ByVal nextState As _

ProcessingState)

'В любой момент времени только одному потоку выполнения могут быть

'разрешены попытки изменить состояние

SyncLock (m_useForStateMachineLock)

'В случае попытки повторного вхождения в текущее состояние

'никакие дополнительные действия не выполняются

If (m_processingState = nextState) Then

Return

End If

'-----------------------------------------------------------

'Простейший защитный код, гарантирующий

'невозможность перехода в другое состояние, если задача либо

'успешно завершена, либо успешно отменена

'-----------------------------------------------------------

If ((m_processingState = ProcessingState.aborted) OrElse _

(m_processingState = ProcessingState.done)) Then

Return

End If

'Убедиться в допустимости данного изменения состояния

Select Case (nextState)

Case ProcessingState.notYetStarted

Throw New Exception _

("Переход в состояние 'notYetStarted' невозможен")

Case ProcessingState.waitingToStartAsync

If (m_processingState <> ProcessingState.notYetStarted) Then

Throw New Exception("Недопустимое изменение состояния")

End If

Case ProcessingState.running

If (m_processingState <> _

ProcessingState.waitingToStartAsync) Then

Throw New Ехсерtion("Недопустимое изменение состояния")

End If

Case ProcessingState.done

'Мы можем завершить работу лишь тогда, когда она выполняется.

'Это возможно также в тех случаях, когда пользователь затребовал

'отмену выполнения, но работа к этому моменту уже была закончена

If ((m_processingState <> ProcessingState.running) AndAlso _

(m_processingState <> ProcessingState.requestAbort)) Then

Throw New Exception("Недопустимое изменение состояния")

End If

Case ProcessingState.aborted

If (m_processingState <> ProcessingState.requestAbort) Then

Throw New Exception("Недопустимое изменение состояния")

End If

End Select

'Разрешить изменение состояния

m_processingState = nextState

End SyncLock

End Sub

Public ReadOnly Property State() As ProcessingState

Get

Dim currentState As ProcessingState

'Предотвратить попытки одновременного чтения/записи состояния

SyncLock (m_useForStateMachineLock)

currentState = m_orocessingState

End SyncLock

Return currentState

End Get

End Property

End Class

Листинг 9.2. Тестовая программа для выполнения работы в фоновом потоке

Option Strict On

Imports System

'---------------------------------------------------------

'Тестовый код, который используется для выполнения фоновым

'потоком

'---------------------------------------------------------

Public Class Test1

Public m_loopX As Integer

'------------------------------------------------------------------

'Функция, вызываемая фоновым потоком

' [in] threadExecute: Класс, управляющий выполнением нашего потока.

' Мы можем контролировать его для проверки

' того, не следует ли прекратить вычисления

'------------------------------------------------------------------

Public Sub ThreadEntryPoint(ByVal threadExecute As _

ThreadExecuteTask)

'Это окно сообщений будет отображаться в контексте того потока,

'в котором выполняется задача MsgBox("Выполнение ТЕСТОВОГО ПОТОКА")

'-------

' 60 раз

'-------

For m_loopX = 1 To 60

'Если затребована отмена выполнения, мы должны завершить задачу

If (threadExecute.State = _

ThreadExecuteTask.ProcessingState.requestAbort) Then

threadExecute.setProcessingState( _

ThreadExecuteTask.ProcessingState.aborted)

Return

End If

'Имитировать выполнение работы: пауза 1/3 секунды

System.Threading.Thread.Sleep(333)

Next

End Sub

End Class

Листинг 9.3. Код для запуска и тестирования приведенного выше тестового кода

'Класс, который будет управлять выполнением нового потока

Private m_threadExecute As ThreadExecuteTask

'Класс, метод которого мы хотим выполнять в асинхронном режиме

Private m_testMe As Test1

'-----------------------------------------------------------------------

'Этот код должен быть запущен ранее другого кода, поскольку он запускает

'новый поток выполнения!

'

'Создать новый поток и обеспечить его выполнение

'-----------------------------------------------------------------------

Private Sub buttonStartAsyncExecution_Click(ByVal sender _

As System.Object, ByVal e As System.EventArgs) _

Handles buttonStartAsyncExecution.Click

'Создать экземпляр класса, метод которого мы хотим вызвать

'в другом потоке

m_testMe = New Test1

'Упаковать точку входа метода класса в делегат

Dim delegateCallCode As _

ThreadExecuteTask.ExecuteMeOnAnotherThread

delegateCallCode = _

New ThreadExecuteTask.ExecuteMeOnAnotherThread(AddressOf _

m_testMe.ThreadEntryPoint)

'Дать команду начать выполнение потока!

m_threadExecute = New ThreadExecuteTask(delegateCallCode)

End Sub

'Принудительно вызвать запрещенное изменение состояния (это приведет

'к возбуждению исключения)

Private Sub buttonCauseException_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) _

Handles buttonCauseException.Click

m_threadExecute.setProcessingState( _

ThreadExecuteTask.ProcessingState.notYetStarted)

End Sub

'Послать асинхронному коду запрос с требованием отмены его выполнения

Private Sub buttonAbort_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles buttonAbort.Click

m_threadExecute.setProcessingState( _

ThreadExecuteTask.ProcessingState.requestAbort)

End Sub

'Проверить состояние выполнения

Private Sub buttonCheckStatus_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles ButtonCheckStatus.Click

'Запросить у класса управления потоком, в каком состоянии он находится

MsgBox(m_threadExecute.State.ToString())

'Запросить класс, метод которого выполняется в потоке,

'o состоянии выполнения

MsgBox(m_testMe.m_loopX.ToString())

End Sub

Листинг 9.4. Код, который должен быть помещен в класс Smartphone Form1.cs

'------------------------------------------------------

'Весь этот код должен находиться внутри класса Form1.cs

'------------------------------------------------------

'Объект, который будет выполнять все фоновые вычисления

Private m_findNextPrimeNumber As FindNextPrimeNumber

'--------------------------------------------

'Обновить текст, информирующий о состоянии...

'--------------------------------------------

Sub setCalculationStatusText(ByVal text As String)

Label1.Text = text

End Sub

Private Sub menuItemExit_Click(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles menuItemExit.Click

Me.Close()

End Sub

'----------------------------------------

'Пункт меню для начала фоновых вычислений

'----------------------------------------

Private Sub menuItemStart Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) _

Handles menuItemStart.Click

'Число, с которого мы хотим начать поиск

Dim startNumber As Long = System.Convert.ToInt64(TextBox1.Text)

'Установить фоновое выполнение

m_findNextPrimeNumber = New FindNextPrimeNumber(startNumber)

'Запустить выполнение задачи в фоновом режиме...

m_findNextPrimeNumber.findNextHighestPrime_Async()

'Установить таймер, используемый для контроля длительности вычислений

Timer1.Interval = 400 '400 мс

Timer1.Enabled = True

End Sub

'--------------------------------------------

'Пункт меню для "отмены" выполняющейся задачи

'--------------------------------------------

Private Sub menuItemAbortClick(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles menuItemAbort.Click

'Не делать ничего, если вычисления не выполняются

If (m_findNextPrimeNumber Is Nothing) Then Return

'Установить поток в состояние прекращения выполнения

m_findNextPrimeNumber.setProcessingState( _

FindNextPrimeNumber.ProcessingState.requestAbort)

'Немедленно известить пользователя 'o готовности прекратить выполнение...

setCalculationStatusText("Ожидание прекращения выполнения...")

End Sub

'--------------------------------------------------------------

'Этот таймер, вызываемый потоком пользовательского интерфейса,

'позволяет отслеживать состояние выполнения 'фоновых вычислений

'--------------------------------------------------------------

Private Sub Timer1_Tick(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Timer1.Tick

'Если к моменту вызова искомое простое число еще

'не было найдено, отключить таймер

If (m_findNextPrimeNumber Is Nothing) Then

Timer1.Enabled = False

Return

End If

'-------------------------------------------------

'Если выполнение было отменено, освободить объект,

'осуществляющий поиск, и выключить таймер

'-------------------------------------------------

If (m_findNextPrimeNumber.getProcessingState = _

FindNextPrimeNumber.ProcessingState.aborted) Then

Timer1.Enabled = False

m_findNextPrimeNumber = Nothing

setCalculationStatusText("Поиск простого числа отменен")

Return

End If

'----------------------------------

'Удалось ли найти правильный ответ?

'----------------------------------

If (m_findNextPrimeNumber.getProcessingState = _

FindNextPrimeNumber.ProcessingState.foundPrime) Then

Timer1.Enabled = False

'Отобразить результат

setCalculationStatusText("Число найдено! Следующее простое число = " + _

m_findNextPrimeNumber.getPrime().ToString())

m_findNextPrimeNumber = Nothing

Return

End If

'--------------------------------------

'Вычисления продолжаются. Информировать

'пользователя о состоянии выполнения...

'--------------------------------------

'Получить два выходных значения

Dim numberCalculationsToFar As Long

Dim currentItem As Long

m_findNextPrimeNumber.getExecutionProgressInfo( _

numberCalculationsToFar, currentItem)

setCalculationStatusText("Вычисления продолжаются. Поиск в области: " + _

CStr(currentItem) + ". " + _

"Для вас выполнено " + CStr(numberCalculationsToFar) + _

" расчетов!")

End Sub

Листинг 9.5. Код класса FindNextPrimeNumber.cs

Option Strict On

Imports System

Public Class FindNextPrimeNumber

'Перечисляем возможные состояния

Public Enum ProcessingState

notYetStarted

waitingToStartAsync

lookingForPrime

foundPrime

requestAbort

aborted

End Enum

Private m_startPoint As Long

Private m_NextHighestPrime As Long

'Поиск какого количества элементов выполнен?

Private m_comparisonsSoFar As Long

'Для какого элемента сейчас выполняется поиск простого числа?

Private m_CurrentNumberBeingExamined As Long

'Вызывается для обновления информации о состоянии выполнения

Public Sub getExecutionProgressInfo( _

ByRef numberCalculationsSoFar As Long, _

ByRef currentItemBeingLookedAt As Long)

'ПРИМЕЧАНИЕ. Мы используем блокирование потока для уверенности в том,

'что эти значения не считываются во время выполнения операции

'их записи. Поскольку доступ к m_comparisonsSoFar

'и m_CurrentNumberBeingExamined могут осуществлять

'одновременно несколько потоков, любая выполняемая над ними

'операция записи/считывания должна синхронизироваться с "блокировкой",

'что будет гарантировать "атомарность" этих операций

SyncLock (Me)

numberCalculationsSoFar = m_comparisonsSoFar

currentItemBeingLookedAt = m_CurrentNumberBeingExamined

End SyncLock

End Sub

Private m_processingState As ProcessingState

'---------------------------

'Простейший конечный автомат

'---------------------------

Public Sub setProcessingState(ByVal nextState As _

ProcessingState)

'Простейший защитный код, гарантирующий

'невозможность перехода в другое состояние, если задача

'либо успешно завершена, либо успешно отменена

If ((m_processingState = ProcessingState.aborted) _

OrElse (m_processingState = ProcessingState.foundPrime)) Then

Return

End If

'Разрешить изменение состояния

m_processingState = nextState

End Sub

Public ReadOnly Property getProcessingState() As ProcessingState

Get

Return m_processingState

End Get

End Property

'------------------------

'Возвращает простое число

'------------------------

Public Function getPrime() As Long

If (m_processingState <> ProcessingState.foundPrime) Then

Throw New Exception("Простое число еще не найдено!")

End If

Return m_NextHighestPrime

End Function

'Конструктор класса

Public Sub New(ByVal startPoint As Long)

setProcessingState(ProcessingState.notYetStarted)

m_startPoint = startPoint

End Sub

'-----------------------------------------------------------

'Создает новый рабочий поток, который будет вызывать функцию

'findNextHighestPrime()

'-----------------------------------------------------------

Public Sub findNextHighestPrime_Async()

Dim threadStart As System.Threading.ThreadStart

threadStart = _

New System.Threading.ThreadStart(AddressOf _

findNextHighestPrime)

Dim newThread As System.Threading.Thread

newThread = New System.Threading.Thread(threadStart)

'Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.waitingToStartAsync)

newThread.Start()

End Sub

'-------------------------------------------------------------

'Основной рабочий поток. Этот поток запускает поиск очередного

'простого числа и выполняется до тех пор, пока не произойдет

'одно из следующих двух событий:

' (а) найдено очередное простое число

' (b) от внешнего (по отношению к данному) потока поступила

' команда прекратить выполнение

'--------------------------------------------------------------

Public Sub findNextHighestPrime()

'Если поступила команда прекратить выполнение, то поиск даже

'не должен начинаться

If (m_processingState = ProcessingState.requestAbort) Then

GoTo finished_looking

End If

'Состояние должно отвечать, что поиск продолжается

setProcessingState(ProcessingState.lookingForPrime)

Dim currentItem As Long

'Проверить, является ли число нечетным

If ((m_startPoint And 1) = 1) Then

'Число является нечетным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 2

Else

'Число является четным, начать поиск со следующего нечетного числа

currentItem = m_startPoint + 1

End If

'Приступить к поиску простого числа

While (m_processingState = ProcessingState.lookingForPrime)

'B случае нахождения простого числа, возвратить его

If (isItemPrime(currentItem) = True) Then

m_NextHighestPrime = currentItem

'Обновить состояние

setProcessingState(ProcessingState.foundPrime)

End If

currentItem = currentItem + 2

End While

finished_looking:

'Выход. К этому моменту либо от другого потока поступила

'команда прекратить поиск, либо было найдено и записано

'следующее наибольшее простое число

'Если поступил запрос прекратить выполнение,

'сообщить, что выполнение процесса прекращено

If (m_processingState = ProcessingState.requestAbort) Then

setProcessingState(ProcessingState.aborted)

End If

End Sub

'Вспомогательная функция, которая проверяет, является

'ли число простым

Private Function isItemPrime(ByVal potentialPrime _

As Long) As Boolean

'Если число - четное, значит, оно не является простым

If ((potentialPrime And 1) = 0) Then

Return False

End If

'Продолжать поиск до тех пор, пока не будет превышено значение

'квадратного корня из числа

Dim end_point_of_search As Long end_point_of_search = _

CLng(System.Math.Sqrt(potentialPrime)) + 1

Dim current_test_item As Long = 3

While (current_test_item <= end_point_of_search)

'---------------------------------------------------------

'Проверить, не поступила ли команда прекратить выполнение!

'---------------------------------------------------------

If (m_processingState <> ProcessingState.lookingForPrime) Then

Return False

End If

'Если число делится без остатка,

'значит, оно не является простым

If (potentialPrime Mod current_test_item = 0) Then

Return False

End If

'Увеличить число на два

current_test_item = current test_item + 2

'-------------------------------------

'Увеличить число проверенных элементов

'-------------------------------------

'ПРИМЕЧАНИЕ. Мы используем блокирование потока для уверенности в том,

'что эти значения не считываются во время выполнения операции

'их записи. Поскольку доступ к m_comparisonsSoFar

'и m_CurrentNumberBeingExamined могут осуществлять

'одновременно несколько нитей, любая выполняемая над ними

'операция записи/считывания должна синхронизироваться с "блокировкой",

'что будет гарантировать "атомарность" этих операций

SyncLock (Me)

m_CurrentNumberBeingExamined = potentialPrime

m_comparisonsSoFar = m_comparisonsSoFar + 1

End SyncLock

End While

'Число является простым

Return True

End Function

End Class

Примеры к главе 10 (производительность и XML)

Листинг 10.1. Использование XML DOM для сохранения данных в файле и их загрузки

Option Strict On

Option Compare Binary

Imports System

'---------------------------------------------

'Демонстрирует сохранение и загрузку файлов с

'использованием объектной модели документа XML

'---------------------------------------------

Public Class SaveAndLoadXML_UseDOM

'XML-дескрипторы, которые мы будем использовать в нашем документе

Const XML_ROOT_TAG As String = "AllMyData"

Const XML_USERINFO_TAG As String = "UserInfo"

Const XML_USERID_TAG As String = "UserID"

Const XML_NAMEINFO_TAG As String = "Name"

Const XML_FIRSTNAME _TAG As String = "FirstName"

Const XML_LASTNAME_TAG As String = "LastName"

'--------------------------------------------------------------

'Загружает пользовательское состояние

' [in] fileName: Имя файла, используемого для сохранения данных

' [out] userId: Загруженный идентификатор пользователя

' [out] firstName: Загруженное имя пользователя

' [out] lastName: Загруженная фамилия пользователя

'--------------------------------------------------------------

Public Shared Sub XML_LoadUserInfo(ByVal fileName As String, _

ByRef userId As Integer, ByRef firstName As String, _

ByRef lastName As String)

'Начинаем с нулевых значений

userId = 0

firstName = ""

lastName = ""

'Предполагаем, что данные еще не загружены

Dim gotUserInfoData As Boolean = False

Dim xmlDocument As System.Xml.XmlDocument = _

New System.Xml.XmlDocument

xmlDocument.Load(fileName)

'Получить корневой узел

Dim rootElement As System.Xml.XmlElement

rootElement = _

CType(xmlDocument.ChildNodes(0), System.Xml.XmlElement)

'Убедиться в том, что корневой узел согласуется с ожидаемым текстом,

'ибо противное означает, что мы имеем дело с каким-то другим XML-файлом

If (rootElement.Name <> XML_ROOT_TAG) Then

Throw New Exception("Тип корневого узла не совпадает с ожидаемым!")

End If

'-----------------------------------------------------------

'Простой конечный автомат для итеративного обхода всех узлов

'-----------------------------------------------------------

Dim childOf_RootNode As System.Xml.XmlElement

For Each childOf_RootNode In _

rootElement.ChildNodes

'Если это узел UserInfo, то мы хотим просмотреть его содержимое

If (childOf_RootNode.Name = XML_USERINFO_TAG) Then

gotUserInfoData = True

'Пользовательские данные найдены

'--------------------------------

'Загрузить каждый из подэлементов

'--------------------------------

Dim child_UserDataNode As System.Xml.XmlElement

For Each child_UserDataNode In _

childOf_RootNode.ChildNodes

'Идентификатор пользователя (UserID)

If (child_UserDataNode.Name = XML_USERID_TAG) Then

userId = CInt(child_UserDataNode.InnerText)

'ФИО пользователя (UserName)

ElseIf (child_UserDataNode.Name = XML_NAMEINFO_TAG) Then

Dim child_Name As System.Xml.XmlElement

For Each child_Name In child_UserDataNode.ChildNodes

'Имя (FirstName)

If (child_Name.Name = XML_FIRSTNAME_TAG) Then

firstName = child_Name.InnerText

'Фамилия (LastName)

ElseIf (chi1d_Name.Name = XML_LASTNAME_TAG) Then

lastName = child_Name.InnerText

End If

Next 'Конец цикла разбора UserName

End If 'Конец оператора if, осуществляющего проверку UserName

Next 'Конец цикла разбора UserInfo

End If 'Конец оператора if, осуществляющего проверку UserInfo

Next 'Конец цикла разбора корневого узла

If (gotUserInfoData = False) Then

Throw New Exception("Данные пользователя в XML-документе не найдены!")

End If

End Sub

'--------------------------------------------------------------------

'Сохраняет пользовательское состояние

' [in] fileName: Имя файла, используемого для сохранения данных

' [in] userId: Идентификатор пользователя, который мы хотим сохранить

' [in] firstName: Имя пользователя, которое мы хотим сохранить

' [in] lastName: Фамилия пользователя, которую мы хотим сохранить

'--------------------------------------------------------------------

Public Shared Sub XML_SaveUserInfo(ByVal fileName As String, _

ByVal userId As Integer, ByVal firstName As String, _

ByVal lastName As String)

Dim xmlDocument As System.Xml.XmlDocument = _

New System.Xml.XmlDocument

'-----------------------------------------

'Добавить элемент документа высшего уровня

'-----------------------------------------

Dim rootNodeForDocument As System.Xml.XmlElement

rootNodeForDocument = xmlDocument.CreateElement( _

XML_ROO T_TAG)

xmlDocument.AppendChild(rootNodeForDocument)

'----------------------------------

'Добавить данные в элемент UserInfo

'----------------------------------

Dim topNodeForUserData As System.Xml.XmlElement

topNodeForUserData = xmlDocument.CreateElement( _

XML_USERINFO_TAG)

rootNodeForDocument.AppendChild(topNodeForUserData)

'---------------------------------------

'Добавить значение UserID в наш документ

'---------------------------------------

'Создать подузел для информации о пространстве имен

Dim subNodeForUserID As System.Xml.XmlElement

subNodeForUserID = _

xmlDocument.CreateElement(XML_USERID_TAG)

subNodeForUserID.InnerText = _

System.Convert.ToString(userId)

'Присоединить подузел UserID к узлу высшего уровня

topNodeForUserData.AppendChild(subNodeForUserID)

'---------------------------------------------

'Добавить все значения NameInfo в наш документ

'---------------------------------------------

'Создать подузел для информации о пространстве имен

Dim subNodeForNameInfo As System.Xml.XmlElement

subNodeForNameInfo = xmlDocument.CreateElement( _

XML_NAMEINFO_TAG)

'Имя (FirstName)

Dim subNodeFirstName As System.Xml.XmlElement

subNodeFirstName = xmlDocument.CreateElement( _

XML_FIRSTNAME TAG)

subNodeFirstName.InnerText = firstName

'Фамилия (LastName)

Dim subNodeLastName As System.Xml.XmlElement

subNodeLastName = xmlDocument.CreateElement( _

XML_LASTNAME_TAG)

subNodeLastName.InnerText = lastName

'Присоединить подузлы имени и фамилии к родительскому узлу

'NameInfo

subNodeForNameInfo.AppendChild(subNodeFirstName)

subNodeForNameInfo.AppendChild(subNodeLastName)

'Присоединить подузел NameInfo (вместе с его дочерними узлами)

'к узлу высшего уровня

topNodeForUserData.AppendChild(subNodeForNameInfo)

'------------------

'Сохранить документ

'------------------

Try

xmlDocument.Save(fileName)

Catch ex As System.Exception

MsgBox( _

"Ошибка при сохранении XML-документа - " + ex.Message)

End Try

End Sub 'Конец функции

End Class 'Конец класса

Листинг 10.2. Вызов кода, предназначенного для сохранения и загрузки XML-документа

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

Const FILENAME As String = "TestFileName.XML"

'Сохранить, используя XML DOM

SaveAndLoadXML_UseDOM.XML_SaveUserInfo(FILENAME, 14, "Ivo", _

"Salmre")

'Сохранить, используя объект однонаправленной записи XMLWriter

'SaveAndLoadXML_UseReaderWriter.XML_SaveUserInfo(FILENAME, _

' 18, "Ivo", "Salmre")

Dim userID As Integer

Dim firstName As String

Dim lastName As String

'Загрузить, используя XML DOM

SaveAndLoadXML_UseDOM.XML_LoadUserInfo(FILENAME, userID, _

firstName, lastName)

'Загрузить, используя объект однонаправленного чтения XMLReader

'SaveAndLoadXML_UseReaderWriter.XML_LoadUserInfo(FILENAME, _

' userID, firstName, lastName)

MsgBox("Готово! " + _

userID.ToString() + ", " + lastName + ", " + firstName)

End Sub

Листинг 10.3. Использование однонаправленного чтения/записи XML-данных для загрузки XML-документа из файла и его сохранения

Option Strict On

Option Compare Binary

Imports System

Public Class SaveAndLoadXML UseReaderWriter

'XML-дескрипторы, которые мы будем использовать в своем документе

Const XML_ROOT_TAG As String = "AllMyData"

Const XML_USERINFO_TAG As String = "UserInfo"

Const XML_USERID_TAG As String = "UserID"

Const XML_NAMEINFO_TAG As String = "Name"

Const XML_FIRSTNAME_TAG As String = "FirstName"

Const XML_LASTNAME TAG As String = "LastName"

'Набор состояний, отслеживаемых по мере чтения данных

Private Enum ReadLocation

inAllMyData

inUserInfo

inUserID

inName

inFirstName

inLastName

End Enum

'--------------------------------------------------------------------

'Сохраняет пользовательское состояние

' [in] fileName: Имя файла, используемого для сохранения данных

' [in] userId: Идентификатор пользователя, который мы хотим сохранить

' [in] firstName: Имя пользователя, которое мы хотим сохранить

' [in] lastName: Фамилия пользователя, которую мы хотим сохранить

'--------------------------------------------------------------------

Public Shared Sub XML_SaveUserInfo(ByVal fileName As String, _

ByVal userId As Integer, ByVal firstName As String, _

ByVal lastName As String)

Dim xmlTextWriter As System.Xml.XmlTextWriter

xmlTextWriter = New System.Xml.XmlTextWriter(fileName, _

System.Text.Encoding.Default)

'Записать содержимое документа!

'<Root>

xmlTextWriter.WriteStartElement(XML_ROOT_TAG)

'<Root>

xmlTextWriter.WriteStartElement(XML_USERINFO_TAG)

'<Root><UserID>

'<Root><UserInfo>

xmlTextWriter.WriteStartElement(XML_NAMEINFO_TAG)

'<Root><UserInfo><Name>

xmlTextWriter.WriteStartElement(XML_FIRSTNAME_TAG)

'<Root><UserInfo><Name><FirstName>

xmlTextWriter.WriteString(firstName) 'Запись значения

xmlTextWriter.WriteEndElement() 'Закрыть дескриптор имени

'<Root><UserInfo><Name>

xmlTextWriter.WriteStartElement(XML_LASTNAME_TAG)

'<Root><UserInfo><Name><LastName>

xmlTextWriter.WriteString(lastName) 'Запись значения

xmlTextWriter.WriteEndElement() 'Закрыть дескриптор фамилии

'<Root><UserInfo><Name>

xmlTextWriter.WriteEndElement() 'Закрыть дескриптор ФИО

'<Root><UserInfo>

'<Root><UserInfo>

xmlTextWriter.WriteStartElement(XML_USERID_TAG)

'<Root><UserInfo><UserID>

'Запись значения

xmlTextWriter.WriteString(userId.ToString())

xmlTextWriter.WriteEndElement() 'Закрыть дескриптор UserID

'<Root><UserInfo>

xmlTextWriter.WriteEndElement()

'Закрыть дескриптор UserInfo

'<Root>

xmlTextWriter.WriteEndElement() 'Закрыть дескриптор документа

xmlTextWriter.Close()

End Sub

'--------------------------------------------------------------

'Загружает пользовательское состояние

' [in] fileName: Имя файла, используемого для сохранения данных

' [out] userId: Загруженный идентификатор пользователя

' [out] firstName: Загруженное имя пользователя

' [out] lastName: Загруженная фамилия пользователя

'--------------------------------------------------------------

Public Shared Sub XML_LoadUserInfo(ByVal fileName As String, _

ByRef userId As Integer, ByRef firstName As String, _

ByRef lastName As String)

Dim currentReadLocation As ReadLocation

'Начинаем с нулевых значении

userId = 0

firstName = ""

lastName = ""

Dim xmlReader As System.Xml.XmlTextReader = _

New System.Xml.XmlTextReader(fileName)

xmlReader.WhitespaceHandling = _

System.Xml.WhitespaceHandling.None

Dim readSuccess As Boolean

readSuccess = xmlReader.Read()

If (readSuccess = False) Then

Throw New System.Exception("Отсутствуют XML-данные для чтения!")

End If

'Убедиться в том, что мы распознали корневой дескриптор

If (xmlReader.Name <> XML_ROOT_TAG) Then

Throw New System.Exception( _

"Корневой дескриптор отличается от ожидаемого!")

End If

'Отметить текущее местоположение в документе

currentReadLocation = ReadLocation.inAllMyData

'------------------------------------------------------

'Цикл прохождения документа и чтение необходимых данных

'------------------------------------------------------

While (readSuccess)

Select Case (xmlReader.NodeType)

'Вызывается при входе в новый элемент

Case System.Xml.XmlNodeType.Element

Dim nodeName As String = xmlReader.Name

LoadHelper_NewElementEncountered(nodeName, _

currentReadLocation)

'--------------------------------------------------

'Здесь мы можем извлечь некоторый фактический текст

'и получить данные, которые пытаемся загрузить

'--------------------------------------------------

Case System.Xml.XmlNodeType.Text

Select Case currentReadLocation

Case ReadLocation.inFirstName

firstName = xmlReader.Value

Case ReadLocation.inLastName

lastName = xmlReader.Value

Case ReadLocation.inUserID

userId = CInt(xmlReader.Value)

End Select

'Конец оператора Case "System.Xml.XmlNodeType.Text"

'----------------------------------------------------

'Вызывается, когда встречается конец

'элемента

'

'Мы можем захотеть переключить состояние в зависимости

'от вида покидаемого узла, чтобы указать на то, что

'собираемся вернуться назад к его предку

'-----------------------------------------------------

Case System.Xml.XmlNodeType.EndElement

Dim continueParsing As Boolean

continueParsing = LoadHelper_EndElementEncountered( _

currentReadLocation)

If (continueParsing = False) Then

GoTo finished_reading_wanted_data

End If

Case Else

'He страшно, если имеются XML-узлы других типов, но

'в нашем примере работы с XML-документом мы должны

'оповестить об этом факте

MsgBox( _

"Встретился непредвиденный XML-тип " + xmlReader.Name)

End Select 'Конец оператора Case, используемого для определения текущего

'типа XML-элeмeнтa, oбpaбaтывaeмoгo анализатором

'Перейти к следующему узлу

readSuccess = xmlReader.Read()

End While

'Если мы оказались в этом месте программы, не покинув

'XML-дескриптора UserInfo, то с XML-данными, которые мы считываем,

'что-то не так

Throw New Exception("He найден элемент UserInfo в XML-документе!")

finished reading_wanted_data:

'Закрыть файл, поскольку работа с ним закончена!

xmlReader.Close()

End Sub

'--------------------------------------------------------

'Вспомогательный код, ответственный за принятие решения

'относительно того, в какое состояние необходимо перейти,

'когда встречается закрывающий дескриптор

'--------------------------------------------------------

Private Shared Function LoadHelper_EndElementEncountered( _

ByRef currentReadLocation As ReadLocation) As Boolean

Select Case (currentReadLocation)

'Если мы покидаем узел Name, то должны вернуться

'обратно в узел UserInfo

Case ReadLocation.inName

currentReadLocation = ReadLocation.inUserInfo

'Если мы покидаем узел FirstName, то должны вернуться

'обратно в узел Name

Case ReadLocation.inFirstName

currentReadLocation = ReadLocation.inName

'Если мы покидаем узел LastName, то должны вернуться

'обратно в узел Name

Case ReadLocation.inLastName

currentReadLocation = ReadLocation.inName

'Если мы покидаем узел UserID, то должны вернуться

'обратно в узел UserInfo

Case ReadLocation.inUserID

currentReadLocation = ReadLocation.inUserInfo

'Если мы покидаем узел UserInfo, то мы только что

'закончили чтение данных в узлах UserID, FirstName

'и LastName

'

'Можно выйти из цикла, поскольку у нас уже есть вся

'информация, которую мы хотели получить!

Case ReadLocation.inUserInfo

Return False 'Анализ должен быть прекращен

End Select

Return True

'Продолжить анализ

End Function

Private Shared Sub LoadHelper_NewElementEncountered( _

ByVal nodeName As String, _

ByRef currentReadLocation As ReadLocation)

'----------------------------------------------------

'Мы вошли в новый элемент!

'В какое состояние переход возможен, зависит от того,

'в каком состоянии мы находимся в данный момент

'----------------------------------------------------

Select Case (currentReadLocation)

'Если мы находимся в узле AllMyData, то переход возможен

'в узлы, которые указаны ниже

Case (ReadLocation.inAllMyData)

If (nodeName = XML_USERINFO_TAG) Then

currentReadLocation = ReadLocation.inUserInfo

End If

'Если мы находимся в узле UserInfo, то переход возможен

'в узлы, которые указаны ниже

Case (ReadLocation.inUserInfo)

If (nodeName = XML_USERID_TAG) Then

currentReadLocation = ReadLocation.inUserID

ElseIf (nodeName = XML_NAMEINFO_TAG) Then

currentReadLocation = ReadLocation.inName

End If

'Если мы находимся в узле Name, то переход возможен

'в узлы, которые указаны ниже

Case (ReadLocation.inName)

If (nodeName = XML_FIRSTNAME_TAG) Then

currentReadLocation = ReadLocation.inFirstName

ElseIf (nodeName = XML LASTNAME_TAG) Then

currentReadLocation = ReadLocation.inLastName

End If

End Select

End Sub

End Class

Примеры к главе 11 (производительность и графика)

Листинг 11.1. Заполнение данными и очистка от них элементов управления TreeView с использованием альтернативных стратегий

'----------------------------------------------------------------------------

'Примечание #1: В этом примере используется класс PerformanceSampling,

' определённый ранее в данной книге. Убедитесь в том, что

' вы включили этот класс в свой проект.

'Примечание #2: Этот код необходимо включить в класс Form, содержащий элемент

' управления TreeView и кнопки Button, к которым подключены

' приведенные ниже функции xxx_Click.

'----------------------------------------------------------------------------

'Количество элементов, которые необходимо поместить в элемент

'управления TreeView

Const NUMBER_ITEMS As Integer = 800

'-------------------------------------------------------------------------

'Код для кнопки "Fill: Baseline"

'Использование неоптимизированного подхода для заполнения данными элемента

'управления TreeView

'-------------------------------------------------------------------------

Private Sub UnOptimizedFill_Click(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles UnOptimizedFill.Click

'Очистить массив для создания одинаковых условий тестирования

If (TreeView1.Nodes.Count > 0) Then

TreeView1.BeginUpdate()

TreeView1.Nodes.Clear()

TreeView1.EndUpdate()

TreeView1.Update()

End If

'Для повышения корректности тестирования предварительно выполнить

'операцию сборки мусора. В реальных кодах этого делать не следует!

System.GC.Collect()

'Запустить таймер

PerformanceSampling.StartSample(0, "TreeViewPopulate")

'Заполнить данными элемент управления TreeView

Dim i As Integer

For i = 1 To NUMBER_ITEMS

TreeView1.Nodes.Add("TreeItem" + CStr(i))

Next

'Остановить таймер и отобразить результат

PerformanceSampling.StopSample(0)

MsgBox(PerformanceSampling.GetSampleDurationText(0))

End Sub

'-------------------------------------------------------------------------

'Код для кнопки "Clear: Baseline"

'Использование неоптимизированного подхода для заполнения данными элемента

'управления TreeView

'-------------------------------------------------------------------------

Private Sub UnOptimizedClear_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles UnOptimizedClear.Click

'Для повышения корректности тестирования предварительно выполнить

'операцию сборки мусора

System.GC.Collect()

'Запустить таймер

PerformanceSampling.StartSample(1, "TreeViewClear")

TreeView1.Nodes.Clear()

PerformanceSampling.StopSample(1)

MsgBox(PerformanceSampling.GetSampleDurationText(1))

End Sub

'--------------------------------------------------

'Код для кнопки "Fill: BeginUpdate"

'Подход, в котором используется метод BeginUpdate()

'--------------------------------------------------

Private Sub UseBeginEndUpdateForFill_Click(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles UseBeginEndUpdateForFill.Click

'Очистить массив для создания одинаковых условий тестирования

If (TreeView1.Nodes.Count > 0) Then

TreeView1.BeginUpdate()

TreeView1.Nodes.Clear()

TreeView1.EndUpdate()

TreeView1.Update()

End If

'Для повышения корректности тестирования предварительно выполнить

'операцию сборки мусора. В РЕАЛЬНЫХ КОДАХ ЭТОГО ДЕЛАТЬ НЕ СЛЕДУЕТ!

System.GC.Collect()

'Запустить таймер

PerformanceSampling.StartSample(2, _

"Populate - Use BeginUpdate")

'Заполнить данными элемент управления TreeView

TreeView1.BeginUpdate()

Dim i As Integer

For i = 1 To NUMBER_ITEMS

TreeView1.Nodes.Add("TreeItem" + i.ToString())

Next

TreeView1.EndUpdate()

'Остановить таймер и отобразить результат

PerformanceSampling.StopSample(2)

MsgBox(PerformanceSampling.GetSampleDurationText(2))

End Sub

'--------------------------------------------------

'Код для кнопки "Clear: BeginUpdate"

'Подход, в котором используется метод BeginUpdate()

'--------------------------------------------------

Private Sub UseBeginEndUpdateForClear_Click(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles UseBeginEndUpdateForClear.Click

'Для повышения корректности тестирования предварительно выполнить

'операцию сборки мусора. В РЕАЛЬНЫХ КОДАХ ЭТОГО ДЕЛАТЬ НЕ СЛЕДУЕТ!

System.GC.Collect()

'Запустить таймер

PerformanceSampling.StartSample(3, "Clear - Use BeginUpdate")

TreeView1.BeginUpdate()

TreeView1.Nodes.Clear()

TreeView1.EndUpdate()

'Остановить таймер и отобразить результат

PerformanceSampling.StopSample(3)

MsgBox(PerformanceSampling.GetSampleDurationText(3))

End Sub

'-------------------------------------

'Код для кнопки "Fill: Use Array"

'Подход, в котором используется массив

'-------------------------------------

Private Sub FillArrayBeforeAttachingToTree_Click(ByVal _

sender As System.Object, ByVal e As System.EventArgs) _

Handles FillArrayBeforeAttachingToTree.Click

'Очистить массив для создания одинаковых условий тестирования

If (TreeView1.Nodes.Count > 0) Then

TreeView1.BeginUpdate()

TreeView1.Nodes.Clear()

TreeView1.EndUpdate()

TreeView1.Update()

End If

'Для повышения корректности тестирования предварительно выполнить

'операцию сборки мусора. В РЕАЛЬНЫХ КОДАХ ЭТОГО ДЕЛАТЬ НЕ СЛЕДУЕТ!

System.GC.Collect()

'Запустить таймер

PerformanceSampling.StartSample(4, "Populate - Use Array")

'Распределить память для нашего массива узлов дерева

Dim newTreeNodes() As System.Windows.Forms.TreeNode

ReDim newTreeNodes(NUMBER_ITEMS - 1)

'Заполнить массив

Dim i As Integer

For i = 0 To NUMBER_ITEMS - 1

newTreeNodes(i) = _

New System.Windows.Forms.TreeNode("TreeItem" + _

i.ToString())

Next

'Связать массив с элементом управления TreeView

TreeView1.BeginUpdate()

TreeView1.Nodes.AddRange(newTreeNodes)

TreeView1.EndUpdate()

'Остановить таймер и отобразить результат

PerformanceSampling.StopSample(4)

MsgBox(PerformanceSampling.GetSampleDurationText(4))

End Sub

Листинг 11.2. Динамическое заполнение данными элемента управления TreeView

'Фиктивный текст для размещения в заполнителях дочерних узлов

Const dummy_node As String = "_dummynode"

'Метка, которую мы будем использовать для обозначения узла

Const node_needToBePopulated As String = "_populateMe"

'Текст, который мы будем использовать для наших узлов высшего уровня

Const nodeText_Neighborhoods As String = "Neighborhoods"

Const nodeText_Prices As String = "Prices"

Const nodeText_HouseType As String = "HouseTypes"

'--------------------------------------------------------------------

'Обработчик события щелчка для кнопки

'Настраивает наш элемент управления TreeView для отображения процесса

'последовательного заполнения дерева

'--------------------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

Dim tnNewNode As TreeNode

'Отключить обновление ПИ до тех пор, пока дерево не будет заполнено

TreeView1.BeginUpdate()

'Избавиться от устаревших данных

TreeView1.Nodes.Clear()

'--------------------

'Узел "Neighborhoods"

'--------------------

'Добавить узел "Neighborhoods" верхнего уровня.

tnNewNode = TreeView1.Nodes.Add("Neighborhoods")

'Установить для узла метку, указывающую на то, что узел

'будет заполняться динамически

tnNewNode.Tag = node_needToBePopulated

'Этот фиктивный дочерний узел существует лишь для того, чтобы

'узел имел, по крайней мере, один дочерний узел и поэтому

'был расширяемым.

tnNewNode.Nodes.Add(dummy_node)

'------------

'Узел "Price"

'------------

tnNewNode = TreeView1.Nodes.Add("Price")

'Установить для узла метку, указывающую на то, что узел

'будет заполняться динамически

tnNewNode.Tag = node_needToBePopulated

'Этот фиктивный дочерний узел существует лишь для того, чтобы

'узел имел, по крайней мере, один дочерний узел и поэтому

'был расширяемым

tnNewNode.Nodes.Add(dummy_node)

'----------------

'Узел "HouseType"

'----------------

tnNewNode = TreeView1.Nodes.Add("HouseType")

'Установить для узла метку, указывающую на то, что узел

'будет заполняться динамически

tnNewNode.Tag = node_needToBePopulated

'Этот фиктивный дочерний узел существует лишь для того, чтобы

'узел имел, по крайней мере, один дочерний узел и поэтому

'был расширяемым.

tnNewNode.Nodes.Add(dummy node)

'Восстанавливаем обновление ПИ

TreeView1.EndUpdate()

End Sub

''-----------------------------------------------------------------------------

''Обработчик событий BeforeExpand для нашего элемента управления TreeView

''ПРИМЕЧАНИЕ: В отличие от C#, данный обработчик

''      НЕ требует от вас связываться дорабатывать код

''      "InitializeComponent()" (не делайте этого!)

''      Вы можете просто выбрать событие обычным путем

''      выпадающего списка событий в редакторах VB

''

''Вызывается при запросе пользователем расширения узла, у которого имеется,

''по крайней мере, один дочерний узел. Этот вызов осуществляется до отображения

''дочерних узлов данного узла и дает нам возможность динамически заполнить

''данными элемент управления TreeView.

''-----------------------------------------------------------------------------

Private Sub TreeView1_BeforeExpand(ByVal sender As Object, _

ByVal e As System.Windows.Forms.TreeViewCancelEventArgs) _

Handles TreeView1.BeforeExpand

'Получить узел, который будет расширяться

Dim tnExpanding As System.Windows.Forms.TreeNode

tnExpanding = e.Node

'Если узел не отмечен как "нуждающийся в заполнении данными",

'то он устраивает нас в том виде, "как он есть".

If Not (tnExpanding.Tag Is node needToBePopulated) Then

Return 'Разрешить беспрепятственное продолжение выполнения

End If

'Требуется динамическое заполнение дерева данными.

'Мы знаем, что узел должен быть заполнен данными; определить,

'что это за узел

If (tnExpanding.Text = nodeText_Neighborhoods) Then

PopulateTreeViewNeighborhoods(tnExpanding)

Return 'done adding items!

Else

'Проверить другие возможности для узлов дерева, которые мы должны

'добавить.

MsgBox("HE СДЕЛАНО: Добавьте код для динамического заполнения этого узла")

'Снять отметку с этого узла, чтобы мы не могли вновь выполнить

'этот код

tnExpanding.Tag = ""

End If

End Sub

'------------------------------------------------------------------

'Эта функция вызывается для динамического добавления дочерних узлов

'в узел "Neighborhood"

'------------------------------------------------------------------

Sub PopulateTreeViewNeighborhoods(ByVal tnAddTo As TreeNode)

Dim tvControl As TreeView

tvControl = tnAddTo.TreeView

tvControl.BeginUpdate()

'Очистить имеющийся фиктивный узел

tnAddTo.Nodes.Clear()

'Объявить четыре узла, которые мы хотим сделать дочерними узлами

'того узла, который был передан.

Dim newNeighborhoodNodes() As TreeNode

ReDim newNeighborhoodNodes(3)

newNeighborhoodNodes(0) = New TreeNode("Capitol Hill")

newNeighborhoodNodes(1) = New TreeNode("Chelsea")

newNeighborhoodNodes(2) = New TreeNode("Downtown")

newNeighborhoodNodes(3) = New TreeNode("South Bay")

'Добавить дочерние узлы в элемент управления TreeView

tnAddTo.Nodes.AddRange(newNeighborhoodNodes)

tvControl.EndUpdate()

End Sub

Листинг 11.3. Запуск обработчика событий при изменении содержимого элемента TextBox программным путем

Private m_eventTriggerCount As Integer

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As  System.EventArgs) Handles Buttonl.Click

'Запускает событие TextChanged так же,

'как если бы текст был введен пользователем

TextBox1.Text = "Привет, мир"

End Sub

Private Sub TextBox1_TextChanged(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles TextBox1.TextChanged

m_eventTriggerCount = m_eventTriggerCount + 1

'Обновить надпись для отображения количества событий

Label1.Text = "Событий: #" + CStr(m_eventTriggerCount)

'Внести каждое событие в список

ListBox1.Items.Add(m_eventTriggerCount.ToString() + TextBox1.Text)

End Sub

Листинг 11.4. Использование модели состояний для обновления интерфейса и контроль запуска событий с целью более глубокого изучения процесса обработки событий и управления им

'-----------------------------------------

'Для активизации контроля запуска событий:

' #Const EVENTINSTRUMENTATION = 1

'Для отмены контроля запуска событий:

' #Const EVENTINSTRUMENTATION = 0

'-----------------------------------------

#Const EVENTINSTRUMENTATION = 1

'-----------------------------------------------------------------------

'Флаг, указывающий обработчикам событий, должен ли из них осуществляться

'выход без выполнения каких-либо действий

'-----------------------------------------------------------------------

Private m_userInterfaceUpdateOccuring As Boolean

'Счетчики событий

Private m_radioButton1ChangeEventCount As Integer

Private m_textBox1ChangeEventCount As Integer

'-------------------------------------------------------------------------

'Код, который следует включать лишь в том случае, если приложение

'выполняется в режиме контроля запуска событий. Этот код характеризуется

'относительно высокими накладными расходами, и его следует компилировать и

'выполнять только тогда, когда выполняется диагностика.

'-------------------------------------------------------------------------

#If EVENTINSTRUMENTATION <> 0 Then

Private m_instrumentedEventLog As System.Collections.ArrayList

'----------------------------------------------------------------------

'Заносит записи о возникновении событий в массив, который мы

'можем просмотреть

'Примечание: Не делается никаких попыток ограничить размерность массива

'  регистрационных записей, поэтому, чем дольше выполняется приложение,

'  тем больше становится размер массива

'----------------------------------------------------------------------

Private Sub instrumented_logEventOccurrence(ByVal eventData _

As String)

'Создать журнал событий, если он еще не был создан

If (m_instrumentedEventLog Is Nothing) Then

m_instrumentedEventLog = _

New System.Collections.ArrayList

End If

'Зарегистрировать событие

m_instrumentedEventLog.Add(eventData)

End Sub

'----------------------------------------------------------

'Отобразить список возникших событий

'Примечание: Этот вариант реализации довольно груб.

' Целесообразнее отображать список событий

' в отдельном диалоговом окне, которое специально выводится

' для этого на экран.

'----------------------------------------------------------

Private Sub instrumentation_ShowEventLog() Dim listItems As _

System.Windows.Forms.ListBox.ObjectCollection

listItems = listBoxEventLog.Items

'Очистить список элементов

listItems.Clear()

'При отсутствии событий - выход

If (m instrumentedEventLog Is Nothing) Then

listItems.Add("0 событий")

Return

End If

'Отобразить поверх списка общее количество

'подсчитанных нами событий

listItems.Add(m_instrumentedEventLog.Count.ToString() + _

" событий")

'Перечислить элементы списка в обратном порядке, чтобы

'первыми отображались самые последние из них

Dim logItem As String

Dim listIdx As Integer

For listIdx = _

m_instrumentedEventLog.Count - 1 To 0 Step -1

logItem = CStr(m_instrumentedEventLog(listIdx))

listItems.Add(logItem)

Next

End Sub

#End If

'------------------------------------------------------

'Событие изменения состояния переключателя RadioButton1

'------------------------------------------------------

Private Sub RadioButton1_CheckedChanged(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles RadioButton1.CheckedChanged

'Если обновление данных в пользовательском интерфейсе осуществляется

'приложением, то мы не хотим обрабатывать его так же, как если бы

'это событие было запущено пользователем. Если это именно так,

'то осуществить выход из функции без выполнения каких-либо действий.

If (m userInterfaceUpdateOccuring = True) Then

Return

End If

'Подсчитать, сколько раз выполнена обработка данного события

m_radioButtonlChangeEventCount = _

m_radioButtonlChangeEventCount + 1

#If (EVENTINSTRUMENTATION <> 0) Then

'Зарегистрировать наступление события

instrumented_logEventOccurrence("radioButton1.Change:" + _

m_radioButton1ChangeEventCount.ToString() + ":" + _

RadioButton1.Checked.ToString()) 'value

#End If

End Sub

'-------------------------------------------------------------

'Событие щелчка на кнопке Button1

'Имитирует обновление пользовательского интерфейса программным

'кодом, что может приводить к запуску обработчика события

'-------------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Указать на то, что мы не хотим, чтобы обработчики сразу же

'обрабатывали события, поскольку мы обновляем

'пользовательский интерфейс.

'm_userInterfaceUpdateOccuring = true;

RadioButton1.Checked = True

TextBox1.Text = "Hello World"

'Обновление пользовательского интерфейса закончено

m_userInterfaceUpdateOccuring = False

End Sub

'------------------------------------------------------------------

'Обработчик события изменения состояния элемента управления TextBox

'------------------------------------------------------------------

Private Sub TextBox1_TextChanged(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles TextBox1.TextChanged

'Если обновление данных в пользовательском интерфейсе осуществляется

'приложением, то мы не хотим обрабатывать его так же, как если бы

'это событие было запущено пользователем. Если это именно так,

'то осуществить выход из функции без выполнения каких-либо действий.

If (m_userInterfaceUpdateOccuring = True) Then

Return

End If

'Подсчитать, сколько раз выполнена обработка данного события

m_textBox1ChangeEventCount = m_textBox1ChangeEventCount + 1

#If EVENTINSTRUMENTATION <> 0 Then

'Занести событие в журнал

instrumented_logEventOccurrence("textBox1.Change:" + _

m_textBoxlChangeEventCount.ToString() + ":" + _

TextBox1.Text.ToString()) 'Value

#End If

End Sub

Private Sub buttonShowEventLog_Click(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles buttonShowEventLog.Click

#If EVENTINSTRUMENTATION <> 0 Then

instrumentation_ShowEventLog()

#End If

End Sub

Листинг 11.5. Вызов метода Update() элемента управления для отображения пояснительного текста, информирующего о ходе выполнения задачи

'--------------------------------------------------------------------

'Этот код принадлежит форме, содержащей по одному элементу управления

'Button (button1) и Label (label1)

'--------------------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.WaitCursor

Dim testString As String

Dim loop3 As Integer

For loop3 = 1 To 100 Step 10

Label1.Text = loop3.ToString() + "% Done..."

'!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

'Чтобы отобразить информацию о процессе обновления,!

'удалите символы комментария в строке ниже         !

'!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

'Label1.Update()

testString = ""

Dim loop2 As Integer

For loop2 = 1 To 1000

testString = testString + "тест"

Next

Next

Label1.Text = "Готово!"

'Удалить курсор ожидания

System.Windows.Forms.Cursor.Current = _

System.Windows Forms.Cursors.Default

End Sub

Листинг 11.6. Создание изображения на внеэкранной растровой поверхности и передача его в элемент управления PictureBox

'--------------------------------------------------------------------

'Создать рисунок на растровой поверхности. Переслать его в PictureBox

'--------------------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Создать новую битовую карту

Dim myBitmap As System.Drawing.Bitmap

myBitmap = New System.Drawing.Bitmap(PictureBox1.Width, _

PictureBox1.Height)

'--------------------------------------------------------------------------

'Создать объект Graphics, чтобы иметь возможность рисовать на битовой карте

'--------------------------------------------------------------------------

Dim myGfx As System.Drawing.Graphics

myGfx = System.Drawing.Graphics.FromImage(myBitmap)

'Закрасить нашу битовую карту желтым цветом

myGfx.Clear(System.Drawing.Color.Yellow)

'Создать перо

Dim myPen As System.Drawing.Pen

rayPen = New System.Drawing.Pen(System.Drawing.Color.Blue)

'-----------------

'Нарисовать эллипс

'-----------------

myGfx.DrawEllipse(myPen, 0, 0, myBitmap.Width - 1, _

myBitmap.Height - 1)

'Создать сплошную кисть

Dim myBrush As System.Drawing.Brush

'-----------------------

'Нарисовать текст кистью

'-----------------------

myBrush = New System.Drawing.SolidBrush( _

System.Drawing.Color.Black)

'Примечание: мы используем объект Font из формы

myGfx.DrawString("Привет!", Me.Font, myBrush, 2, 10)

'------------------------------

'Важно! Очистить все после себя

'------------------------------

myGfx.Dispose()

myPen.Dispose()

myBrush.Dispose()

'-------------------------------------------------------------------

'Указать объекту pictureBox, на необходимость отображения растрового

'изображения, которое мы только что создали и нарисовали.

'-------------------------------------------------------------------

PictureBox1.Image = myBitmap

End Sub

Листинг 11.7. Создание объекта Graphics для формы

'----------------------------------------------------------

'Создает объект Graphics для формы и осуществляет рисование

'----------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Создать объект Graphics для формы

Dim myGfx As System.Drawing.Graphics

myGfx = Me.CreateGraphics()

'Создать кисть

Dim myBrush As System.Drawing.Brush

myBrush = New System.Drawing.SolidBrush( _

System.Drawing.Color.DarkGreen)

'Заполнить прямоугольник

myGfx.FillRectangle(myBrush, 4, 2, 60, 20)

'-------------------------

'Важно: Выполнить очистку!

'-------------------------

myBrush.Dispose()

myGfx.Dispose()

End Sub

Листинг 11.8. Подключение к функции Paint формы

'Кисти, которые мы хотим кэшировать, чтобы избавить себя от необходимости

'все время создавать их и уничтожать

Private m_brushBlue As System.Drawing.Brush

Private m_brushYellow As System.Drawing.Brush

'Ради интереса подсчитаем, сколько раз осуществлялся вызов

Private m_paintCount As Integer

'-----------------------------------------------------------------------------

'Мы перекрываем обработчики событий Paint наших базовых классов. Это означает,

'что каждый раз, когда форма вызывается для перерисовки самой себя, будет

'вызываться эта функция.

'-----------------------------------------------------------------------------

Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs)

'ВАЖНО: Вызвать базовый класс и дать ему возможность

'выполнить всю необходимую работу по рисованию

MyBase.OnPaint(e)

'Увеличить на 1 значение счетчика вызовов

m_paintCount = m_paintCount + 1

'--------------------------------------------------------------------------

'Важно:

'Вместо того чтобы создавать объект Graphics, мы получаем его

'на время данного вызова. Это означает, что освобождать память путем вызова

'метода .Dispose() объекта - не наша забота

'--------------------------------------------------------------------------

Dim myGfx As System.Drawing.Graphics

myGfx = e.Graphics

'-------------------------------------------------------------------

'Поскольку эту операцию рисования необходимо выполнить быстро,

'кэшируем кисти, чтобы избавить себя от необходимости создавать их и

'уничтожать при каждом вызове

'-------------------------------------------------------------------

If (m_brushBlue Is Nothing) Then

m_brushBlue = New System.Drawing.SolidBrush( _

System.Drawing.Color.Blue)

End If

If (m_brushYellow Is Nothing) Then

m_brushYellow = New System.Drawing.SolidBrush( _

System.Drawing.Color.Yellow)

End If

'-------------------

'Выполнить рисование

'-------------------

myGfx.FillRectangle(m_brushBlue, 2, 2, 100, 100)

myGfx.DrawString("PaintCount: " + CStr(m_paintCount), _

Me.Font, m_brushYellow, 3, 3)

'Выход: Объекты, для которых мы должны были бы вызывать метод

'.Dispose(), отсутствуют.

End Sub

Листинг 11.9. Простой пользовательский элемент управления, который изменяет цвета и запускает событие, определяемое пользователем

'Простейший пользовательский элемент управления

Public Class myButton

Inherits System.Windows.Forms.Control

'--------------------------------------

'Объекты, необходимые нам для рисования

'--------------------------------------

Private m_RectangleBrush As System.Drawing.Brush

Private m_TextBrush As System.Drawing.Brush

Private m_RectangleColor As System.Drawing.Color

'------------------------------------------------------------------------

'Событие, которое мы хотим предоставить на обработку. Это - общедоступный

'делегат.

'------------------------------------------------------------------------

Public Event EventButtonTurningBlue(ByVal sender As Object, _

ByVal e As System.EventArgs)

'Конструктор

Public Sub New()

MyBase.New()

'ПРИМЕЧАНИЕ: Мы должны написать функцию "Dispose()" и

'деструктор, который освобождает память от этих объектов

'Создать необходимые кисти

m_RectangleColor = System.Drawing.Color.Black

m_RectangleBrush = New System.Drawing.SolidBrush( _

m_RectangleColor)

m_TextBrush = New System.Drawing.SolidBrush( _

System.Drawing.Color.White)

End Sub

'-----------------------------------------------

'Внутренним откликом на щелчок является

'повторение трех различных цветов кнопки в цикле

'-----------------------------------------------

Protected Overrides Sub OnClick(ByVal e As System.EventArgs)

'--------------------------------------------------------

'Важно: Вызвать базовую реализацию. Это

'обеспечит возможность вызова любого обработчика событий,

'подключенного к данному элементу управления

'--------------------------------------------------------

MyBase.OnClick (e)

'------------------------------------------------------

'Выбрать цвет новой кисти, исходя из цвета старой кисти

'------------------------------------------------------

If (m_RectangleColor.Equals(System.Drawing.Color.Black)) Then

m_RectangleColor = System.Drawing.Color.Blue

'!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

'Запустить событие!

'!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

'Возбудить событие без передачи аргумента

RaiseEvent EventButtonTurningBlue(Me, Nothing)

ElseIf (m_RectangleColor.Equals(System.Drawing.Color.Blue)) Then

m_RectangleColor = System.Drawing.Color.Red

Else

m_RectangleColor = System.Drawing.Color.Black

End If

'-----------------------

'Освободить старую кисть

'-----------------------

m_RectangleBrush.Dispose()

'----------------------------------------------------------------

'Создать новую кисть, которую мы собираемся использовать для фона

'----------------------------------------------------------------

m_RectangleBrush = _

New System.Drawing.SolidBrush(m_RectangleColor)

'------------------------------------------------------------

'Сообщить операционной системе, что наш элемент управления

'должен быть перерисован, как только представится возможность

'------------------------------------------------------------

Me.Invalidate()

End Sub

'----------------------------------------------------------------

'Ради интереса подсчитаем, сколько раз осуществлялась перерисовка

'----------------------------------------------------------------

Private m_paintCount As Integer

Protected Overrides Sub OnPaint( _

ByVal e As System.Windows.Forms.PaintEventArgs)

'--------------------------------------------

'ВАЖНО: Вызвать базовый класс и позволить ему

'выполнить работу по рисованию

'--------------------------------------------

MyBase.OnPaint(e)

'Увеличить на единицу значение счетчика вызовов

m_paintCount = m_paintCount + 1

'--------------------------------------------------------------------------

'Важно:

'Вместо того чтобы создавать объект Graphics, мы получаем его

'на время данного вызова. Это означает, что освобождать память путем вызова

'метода .Dispose() объекта - не наша забота

'--------------------------------------------------------------------------

Dim myGfx As System.Drawing.Graphics

myGfx = e.Graphics

'Нарисовать прямоугольник

myGfx.FillRectangle(m_RectangleBrush, 0, 0, _

Me.Width, Me.Height)

'Нарисовать текст

myGfx.DrawString("Button! Paint: " + m_paintCount.ToString(), _

Me.Parent.Font, m_TextBrush, 0, 0)

End Sub

End Class

Листинг 11.10. Код, который должен быть помещен в форму для создания экземпляра пользовательского элемента управления

'Наша новая кнопка

Private m_newControl As myButton

'--------------------------------------------------------------

'Этот код будет подключен в качестве нашего обработчика событий

'--------------------------------------------------------------

Private Sub CallWhenButtonTurningBlue(ByVal sender As Object, _

ByVal e As System.EventArgs)

MsgBox("Кнопка становится синей!")

End Sub

'----------------------------------------------

'Эта функция подключается для обработки событий

'щелчка на кнопке Button1

'----------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'----------------------------------------------

'Для простоты мы допускаем существование только

'одного экземпляра элемента управления,

'----------------------------------------------

If Not (m_newControl Is Nothing) Then Return

'Создать экземпляр нашей кнопки

m_newControl = New myButton

'Указать ему его местоположение внутри родительского объекта

m_newControl.Bounds = New Rectangle(10, 10, 150, 40)

'-------------------------------

'Присоединить обработчик событий

'-------------------------------

AddHandler m_newControl.EventButtonTurningBlue, _

AddressOf CallWhenButtonTurningBlue

'Добавить его в список элементов управления данной формы.

'Это сделает его видимым

Me.Controls.Add(m_newControl)

End Sub

Листинг 11.11. Три полезных способа кэширования графических ресурсов

Imports System

Imports System.Drawing

Friend Class GraphicsGlobals

'=======================================================================

'Подход 1: Создать ресурс по требованию

'         и кэшировать его для последующего использования.

'

'Внешний код получает доступ к общедоступным свойствам для их просмотра,

'но сами переменные остаются внутренними переменными класса

'=======================================================================

Private Shared s_bluePen As Pen

Public Shared ReadOnly Property globalBluePen() As Pen

Get

'Если перо еще не было создано

If (s_bluePen Is Nothing) Then

s_bluePen = New System.Drawing.Pen( _

System.Drawing.Color.Blue)

End If

Return s_bluePen

End Get

End Property

'========================================================

'Подход 2:

'Загрузить глобально и кэшировать все

'используемые объекты Pen, ImageAttribute, Font и Brush

'

'Внешний код получает доступ ко всем общедоступным членам,

'так что никакие функции доступа не нужны.

'=========================================================

Public Shared g_blackPen As Pen

Public Shared g_whitePen As Pen

Public Shared g_ImageAttribute As Imaging.ImageAttributes

Private Shared s_alreadyInitialized As Boolean

Public Shared g_boldFont As Font

Public Shared g_smallTextFont As Font

Public Shared g_greenBrush As Brush

Public Shared g_yellowBrush As Brush

Public Shared g_redBrush As Brush

Public Shared g_blackBrush As Brush

'==============================================================

'Эта функция должна быть вызвана до попыток доступа к любому из

'вышеперечисленных глобальных объектов

'==============================================================

Public Shared Sub InitializeGlobals()

If (s_alreadyInitialized = True) Then Return

g_blackPen = New Systera.Drawing.Pen(Color.Black)

g_whitePen = New System.Drawing.Pen(Color.White)

g_ImageAttribute = New _

System.Drawing.Imaging.ImageAttributes

g_ImageAttribute.SetColorKey(Color.White, Color.White)

g_boldFont = New Font(FontFamily.GenericSerif, _

10, FontStyle.Bold)

g_smallTextFont = New Font(FontFamily.GenericSansSerif, _

8, FontStyle.Regular)

g_blackBrush = New SolidBrush(System.Drawing.Color.Black)

g_greenBrush = New SolidBrush(System.Drawing.Color.LightGreen)

g_yellowBrush = New SolidBrush(System.Drawing.Color.Yellow)

g_redBrush = New SolidBrush(System.Drawing.Color.Red)

s_alreadyInitialized = True

End Sub

'====================================================

'Подход 3: Возвратить массив связанных ресурсов.

' Кэшировать ресурсы локально, чтобы при многократных

' запросах не загружались (напрасно) их дубликаты

'====================================================

Private Shared m_CaveMan_Bitmap1 As Bitmap

Private Shared m_CaveMan_Bitmap2 As Bitmap

Private Shared m_CaveMan_Bitmap3 As Bitmap

Private Shared m_CaveMan_Bitmap4 As Bitmap

Private Shared m_colCaveManBitmaps As _

System.Collections.ArrayList

'--------------------------------------------------

'Создать и загрузить массив изображений для спрайта

'--------------------------------------------------

Public Shared Function g_CaveManPictureCollection() As _

System.Collections.ArrayList

'Изображения загружаются лишь в том случае, если мы их еще не загрузили

If (m_CaveManBitmap1 Is Nothing) Then

'-----------------------------------------------------------------

'Загрузить изображения. Эти изображения хранятся в виде

'встроенных ресурсов в нашем двоичном приложении

'

'Загрузка изображений из внешних файлов осуществляется аналогичным

'образом, но выполнить ее проще (нам достаточно лишь указать

'имя файла в конструкторе растровых изображений).

'-----------------------------------------------------------------

'Получить ссылку на нашу двоичную сборку

dim thisAssembly as System.Reflection.Assembly = _

System.Reflection.Assembly.GetExecutingAssembly()

'Получить имя сборки

Dim thisAssemblyName As System.Reflection.AssemblyName = _

thisAssembly.GetName()

Dim assemblyName As String = thisAssemblyName.Name

'Загрузить изображения в виде двоичных потоков из нашей сборки

m_CaveMan_Bitmap1 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream( _

assemblyName + ".Hank_RightRun1.bmp"))

m_CaveMan_Bitmap2 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream( _

assemblyName + ".Hank_RightRun2.bmp"))

m_CaveMan_Bitmap3 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream( _

assemblyName + ".Hank_LeftRunl.bmp"))

m_CaveMan_Bitmap4 = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream( _

assemblyName + ".Hank_LeftRun2.bmp"))

'Добавить их в коллекцию

m_colCaveManBitmaps = New System.Collections.ArrayList

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap1)

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap2)

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap3)

m_colCaveManBitmaps.Add(m_CaveMan_Bitmap4)

End If

'Возвратить коллекцию

Return m_colCaveManBitmaps

End Function

End Class

Примеры к главе 13 (проектирование пользовательского интерфейса)

Листинг 13.1. Использование конечного автомата для экспериментов с двумя различными вариантами компоновки пользовательского интерфейса

#Const PLAYFIELD_ON_BOTTOM = 0 'Отобразить ПОЛЕ ИГРЫ под ПИ

'#Const PLAYFIELD_ON_BOTTOM = 1 'Отобразить ПОЛЕ ИГРЫ над ПИ

'-------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Вызывается при загрузке формы

'-------------------------------------------------

Private Sub Form1_Load(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles MyBase.Load

'Задать совместно используемые свойства нашего визуального интерфейса

SetStartControlPositionAndState()

'Задать динамические свойства, исходя из того, в какое состояние

'игры мы входим

StateChangeForGameUI(GameUIState.startScreen)

End Sub

'---------------------------------------------------------------------------

'Конечный автомат, который управляет отображением кнопок, скрываемых вручную

'---------------------------------------------------------------------------

Private Enum GameUIState

startScreen = 1

waitForNextQuestion = 2

waitForUserToStateKnowledge = 4

waitForUserToAnswerMultipleChoice = 8

End Enum

'Текущее состояние игры

Private m_GameUIState As GameUIState

'==========================================================================

'Конечный автомат, используемый для управления пользовательским интерфейсом

'==========================================================================

Private Sub StateChangeForGameUI(ByVal newGameUIState As _

GameUIState)

m_GameUIState = newGameUIState

Select Case (newGameUIState)

Case GameUIState.startScreen

buttonAskQuestion.Visible = True

buttonAskQuestion.Text = "Start"

'Скрыть текстовое окно

textBoxAskQuestion.Visible = False

SetAnswerButtonVisibility(False)

SetDifficultyButtonVisibility(False)

Case GameUIState.waitForNextQuestion

setQuestionText("List answer details here... " + vbCrLf + _

"Lots of space to write..." + vbCrLf + _

"Waiting for user to select next question...")

textBoxAskQuestion.Visible = True

buttonAskQuestion.Text = "Next"

buttonAskQuestion.Visible = True

'Убедиться в том, что кнопка отображается на переднем плане

buttonAskQuestion.BringToFront()

SetAnswerButtonVisibility(False)

SetDifficultyButtonVisibility(False)

#If PLAYFIELD_ON_BOTTOM <> 0 Then 'ПОЛЕ ИГРЫ располагается под ПИ

textBoxAskQuestion.Height = pictureBoxGameBoard.Top - 2

#Else 'ПОЛЕ ИГРЫ располагается над пользовательскими элементами управления

textBoxAskQuestion.Top = pictureBoxGameBoard.Top + _

pictureBoxGameBoard.Height + 2

textBoxAskQuestion.Height = Me.Height - _

textBoxAskQuestion.Top

#End If

Case GameUIState.waitForUserToStateKnowledge

SetTextForVocabularyQuestion()

textBoxAskQuestion.Visible = True

buttonAskQuestion.Visible = False

SetAnswerButtonVisibility(False)

SetDifficultyButtonVisibility(True)

#If PLAYFIELD_ON_BOTTOM <> 0 Then 'ПОЛЕ ИГРЫ располагается под ПИ

textBoxAskQuestion.Height = _

buttonShowAnswers_AdvancedVersion.Top - 2

#Else 'ПОЛЕ ИГРЫ располагается над пользовательскими элементами управления

textBoxAskQuestion.Top = _

buttonShowAnswers_AdvancedVersion.Top + _

buttonShowAnswers_AdvancedVersion.Height + 2

textBoxAskQuestion.Height = Me.Height - _

textBoxAskQuestion.Top

#End If

Case GameUIState.waitForUserToAnswerMultipleChoice

buttonAskQuestion.Visible = False

SetDifficultyButtonVisibility(False)

'Сделать кнопки доступными, чтобы пользователь мог щелкать на них

SetAnswerButtonEnabled(True)

SetAnswerButtonVisibility(True)

#If PLAYFIELD_ON_BOTTOM <> 0 Then

'ПОЛЕ ИГРЫ располагается под ПИ

textBoxAskQuestion.Height = buttonAnswer0.Top - 2

#Else 'ПОЛЕ ИГРЫ располагается над пользовательскими элементами управления

'Разместить текстовое окно таким образом, чтобы экран использовался

'эффективно

textBoxAskQuestion.Top = buttonAnswer5.Top + _

buttonAnswer5.Height + 2

textBoxAskQuestion.Height = Me.Height - _

textBoxAskQuestion.Top

#End If

End Select

End Sub

'========================================================================

'Задать статическую компоновку нашего пользовательского интерфейса.

'Сюда входят все элементы, позиции которых остаются фиксированными.

'Изменения в остальные свойства внесет конечный автомат пользовательского

'интерфейса

'========================================================================

Private Sub SetStartControlPositionAndState()

pictureBoxGameBoard.Width = 240

pictureBoxGameBoard.Height = 176

'Установить размеры кнопок множественного выбора вариантов ответов

Const answerButtons_dx As Integer = 117

Const answerButtons_dy As Integer = 18

buttonAnswer0.Width = answerButtons_dx

buttonAnswer0.Height = answerButtons_dy

buttonAnswer1.Size = buttonAnswer0.Size

buttonAnswer2.Size = buttonAnswer0.Size

buttonAnswer3.Size = buttonAnswer0.Size

buttonAnswer4.Size = buttonAnswer0.Size

buttonAnswer5.Size = buttonAnswer0.Size

buttonShowAnswers_AdvancedVersion.Width = answerButtons_dx

buttonShowAnswers_AdvancedVersion.Height = 24

buttonShowAnswers_SimpleVersion.Size = _

buttonShowAnswers_AdvancedVersion.Size

'Расстояние (в пикселях) между соседними кнопками

Const dx_betweenButtons As Integer = 3

Const dy betweenButtons As Integer = 2

Const answerbuttons_beginX As Integer = 3

'Создать задний план для нашего изображения, чтобы мы видели

'его в процессе тестирования

Dim gameBoard As System.Drawing.Bitmap

gameBoard = New System.Drawing.Bitmap( _

pictureBoxGameBoard.Width, pictureBoxGameBoard.Height)

Dim gameboard_gfx As System.Drawing.Graphics

gameboard_gfx = System.Drawing.Graphics.FromImage(gameBoard)

gameboard_gfx.Clear(System.Drawing.Color.Yellow)

Dim myPen As System.Drawing.Pen = New System.Drawing.Pen( _

System.Drawing.Color.Blue)

gameboard_gfx.DrawRectangle(myPen, 2, 2, _

gameBoard.Width - 4, gameBoard.Height - 6)

myPen.Dispose()

gameboard_gfx.Dispose()

pictureBoxGameBoard.Image = gameBoard

'Разместить текстовое окно, в котором содержатся задаваемые вопросы,

'а также подробные ответы для пользователей

textBoxAskQuestion.Left = 0

textBoxAskQuestion.Width = 240

buttonAskQuestion.Width = 64

buttonAskQuestion.Height = 20

#If PLAYFIELD_ON_BOTTOM <> 0 Then 'ПОЛЕ ИГРЫ располагается под ПИ

Const answerbuttons_beginY As Integer = 42

Const showanswers_beginY As Integer = 77

'------------------------------------------------------------

'Задать кнопки выбора вариантов "Easy" или "Hard" режима игры

'------------------------------------------------------------

buttonShowAnswers_AdvancedVersion.Top = showanswers_beginY

buttonShowAnswers_SimpleVersion.Top = showanswers_beginY

'------------------------------

'Задать набор вариантов ответов

'------------------------------

'Задать элемент управления, по которому будут выравниваться

'все остальные элементы управления

buttonAnswer0.Top = answerbuttons_beginY

'Поместить PictureBox под элементами управления

pictureBoxGameBoard.Top = _

(answerButtons dy + dy betweenButtons) * 3 + _

answerbuttons_beginY

buttonAskQuestion.Top = 0

buttonAskQuestion.Left = 174

textBoxAskQuestion.Top = 0

#Else 'ПОЛЕ ИГРЫ располагается над пользовательскими элементами управления

Const answerbuttons_beginY As Integer = 174

'------------------------------------------------------------

'Задать кнопки выбора вариантов "Easy" или "Hard" режима игры

'------------------------------------------------------------

buttonShowAnswers_AdvancedVersion.Top = answerbuttons_beginY

buttonShowAnswers_SimpleVersion.Top = answerbuttons_beginY

'-----------------------------

'Задать набор вариантов ответа

'-----------------------------

'Задать элемент управления, по которому будут выравниваться

'все остальные элементы управления

buttonAnswer0.Top = answerbuttons_beginY

pictureBoxGameBoard.Top = 0

buttonAskQuestion.Top = answerbuttons_beginY

buttonAskQuestion.Left = 174

#End If

buttonShowAnswers AdvancedVersion.Left = answerbuttons_beginX

buttonShowAnswers_SimpleVersion.Left = _

buttonShowAnswers_AdvancedVersion.Left + _

answerButtons dx + dx_betweenButtons

pictureBoxGameBoard.Left = 0

pictureBoxGameBoard.Width = 240

pictureBoxGameBoard.Height = 172

buttonAnswer0.Left = answerbuttons_beginX

buttonAnswer1.Left = buttonAnswer0.Left + answerButtons_dx + _

dx_betweenButtons

buttonAnswer1.Top = buttonAnswer0.Top

'Следующий ряд

buttonAnswer2.Left = buttonAnswer0.Left

buttonAnswer2.Top = buttonAnswer0.Top + answerButtons_dy + _

dy_betweenButtons

buttonAnswer3.Left = buttonAnswer2.Left + answerButtons_dx + _

dx_betweenButtons

buttonAnswer3.Top = buttonAnswer2.Top

'Следующий ряд

buttonAnswer4.Left = buttonAnswer2.Left

buttonAnswer4.Top = buttonAnswer2.Top + answerButtons_dy + _

dy_betweenButtons

buttonAnswer5.Left = buttonAnswer4.Left + answerButtons_dx + _

dx_betweenButtons

buttonAnswer5.Top = buttonAnswer4.Top

End Sub

'-----------------------------------------------------------------------

'Вспомогательная функция, которая позволяет задавать состояние видимости

'кнопок, отображающих ответы из словаря

'-----------------------------------------------------------------------

Private Sub SetAnswerButtonVisibility(ByVal visibleState _

As Boolean)

buttonAnswer0.Visible = visibleState

buttonAnswer1.Visible = visibleState

buttonAnswer2.Visible = visibleState

buttonAnswer3.Visible = visibleState

buttonAnswer4.Visible = visibleState

buttonAnswer5.Visible = visibleState

End Sub

'-----------------------------------------------------------------

'Вспомогательная функция, вызываемая для задания свойств видимости

'некоторых элементов управления

'-----------------------------------------------------------------

Private Sub SetDifficultyButtonVisibility(ByVal visibleState _

As Boolean)

buttonShowAnswers_AdvancedVersion.Visible = visibleState

buttonShowAnswers_SimpleVersion.Visible = visibleState

End Sub

'-----------------------------------------------------------------------

'Вспомогательная функция, которая позволяет задавать состояние видимости

'кнопок, отображающих ответы из словаря

'-----------------------------------------------------------------------

Private Sub SetAnswerButtonEnabled(ByVal enabledState _

As Boolean)

buttonAnswer0.Enabled = enabledState

buttonAnswer1.Enabled = enabledState

buttonAnswer2.Enabled = enabledState

buttonAnswer3.Enabled = enabledState

buttonAnswer4.Enabled = enabledState

buttonAnswer5.Enabled = enabledState

End Sub

'-----------------------------------------------------------------

'Задает текст в текстовом окне и кнопках,

'необходимых для формулирования вопросов.

'

'В случае практической реализации эта функция должна просматривать

'вопросы динамически

'-----------------------------------------------------------------

Private Sub SetTextForVocabularyQuestion()

setQuestionText("What is the English word for 'der Mensch'?")

buttonAnswer0.Text = "Four"

buttonAnswer1.Text = "Person"

buttonAnswer2.Text = "Three"

buttonAnswer3.Text = "To Jump"

buttonAnswer4.Text = "Newspaper"

buttonAnswer5.Text = "Brother"

End Sub

'Вызывается для оценки варианта ответа, выбранного пользователем

Private Sub evaluateMultipleChoiceAnswer(ByVal buttonClicked _

As Button, ByVal selection As Integer)

'Примечание: В практической реализации правильный номер ответа

'определяется динамически и не всегда соответствует "кнопке #1"

'Если выбранный пользователем вариант ответа не является правильным,

'отменить доступ к нажатой кнопке

If (selection <> 1) Then

'Выбранный вариант ответа является неправильным

buttonClicked.Enabled = False

Else

'Пользователь выбрал правильный ответ, продолжить игру

StateChangeForGameUI(GameUIState.waitForNextQuestion)

End If

End Sub

'Абстракция, задающая текст вопросов

Sub setQuestionText(ByVal textIn As String)

textBoxAskQuestion.Text = textIn

End Sub

'----------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Пользователь желает увидеть следующий вопрос

'----------------------------------------------------------------

Private Sub buttonAskQuestion_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonAskQuestion.Click

SetTextForVocabularyQuestion()

StateChangeForGameUI(GameUIState.waitForUserToStateKnowledge)

End Sub

'---------------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ:

'Пользователь желает ответить на отображенный вопрос и сообщить, какой

'наиболее сложный уровень является для него приемлемым

'---------------------------------------------------------------------

Private Sub buttonShowAnswers AdvancedVersion_Click( _

ByVal sender As Object, ByVal e As System.EventArgs) _

Handles buttonShowAnswers_AdvancedVersion.Click

'Установить состояние игры для отображения вариантов выбора

StateChangeForGameUI( _

GameUIState.waitForUserToAnswerMultipleChoice)

End Sub

'---------------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ:

'Пользователь желает ответить на отображенный вопрос и сообщить, какой

'наиболее легкий уровень является для него приемлемым

'---------------------------------------------------------------------

Private Sub buttonShowAnswers_SimpleVersion_Click( _

ByVal sender As Object, ByVal e As System.EventArgs) _

Handles buttonShowAnswers_SimpleVersion.Click

'Установить состояние игры для отображения вариантов выбора

StateChangeForGameUI( _

GameUIState.waitForUserToAnswerMultipleChoice)

End Sub

'ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

Private Sub buttonAnswer0_Click(ByVal sender As Object, ByVal _

e As System.EventArgs) Handles buttonAnswer0.Click

evaluateMultipleChoiceAnswer(buttonAnswer0, 0)

End Sub

'ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

Private Sub buttonAnswer1_Click(ByVal sender As Object, ByVal _

e As System.EventArgs) Handles buttonAnswer1.Click

evaluateMultipleChoiceAnswer(buttonAnswer1, 1)

End Sub

'ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

Private Sub buttonAnswer2_Click(ByVal sender As Object, ByVal _

e As System.EventArgs) Handles buttonAnswer2.Click

evaluateMultipleChoiceAnswer(buttonAnswer2, 2)

End Sub

'ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

Private Sub buttonAnswer3_Click(ByVal sender As Object, ByVal _

e As System.EventArgs) Handles buttonAnswer3.Click

evaluateMultipleChoiceAnswer(buttonAnswer3, 3)

End Sub

'ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

Private Sub buttonAnswer4_Click(ByVal sender As Object, ByVal _

e As System.EventArgs) Handles buttonAnswer4.Click

evaluateMultipleChoiceAnswer(buttonAnswer4, 4)

End Sub

'ОБРАБОТЧИК СОБЫТИЙ: Был выполнен щелчок на кнопке выбора варианта ответа

Private Sub buttonAnswer5_Click(ByVal sender As Object, ByVal _

e As System.EventArgs) Handles buttonAnswer5.Click

evaluateMultipleChoiceAnswer(buttonAnswer5, 5)

End Sub

Листинг 13.2. Динамическое создание элементов управления на форме во время выполнения

'-------------------------------------

'Счетчик количества создаваемых кнопок

'-------------------------------------

Private m_nextNewButtonIndex As Integer

'---------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Обработчик щелчка на кнопке, которая

' имеется на нашей форме.

'

'Эта функция создает новую кнопку, присоединяет ее к нашей форме

'и подключает обработчик события щелчка для нее

'---------------------------------------------------------------

Private Sub buttonCreateNewButtons_Click(ByVal sender As _

System.Object, ByVal e As System.EventArgs) _

Handles buttonCreateNewButtons.Click

'Впоследствии мы начнем создавать новые кнопки, начиная

'снизу экрана, поэтому ограничиваем их количество восемью

If (m_nextNewButtonIndex > 8) Then

Return

End If

'----------------------------------------------------

'Создать кнопку (еще не присоединенную к нашей форме)

'установить ее местоположение, размеры и текст

'----------------------------------------------------

Const newButtonHeight As Integer = 15

Dim newButton As System.Windows.Forms.Button

newButton = New System.Windows.Forms.Button

newButton.Width = 100

newButton.Height = newButtonHeight

newButton.Left = 2

newButton.Top = (newButtonHeight + 2) * m_nextNewButtonIndex

newButton.Text = "New Button " + _

m_nextNewButtonIndex.ToString()

'----------------------------------------------------

'Присоединить обработчик к событию щелчка для данного

'элемента управления.

'----------------------------------------------------

AddHandler newButton.Click, _

AddressOf Me.ClickHandlerForButtons

'---------------------------------------------

'Присоединить эту кнопку к форме. По существу,

'это создаст кнопку на форме!

'---------------------------------------------

newButton.Parent = Me

'Увеличить счетчик в соответствии с созданием очередной кнопки

m_nextNewButtonIndex = m_nextNewButtonIndex + 1

End Sub

'-----------------------------------------------------

'Обработчик событий, который мы динамически подключаем

'к нашим новым кнопкам

'-----------------------------------------------------

Private Sub ClickHandlerForButtons(ByVal sender As Object, _

ByVal e As System.EventArgs)

Dim buttonCausingEvent As Button = _

CType(sender, System.Windows.Forms.Button)

'Вызвать окно сообщений, извещающее о том,

'что мы получили событие

MsgBox("Click event from:" + vbCrLf + buttonCausingEvent.Text)

End Sub

Листинг 13.3. Фильтрующее текстовое окно, принимающее текст в формате ###-##-####

Option Strict On

Imports System

'----------------------------------------------------------------------------

'Этот класс является элементом управления, производным от элемента управления

'TextBox.

'Он наследует все графические свойства TextBox, но добавляет фильтрацию

'содержимого текстового окна, тем самым гарантируя,

'что вводимый текст будет соответствовать формату:

'###-##-####.

'Этот формат соответствует формату номеров карточек социального страхования,

'используемых в США.

'-----------------------------------------------------------------------------

Public Class SocialSecurityTextBox

Inherits System.Windows.Forms.TextBox

Private m_inputIsFullValidEntry As Boolean

'------------------------------------------------

'Указывает, получен ли

'номер карточки социального страхования полностью

'------------------------------------------------

Public ReadOnly Property IsFullValidInput() As Boolean

Get

Return m_inputIsFullValidEntry

End Get

End Property

'Объект StringBuilder, которую мы будем часто использовать

Private m_sb As System.Text.StringBuilder

'Максимальная длина обрабатываемых строк

Const SSNumberLength As Integer = 11

'-----------

'Конструктор

'-----------

Public Sub New()

'Распределить память для нашего объекта StringBuilder и предоставить

'место для нескольких дополнительных рабочих символов по умолчанию

m_sb = New System.Text.StringBuilder(SSNumberLength + 5)

m_inputIsFullValidEntry = False

End Sub

'---------------------------------------------------------------------

'Форматировать поступающий текст с целью установления его соответствия

'нужному формату:

'

' Формат номера карточки социального страхования: ###-##-####

' символы: 01234567890

'

' [in] inString          : Текст, который мы хотим форматировать

' [in/out] selectionStart: Текущая точка вставки в тексте;

'  она будет смещаться в связи с удалением

'                           и добавлением нами символов

'----------------------------------------------------------------------

Private Function formatText_NNN_NN_NNNN(ByVal inString As _

String, ByRef selectionStart As Integer) As String

Const firstDashIndex As Integer = 3

Const secondDashIndex As Integer = 6

'Удалить старые данные и поместить входную строку

'в объект StringBuilder, чтобы мы могли с ней работать.

m_sb.Length = 0

m_sb.Append(inString)

'------------------------------------------------------------

'Просмотреть каждый символ в строке, пока не будет

'достигнута максимальная длина нашего форматированного текста

'------------------------------------------------------------

Dim currentCharIndex As Integer

currentCharIndex = 0

While ((currentCharIndex < m_sb.Length) AndAlso _

(currentCharIndex < SSNumberLength))

Dim currentChar As Char

currentChar = m_sb(currentCharIndex)

If ((currentCharIndex = firstDashIndex) OrElse _

(currentCharIndex = secondDashIndex)) Then

'-------------------------------

'The character needs to be a "-"

'-------------------------------

If (currentChar <> "-"c) Then 'Вставить дефис

m_sb.Insert(currentCharIndex, "-")

'Если мы добавили символ перед точкой вставки,

'она должна быть смещена вперед

If (currentCharIndex <= selectionStart) Then

selectionStart = selectionStart + 1

End If

End If

'Этот символ годится, перейти к следующему символу

currentCharIndex = currentCharIndex + 1

Else

'-------------------------

'Символ должен быть цифрой

'-------------------------

If (System.Char.IsDigit(currentChar) = False) Then

'Удалить символ

m_sb.Remove(currentCharIndex, 1)

'Если мы добавили символ перед точкой вставки,

'она должна быть смещена назад

If (currentCharIndex < selectionStart) Then

selectionStart = selectionStart - 1

End If

'He увеличивать значение счетчика символов, ибо мы должны

'просмотреть символ, занявший место того символа,

'который мы удалили

Else

'Символ является цифрой, все нормально.

currentCharIndex = currentCharIndex + 1

End If

End If

End While

'Если превышена длина строки, усечь ее

If (m_sb.Length > SSNumberLength) Then

m_sb.Length = SSNumberLength

End If

'Возвратить новую строку

Return m_sb.ToString()

End Function

Private m_in_OnChangeFunction As Boolean

Protected Overrides Sub OnTextChanged(ByVal e As EventArgs)

'------------------------------------------------------------------

'Если мы изменим свойство .Text, то будет осуществлен повторный

'вход в обработчик. В этом случае мы не хотим предпринимать никаких

'действий и должны просто выйти из функции без передачи события

'куда-то еще.

'------------------------------------------------------------------

If (m_in_OnChangeFunction = True) Then

Return

End If

'Заметьте, что сейчас мы находимся в функции OnChanged,

'поэтому мы можем обнаружить повторное вхождение (см. код выше)

m_in_OnChangeFunction = True

'Получить текущее свойство .Text

Dim oldText As String = Me.Text

'Получить текущий индекс SelectionStart

Dim selectionStart As Integer = Me.SelectionStart

'Форматировать строку, чтобы она удовлетворяла нашим потребностям

Dim newText As String = formatText_NNN_NN_NNNN(oldText, _

selectionStart)

'Если текст отличается от исходного, обновить

'свойство .Text

If (oldText <> newText) Then

'Это приведет к повторному вхождению

Me.Text = newText

'Обновить местоположение точки вставки

Me.SelectionStart = selectionStart

End If

'Мы принудительно обеспечили соответствие введенного текста правильному

'формату, поэтому, если длина строки согласуется с длиной номера

'карточки социального страхования, то мы знаем что он имеет

'формат ###-##-####.

If (Me.Text.Length = SSNumberLength) Then

'Да, мы имеем полный номер карточки социального страхования

m_inputIsFullValidEntry = True

Else

'Нет, мы пока не получили полный номер карточки социального страхования

m_inputIsFullValidEntry = False

End If

'Вызвать наш базовый класс и сообщить всем объектам, которых это может

'интересовать, что текст изменился

MyBase.OnTextChanged(e)

'Заметьте, что сейчас мы покидаем наш код и хотим отключить

'проверку повторных вхождений в него.

m_in_OnChangeFunction = False

End Sub

Protected Overrides Sub OnKeyPress( _

ByVal e As System.Windows.Forms.KeyPressEventArgs)

'Поскольку нам известно, что никакие буквы при вводе нам не нужны,

'то просто игнорировать их, если они встречаются.

Dim keyPressed As Char = e.KeyChar

If (System.Char.IsLetter(keyPressed)) Then

'Сообщить системе о том, что событие обработано

e.Handled = True

Return

End If

'Обработать нажатие клавиши обычным способом

MyBase.OnKeyPress(e)

End Sub

End Class

Листинг 13.4. Код формы для создания пользовательского элемента управления TextBox

'-----------------------------------------------------------------

'Переменная для хранения нашего нового элемента управления TextBox

'-----------------------------------------------------------------

Private m_filteredTextBox As SocialSecurityTextBox

'-----------------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Создать экземпляр нашего пользовательского элемента

' управления и поместить его в форму

'-----------------------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Создать, позиционировать и разместить элемент управления

m_filteredTextBox = New SocialSecurityTextBox

m_filteredTextBox.Bounds = _

New System.Drawing.Rectangle(2, 2, 160, 20)

'Подключить обработчик событий

AddHandler m_filteredTextBox.TextChanged, _

AddressOf Me.textBox_TextChanged

'Задать родительский объект

m_filteredTextBox.Parent = Me

'Выделить элемент управления

m_filteredTextBox.Focus()

'Сделать данную кнопку недоступной, чтобы поверх данного объекта

'не был создан второй объект

SocialSecurityTextBox Button1.Enabled = False

End Sub

'----------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Этот обработчик подключается динамически при

' создании элемента управления

'----------------------------------------------------------------

Private Sub textBox_TextChanged(ByVal sender As Object, _

ByVal e As System.EventArgs)

If (m_filteredTextBox.IsFullValidInput = True) Then

label1.Text = "FULL SOCIAL SECURITY NUMBER!!!"

Else

Label1.Text = "Not full input yet..."

End If

End Sub

Листинг 13.5. код формы, демонстрирующий использование прозрачности '

'----------------------------------------------------------------

'Размеры наших битовых образов и экранного изображения PictureBox

'----------------------------------------------------------------

Const bitmap_dx As Integer = 200

Const bitmap_dy As Integer = 100

'-------------------------------------------------

'Создает и прорисовывает изображение заднего плана

'-------------------------------------------------

Private m_backgroundBitmap As System.Drawing.Bitmap

Sub CreateBackground()

If (m_backgroundBitmap Is Nothing) Then

m_backgroundBitmap = New Bitmap(bitmap_dx, bitmap_dy)

End If

'Делаем битовую карту белой

Dim gfx As System.Drawing.Graphics

gfx = System.Drawing.Graphics.FromImage(m_backgrourdBitmap)

gfx.Clear(System.Drawing.Color.White)

'Рисуем текст черным

Dim myBrush As System.Drawing.Brush

myBrush = New System.Drawing.SolidBrush( _

System.Drawing.Color.Black)

Dim у As Integer

For у = 0 To bitmap_dy Step 15

gfx.DrawString("I am the BACKGROUND IMAGE...hello", Me.Font, myBrush, 0, y)

Next

'Очистить

myBrush.Dispose()

gfx.Dispose()

End Sub

'-------------------------------------------------

'Создает и прорисовывает изображение заднего плана

'-------------------------------------------------

Private m_foregroundBitmap As System.Drawing.Bitmap

Sub CreateForeground()

If (m_foregroundBitmap Is Nothing) Then

m_foregroundBitmap = New Bitmap(bitmap_dx, bitmap_dy)

End If

'Делаем всю битовую карту синей

Dim gfx As System.Drawing.Graphics

gfx = System.Drawing.Graphics.FromImage(m_foregroundBitmap)

gfx.Clear(System.Drawing.Color.Blue)

'Рисуем несколько фигур желтым

Dim yellowBrush As System.Drawing.Brush

yellowBrush = New System.Drawing.SolidBrush( _

System.Drawing.Color.Yellow)

gfx.FillEllipse(yellowBrush, 130, 4, 40, 70)

gfx.FillRectangle(yellowBrush, 5, 20, 110, 30)

gfx.FillEllipse(yellowBrush, 60, 75, 130, 20)

'Очистить

yellowBrush.Dispose()

gfx.Dispose()

End Sub

'-----------------------------------------------------------------

'Устанавливает размеры и местоположение PictureBox с левой стороны

'-----------------------------------------------------------------

Private Sub SetPictureBoxDimensions()

PictureBox1.Width = bitmap_dx

PictureBox1.Height = bitmap_dy

PictureBox1.Left = 20

End Sub

'---------------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Отобразить изображение ЗАДНЕГО ПЛАНА в PictureBox

'---------------------------------------------------------------------

Private Sub buttonDrawBackground_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonDrawBackground.Click

SetPictureBoxDimensions()

CreateBackground()

PictureBox1.Image = m_backgroundBitmap

End Sub

'-----------------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Отобразить изображение ПЕРЕДНЕГО ПЛАНА в PictureBox

'-----------------------------------------------------------------------

Private Sub buttonDrawForeground_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonDrawForeground.Click

SetPictureBoxDimensions()

CreateForeground()

PictureBox1.Image = m_foregroundBitmap

End Sub

'-----------------------------------------------------------------------

'ОБРАБОТЧИК СОБЫТИЙ: Наложить изображение ПЕРЕДНЕГО ПЛАНА на изображение

' ЗАДНЕГО ПЛАНА. Использовать МАСКУ ПРОЗРАЧНОСТИ, чтобы желтый

' цвет в изображении ПЕРЕДНЕГО ПЛАНА стал прозрачным и через

' него можно было видеть содержимое изображения

' ЗАДНЕГО ПЛАНА

'------------------------------------------------------------------------

Private Sub buttonDrawBackgroundPlusForeground_Click(ByVal _

sender As Object, ByVal e As System.EventArgs) _

Handles buttonDrawBackgroundPlusForeground.Click

SetPictureBoxDimensions()

CreateForeground()

CreateBackground()

'Получить объект Graphics изображения ЗАДНЕГО ПЛАНА, поскольку

'именно поверх него мы собираемся рисовать.

Dim gfx As System.Drawing.Graphics

gfx = System.Drawing.Graphics.FromImage(m_backgroundBitmap)

'-------------------------------------------------------

'Создать класс ImageAttributes. Этот класс позволяет нам

'задать прозрачный цвет на наших операций рисования

'-------------------------------------------------------

Dim trasparencyInfo As System.Drawing.Imaging.ImageAttributes

trasparencyInfo = New System.Drawing.Imaging.ImageAttributes

'----------------------

'Задать прозрачный цвет

'----------------------

trasparencyInfo.SetColorKey(System.Drawing.Color.Yellow, _

System.Drawing.Color.Yellow)

'Задать прямоугольник рисунка

Dim rect As System.Drawing.Rectangle = _

New System.Drawing.Rectangle(0, 0, _

m_backgroundBitmap.Width, m_backgroundBitmap.Height)

'-----------------------------------------------------------------------

'Нарисовать изображение ПЕРЕДНЕГО ПЛАНА поверх изображения ЗАДНЕГО ПЛАНА

'и использовать прозрачный цвет в ImageAttributes для создания окна

'прозрачности, через которое виден задний план

'-----------------------------------------------------------------------

gfx.DrawImage(m_foregroundBitmap, rect, 0, 0, _

m_foregroundBitmap.Width, m_foregroundBitmap.Height, _

System.Drawing.GraphicsUnit.Pixel, trasparencyInfo)

'Очистить

gfx.Dispose()

'Показать результат в виде растрового изображения

PictureBox1.Image = m_backgroundBitmap

End Sub

Листинг 13.6. Код формы, демонстрирующий загрузку встроенных ресурсов

'-----------------------------------------------------------

'Загрузить изображение и отобразить его в объекте PictureBox

'-----------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

LoadImageFromResource()

PictureBox1.Image = m_myBitmapImage

End Sub

Private m_myBitmapImage As System.Drawing.Bitmap

'------------------------------------------------------------------

'Загрузить изображение, которое хранится в виде встроенного ресурса

'в нашей сборке

'------------------------------------------------------------------

Public Sub LoadImageFromResource()

'Если изображение уже загружено,

'то не имеет смысла делать это повторно.

If Not (m_myBitmapImage Is Nothing) Then

Return

End If

'----------------------------------------------------

'Получить ссылку на двоичную сборку нашего приложения

'----------------------------------------------------

Dim thisAssembly As System.Reflection.Assembly = _

System.Reflection.Assembly.GetExecutingAssembly()

'-------------------

'Получить имя сборки

'-------------------

Dim thisAssemblyName As System.Reflection.AssemblyName = _

thisAssembly.GetName()

Dim assemblyName As String = thisAssemblyName.Name

'-----------------------------------------------------------------------

'Извлечь поток изображения из нашей сборки и создать соответствующую ему

'битовую карту в памяти

'ПРИМЕЧАНИЕ: Имя потока ресурса ResourceStream ЧУВСТВИТЕЛЬНО К РЕГИСТРУ,

'   поэтому имя изображения должно В ТОЧНОСТИ совпадать с именем

'   файла изображения, который вы добавили в проект

'-----------------------------------------------------------------------

m_myBitmapImage = New System.Drawing.Bitmap( _

thisAssembly.GetManifestResourceStream( _

assemblyName + ".MyImage.PNG"))

End Sub

Примеры к главе 14 (данные)

Листинг 14.1. Простой пример создания и использования объекта ADO.NET DataSet

'Объект DataSet, который мы собираемся загрузить

Private m_myDataSet As System.Data.DataSet

'Константы, которые будут использоваться

Const FILE_EMPTY_DATASET As String = "EmptyDataSet.xml"

Const FILE_1TABLE_DATASET As String = "1TableDataSet.xml"

Const dividerLine As String = _

"-----------------------------" + vbCrLf

'-------------------------------------------------------

'Загрузить содержимое файла и присоединить его к тексту,

'содержащемуся в элементе управления textBox1

'-------------------------------------------------------

Private Sub addFileContentsToTextBox(ByVal fileName As String)

'Открыть файл и считать его содержимое

Dim myStreamReader As System.IO.StreamReader

myStreamReader = System.IO.File.OpenText(fileName)

Dim fileText As String = myStreamReader.ReadToEnd()

'Закрыть файл

myStreamReader.Close()

'Присоединить содержимое к тексту, находящемуся в текстовом окне

TextBox1.Text = TextBox1.Text + _

dividerLine + "FILE: '" + fileName + "'" + vbCrLf + _

dividerLine + fileText + vbCrLf

End Sub

'--------------------------------------------------------

'1. Создает набор данных,

' сохраняет набор данных в виде XML,

' отображает результаты в текстовом окне

'2.  Добавляет таблицу данных в набор данных,

'  добавляет два типизированных столбца в таблицу данных,

'  добавляет две строки в таблицу данных,

'  сохраняет набор данных в виде XML,

'  отображает результаты в текстовом окне

'--------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

'Очистить текстовое окно от содержимого

TextBox1.Text = ""

'===========================================

'1. Создать новый набор данных

'===========================================

m_myDataSet = New System.Data.DataSet("HelloWorld-DataSet")

'Записать содержимое ADO.NET DataSet в виде XML и отобразить

'файл в текстовом окне

m_myDataSet.WriteXml(FILE_EMPTY_DATASET)

addFileContentsToTextBox(FILE_EMPTY_DATASET)

'==================================================

'2. Добавить таблицу данных в набор данных ADO.NET,

' а также 2 строки данных в таблицу данных

'==================================================

Dim myTestTable As System.Data.DataTable

myTestTable = m_myDataSet.Tables.Add("TestTable")

'----------------------------

'Добавить 2 столбца в таблицу

'----------------------------

'Добавить столбец данных в таблицу DataTable набора DataSet

myTestTable.Columns.Add("TestColumn0", _

GetType(System.DateTime))

'Добавить строковый столбец в таблицу DataTable набора DataSet

myTestTable.Columns.Add("TestColumn1", GetType(String))

'--------------------------------

'Добавить строки данных в таблицу

'--------------------------------

'Добавить строку данных в таблицу данных

Dim rowOfData() As Object

ReDim rowOfData(1)

'Столбец 0 - это тип данных

rowOfData(0) = System.DateTime.Today

'Столбец 1 — это строковый тип

rowOfData(1) = "а string of data today"

myTestTable.Rows.Add(rowOfData)

'Добавить вторую строку данных в таблицу данных

Dim rowOfData2() As Object

ReDim rowOfData2(1) 'Столбец 0 — это тип данных

rowOfData2(0) = System.DateTime.Today.AddDays(1)

'Столбец 1 — это строковый тип

rowOfData2(1) = "tomorrow's string"

myTestTable.Rows.Add(rowOfData2)

'Записать содержимое набора ADO.NET DataSet в виде XML и отобразить

'файл в текстовом окне

m_myDataSet.WriteXml(FILE_1TABLE_ DATASET)

addFileContentsToTextBox(FILE_1TABLE_DATASET)

End Sub

Листинг 14.2. Использование параметра XMLWriteMode при сохранении объекта ADO.NET DataSet

'-----------------------------------------------------------------------

'Необходимость в этой функции возникает по той причине, что .NET Compact

'Framework не поддерживает перегрузку:

' "public voidWriteXml(string, XmlWriteMode);"

'

'в качестве функции-члена "public" (только "private")

'-----------------------------------------------------------------------

Sub writeDataSetToFile(ByVal ds As System.Data.DataSet, _

ByVal filename As String, _

ByVal xmlWriteMode As System.Data.XmlWriteMode)

'Создать объект XmlWriter для записи наших XML-данных

Dim xmlWriter As System.Xml.XmlWriter

xmlWriter = New System.Xml.XmlTextWriter(filename, _

System.Text.Encoding.Default)

'ПРИМЕЧАНИЕ: Эта перегруженная версия не является общедоступной (public)!

'ds.WriteXml(filename, xmlWriteMode)

'Вместо этого используем следующую функцию:

ds.WriteXml(xmlWiiter, xmlWriteMode)

xmlWriter.Close() 'Важно закрыть файл!

End Sub

Листинг 14.3. Сравнение производительности различных вариантов доступа к данным с использованием объектов DataSet

Private m_myDataSet As System.Data.DataSet 'Набор данных для тестирования

'Индексы столбцов и таблицы, подлежащие кэшированию

Private m_indexesLookedUp As Boolean = False

Private Const INVALID_INDEX As Integer = -1

Private m_IndexOfTestColumn_CreditCard _

As Integer = INVALID_INDEX

Private m_IndexOfTestColumn_TravelDate _

As Integer = INVALID_INDEX

Private m_IndexOfTestTable As Integer = INVALID_INDEX

'Столбцы данных и таблица, подлежащих кэшированию

Private m_TestColumn_CreditCard As System.Data.DataColumn

Private m_TestColumn_TravelDate As System.Data.DataColumn

Private m_TableCustomerInfo As System.Data.DataTable

Public Enum testType '3 вида тестов, которые мы можем выполнять

textColumnLookup

cachedIndexLookup

cachedColumnObject

End Enum

'Эти константы определяют размерные характеристики тестов

Const DUMMY_ROWS_OF_DATA As Integer = 100

Const NUMBER_TEST_ITERATIONS As Integer = 500

'Табличная информация

Const TABLE_NAME_PASSENGERINFO As String = "CustomerTravelInfo"

Const COLUMN_NAME_DATE_OF_TRAVEL As String = "DateOfTravel"

Const COLUMN_NAME_PASSENGER_NAME As String = "PassengerName"

Const COLUMN_NAME_PASSENGER_CREDIT_CARD As String = _

"PassengerCreditCard"

Const TEST_CREDIT_CARD As String = "IvoCard-987-654-321-000"

'--------------------

'Создает набор данных

'--------------------

Private Sub createDataSet()

'1. Создать новый объект DataSet

m_myDataSet = New System.Data.DataSet("TravelService Dataset")

'2. Добавить объект DataTable в объект ADO.NET DataSet

Dim myTestTable As System.Data.DataTable

myTestTable = m_myDataSet.Tables.Add(TABLE_NAME_PASSENGERINFO)

'Добавить 2 столбца в таблицу

'Добавить столбец данных в таблицу DataTable набора данных DataSet

myTestTable.Columns.Add(COLUMN_NAME_DATE_OF_TRAVEL, _

GetType(System.DateTime))

'Добавить столбец строк в таблицу DataTable набора данных DataSet

myTestTable.Columns.Add(COLUMN_NAME_PASSENGER_NAME, _

GetType(String))

'Добавить столбец строк в таблицу DataTable набора данных DataSet

myTestTable.Columns.Add(COLUMN_NAME_PASSENGER_CREDIT_CARD, _

GetType(String))

'Данные для размещения в строках данных

Dim objArray() As Object ReDim objArray(2)

'--------------------------------

'Добавить строки данных в таблицу

'--------------------------------

Dim buildTestString As System.Text.StringBuilder

buildTestString = New System.Text.StringBuilder

Dim addItemsCount As Integer

For addItemsCount = 1 To DUMMY_ROWS_OF_DATA

'Выбрать день отъезда пассажира

objArray(0) = System.DateTime.Today.AddDays(addItemsCount)

'Выбрать имя пассажира

buildTestString.Length = 0

buildTestString.Append("TestPersonName")

buildTestString.Append(addItemsCount)

objArray(1) = buildTestString.ToString()

'Связать с пассажиром текстовый номер кредитной карточки

buildTestString.Length = 0

buildTestString.Append("IvoCard-000-000-0000-")

buildTestString.Append(addItemsCount)

objArray(2) = buildTestString.ToString()

'Добавить элементы массива в строку набора данных

myTestTable.Rows.Add(objArray)

Next

'Добавить элемент, поиск которого мы хотим проводить при выполнении теста

objArray(0) = System.DateTime.Today

objArray(1) = "Ms. TestPerson"

objArray(2) = ТЕST_CREDIT_CARD

'Добавить элементы массива в строку набора данных

myTestTable.Rows.Add(objArray)

End Sub

'---------------------------------------------------------------

'Найти и кэшировать все индексы набора данных, которые нам нужны

'---------------------------------------------------------------

Private Sub cacheDataSetInfo()

'Выйти из функции, если индексы уже загружены

If (m_indexesLookedUp = True) Then Return

'Кэшировать индекс таблицы

m_IndexOfTestTable = _

m_myDataSet.Tables.IndexOf(TABLE_NAME_PASSENGERINFO)

'------------------------------------------

'Итерировать по всем столбцам нашей таблицы

'и кэшировать индексы нужных столбцов

'------------------------------------------

mTableCustomerInfo = m_myDataSet.Tables(m_IndexOfTestTable)

Dim dataColumnCount As Integer

dataColumnCount = m_TableCustomerInfo.Columns.Count

Dim myColumn As System.Data.DataColumn

Dim colIdx As Integer

While (colIdx < dataColumnCount)

myColumn = m_TableCustomerInfo.Columns(colIdx)

'Предпринимать поиск, только если это еще не сделано

If (m_IndexOfTestColumn_CreditCard = INVALID_INDEX) Then

'Проверить, совпадает ли имя

If (myColumn.ColumnName = _

COLUMN_NAME_PASSENGER_CREDIT_CARD) Then

'Кэшировать индекс

m_IndexOfTestColumn_CreditCard = colIdx

'Кэшировать столбец

m_TestColumn_CreditCard = myColumn

GoTo next_loop_iteration 'Опустить другие операции сравнения...

End If 'Endif: сравнение строк

End If

If (m _IndexOfTestColumn_TravelDate = INVALID_INDEX) Then

'Проверить, совпадает ли имя

If (myColumn.ColumnName = _

COLUMN_NAME_DATE_OF_TRAVEL) Then

'Кэшировать индекс

m_IndexOfTestColumn_TravelDate = colIdx

'Кэшировать столбец

m_TestColumn_TravelDate = myColumn

GoTo next_loop_iteration 'Опустить другие операции сравнения

End If 'Endif: сравнение строк

End If

next_loop_iteration:

colIdx = colIdx + 1

End While

m_indexesLookedUp = True

End Sub

'---------------

'Выполнить тест.

'---------------

Sub changeDayOfTravel_test(ByVal kindOfTest As testType)

'Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.WaitCursor

'Начать с известной даты

Dim newDate As System.DateTime

newDate = System.DateTime.Today

changeDayOfTravel_textColumnLookup(TEST_CREDIT_CARD, newDate)

'ДОПУСТИМО ТОЛЬКО ДЛЯ ТЕСТОВОГО КОДА!!!

'Вызов сборщика мусора в коде ЗАМЕДЛИТ работу вашего приложения!

System.GC.Collect()

Const testNumber As Integer = 0

'Настроить соответствующим образом в зависимости от вида выполняемого теста

Select Case (kindOfTest)

Case testType.textColumnLookup

PerformanceSampling.StartSample(testNumber, _

"Text based Column lookup.")

Case testType.cachedIndexLookup

PerformanceSampling.StartSample(testNumber, _

"Cached Column Index lookup.")

Case testType.cachedColumnObject

PerformanceSampling.StartSample(testNumber, _

"Cached Column objects")

Case Else

Throw New Exception("Unknown state!")

End Select

'Выполнить тест!

Dim testCount As Integer

For testCount = 1 To NUMBER_TEST_ITERATIONS

'Передвинуть дату вперед на один день

newDate = newDate.AddDays(1)

Dim numberRecordsChanged As Integer = 0

'Какой вид теста мы выполняем?

Select Case (kindOfTest)

Case testType.textColumnLookup

'НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Просмотреть все имена, используя СТРОКИ

numberRecordsChanged = _

changeDayOfTravel_textColumnLookup( _

TEST_CREDIT_CARD, newDate)

Case testType.cachedIndexLookup

'ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированные индексы

numberRecordsChanged = _

changeDayOfTravel_cachedColumnIndex( _

TEST_CREDIT_CARD, newDate)

Case testType.cachedColumnObject

'НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированные объекты

numberRecordsChanged = _

changeDayOfTravel_CachedColumns( _

TEST_CREDIT_CARD, newDate)

End Select

'Убедиться в том, что тест выполняется, как и ожидалось

If (numberRecordsChanged <> 1) Then

MsgBox("No matching records found. Test aborted!")

Return

End If

Next

'Получить время, которое потребовалось для выполнения теста

PerformanceSampling.StopSample(testNumber)

'Обычный курсор

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.Default

'Отобразить результаты выполнения теста

Dim runInfo As String = NUMBER_TEST_ITERATIONS.ToString() + _

"x" + DUMMY_ROWS_OF_DATA.ToString() + ": "

MsgBox(runInfo + _

PerformanceSampling.GetSampleDurationText(testNumber))

End Sub

'ФУНКЦИЯ ПОИСКА, ОБЛАДАЮЩАЯ НИЗКОЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

Private Function changeDayOfTravel_textColumnLookup( _

ByVal creditCardNumber As String, _

ByVal newTravelDate As System.DateTime) As Integer

Dim numberRecordsChanged As Integer

'Найти имя таблицы

Dim dataTable_Customers As System.Data.DataTable

'НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск в таблице, используя

'сравнение строк!

dataTable_Customers = _

m_myDataSet.Tables(TABLE_NAME_PASSENGERINFO)

Dim currentCustomerRow As System.Data.DataRow

For Each currentCustomerRow In dataTable_Customers.Rows

Dim currentCreditCard As String

'НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск в таблице, используя

'сравнение строк!

currentCreditCard = CType( _

currentCustomerRow(COLUMN_NAME_PASSENGER_CREDIT_CARD), String)

'Проверить, является ли данная кредитная карточка искомой

If (creditCardNumber = currentCreditCard) Then

'Изменить дату отъезда

'НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск столбца, используя

'сравнение строк!

Dim currentTravelDate As System.DateTime = CType( _

currentCustomerRow(COLUMN_NAME_DATE_OF_TRAVEL), _

System.DateTime)

If (currentTravelDate <> newTravelDate) Then

'НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Осуществить поиск столбца, используя

'сравнение строк!

currentCustomerRow(COLUMN_NAME_DATE_OF_TRAVEL) = _

newTravelDate

numberRecordsChanged = numberRecordsChanged + 1

End If

End If 'endif: сравнение строк

Next 'end for each

Return numberRecordsChanged 'Количество обновленных записей

End Function

'ФУНКЦИЯ, ХАРАКТЕРИЗУЮЩАЯСЯ НЕСКОЛЬКО ЛУЧШЕЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

Private Function changeDayOfTravel_cachedColumnIndex( _

ByVal creditCardNumber As String, ByVal newTravelDate _

As DateTime) As Integer

Dim numberRecordsChanged As Integer

'Поиск имени таблицы

Dim dataTable_Customers As System.Data.DataTable

'ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: использовать кэшированный индекс

dataTable_Customers = _

m_myDataSet.Tables(m_IndexOfTestTable)

Dim currentCustomerRow As System.Data.DataRow

For Each currentCustomerRow In dataTable_Customers.Rows

Dim currentCreditCard As String

'ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: использовать кэшированный индекс столбца!

currentCreditCard = CType(currentCustomerRow( _

m_IndexOfTestColumn_CreditCard), String)

'Проверить, совпадает ли номер кредитной карточки

If (creditCardNumber = currentCreditCard) Then

'Изменить дату отъезда

'ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

Dim currentTravelDate As System.DateTime = CType( _

currentCustomerRow (m_IndexOfTestColumn_TravelDate), System.DateTime)

If (currentTravelDate <> newTravelDate) Then

'ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

currentCustomerRow(m_IndexOfTestColumn_TravelDate) = _

newTravelDate

numberRecordsChanged = numberRecordsChanged + 1

End If

End If

Next

Return numberRecordsChanged 'Количество обновленных записей

End Function

'ФУНКЦИЯ, ОБЛАДАЮЩАЯ НАИЛУЧШЕЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

Private Function changeDayOfTravel_CachedColumns( _

ByVal creditCardNumber As String, _

ByVal newTravelDate As System.DateTime) As Integer

Dim numberRecordsChanged As Integer

'Найти имя таблицы

Dim dataTable_Customers As System.Data.DataTable = _

m_TableCustomerInfo

Dim currentCustomerRow As System.Data.DataRow

For Each currentCustomerRow In dataTable_Customers.Rows

Dim currentCreditCard As String

'НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

currentCreditCard = CType( _

currentCustomerRow(m_TestColumn_CreditCard), _

String)

'Проверить, совпадает ли номер кредитной карточки

If (creditCardNumber = currentCreditCard) Then

'Изменить дату отъезда

'НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

Dim currentTravelDate As System.DateTime = CType( _

currentCustomerRow(m_TestColumn_TravelDate), _

System.DateTime)

If (currentTravelDate <> newTravelDate) Then

'НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать кэшированный индекс столбца!

currentCustomerRow(m_TestColumn_TravelDate) = _

newTravelDate

numberRecordsChanged = numberRecordsChanged + 1

End If

End If

Next

Return numberRecordsChanged 'Количество обновленных записей

End Function

'Событие щелчка на кнопке

Private Sub buttonRunTest_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonRunTest.Click

createDataSet()

cacheDataSetInfo()

'НИЗКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать поиск по строкам

changeDayOfTravel_test(testType.textColumnLookup)

'ЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать поиск по целочисленным индексам

changeDayOfTravel_test(testType.cachedIndexLookup)

'НАИЛУЧШАЯ ПРОИЗВОДИТЕЛЬНОСТЬ: Использовать поиск по объектам столбцов

changeDayOfTravel_test(testType.cachedColumnObject)

End Sub

Листинг 14.4. Результаты тестирования производительности при использовании пользовательского формата данных вместо объектов DataSet

'Определение размерных характеристик теста

Const DUMMY _ROWS_OF_DATA As Integer = 100

Const NUMBER_TEST_ITERATIONS As Integer = 500

Const TABLE_NAME_PASSENGERINFO As String = "CustomerTravelInfo"

Const TEST_CREDIT_CARD As String = "IvoCard-987-654-321-000"

Private m_data_creditCards() As String

Private m_data_names() As String

Private m_data_travelDates() As System.DateTime

'-------------------------------------------------------------

'Создает массив данных (вместо использования объектов DataSet)

'-------------------------------------------------------------

Private Sub createDataSet()

'=============================================

'1. Создать пространство для размещения данных

'=============================================

ReDim m_data_creditCards(DUMMY_ROWS_OF_DATA)

ReDim m_data_names(DUMMY_ROWS_OF_DATA)

ReDim m_data_travelDates(DUMMY_ROWS_OF_DATA)

'----------------------

'Добавить строки данных

'----------------------

Dim buildTestString As System.Text.StringBuilder

buildTestString = New System.Text.StringBuilder

Dim addItemsCount As Integer

For addItemsCount = 0 To DUMMY_ROWS_OF_DATA

'Выбрать день отъезда пассажира

m_data_travelDates(addItemsCount) = _

System.DateTime.Today.AddDays(addItemsCount)

'---------------------

'Выбрать имя пассажира

'---------------------

'Очистить строку

buildTestString.Length = 0

buildTestString.Append("TestPersonName")

buildTestString.Append(addItemsCount)

m_data_names(addItemsCount) = buildTestString.ToString()

'-------------------------------------------------------

'Связать с пассажиром текстовый номер кредитной карточки

'-------------------------------------------------------

'Строка значения третьего столбца набора данных

buildTestString.Length = 0

buildTestString.Append("IvoCard-000-000-0000-")

buildTestString.Append(addItemsCount)

m_data_creditCards(addItemsCount) = _

buildTestString.ToString()

Next

'Добавить элемент, поиск которого мы хотим выполнить в нашем тесте.

'Выбрать день для значения в первом столбце данных

m_data_travelDates(DUMMY_ROWS_OF_DATA) = _

System.DateTime.Today

'Строка для второго столбца данных

m_data_names(DUMMY_ROWS OF DATA) = "Ms. TestPerson"

'Строка с идентификатором кредитной карточки

m_data_creditCards(DUMMY_ROWS_OF_DATA) = TEST_CREDIT_CARD

End Sub

'---------------

'Выполнить тест.

'---------------

Sub changeDayOfTravel_test()

'Отобразить курсор ожидания

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.WaitCursor

'Начать с известной даты.

Dim newDate As System.DateTime newDate = System.DateTime.Today

changeDayOfTravel_CustomArrays(TEST_CREDIT_CARD, newDate)

'ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ!!!

'HE СЛЕДУЕТ использовать вызовы сборщика мусора в готовом программном

'коде. Это ЗАМЕДЛЯЕТ работу приложения.

System.GC.Collect()

Const testNumber As Integer = 0

'Запустить таймер теста

PerformanceSampling.StartSample(testNumber, "Custom Array implementation")

'Запустить тест!

Dim testCount As Integer

For testCount = 1 To NUMBER_TEST_ITERATIONS

'Передвинуть дату вперед на один день

newDate = newDate.AddDays(1)

Dim numberRecordsChanged As Integer

'Просмотреть все имена, используя СТРОКИ

numberRecordsChanged = _

changeDayOfTravel_CustomArrays(ТЕST_CREDIT_CARD, newDate)

'Убедиться в нормальном выполнении теста

If (numberRecordsChanged <> 1) Then

MsgBox("No matching records found. Test aborted!")

Return

End If

Next

'Получить время выполнения теста

PerformanceSampling.StopSample(testNumber)

'Обычный курсор

System.Windows.Forms.Cursor.Current = _

System.Windows.Forms.Cursors.Default

'Отобразить результаты теста

Dim runInfo As String = NUMBER_TEST_ITERATIONS.ToString() + _

"x" + DUMMY_ROWS_OF_DATA.ToString() + ": " MsgBox(runInfo + _

PerformanceSampling.GetSampleDurationText(testNumber))

End Sub

Private Function changeDayOfTravel_CustomArrays( _

ByVal creditCardNumber As String, ByVal newTravelDate _

As System.DateTime) As Integer

Dim numberRecordsChanged As Integer

'Просмотреть каждый элемент массива

Dim index As Integer

For index = 0 To DUMMY_ROWS_OF_DATA

Dim currentCreditCard As String

currentCreditCard = m_data_creditCards(index)

'Обновить запись при наличии совпадения

If (creditCardNumber = currentCreditCard) Then

'Изменить дату поездки

Dim currentTravelDate As System.DateTime = _

m_data_travelDates(index)

'Увеличить значение счетчика обновлений только при несовпадении данных

If (currentTravelDate <> newTravelDate) Then

m_data_travelDates(index) = _

newTravelDate

numberRecordsChanged = numberRecordsChanged + 1

End If

End If

Next

'Возвратить количество обновленных записей

Return numberRecordsChanged

End Function

Private Sub buttonRunTest_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonRunTest.Click

createDataSet()

changeDayOfTravel_test()

End Sub

Листинг 14.5. Пример пользовательского управления данными — код, помещаемый в форму Form1.cs

'Создает базу данных

Private Sub buttonCreateDatabase_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonCreateDatabase.Click

DatabaseAccess.CreateAndFillDatabase()

End Sub

'Загружает данные из базы данных и отображает их

Private Sub buttonLoadGameData_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonLoadGameData.Click

'Очистить текстовое окно

TextBox1.Text = ""

'Загрузить данные для слов

GameData.InitializeGameVocabulary()

'Обойти все слова и добавить их в текстовый список

Dim thisStringBuilder As System.Text.StringBuilder

thisStringBuilder = New System.Text.StringBuilder

Dim thisWord As VocabularyWord

For Each thisWord In GameData.AllWords

thisStringBuilder.Append(thisWord.EnglishWord)

thisStringBuilder.Append(" = ")

thisStringBuilder.Append( _

thisWord.GermanWordWithArticleIfExists)

thisStringBuilder.Append(vbCrLf) 'Новая строка

Next

'Отобразить список слов в текстовом окне

TextBox1.Text = thisStringBuilder.ToString()

End Sub

Листинг 14.6. Пример кода управления данными для DatabaseAccess.cs

Option Strict On

'----------------------------------------------------------

'Код доступа к базе данных: Этот класс управляет доступом в

'базу данных наших приложений

'----------------------------------------------------------

Imports System

Friend Class DatabaseAccess

Const DATABASE_NAME As String = "LearnGerman.sdf"

Const CONNECT_STRING As String = _

"Data Source = " + DATABASE_NAME + "; Password = ''"

Const TRANSLATIONTABLE_NAME As String = "TranslationDictionary"

Const TRANSLATIONTABLE_ENGLISH_COLUMN As String = "EnglishWord"

Const TRANSLATIONTABLE_GERMAN_COLUMN As String = "GermanWord"

Const TRANSLATIONTABLE_GERMANGENDER_COLUMN As String = "GermanGender"

Const TRANSLATIONTABLE_WORDFUNCTION_COLUMN As String = "WordFunction"

Friend Const DS_WORDS_COLUMNINDEX_ENGLISHWORD As Integer = 0

Friend Const DS_WORDS_COLUMNINDEX_GERMANWORD As Integer = 1

Friend Const DS_WORDS_COLUMNINDEX_GERMANGENDER As Integer = 2

Friend Const DS_WORDS_COLUMNINDEX_WORDFUNCTION As Integer = 3

Public Shared Function GetListOfWords() As _

System.Data.IDataReader

Dim conn As System.Data.SqlServerCe.SqlCeConnection = Nothing

conn = New System.Data.Sq]ServerCe.SqlCeConnection( _

CONNECT_STRING)

conn.Open()

Dim cmd As System.Data.SqlServerCe.SqlCeCommand = _

conn.CreateCommand()

cmd.CommandText = "select " + _

TRANSLATIONTABLE_ENGLISH_COLUMN + ", " _

+ TRANSLATIONTABLE_GERMAN_COLUMN + ", " _

+ TRANSLATIONTABLE_GERMANGENDER_COLUMN + ", " _

+ TRANSLATIONTABLE_WORDFUNCTION_COLUMN + " " _

+ "from " + TRANSLATIONTABLE_NAME

'Выполнить команду базы данных

Dim myReader As System.Data.SqlServerCe.SqlCeDataReader = _

cmd.ExecuteReader(System.Data.CommandBehavior.SingleResult)

Return myReader

End Function

'------------------------------------------

'Создает базу данных в случае необходимости

'------------------------------------------

Public Shared Sub CreateDatabaseIfNonExistant()

If (System.IO.File.Exists(DATABASE_NAME) = False) Then

CreateAndFillDatabase()

End If

End Sub

'---------------------------------------

'Создает и наполняет данными базу данных

'---------------------------------------

Public Shared Sub CreateAndFillDatabase()

'Удалить базу данных, если она уже существует

If (System.IO.File.Exists(DATABASE_NAME)) Then

System.IO.File.Delete(DATABASE_NAME)

End If

'Создать новую базу данных

Dim sqlCeEngine As System.Data.SqlServerCe.SqlCeEngine

sqlCeEngine = New System.Data.SqlServerCe.SqlCeEngine( _

CONNECT_STRING)

sqlCeEngine.CreateDatabase()

'-------------------------------------

'Попытаться подключиться к базе данных

'и наполнить ее данными

'-------------------------------------

Dim conn As System.Data.SqlServerCe.SqlCeConnection = Nothing

Try

conn = New System.Data.SqlServerCe.SqlCeConnection( _

CONNECT_STRING)

conn.Open()

Dim cmd As System.Data.SqlServerCe.SqlCeCommand = _

conn.CreateCommand()

'Создает таблицу перевода

'Поля:

' 1. Слова на английском языке (English)

' 2. Слова на немецком языке (German)

' 3. Грамматический род (Gender)

' 4. Тип слова

cmd.CommandText = "CREATE TABLE " + TRANSLATIONTABLE_NAME _

+ " (" + _

TRANSLATIONTABLE_ENGLISH_COLUMN + " ntext" + ", " + _

TRANSLATIONTABLE_GERMAN COLUMN + " ntext" + ", " + _

TRANSLATIONTABLE_GERMANGENDER_COLUMN + " int" + ", " + _

TRANSLATIONTABLE_WORDFUNCTION_COLUMN + " int" + ")"

cmd.ExecuteNonQuery()

'Наполнить базу данных словами

FillDictionary(cmd)

Catch eTableCreate As System.Exception

MsgBox("Error occured adding table :" + eTableCreate.ToString())

Finally

'Всегда закрывать базу данных по окончании работы

conn.Close()

End Try

'Информировать пользователя о создании базы данных

MsgBox("Created language database!")

End Sub

Private Shared Sub FillDictionary( _

ByVal cmd As System.Data.SqlServerCe.SqlCeCommand)

'Глаголы

InsertEnglishGermanWordPair(cmd, "to pay", "zahlen", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Verb)

InsertEnglishGermanWordPair(cmd, "to catch", "fangen", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Verb)

'Добавить другие слова.

'Местоимения

InsertEnglishGermanWordPair(cmd, "What", "was", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Pronoun)

'Добавить другие слова.

'Наречия

InsertEnglishGermanWordPair(cmd, "where", "wo", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Adverb)

InsertEnglishGermanWordPair(cmd, "never", "nie", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Adverb)

'Добавить другие слова.

'Предлоги

InsertEnglishGermanWordPair(cmd, "at the", "am", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Preposition)

'Имена прилагательные

InsertEnglishGermanWordPair(cmd, "invited", "eingeladen", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Verb)

InsertEnglishGermanWordPair(cmd, "yellow", "gelbe", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Adjective)

InsertEnglishGermanWordPair(cmd, "one", "eins", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Adjective)

InsertEnglishGermanWordPair(cmd, "two", "zwei", _

VocabularyWord.WordGender.notApplicable, _

VocabularyWord.WordFunction.Adjective)

'Имена существительные мужского рода

InsertEnglishGermanWordPair(cmd, "Man", "Mann", _

VocabularyWord.WordGender.Masculine, _

VocabularyWord.WordFunction.Noun)

InsertEnglishGermanWordPair(cmd, "Marketplace", "Marktplatz", _

VocabularyWord.WordGender.Masculine, _

VocabularyWord.WordFunction.Noun)

InsertEnglishGermanWordPair(cmd, "Spoon", "Löffel", _

VocabularyWord.WordGender.Masculine, _

VocabularyWord.WordFunction.Noun)

'Имена существительные женского рода

InsertEnglishGermanWordPair(cmd, "Woman", "Frau", _

VocabularyWord.WordGender.Feminine, _

VocabularyWord.WordFunction.Noun)

InsertEnglishGermanWordPair(cmd, "Clock", "Uhr", _

VocabularyWord.WordGender.Feminine, _

VocabularyWord.WordFunction.Noun)

InsertEnglishGermanWordPair(cmd, "Cat", "Katze", _

VocabularyWord.WordGender.Feminine, _

VocabularyWord.KordFunction.Noun)

'Имена существительные среднего рода

InsertEnglishGermanWordPair(cmd, "Car", "Auto", _

VocabularyWord.WordGender.Neuter, _

VocabularyWord.WordFunction.Noun)

InsertEnglishGermanWordPair(cmd, "Book", "Buch", _

VocabularyWord.WordGender.Neuter, _

VocabularyWord.WordFunction.Noun)

End Sub

'----------------------------

'Помещает слово в базу данных

'----------------------------

Private Shared Sub InsertEnglishGermanWordPair( _

ByVal cmd As System.Data.SqlServerCe.SqlCeCommand, _

ByVal englishWord As String, ByVal germanWord As String, _

ByVal germanWordGender As VocabularyWord.WordGender, _

ByVal wordFunction As VocabularyWord.WordFunction)

cmd.CommandText = "INSERT INTO " + TRANSLATIONTABLE NAME + _

"(" + TRANSLATIONTABLE_ENGLISH_COLUMN + ", " + _

TRANSLATIONTABLE_GERMAN_COLUMN + ", " + _

TRANSLATIONTABLE_GERMANGENDER_COLUMN + ", " + _

TRANSLATIONTABLE_WORDFUNCTION_COLUMN + _

") VALUES ('" _

+ englishWord + "', '" + germanWord + "', '" _

+ System.Convert.ToString(CType(germanWordGender, Integer)) + "', '"

+ System.Convert.ToString(CType(wordFunction, Integer)) + "')"

cmd.ExecuteNonQuery()

End Sub

End Class

Листинг 14.7. Пример кода управления данными для GameData.cs

Option Strict On

'-----------------------------------------------------------------

'Код управления данными в памяти

'

'Этот код предназначен для управления представлением кода в памяти

'-----------------------------------------------------------------

Imports System

Friend Class GameData

'Массив списков для сохранения загружаемых данных

Private Shared m_vocabularyWords_All As _

System.Collections.ArrayList

Private Shared m_vocabularyWords_Nouns As _

System.Collections.ArrayList

Private Shared m_vocabularyWords Verbs As _

System.Collections.ArrayList

Private Shared m_vocabularyWords_Adjectives As _

System.Collections.ArrayList

Private Shared m_vocabularyWords Adverbs As _

System.Collections.ArrayList

Private Shared m_vocabularyWords_Prepositions As _

System.Collections.ArrayList

Public Shared ReadOnly Property _

isGameDataInitialized() As Boolean

Get

'Инициализация данных игры, если слова загружены

Return Not (m_vocabularyWords_All Is Nothing)

End Get

End Property

'Возвращает коллекцию всех имеющихся слов

Public Shared ReadOnly Property _

AllWords() As System.Collections.ArrayList

Get

'Загрузить данные, если они не были инициализированы

If (m_vocabularyWords_All Is Nothing) Then

InitializeGameVocabulary()

End If

Return m_vocabularyWords_All

End Get

End property

'Возвращает коллекцию всех имеющихся имен существительных

Public Shared ReadOnly Property _

Nouns() As System.Collections.ArrayList

Get

'Загрузить данные, если они не были инициализированы

If (m_vocabularyWords_Nouns Is Nothing) Then

InitializeGameVocabulary()

End If

Return m_vocabularyWords_Nouns

End Get

End Property

'==========================================================

'Загружает данные из нашей базы данных

'==========================================================

Public Shared Sub InitializeGameVocabulary()

'Создать новый массив списков для хранения наших слов

m_vocabularyWords_All = New System.Collections.ArrayList

m_vocabularyWords_Nouns = New System.Collections.ArrayList

m_vocabularyWords_Verbs = New System.Collections.ArrayList

m_vocabularyWords_Adjectives = _

New System.Collections.ArrayList

m_vocabularyWords Adverbs = _

New System.Collections.ArrayList

m_vocabularyWords_Prepositions = _

New System.Collections.ArrayList

Dim dataReader As System.Data.IDataReader

dataReader = DatabaseAccess.GetListOfWords()

Dim newWord As VocabularyWord

'Обойти все записи

While (dataReader.Read())

Dim thisword_gender As VocabularyWord.WordGender

Dim thisword_function As VocabularyWord.WordFunction

thisword_gender = CType(dataReader.GetInt32( _

DatabaseAccess.DS_WORDS_COLUMNINDEX_GERMANGENDER), _

VocabularyWord.WordGender)

thisword_function = CType(dataReader.GetInt32( _

DatabaseAccess.DS_WORDS_COLUMNINDEX_WORDFUNCTION), _

VocabularyWord.WordFunction)

'Поместить данные для только что считанного слова в класс

newWord = New VocabularyWord(dataReader.GetString( _

DatabaseAccess.DS_WORDS_COLUMNINDEX_ENGLISHWORD), dataReader.GetString( _

DatabaseAccess.DS_WORDS_COLUMNINDEX_GERMANWORD), _

thisword_gender, thisword_function)

'Добавить новое слово в массив списков

m_vocabularyWords_All.Add(newWord)

'Слова могут принадлежать нескольким группам, поэтому

'необходимо выполнить проверку с использованием операции логического И

'для проверки того, что слово относится к данной категории

If ((newWord.getWordFunction And _

VocabularyWord.WordFunction.Noun) <> 0) Then

m_vocabularyWords_Nouns.Add(newWord)

End If

If ((newWord.getWordFunction And _

VocabularyWord.WordFunction.Verb) <> 0)

Then m_vocabularyWords_Verbs.Add(newWord)

End If

If ((newWord.getWordFunction And _

VocabularyWord.WordFunction.Adjective) <> 0) Then

m_vocabularyWords_Adjectives.Add(newWord)

End If

If ((newWord.getWordFunction And _

VocabularyWord.WordFunction.Adverb) <> 0) Then

m_vocabularyWords_Adverbs.Add(newWord)

End If

If ((newWord.getWordFunction And _

VocabularyWord.WordFunction.Preposition) <> 0) Then

m_vocabularyWords_Prepositions.Add(newWord)

End If

End While

'Закрыть объект DataReader

dataReader.Close()

End Sub

End Class

Листинг 14.8. Пример кода управления данными для VocabularyWord.cs

Option Strict On

Imports System

'------------------------------

'Хранит данные слова из словаря

'------------------------------

Friend Class VocabularyWord

<System.FlagsAttribute()> _

Public Enum WordFunction

Noun = 1

Verb = 2

Pronoun = 4

Adverb = 8

Adjective = 16

Preposition = 32

Phrase = 64

End Enum

Public Enum WordGender

notApplicable = 0

Masculine = 1

Feminine = 2

Neuter = 3

End Enum

Private m_englishWord As String

Private m_germanWord As String

Private m_germanGender As VocabularyWord.WordGender

Private m_wordFunction As VocabularyWord.WordFunction

Public ReadOnly Property EnglishWord() As String

Get

Return m_englishWord

End Get

End Property

Public ReadOnly Property GermanWord() As String

Get

Return m_germanWord

End Get

End Property

Public ReadOnly Property getWordFunction() As WordFunction

Get

Return m_wordFunction

End Get

End Property

Public ReadOnly Property getWordGender() As WordGender

Get

Return m_germanGender

End Get

End Property

'-----------------------------------------------------------------

'Возвращает слово на немецком языке, которому предшествует артикль

'(например, 'der', 'die', 'das'), если он существует

'-----------------------------------------------------------------

Public ReadOnly Property GermanWordWithArticleIfExists() As String

Get

If (m_germanGender = WordGender.notApplicable) Then

Return Me.GermanWord

End If

Return Me.GenderArticle + " " + Me.GermanWord

End Get

End Property

Public ReadOnly Property GenderArticle() As String

Get

Select Case (m_germanGender)

Case WordGender.Masculine

Return "der"

Case WordGender.Feminine

Return "die"

Case WordGender.Neuter

Return "das"

End Select

Return ""

End Get

End Property

Public Sub New(ByVal enlgishWord As String, ByVal germanWord _

As String, ByVal germanGender As WordGender, _

ByVal wordFunction As WordFunction)

m_englishWord = enlgishWord

m_germanWord = germanWord

m_germanGender = germanGender

m_wordFunction = wordFunction

End Sub

End Class

Примеры к главе 15 (передача данных)

Листинг 15.1. Простой код файлового ввода-вывода, иллюстрирующий различия между локальной и удаленной передачей данных

Этот код представляет собой всего лишь последовательность вызовов функций. Программистам на VB будет несложно написать его, используя в качестве образца код на C#.

Листинг 15.2. Имитация сбоев при передаче данных для тестирования приложения

'Флаги условной компиляции для нашего инструментированного кода

#Const DEBUG_SIMULATE_FAILURES = 1 'Имитировать сбои

'#Const DEBUG_SIMULATE_FAILURES = 0 'Не имитировать сбои

'-----------------------------------------------------------------

'Глобальная переменная, которую мы хотим использовать для указания

'необходимости генерации исключений в процессе передачи данных

'-----------------------------------------------------------------

#If DEBUG_SIMULATE_FAILURES <> 0 Then

'Переменная для хранения информация о следующем сбое

Shared g_failureCode As SimulatedFailures = _

SimulatedFailures.noFailurePending

'Список сбоев, которые мы хотим имитировать

public enum SimulatedFailures

noFailurePending 'No test failures pending

'Имитируемые сбои:

failInNextWriteSocketCode

failInNextWebServiceCall

failInNextFileIODuringFileOpen

failInNextFileIODuringFileRead

'и так далее

End Enum

#End If 'DEBUG_SIMULATE_FAILURES

'---------------------------------------------------

'Функция, которую мы используем для передачи данных.

'---------------------------------------------------

Private Sub writeDataToSocket( _

ByVal mySocket As System.Net.Sockets.Socket, _

ByVal dataToSend() As Byte)

'------------------------------------------------------------------

'Этот код следует компилировать лишь при тестировании сетевых сбоев

'------------------------------------------------------------------

#If DEBUG_SIMULATE_FAILURES <> 0 Then

'Если это сбой, который мы хотим тестировать, генерировать исключение

If (g_failureCode = _

SimulatedFailures.failInNextWriteSocketCode) Then

'Сбросить этот сбой, чтобы он не возник

'при следующем вызове этой функции

g_failureCode = SimulatedFailures.noFailurePending

Throw New Exception("Test communications failure: " + _

g_failureCode.ToString())

End If

#End If

'Передать данные обычным образом.

mySocket.Send(dataToSend)

End Sub

Листинг 15.3. Тестовый код, который необходимо поместить в класс формы для тестирования передачи и приема данных посредством механизма IrDA

'Имя, которое мы хотим присвоить сокету IrDA

Const myIrDASocketName As String = "IrDaTestFileTransmit"

Private Sub buttonTestFileSend_Click(ByVal sender As Object, _

ByVal e As System.EventArgs) Handles buttonTestFileSend.Click

'Создать простой текстовый файл, который мы хотим передать

Const fileName As String = "\myTestSendFile.txt"

Dim textFileStream As System.IO.StreamWriter

textFileStream = System.IO.File.CreateText(fileName)

textFileStream.WriteLine("Today...")

textFileStream.WriteLine("is а nice day")

textFileStream.WriteLine("to go swim")

textFileStream.WriteLine("in the lake")

textFileStream.Close()

Dim irdaFileSender As IrDAFileSend

irdaFileSender = New IrDAFileSend(fileName, myIrDASocketName)

'Имеется 2 режима: 1 - Sync (синхронный), 2 — Async (асинхронный)

'1. Вызвать функцию в синхронном режиме

'и блокировать поток выполнения до тех пор,

'пока файл не будет передан

'1a. Информировать пользователя о том, что мы пытаемся передать данные

Me.Text = "Trying to send..."

'Подождать, пока клиент не будет найден, а затем передать файл

irdaFileSender.LoopAndAttemptIRSend()

'1c. Информировать пользователя о том, что файл передан

MsgBox("File sent!")

Me.Text = "IrDA: Sent!"

'2. Вызвать функцию в асинхронном режиме и поручить

'передачу файла фоновому потоку

'irdaFileSend.LoopAndAttemptIRSendAsync()

'ПРИМЕЧАНИЕ: Если мы вызываем функцию в асинхронном режиме, то должны

'периодически проверять, не завершила ли она выполнение, путем

'вызова метода 'irdaFileSend.Status'

End Sub

Private Sub buttonTestFileReceive_Click(ByVal sender As Object, _

ByVal e As EventArgs) Handles buttonTestFileReceive.Click

'Если файл назначения уже существует, уничтожить его

Const fileName As String = "\myTestReceiveFile.txt"

If (System.IO.File.Exists(fileName)) Then

System.IO.File.Delete(fileName)

End If

Dim irdaFileReceiver As IrDAFileReceive

irdaFileReceiver = New IrDAFileReceive(fileName, _

myIrDASocketName)

'Имеется 2 режима: 1 — Sync (синхронный), 2 - Async (асинхронный)

'1. Вызвать функцию в синхронном режиме

' блокировать поток выполнения до тех пор, пока

'файл не будет получен

'1a. Информировать пользователя о том, что мы ожидаем получения файла

Me.Text = "Waiting to receive..."

'1b. Ожидать, пока не будет сделана попытка установления с нами связи

'и передачи файла

irdaFileReceiver.WaitForIRFileDownload()

'1с. Информировать пользователя о том, что мы получили переданный файл

Me.Text = "IrDA: received!"

MsgBox("File received!")

'2. Вызвать функцию в асинхронном режиме и поручить

'получение файла фоновому потоку

'irdaFileReceive.WaitForIRFileDownloadAsync()

'ПРИМЕЧАНИЕ: Если мы вызываем функцию в асинхронном режиме, то должны

'периодически проверять, не завершила ли она выполнение, путем

'вызова метода 'irdaFileReceive.Status'

End Sub

Листинг 15.4. Класс IrDAFileSend

Option Strict On

'====================================================================

'Этот класс является клиентом IrDA. Он осуществляет поиск сервера

'IrDA, имя которого совпадает с именем службы IrDA, и после того, как

'он найден, направляет ему поток данных файла,

'====================================================================

Class IrDAFileSend

Private m_descriptionOfLastSendAttempt As String

Private m_IrDAServiceName As String

Private m_fileToSend As String

Private m_wasSenderStopped As Boolean

Public Enum SendStatus

AttemptingToSend

Finished_Successfully

Finished_Aborted

Finished_Error

End Enum

Private m_SendStatus As SendStatus

Public ReadOnly Property Status() As SendStatus

Get

'Блокировка выполнения параллельных операций чтения/записи в m_SendStatus

SyncLock (Me)

Return m_SendStatus

End SyncLock

End Get

End Property

Private Sub setStatus(ByVal newStatus As SendStatus)

'Блокировка выполнения параллельных операций чтения/записи в m SendStatus

SyncLock (Me)

m_SendStatus = newStatus

End SyncLock

End Sub

Public ReadOnly Property ErrorText() As String

Get

Return m_descriptionOfLastSendAttempt

End Get

End Property

'-----------

'КОНСТРУКТОР

'-----------

Public Sub New(ByVal fileToSend As String, ByVal irdaServiceName As String)

'Имя сокета IrDA, поиск которого мы хотим осуществить

m_IrDAServiceName = irdaServiceName

'Файл, который мы хотим передать

m_fileToSend = fileToSend

End Sub

'--------------------------------------------------------------

'Запускает новый поток для осуществления попытки отправки файла

'--------------------------------------------------------------

Public Sub LoopAndAttemptIRSendAsync()

'Мы находимся в режиме передачи

setStatus(SendStatus.AttemptingToSend)

'Пользователь пока что не отменил выполнение операции

m_wasSenderStopped = False

'Это функция, которую должен запустить на выполнение новый поток

Dim threadEntryPoint As System.Threading.ThreadStart

threadEntryPoint = _

New System.Threading.ThreadStart(AddressOf LoopAndAttemptIRSend)

'-----------------------------------

'Создать новый поток и запустить его

'-----------------------------------

Dim newThread As System.Threading.Thread = _

New System.Threading.Thread(threadEntryPoint)

newThread.Start()

'Вперед!

End Sub

'-----------------------------------------------------

'Входит в цикл и пытается передать файл посредством IR

'-----------------------------------------------------

Public Sub LoopAndAttemptIRSend()

Dim irDASender As System.Net.Sockets.IrDAClient

Dim streamOutToIrDA As System.IO.Stream

Dim streamInFromFile As System.IO.Stream

'Пользователь пока что не отменил выполнение операции

m_wasSenderStopped = False

setStatus(SendStatus.AttemptingToSend)

'-----------------------------------------------------------------

'Непрерывное выполнение цикла, пока не удастся отправить сообщение

'-----------------------------------------------------------------

While (True)

'Значения всех этих переменных должны быть нулевыми до и после

'вызова sendStream(...), если не было сгенерировано исключение!

irDASender = Nothing

streamOutToIrDA = Nothing

streamInFromFile = Nothing

'Попытаться передать поток

Dim bSuccess As Boolean

Try

bSuccess = sendStream(mjdescriptionOfLastSendAttempt, _

streamOutToIrDA, irDASender, streamInFromFile)

Catch eUnexpected As System.Exception 'Неожиданная ошибка!!!

setStatus(SendStatus.Finished_Error) 'Уведомить о сбое

m_descriptionOfLastSendAttempt = _

"Unexpected error in IR send loop. " + eUnexpected.Message

'------------------------------------------------

'Освободить все распределенные нами ранее ресурсы

'------------------------------------------------

If Not (streamOutToIrDA Is Nothing) Then

Try

streamOutToIrDA.Close()

Catch

'Поглотить любую ошибку

End Try

streamOutToIrDA = Nothing

End If

If Not (streamInFromFile Is Nothing) Then

Try

streamInFromFile.Close()

Catch

'Поглотить любую ошибку

End Try

streamInFromFile = Nothing

End If

If Not (irDASender Is Nothing) Then

Try

irDASender.Close()

Catch

'Поглотить любую ошибку

End Try

irDASender = Nothing

End If

Return 'Выход

End Try

'Проверить успешность выполнения

If (bSuccess = True) Then

m_descriptionOfLastSendAttempt = "Success!"

setStatus(SendStatus.Finished Successfully)

Return

End If

'Проверить, не была ли операция отменена пользователем

If (m_wasSenderStopped = True) Then

m_descriptionOfLastSendAttempt = "User Aborted."

setStatus(SendStatus.Finished_Aborted)

Return

End If

'В противном случае... Нам пока не удалось обнаружить сервер IrDA,

'имя которого совпадает с именем службы. Мы продолжим выполнение цикла

'и попытаемся найти сервер.

End While

'Мы никогда не попадем в это место программы при выполнении

End Sub

'----------------------------------------------------------------------

'Попытаться передать поток ввода-вывода (например, файл) посредством IR

'[возвращаемое значение]:

' true: успешная передача файла

' false: файл не был успешно передан

'----------------------------------------------------------------------

Private Function sendStream(ByRef errorDescription As String, _

ByRef streamOutToIrDA As System.IO.Stream, _

ByRef irDASender As System.Net.Sockets.IrDAClient, _

ByRef streamInFromFile As System.IO.Stream) As Boolean

errorDescription = ""

'----------------------------

'Создание нового клиента IRDA

'----------------------------

Try

'-------------------------------------------------------

'Возврат произойдет довольно быстро. Клиент будет выбран

'и возвращен, если прослушивающие клиенты отсутствуют.

'-------------------------------------------------------

irDASender = _

New System.Net.Sockets.IrDAClient(m_IrDAServiceName)

Catch eCreateClient As System.Exception

'В данном случае могли возникнуть несколько ситуаций:

'#1: отсутствуют прослушивающие устройства

'#2: прослушивающее устройство существует, но не реагирует

' (может отказаться от разговора)

errorDescription = eCreateClient.Message

Return False

End Try

'В данном случае могли возникнуть несколько ситуаций:

'#1: Мы получили соединение от приемного устройства IR

'#2: IR-запрос был отменен (кто-то вызвал функцию STOP).

If (m_wasSenderStopped = True) Then

irDASender.Close()

irDASender = Nothing

Return False

End If

'==========================================

'ПЕРЕДАТЬ ДАННЫЕ!

'==========================================

'Открыть файл, который мы хотим передать

streamInFromFile = System.IO.File.OpenRead(m_fileToSend)

'Открыть сокет IrDA, которому мы хотим передать данные

streamOutToIrDA = irDASender.GetStream()

Const BUFFER_SIZE As Integer = 1024

Dim inBuffer() As Byte

ReDim inBuffer(BUFFER_SIZE)

Dim bytesRead As Integer

Dim iTestAll As Integer

Dim iTestWrite As Integer

' Цикл...

Do

'Считать байты из файла

bytesRead = streamInFromFile.Read(inBuffer, 0, BUFFER_SIZE)

iTestAll = iTestAll + 1

'Записать байты в наш выходной поток

If (bytesRead > 0) Then

streamOutToIrDA.Write(inBuffer, 0, bytesRead)

iTestWrite = iTestWrite + 1

End If

Loop While (bytesRead > 0)

'Сбросить выходной поток

streamOutToIrDA.Flush() 'Закончить запись любых данных

streamOutToIrDA.Close() 'Закрыть поток

streamOutToIrDA = Nothing

'Освободить локальный файл

streamInFromFile.Close()

streamOutToIrDA = Nothing

'Освободить порт IrDA

irDASender.Close()

irDASender = Nothing

'Успешное завершение!!!

Return True

End Function

End Class

Листинг 15.5. Класс IrDAFileReceive

'-------------------------------------------------------------------

'Обеспечивает прием файла через IrDA (инфракрасный порт)

'Этот класс НЕ является реентерабельным и не должен вызываться более

'чем одной функцией за один раз. Если необходимо иметь несколько

'сеансов связи через IR, это необходимо делать путем создания

'нескольких различных экземпляров данного класса.

'--------------------------------------------------------------------

Public Class IrDAFileReceive

Private m_wasListenerStopped As Boolean

Private m_IrDAServiceName As String

Private m_fileNameForDownload As String

Private m_errorDurmgTransfer As String

Private m_irListener As System.Net.Sockets.IrDAListener

Private m ReceiveStatus As ReceiveStatus

Public ReadOnly Property ErrorText() As String

Get

Return m_errorDuringTransfer

End Get

End Property

'--------------------------

'Различные состояния приема

'--------------------------

Public Enum ReceiveStatus

NotDone_SettingUp

NotDone_WaitingForSender

NotDone_Receiving

Done_Success

Done_Aborted

Done_ErrorOccured

End Enum

'------------------------------

' Возвращает состояние передачи

'------------------------------

Public ReadOnly Property Status() As ReceiveStatus

Get

SyncLock (Me)

Return m_ReceiveStatus

End SyncLock

End Get

End Property

Private Sub setStatus(ByVal newStatus As ReceiveStatus)

'Обеспечить многопоточную безопасность для предотвращения

'параллельного выполнения операций чтения/записи

SyncLock (Me)

m_ReceiveStatus = newStatus

End SyncLock 'end lock

End Sub

'--------------------------------------------------

' (in) filename: желаемое имя для входного файла IR

'--------------------------------------------------

Public Sub New(ByVal filename As String, ByVal irdaServiceName As String)

'Имя сокета IrDA, который мы хотим открыть

m_IrDAServiceName = irdaServiceName

'Имя файла, в котором мы хотим сохранить полученные данные

m_fileNameForDownload = filename

End Sub

'----------------------------------------------------------

'Обеспечивает асинхронный прием файла через IR

' (in) filename: имя файла, в который осуществляется запись

'----------------------------------------------------------

Public Sub WaitForIRFileDownloadAsync()

'Заметьте, что сейчас мы находимся в режиме подготовки

setStatus(ReceiveStatus.NotDone_SettingUp)

'-------------------

'Создать новый поток

'-------------------

Dim threadEntryPoint As System.Threading.ThreadStart

threadEntryPoint = _

New System.Threading.ThreadStart(AddressOf WaitForIRFileDownload)

Dim newThread As System.Threading.Thread = _

New System.Threading.Thread(threadEntryPoint)

'Запустить поток на выполнение

newThread.Start()

End Sub

'------------------------------------------

'Открывает порт IR и ожидает загрузки файла

'------------------------------------------

Public Sub WaitForIRFileDownload()

Dim outputStream As System.IO.Stream

Dim irdaClient As System.Net.Sockets.IrDAClient

Dim irStreamIn As System.IO.Stream

Try

'=========================================================

'Задать и загрузить файл!

'=========================================================

internal_WaitForIRFileDownload(outputStream, irdaClient, irStreamIn)

Catch 'Поглотить любые возникающие ошибки

setStatus(ReceiveStatus.Done_ErrorOccured)

End Try

'=============================================

'Освободить все ресурсы

'=============================================

'Закрыть наш входной поток

If Not (irStreamIn Is Nothing) Then

Try

irStreamIn.Close()

Catch 'Поглотить любые возникающие ошибки

End Try

End If

'Закрытие клиента IrDA

If Not (irdaClient Is Nothing) Then

Try

irdaClient.Close()

Catch 'Поглотить любые возникающие ошибки

End Try

End If

'Закрыть файл, в который осуществлялась запись

If Not (outputStream Is Nothing) Then

Try

outputStream.Close()

Catch 'Поглотить любые возникающие ошибки

End Try

End If

'Закрыть прослушивающее устройство, если оно выполняется

If Not (m_irListener Is Nothing) Then

'Установить первым, чтобы код, выполняющийся другим потоком,

'был отменен, если он установлен

m_wasListenerStopped = True

Try

m_irListener.Stop()

Catch 'Поглотить любые возникающие ошибки

End Try

m_irListener = Nothing

End If

End Sub

Private Sub internal_WaitForIRFileDownload( _

ByRef outputStream As System.IO.Stream, _

ByRef irdaClient As System.Net.Sockets.IrDAClient, _

ByRef irStreamIn As System.IO.Stream)

'---------------------------------------------------------

'Открыть входной файл для направления в него потока данных

'---------------------------------------------------------

outputStream = System.IO.File.Open( _

m_fileNameForDownload, _

System.IO.FileMode.Create)

'==========================================

'ОБНОВЛЕНИЕ СОСТОЯНИЯ

'==========================================

setStatus(ReceiveStatus.NotDone_WaitingForSender)

'---------------------------------

'Открыть прослушивающее устройство

'---------------------------------

Try

m_wasListenerStopped = False

m_irListener = _

New System.Net.Sockets.IrDAListener(m_IrDAServiceName)

m_irListener.Start()

Catch eListener As System.Exception

m_errorDuringTransfer = "Error creating listener - " + _

eListener.Message

GoTo exit_sub_with_error

End Try

'Проверить, не поступила ли команда отменить выполнение

If (m_wasListenerStopped = True) Then

GoTo exit_sub_with_abort

End If

'------------------

'Принять соединение

'------------------

Try

'--------------------------------------------------------------------

'Выполнение будет приостановлено здесь до тех пор, пока устройство не

'начнет передавать информацию, или не будет остановлен объект

'прослушивания, выполняющийся в другом потоке)

'--------------------------------------------------------------------

irdaClient = m_irListener.AcceptIrDAClient()

Catch eClientAccept As System.Exception

'Если прослушивание остановлено другим потоком, инициировавшим отмену

'выполнения, будет сгенерировано исключение и управление будет

'передано сюда.

If (m_wasListenerStopped = True) Then

GoTo exit_sub_with_abort

End If

'Если прослушивание не было прекращено,

'то произошло иное исключение. Обработать его.

m_errorDuringTransfer = "Error accepting connection - " + _

eClientAccept.Message

GoTo exit_sub_with_error

End Try

'В этом месте возможны два состояния:

'#1: Мы получили соединение от передающего устройства IR

'#2: IR-запрос был отменен (кто-то вызвал функцию STOP)

' (в этом случае приведенный ниже код сгенерирует исключение)

'Проверить, не было ли отменено выполнение

If (m_wasListenerStopped = True) Then

GoTo exit_sub_with_abort

End If

'==========================================

'ОБНОВЛЕНИЕ СОСТОЯНИЯ

'==========================================

setStatus(ReceiveStatus.NotDone_Receiving)

'-------------------------

'Открыть принимающий поток

'-------------------------

Try

irStreamIn = irdaClient.GetStream()

Catch exGetInputStream As System.Exception

m_errorDuringTransfer = "Error getting input stream - " + _

exGetInputStream.Message

GoTo exit_sub_with_error

End Try

'Приготовиться к получению данных!

Const BUFFER_SIZE As Integer = 1024

Dim inBuffer() As Byte

ReDim inBuffer(BUFFER_SIZE)

Dim bytesRead As Integer

Do

'Считать байты из порта IR

bytesRead = irStreamIn.Read(inBuffer, 0, BUFFER_SIZE)

'Записать байты в наш выходной поток

If (bytesRead > 0) Then

outputStream.Write(inBuffer, 0, bytesRead)

End If

Loop While (bytesRead > 0)

outputStream.Flush() 'Закончить запись любых выходных данных

'==========================================

'ОБНОВЛЕНИЕ СОСТОЯНИЯ: УСПЕШНО ВЫПОЛНЕНО

'==========================================

setStatus(ReceiveStatus.Done_Success)

Return 'No errors

'==========================================

'ОШИБКА.

'==========================================

exit_sub_with_abort:

'ОБНОВЛЕНИЕ СОСТОЯНИЯ: Отменено (но не из-за ошибки)

setStatus(ReceiveStatus.Done_Aborted)

Return

exit_sub_with_error:

'ОБНОВЛЕНИЕ СОСТОЯНИЯ: ОШИБКА!!!!

setStatus(ReceiveStatus.Done_ErrorOccured)

End Sub

End Class

Листинг 15.6. Простая Web-служба

'Этот код следует вставить в класс Service1, содержащийся

'в файле "Service1.asmx.vb".

'"[WebMethod]" - это атрибут метаданных, который указывает механизму

'Web-службы на то, что данный метод должен быть доступным через Web

<WebMethod()> _

Public Function AddTwoNumbers(ByVal x As Integer, _

ByVal у As Integer) As Integer

Return x + у

End Function

Листинг 15.7. Вызовы Web-служб с передачей параметров только явным образом

Этот код представляет собой всего лишь последовательность вызовов функций. Программистам на VB будет несложно написать его, используя в качестве образца код на С#.

Листинг 15.8. Вызов Web-служб путем неявной передачи параметров посредством cookie-файлов

Этот код представляет собой всего лишь последовательность вызовов функций. Программистам на VB будет несложно написать его, используя в качестве образца код на С#.

Листинг 15.9. Неэффективная организация диалога с Web-службой, в которой используется множество вызовов

Этот код представляет собой всего лишь последовательность вызовов функций. Программистам на VB будет несложно написать его, используя в качестве образца код на С#.

Листинг 15.10. Группирование запросов в одном вызове Web-службы

Этот код представляет собой всего лишь последовательность вызовов функций. Программистам на VB будет несложно написать его, используя в качестве образца код на С#.

Листинг 15.11. Код для загрузки файла с Web-сервера

'----------------------------------------------------------

'Осуществляет синхронную загрузку файла с Web-сервера

'и сохраняет его в локальной файловой системе

'[in] httpWhereFrom: URL-адрес файла

' (например, "http://someserver/somefile.jpg")

'[in] filenameWhereTo: Место, куда необходимо записать файл

' (например, "\\localfile.jpg")

'----------------------------------------------------------

Public Sub downloadFileToLocalStore(ByVal httpWhereFrom As _

String, ByVal filenameWhereTo As String)

Dim myFileStream As System.IO.FileStream = Nothing

Dim myHTTPResponseStream As System.IO.Stream = Nothing

Dim myWebRequest As System.Net.WebRequest = Nothing

Dim myWebResponse As System.Net.WebResponse = Nothing

'Если файл, который мы хотим записать, уже существует, удалить его

If (System.IO.File.Exists(filenameWhereTo) = True) Then

System.IO.File.Delete(filenameWhereTo)

End If

Try

'Создать Web-запрос

myWebRequest = _

System.Net.HttpWebRequest.Create(httpWhereFrom)

'Получить ответ

myWebResponse = myWebRequest.GetResponse()

'Получить поток для ответа

myHTTPResponseStream = myWebResponse.GetResponseStream()

'Создать локальный файл, в который необходимо направить поток ответа

myFileStream = System.IO.File.OpenWrite(filenameWhereTo)

'Этот размер буфера является настраиваемым

Const buffer_length As Integer = 4000

Dim byteBuffer() As Byte

ReDim byteBuffer(buffer_length)

Dim bytesIn As Integer

'Считать файл и направить поток данных в локальный файл

Do

'Считать данные

bytesIn = myHTTPResponseStream.Read(byteBuffer, _

0, buffer_length)

'Записать данные

If (bytesIn <> 0) Then

myFileStream.Write(byteBuffer, 0, bytesIn)

End If

Loop While (bytesIn <> 0)

Catch myException As Exception 'Сбой при загрузке!

'Что-то случилось. Освободить ресурс

attemptCleanup ThrowNoExceptions(myFileStream, _

myHTTPResponseStream, myWebResponse)

'Теперь, когда ресурс освобожден, повторно сгенерируем исключение,

'чтобы сообщить приложению о том, что произошел сбой!

Throw myException

End Try

'Загрузка прошла успешно!

'Закрыть все ресурсы.

Try

'Стандартная процедура закрытия ресурсов.

myFileStream.Close()

myFileStream = Nothing

myHTTPResponseStream.Close()

myHTTPResponseStream = Nothing

myWebResponse.Close()

myWebResponse = Nothing

Catch myException As Exception 'Сбой в процессе закрытия ресурса!

'Что-то случилось. Освободить ресурс

attemptCleanup_ThrowNoExceptions(myFileStream, _

myHTTPResponseStream, myWebResponse)

'Теперь, когда ресурс освобожден, повторно сгенерируем исключение,

'чтобы сообщить приложению о том, что произошел сбой!

Throw myException

End Try

'Успешное выполнение!

End Sub

'----------------------------------------------

'Пытается закрыть и освободить все объекты

'Перехватывает любое вырабатываемое исключение.

'----------------------------------------------

Sub attemptCleanup_ThrowNoExceptions( _

ByVal myFileStream As System.10.FileStream, _

ByVal myHTTPResponseStream As System.IO.Stream, _

ByVal myWebResponse As System.Net.WebResponse)

If Not (myFileStream Is Nothing) Then

Try

myFileStream.Сlose()

Catch 'He выполнять никаких действий.

End Try

End If

If Not (myHTTPResponseStream Is Nothing) Then

Try

myHTTPResponseStream.Close()

Catch 'He выполнять никаких действий.

End Try

End If

If Not (myWebResponse Is Nothing) Then

Try

myWebResponse.Close()

Catch 'He выполнять никаких действий.

End Try

End If

End Sub

Примечания

1

Caveat emptor (лат.) — пусть покупатель будет бдителен.

Content

Салмре Иво Программирование мобильных устройств на платформе .NET Compact Framework

Об авторе

Предисловие

Мобильные устройства на наших глазах претерпевают революционные изменения

Чего в наши дни не хватает большинству технических книг?

Что нового в этой книге?

На кого рассчитана эта книга?

Благодарности

От издательства

ГЛАВА 1 Введение

Добро пожаловать в мир разработки мобильного программного обеспечения

Успех определяется несколькими ключевыми факторами

Как читать эту книгу

Способы разработки программ для мобильных устройств

Серверные приложения для мобильных устройств

Мобильные приложения на основе модели интеллектуального клиента

Управляемый код

.NET Compact Framework — среда выполнения управляемого кода для устройств

Резюме

ГЛАВА 2  Характеристики мобильных приложений

Введение

Распространенные схемы использования мобильных устройств

Долговременные и кратковременные виды деятельности

Исследовательские и целевые виды деятельности

Форм-фактор

Требования надежности

Важные характеристики мобильных приложений

Время запуска

Отклик устройства

Фокусирование внимания на отдельных задачах

Настройка взаимодействия с внешними источниками информации

Единообразие стиля интерфейса

Различия в архитектуре компьютеров

Резюме

ГЛАВА 3  Внутренняя структура .NET Compact Framework

Введение

Как проектировалась .NET Compact Framework

.NET Compact Framework как подмножество платформы для настольных компьютеров

Управляемый код и собственный код

Исполнительный механизм

Библиотеки управляемого кода

Библиотеки базовых классов

Библиотеки пользовательского интерфейса

Библиотеки клиентов Web-служб

Библиотеки XML

Библиотеки данных

Вынесение полезной отладочной и проектной информации в необязательные компоненты

Средства подключения к базам данных SQL СЕ/SQL

Элементы, отсутствующие в первой версии .NET Compact Framework

Защита доступа

Мультимедиа

Как запускается и выполняется код

Управление памятью и сборка мусора

Краткий обзор методов управления памятью и сборки мусора

Резюме

ГЛАВА 4 Как добиться успеха при разработке мобильных приложений

Введение

Трудности постоянного и временного характера, с которыми приходится сталкиваться при разработке программного обеспечения

Трудности временного характера и способы их преодоления

Трудности постоянного характера и методологии, привлекаемые для их разрешения

Разработка программ является итеративным процессом, который, тем не менее, также должен подчиняться определенным правилам

Описание проекта

Плановые пересмотры проекта

Детали ничего не стоят, если общая картина неверна

Решайте задачи в определенной очередности; не бойтесь при необходимости возвращаться назад

Шаг 0: прежде чем приступать к работе, определите сферу применения вашего приложения

Шаг 1: начните с анализа проблем производительности и никогда не упускайте их из виду

Шаг 2: спроектируйте подходящий пользовательский интерфейс

Шаг 3: выберите подходящие модели данных и памяти

Шаг 4: выберите подходящую модель коммуникации и модель ввода-вывода

При необходимости вернитесь к шагам 0, 1, 2 и 3

Шаг 5: пакетирование приложения для его установки

Резюме

ГЛАВА 5 Наш друг конечный автомат

Введение

Что такое конечный автомат?

Явно и неявно определенные конечные автоматы

Подход 1: зависящее от специфики конкретной ситуации, децентрализованное, неявное управление состояниями (неудачный подход)

Подход 2: плановое, централизованное, явное управление состояниями (удачный подход)

Сколько конечных автоматов должно быть в приложении?

Конечный автомат для пользовательского интерфейса

Конечный автомат для модели памяти

Конечный автомат для фоновых задач

Использование конечных автоматов в играх

Резюме

ГЛАВА 6 Шаг 0: прежде чем приступать к работе, определите сферу применения приложения

Введение

Независимое приложение или часть большой системы?

Независимые приложения

Наборы взаимосвязанных приложений, установленных на устройстве

Мобильные приложения, взаимодействующие с приложениями для настольных компьютеров и серверов

Не пытайтесь просто переносить на устройства приложения, рассчитанные на настольные компьютеры! Мыслите категориями устройств!

Стереотипы использования мобильного и настольного программного обеспечения

Шаги по определению сферы применения мобильного приложения

ГЛАВА 7 Шаг 1: начинайте с анализа проблем производительности и никогда не упускайте их из виду

Введение

Важность планомерного подхода

Определите обязательные характеристики сценариев рабочих сеансов пользователя

Определите контрольные точки разработки, критерии завершения которых ориентированы на достижение высокой производительности

Время от времени критически пересматривайте написанный код

Определите модель памяти для вашего приложения

Как можно чаще контролируйте показатели, характеризующие работу вашего приложения

Программа для измерения характеристик кода

Выполняйте тестирование с использованием реальных объемов данных

Тестируйте приложения в предельных режимах

Своевременно предпринимайте меры по поддержанию высокой производительности приложения (со временем ситуация будет только ухудшаться!)

Определение задач, решение которых необходимо для достижения высокой производительности

Ha всем, что связано с оценкой производительности, лежит печать субъективности

Немедленная ответная реакция приложения

Максимальная продолжительность отображения курсора ожидания

Максимальная продолжительность загрузки/сохранения данных, а также запуска/закрытия приложения

Накладные расходы по обработке исключений

Пример сравнения эквивалентных алгоритмов, в которых возбуждение исключений соответственно используется или не используется

Резюме

ГЛАВА 8 Производительность и управление памятью

Определение модели памяти для приложения

Управление памятью на макроскопическом "уровне приложения"

Управление "служебными" данными приложения

Управление объемом пользовательских данных, хранящихся в памяти

Использование модели загрузки данных по требованию

Управление памятью на микроскопическом "уровне алгоритма"

Пишите аккуратные алгоритмы: не сорите!

Пишите экономные алгоритмы: разумно расходуйте память и повторно используйте объекты

Повторно используйте размещенные в памяти объекты при любом удобном случае

Избегайте размещения в памяти лишних объектов

Анализ описанных выше шагов последовательной оптимизации

Уделяйте особое внимание тому, как используются строки в ваших алгоритмах

Пример эффективного создания строк

Резюме

ГЛАВА 9 Производительность и многопоточное выполнение

Введение: когда и как следует использовать многопоточное выполнение

Многозадачность и многопоточность в современных операционных системах

В каких случаях следует использовать фоновые потоки

Рекомендации по использованию потоков в мобильных приложениях

Назначайте обслуживание пользовательского интерфейса основному потоку

Стремитесь поддерживать способность пользовательского интерфейса к отклику на высоком уровне

Начинайте с создания однопоточного приложения

В простых случаях пытайтесь обойтись без многопоточного выполнения, используя курсоры ожидания

Рассмотрите возможность использования фоновых потоков, если выполнение задачи требует длительного или неопределенного времени

Максимально упрощайте многопоточный код и документируйте его для повышения надежности

Рассмотрите возможность предварительного выполнения некоторой работы, осуществляемой кодом

Пример использования фонового потока для выполнения отдельной задачи

Потоки и пользовательский интерфейс

Пример использования фоновой обработки одновременно с обновлением данных высокоприоритетного потока пользовательского интерфейса

Резюме

ГЛАВА 10 Производительность и XML

Введение: работа с XML

XML или не XML?

Сравнение XML с другими текстовыми форматами

Различные способы хранения данных в виде текста

Иерархическая структура XML-данных

Другие возможности XML

Различные способы работы с XML

Простой пример, иллюстрирующий применение модели XML DOM и однонаправленного чтения-записи XML-документов

Пример: содержимое XML-файла

XML DOM

Модель однонаправленного чтения-записи XML-данных

Повышение производительности приложения перекладыванием работы на другие программы

Избегайте выполнения сложных преобразований данных на устройстве

Избегайте выполнения сложного поиска данных на устройстве

Рассмотрите возможность исключения необязательной информации перед отправкой данных на устройство

Когда не стоит перекладывать выполнение работы на сервер

Резюме

ГЛАВА 11 Производительность графического кода и пользовательского интерфейса

Введение

Стратегии проектирования высокопроизводительных пользовательских интерфейсов

Использование встроенных средств повышения производительности

Выполняйте тесты с использованием реальных объемов данных, которые будут отображаться в вашем приложении

Отсроченный выбор — это благо! Откладывайте, откладывайте, откладывайте…

Будьте внимательны, когда работаете с кодом, управляемым событиями

Не допускайте, чтобы пользователю оставалось лишь догадываться о ходе выполнения приложения

Выбор подходящих форматов и размеров растровых изображений

Размеры изображения имеют существенное значение

Так много файловых форматов и так мало времени…

Как поступать в тех случаях, когда источником изображения с высоким разрешением является само мобильное устройство

Стратегии проектирования высокопроизводительного графического кода

Способы интеграции графики с кодом пользовательского интерфейса

Где рисовать — на экране или вне экрана?

Определите собственный процесс визуализации

Отсрочка — зло, используйте предварительные вычисления

Кэшируйте часто используемые ресурсы

Старайтесь избегать распределения памяти для объектов при выполнении повторяющихся или непрерывно продолжающихся операций рисования

Резюме

ГЛАВА 12 Производительность: подведение итогов

Итоговые замечания по поводу производительности

Производительность и управление памятью

Производительность и многопоточное выполнение

Производительность и уровни абстракции API-интерфейсов

Связь производительности с организацией пользовательского интерфейса и работы с графикой

Старайтесь постоянно информировать пользователя о ходе выполнения приложения

Заключительные замечания и рекомендации

ГЛАВА 13 Шаг 2: проектирование подходящего пользовательского интерфейса

Мыслите категориями устройств!

Один размер для всего не годится

Одна рука или две?

Возрастание роли навигационных средств при уменьшении экранного пространства

Списки или вкладки?

Пользовательские интерфейсы мобильных телефонов и важность соблюдения единообразия в использовании клавиш

Сенсорные экраны и важность использования крупных кнопок

Оптимизируйте ввод обычных данных

Убедитесь в том, что для механизмов автоматизированного ввода предусмотрены параллельные механизмы ввода вручную

Тестирование на эмуляторах и физических устройствах

Проектируйте код пользовательского интерфейса мобильного приложения таким образом, чтобы его можно было легко тестировать и модифицировать

Модель состояний для компоновки пользовательского интерфейса и управления им

Пример кода, демонстрирующий две различные модели компоновки для одного и того же приложения

Размещение элементов управления

Экранное пространство — ценная вещь

Разработка улучшенных пользовательских интерфейсов средствами .NET Compact Framework

Динамическое создание элементов управления

Создание пользовательских элементов управления и перекрытие поведения существующих элементов управления

Использование прозрачных областей растровых изображений

Встраивание изображений в виде ресурсов приложений

Резюме

ГЛАВА 14 Шаг 3: разработка подходящей модели данных

Введение в модели доступа к данным, используемые в мобильных приложениях

Выбор подходящих абстракций для хранения данных в памяти

Выбор подходящей модели данных, требующих долговременного хранения

Специфика .NET Compact Framework: ADO.NET

Элементарные сведения об объектах ADO.NET DataSet

Отслеживание изменения данных

Две модели использования ADO.NET

Различные способы хранения долговременных данных

SQL СЕ

Резюме

ГЛАВА 15 Шаг 4: выбор подходящей коммуникационной модели

Введение в технологии связи с помощью мобильных приложений

Написание кодов программ для работы с мобильными сетями

Не допускайте того, чтобы работа приложения всецело зависела от возможности подключения к сети

Не допускайте того, чтобы поток пользовательского интерфейса блокировался на длительное время

Работайте на самом высоком уровне абстракции, который соответствует вашим потребностям

Всегда исходите из того, что связь может быть нарушена в любой момент

Имитация сбоев связи с целью тестирования отказоустойчивости приложения

Информируйте пользователя о ходе выполнения процесса синхронизации данных

Исходите из того, что скорость передачи данных и длительность задержек могут меняться

Внедряйте необходимые коммуникационные средства безопасности уже на ранних стадиях проектирования приложения

Передача данных и выбор сети

Wi-Fi: локальные сети

Bluetooth: персональные сети

Сети мобильной телефонной связи/сотовая связь

Связь посредством лотка/кабельного соединения с ПК

Сетевой кабель

IrDA

Карты памяти

Принудительная перекачка информации на устройства

Web-службы

Очень краткое описание Web-служб

Вызов Web-служб с мобильного устройства

Трудности, связанные с использованием Web-служб на мобильных устройствах

Резюме

ГЛАВА 16 Шаг 5: упаковка и развертывание мобильного приложения

Введение

Нуждается ли ваше мобильное приложение в цифровой подписи?

Инсталляция сред выполнения и других необходимых компонентов

Динамическое развертывание сред выполнения на мобильных устройствах

Динамическая установка компонентов, необходимых приложению

Возможные варианты упаковки и установки

Копирование и выполнение / загрузка и выполнение

Установка под управлением устройства

Установка под управлением настольного компьютера

Установка с использованием карт памяти

Установка с использованием инструмента разработки

Установка приложений в ПЗУ

Резюме

ГЛАВА 17 Послесловие

ПРИЛОЖЕНИЕ А Дополнительные ресурсы по .NET Compact Framework

Сетевые ресурсы

Обмен программами

Сетевые телеконференции

Общие вопросы разработки мобильных приложений

Особенности взаимодействия с собственным кодом

Работа с операторами мобильных сетей

Развертывание и установка

Оптимизация производительности

ПРИЛОЖЕНИЕ Б Примеры программ на языке Visual Basic .NET

Почему именно VB.NET и С#?

Примеры к главе 5 (конечные автоматы)

Примеры к главе 7 (производительность: введение)

Примеры к главе 8 (производительность и память)

Примеры к главе 9 (производительность и многопоточное выполнение)

Примеры к главе 10 (производительность и XML)

Примеры к главе 11 (производительность и графика)

Примеры к главе 13 (проектирование пользовательского интерфейса)

Примеры к главе 14 (данные)

Примеры к главе 15 (передача данных)

Примечания