[Build 14] – What’s new with Windows Phone Silverlight Apps !

Mail de John
Vendredi 4 avril 2014 06:11

What’s new with Windows Phone Silverlight Apps!

 

Différences entre les applications XAML et les applications Silverlight.
Le framework XAML est le framework du futur. C’est là où les prochaines mises à jour auront lieu. Mais le framework Silverlight continuera à être mis à jour quelques temps afin de suivre les évolutions du framework XAML pour les applications existantes.

La convergence entre les API est de l’odre de 90%.


Cependant certaines API n’ont pas encore migrées :

– Lenses
– VOIP
– Camera Capture Task
– Clipboard
– Lockscreen Wallpaper
– Ringtone et Alarmes
– Simple sound effects (XNA)
– Photos Extensibility
– Search Extras

 

On enchaîne par une démonstration de la migration d’une application Silverlight 8.0 vers Silverlight 8.1

Les applications Silverlight 8.1 s’exécutent dans le même contexte que les applications WinRT. Pour cette raison, les applications Silverlight 8.1 disposent maintenant d’un fichier appxmanifest en plus de l’historique fichier WMAppManifest.xml. Les deux doivent être mis maintenus à jour.

Lorsque l’on migre en 8.1 il y a quelques « breaking changes » :

– CLR/Silverlight bug fixes
o Array.Sort (IntrospectiveSort à la place du QuickSort)
o DateTime.Parse (correction de bugs)

– Différences au niveau de contexte d’exécution des applications WinRT
o Fast App Resume est activé par défaut (resume vs replace)
o Appuyer sur back ferme l’application, à la différence des Universal Apps, mais il existe une API spéciale qu’il est recommandé d’utiliser pour que les applications Silverlight 8.1 fonctionnent comme les Universal Apps.

Fonctionnalités non supportés dans Silverlight 8.1 :
– Background Audio (existe dans les Universal Apps)
– Continuous Background Execution Agents (GPS Apps)

Nouvelles fonctionnalités et mises à jour :

– Nouvelles API disponibles pour les applications Natives (C++)
– WinRT APIs
– SD Card Support
– Share Source
– Share Target
– WNS Push Notification Trigger
– WNS Notifications
– Storage
– GeoFencing
– Bluetooth 4.0
– Background Tasks
– Known Folders (Audio/Video/Photos/…)
– Appointments / Calendar Enhancements
– Email with Attachments
– Web Authentication
– Data Roaming
– Accessibility (UIA, Large Text, High Contrast)

On a ensuite une démonstration du remplacement d’un EmailComposeTask par un Share Contract avec une pièce jointe suivi d’une autre démonstration où on ajoute une BackgroundTask.

Le Store supporte maintenant 3 versions d’une application (7.1, 8.0 et 8.1).
Avant de pouvoir déployer une application 8.1 pour la première fois, il faut réserver un nom spécifique à cette version. Ce nom doit se trouver dans le appxmanifest et il faut l’éditer à la main en mode texte (voir slides de la présentation).

 

 

John

 

[Build 14] – Multitasking and Background Processing on Windows Phone

Mail de John
Jeudi 3 avril 2014 10:56

Multitasking and Background Processing on Windows Phone

On commence par un petit rappel du model de multitasking dans Windows Phone 8.
S’ensuit un rappel du modèle d’exécution des tâches de fond dans WinRT (Processus séparés, réponds à des Triggers et à des conditions).

Présentation des triggers disponibles dans Windows Phone.
Comment créer une tâche de fond ?
– Implémenter IBackgroundTask.
– Modifier le Manifest pour activer l’accès aux tâches de fond.

Démonstration en C# de création d’une backgroundtask et comment on l’enregistre dans le système (BackgroundExecutionManager.RequestAccessAsync), l’ajout de triggers (BackgroundTaskBuilder, SystemTrigger, SystemCondition). Ensuite démonstration de comment lancer une backgroundtask en Javascript (Ajout de la définition de la propriété TaskEntryPoint du BUilder qui correspond au fichier js contenant la tâche).

Les tâches de fond natives (aka WinRT) sont disponibles dans les applications Silverlight 8.1. Les BackgroundAgents sont maintenant hébergés par l’infrastructure WinRT.

