Блог Сергея Байдачного

В первой версии Windows Phone (7) разработчик имел очень ограниченный доступ к камере. Фактически вся работа сводилась к вызову стандартного приложения по работе с камерой с помощью класса CameraCaptureTask. Объекты этого класса обладают методом Show, способным инициировать стандартное приложение по работе с камерой (и деактивировать Ваше), а с помощью обработчика события Completed можно было получить отснятое изображение. Подобный подход хорош, если Вам не нужна тесная интеграция с камерой и не хочется делать дополнительную работу.

А вот в Windows Phone 7.5 разработчик получил значительно больше возможностей. При этом слово «больше» явно преуменьшает тот набор функциональности, который можно использовать сегодня. По большому счету Вы можете без труда написать собственное приложение по работе с камерой, позволяя пользователю устанавливать различные настройки. При этом речь идет как о создании фотографий, так и о полном доступе к данным, поступающим на камеру. Давайте рассмотрим новые механизмы более детально.

Начнем с того, что для использования камеры в своем приложении необходимо обязательно задекларировать такую возможность. Это делается с помощью Capability элемента с именем ID_CAP_ISV_CAMERA, который прописывается в манифесте приложения (WMAppManifest.xml). При этом данная декларация позволяет использовать как стандартную, так и фронтальную (лицевую) камеру (по выбору пользователя через интерфейс приложения). Декларация прописана по умолчанию в шаблоне проекта Visual Studio, поэтому Вам вряд ли нужно будет выполнять этот шаг. Но если Вы решили использовать именно фронтальную камеру, так как именно с помощью нее можно выполнить некоторые функции Вашего приложения, то необходимо задекларировать еще одну возможность, с именем ID_HW_FRONTCAMERA. При этом нужно помнить, что не все телефоны оснащены лицевой камерой. Последняя возможность не декларируется по умолчанию, поэтому ее потребуется прописать явно.

Теперь необходимо определиться, какое приложение Вы хотите реализовать. Дело в том, что в Windows Phone 7.5 появилось сразу два API по работе с камерой. Первое API является частью платформы Windows Phone и позволяет реализовать приложение по съемке фотографий. Второе API является частью SilverLight 4 и позволяет обрабатывать весь аудио и видео поток, поступающий на камеру. Преимущество первого API – возможность обрабатывать события, связанные с фокусом, вспышкой и другими элементами телефона. Преимущество Silverlight API – его универсальность. В любом случае оба API можно комбинировать.

Начнем наш обзор с Windows Phone API. Тут выделяют три основных класса: PhotoCamera, PictureDecoder, Extentions. Основную работу выполняет первый класс. А вот два других являются вспомогательными и позволяют преобразовать объект типа WriteableBitmap в JPEG и наоборот. Фактически второй и третий классы реализуют мостик между Silverlight и объектом типа PhotoCamera. При этом, Silverlight 4 не поддерживал стандартных механизмов преобразования BMP изображений в JPEG, что затрудняло работу разработчиков при создании веб-приложений. Но телефон ведь не только позволяет снимать изображение с камеры, но и преобразовывать его в JPEG. Именно поэтому такая возможность стала доступна и разработчику, как открытый API уже существующих в устройстве возможностей.

Не буду детально останавливаться на PictureDecoder и Extensions, а лишь отмечу, что первый класс обладает двумя статическими методами, позволяющими получить готовый WriteableBitmap, получив в качестве параметров ссылку на поток с файлом JPEG. А вот второй класс является расширителем класса WriteableBitmap и позволяет добавить в интерфейс последнего два метода (LoadJpeg и SaveJpeg). Иными словами Вы можете использовать эти методы, как методы экземпляров типа WriteableBitmap.

Теперь перейдем к основному классу – PhotoCamera. Тут есть два небольших правила-рекомендации. Объект типа PhotoCamera правильно создавать и инициализировать внутри перегруженного метода OnNavigatedTo. Уничтожать данный объект следует внутри метода OnNavigatingFrom. Это позволит гарантировать, что все ресурсы будут освобождены своевременно, если приложение поддерживает навигацию на другие страницы. Создание самого объекта типа PhotoCamera не вызывает затруднений – тут присутствует конструктор без параметров, а также конструктор, который принимает тип камеры (обычная или фронтальная).

