• Améliorez votre productivité XAML en Entreprise
  

• WPF/XAML UI : Chasse aux Fuites Mémoire
  

Merci d’avoir été si nombreux à nous avoir suivi sur place et en ligne. Rendez-vous l’année prochaine !

Publique

La publication dite publique est le mode par défaut. Elle permet de distribuer une application qui, après validation, sera accessible à tous les utilisateurs de Windows Phone dans les régions sélectionnées.

Pour distribuer publiquement une application, il suffit de suivre la procédure par défaut (en anglais) de soumission sur AppHub.

Cachée (privée)

La publication cachée permet aux utilisateurs ayant connaissance d’une URI spécifique (de la forme zune://navigate/?appid=…) de télécharger l’application. Contrairement à la distribution publique, les applications cachées n’apparaissent pas dans les résultats de recherche du Marketplace, mais toute personne disposant de l’URI pourra l’installer. Notons que les applications cachées peuvent être payantes et que le processus de certification des applications cachées est rigoureusement identique à celui utilisé pour les applications publiques.

Pour distribuer une application cachée sélectionnez pour Public Marketplace (l’application sera en effet sur le Marketplace public, mais non trouvable). Puis à l’étape test pour Publish options, sélectionnez As soon as it’s certified, but make it hidden

Private Beta

La publication private beta a pour objectif de mettre gratuitement une application à disposition pour un temps limité à un groupe précis de testeurs, avant une publication publique ou privée. Le groupe de testeur est défini par un ensemble de Live ID, et l’application pourra s’exécuter uniquement sur leurs téléphones pour une durée maximale de 90 jours. A la fin de ce délai, l’application ne démarrera plus et sera automatiquement désinstallée. Notons que les téléphones des testeurs n’ont pas à être débloqués pour exécuter des applications en beta, et que les testeurs n’ont pas besoin d’avoir un compte développeur.

Les applications beta passent par un processus automatique de validation, moins strict que celui utilisé pour la certification. Les applications ainsi distribuées sont donc disponibles plus rapidement que pour les publications publiques ou cachées (généralement sous 24h). Une fois l’application sortie de sa période beta, le développeur pourra choisir de la distribuer via le processus standard de certification et de publication.

Pour publier une application en mode beta, il faut choisir l’option Private Beta Test dans la première page du processus de soumission d’application.

Les applications en beta étant forcément gratuites, l’étape Price ne sera pas affichée. Lors de l’étape test vous pourrez saisir les Live IDs qui auront l’autorisation de télécharger l’application.

Peu après avoir cliquer sur le bouton Submit vous recevrez un mail précisant l’URI permettant d’accéder à l’application. Notez qu’un délai de 24h peut être observé entre la réception du mail et la possibilité de télécharger l’application.

Vous pouvez à tout moment modifier la liste des participants ou terminer la beta en accédant aux informations de votre application :

En espérant que ces informations vous auront été utiles! Et merci à Pierre Cauchois, notre guru préféré de Windows Phone, pour la relecture de cet article.

Pour faciliter la visualisation et directement au coeur des sujets le contenu est présenté sous forme de plusieurs webcasts courtes, ciblant chacune une des nouvelles fonctionnalités de l’OS : live tiles, tâches de fond, intégration XNA, nouveautés du Marketplace etc.

https://msdn.microsoft.com/fr-fr/windowsphone/hh310314

Le Marketplace accepte depuis quelques semaines les applications ciblant Mango : faites partie des pionniers de Mango en soumettant vos applications dès aujourd’hui, et soyez présent dès le jour du lancement !

Venez nombreux !

function Hash($textToHash)

{

    $hasher = new-object System.Security.Cryptography.SHA256Managed

    $toHash = [System.Text.Encoding]::UTF8.GetBytes($textToHash)

    $hashByteArray = $hasher.ComputeHash($toHash)

    foreach($byte in $hashByteArray)

    {

         $res += $byte.ToString()

    }

    return $res;

}

And its usage :

PS #> . Hash.ps1

PS #> Hash("hi")

Instead of SHA256, you can use other hashing algorithms like the ones available by default in .NET 3.5 ou 4 :

• System.Security.Cryptography.MD5
• System.Security.Cryptography.RIPEMD160
• System.Security.Cryptography.SHA1
• System.Security.Cryptography.SHA256
• System.Security.Cryptography.SHA384
• System.Security.Cryptography.SHA512

Happy scripting!

function Hash($textToHash)

{

    $hasher = new-object System.Security.Cryptography.SHA256Managed

    $toHash = [System.Text.Encoding]::UTF8.GetBytes($textToHash)

    $hashByteArray = $hasher.ComputeHash($toHash)

    foreach($byte in $hashByteArray)

    {

         $res += $byte.ToString()

    }

    return $res;

}

Et son utilisation :

PS #> . Hash.ps1

PS #> Hash("hi")

Notez que d’autres algorithmes de hashage peuvent êtres utilisés. On pourra donc substituer au SHA256 un des autres algorithmes disponibles par défaut dans .NET 3.5 ou 4 :

• System.Security.Cryptography.MD5
• System.Security.Cryptography.RIPEMD160
• System.Security.Cryptography.SHA1
• System.Security.Cryptography.SHA256
• System.Security.Cryptography.SHA384
• System.Security.Cryptography.SHA512

Bon scripting!

Silverlight et WPF en entreprise : retours d'expérience, bonnes pratiques et techniques avancées
Le mardi 8 février 2011, 17:30 - 18:30

Silverlight et WPF permettent de réaliser des applications d'entreprise composites à la fois riches et performantes. Cette session décrit, par le biais de retours d'expérience et de code, des techniques éprouvées pour la réalisation de telles applications. Nous traiterons dans un premier temps des patterns d'applications composites (modulaires) et de la gestion des tests unitaires. Nous aborderons ensuite les bonnes pratiques d'intégration permettant aux applications de fournir des expériences utilisateurs riches, tout en restant performantes et maintenables.

Performances et optimisation des applications Windows Phone 7
Le mardi 8 février 2011, 13:00 - 14:00

Fill Rate, UI Thread, Compositor Thread, Bitmap caching, asynchronisme sont les mots clefs de cette session dont le but est de vous aider à créer des applications qui frôlent les 60 images par secondes sans pour autant sacrifier la richesse de l'interface !
Venez en apprendre plus sur le moteur de rendu de Silverlight pour Windows Phone afin de le maîtriser et de comprendre les problèmes de performances que vous pouvez rencontrer sur des devices aux ressources limitées.

Venez nombreux !

If you encounter such a scenario you will undoubtedly notice that the Panorama/Pivot will always take precedence when it comes to handling the panning manipulations. For example, placing a cursor within a TextBox will cause the hosting Panorama/Pivot to pan horizontally as the finger moves left or right to place the cursor. For the exact same reason Sliders and ToggleSwitches tend do not behave as expected.

I have implemented the BlocksPan.IsEnabled attached property to address this scenario. Setting it to true on a control makes any manipulation on the control block the panning of the hosting Panorama/Pivot. The usage is straightforward:

<controls:Panorama Title="MY APPLICATION" x:Name="panorama">

  <controls:PanoramaItem Header="First item">

    <TextBox pcExt:BlocksPan.IsEnabled="True" Text="This textbox blocks the panning"/>

Technically, the idea is to make the parent Panorama/Pivot invisible to hit test when a manipulation is started on a child control where this attached property is set. You can find the source code and an example attached to this post.

Note: Allowing complex user input within a Panorama or a Pivot is not a recommended UX practice on Windows Phone, furthermore expecting horizontal manipulations on controls hosted in a Panorama/Pivot results in an “ergonomic ambiguity”. This extension is only intended to target the few scenarios where creating another dedicated level of navigation does not make sense.

WP7BlocksPan.zip

Si vous êtes déjà familier avec les contrôles Panorama/Pivot, vous aurez sans aucun doute remarqué que ces derniers ont toujours la priorité en matière de gestion des manipulations. Par exemple, placer un curseur dans une TextBox située dans un Panorama/Pivot s’avère difficile voire impossible : le contrôle hôte, plutôt que le curseur de texte, défilera à droite ou à gauche lorsque le doigt glisse horizontalement sur l’écran. Les contrôles Slider et ToggleSwitch sont d’autres exemples similaires.

J’ai pour ces cas précis, implémenté la propriété attachée BlocksPan.IsEnabled. La définir à true sur un contrôle rend les manipulations effectuée sur ce dernier prioritaire par rapport au Panorama/Pivot dans lequel il est hébergé. Son utilisation est simple :

<controls:Panorama Title="MY APPLICATION" x:Name="panorama">

  <controls:PanoramaItem Header="First item">

    <TextBox pcExt:BlocksPan.IsEnabled="True" Text="This textbox blocks the panning"/>

Techniquement, l’idée est de rendre le Panorama/Pivot parent invisible au hit test lorsqu’une manipulation est démarrée sur le contrôle décoré par la propriété attachée. Un exemple et le code source sont disponibles dans le projet attaché.

Note: Permettre les saisies complexes au sein d’un Panorama/Pivot n’est pas une pratique recommandée car elle introduit une “ambiguité ergonomique” qui rend l’interface utilisateur moins déterministes. Cette extension a pour but d’être utilisée dans les scénarios simples pour lesquelles la création d’un niveau de navigation supplémentaire pour la saisie n’aurait pas de sens.

WP7BlocksPan.zip