Как шарить код в универсальных приложениях

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

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

The new Univeral app projects

Конечно же у нас есть возможность адаптировать дизайн для каждого устройства. Мы также можем использовать директивы и частичные классы в общем проекте, чтобы определить специфичный код, который будет собираться под каждым приложением. Таким образом, у нас есть один общий пункт сбора для Windows 8.1 и Windows Phone 8.1 проектов, но мы также можем написать собственный код для каждого из них.

Но что же делать, если мы хотим шарить код между различными приложениями, потому что, например, мы хотим перераспределить наши библиотеки? Прежде всего, мы можем подумать об использовании портативных библиотек. Этот тип проекта был улучшен в Visual Studio 2013 Update 2 и теперь, если мы нацелены на Windows 8.1 и Windows Phone 8.1, мы сможем использовать всё общее API. Тем не менее PCL производит единственный двоичный файл, который работает на всех поддерживаемых платформах. Обработка расходящегося API требует использования абстракции более высокого уровня, например, инъекции зависимостей или IoC контейнеры. Мы не можем просто использовать директивы для определения, к какой платформе будет принадлежать код/

К счастью, есть другое решение. Недавно было выпущено расширение под Visual Studio 2013 под названием Shared Project Reference Manager, который позволяет использовать одну и ту же концепцию универсального общего проекта практически с любым C#, VB.NET, C ++ и т.п.. Давайте посмотрим, как его использовать.

Прежде всего, создать два класса библиотек, один для Windows, и второй для Windows Phone. Они будут содержать любой код, если это необходимо.

Libraries for Universal apps

После мы должны добавить новый общий проект к решению. Этот шаблон был добавлен в IDE после установки расширения, описанного выше.

Shared Project

Замечание: очень важно заметить, что выделение должно быть именно на “Visual C#”, т.к. если оно будет на каком-либо другом, например “Universal Apps”, это шаблон НЕ будет представлен.

После этого щелкните правой кнопкой мыши на пункт “Reference” в обеих библиотеках классов, выберите команду  Add Shared Project Reference и в новом окне нажмите на общий проект, который мы только что создали.

Shared Project Reference ManagerТеперь мы можем приступить к созданию любого файла в этом новом общем проекте, как мы делаем это всегда. Поведение будет такое же, как и у основных проектов — все, что мы к нему добавим, будет автоматически доступно в обоих конкретных библиотеках.

Shared Project Library

Вот и вся суть нового расширения, которое помогает значительно улучшить распределение кода и сделать его еще более универсальным.

 

Ссылка на источник: How to share code among different Universal Windows apps

Tagged with: , , , , ,
Опубликовано в Development, Windows 8.1

Task.Run vs Task.Factory.StartNew

В NET 4 Task.Factory.StartNew был основным методом планирования новой задачи. Многие перегрузки, предоставляемые высоко конфигурируемый механизм, который имеет гибкий набор параметров задаваемых в произвольном порядке, которые позволяют отменить и контролировать порядок выполнения. Обратной стороной гибкости является сложность. Вы должны знать, когда и какую перегрузку использовать, какой планировщик и тому подобное.

Так, в .NET Framework 4.5, была введен новый метод Task.Run. Это никоим образом не отменяет Task.Factory.StartNew, а должен рассматриваться просто как быстрый способ, для использования Task.Factory.StartNew без необходимости указания кучи параметров. Это ярлык. На самом деле, Task.Run фактически реализован по той же логике используемой для Task.Factory.StartNew, просто получил параметры по-умолчанию. Вы просто передаете Action в Task.Run:

Task.Run(someAction);

что будет эквивалентно:

Task.Factory.StartNew(someAction, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default);

Таким образом, Task.Run может и должен использоваться для наиболее распространенных случаев разгрузки некоторой работы, которые будут обработаны в ThreadPool. Это не значит, что Task.Factory.StartNew никогда не будет использоваться; это далеко не так. В Task.Factory.StartNew по-прежнему остается еще много важных (более продвинутый) возможностей. Вы можете контролировать TaskCreationOptions для понимания того, как задача будет вести себя, так же вы можете контролировать планировщик  и т.д.

Task.Run обеспечивает восемь перегрузок, поддерживает все следующие комбинации:

  1. Task vs Task<TResult>
  2. Cancelable vs non-cancelable
  3. Synchronous vs asynchronous delegate

Первых два пункта должны быть очевидными. Для первого: есть перегрузки, которые возвращают Task (для операций, которые не имеют результата) и есть перегрузки, которые возвращают Task <TResult> (для операций, которые имеют результат типа TResult). Есть также перегрузки, которые принимают CancellationToken.

Третий пункт более интересный и напрямую связаны с поддержкой асинхронного языка в C # и Visual Basic. Остановимся на мгновение на Task.Factory.StartNew. Если я напишу следующий код:

var t = Task.Factory.StartNew(() =>
   { 
      Task inner =Task.Factory.StartNew(() => {});
      return inner; 
   });