Я не смог найти ни одного устройства с фронтальной камерой в своих запасниках, поэтому не смог проверить, можно ли получать изображение с обеих камер одновременно. Но если можно, то это позволит создать много интересных приложений. Фронтальную камеру сегодня поддерживает HTC Titan, HTC Radar и Samsung I8350. Если у Вас одно из этих устройств, попробуйте проверить и написать.

Итак, создав объект типа PhotoCamera, следует определить необходимые в приложении события, ассоциированные с этим объектом и задать свойства. Я не буду перечислять основные свойства и события, а просто приведу небольшой пример.

В шаблонный xaml, внутрь элемента Grid с именем ContentPanel, добавим код:

   1:   <StackPanel>

   2:       <Rectangle Height="400" Width="400" Margin="12,17,0,0" Name="videoRect" />

   3:   </StackPanel>

В файл с кодом добавим следующий текст:

   1:  PhotoCamera camera;

   2:  MediaLibrary library;

   3:   

   4:  protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)

   5:  {

   6:      if (PhotoCamera.IsCameraTypeSupported(CameraType.Primary))

   7:      {

   8:          camera = new PhotoCamera(CameraType.Primary);

   9:   

  10:          videoRect.Fill = new VideoBrush();

  11:          ((VideoBrush)videoRect.Fill).SetSource(camera);

  12:          library = new MediaLibrary();

  13:   

  14:          CameraButtons.ShutterKeyHalfPressed += 

  15:  new EventHandler(CameraButtons_ShutterKeyHalfPressed);

  16:          CameraButtons.ShutterKeyPressed += 

  17:  new EventHandler(CameraButtons_ShutterKeyPressed);

  18:          camera.CaptureImageAvailable += 

  19:  new EventHandler<ContentReadyEventArgs>(camera_CaptureImageAvailable);

  20:      }

  21:  }

  22:   

  23:  void camera_CaptureImageAvailable(object sender, ContentReadyEventArgs e)

  24:  {

  25:      string fileName = Guid.NewGuid().ToString() + ".jpg";

  26:      library.SavePictureToCameraRoll(fileName, e.ImageStream);

  27:      Deployment.Current.Dispatcher.BeginInvoke(delegate()

  28:      {

  29:          MessageBox.Show("Image saved");

  30:      });

  31:  }

  32:   

  33:  void CameraButtons_ShutterKeyPressed(object sender, EventArgs e)

  34:  {

  35:      camera.CaptureImage();

  36:  }

  37:   

  38:  void CameraButtons_ShutterKeyHalfPressed(object sender, EventArgs e)

  39:  {

  40:      camera.Focus();

  41:  }

  42:   

  43:  protected override void OnNavigatingFrom(System.Windows.Navigation.NavigatingCancelEventArgs e)

  44:  {

  45:      if (camera != null)

  46:      {

  47:          camera.Dispose();

  48:          camera.CaptureImageAvailable -= camera_CaptureImageAvailable;

  49:      }

  50:  }

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

На картинке я специально повернул телефон так, как он расположен во время съемки. Как видно, чтобы изображение на экране, соответствовало изображению с камеры, нужно элемент, куда мы выводим изображение, повернуть на 90 градусов.

Итак, что мы увидели в данном примере:

1). Изображение можно снимать, используя стандартную клавишу камеры в телефоне. Для этого используется класс CameraButtons, содержащий несколько статических событий, позволяющих нам подключить наш код. Тут и возможность провести фокус (относительно центра или какой-то точки), тут и возможность обработать поток, который связан со сформированным изображением, доступным после завершения съемки.

