Разработка приложений для универсальной платформы windows. Понятие платформы программного обеспечения. Хранения параметров приложения и работа с файлами
Библиотека программиста
«Очень важно не прерывать вопросов. Любопытство имеет свое право на существование»
Альберт Эйнштейн
37. Платформы семейства Windows
В этом разделе использованы материалы из книги: Джеффри Рихтер. Windows для профессионалов (программирование в Win32 API для Windows NT и Windows 95)/Пер. с англ. – М.: Издательский отдел "Русская Редакция" ТОО "Channel Traiding Ltd.",1995. – 720с. (Оригинальное издание – 1995г.)
Интерфейс Win32 API. Операционные системы Windows различных версий предлагают разработчикам прикладных программ (программистам) так называемый интерфейс программирования приложений Win32 API (application programming interface). API представляет собой совокупность функций, к которым может обращаться приложение.
Интерфейс Win32 API реализован на трех платформах: Win32s, Windows NT (Windows 2000) и Windows 95. Первоначальная цель компании Microsoft заключалась в том, чтобы реализовать этот интерфейс (т.е. все его функции) на всех трех платформах. В этом случае приложение, разработанное для любой платформы, можно было бы перенести на другую платформу достаточно просто: необходимо было бы только вновь компилировать его для другой платформы. В действительности, однако, осуществить эту мечту в полной мере не удалось, вследствие чего между тремя названными платформами есть довольно существенные отличия, которые сужают возможности по переносу приложений с одной платформы на другую.
Платформа Win32s была самой первой платформой, способной выполнять 32-битные приложения. Она состоит из набора динамически подключаемых библиотек (dll-файлы) и драйвера виртуального устройства (virtual-device driver). Этот набор служит дополнением к 16-битным системам Windows 3.x. Таким образом, Win32s является всего лишь надстройкой над Windows 3.x. Эта надстройка преобразует 32-битные параметры функций в 16-битные и вызывает соответствующие фунции Windows 3.x.
В Win32s большинство функций Win32 реализовано просто в виде "заглушек": при их вызове происходит возврат управления без выполнения каких-либо действий. Например, поскольку 16-битная Windows не поддерживает потоков, функция CreateThread возвратит пустой указатель. Вместе стем в Win32s были реализованы некоторые функции, не поддерживаемые Windows 3.x. К ним относятся, например, проецируемые в память файлы и структурная обработка исключений.
Целью разработки Win32s было подталкивание программистов к разработке 32-битных приложений с тем, чтобы к моменту выпуска платформы Windows NT на рынке уже присутствовали 32-битные приложения. Эта цель, к сожалению, так и не была достигнута, так как Win32s не имела особого успеха.
Платформа Windows NT – это полноценная операционная система, которая поддерживает функции Win32 в наиболее полном объеме. Она является сравнительно новой ОС и над ней не довлеет груз MS DOS. Корпорация Microsoft делает ставку именно на эту операционную систему. Правда, платформа Windows NT предъявляет высокие требования к аппаратному обеспечению компьютера, в первую очередь к объему ОЗУ и винчестера.
Платформа Windows NT имеет целый ряд преимуществ по сравнению с двумя другими платформами.
Во-первых, 32-битные приложения являются для нее "родными" и могут выполняться наиболее эффективно благодаря интерфейсу Win32 API. Здесь же необходимо отметить и высокую устойчивость платформы по отношению к неизбежным сбоям в работе приложений.
Во-вторых, Windows NT способна выполнять (одновременно) несколько разнотипных приложений, разработанных для MS DOS, OS/2, POSIX, Presentation Manager и Windows 3.x.
В-третьих, Windows NT является единственной переносимой из рассматриваемых платформ, т.е. она способна работать на машинах с разными типами процессоров. Так как большая часть кода Windows NT написана на языках С и С++, то для ее переноса на компьютер с другим (не Intel) типом процессора – MIPS R4000, DEC Alpha или Motorola PowerPC – достаточно перекомпилировать исходные тексты с помощью компилятора, являющегося "родным" для процессора. Конечно, на самом деле переход на другой тип компьютера несколько сложнее, так как требует переписывания двух низкоуровневых компонентов системы: ядра (Kernel) и так называемого слоя абстрагирования от аппаратной части компьютера (Hardware Abstraction Level – HAL). Эти компоненты пишутся в основном на соответствующей версии языка ассемблер и весьма специфичны для конкретного процессора. Для того чтобы приложения, написанные для Windows NT, могли работать на другом компьютере, их остается только перекомпилировать.
Таким образом, если предполагается использовать разрабатываемое приложение на компьютерах с разными типами процессоров, то его надо разрабатывать для платформы Windows NT.
И, наконец, в-четвертых, Windows NT единственная из обсуждаемых платформ, которая может работать на многопроцессорном компьютере и действительно будет использовать его уникальные возможности. Например, если на компьютере установлено 30 процессоров, то Windows NT обеспечит действительно одновременное выполнение до 30 потоков. (Фирма Sequent разработала компьютерную систему с 30 процессорами Intel.)
Платформа Windows 95 – это новейшая операционная система, которая заполняет на рынке очень объемную нишу компьютеров класса Intel 386 и выше с 4 и более мегабайтами ОЗУ. Причиной выпуска Windows 95 является как раз чрезмерно высокие требования Windows NT к характеристикам компьютера.
Для того чтобы Windows 95 могла работать на машинах с 4 Мбайтами памяти, MIcrosoft урезала некоторые функции интерфейса Win32 API. Вследствие этого Windows 95 не полностью поддерживает некоторые функции Win32 API, в частности, асинхронного ввода/вывода файлов, отладки, регистрации, защиты и др. Эти функции реализованы, но не полностью. Вместе с тем, Windows 95 поддерживает большинство функций Win32 API и является самой популярной платформой.
Таким образом, из рассмотренных трех платформ в настоящее время следует всерьез рассматривать только платформы Windows NT и Windows 95, так как платформа Win32s на самом деле не поддерживает большинство функций Win32 API.
Следует отметить еще одно отличие в платформах Windows 95 и Windows NT. В Windows 95 к интерфейсу Win32 API добавлен ряд новых функций для поддержки модемов, более точного воспроизведения цветов и прочего сервиса. А вот Windows NT (по крайней мере версии 3.5) этих функций не имеет вообще. Следовательно, при разработке программ надо иметь ввиду, что некоторые функции интерфейса Win32 API существуют на одной платформе и полностью отсутствуют на другой. Это тем более прискорбно, что платформа Windows NT должна, по замыслу компании Microsoft, поддерживать все функции интерфейса Win32 API.
Полный перечень отличий реализации платформы Win32 в различных версиях Windows можно найти в разделе "Platform Differences" справочного файла ProgTech.hlp.
В операционную систему Windows NT 3.5 встроены графические возможности трехмерной графики OpenGL API . OpenGL - это независимая от операционной системы промышленно-стандартная библиотека графических функций, разработанная фирмой Silicon Graphics для своих рабочих станций. В настоящее время OpenGL признана Architecture Review Board, включающей такие фирмы, как DEC, IBM, Intel, Microsoft и Silicon Graphics. Технология OpenGL была лицензирована Microsoft для предоставления этого мощного 32-разрядного API пользователям Windows NT. Развитые функции этой библиотеки требуются в том случае, когда необходима визуализация крупных проектов и данных. Типичные задачи, требующие ее использования, - это САПР, системы механического и промышленного дизайна, программы статистического и научного анализа.
Последнее обновление: 12.04.2017
UWP (Universal Windows Platform) представляет собой унифицированную платформу для создания и запуска приложений в Windows 10 и Windows 10 Mobile.
UWP стала результатом фолюции более ранних технологий. Так, с выходом Windows 8 была внедрена новая архитектурная платформа для приложений - Windows Runtime (WinRT), которая позволяла запускать приложения в так называемом режиме Modern (Metro) на десктопах, планшетах. Затем с выходом Windows 8.1 и Windows Phone 8.1 эта технология получила развитие - появились "универсальные приложения", которые можно было запускать сразу Windows 8.1 и WP8.1. И в июле 2015 года официально вышла новая ОС Windows 10. Она использует платформу UWP, которая представляет собой развитие Windows Runtime.
Как подсказывает название платформы, она является универсальной - универсальной для всех устройств экосистемы Windows 10. А это обычные дестопы, планшеты, мобильные устройства, устройства IoT (интернет вещей), Xbox, устройства Surface Hub. И приложение UWP может одинаково работать на всех этих платформах, если на них установлена Windows 10.
Почему UWP?
Программирование под UWP несет ряд преимуществ:
Широта распространения . На текущий момент (апрель 2017) Windows 10 установлена уже более чем на 400 миллионах устройств. На десктопах Windows 10 уже опередила Windows 8/8.1.
Поддержка широкого круга устройств . Десктопы, планшеты, смартфоны, большие планшеты Surface Hub, различные IoT-устройства, в перспективе устройства виртуальной реальности HoloLens - круг устрйоств, на которых может работать Windows 10 действительно широк.
Поддержка разных языков и технологий программирования . UWP-приложения можно создавать с помощью таких языков, как Visual C++, C#, Visual Basic, JavaScript. В качестве технологии для создания графического интерфейса Visual C++, C# и Visual Basic используют XAML, JavaScript применяет HTML. Кроме того, С++ может вместо XAML использовать DirectX. То есть достаточно распространенные и и знакомые многим технологии.
Магазин приложений и удобство распространения . Windows Store представляет собой прекрасное место для распространения UWP-приложений, как платных, так и бесплатных. Сами возможности платформы и магазина Windows Store позволяют использовать разные способы монетизации. Например, можно интегрировать в приложения блоки для показа рекламы через различные SDK. Можно распространять за определенную плату, причем оплату можно гибко настраивать. При необходимости можно встроить предоставление ознакомительной версии, после использования которой пользователь может решить, покупать приложение или нет. И также можно монетизировать по модели freemium, при которой приложение условно бесплатное, а отдельные услуги внутри приложения предоставляются за определенную плату. Причем все эти возможности монетизации обесечиваются встроенными инструментами SDK.
Богатые возможности платформы . UWP многое наследует от Windows Runtime из Windows 8.1 и в то же время предоставляет много новых функцональностей, как, более богатые возможности по интеграции с облаком, использование Cortana, системы уведомлений в Win10 и многое другое.
Что необходимо для разработки под UWP
Для программирования под UWP необходима ОС Windows 10. Все другие операционные системы, как Windows 8.1/8/7, не говоря уже о Windows XP, не подходят !
Также потребуется среда разработки Visual Studio 2017 Community. Это полнофункциональная бесплатная среда разработки, которую можно загрузить с официального сайта по адресу https://www.visualstudio.com/downloads/download-visual-studio-vs .
Также можно использовать версию VS 2015, а все остальные предыдущие версии Visual Studio - 2013, 2012, 2010 и т.д. с UWP не работают.
При установке Visual Studio 2017 в программе установщика необходимо отметить соответствующий пункт:
Перед чем как начать создание приложений, убедитесь, что в центре обновления в Windows 10 установлена соответствующая опция для разработчиков:
И имея Windows 10 и установленную Visual Studio 2017, можно приступать к разработке приложений.
Так что вполне можно начать знакомиться с новой платформой. Давайте я сделаю небольшой экскурс, описав некоторые отличия.
Начну с того, что приложения UWP обладают кое-чем, чего нет у классических приложений Windows – у них есть App Model. Что такое App Model? Это своеобразный регламент. Описание всех возможностей приложения - его прав доступа, способа установки, обновления, хранения информации и т.п.
У приложений Windows Store, точно так же как и у приложений UWP есть файл манифеста, в котором описаны все возможности и права приложения. Это файл Package.appxmanifest. Его можно редактировать как в графическом редакторе, так и в виде кода XML. Скриншот графического редактора смотрите ниже.
Элементы управления
Если вы помните, то совсем недавно у Windows 8 и 8.1 была Charm panel – волшебная панелька:Сейчас же вместо нее используются более привычные для WPF разработчиков контролы:
Здесь новым контролом является ContentDialog, который блокирует приложение, примерно так же, как блокирует его MessageBox.
Кроме того в UWP более привычная для разработчиков WP навигация:
Что может показаться интересным, так это то, что некоторые элементы управления могут иметь различный внешний вид при отображении на различных устройствах. Простыми словами, контрол может выглядеть немного иначе, например, при отображении на десктопе и на мобильном устройстве.
В целом, я так полагаю, среднестатистический разработчик уже давно привык большому разнообразию контролов. Освоение новых трудностей вызвать не должно.
Разработка под различные устройства
Постараюсь разобрать то, что для WPF разработчика будет необычным. Например, это то, что при разработке приложений Windows 8.1 можно было в одном решении разрабатывать одновременно и под телефон и под десктоп.В таком случае создавалось 3 проекта. В приложениях WP и WinRT хранился xaml код «вьюшек» и какой-то особый код под устройства, а в общем проекте хранился общий код xaml и общий для двух проектов код C#.
Сейчас же, так как платформа UWP универсальная, то для каждого типа устройств можно создать папку, в которую можно поместить «вьюшку» - т.е. xaml файл с дизайном под параметры устройства.
Жизненный цикл
Есть старая шутку про формулу-1: «У Ральфа Шумахера два положения педали – включено и выключено. Остальными положениями можно пренебречь».Этой шуткой я могу немного подколоть классические приложения.Net. Они либо работают, либо не работают. В приложениях Store все немного иначе. У них кроме состояний «Включено/выключено» есть еще и промежуточное состояние «Приостановлено». Жизненный цикл приложений 8.x и UWP отображен на следующей картинке:
Триггеры и фоновые задания
Приложения.Net могут быть либо исполняемыми файлами либо могут быть службами/сервисами. Это совершенно разные виды приложений. То есть не может быть такого, что приложение exe, но при этом оно работает в фоне. Нет, конечно же, приложение может работать в трее. Но фактически получается, что оно запущено и просто свернуто.Что касается приложений 8.x и UWP, то они могут содержать в себе фоновые задания. Фоновые задания это некоторое подобие сервиса. То есть приложение может не работать, но в системе будет выполняться какая-то задача. Кроме того фоновая задача может «отлавливать» какие-то события в работе системы триггером.
Один из самых популярных триггеров это SystemTrigger . С помощью него приложение может выполнить какой-либо код при наступлении таких событий как: появление или пропажа интернета, изменение состояния сети, подключение или отключение пользователя, получение смс, изменение часовой зоны и т.п.
Также довольно популярны TimeTrigger и MaintenanceTrigger . Оба триггера выполняют какой-либо код с периодичностью в определенный промежуток времени. Промежуток времени должен быть не менее 15 минут. Отличие в то, что TimeTrigger требует регистрации приложения на экране блокировки, а MaintenanceTrigger-у требуется чтобы устройство работало не от батареи, а от сети.
В UWP появилось много новых триггеров. Взять, например такой вот интересный триггер как MediaProcessingTrigger , который позволяет приложению перекодировать мультимедиа в рамках фоновой задачи.
Использование библиотек
Если в классических приложениях вы использовали библиотеки DLL, то в приложениях 8.x и UWP вы сможете использовать как PCL, так и компонент среды выполнения WinMD. В чем отличие?PCL (portable class library) может быть добавлена приложениям под различные платформы. И под.Net Framework различных версий, и под Windows 8.x и под WP, под UWP и даже под iOS/Android приложения Xamarin. То есть в эту библиотеку можно запихнуть какой-то общий платформонезависимый код.
WinMD может быть использован только под 8.x или UWP. Вне зависимости от языка, на котором написаны приложения, они могут работать с WinMD. Но сам WinMD в случае если он содержит в себе сложные вычисления лучше писать на C++ для достижения наилучшей производительности.
Впрочем, при разработке под UWP вы можете создать и библиотеку классов (DLL).
Работа с данными
В чем еще заключается отличие приложений UWP, так это в том, что они не работают с базами данных напрямую. То есть такие базы данных, как, скажем SQL Server или Oracle, расположенные на сервере организации, будут вам недоступны. Впрочем, это было бы странно, если бы пользователь скачивал из Store приложение, и приложение начинало бы работать с базой SQL Server-а, расположенной на сервере в локальной сети. Но вы сможете работать с данными, используя веб-сервисы. Есть возможность использовать для баз MySQL оракловский Connector/Net, но он на данный момент не поддерживает SSL и потому не особо интересен. Так что лучше не отклоняться от концепта использования сервисов для доступа к данным.Для хранения информации внутри приложения вы можете использовать SQLite.
Хранения параметров приложения и работа с файлами
Хранение параметров приложения возможно не только на устройстве, но и в облаке. Таким образом, если запускать приложение на различных устройствах, то настройки везде будут одинаковыми.Следующий небольшой сниппет сохраняет количество вызова кода в облаке:
Int timescount = 0;
Object roamS = Windows.Storage.ApplicationData.Current.RoamingSettings.Values["times"];
if (roamS != null) timescount = (int)roamS;
timescount++;
Windows.Storage.ApplicationData.Current.RoamingSettings.Values["times"] = timescount;
Если заменить Windows.Storage.ApplicationData.Current.RoamingSettings на Windows.Storage.ApplicationData.Current.LocalSettings, то параметр будет сохранен локально на устройстве.
Настройки могут быть скомпонованы как в составные параметры, так и в контейнеры. Файлы точно так же как и настройки можно хранить как на устройстве в локальной папке, так и в облаке. Но кроме этого есть возможность хранить файлы во временной папке, которая при необходимости может быть очищена системой - ApplicationData.TemporaryFolder .
Кроме того можно получить доступ к папке, которая содержится в приложении с помощью
Windows.ApplicationModel.Package.Current.InstalledLocation
Доступ к файлам, хранящимся на дисках, тоже организован по особой модели. Содержимое папок документов, фотографий, видео и подобных может быть получено с помощью класса KnownFolders, но в таком случае необходима установка разрешений в манифесте. Доступ к какой-либо другой папке возможен только в случае, если пользователь выберет папку сам в процессе работы с приложением. Посещенные папки можно сохранять, дабы при повторном запуске приложения не заставлять пользователя делать лишние действия
Var folderPicker = new Windows.Storage.Pickers.FolderPicker();
folderPicker.FileTypeFilter.Add(".jpg");
folderPicker.FileTypeFilter.Add(".jpeg");
folderPicker.FileTypeFilter.Add(".png");
folderPicker.SuggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.PicturesLibrary;
folderPicker.SettingsIdentifier = "picker2";
Windows.Storage.StorageFolder lastFolder = await folderPicker.PickSingleFolderAsync();
if (lastFolder == null) return;
String mruToken = Windows.Storage.AccessCache.StorageApplicationPermissions.MostRecentlyUsedList.Add(lastFolder);
Получить после этого последнюю сохраненную папку можно так:
String mruFirstToken = StorageApplicationPermissions.MostRecentlyUsedList.Entries.FirstOrDefault().Token; lastFolder = await StorageApplicationPermissions.MostRecentlyUsedList.GetFolderAsync(mruFirstToken);
Привязки данных
Как в приложениях WPF, так и в приложениях UWP, а также при разработке под 8.x можно использовать привязки данных – {binding}. Но в UWP появились еще и компилируемые привязки – {x:bind} В чем отличие? Компилируемые работаю гораздо быстрее, а формируются/проверяются они во время компиляции а не во время запуска приложения. Также они строго типизированные.Подробнее здесь.
Дорогие хабравчане!
Хотел бы попродробнее рассказать вам про одно из самых интересных на мой взгляд нововведений . Речь пойдет про одновременную разработку приложений для Windows 8 и Windows Phone, т.е. про универсальные приложения для платформы Windows .
Платформа Майкрософт покрывает широкий спектр устройств - от смартфонов и планшетов до настольных компьютеров и игровой приставки Xbox One, и вполне естественно, что разработчику хочется минимизировать усилия при создании приложений под все форм-факторы. На конкурирующих платформах существует огромная разница между настольными и мобильными приложениями (поскольку они работают под управлением различных операционных систем), при этом мобильные приложения, разработанные для смартфона, могут работать на планшетных устройствах, что зачастую приводит к неудовлетворенности пользователя из-за не очень качественного пользовательского интерфейса.
На данный момент Майкрософт вплотную подошел к тому, чтобы унифицировать все платформы (Windows Phone, Windows 8, Xbox One) с точки зрения API, и позволить программисту максимально использовать общий код при создании приложений, при этом сохранив возможность использования различного дизайна для различных форм-факторов. Подробнее про то, как это реализовано на текущий момент - читайте ниже.
Как раньше создавались приложения Windows + Phone
До сегодняшнего дня для создания приложений с общим кодом для Windows и Windows Phone приходилось использовать разделяемую переносимую библиотеку (portable library) для выделения общего кода, отвечающего за доступ к данным и бизнес-логику, и различные проекты для UI. Подробнее такой подход описан в специальном курсе на Microsoft Virtual Academy , или . Также из-за разницы в API Windows 8 и Windows Phone приходилось часть кода делать платформенно-зависимым.Универсальные приложения Windows
На конференции build были объявлены следующие нововведения:- В новой версии Windows Phone 8.1 будут использоваться Windows RT API Это означает, что около 90% системных вызовов между Windows 8.1 и Windows Phone 8.1 будут общими. Кроме того, язык разметки XAML также был унифицирован между платформами. Иными словами, новые приложения Windows Phone 8.1 будут использовать Windows XAML, а не Silverlight. Если вам нужна совместимость, для Windows Phone по-прежнему можно будет разрабатывать с использованием Silverlight, в т.ч. используя новые возможности, но это тема для отдельной статьи.
- В Visual Studio 2013 Update 2 появится новый шаблон проекта
для унифицированных приложений Windows. Этот шаблон создает различные проекты для Windows и Phone, и третий «разделяемый» проект, в котором размещается весь общий код. При этом разделяемый проект
может содержать не только код, но и XAML-разметку, общие ресурсы, изображения и т.д. Этот проект не компилируется в отдельную библиотеку, а разделяется между двумя платформенными проектами на уровне текстового включения на этапе компиляции. Такой шаблон можно использовать для разработки на C#/XAML, C++/XAML или HTML/JS. - Если вы хотите выделить часть платформенно-независимого кода в отдельную библиотеку, разделяемую между несколькими приложениями, то по-прежнему можно использовать переносимую библиотеку, в которую теперь можно включать также и XAML-разметку . Переносимые библиотеки можно использовать для разработки на C# или Visual Basic.
- Бинарной совместимости между платформами пока нет , т.е. приложения Windows 8 и Windows Phone по-прежнему будут распространяться через соответствующие магазины, и разработчику будет необходимо создать и загрузить в каждый из магазинов пакеты приложения (хотя теперь Windows Phone 8.1 будет использовать такой же формат.appx, что и Windows 8. Однако в магазинах Windows и Windows Phone будут использоваться единые идентификаторы приложений , что позволит реализовать сценарии единой покупки приложения для использования на всех платформах .
- Приложения для Xbox One в текущей версии Visual Studio Update 2 не так хорошо вписываются в общую историю, хотя на пленарном докладе было показано универсальное приложение Khan Academy с использованием Kinect, работающее на Xbox и Windows (да, Kinect v2 будет поддерживаться в приложениях магазина Windows, но это опять же тема для отдельной статьи). Разработка для Xbox One на текущий момент предполагается на HTML/JS/CSS и C++
Universal Hello World
Рассмотрим небольшой пример создания универсального приложения. Структура проектов в Visual Studio 2013 Update 2 была изменена, и теперь в разделе Магазин Window доступны как приложения для Windows и Windows Phone, так и универсальные приложения и библиотеки.Вновь создаваемое универсальное приложение будет расчитано на платформу Windows Phone 8.1 и Windows 8.1 Update. При этом в разделе приложений Windows Phone доступны шаблоны проектов Windows Phone, основанные на Silverlight, которые позволят создавать приложения для ранних версий платформы - но возможности универсальных приложений при этом использовать нельзя.
После создания пустого универсального приложения, мы получим следующую структуру, состоящую из трех проектов: по одному проекту на каждую платформу и общий разделяемый проект:
Обратите внимание:
- По умолчанию дизайн страничек (XAML) для платформ разнесен по разным проектам. Однако в простых случаях вы можете использовать общие XAML-файлы для всех платформ, если вы уверены, что ваш дизайн будет достаточно хорошо адаптироваться к разным разрешениям, от смартфона до десктопа. При этом многие встроенные элементы управления (например, GridView) умеют адаптироваться и изменять свой внешний вид в зависимости от платформы.
- Если у вас есть уже готовый проект Windows или Windows Phone, вы можете создать на его основе универсальное приложение, выбрав в контекстном меню проекта соответствующий пункт. При этом проект будет преобразован в такую же трех-проектную структуру, и вы сможете переносить файлы приложения в общий проект для их совместного использования.
- В разреляемый проект можно включать ссылки на библиотеки (References), при этом эти ссылки будут добавлены в оба проекта (мы видим, что в ссылках каждого из платформенных проектов присутствует Shared-ссылка). Если какие-то библиотеки доступны только для одной из платформ, то мы все равно можем использовать соответствующую функциональность в общем коде, окружая её директивами условной компиляции #ifdef. Visual Studio настолько удобна, что при этом будет работать Intellisense, предупреждая нас о том, что ссылка доступна только в одной из платформ.
- Если мы выносим XAML-код в общий проект, то в редакторе XAML доступен drop-down для переключения платформы, и мы можем визуально редактировать дизайн страницы как в режиме телефона, так и в режиме планшета/десктопа.
В большинстве случаев вы захотите разделять как можно больше кода между платформами, перенеся все, что возможно, в проект shared. В нашем случае мы можем перенести MainPage.xaml из одного из проектов в разделяемый проект, и удалить его в платформенных проектах, поскольку в нашем случае дизайн странички не будет отличаться от платформы к платформе:
Таким образом, мы получили универсальное приложение, код и дизайн которого полностью находятся в разделяемом проекте.
На пути к реальному приложению - Photo Viewer
Попробуем превратить наше приложение Hello World во что-то полезное - например, в просмотрщик лучших фотографий flickr. Flickr предоставляет RSS-поток фотографий, поэтому определить соответствующий источник данных сравнительно просто (для пущей простоты загрузка RSS сделана не-асинхронной, в реальных проектах так делать не надо):Код для получения картинок из Flickr
public class Flickr
{
List
На основной страничке используем GridView, привязанный к этому источнику данных. Для того, чтобы на разных платформах фотографии были разного размера, используем ключ из ресурсного файла, определяющий требуемый размер фотографии.
XAML-дизайн основной страницы приложения
Чтобы задать разные параметры в ресурсном файле, создадим в каждом из платформенных проектов свой ресурсный файл Resource.xaml следующего содержания:
И в завершение нам надо подключить этот ресурсный файл в App.xaml (который находится в разделяемом проекте):
App.xaml
В результате мы получаем пару приложений для Windows 8 и Windows Phone, которые корректно отображают галерею изображений с учетом специфики платформы.
Полный исходный код приложения можно получить на github .
Мораль
Для создания новых приложений на платформе Windows 8 сейчас лучшим решением будет использовать универсальные приложения. Если у вас есть существующее приложение Windows 8, то его имеет смысл потихоньку конвертировать в универсальное приложение и портировать на Windows Phone 8.1. Существующее приложения Windows Phone 8 преобразовать в универсальное приложение сложнее (т.к. для ряда операций используются другие наборы API), об этом мы еще с вами поговорим. Наконец, универсальные приложения для Windows Phone требуют версии Windows Phone 8.1, поэтому на текущий момент, чтобы иметь достаточно широкую install base, имеет смысл использовать приложения Silvelight 8.0Операционная система Windows Core OS – это будущая основа Windows и исторический шаг вперед к превращению Windows 10 в настоящую универсальную ОС.
Вкратце, Windows Core OS (сокращенно WCOS) является связующим кросс-платформным звеном для Windows, что позволяет использовать любые устройства или архитектуры, улучшаемые модульными расширениями, способными активировать на устройствах необходимые функции.
Проект «Andromeda OS» в кругах посвященных теперь называется «Windows Core OS»
Ее основная цель – сделать ОС Windows 10 намного более гибкой и совместимой с большим количеством устройств без привязки к определенным ранее разработанным вариантам продуктов. Вследствие этого Windows станет «меньше» (в зависимости от устройства), собственно ОС будет разрабатываться быстрее, а устройства не будут перенасыщены уже неактуальными компонентами и функциями. Общая производительность и скорость выполнения операций на меньших или более слабых устройствах возрастут.
Что это значит для пользователя?
Сегодняшняя Windows 10 выпускается в нескольких вариантах (например, есть версии для настольных ПК и для мобильных устройств), не являясь единственной ОС для всех девайсов. Однако эти версии имеют общие элементы, такие как OneCore и универсальная платформа Windows, поэтому WCOS призвана заменить эти вариации универсальной платформой.
WCOS открывает дверь множеству новых конфигураций Windows. Конечно, десктопные ОС Windows 10, например, Pro и Enterprise продолжат существовать, предоставляя полную функциональность и все возможности ОС для настольных ПК.
Первичное исполнение WCOS предположительно будет разработано в 2018 году и, скорее всего, будет ориентировано на мобильный сегмент.
Следующий шаг – подготовка WCOS для настольных компьютеров и устройств типа Xbox. WCOS и совместные разработки Microsoft и CShell помогают корпорации совершить большой прыжок в сторону концепции «One Windows» («Единый Windows»). Первыми универсальными компонентами Windows 10 были OneCore и универсальная платформа Windows. Сейчас же Microsoft двигается дальше в этом направлении благодаря WCOS и CShell.
Будущее Windows
WCOS станет толчком запуска Windows на современных мобильных устройствах и сделает его совместимым с инновационными девайсами, которые, возможно, увидят мир в ближайшие несколько лет. Microsoft нуждается в гибкой, конфигурируемой и быстро реагирующей ОС, которой на сегодняшний день Windows не является. WCOS исправит это.
Важно: WCOS не предназначается для прямой работы с потребителями и не будет открыто продаваться корпорацией Microsoft. Это внутренняя платформа, позволяющая создать такие версии Windows 10, которые ранее были нереальны. Но, как обычно, Microsoft может в любое время отказаться от своих планов относительно WCOS или отложить их.