тип «T» будет Task <Task>; делегат задачи типа Func <TResult>, TResult в данном случае является Task’ом, и, таким образом StartNew возвращается Task<Task>. Точно так же, если бы я изменил на это:

var t = Task.Factory.StartNew(() => 
   { 
      Task<int> inner = Task.Factory.StartNew(() => 42)); 
      return inner; 
   });

тип «T» теперь будет Task<Task<int>>. Делегат задачи является Func <TResult>, TResult теперь Task<int>, и, таким образом StartNew возвращает Task<Task<int>>. Почему это уместно? Рассмотрим теперь, что произойдет, если я напишу следующее:

var t = Task.Factory.StartNew(async delegate 
   { 
      await Task.Delay(1000); 
      return 42; 
   });

Используя ключевое слово async, компилятор собирает этот делегат в Func<Task<int>>: вызов вернет Task<int>. А так как делегат Func<Task<int>>, TResult является Task<int>, и, таким образом, тип «t» будет Task<Task<int>>, не Task<int>.

Чтобы обработать все эти случаи, в NET 4 был введен метод Unwrap. У Unwrap есть две перегрузки, обе из которых являются расширениями, один типа Task<Task>, второй Task <Task<TResult>>. Назвали этот метод Unwrap, потому что он, по сути, «разворачивает» внутреннюю задачу, которая вернулась в результате выполнения внешней. Вызов Unwrap на Task<Task> дает Вам новую задачу, которая представляет собой возможное завершение внутренней задачи. Точно так же, вызывая Unwrap на Task<Task<TResult >> Вы получите новый Task <TResult>, который представляет собой возможное завершение этой внутренней задачи. (В обоих случаях, если во внешней задаче возникла ошибка или она была отменена,то внутренней задачи не будет, так как нет никакого результата от задачи, которая не дошла до конца). Вернемся обратно к предыдущему примеру, если бы я хотел видеть ‘t’ возвращаемым результатом (в данном случае это значение 42), я мог бы написать:

var t = Task.Factory.StartNew(async delegate 
   { 
      await Task.Delay(1000); 
      return 42; 
   }).Unwrap();

Переменная ‘t’ теперь будет типа Task<int>, представляющего результат асинхронного вызова.

Приступим к рассмотру Task.Run. Поскольку ожидается, что этот функционал будет характерным для людей, которые хотят разгрузить работу в ThreadPool и для этого использовать async/await, было принято решение взять на вооружение Task.Run. У Task.Run есть перегрузки, которые принимают Action, Func <TResult>, Func <Task> и Func<Task<TResult>>. Внутренне, впринципе, Task.Run делает то же самое, что и Task.Factory.StartNew выше. Так что, когда я пишу:

var t = Task.Run(async delegate 
   { 
      await Task.Delay(1000); 
      return 42; 
   });

тип «t» является Task <int>, и реализация этой перегрузки Task.Run в основном эквивалентна:

var t = Task.Factory.StartNew(async delegate 
   { 
      await Task.Delay(1000); 
      return 42; 
   }, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default).Unwrap();

Как и упоминалось ранее — это всего лишь ярлык.

Приведем еще небольшой пример с использованием await:

int result = await Task.Run(async () => 
   { 
      await Task.Delay(1000); 
      return 42; 
   });

тип результата будет int и примерно через секунду после начала работа переменной result будет присвоено значение 42.

Интересно, что ключевое слово await можно рассматривать как почти эквивалентный методу Unwrap. Так, если мы вернемся назад к Task.Factory.StartNew, то я мог бы переписать последний фрагмент выше следующим образом (используя Unwrap):

int result = await Task.Factory.StartNew(async delegate 
   { 
      await Task.Delay(1000); 
      return 42; 
   }, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default).Unwrap();

или, вместо того чтобы использовать Unwrap, я мог бы использовать еще раз await:

int result = await await Task.Factory.StartNew(async delegate 
   { 
      await Task.Delay(1000); 
      return 42; 
   }, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default);

 await await — не опечатка. Task.Factory.StartNew возвращается Task<Task<int>>. Если мы дождемся выполнения Task<Task<int>> то получим Task<int>, и если и далее так продолжать, то дождясь Task <int> получим int.

Вот и вся разница между этими функционалами. Всем удачного программирования и не переусердствуйте с фоновыми задачами:)

 

Ссылка на источник: Task.Run vs Task.Factory.StartNew

Tagged with: , , , , ,
Опубликовано в .Net, Development, Windows 8.1

SQLite в универсальных приложениях. Часть 2

В этой серии постов, я опишу, как построить SQLite приложение, которое будет работать в средах выполнения Windows устройств (Windows 8.1 и Windows Phone 8.1).

В первой стать я кратко рассказал об универсальных приложениях и о том, как добавить SQLite в проект.

Во второй части мы рассмотрим, как использовать универсальный проект, чтобы избежать ненужного дублирования кода посредством совместного использования, которое остается одинаковыми для Windows Store приложений и для Windows Phone Store приложений, и как воспользоваться SQLite для управления локально хранимыми данными.

В первом посте мы создали универсальное приложение, со всеми правильными ссылками на SQLite библиотеки.