2). Для работы с камерой есть ряд простых методов, такие как Focus или CaptureImage. Эти методы инициируют некоторый процесс в параллельном потоке, и передают свои результаты в параметрах таких событий как CaptureImageAvailable или AutoFocusCompleted. Поэтому, если Вы хотите изъять фотографию, то нужно определить обработчик первого события. Но изменение интерфейса нужно выполнять, передав управление в интерфейсный поток.

3). PhotoCamera позволяет сохранить изображение в виде потокового объекта, который уже преобразован к формату JPEG. Поэтому, если Вы хотите предварительно обработать изображение, то поток можно преобразовать во WritableBitmap с помощью классов, упоминавшийся выше, обработать и снова преобразовать в JPEG.

Сценарий выше работает если Вы хотите снять обычное изображение с камеры. Но если приложение немного более сложное, например, накладывает дополнительные элементы (например, усы на лица людей в кадре), то необходимо привлечь несколько дополнительных методов объекта типа PhotoCamera. Одним из таких методов является GetPreviewBufferArgb32, позволяющий вернуть текущий фрейм для дальнейших манипуляций. Получив массив данных, разработчик может выполнить их предварительную обработку, преобразовать во WritableBitmap и выдать на экран. В этом случае VideoBrush не используется совсем, а используется объект Image, в который и выводиться очередной WriteableBitmap. Естественно, что обработка каждого следующего фрейма проводиться в методе, который запускают в параллельном потоке. А частота выдачи изображений на экран, зависит от сложности алгоритма, обрабатывающего изображение.

Если говорить про Silverlight 4 API, то тут ничего не поменялось. Работа начинается с классов AudioCaptureDevice, VideoCaptureDevice и CaptureDeviceConfiguration. Эти классы используются для получения ссылок на доступные аудио и видео устройства. Если устройств несколько, то Вы можете предоставить пользователю выбор, с каким устройством работать.

Основным классом является CaptureSource, который позволяет начать запись. Внутри этого класса описаны ссылки на аудио и видео устройства, а также присутствуют такие методы как Start и Stop, позволяющие запустить или остановить работу камеры. Кроме того, объект данного класса может служить источником данных для VideoBrush.

Отличие классов Silverlight API состоит в том, что с помощью них можно выполнять запись изображения в видео-файл (MP4). Для этого используется класс FileSink, который имеет свойства CaptureSource и IsolatedStorageFileName – все, что необходимо для начала записи. При установке свойства CaptureSource соответствующий объект должен быть остановлен. Если Вы хотите написать собственный декодер, то можно использовать такие классы как VideoSink и AudioSink. Последние можно использовать и для передачи аудио и видео в различных системах видео чата.

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

В свою очередь хочу отметить, что в Windows Phone 7.5 набор клавиатур был пополнен еще двумя: клавиатура, содержащая только цифры и клавиатура, адаптированная для набора формул. Соответственно Input Scope для первого типа клавиатуры может быть установлен в одно из значений: CurrencyAmount, DateDay, DateMonth, DateYear, Digits, Number, NumberFullWidth, NumericPassword, TimeHour, TimeMinorSec. А Input Scope для второй клавиатуры устанавливается в значение Formula.

Некоторое время назад я писал о работе с ApplicationBar в Windows Phone приложениях http://baydachnyy.com/2011/03/07/windows-phone-7-application-bar/. Как ни странно, сегодня многие разработчики забывают об этом элементе управления, являющимся привычной составляющей любого Silverlight интерфейса в WP – пытаясь городить свои кнопки в основном экране приложения. Но я сейчас не об этом.

Одним из недостатков ApplicationBar было его постоянное присутствие на экране. Как результат, если вы работали с очень динамичным приложением (да, игры бывают и на Silverlight), то была велика вероятность щелкнуть на кнопку в ApplicationBar по чистой случайности. В Windows Phone 7.5 этот недостаток был устранен за счет добавления свойства Mode. Установив это свойство в Minimized, вы получите «свернутую» версию этого элемента управления. И прежде чем нажать на кнопку, пользователь должен будет его развернуть.