Accès aux Sensors, Bluetooth LE, RFCoom même si l’application n’est pas en premier plan.
Basé sur les nouvelles API Bluetooth WinRT.

Nouveau triggers :
– GattCharacteristicNotificationTrigger
– DeviceChangeTriggfer
– DeviceUpdateTrigger
– RfcommConnectionTrigger

Les notifications de Geofencing peuvent être reçues en background dans une tâche de fond.
Ajout des Push Triggers dans Windows Phone.
Associer une Background Task avec un WNS channel.
Activation d’une tâche de fond grâce à une notification push raw.

Démonstration des Push Notifications.

Le rendu XAML dans les BackgroundTasks est maintenant possible ! (Démonstration de ceci en C++ c’est mieux pour la mémoire).

BackgroundTransfer
– Windows.Networking.BackgroundTransfer
– Pas de restriction de taille de fichiers
– Support du multi part mime (pour les gros fichiers)
– Verbes HTTP supplémentaires (PUT, RETR, STORE) et aussi FTP
– In-progress stream access
– Data-Sense and Battery Save aware

Non disponible pour les applications Windows XAML :
– Continuous Background Location
– Runs-Under-Lock
– VoIP Agents
– Wallet Agents

Economiseur de batterie :
Permet de trier et de gérer les applications qui tournent en tâche de fond et de voir leurs utilisations de ressources

Contraintes de ressources :
– Toutes les tâches de fond ont des quotas CPU, mémoire et réseaux
– Les quotas sont basés sur l’utilisation actuelle du CPU au lieu d’une limite d’horloge
– Le quota d’horloge sera renforcé (au moins une fois toutes les 30 secondes)
– Le quota de mémoire s’adapte aux capacités de chaque device.
– Le TimeTrigger aura un temps d’exécution assuré d’un maximum de 30 minutes maximum.
Appelez RequestAccessAsync() pour avoir votre quota maximum.
John

 

[Build 14] – Developing apps using the common XAML UI Framework

Mail de John
Jeudi 03/04/2014 10:08

// Developing apps using the common XAML UI Framework

Pour développer une Universal App, il faut la dernière update de VS2013 (update gratuite). Cela est valable aussi pour Visual Studio Express.

On dispose d’un « projet partagé » dans lequel on peut mettre tous les fichiers à partager et pas seulement le code source. On peut y mettre des images, des fichiers ressources etc… Ce projet partagé ne génère aucune sortie (pas de dll, xap, appx…)
On peut convertir un projet Windows 8.1 en projet disposant d’un projet partagé. Cela n’entraine aucune modification du projet original. C’est à nous de déplacer les fichiers intéressants pour nous dans le projet partagé. Les fichiers XAML partagés sont rigoureusement les mêmes entre un projet partagé et un projet Windows 8.1 et un projet Windows Phone 8.1 Universel.

Tout WinRT n’est pas commun entre Windows Phone et Windows 8.1 mais la plupart des fonctionnalités le sont.

Qu’est-ce qui est commun alors (en se focalisant sur l’espace de nom XAML) ?
#Voir la session DeepDive controls 2-516 (Shawn Oster)
Les primitives sont partagées (Panels, Buttons, Slider, RadioButton, ProgressBar, TextBox, TextBlock, Shapes/Path etc….)
Certaines primitives ont la même API mais sont adaptés par devices (Hub, AppBar/CommandBar, Date/Time Picker, ListView, Flyouts, Media, Ads SDK*). L’AppBar ne peut en fait pas être utilisé sur Windows Phone. Les Flyouts sur Windows Phone peuvent être en plein écran mais pas en Windows 8.1.

S’ensuit une démo intéressante du HubControl, de l’AppBar et d’autres contrôles vus en mode Windows 8.1 et Windows Phone 8.1.

En ce qui concerne les publicités, on ne peut pas les utiliser directement en XAML. Il faut les instancier par code car les deux SDK de pubs sont dans des namespaces différents même si l’API est identique. De plus les AdUnit diffèrent en fonction des plateformes. Pour cela on utilise une directive de compilation : WINDOWS_APP ou WINDOWS_PHONE_APP.

