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

Базы данных предлагают наивысшую степень организации данных, однако привносят с собой дополнительные накладные расходы, связанные с выполнением процессора базы данных.

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

■ Двоичные потоки.

■ Текстовые потоки.

■ Объекты однонаправленного чтения и записи XML.

■ Объектная модель документов (DOM) XML.

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

Какой формат данных следует использовать для хранения данных — целиком зависит от целей вашего приложения; никакого универсального рецепта здесь не существует. Распространенной ошибкой тех, кто только приступает к разработке программного обеспечения для мобильных устройств, является допущение о том, что, поскольку в этом случае приходится иметь дело с ограниченными ресурсами, следует сразу же переходить на самый низкий уровень абстракции и использовать двоичные файлы наряду с потоковыми операциями файлового ввода-вывода. Иногда необходимость в этом действительно существует, но в большинстве случаев это просто означает выполнение ненужной работы, которая потребует дополнительного тестирования и, вероятно, приведет к худшему решению, не обеспечивающему достаточной гибкости. Общее правило заключается в том, чтобы использовать наивысший уровень абстракции, допустимый с точки зрения размера данных и достигаемой при этом производительности. Было бы неразумно изобретать собственный двоичный формат для данных сравнительно небольшого объема, поскольку при средних запросах памяти лучшего варианта, чем XML, не найти. С XML легко работать, он обеспечивает надежную работу с различными версиями данных и для него существует высокоуровневый API- интерфейс, упрощающий процесс программирования. Точно так же, в случае возникновения действительной необходимости в двоичном формате, например, для хранения больших объемов данных, описывающих изображения, гораздо предпочтительнее воспользоваться уже имеющимися и проверенными на практике форматами, если таковые имеются. Поскольку существует целый ряд хорошо зарекомендовавших себя форматов изображения, изобретение собственного формата будет, как правило, напрасной тратой времени. При любой удобной возможности старайтесь использовать уже существующие компоненты и форматы данных; изобретайте свои собственные форматы лишь в тех случаях, когда вы убеждены, что высокоуровневые подходы не сработают.

Не считая простейших игр и элементарных приложений вспомогательного характера наподобие калькуляторов, большинство представляющих интерес приложений для мобильных устройств, так или иначе, взаимодействуют с данными, хранящимися за пределами устройств. Эти данные могут находиться в базе данных, реплицируемой на устройстве. Они могут содержаться в хранящейся на устройстве адресной книге, синхронизируемой с электронным почтовым сервером. Ими также могут быть изображения или музыкальные файлы, загруженные с Web или настольного компьютера или "полученные" от другого устройства через инфракрасный порт. Пользователи мобильных телефонов обмениваются SMS-сообщениями. XML-данные передаются Web-службам и принимаются от них.

Доступ к данным может осуществляться через сеть Wi-Fi, данные могут передаваться посредством флэш-карты, вставленной в устройство, пересылаться при помощи мобильных телефонов с использованием протокола GPRS, передаваться через инфракрасный порт или просто пересылаться по Ethernet-кабелю, подключенному к устройству. Короче говоря, существует множество самых различных типов данных, которыми устройства могут обмениваться, и средств, обеспечивающих передачу этих данных.

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

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

■ Должно ли быть подключение к источникам актуальных данных постоянным или оно будет требоваться лишь время от времени?

■ Какие объемы данных потребуется перемещать? От ответа на этот вопрос могут зависеть другие ваши решения.

■ Каким образом будет осуществляться обмен данными? Посредством беспроводного сетевого соединения? Посредством лотка ПК? Посредством карты флэш-памяти?

■ Какова структура расходов на обеспечение соединений? Поскольку за использование сети Wi-Fi в составе интрасети ничего платить не надо, плата за использование мобильных сетей обычно взимается в соответствии с объемом передаваемых данных.

Вы должны исходить из того, что в мобильных сетях соединения часто разрываются, и, как правило, это происходит в самый неподходящий момент. Даже если устройство подключено к сети непосредственно через кабель, все равно следует подумать о мерах предосторожности, заранее предполагая, что случиться может все что угодно: сервер может выйти из строя, кабель может порваться, прокси-серверы, преобразователи сетевых адресов, маршрутизаторы и брандмауэры могут внезапно "организовать против вас заговор", а некие противные маленькие злые гномики могут проникнуть в "железо" и атаковать ваши пакеты данных крохотными молоточками, чтобы не дать им дойти до пункта назначения. Разумная доля скептицизма, граничащая с паранойей, сторицей себя окупит. Заблаговременно предполагайте любые мыслимые и немыслимые ситуации, лишь бы ваше приложение было надежно защищено, и трезво подходите к реалиям работы в условиях сбойных соединений и возникновения непредвиденных затруднений.

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

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

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

■ Поместите все процедуры доступа к сети в блоки try/catch (то есть организуйте структурную обработку исключений). Исходите из того, что время от времени будет выполняться каждый из этих catch-блоков, и имитируйте эти ситуации в процессе проектирования и тестирования приложения, чтобы проверить, правильно ли реагируют на возникновение исключений предусмотренные для них обработчики. Целесообразно предусмотреть, чтобы исключения возбуждались при любых периодических нарушениях связи; точно так же, целесообразно перехватывать подобные исключения и обрабатывать их так, чтобы это облегчало работу пользователя.