Вот небольшой кусочек кода, демонстрирующий работу этого свойства:

   1:  <phone:PhoneApplicationPage.ApplicationBar>

   2:        <shell:ApplicationBar IsVisible="True" IsMenuEnabled="True" Mode="Minimized">

   3:            <shell:ApplicationBarIconButton IconUri="images/appbar.add.rest.png" 

   4:                   x:Name="gpsItem" Text="Установить" Click="ApplicationBarIconButton_Click_1/>

   5:            <shell:ApplicationBarIconButton IconUri="images/appbar.feature.search.rest.png"  

   6:                   x:Name="roadItem" Text="Показать" Click="ApplicationBarIconButton_Click_2"/>

   7:        </shell:ApplicationBar>

   8:  </phone:PhoneApplicationPage.ApplicationBar>

А вот то, что останется от ApplicationBar в этом случае:

Просил Полховского написать статью и выслать мне ссылку, но он так этого и не сделал. Все нужно делать самому. Итак, все мы знаем, что Windows Phone 7 Маркетплейса пока в Украине нет. Все мы знаем, что если бы у нас был Маркетплейс, то студенты/участники программы Dreamspark могли бы зарегистрироваться там абсолютно бесплатно. А это означает, что любой студент может разлочить до 3-х устройств. Проблема была только в том, что устройство можно было разлочить только после прохождения верификации (отправить паспорт страны регистрации). А для студентов верификация производилась только в момент публикации первого приложения (чтобы сэкономить бюджет). Сколько этих студентов зарегистрируется бесплатно, вот если они уже начинают публикацию….)

Таким образом, нашим студентам пользы от DreamSpark не было. Но время шло, а со временем появилось количество фидбеков о том, что студент не может публиковать приложение, не протестировав его на реальном устройстве. Именно поэтому (даже не знаю когда), теперь все студенты могут разблокировать устройства без прохождения верификации, а сразу же после регистрации в Маркетплейс.

Иными словами, регистрируемся, указываем страну, присутствующую в маркете, проходим верификацию в DreamSpark (нужен код), задаем какой-нибудь адрес и успешно завершаем регистрацию (если Вы выбрали Россия, то нужно, чтобы индекс был российский). Затем берем устройство и успешно его разблокируем.

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

По вопросу верификации в DreamSpark прошу писать мне – вышлю код.

Только что столкнулись с небольшой проблемой при публикации приложения в маркетплейс, это необходимость присутствия атрибута NeutralResourcesLanguageAttribute в файле AssemblyInfo.cs. Раньше можно было публиковать приложения и без этого атрибута, а теперь – ни-ни. При этом язые должен быть установлен в тот же, что и язык интерфейса по умолчанию. Даже если Вы меняете культуру программно – это не является оправданием.

Таким образом, если язык Вашего интерфейса русский, то атрибут должен быть следующий:

[assembly: NeutralResourcesLanguageAttribute("ru-RU")]

Для английского нужно ru-RU заменить на en-US.

Опять не смог сдержаться.

Недавно, в некоторых онлайн ресурсах, опубликовали табличку, где показаны продажи устройств на различных платформах за третий квартал 2010 и 2011 года. Такие себе Майкрософт ненавистники развели тут же дебаты на тему, мол продажи WP 7 падают, все, настал конец, Андроид рулит и т. д. Еще рассказывают, что в Андроиде какой-то там версии возможностей больше, но конкретику не приводят

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

Ребята, Вы сначала посмотрите, что на рынке происходит, а потом делайте выводы. Кто-то из Вас пытался купить WP 7 в третьем квартале? Я – пытался. Хотел подарить три телефона студентам партнерам. Оказалось, что последний телефон в Украине купили еще в июне. Агентство смогло найти только одно устройство, и то, на черном рынке Причина простая: все производители ждали Манго. Киевляне в этом сейчас могут убедиться, так как весь Киев заклеен бигбордами с рекламой Титана, а 7-го декабря в Россию официально поступит в продажу Нокиа (я уже жду на hotline).