Certains contrôles restent spécifiques à la plateforme :
Windows :
– SearchBox
– SettingsFlyout

Windows Phone :
– Pivot
– AutoSuggestBox
– ContentDialog
– Maps
– System Chrome (Progress Area) (Nouvelle API permettant de choisir la façon dont le SystemTray obtient sa couleur de fond).

Il y a une petite différence dans le modèle de navigation entre Windows Phone et Windows au niveau de la gestion du bouton back (maintenant l’appui sur Back ne ferme plus l’application).

#Voir la session Navigation Model for XAML Apps (Roberth Karman)

Il y a des points communs au niveau des animations :
ThemeAnimations et ThemeTransitions fonctionnent aussi maintenant sous Windows Phone.

La gestion du texte est uniformisée entre Windows Phone et Windows.
Il reste cependant quelques spécificités à Windows Phone.
Les PasswordBox sont aussi légèrement différentes (sur le téléphone on a un délai avant le masquage des caractères écrits).
Les tuiles sont aussi différentes entre Windows et Windows Phone.
Ajout dans Windows du XamlRenderingBackgroundTask pour générer des tasks en XAML dans Windows.
Ajout de l’API du RequestedTheme dans Windows Phone permettant de surdéfinir le thème par nœud XAML.

John

[Blend] Convertir des objets en Path et les manipuler

Blend est un outil pleins de possibilités. Aujourd’hui je vais vous présenter une fonctionnalité assez méconnue et pourtant très pratique.

Pour ceux qui ne connaitrait pas, un Path est un objet XAML permettant décrivant un forme arbitraire. On peut s’en servir pour dessiner un rectangle, une croix ou même une théière, bref tout ce que l’on veux.  Ce Path peut servir de différentes manières. En WPF on peut s’en servir pour générer des Brush. On peut aussi s’en servir pour faire du clipping avec les PathGeometry. Dans WinRT 8.1 on peut les utiliser pour dessiner les formes des boutons des AppBarButton grâce aux PathIcon. Je vous renvoie à la MSDN pour plus d’informations sur les Path.

Mise en pratique

Supposons que comme moi le design n’est pas votre fort mais vous avez quand même cependant besoin d’un Path dans votre application.

Blend vous offre la possibilité d’en créer à partir de la plupart des objets XAML y compris des TextBlock.

Nous allons donc nous servir d’un TextBlock pour générer un joli Path en forme de X. Pour cela on va glisser un TextBlock sur la surface de travail et changer quelques-unes de ses propriétés pour le rendre plus jolie. Ici j’ai changé la police d’écriture, la taille de la police.

BlendConvertToPath1

Pour convertir ce TextBlock en Path il faut aller dans le menu Object, et sélectionner Convert To Path dans le sous-menu Path.

BlendConvertToPath2

Un Path est maintenant généré et remplace notre TextBlock dans le XAML.

En poussant le concept un peu plus loin on peut écrire un texte en Windings et le convertir en Path et avoir une jolie cloche comme dans l’image ci-dessous.

BlendConvertToPath3

Une fois que l’on dispose d’un Path on peut profiter d’une autre fonctionnalité de Blend, les combinaisons de formes.

Commençons par glisser un Rectangle sous notre Path.

BlendConvertToPath4

Dans la partie Object and Timeline sélectionner le Rectangle et le Path (en utilisant la combinaison Shift + Click) en commençant par le Path puisque l’ordre de sélection peut-avoir une influence sur le résultat des opérations.

BlendConvertToPath5

Dans le menu Object on va cette fois aller dans le sous-menu Combine et sélectionner une opération. Ici j’ai choisi Exclude Overlap qui va grosso-modo retirer la forme du Path dans le Rectangle.

BlendConvertToPath6

On se retrouve à présent avec un seul Path représentant le résultat de l’opération. Vous noterez la perte de certains styles comme la couleur.

BlendConvertToPath7

Et si on met justement un peu de couleur de fond et de couleur de bordure on remarque qui la forme de la cloche a bien été « creusée » dans le rectangle.

BlendConvertToPath8

Conclusion

Ces opérations sont très puissantes et les possibilités de création très importantes.

A vous maintenant d’essayer un peu tout cela en testant les diverses opérations pour créer des formes compliquées sans forcément pour cela avoir besoin de talents de graphistes.