Чтобы помочь нам скрыть все сложности вызова SQLite API мы добавим sqlite-net библиотеку на оба проекта: Windows, и Windows Phone, используя NuGet:

В результате, у нас будет по две копии файлов «SQLite.cs» и «SQLiteAsync.cs», один в проекте Windows, и один в проекте Windows Phone:

Чтобы избежать ненужного дублирования, давайте начнем с использования общего проекта:

Переместите одну копию «SQLite.cs» и «SQLiteAsync.cs» файлов в общий проект. Удалите вторую копию.

В конце концов получим:

Использование sqlite-net очень просто, и есть много постов, описывающих, как это делать, например, Using SQLite in your Windows 8 Metro style applications от Matteo Pagani.

Рассмотрим основные операции:

Открыть таблицу под названием “People.db” (будет создана, если несуществует) :

По-умолчанию таблица будет создаваться sqlite-net библиотекой в:

Так можно проверить наличие базы данных:

Создание таблицы

Для начала необходимо создать класс, который будет представлять оду таблицу

Как вы видите, есть возможность пользоваться атрибутами, которые определенны в sqlite-net библиотеке. Вот весь перечень доступных атрибутов:

Атрибуты классов:

  • [Table(Name)]

Атрибуты свойств:

  • [AutoIncrement]
  • [PrimaryKey]
  • [Column(Name)]
  • [Indexed] | [Indexed(string name, int order)]
  • [Unique]
  • [Ignore]
  • [MaxLength(int length)]
  • [Collation(string name)]
  • [NotNull]

Конечно же класс User это наша модель, которая будет использоваться в обоих проектах, поэтому создадим папку  Model в шареном проекте:

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

Метод будет проверять существование таблицы в файле данных SQLite и если не найдет ее — создаст. Кроме того, если класс, который представляют собой таблицу, изменился, метод будет пытаться обновить таблицу SQLite (на самом деле, поддерживается только добавление новых столбцов)

Стоит отметить, что метод не будет уничтожать существующую таблицу.

Запись в таблицу

Это очень легко!

Несколько записей одновременно

Любую IEnumerable коллекцию можно добавить в таблицу:

Получение содержимого

Мы можем обращаться к таблице использую Linq:

или же обычные запросы:

SQL команды могут содержать параметры:

Обновление

Уже записанные данные можно легко изменить на уровне модели, сохраняя их в базе данных

Удаление

Удаление записи

Удаление таблицы

Проще простого!:

Демо

Чтобы продемонстрировать, как использовать SQLite-чистую библиотеку я создал очень простое демонстрационное приложение.

Для простоты я не использовал MVVM. Более того, я создал одну страницу XAML как для Windows, так для и Windows Phone проекта. В рабочем коде вы, вероятно, используете MVVM (Model View ViewModel) и некоторое количество страниц XAML, специально разработанных для каждой платформы.

Чтобы продемонстрировать использование (или злоупотребления, в данном случае), я создал отдельную страницу XAML в общем проекте. десь вы можете увидеть CommandBar, которой на Windows Phone показывает PrimaryCommands (максимум пять) и SecondaryCommands (MenuItems):

Поскольку файл XAML является одинаковым как для Windows так и для Windows Phone, я перенес его в общий проект и удалил из обоих.

В конце концов получилось следующее:

Демо из Windows Phone

Это заключение второго поста о том, как использовать универсальное приложение избегая ненужного дублирования кода посредством совместного использования, которые остаются одинаковыми для Windows Store и для Windows Phone Store, и как воспользоваться SQLite для локального управления хранимыми данными.

 

Ссылка на источник: Universal App with SQLite – Part 2

Tagged with: , , , , ,
Опубликовано в Development, Windows 8.1

SQLite в универсальных приложениях. Часть 1

В этой серии постов, я опишу, как построить SQLite приложение, которое будет работать в средах выполнения Windows устройств (Windows 8.1 и Windows Phone 8.1).

В этой первой статье я кратко представлю новый «Universal Apps» в виде Visual Studio проекта, и объясню, как добавить SQLite в проект.

Для всего этого на необходимо создать наш тестовый универсальный проект:

 

Идея проста, но элегантна. Теперь, когда Windows Phone уже выпущен (хоть и в тестовой версии), мы можем получить одну папку проекта, содержащий три проекта, один для Windows, один для Windows Phone App Store, и один дополнительный (о всех нюансах построения универсального проекта вы можете почитать в моих предыдущих статьях):

Во-первых, вы должны работать в Visual Studio 2013 и установить как минимум  обновление Visual Studio 2013 Update 2 Release Candidate.

После этого вы должны создать новое пустое универсальное приложение и назовите его «SQLiteTest»:

Теперь, когда у вас есть свой проекта, необходимо добавить SQLite. На самом деле, единственный способ сделать это с помощью SDK расширения для Visual Studio — вам будет необходимо добавить его в два проекта, один для ОС Windows App Store, и один для Windows Phone Store App.

Первое расширение доступно как VSIX пакет, созданного официальной командой SQLite:

Скачайте и установите его

Второй расширение также доступно в качестве VSIX пакет — SQLite for Windows Phone 8.1

Чтобы проверить, что все в порядке, вы можете открыть Visual Studio 2013 «Инструменты | Расширения и обновления» и найти установленные пакеты SDK:

После того как вы скачали и установили VSIX пакеты, вы, наконец, готовы добавить SQLite ссылки в ваши проекты.

Во-первых, щелкните правой кнопкой мыши на ссылки SQLite.Test.Windows (Windows 8.1) проекта:

Затем добавьте ссылку на «SQLite для Windows Runtime (Windows 8.1)» библиотеку

Тоже самое необходимо проделать с Windows Phone 8.1 проектом

Добавить ссылку на SQLite for Windows Runtime (Windows Phone 8.1) соответственно

Когда это сделано, вы можете увидеть, что надлежащие ссылки на SQLite и Visual C + + 2013 Runtime были добавлены в соответствующие проекты:

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

«The processor architecture of the project being built “Any CPU” is not supported by the referenced SDK “SQLite.WinRT81, Version=3.8.4.3″. Please consider changing the targeted processor architecture of your project (in Visual Studio this can be done through the Configuration Manager) to one of the architectures supported by the SDK: “x86, x64, ARM».

Решение это проблемы очень простое! Состоит из следующих действий: откройте Configuration Manager и установить платформу для x86 для проектов в Debug и Release конфигурациях. Не выбрал x64, т.к. дизайнер XAML не сможет показать интерфейс.

Это не помешает вам создавать приложение под различные платформы для развертывания на магазине, потому что, когда вы будете готовы запаблишить и начнете создавать пакеты, вам всего лишь надо будет выбрать все платформы:

для Windows 8.1:

и для Windows Phone 8.1:

Это мой первый пост о том, как создать (и успешно построить) универсальный проект с использованием SQLite.

 

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

 

Ссылка на источник: Universal App with SQLite – Part 1

 

Tagged with: , , , , ,
Опубликовано в Development, Windows 8.1

Windows/Phone 8.1–разработка для обоих. Часть 3

Эта статья является продолжением из предыдущей. Перед прочтением данной рекомендую пересмотреть предыдущие из данной серии.

Создадим новое универсальное приложение

Visual Studio уже поддерживает универсальные проекты. Они предназначены не только для. NET приложений, вы также можете создавать их на других платформах (например HTML / JS);

clip_image002

Вы также можете заметить, что можно создать как универсальную портативную библиотеку классов так и runtime component.

Структура проекта

Что мы увидим, когда создадим такой проект?

clip_image004

На скриншоте выше отображена структура приложения для Windows, Windows Phone и общего проекта.

В ОС Windows/Phone приложения есть вещи, которые вы возможно ожидали, учитывая предыдущие дискуссии вокруг «одно приложение для всех». Использование Windows 8.1 приложения в качестве примера:

clip_image006

У приложения Windows 8.1 есть:

  1. Собственный файл MainPage.xaml и MainPage.xaml.cs.
  2. Собственный манифест приложения.
  3. Собственные активы для различных логотипов и т.п.
  4. Набор ссылок:
  •                 . NET для Windows Store приложений
  •                 Windows 8.1 (т.е. WinRT)
  •                 Общий проект.

В Windows Phone 8.1 приложении то же самое:

clip_image008

Есть несколько различных логотипов, с учетом масштабирования.

Имеется ссылка на «Windows Phone 8.1» (WinRT), а не «Windows 8.1».

Что нового в проекте shared

Логика общей папки очень похожа на подход с линковаными  (ссылочными, связанными) файлами в Visual Studio.

Во-первых, общая папка появляется на диске в таком виде;

clip_image010

Это настоящая папка, а не только часть концепции внутри Visual Studio. Таким образом, элементы внутри этой папки, по сути, строятся дважды — один раз в рамках проекта для Windows 8.1 и другой — в контексте проекта Windows Phone 8.1.

Это означает, что если вы собираетесь работать в shared проекте, вы должны учитывать тот факт, что данный код должен одинаково хорошо работать одновременно на обоих платформах.

Класс App

По-умолчанию данный класс находится в shared проекте в Visual Studio. В нем по сути ничего нет, взглянем:

clip_image012

хотя я думаю, довольно сказать, что мы используем один и тот же базовый класс приложений и тот же вариант XAML для Windows/Phone 8.1.

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

clip_image014

Например, здесь есть условная компиляция некоторых элементов для WINDOWS_PHONE_APP, которые не работают в Windows 8.1. Очевидно, т.к. файл компилируется в два раза.

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

clip_image016

а теперь переключим в режим Windows Phone

clip_image018

IntelliSense также фильтруется с помощью этой панели навигации. В качестве примера, есть класс в Windows Phone 8.1, который называется ContentDialog и не является частью ОС Windows 8.1. Если я использую этот класс в контексте  Windows Phone 8.1, то все хорошо, хотя IntelliSense предупреждает меня о наличии

clip_image020