В третьем квартале WP 7 телефонов элементарно не было в продаже, поэтому не читайте советскую прессу А вот что будет уже перед Рождеством и в первом квартале 2012 – очень интересно. Но у меня уже такое чувство, что дадим мы кому-то ногой под (черт, я же сотрудник Майкрософт и не могу ругаться даже в личном блоге)….

Продолжу тему, связанную с расширениями функциональности встроенных в WP 7 приложений. В прошлой статье мы говорили о расширении функциональности поиска, а в этой поговорим и расширении стандартного приложения по работе с изображениями – Pictures Hub.

Итак, начнем с того, что можно расширять. Тут существуют три возможности:

1). Расширение списка приложений на вкладке Apps, которая доступна при загрузке Pictures Hub.

Данная вкладка появляется только тогда, когда у Вас есть хотя бы одно приложение (установленное, в отличие от поиска), декларирующее поддержку фото-приложения. Если таких приложений не установлено, то и вкладки нет.

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

2, 3). Следующая возможность появляется уже на уровне работы с конкретной фотографией и позволяет Вашему приложению получить доступ к самой фотографии из меню Application Bar приложения Picture Viewer, вызываемого из Pictures Hub для просмотра отдельной фотографии.

Как видно, при работе с отдельной фотографией доступны такие пункты меню, как apps… и share….

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

Второй – использовать одно из приложений из списка, чтобы передать изображение по сети какой-либо веб-службе (например, опубликовать в facebook). Тут также можно получить идентификатор изображения, которое потом загрузить внутри приложения.

Давайте рассмотрим, как эти механизмы реализуются на практике.

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

   1:  <Extensions>

   2:     <Extension ExtensionName="Photos_Extra_Viewer" 

             ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5632}" TaskID="_default" />

   3:     <Extension ExtensionName="Photos_Extra_Hub" 

             ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5632}" TaskID="_default" />

   4:     <Extension ExtensionName="Photos_Extra_Share" 

             ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5632}" TaskID="_default" />

   5:  </Extensions>

При работе с расширениями нет ничего нового по сравнению с расширением поисковой функциональности. В элементе Extension прописывается фиксированный (характерный для расширения приложения по работе с изображениями) ConsumerID, имя расширения позволяет указать, какую часть приложения мы будем расширять, а TaskID ссылается на запись в разделе Tasks.

Если Вы планируете расширять Puctures Hub (основное его окно), то кода выше полностью достаточно. Ведь приложение просто вызывается из галереи, не получая специальных параметров.

Если речь идет о расширении Picture Viewer, то тут необходимо еще реализовать и код логики, обрабатывающей изображение. Для этого нужно получить идентификатор из QueryString, загрузить фотографию и отобразить пользователю соответствующий интерфейс. Обычно первая часть этих действий выполняется в перегруженном методе OnNavigatedTo, который инициализируется при переходе на страницу. Вот пример кода, который может быть реализован внутри метода:

   1:  IDictionary<string, string> queryStrings = 

   2:     this.NavigationContext.QueryString;

   3:   

   4:  if (queryStrings.ContainsKey("token"))

   5:  {

   6:     MediaLibrary library = new MediaLibrary();

   7:   

   8:     Picture picture = 

   9:        library.GetPictureFromToken(queryStrings["token"]);

  10:   

  11:     BitmapImage bitmap = new BitmapImage();

  12:     bitmap.CreateOptions = BitmapCreateOptions.None;

  13:     bitmap.SetSource(picture.GetImage());

  14:     WriteableBitmap picLibraryImage = new WriteableBitmap(bitmap);

  15:     . . . . .

  16:  }

  17:   

В данном коде мы обрабатываем ключ token, который присутствует, если мы расширяем пункт apps… В случае с share… пунктом следует обрабатывать ключ FileId.

Таким образом, расширить Pictures Hub – простая задача. Проблема только в отсутствии возможности протестировать все это на эмуляторе, так как в последнем Pictures Hub не активирован.