Visual Studio 2013 Diagnostics Tools for XAML-Based Windows Store Apps (3-322)

Session animée par Pratap Lakshman

La session commence par un rappel de ce qui peux causer des mauvaises notations d’applications sur le store :

  • App Freezes
  • Crashes
  • Mauvaise réactivité
  • Utilisation trop importante de la batterie

Outils d’analyses :

  • XAML UI réactivité
  • Utilisation CPU
  • Consommation d’énergie
  • Managed memory dump analysis

Rappels sur ce qui prend du temps en XAML :

  • Chargement, parsing, construction de l’arbre d’éléments et du modèle objet, formatage (style) et mis en forme (layout)
  • Affichage et rastérisation
  • Composition

Démo d’utilisation de l’outil d’analyse de réactivité de l’UI (UI Responsiveness Tool)

Petit schéma montrant comment analyser rapidement ce qui ne va pas dans le démarrage de l’application.

Démo de l’outil de diagnostic du CPU.

Efficience – Influence des resources systèmes

  • Les sources d’utilisation d’énergie les plus importantes sont le CPU, l’affichage et le réseau
  • L’affichage varie en fonction du type d’écran, des couleurs et de la luminosité
  • Le réseau varie selon le réseau et sa qualité (Filaire != Wiifi != 2G != 3G etc…)

S’ensuit un long chapitre sur la partie réseau téléphonique avec une démo à la clef.

Et après une présentation et une démo sur l’analyse de mémoire qui marche aussi avec des applications en production et de trouver les fuites de mémoire. Cependant ce n’est pas l’outil intégré à Visual Studio 2013.

Une session qui présente des concepts intéressants mais qui n’effleure que la surface de ce qu’il est surement possible de faire avec ces outils. Je m’attendais à plus efficace pour une session de niveau 300. C’est cependant quand même intéressant à regarder.

John Thiriet

Windows Runtime Internals: Understanding the Threading Model (4-107)

Session animée par Martyn Lovell

Le but de la session est de présenter pourquoi le threading est important et comment le theading est implémenté dans WinRT et qu’est-ce qui se cache derrière la façade.

La session commence par une démo en C++ nommée « Media Buttons » qui montre tout les threads créés automatiquement par le système.

Pourquoi on a besoin de threads :

  • Services connectés au monde
  • Application responsive
  • Expérience touch
  • Plusieurs cœurs

Comment Windows parallélise :

  • Kernel threads
  • Separate processes
  • Brokers
  • Async operations

 Windows threading model :

  • UI objects dans le thread UI
  • Le thread principal vi aussi longtemps que l’application
  • La plupart des autres objets peuvent être utilisés dans n’importe quel threads
  • La plupart du travail est passé au ThreadPool
  • Les objets Windows suivent des règles naturelles et familières
  • Vous contrôlez la durée de vit d’un thread

 Le thread UI :

  • Les interfaces utilisateurs ont des besoin spécians
    • On ne veux pas que OK soit appuyé pendant le OnCancel
  • Les objet UI sont naturellement sérialisés
  • Ne pas faire de long travail sur le thread UI
  • A la place il faut passer un maximum de travail au thread pool

Demo : Comportement du thread UI

 UI Thread reentrency :

  • Les objets sur le thread UI n’ont pas besoin de locking pour se protéger eux-mêmes
  • Les thread UI ne sont pas réentrants
  • Quand vous faite un appel à un autre thread/process, seul les threads logiquement connectés peuvent vous rappeler
  • Les threads UI ne peuvent pas s’appeler en même temps (rejeté au moment de l’appel dans Windows 8.1)
  • Utiliser un dispatcher ou un objet asynchrone pour éviter ce genre d’appels

