Загрузить статью
app-communication-ccefinal.pdf [Eng., 228.17 KB)
Аннотация
API WinRT в составе Windows 8 позволяет разработчикам быстро создавать и развертывать приложения, а затем публиковать их в магазине Windows. Если приложению нужен доступ к низкоуровневым системным ресурсам, требуются классические API Windows 8. Для обоих типов API разработчикам требуется создать два приложения (по одному для каждой среды) и каким-либо образом обеспечить обмен данными между ними. Для приложений, которые продаются в магазине Windows, этот обмен данными невозможно устроить локально. Вот что говорится в требованиях к сертификации приложений для магазина Windows:
3.1bПриложения для магазина Windows не должны обмениваться данными с локальными приложениями или службами посредством локальных механизмов, включая файлы и записи в реестре.
В этой статье рассматриваются способы обмена данными между десктопными и плиточными приложениями Windows 8. Приводятся основы реализации каждого подхода и соображения, которые следует учитывать при выборе. Если использовать сетевое подключение невозможно, то требование локального обмена данными не позволит выставить приложение в магазине Windows. Если есть интрасеть, можно использовать веб-службы или общее облако. При наличии доступа к Интернету крупные коммерческие решения могут использовать общее хранилище и другие веб-службы.
Общие сведения
Плиточные приложения Windows 8 должны быть компактными, надежными и быстрыми, а также должны поддерживать сенсорное управление. Для таких приложений действует ряд ограничений на доступ к различным компонентам файловой системы, ОС и оборудования. При обновлении существующих приложений до плиточной модели возникают некоторые препятствия. Часть функциональности приложений невозможно реализовать с помощью API WinRT API. Одно из возможных решений: создать интерфейс в стиле Windows 8, который будет обмениваться данными с десктопным приложением, чтобы выполнять действия, которые не поддерживаются в API WinRT. Есть несколько способов это сделать, но использование магазина Windows накладывает ряд ограничений.
Если компания разрабатывает собственные плиточные приложения Windows 8 для внутреннего использования, нет необходимости распространять их через магазин Windows. Значит, на эти приложения не действует запрет совместного доступа к локальным ресурсам. Дополнительные сведения см. по адресу http://blogs.msdn.com/b/windowsstore/archive/2012/04/25/deploying-metro-style-apps-to-businesses.aspx.
Соображения
Направление обмена данными
Если приложение просто предоставляет данные пользователям, данные будут передаваться главным образом (а может, и полностью) от десктопного приложения к плиточному. Обратная ситуация возникает довольно редко, но все же возможна. Если интерфейс более интерактивный, он должен как передавать данные во внутреннюю систему, так и получать данные оттуда.
Переключение между приложениями или фоновый обмен данными
Если требуется дискретный обмен данными, например сохранение файла в облегченном редакторе и переключение в полнофункциональный редактор, метод обмена данными может быть более статическим. При этом допускается больше вариантов реализации. При непрерывном обмене данными действует больше ограничений. Одно из важнейших ограничений: поток данных должен исходить из плиточного приложения Windows 8, которое используется в качестве интерфейса. Если же на переднем плане будет работать десктопное приложение, то плиточное будет, скорее всего, приостановлено. Приостановленное приложение, по сути, не работает: оно не может обмениваться данными и обрабатывать информацию.
Подключения
Если оба приложения находятся на одном и том же компьютере, количество возможных вариантов резко сокращается: многие способы обмена данными между процессами, доступные в прежних системах, не могут соединить WinRT с приложениями Win32. При добавлении интрасети появляется несколько дополнительных вариантов. Файлы можно хранить в локальном облаке или на серверном облачном хранилище, уведомления можно передавать через службу push-уведомлений Windows, можно использовать веб-службы. При наличии доступа в Интернет можно использовать крупные облачные хранилища и внешние веб-службы.
Автономная работа
Для общедоступного развертывания плиточного приложения Windows 8 это приложение необходимо сначала отправить в магазин Windows, для чего требуется пройти сертификацию. Десктопные приложения для Windows 8 также могут быть выставлены в магазине, но они должны быть автономными (не требовать установки других программных компонентов). Плиточные приложения Windows 8, выставленные в магазине Windows, могут зависеть от других программ, но только в случае, если эти программы также выставлены в магазине. Приложения для магазина Windows могут использовать другие программы (например, серверы, предоставляющие содержимое), но это может стать серьезным препятствием при совершенствовании приложений, работающих вместе. Десктопное приложение должно обладать, по крайней мере, мощной функциональностью, а плиточное приложение может служить вспомогательным компонентом (с дополнительной функциональностью) или в качестве расширения (более удобный доступ к уже существующим возможностям). Если внутренней обработкой занимается десктопное приложение, предоставляя содержимое плиточному приложению, то десктопному приложению также нужен свой интерфейс, чтобы оно могло работать автономно.
Возможные подходы
Веб-служба
Десктопное приложение может выполняться в качестве внутренней системы и предоставлять свои данные через веб-службу, что дает возможность плиточному приложению Windows 8 подключаться и обмениваться данными. Десктопное приложение также может служить посредником: обрабатывать взаимодействие и получать запросы по подключению. Пример использования веб-служб со стороны Windows 8 см. по адресу http://www.codeproject.com/Tips/482925/Accessing-Data-through-Web-Service-in-Windows-8-St.
Локальные файлы
Когда оба приложения находятся на одном и том же компьютере и пытаются обмениваться данными без использования сети, набор возможных вариантов весьма ограничен, но и эта задача решаема. Если приложение развертывается внутри компании, а магазин Windows не нужен, обмен данными можно осуществлять через локальные файлы, доступные для обоих приложений. Если десктопному приложению удастся обойти некоторые блокировки записи, оно сможет изменить общие файлы и обеспечить обмен информацией почти в реальном времени (если читать файлы быстро и часто). Пакет Intel Energy Checker SDK использует аналогичную модель (дополнительные сведения см. в разделе справочных материалов). В Windows 8 отключены именованные каналы, общая память и другие стандартные способы обмена данными между процессами. Поэтому остается, по сути, только использование локальных общих файлов. Опасность в этом случае заключается в раскрытии данных пользователям: поскольку файлы находятся в общей папке, пользователи могут получать к ним доступ, просматривать их и изменять. При этом возникают проблемы безопасности, если файлы не зашифрованы, и проблемы функциональности, если пользователь вдруг решит заблокировать, изменить или удалить файлы. Этот подход подробно описывается по адресу http://stackoverflow.com/questions/7465517/how-can-a-metro-app-in-windows-8-communicate-with-a-backend-desktop-app-on-the-s.
Облако: хранение и уведомления
При наличии доступа в сеть приложения могут обмениваться файлами с помощью удаленного сервера или облака. В большинстве облачных служб предусмотрены защитные механизмы, исключающие конфликты при доступе к файлам и утрату данных. Если настроить сервер push-уведомлений Windows (WNS), десктопное приложение сможет отправлять сообщения и обновления плиточному приложению Windows 8 в виде уведомлений. Это могут быть всплывающие уведомления, обновления динамических плиток; они могут обрабатываться кодом для настраиваемого обмена информацией. Примеры использования всплывающих уведомлений см. по адресу http://code.msdn.microsoft.com/windowsapps/Toast-notifications-sample-52eeba29Сведения об использовании облака см. по адресу http://www.windowsazure.com/en-us/develop/mobile/tutorials/get-started.
Имитация стиля
Если все перечисленные варианты неприменимы (например, используется один компьютер с ограниченными подключениями), можно полностью отказаться от реализации плиточного приложения Windows 8 и использовать только его плитку в качестве ярлыка для полноэкранного классического приложения, дизайн которого будет близок к стилю Windows 8. При этом не будут доступны все возможности Windows 8, но можно разрабатывать полнофункциональное приложение без ограничений, связанных с WinRT. Сведения и примеры таких приложений см. по адресу http://stackoverflow.com/questions/12881521/desktop-application-in-metro-style.
Тупики
Локальное замыкание веб-подключения
Локальное замыкание веб-подключения можно использовать приложениями в других ОС для подключения через веб-сокет к другой программе на этом же компьютере. В Windows 8 реализация этого подхода затруднена: механизмы безопасности Windows 8 отключают замыкание на себя. Эти механизмы безопасности можно отключить вручную, но лишь в режиме отладки. При этом приложение будет не только непригодно для распространения в коммерческих целях, но и никогда не пройдет сертификацию для магазина Windows.
Обмен данными в Win32
В Windows 8 можно упаковать API десктопных приложений в управляемые DLL-библиотеки для использования приложениями в стиле Windows 8. В теории это звучит неплохо, но на практике такой подход приводит к новым проблемам. В DLL-библиотеку придется упаковать целое приложение, из-за чего размер файла может достигнуть огромной величины. Если приложению требуется определенная функциональность Win32, не нарушающая политику сертификации магазина Windows, можно использовать собственную библиотеку. В определенных случаях добавление API в WinRT может сработать, но в качестве основной стратегии обмена данными между приложениями такой подход не годится.
Обзор возможных подходов
| Подход | Требуется сеть | Доступ пользователя | Двусторонняя передача данных | Прочие ограничения |
|---|---|---|---|---|
| Локальные файлы | Нет | Да | Не совсем: плиточное приложение Windows 8 должно быть на стороне интерфейса | Требуется сопутствующая загрузка, невозможно использовать Windows |
| Облако/сервер уведомлений Windows (WNS) | Интрасеть + сервер | Нет | Облако — да, но в WNS данные направлены только в сторону интерфейса Windows 8 | Для многих облачных служб требуется доступ к Интернету или сервер в локальной сети |
| Веб-службы | Интрасеть + сервер | Нет | Да | Для многих веб-служб требуется доступ к Интернету или сервер в локальной сети |
| Имитация стиля | Нет | Нет | Н/д | Нет динамических плиток, невозможно использовать чудо-кнопки, возможна путаница пользователей |
Заключение
Получить доступ к преимуществам плиточных приложений Windows 8 и десктопных приложений можно разными способами. Как это всегда бывает с программными решениями, одного лучшего варианта не существует. Выбор ограничивается различными факторами, но каждый метод имеет свои преимущества. Поскольку доступ к Интернету широко распространен, чаще всего используются веб-службы и облачные решения. Предоставленная здесь информация может служить отправной точкой для выбора наиболее подходящего решения. В будущем могут появиться и другие возможные варианты.
Прочие справочные материалы
Требования для сертификации приложений для Windows 8 http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx
Требования для сертификации классических приложений для Windows 8 http://msdn.microsoft.com/en-us/library/windows/desktop/hh749939.aspx
Требования для сертификации приложений для Windows Server http://msdn.microsoft.com/en-us/library/windows/desktop/hh848078(v=vs.85).aspx
Об авторе
Брэд Хилл (Brad Hill) — инженер по программному обеспечению в подразделении Developer Relations корпорации Intel. Брэд занимается изучением новых технологий на оборудовании Intel и обменивается лучшими методиками с разработчиками ПО на форумах Intel Developer Zone и на конференциях разработчиков. В настоящее время он работает над получением степени Ph.D по компьютерным наукам в Университете штата Аризона.