И вот что мы увидим, если переключимся в режим Windows 8.1:

clip_image022

Простенький пример

Давайте предположим, что я хочу создать простой пример приложения с TextBlock и Button и кнопкой запуска браузера.

Начнем с ресурсов:

clip_image024

И вы заметите, что формат файла ресурсов, который я использую здесь Resources.resw, что является форматом ресурсов Windows 8.1.

Затем определим немного «UI» на Phone в файле MainPage.xaml. Например;

clip_image026

clip_image028

И напишем немного кода для обработки нажатия:

clip_image030

И это работает просто отлично!

Когда дело доходит до части Windows 8.1, то я понимаю, что можно просто использовать точно такой же интерфейс, так почему бы не скопировать MainPage.xaml и MainPage.xaml.cs в общую папку?

clip_image032

Как и следовало ожидать, при компиляции я получаю список ошибок

clip_image034

какие кажутся справедливыми. Чтобы исправить, я могу просто удалить файлы MainPage.xaml/MainPage.xaml.cs из Windows/Phone проектов, оставив единственный экземпляр в общей папке.

Это работает отлично!

Что же касается Portable Class Library?

Вместо того, чтобы держать код в папке общего доступа, я могу положить его в PCL, как мы делали это раньше при шаринге кода между WinRT и WP.

Если я добавить новую библиотеку класса в мой проект:

clip_image036

После я могу написать некоторый класс, который делает вызов класса Launcher:

using System;  
using System.Threading.Tasks;  
using Windows.System;  
namespace CrossPlatform  
{  
   publicstaticclass Class1  
   { 
      publicstatic async Task Launch()  
      {  
          await Launcher.LaunchUriAsync(new Uri("http://www.microsoft.com"));  
      }   
   }  
 }

«Интересным» является то, что эту портативную библиотеку классов я не могу добавить ссылкой в мой общий проект (shared).

Вместо этого я добавить ссылки к обеим проектам отдельно;

clip_image038

И уже после этого я могу писать в общих классах код, ссылаясь на PCL.

clip_image040

что является само собой немного непривычным для первого раза

 

В итоге

Visual Studio 2013 с обновлениями позволяет создавать «универсальный» проект, который содержит два проекта — один для каждого Windows/Phone наряду с общей папкой, которая будет построена два раза — один раз в контекст приложения для Windows и снова в контексте Phone.

Все срабатывает на отлично и сама среда прекрасно понимает эту идею и показывает вам правильный IntelliSense и дизайнер при редактировании общих файлов (в зависимости от платформы, в которой вы работаете на данный момент).

 

Ссылка на источник: Windows/Phone 8.1 – Building for Both, Part 3

 



									
Tagged with: , , , , , , ,
Опубликовано в Development, Windows 8.1

Windows/Phone 8.1–разработка для обоих. Часть 2

Данный пост является продолжением первой части.

Сходство данных платформ

API этих двух платформ все больше и больше становятся похожими на друг на друга.

clip_image002

Эта картинка явно показывает, что WinRT занимает еще более больший набор API-интерфейсов для Windows Phone 8.1 приложений, чем это было в Windows Phone 8.0 и, на высоком уровне, я думаю, вы могли бы рассматривать эту проблему как «тот же самый набор WinRT API, что и для разработчика Windows 8.1», хотя это и не совсем верно, когда дело доходит до деталей.

Я нарисовал пунктирные линии вокруг Win32, Silverlight, NET API, в приведенной выше диаграмме, потому что не каждый разработчик 8.1 приложений назвал бы это API, все зависит от того, что приложение делает, но каждый разработчик 8.1 приложений будет использовать WinRT API, так или иначе.

Я думаю, что справедливо сопоставить данные платформы по приведенной ниже схеме;

clip_image004

Теперь XAML на Windows и Phone одно и тоже. Это означает, что;

  1. Сопоставления пространства имен CLR будут работать таким же образом.
  2. Встроенные типы, как х:String и т.п. будут работать так же.
  3. Возможности привязки данных и синтаксис будет работать таким же образом и т.д.

Важно также отметить, что подмножество. NET, которое представлено как в Windows так и Phone 8.1 — это одно и то же подмножество .NET, поэтому общий код может быть расположен в общем слое.

Windows Phone 8.1 обратно совместимая ОС — приложения и игры из предыдущих версий операционной системы будет продолжать работать и разработчики, имеющие существующую Silverlight приложение не должны пересоздавать их для Windows Phone Winrt, для этого существует возможность ретаргерить его до Windows Phone 8.1 Siverlight. Последняя возможность предоставляет следующий рисунок

clip_image006

Это означает, что Silverlight разработчик продолжает работать с «Silverlight XAML» и продолжает работать с «Silverlight. NET”, но также получает доступ к новым API WinRT, которые были расширены для Windows Phone 8.1.

Схожесть — это не означает, что одно приложение можно будет запускать везде

Разработчики, которые разрабатывают для Windows/Phone 8.1 на новой платформе будут по-прежнему писать 2 приложения и представлять их в магазине отдельными приложениями.