Первая функциональность, с которой мне захотелось познакомиться в Windows Phone 7.5 – расширение возможностей стандартного поиска, результатами, которыми обладает Ваше собственное приложение. Решил это сделать, увидев подобную функциональность в Windows 8, ожидая увидеть что-то аналогичное. Скажу сразу, реализация в Windows Phone 7.5 меня разочаровала. Несмотря на это, механизм существует, поэтому я решил описать его возможности.

Начнем с того, что стандартный поиск в Bing теперь интегрирован с Windows Phone Marketplace. Иными словами, если пользователь выполняет поиск и вводит запрос, соответствующий названию приложения из Marketplace (или похожим критериям), то ссылка на приложение выдается в топе результатов поиска. При этом пользователь может установить приложение, используя результаты поиска, или запустить его на устройстве, если оно уже установлено. Ниже небольшой пример, который легко воспроизвести и в эмуляторе:

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

string searchTerms = NavigationContext.QueryString["bing_query"];

Естественно, данные нужно выбирать на основной странице приложения сразу же после его загрузки. Другой вопрос, что с ними делать. По крайней мере информацию о том, что Ваше приложение кто-то устанавливает через поисковый запрос – Вы получите.

Если Вы все же решили попробовать получать запрос из Bing, положившись на Вашу удачу, то можете попробовать протестировать поведение приложения, эмулируя его запуск с поисковым запросом. Для этого в WMAppManifest.xml достаточно прописать следующий код, заменив элемент DefaultTask на следующий:

<DefaultTask Name ="_default" NavigationPage="MainPage.xaml?bing_query=Пятнашки"/>

В этом случае, приложение получит параметры и сможет обработать их так, будто бы запущено из окна поиска Bing.

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

Возможность базируется на так называемых «Быстрых карточках». Так, обратите внимание на изображение ниже:

Тут, перед результатами поиска из Web (и после ссылки на приложение в Marketplace) появляется специальный раздел Products. Его появление объясняется тем, что Bing нашел несколько продуктов, соответствующих нашему запросу. Нажав на один из представленных продуктов, мы можем перейти к его описанию, состоящему из нескольких вкладок (это и есть быстрая карточка продукта):

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

Причем, обратите внимание, в списке приложений есть и те, которые уже установлены, а также те, которые можно загрузить. Идея состоит в том, чтобы пользователю показать именно те приложения, которые помогут ему работать с «Быстрыми карточками». Иными словами, если продукт продается на eBay, то пользователю было бы здорово загрузить приложение-клиент для eBay (кстати, он есть в списке) или выбрать приложение другого магазина.

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

1). Необходимо понимать, что существует всего (пока) три типа таких карточек: Продукты, Местоположения (отображающиеся на вкладке Local) и Фильмы (которые демонстрируются в кинотеатрах, недалеко от Вашего местоположения).

2). Каждый тип карточки поддерживает несколько расширений (категорий). Иными словами, если пользователь ищет новый лаптоп, а Вы продаете ювелирные украшения, то не имеет смысла показывать пользователю Ваше приложение. Список доступных расширений можно посмотреть тут: http://msdn.microsoft.com/en-us/library/hh202958(v=VS.92).aspx.

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

Давайте рассмотрим детальную реализацию третьего пункта.

Начнем с изменения WMAppManifest.xml, где в раздел App (в самый конец) записывают следующий блок:

   1:  <Extensions>

   2:     <Extension ExtensionName="Bing_Products_Arts_and_Crafts"

   3:        ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5661}"

   4:        TaskID="_default" ExtraFile="Extensions\\Extras.xml" />

   5:        . . . . .

   6:  <Extensions>

Тут основным атрибутом является ExtensionName, описывающим с помощью элементов Extention категории, в ответ на которые Ваше приложение будет появляться в списке. Атрибут CunsumerID Вы просто копируете с его значением, так как значение этого атрибута является стандартным для данного типа расширений. Атрибут TaskID указывает на ту задачу, которая будет выполняться при запуске приложения (обычно это _default – запуск MainPage.xaml), наконец ExtraFile указывает путь к файлу, где записываются дополнительные детали к расширению (обычно он один для всех расширений).

