Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
На основании полученных результатов можно сделать следующие выводы:
1. Очень важно внимательно исследовать возможности применяемого каркаса пользовательского интерфейса с целью отыскания в нем встроенных механизмов, которые могут быть использованы для повышения производительности
2. Было бы неправильно предполагать, будто такие концептуально простые операции, как, например, очистка элемента управления от данных, будут сами по себе выполняться быстро и поэтому не следует прилагать никаких усилий к их ускорению.
3. Всегда имеет смысл затратить время на количественную оценку быстродействия различных подходов, чтобы выбрать наиболее оптимальный способ решения задач, возлагаемых на пользовательский интерфейс.
Выполняйте тесты с использованием реальных объемов
Обычная ошибка, которую допускают при написании кодов пользовательских интерфейсов. заключается в том, что в процессе проектирования и тестирования интерфейса используются данные меньшего объема, чем тот, с которым приходится сталкиваться при развертывании мобильного приложения. Алгоритм, который прекрасно справляется с извлечением из базы данных 20 элементов данных и их передачей пользовательскому интерфейсу, вовсе не обязательно сделает хорошо то же самое для 200 элементов данных. Если вы тестируете интерфейс, используя лишь небольшие наборы данных, то тем самым оставляете открытыми двери для множества неприятных сюрпризов, ожидающих вас на последующих стадиях разработки или при развертывании приложения, когда настанет черед работать с реальными объемами данных. Гораздо лучше выявлять все проблемы производительности еще на ранней стадии, когда для их преодоления могут быть найдены наиболее конструктивные решения; вносить изменения в проект впоследствии всегда труднее, это может нарушать стабильность работы приложения и почти всегда приводит к менее удовлетворительным результатам.
Еще одной распространенной ошибкой является использование других источников данных в процессе проектирования приложения, например, использование локальной базы данных или текстового файла в качестве временной замены до тех, пока не станут доступными данные на удаленном сервере, к которому при реальной работе будет получать доступ мобильное приложение. Чаще всего подобные проблемы возникают в тех случаях, когда либо реальные базы данных или данные недоступны для приложения на стадии проектирования, либо фактическая природа данных имеет критическое значение, но использовать в целях тестирования актуальные данные проектировщики приложения возможности не имеют. Резкие скачки производительности могут наблюдаться и при переходе от одного источника данных к другому. Как уже отмечалось, лучше всего, если тестирование приложения еще на ранних стадиях его разработки осуществляется в условиях, близких к реальным.
В любом случае очень важно точно представлять себе емкость и местоположение источников данных, которые ваше приложение должно будет отображать в пользовательском интерфейсе, а также механизмы доступа к этим источникам. Определите эти характеристики источников данных уже на ранних стадиях процесса проектирования приложения и выполняйте тестирование приложения с использованием источников данных, удовлетворяющих этим требованиям. Если приложение предназначено для работы с данными различного объема, тестируйте его на максимальном объеме данных. Настоятельно рекомендуется организовать буфер данных и тестировать приложение при объеме данных, который в разумной степени превышает расчетный, чтобы проверить, как это повлияет на производительность. Если данные могут поступать из различных источников, тестируйте производительность с использованием каждого из возможных механизмов доступа к данным. Если для доступа к данным будет использоваться коммутируемая линия или линия с низкой пропускной способностью, тестируйте приложение в таких же условиях. Важно не только то, чтобы приложение в подобных ситуациях работало корректно, но и то, чтобы оно имело привлекательный внешний вид и не теряло своей интерактивности на время длительных периодов обновления пользовательского интерфейса. При соблюдении всех этих рекомендаций весь ваш процесс проектирования будет нацелен на достижение производительности, обеспечивающей прекрасные условия для работы в реальных условиях. Для этого не существует лучшего способа, чем работа с теми же данными и с использованием тех же методов доступа к ним, что и те, с которыми будут сталкиваться в реальной работе конечные пользователи.
Отсроченный выбор — это благо! Откладывайте, откладывайте, откладывайте…
Многие приложения служат для того, чтобы предоставить пользователям возможность исследовать большие объемы динамических данных в сжатом
Так, мобильное приложение для агентов по продаже недвижимости может открывать доступ к просмотру данных, охватывающих сотни или тысячи домов, организуя их в виде иерархического дерева навигация по узлам которого возможна при использовании мобильного телефона или PDA. В типичных случаях первоначальный вариант проекта, позволяющий решить эту задачу, может быть основан на загрузке в память всей структурной информации о списках выставленных на продажу домов и предоставлении пользователю возможности осуществлять навигацию по узлам иерархического дерева для нахождения объектов, которые могут представлять интерес. Когда пользователь выбирает конкретный объект недвижимости, приложение загружает для него в ответ на запрос такую детальную информацию, как фотографии, поэтажные планы, схему расположения улиц и рыночный статус.
Элемент управления TreeView может предложить вам богатое разнообразие способов иерархического представления информации о возможных объектах недвижимости, обеспечивающих возможность последовательной конкретизации выбора. Так, TreeView можно использовать для формирования иерархической структуры с тремя узлами верхнего уровня, которые являют собой различные способы сводного представления данных в соответствии с различными стратегиями принятия решений, которые пользователь может использовать в процессе навигации по узлам данных. Ниже приведены примеры трех возможных способов развертывания иерархических структур, которыми, в частности, может воспользоваться конечный пользователь.
■ Способ 1. Начните с просмотра данных, сгруппированных по районам (Neighbourhoods), а затем перейдите к просмотру данных, сгруппированных по ценам, чтобы определить, информация о домах какой стоимости должна быть отображена. Этому способу навигации соответствуют следующие переходы по иерархическим узлам TreeView: Neighbourhoods→Price→ListOfUnits.
■ Способ 2. Начните с группировки по ценам (Price), а затем перейдите к просмотру данных, сгруппированных по типам, и, наконец, по районам, в результате чего будет отображен соответствующий список домов. Этому способу навигации соответствуют следующие переходы по иерархическим узлам TreeView: Price→HouseType→Neighbourhood→ListOfUnits.
■ Способ 3. Начните с типов домов (HouseType), а затем последовательно перейдите к просмотру данных, сгруппированных по интервалам цен и районам. Этому способу навигации соответствуют следующие переходы по иерархическим узлам TreeView: HouseType→Price→Neighbourhood→ListOfUnits.
На рис. 11.2 показано, как может выглядеть навигация по узлам иерархии TreeView. Имеется три узла верхнего уровня: Neighbourhood, Price и House- Type У каждого родительского узла имеются подузлы, по которым пользователи могут переходить вглубь иерархии, получая, в конечном счете, множество объектов недвижимости, информацию о которых они хотят просмотреть.
Несмотря на всю полезность метафоры дерева для отбора домов на основании иерархических категорий, при ее использовании могут возникать проблемы, обусловленные заметным ростом количества узлов дерева даже при средних объемах данных. Простая иерархия, включающая 10 узлов типа Neighbourhood, каждый из которых включает по 4 узла типа HouseType, включающие каждый по 4 узла типа Price, каждый из которых, в свою очередь, включает по 6 узлов типа House. в сумме дает для нашего дерева 960 концевых узлов, или листьев.
Это число следовало бы дополнительно умножить на количество способов навигации, которые мы хотим использовать:
960 для навигации по схеме Neighbourhoods→HouseType→Price→ListOfUnits
960 для навигации по схеме Price→Neighbourhoods→HouseType→ListOfUnits
960 для навигации по схеме HouseTypeOPrice→Neighbourhood→ListOfUnits
Рис. 11.2. Простой пример того, как может выглядеть иерархия узлов элемента управления TreeView для задачи поиска объектов недвижимости