Build 2015 – Day 1

Par Benoît,
Pôle .Net MCNEXT

Bonjour à tous,

Après la keynote qui nous a tant surpris de part les avancées technologiques de Microsoft (HoloLens,…) que ses choix stratégiques (Android et iOS au sein du store), les sessions ont débuté.

Aussi vous trouverez ci-joint un compte rendu pour chacune des 4 sessions auxquelles j’ai pu participer en cette première journée. J’ai suivi un parcours plutôt orienté XAML, mais au-delà la techno, ces sessions ont été une manière de voir les orientations fonctionnelles et design pour W10.

1 – Strategies for developing cross-platform applications with VS 2015
Une session traitant du développement multiplateforme grâce à Xamarin et Cordova.

2 – What’s new in XAML for Universal Windows Apps
Un point sur les nouveautés XAML introduit par W10, entre contrôles universels, nouveau binding et layout responsive.

3 – Data Binding : Boost your app’s performance through new advancement to XAML Data Binding
Introduit lors de la précédente session, le nouveau binding compilé est ici étudié en profondeur.

4 –  UX Patterns and Responsive Techniques for Universal Windows Apps
Cette ultime session de la journée fait le point sur les bonnes pratiques du design d’Universal App (qui reprend nombre de guidelines Windows 8).

Bonne lecture ! Benoit

Lire la suite

[Build 14] – How to Analyze Performance Issues in Your Windows and Windows Phone Apps

Mail de John
Samedi 5 avril 2014 20:33
How to Analyze Performance Issues in Your Windows and Windows Phone Apps

La performance est un problème d’expérience utilisateur. C’est l’utilisateur qui jugera. Avoir une application performante améliore les notes dans le store.

Les outils :
– Visual Studio
– WP 8.1 SDK VS Dev Power Tools
o Tracer l’application
– Windows Performance Toolkit
o Tracer l’application et faire une analyse approdonfie
o http://aka.ms/downloadWPT

Identifier les scenarii :
– Se focaliser les scenarii qui
o Ont une vraie valeur pour les utilisateurs
o Sont les clefs de l’utilisation de l’application
o Ont des problèmes de performances visibles
– Fast scenarios
o App launch
o Page navigation
o User Interaction
– Fluid scenarios
o Glitch free animation
o Glitch free panning
o Keeping up with the panning

Demo :
– Capturer une trace
– Localiser un scenario dans la trace
– Investiguer les problèmes de vitesse
– Investiguer les problèmes de fluidité

Cette démonstration utilise à la fois de XAML et du HTML pour montrer que WPA fonctionne dans les deux environnements à la fois sur Windows et sur Windows Phone.
John

[Build 14] – Windows Runtime for Windows Phone Developers

Mail de Mehdi
Vendredi 4 avril 2014 10:31

Windows Runtime for Windows Phone Developers

// Speakers : Doug Holland, Jerry Nixon

On débute la session par un petit Historique de WP (7.0 Silverlight, 7.5 Silverlight, 7.8 Silverlight, 8.0 Silverlight, 8.1 Silverlight et maintenant WinRT)
Le speaker commence par nous dire pourquoi nous devons rester sur du Silverlight : Beaucoup d’investissement (une base importante de code) utilisation de certaines API toujours pas disponible avec WinRT (exemple : VoIP, Lock Screen WP) et que Microsoft respecte nos investissements et que Silverlight pour WP continuera à être supporté/amélioré en parallèle que WinRT.

Ensuite il nous dit pourquoi nous devons re targeter nos applications en Silverlight 8.1. La réponse est simple : pour avoir accès à plusieurs nouvelles API (accès à la carte SD, GeoFencing, App Sharing)

Et enfin, il nous dit dans quel cas nous pouvons/devons choisir WinRT. Et là aussi la réponse est plutôt simple : plus de convergences (avec Windows) nouveaux contrôles (lesquels ? aucune présentation) choix de langage …

Petit rappel sur le async await (avec comme règle toute méthode qui dépasse les 50 millisecondes doit être en asynchrone pour ne pas bloquer l’interface et c’est ce qui fait dans WinRT).

Si on choisit le développement avec WinRT le speaker nous présente plusieurs API qui ne sont plus disponibles et qui sont généralement remplacées par l’API équivalente sur Windows.

Si on utilise Microsoft.Phone.Task :
– MarketplaceReviewTask n’est plus disponibleet doit être remplacé par un lacement d’une uri qui redirige vers le store
– Même chose pour le MarketplaceSearchTask
– Le WebBrowserTask est remplacé par Windows.System.Lancher.LanchUri
– AdressChooserTask remplacé par Windows.ApplicationModel.Contacts.ContactPicker
– PhoneCallTask remplacé par Windows.ApplicationModel.Cells.PhoneCallManager
– SmsComposeTask remplacé par Windows.ApplicationModel.Chat.ChatMessageManger
Microsoft.Phone.BackgroundAgent est remplacé par BackgroundTask (comme sur windows 8) avec plus de features.

La navigartion sur WP ne se fait plus par chemin, mais par type de page (comme sur windows 8)

Le bouton back ne ferme plus automatiquement l’application.

Les fichiers de localisation sont maintenant de resw en XAML nous avons maintenant x : UId l’identifiant qu’on utilise uniquement dans ces fichiers. On peut spécifier une propriété genre LeUidDunElement.text ou LeUidDunElement.Foreground.

Dernier point de la session, on nous reparle de la particularité du fileOpenPicker, quand on l’utilise on quitte l’application (elle passe donc en suspended voir elle est tuée par l’OS) donc quand on sélectionne un fichier l’application est relancée on passe par l’event activeted avec en arguement l’activation par fichier.
Mehdi

[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.