Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework
- Название:Программирование мобильных устройств на платформе .NET Compact Framework
- Автор:
- Жанр:
- Издательство:Издательский дом Вильямс
- Год:2006
- Город:Москва • Санкт-Петербург • Киев
- ISBN:5-8459-0989-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework краткое содержание
Книга известного профессионала в области компьютерных технологий посвящена разработке приложений для широкого спектра мобильных устройств с использованием популярной и постоянно развивающейся платформы .NET Compact Framework. Уникальность этой книги состоит в том, что в ней гармонично переплетены теоретические сведения обо всем цикле разработки программного обеспечения с практическими примерами применения на языках С# и Visual Basic. Подробно рассматриваются концепции, лежащие в основе самой платформы .NET Compact Framework, а также вопросы, связанные с созданием эффективного пользовательского интерфейса, управлением памятью, производительностью и надежностью. Немалое внимание уделяется практическим аспектам разработки приложений для мобильных устройств, среди которых выбор модели представления и доступа к данным, внедрение коммуникационной модели, реализация модели поведения с помощью конечных автоматов и использование XML.
Книга рассчитана на разработчиков разной квалификации, а также может быть полезна для студентов и преподавателей соответствующих специальностей.
Программирование мобильных устройств на платформе .NET Compact Framework - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
■ Данные панели игры. Поскольку наша игра — графическая, то каждый отображаемый на панели уровень игры должен обладать собственными состояниями и ресурсами, которые с ним связаны. Все растровые изображения и объекты, хранящие информацию о состоянии, относящуюся к отдельным зонам панели игры, занимают определенные объемы памяти. Вполне вероятно, что наиболее оптимальным был бы конечный автомат, который в каждый момент времени хранит в памяти данные, относящиеся только к панели текущего уровня игры, и освобождает память от этих данных сразу же после того, как необходимость в них отпадает, например, когда должны быть загружены данные для другого уровня.
■ Глобально доступные кэшированные графические объекты. В нашей графической игре будет повторно выполняться множество самых обычных задач рисования. Вместо того чтобы непрерывно создавать и уничтожать часто используемые перья, кисти и растровые изображения, имеет смысл привлечь модель состояний, обеспечивающую хранение этих ресурсов в памяти на протяжении всего того времени, в течение которого они необходимы для выполнения повторяющихся задач перерисовки экрана. При переключении состояния игры в режим, в котором эти ресурсы не требуются, память может освобождаться от них.
Конечный автомат для фоновых задач
В ваших мобильных приложениях обязательно будут встречаться участки кода, которые либо долго выполняются, либо требуют сетевого доступа; в разряд "длительно выполняющихся" попадают все операции, выполнение которых может занимать более 0,5 секунды. Некоторые возможные примеры таких операций приводятся ниже:
■ Рекурсивные или итеративные вычисления, требующие просмотра многочисленных вариантов. К этой категории относятся поисковые алгоритмы, алгоритмы анализа данных, а также игры, основанные на механизме искусственного интеллекта. Поиск наиболее оптимального хода в шахматной игре может потребовать перебора многих тысяч различных допустимых вариантов шахматных ходов с использованием анализа различной глубины. Выполнение подобных операций может осуществляться в течение очень длительных промежутков времени.
■ Загрузка или сохранение больших объемов данных. Загрузка нескольких сотен порций информации из XML-файла или базы данных может занимать довольно большое время.
■ Сетевые операции. Почти все операции, выполняемые в сети, подвержены риску задержек и других проблем связи.
Операции подобного рода рекомендуется выполнять в асинхронном по отношению к потоку выполнения пользовательского интерфейса режиме. При реализации любой асинхронной операции конечный автомат, с помощью которого поток выполнения пользовательского интерфейса может связываться с фоновым потоком и получать информацию о ходе его выполнения, играет очень большую роль. Поток пользовательского интерфейса должен иметь возможность периодического опроса
состояния выполнения фоновой операции и одновременно предоставлять пользователю возможность в любой момент прекратить выполнение этой операции. В свою очередь, фоновый поток должен иметь возможность информировать поток пользовательского интерфейса о ходе своего выполнения, а также получать от него уведомления о необходимости прекратить свое выполнение в необходимых случаях. Модель выполнения потока под управлением конечного автомата обеспечивает прекрасные возможности для удовлетворения этих требований.
Ниже приводится пример, иллюстрирующий использование конечного автомата для управления фоновыми вычислениями, выполнение которых может занимать много времени. Целью этих вычислений является нахождение ближайшего простого числа (prime), превышающего заданное целое число. Соответствующий код может выполняться либо в синхронном режиме в целях отладки, либо в асинхронном режиме, позволяющем избежать блокирования пользовательского интерфейса на время проведения вычислений. На рис. 5.3 представлена схема простого конечного автомата, при помощи которого фоновый поток выполнения может предоставлять информацию о своем состоянии. Кроме того, этот конечный автомат позволяет потоку пользовательского интерфейса возможность направлять фоновому потоку запросы, требующие прекратить выполнение.

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