Тем не менее, возможность для шаринга кода между этими двумя приложениями становится значительно больше с Windows Phone 8.1, чем это было до настоящего времени. С точки зрения разработчика XAML:

clip_image008

В данный момент можно получать два приложения с различным интерфейсом, которые используют общий .NET код и API-интерфейсы платформы Win32.

Это означает, что традиционная «проблема» (невозможность разработки полноценной портативной библиотеки классов) уходит — сейчас код, встроенный в PCL, может использовать WinRT для доступа к файловой системе, камере, сети и так далее, т.к. API WinRT доступно теперь  на обоих платформах Windows/Phone.

Общий XAML — что это значит?

Теперь можно разрабатывать на XAML сразу для обеих платформ — Windows/Phone 8.1. Как и следовало ожидать, есть некоторые тонкости. Мы всегда должны помнить, как выглядят контролы на этих двух платформах:

clip_image010

Распределяются они на 4-е категории:

  1. Контрол, такой как Button, одинаковые элементы управления на обеих платформах и делают то же самое.
  2. Контрол, такой как Hub (Windows 8.1), которые одинаковы в управлении на обеих платформах, но, скорее всего, будут иметь различный контент внутри себя на каждой платформе.
  3. Контрол, такой как DatePicker, у которых одинаковое управление на обеих платформах, но работают по-другому.
  4. Контрол, такой как Pivot, которые существуют только на одной платформе — в случае Pivot это только Windows Phone.

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

Общий WinRT — что это значит?

Здесь намного больше общего, чем в том же XAML.

clip_image012

Очень много из API будет одинаковое и это больше повлияет написание ​​кода. Разработчики под Windows Phone заметят на порядок больше изменений, чем, например, разработчики Windows 8.1. Например:

clip_image014

разработчик собирается использовать WinRT API, для данного вида функциональности, тогда как в Phone 8.0 использовались Silverlight.NET API-интерфейсы.

Есть еще несколько последствий — использование API-интерфейсов WinRT для уведомлений, например, Windows Phone 8.1 использует Windows Notification Service.

Описанная выше картина свидетельствует, что есть некоторые API-интерфейсы, которые все еще привязаны к определенной платформе.

В итоге.

В ОС Windows/Phone 8.1 платформы гораздо более сильно унифицированы, чем ранее. Windows Phone 8.1 поддерживает ряд различных способов построения 8.1 приложений:

  1. XAML / C + +
  2. XAML / .NET
  3. Silverlight 8.1

И это не считая вариантов вокруг разработки игр.

Схожесть API, которое значительно унифицировано, должна значительно упростить жизнь разработчикам XAML.

Ссылка на источник: Windows/Phone 8.1 – Building for Both, Part 2

 

 

 

 

 

 

Tagged with: , , , , ,
Опубликовано в Development, Windows 8.1

Windows/Phone 8.1–разработка для обоих. Часть 1

Ну я думаю уже все знают, что совсем недавно на конференции Build было представлено новое обновление для Windows и Windows Phone, поэтому сильно разглагольствовать не буду и сразу переду к фактам, которые влияют а нас сейчас и будут влиять в ближайшем будущем.

Для начала подчеркнем некоторые основные вещи:

  • Это обновление будет доступно всем существующим Windows Phone 8 пользователям и будет поставляться предварительно установленной на новых телефонах;
  • Она работает с существующими приложениями/играми, запущенные на 8.0 сегодня.
  • Там много новых функциональных возможностей конечного пользователя, которое нет смысла описывать здесь…;
  • Разработчик может продолжать работать на 8.0 приложениях/играх и публиковать новые версии в магазине в уверенности, что приложение будет продолжать работать на всех 8.0 и 8.1 устройствах.

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

 

Куда мы пришли?

Всю ситуацию на обеих платформах можно обрисовать рисунком ниже

clip_image002

Это данные с портала  “Microsoft by the Numbers” и я думаю некоторых из вас они точно удивили.

Учитывая, что у нас есть 2 платформы: «Windows» и «Windows Phone», то было бы разумно ожидать, что будет в значительной мере равное количество приложений на них. Но, есть 100 000 разрыв между двумя магазинами. Некоторые причины, из-за которых это могло случиться:

  • Магазин для Windows Phone существует дольше магазина для Windows 8.
  • Разработчики обычно подразумевают телефоны, когда думают о разработке под мобильные платформы, а не о планшетах/ноутбуках и т.п.. Если верить статистике, то только 12% разработчиков думают не только о телефонах, когда начинают разрабатывать свое приложение.

Я думаю что все сводиться к нескольким причинам:

clip_image004

Приложение в разных, хоть и похожих, платформах используются тоже по-разному. Так же приложения находятся в двух разных магазинах. Ну и конечно же, это два разных приложения, а соответственно больше работы и денег будет потрачено на них.

 

Телефоны “другие”

clip_image006

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

Планшеты очень разные, они довольно таки редко покидают ​​дом, включаются и выключаются часто.

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

Интересно взглянуть на пару приложений и посмотреть, как они проводят эту разницу между Windows/Windows Phone…

