Windows 10 - это вершина развития концепции единства наших платформ: теперь все они выполняются на едином ядре Windows. Благодаря этому одно приложение может работать на любом устройстве под управлением Windows: на телефоне у вас в кармане, на планшете или ноутбуке в вашей сумке, на компьютере у вас на столе или на консоли Xbox в вашей гостиной. Добавьте к этому еще и новые устройства в семействе Windows: HoloLens , Surface Hub и устройства Интернета вещей, такие как . Чтобы приобрести, распространить и обновить приложения, разработчики и пользователи всех этих устройств Windows теперь будут обращаться в единый Магазин.
Что касается API для определенных семейств устройств (к примеру, интерфейс номеронабирателя), универсальная платформа позволяет выделить этот функционал в приложении без условных флагов компилятора.
Сегодня я кратко расскажу о том, как новая платформа отвечает :
1. Глобальный охват различных типов устройств
2. Уникальные возможности
3. Максимальная отдача от технологий разработки
Все технические подробности об универсальной платформе будут освещены на конференции Build .
Глобальный охват различных типов устройств с помощью мобильных возможностей
Чтобы понять, почему мы объединили Windows на базе единого ядра и платформы разработки, нужно понять, что сегодня пользователи взаимодействуют с устройствами совершенно иначе и ожидают от них совсем иного. За последнее десятилетие число мобильных устройств выросло в разы, благодаря чему появились принципиально новые функции приложений, а веб-страницы обрели новый облик. Разработчики нашли инновационные и уникальные способы взаимодействия с клиентами. До настоящего времени мобильными функциями обычно обладали приложения и веб-страницы, созданные для мобильных устройств
, то есть, по сути, мобильного телефона.
Но сегодня все больше пользователей хотят использовать мобильные возможности на ВСЕХ устройствах, каждый раз выбирая то, которое лучше всего подходит для конкретной задачи.
Особенно четко прослеживается эта тенденция, если проанализировать поисковые запросы в Магазине. Всего год назад возможности для телефонов Windows были совершенно иными по сравнению с функционалом планшетов. А он, в свою очередь, отличался от взаимодействия с ноутбуками, компьютерами и игровыми консолями. Но эта ситуация быстро меняется. Сегодня поисковые запросы в Магазине для различных типов устройств часто перекрываются: как внутри категорий приложений, так и между ними.
Чтобы создать платформу, которая поддерживает целый спектр этих новых мобильных возможностей , недостаточно просто учесть различные размеры экрана. Нужно еще и дать выбор моделей взаимодействия: с помощью жестов, мыши и клавиатуры, геймпада или пера. Ведь, переходя с одного устройства на другое, пользователь быстро меняет эту модель. Например, сенсорными жестами он выбирает песню или плей-лист, читает новости или документы, просматривает фотографии из поездки. Клавиатура и мышь помогают ему в работе с офисными приложениями: он управляет плей-листами, публикует записи блога или доводит до совершенства видео или снимок, чтобы показать их другим. Чтобы восполнить пробелы в функционале устройств (если подумать, сколько из них пользователю действительно хотелось бы носить с собой?), на рынке появляются многоцелевые устройства, такие как трансформер Surface Pro 3. Эта тенденция учитывается и в области приложений, только здесь разработчики создают одну или несколько мобильных версий ПО для разных платформ, а еще настольное приложение и веб-сайт. Мы считаем, что все может (и должно) быть гораздо проще.
Windows 10 открывает новую главу в истории мобильных возможностей , выходя за рамки только мобильных устройств и позволяя клиентам с удобством пользоваться любыми форм-факторами. Эти мобильные возможности Windows основаны на едином ядре и универсальной платформе приложений.
Создавая такую платформу, мы хотим, чтобы все разработчики для Windows получили равные преимущества от единого ядра. Благодаря данной платформе появляется целый класс универсальных приложений Windows, которые достаточно написать один раз, используя один набор бизнес-правил и один интерфейс. И эти приложения будут поставляться в Магазин в виде единого пакета. Они подойдут для любого устройства под управлением Windows 10, интересного для разработчика. Такие приложения, адаптированные для каждой модели ввода данных и размера экрана устройства, будут иметь единый облик и функционал. Благодаря новой универсальной платформе приложений вы действительно сможете создать одно приложение, которое будет без проблем выполняться практически везде: на мобильных и настольных устройствах, на консолях, голографических устройствах и даже на устройствах Интернета вещей.
Уникальное и персональное взаимодействие
С помощью универсальной платформы приложений вы сможете быстро создавать новые мобильные возможности. Обладая гибкостью и единым функционалом, они лягут в основу уникальных моделей взаимодействия, которые пользователи смогут с легкостью настраивать на любом семействе устройств. Для этого мы предлагаем ряд функций платформы, которые интеллектуально адаптируют интерфейс приложения во время выполнения. Так что вам остается лишь поработать над удобством решения для клиента.
- Адаптивный пользовательский интерфейс . Интерфейс приложения будет плавно адаптироваться во время выполнения в контекстном режиме, учитывая, как пользователь взаимодействует с ним и каковы доступные возможности устройства.
- Макет экрана . Помимо базовых улучшений модели приложения, обновленный класс ViewStateManager упрощает создание адаптивных функций взаимодействия. Это значит, что в проектах универсальных приложений больше не нужно указывать отдельные заголовки или определения интерфейса для больших и малых экранов. Тем не менее отдельные определения интерфейса по-прежнему доступны.
- Пользовательское управление . В новой Windows 10 прямо во время выполнения определяется, как пользователь взаимодействует с приложением, - на основе этого и предлагается та или иная модель взаимодействия. К примеру, на ноутбуке с сенсорным экраном в приложении будут увеличены элементы для касаний (по сравнению с размером для управления мышью).
- Естественные способы ввода данных . Windows 10 позволяет создавать приложения с более естественным и персональным взаимодействием и вводом данных, поддерживая управление голосом, пером, жестами и взглядом. Поскольку в Windows уже предусмотрены все эти способы ввода, вам не придется анализировать введенные данные. Вы просто выбираете способы, которые подходят для вашего приложения: система сама установит их наличие и определит значение полученной информации.
- Облачные сервисы . В приложениях для Windows предлагается несколько видов сервисов: службы Windows Notification Services (WNS), перемещаемые данные Windows и хранилище учетных данных Windows. В Windows 10 разработчикам предоставляется больше сервисов Windows, в том числе расширенный искусственный интеллект Cortana, сервис OneDrive и средства Application Insights . Помимо Windows, мы упрощаем доступ к преимуществам Microsoft Azure с помощью таких сервисов, как мобильные службы Azure и концентратор уведомлений Azure.
Однако мы знаем, что мобильное взаимодействие не заканчивается на том, когда клиент закрывает приложение. В оболочке Windows было сделано несколько улучшений, реализованных благодаря преимуществам универсальной платформы. Ваши клиенты непременно их оценят и будут чаще запускать ваши приложения. Примеры:
- Интеграция с Cortana . Теперь приложения отображаются (и могут запускаться) прямо в результатах поиска личного помощника Cortana, при этом в верхней части списка расположены установленные решения.
- Центр поддержки . В Windows 10 уведомления обрели единый облик и практический смысл на всех устройствах Windows.
Наконец, мне хотелось бы отметить, что универсальная платформа приложений лежит в основе самой Windows 10. На ней выполняется значительная часть оболочки и ряд ключевых возможностей Windows: некоторые встроенные приложения, Магазин Windows, браузер под кодовым названием Project Spartan и ряд других. Поэтому анимации, API и элементы управления этих приложений доступны и вам. Можете не сомневаться: эта платформа была тщательно проверена в реальных условиях и позволяет создавать мобильные возможности для удобства ваших клиентов.
Максимальная отдача от кода приложений и веб-страниц.
Новая платформа Windows 10 позволяет по максимуму использовать уже имеющийся код и навыки разработки, а также расширять спектр их применения.
Windows 10 поддерживает существующие приложения Windows и настольные приложения на устройствах, для которых они были созданы. И мы хотим, чтобы вы без труда перенесли эти возможности на новую универсальную платформу приложений.
Для HTML-разработчиков в Windows 10 предусмотрен ряд улучшений для современного Интернета:
- Новый механизм визуализации . Он избавляет вас от лишней работы по унификации мобильного интерфейса для различных платформ. Механизм входит в состав браузера Internet Explorer 11, нового браузера Project Spartan, а также используется в элементе управления WebView.
- Браузер Project Spartan . Браузер Project Spartan тоже является универсальным приложением Windows и обновляется через Магазин, всегда оставаясь актуальным.
- Веб-приложения . В Windows 10 вы сможете с легкостью создать приложение Windows, которое упакует ваш веб-сайт для публикации в Магазине. После установки веб-сайт сможет обновляться и вызывать универсальные API JavaScript, предлагая пользователям привлекательные функции взаимодействия.
Библиотека программиста
«Очень важно не прерывать вопросов. Любопытство имеет свое право на существование»
Альберт Эйнштейн
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. Развитые функции этой библиотеки требуются в том случае, когда необходима визуализация крупных проектов и данных. Типичные задачи, требующие ее использования, - это САПР, системы механического и промышленного дизайна, программы статистического и научного анализа.
О руководстве
С помощью этого учебного пособия вы научитесь программированию с использованием инструментария wxWidgets. В конце каждой главы вы найдёте ссылки на остальные материалы руководства.
wxWidgets
wxWidgets это набор инструментов для создания графического пользовательского интерфейса (GUI) в C++ приложениях. Это кросс-платформенный инструментарий с открытым исходным кодом. wxWidgets приложения работают на всех основных платформах: Windows, Unix and Mac. Проект был основан Юлианом Смартом (Julian Smart) в 1992 году. Это больше чем просто набор инструментов. Он предоставляет большое разнообразие классов для работы с потоками, базами данных, командными последовательностями, интерактивной помощью и настройками приложения. wxWidgets содержит большую группу виджетов. Познакомиться с сообществом wxWidgets можно на сайте http://www.wxwidgets.org/ .
Язык программирования C++
C++ один из наиболее широко используемых языков программирования на этой планете. На нем написано большинство известных программных пакетов таких как MS Office, Macromedia Flash, Firefox, Photoshop и 3D Max. C++ доминирует в мире игр для PC. Это один из самых сложных языков программирования. С другой стороны, программирование на C++ в 2007 году отличается от программирования в 1997. Многое стало проще в наши дни.
Индекс сообщества программистов TIOBE отображает примерную долю использования языков программирования (информация ниже по состоянию на 2010 год - прим. Sl-Alex). Java рулит. C++ свергнут с престола. Но C++ служит их основой и в ближайшие десятилетия для него нет серьёзных угроз. Мы можем ясно видеть специализацию среди языков программирования. Java в основном используется в корпоративных проектах и портируемых программах, C - король в системном программировании (ОС, драйверы устройств, небольшие программы), PHP прочно закрепился на небольших и средних веб-сайтах, Javascript используется для реализации клиентской части веб-приложения.
C/C++ наиболее часто используемые языки для создания классических ГУИ (Графический Пользовательский Интерфейс (GUI)) приложений для настольных систем. Вот прекрасная , поясняющая почему Java не уничтожит C++ в ближайшие годы.
Мультиплатформенное программирование
Сегодня, мультиплатформенное программирование - это модное слово. Многие языки и библиотеки хотят стать мультиплатформенными. wxWidgets изначально создавался как мультиплатфоменный инструмент. Большинство разработчиков выбирают такие возможности. Если это возможно, используют web. Или же выбирают между Qt, wxWidgets, Swing или SWT. Так же существует такая вещь как FLTK, но он не так популярен и это не лучший выбор. В моей стране есть большая железнодорожная компания. Эта компания использует ПО написанное на Java и Swing. Этот выбор обусловлен тем, что дешевле купить новое оборудование и написать ПО на Java. Используя Java, скорость разработки возрастает и количество багов уменьшается. Конечно, такой выбор правильный. Но когда мы пишем текстовый редактор на Java мы не можем сказать нашим заказчикам, эй ребята, вам нужно будет докупить ещё 1 Гб памяти. В такой ситуации Java нам мало чем может помочь. Что касается Qt, то эта библиотека главный конкурент wxWidgets. Поэтому для каждой задачи нужно использовать правильный инструмент - это самое важное решение любого программиста и менеджера.
Дорогие хабравчане!
Хотел бы попродробнее рассказать вам про одно из самых интересных на мой взгляд нововведений . Речь пойдет про одновременную разработку приложений для 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Так что вполне можно начать знакомиться с новой платформой. Давайте я сделаю небольшой экскурс, описав некоторые отличия.
Начну с того, что приложения 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} В чем отличие? Компилируемые работаю гораздо быстрее, а формируются/проверяются они во время компиляции а не во время запуска приложения. Также они строго типизированные.Подробнее здесь.