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

Автор книги: Иво Салмре

сообщить о нарушении

Текущая страница: 6 (всего у книги 69 страниц)

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

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

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

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

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

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

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

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

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

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

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

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

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

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