На примере рассмотрим официальное приложение Twitter:

clip_image008

OneNote:

clip_image010

Мы с вами видим совершенно разные приложения во втором случае (т.е. они действительно мало чем похожи) и практически  одинаковые в первом. И есть действительно очень много приложений в wp маркете, которые очень сильно отличаются от своих “собратьев” в windows store. И здесь очень сложно найти какой-либо правильный путь…в действительности все будет зависеть от потребностей пользователя и случаев, в которых он будет пользоваться тем или иным функционалом.

Но есть и еще одно существенное отличие между ними…

 

Разные платформы

Все кто работали с обеими платформами могут согласиться со мной, что между ними действительно большое отличие.

Windows Phone для разработчика можно отобразить как:

clip_image012

UI слой здесь я назвал «Silverlight XAML», потому что Silverlight рендеритсяг на Windows Phone 8.0. Это интерфейс может быть создан в XAML или он может быть создан в коде.

У приложения есть некоторый код, который так или иначе связывает этот слой пользовательского интерфейса с нижними. Основным API для Windows Phone 8.0 приложения я назвал «Silverlight. NET», который представляет собой подмножество .NET Framework’а, специально разработанного для “телефонных” приложений.

Когда вы смотрите на платформу Windows, 8.1, складывается совершенно другое впечатление:

clip_image014

Во-первых, здесь есть более широкий выбор — разработчик может создавать собственные приложения, используя HTML/CSS как слой пользовательского интерфейса или XAML. Они могут смешивать и сочетать UI слой с кодом, написанным на JavaScript/C++/.NET.

В основе этого кода, в большинстве случаев, WinRT, который в значительной степени обеспечивает всех разработчиков доступом к файловой системе, к камере или сети и т.п. Есть также небольшое количество Win32 API, доступны разработчику, но большинство не обязаны их использовать.

Что общего между ОС Windows 8.1/Phone 8.0, подчеркивает диаграмма ниже:

clip_image016

.NET разработчики могут создавать портативную библиотеку классов, которую можно использовать как на Windows 8.1/Phone 8.0, но разработчик несколько ограничен и код, который можно встроить в эту библиотеку, может содержать только ссылку на подмножества API, которые действительно являются общими для обеих платформ; а это подмножество небольшое .

Это означает, что, например, портативная библиотека классов не может содержать код, который предназначен для доступа к камере или обновления плитки. Такие проблемы делают портативный код полезным только в контексте абстракции.

Разработчики, работающие с шаблоном MVVM относительно хорошо себя чувствуют. Им необходимо сделать различные отображения (UI) для Windows/Phone и обеспечение связанными классами (ViewModels),  с помощью которых осуществляется привязки данных.

clip_image018

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

 

Пример

clip_image020

Как вы видите есть Windows 8.1 и Windows Phone 8.0 приложение и кроссплатформенная портативнаz библиотека классов, ссылка на которую есть в обоих приложениях. Большая часть кода в этом простом решении находится в кросс-платформенной библиотеки и разбита на модели, вьюмодели и сервисы.

clip_image022

Приложение использует 1 класса модели, 4 портативные вьюмодели. В свою очередь, они полагаться на 3 сервиса:

  • Служба для доступа к Flickr (IFlickrService)
  • Служба для загрузки фото и сохранения его в библиотеку фотографий на устройстве (IPhotoSavingService)
  • Служба для навигации (INavigationService).

Из этих 3 услуги, сервис Flickr можно сделать портативным, т.к. он просто использует портативный класс HttpClient и десериализацию данных JSON (с помощью портативной библиотеки JSON.NET).

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

clip_image024

Каждый проект также определяет свой собственный код запуска в виде файла App.xaml и App.xaml.cs и каждый проект предоставляет свои собственные View используя XAML.

clip_image026

Если посмотреть какое-либо отображение (View) — оно состоит полностью их xaml и привязки данных.

clip_image028

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

 

В итоге

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

 

Ссылка на источник: Windows/Phone 8.1–Building for Both, Part 1

 

Tagged with: , , , , , ,
Опубликовано в Development, Windows 8.1

Ссылка на ваше приложение в результатах поиска

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

Сегодня я рад рассказать Вам о Bing App Linking, чтобы помочь сделать ваше  Windows и/или Windows Phone приложение более популярным и распространенным, и предоставить пользователям новые возможности по взаимодействию с ним. После нескольких простых шагов вы можете легко “связать” свое приложение с поиском Bing в Windows Smart Search и Windows Phone. Например, если у вас есть турагенство и приложение на Windows Phone, то любой, кто будет искать «Отели Парижа» (естественно с помощью Bing на Windows/Windows Phone) будет видеть ссылку на ваше приложение наряду с релевантными результатами поиска вашего сайта. С помощью одного клика пользователь может перейти в ваше приложение на информацию об отелях Парижа или, если оно еще не установлено, установить.