Schéma d’explication du « Single-threaded apartment reentrancy ».

 UI Thread waiting :

  • Pas de délais autorisés sur les threads UI
  • Most classic waiting primitives are inappropriate (Windows tue les applications ne répondant plus)
  • A la place il faut appeler des primitives UI-safe (C# await, C++ create_task, JS promise)

Démo : Safe view shutdown (MultipleView Sample)

 Le UI thread Principal :

  • L’interface principale de l’application est toujours lancée dans le thread UI principal
  • Le thread UI principal est utilisé pour gérer l’état global de l’application
  • Les autres threads UI sont pour les documents et les contrats
  • Le thread UI principal est vivant tant jusqu’à ce que l’application meure

 Threading dans l’environnement HTML :

  • Tout les threads sont des threads UI (même les web workers sont single-threaded)
  • Tout les évènement et complétions sont délivrées là où elle ont commencées
  • Utilisez les api standard des applications web au lieu du WinRT Core*

Threading en XAML :

  • Les objets UI sont liés à un threads
  • Utilise le dispatcher to déplacer le travail de l’ui dans le thread UI
  • Tout l’arbre XAML est dans un seul thread
  • Les évènements sont dans le thread UI

Objects and threading

  • Les protocoles basiques de WinRT sont threading-agnostic (Iunknown, Iinspectable)
  • La plupart des objets WinRT n’ont pas besoin de marshaling
  • Même les références à des objets hors du processus (proxies) sont agiles dans WinRT
  • Donc même si le marshaling existe toujours il est rarement visible et ce délibérément

Marshaling :

  • Les objet décident comment ils se marshallent (IMarshal, INoMarshal contrôlent le marshalling)
  • Les objets WinRT généralement « opt-out of marshaling »
  • Tout les marshalers sont fournis par le système avec l’aide des données générés par le MIDL

Thread pool threads :

  • Là où le travail long est effectué
  • Ils sont alloués, étendues et schedulés par le système
  • Les opérations async de WinRT tournent générallement dedans
  • Toujours initialisés par WinRT

Schéma démo des callback sur des objets asynchrones

Les objets agiles :

  • Objets qui peuvent travailler dans n’importe quel thread ou process sans être marshalled
  • Ils ne peuvent stocker que des objets agiles
  • Pas de stockage de Iinspectables
  • Ils sont simple à manipuler
  • La plupart des objets WinRT sont agiles

Apartments :

  • Apartments sont des concepts COM qui groupent et contrôlent les durés de vie des objets
  • Ils existent dans WinRT mais sont maintenant largement inutiles et remplacés par les objets agiles
  • Trois apartment
    • ASTA
    • MTA
    • NTA (Neutral threaded apartment utilisés par WinRT)

Appels cross-threads :

  • Les appels WinRT sont délivrés seulement quand le thread est prêt
  • Les appels sont en compétitions avec les autres pour obtenir l’attention d’un thread
  • Win 8.1 change :
    • Les appels ne bloquent plus les input
    • Le scheduler autorise les priorisation des work items

Une session intéressante qui explique tout ce qui se passe dans WinRT au niveau du threading. Définitivement à voir et à revoir.

John Thiriet

App Performance: The Windows Performance Toolkit (3-100)

Session animée par Chell Sterioff

Objectif : se familiariser avec les outils d’analyses d’applications

Outils d’analyse de performance :

  • Visual Studio
  • Windows performance Toolkit
    • Windows Performance Recorder
    • Windows Performance Analyser

Démo de présentation du recorder et quelles sont les différentes options à notre disposition.

Démo de présentation de tout ce que présente l’analyseur et de la logique à utiliser pour diagnostiquer correctement des problèmes de performance.

Une session très orientée démo et assez difficile à suivre qui dans une certaine mesure entre en conflit avec précédente. La principale difference étant que celle-ci est orienté HTML alors que la précédente était XAML. A voir mais surement plusieurs fois et en plusieurs fois.

John Thiriet

XAML performance fundamentals (3-157)

Session animée par Kiran Kumar

On commence par une petite piqure de rappel sur ce que signifie la performance

  • Fluidité
  • Rapidité
  • Impression des utilisateurs

Ensuite on parle de ce qu’il faut savoir

  • Connaître le runtime
  • Connaître son budget (CPU ou temps de développement)
  • Utilisation de pattern (MVVM)

Rappel/présentation sur l’architecture de XAML et les différents threads qui le compose.

Description du cycle de vie d’une frame XAML.

Description du démarrage d’une application en XAML et de ce qui cause des ralentissements.

S’ensuit une démonstration de comment on peu diagnostiquer ce genre de soucis de démarrage et de parsing de xaml (utilisation de wprui et wpa avec un profil spécialisé pour l’analyse du XAML)

Rappels sur les animations dépendantes et indépendantes et que les animations dépendantes ralentissent sont soumises au CPU et non au GPU.

Nouvelles api de diagnostics : DebugSettings.EnableFrameRateCounter, DebugSetting.EnableRedrawRegions, DebugSettings.IsOverdrawHeatMapEnabled

Description du fonctionnement des animations de panning et pastes d’améliorations pour l’affichage des contenus virtualisés.

Présentation d’une nouvelle api GridView.ContainerContentChanging qui permet d’éviter le coût du databinding en donnant la main à l’utilisateur pour qu’il remplisse les éléments du GridView.

Démo diagnostic des problèmes d’animations et de panning.

On parle ensuite des médias et de la manière d’optimiser leurs performance.

Présentation des améliorations :

  • Démarrage plus rapide
  • Templates par défuts meilleurs
  • Support du XAML binaire
  • Databinding plus rapide
  • Utilisation mémoire inférieure
  • Grouping Panning 2x plus rapide
  • Nouvelle api pour les panels
  • Etc…

Comme l’année dernière Kiran Kumar a fait une belle session rentrant bien dans les détails du moteur de XAML et montrant les nouveautés du Windows Performance Analyser

John Thiriet

Unlocking the power of DirectX in apps that use XAML (4-065)

Session animée par Bede Jordan

A chaque fois j’essaie d’aller voir une session C++ ou DirectX et celle-ci est l’heureuse élue.

Pourquoi utiliser XAML et DirectX ensemble

  • XAML permet de faire des interfaces graphiques simplement (comparé à DirectX)
  • DirectX est la couche la plus basse pour faire du graphique. XAML (dans Windows 8) est construit au dessus de DirectX via DirectComposition pour Windows 8.1

En bref :

  • XAML => UI et contrôles
  • DirectX => Graphisme edition d’images, jeux.

Applications utilisants cette intéropérabilité entre XAML et DirectX :

  • OneNote
  • FreshPaint
  • Bing Maps
  • Reader (Pdf)
  • Jeux de Microsoft

Plusieurs options pour gérer ça :

  • SurfaceImageSource et VirtualSurfaceImageSource (explication de comment on les utilise et des nouveautés dans Windows 8.1)
  • SwapChainBackgroundPanel, SwapChainPanel (permet de créer plusieurs SwapChain et d’avoir des tailles plus petites que le plein écran des SwapChainBackgroundPanel, plus de limitation de z-order comme les webview)

On nous explique quelle API utiliser et quand les utiliser.

Présentation des Dependent et Independent Input et de comment on utilise des entrées indépendentes et démonstration.

Une session très intéressante qui permet d’imaginer des scenarii un peu différents de ceux que l’on a l’habitude de faire.

John Thiriet

What’s New in Visual Studio & Blend for XAML Developers (3-321)

Session animée par Unni Ravindranathan

La session commence par le fait que l’on apprend que les templates de création de projet ont été mis à jour.

Édition du xaml

  • Améliorations de l’éditeur
  • Nouvelle expériences dans Blend
  • Amélioration dans la performance et la robustesse du designer

Diagnostics

  • Détection des problèmes de responsivité de l’UI
  • Profiling de la consommation d’énergie

Debug d’async

Windows Azure Mobile Services Integration

Store integration

Coded UI testing

.NET

  • Possibilité de voir la valeur de retour des méthodes dans la watch
  • 64 bit edit and continue est maintenant supporté

C++

  • Améliorations de l’éditeur

API Deprecation

  • Ajout du support de la dépréciation des API dans le XAML aussi

Démo Hub avec toutes les nouvelles fonctionnalités de VS2013

Partie spéciale Blend :

  • Retour des behaviors dans Blend
  • Ajouts des règles et des guides dans Blend qui peuvent se réutiliser de page en page
  • Amélioration de la partie device
  • Retour et amélioration de la partie Data
  • Gestion des commandbar
  • Édition des Template avec les données courantes

Une session très intéressante avec pas mal de fonctionnalités que l’on attendait pas/plus.

John Thiriet