На следующем этапе Вы можете создать файл, указанный в атрибуте ExtraFile. Тут может быть код, похож на этот:

   1:  <ExtrasInfo>

   2:    <AppTitle>

   3:       <default>Quick Card Sample</default>

   4:    </AppTitle>

   5:   

   6:    <Consumer ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5661}">

   7:       <ExtensionInfo>

   8:          <Extensions>

   9:            <ExtensionName>Bing_Products_Arts_and_Crafts</ExtensionName>

  10:            <ExtensionName>Bing_Products_Baby_and_Nursery</ExtensionName>

  11:          </Extensions>

  12:   

  13:          <CaptionString>

  14:            <default>Product URI Details</default>

  15:            <fr-FR> . . . </fr-FR>

  16:          </CaptionString>

  17:   

  18:       </ExtensionInfo>

  19:   

  20:       . . . . .

  21:   

  22:     </Consumer>

  23:  </ExtrasInfo>

Так, в этом файле поддерживаемые Вашим приложением расширения разбиваются на группы. Для каждой из групп задается заголовок, который будет отображаться вместе с Вашим приложением (причем для всех поддерживаемых Вами культур).

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

app://<AppID>/_default#/SearchExtras?ProductName=<product_name>&Category=<extension_names>

Тут параметры могут меняться, в зависимости от типа Быстрой карточки.

Так вот, чтобы это работало, нужно настроить mapping внутри Вашего приложения. Это можно сделать, прописав в ресурсах объекта App вот такой код (при этом запрос перенаправляется на другую страницу приложения):

   1:  <Application.Resources>

   2:     <nav:UriMapper x:Key="UriMapper">

   3:        <nav:UriMapper.UriMappings>

   4:           <nav:UriMapping Uri="/SearchExtras" MappedUri="/ItemPage.xaml"/>

   5:        </nav:UriMapper.UriMappings>

   6:     </nav:UriMapper>

   7:  </Application.Resources>

Далее, подключаем данный mapping внутри App.xaml.cs, при загрузке приложения:

RootFrame.UriMapper = Resources["UriMapper"] as UriMapper;

Вот и все. Теперь обрабатываем параметры запроса с помощью QueryString и реализуем нужную нам бизнес-логику.

Таким образом, добавить Ваше приложение в список, ассоциированный с одной или несколькими категориями в Быстрых карточках не так и сложно. Другое дело, что пользователю весьма нетривиально попасть на предлагаемый список, чтобы увидеть Ваше приложение. И самое интересное (возможно, с этого стоило начать), быстрые карточки работаю пока не везде. Точнее работают они всего в 4-х странах: США, Франция, Австралия и Англия. Причем в последних трех, работают только Продукты. Проверить работу карточек Вы можете, установив Browser&Search language в язык, соответствующей одной из стран.

Решил написать несколько статей, посвященных Windows Phone 7.5. А поскольку мы сейчас реализуем несколько программ, позволяющих студентам и разработчикам опубликовать свои приложений я Marketplace (вот пример: ссылка), то первую статью я решил посвятить публикации приложений. Даже не столько публикации, как подготовке к публикации приложений.

Итак, Ваше приложение полностью готово и Вы хотите его опубликовать в Windows Phone Marketplace. Проблема в том, что для удачной публикации Вам понадобиться пройти сертификацию на выполнение требований Marketplace, а также подготовить дополнительные материалы (иконки, описание и т. д.), которые понадобятся при публикации. Чтобы понять, что Вам понадобиться для публикации и готов ли Ваш пакет, существует два пути:

1). Прочитать все, что касается Marketplace в MSDN (http://msdn.microsoft.com/en-us/library/hh202930(v=VS.92).aspx), включая различные требования к сертификации (http://msdn.microsoft.com/en-us/library/hh184843(v=VS.92).aspx). При этом Вы не застрахованы от ошибок.

2). Использовать Windows Phone Marketplace Test Kit – специального пакета для разработчика, являющегося частью Windows Phone SDK 7.1. Пакет интегрируется с Visual Studio в виде расширения и позволяет выполнить все необходимые проверки на готовность пакета, не выходя из оболочки.