Более десятка приложений уже используют Bing App Linking, в том числе Hulu, Foursquare, TripAdvisor, Amazon, Kayak, и EBay. Посмотрите «Modern Family» в ОС Windows 8.1 Smart Search и одним щелчком мыши вы можете перейти в приложение Hulu и начать смотреть шоу. Поиск «Ferry Building» на вашем Windows Phone и переходите в приложение Foursquare. Посетите bing.com/applink для того, чтобы начать работу с вашим приложением.

Как это работает?

Реализовать всю эту красоту можно всего лишь в 4-е шага:

  1. “Привяжите” свой сайт к своему приложению через Bing webmaster portal. Вы можете остановиться здесь, если хотите чтобы приложение ссылалось на результаты сайта. Продолжите с пунктами 2, 3, и 4, чтобы добавить глубокие ссылки на релевантные результаты веб-страницы (например http://www.contoso.com/A).
  2. Подгоните разметку веб-страниц, которыебудут содержать ссылки на приложение. Разметка, основанная на schema.org, включает в себя ID вашего приложения, имя пакета и аргументы запуска.
  3. Включите возможность “ссылок” в вашем приложении и обновите приложение в магазине.
  4. Зарегистрируйте ваше приложение через Bing webmaster portal.

Когда все будет готово, “связанные” приложения для Windows отображаются в Windows 8.1 Smart Search, а “связанные” с Windows Phone — в результатах поиска на телефоне соответственно. “Связывание” поддерживается для всех Windows 8 и Windows Phone 8 (7,1) приложений и доступна сегодня на ОС Windows 8.1 и Windows Phone 8.1 устройствах. Для Windows Phone 8.0 устройств такая “ссылочность” не поддерживается. Посетите bing.com/applink для более подробной информации.

Ссылка на источник: Link Your App to Search Results

 

 

Tagged with: , , , , ,
Опубликовано в Tablets, Windows 8.1

Как изменить “шрифт по-умолчанию” при разработке Windows Store приложений

По умолчанию семейством шрифтов в Windows Store приложениях установлен Segoe UI. Это означает, что, если вы используете какой-либо контрол (например: TextBlock, RichTextBlock, кнопки, и т.д.), и если вы не установите значение этого свойства явно, то Segoe UI будет значением по умолчанию.

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

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

Это делается очень просто и сейчас я расскажу вам как… Ключевым именем ресурса семейства шрифтов, который указывает на шрифт по умолчанию, является — ContentControlThemeFontFamily.

Чтобы переопределить его, мы должны установить новое значение в App.xaml или в любом наборе ресурсов, объявленном в App.xaml.

<FontFamily x:Key="ContentControlThemeFontFamily">YOUR NEW FONT NAME</FontFamily>

Все! Теперь в вашем приложении новый шрифт по-умолчанию.

 

Ссылка на источник: How to change default font in Windows Store Apps (C#, XAML)

 

 

Tagged with: , , , , , ,
Опубликовано в Development, Windows 8.1

Написание локализованных Windows Store приложений. Часть 2.

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

Зачем нам это понадобится? Например, у вашего бизнеса могут быть разные логотипы для разных стран, также могут использоваться различные цвета и/или размера шрифта.

Давайте продолжим предыдущий пример (с первой части) с нашим приложением «My Contoso», и скажем, что приложение на рынке США использует синий логотип, в то время как приложение выпущенное для рынка Великобритании имеет красный логотип.

 Лого

Как и во всех других локализованных ресурсах, вам просто необходимо создать вложенную папку в  /images, соответствующую каждому применимому стандарту. В нашем примере, мы будем использовать en-US (USA) и en-GB (UK).

Затем поместите каждый из ваших локализованных логотипов в соответствующие папки, используя одинаковые имена для каждого.

При этом вы также может включать файлы с различным уровнем масштабирования для каждого изображения.

Стили

Для приложений, написанных на JavaScript, стили находятся в файлах CSS так что вы просто можете создать конкретный файл CSS для каждого региона с соответствующими стилями:

Для US:

.hubpage .hub .section1 {
  width: 520px;
  color:blue;
}

Для GB:

.hubpage .hub .section1 {
  width: 320px;
  color:red;
}

После того, как мы сделали локализацию логотипов, создадим вложенные папки и поместить соответствующие файлы CSS.

Повторите этот процесс со всеми CSS для каждой страницы.

Вот результаты для рынка США:

Для Британии:

Необходимо разместить резервный контент в корневой папке. По сути, это будет контент по-умолчанию, на случай, если локализация пользователя не совпадет ни с одной из зарезервированных.

Выводы

Мы рассмотрели пару примеров приложений, которые полагаются на средства и методы локализации. С помощью API Глобализация Windows, и нативной структуры приложений, мы увидели процесс создания контента, который адаптируется к местности пользователя без дополнительных действий.

Преимущество глобализации и локализации приложения не может оспариваться, так как таким образом мы как минимум расширяем свой рынок, привлекая большее количество пользователей и соответственно увеличивая возможность заработка.

Ссылка на источник: Writing Windows Store apps with locale-based adaptive design

 

Tagged with: , , , ,
Опубликовано в Development, Windows 8.1