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

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

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

Об авторе

Иво Салмре (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, открывающее программный доступ к соответствующему тексту. ...