Внимание! Если Вы установили WP 7.1 SDK, а приложение продолжаете разрабатывать в режиме WP 7.0, то пакет активен не будет, и Вы не сможете увидеть соответствующие пункты меню в Visual Studio.

Поскольку я не могу помочь Вам с чтением технической документации, то перейду к рассмотрению второго пункта, это использование Windows Phone Marketplace Test Kit. Особенность данного подхода состоит в том, что задание по проверки готовности к сертификации можно поручить и тестеру в Вашей команде.

Итак, если у Вас установлен Windows Phone 7.1 SDK и Вы ведете разработку приложения в Visual Studio, то Вы без труда сможете найти пункт меню Project->Open Marketplace Test Kit. Открыв соответствующее окно, Вы сможете увидеть следующее окно, содержащее 4 закладки (я уже загрузил свои рисунки):

Обратите внимание, что внизу окна присутствует надпись, которая предлагает обновить входящий в состав Test Kit набор Test Cases. Если Вы увидели такую надпись, то нажмите Update, чтобы Ваше приложение удовлетворяло самым последним требованиям Marketplace.

Итак, открывшееся окно содержит 4 закладки:

Замечание. Чтобы работать с Test Kit, Вам необходимо создать Release версию Вашего приложения. Причем, исправляя ошибки по ходу прохождения тестов, выполняйте команду Build после каждого изменения.

Application Details – тут Вы вносите необходимые ресурсы для публикации Вашего приложения. Это три иконки различного размера. Эти иконки будут отображаться при выборе приложения в Marketplace, при установке приложения в обще меню и на основной экран. Также необходимо приложить скриншоты Вашего приложения. По требованиям необходимо приложить минимум один скриншот, но можно и больше (чтобы дать пользователю больше деталей во время знакомства с приложением). Если иконки (обычные изображения в формате png) помочь создать Вам сможет лишь дизайнер, то скриншоты приложения можно получить, используя стандартный эмулятор. Для этого запустите приложение в эмуляторе и откройте расширенную панель управления:

Как видите, тут не только можно снимать скрины, но и эмулировать работу GPS и акселерометра.

Подготовив все необходимые ресурсы, перейдем к следующей вкладке.

Automated Tests – тут проверяется корректность структуры xap-файла, и соответствие Вашего приложения заявленным в манифесте возможностям.

Если все иконки и скрины заданы верно, а размер пакета не превосходит требуемого, то приложение успешно пройдет все тесты. Просто нажмите Run Tests и посмотрите на результат. Особое внимание следует уделить тесту Capability Validation. С помощью этого теста Вы сможете однозначно определить, какие возможности необходимы Вашему приложению и отредактировать WMAppManifest, указав корректные значения.

Monitored Tests – следующий набор тестов позволяет проверить Ваше приложение на производительность и корректность работы. К сожалению подобные тесты можно выполнить только на реальном устройстве. Поэтому, если Вы являетесь счастливым обладателем Windows Phone устройства, то подключите его через USB, выберите вариант развертывания Windows Phone Device и запустите приложение с помощью Start Application. Поиграйтесь с Вашим приложением, стараясь воспроизвести все ситуации, а затем выйдите из приложения, нажав кнопку Back на устройстве (находясь в основном окне приложения) или нажав Close Application в окне Visual Studio. В результате Вы получите набор данных, связанных со временем запуска приложения, используемой памятью, исключениями и реакцией на Back кнопку:

Manual Tests – не все тесты можно пройти в автоматическом режиме, поэтому последняя вкладка предлагает Вам несколько десятков тест-кейсов, которые следует пройти в «ручном» режиме, чтобы убедиться в том, что приложение работает хорошо.

Если у Вас и тут все хорошо, то смело приступайте к публикации приложения.