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

Оглавление книги