Debug data in the isolated storage is not easy, mango brought out a new tool: ‘ISTools’, but not necessarily easy to use. That’s why I create a plug-in for Visual Studio 2010 (Express version does not support add-ins) to simplify the task, no need to select the target (emulator or phone) and to give the identifier of the project (which is a bit boring to find).  I leave Chris Sainty to explain the other concerns :

One of the most useful new tools with the latest Windows Phone SDK is the Isolated Storage Explorer.

It is a command line tool used for downloading and uploading the contents of an application’s Isolated Storage folders to either the Emulator or a Device. There are two times when this is invaluable.

 

The first is when you are deploying a new version and you do not want to lose the data. Since day one I have been annoyed with the frequency that that deployment mechanism decides to delete the application and reinstall it. By using this tool I never need to worry about that again as I can just save a snapshot, deploy, load the snapshot back in.

 

The second is when I find a bug with while using a retail copy of my app which I can not hook the debugger into. I can take a snapshot, load it into the emulator and debug.

So here is the add-in ! Simple but effective :

Why use an Add-in ?

SDK Mango has made a new tool called IsolatedStorageExplorerTool, which retrieves data from the isolated storage of your windows phone applications as well as to inject data from your PC to the phone. The only problem is that the tool is not at all easy, here’s what it looks like for example the command line :

ISETool.exe ts xd 11111111-2222-3333-4444-555555555555 "C:\Data\My Files"

Where ts represents an import, xd means « emulator » followed by the identifier of your projectand then the destination directory.

The addin makes it possible to simplify this, it automatically retrieves the identifier of the project and the target (phone or emulator) and remembers the last directory used, you just have to click on the import or export without worrying of it all.

 Installation of the Add-In

Download the file here  : Isolated Storage Tools

Launch the « ISTools.vsix » file, the following window (ok, I’m *le* french) will be displayed :

Click on install and it’s all !

How use the add-in

When you open your windows phone project,  just go to the Tools menu and click on Isolated Storage Tools  :

or you can open the ‘display’ menu > other windows > Isolated Storage Tools

Import data

To import the data from the phone, simply click on import, an Explorer window will appear with all the files of the current application:

You can add or delete files, edit them with your favorite editor, etc … and then reinject them back into the phone or the emulator, click the  »export »  and data from the isolated storage  will be replaced by your new data.

Suite à la sortie de l’IsoStoreSpy par Samuel Blanchard, j’ai voulu ressortir de mes cartons un AddIn que j’avais codé pour déboguer Fuse facilement qui permet notamment de visualiser et d’injecter des données dans l’isolated storage de vos applications Windows Phone 7.

Pourquoi un Addin ?

Le SDK de Mango a apporté un nouvel outils nommé IsolatedStorageExplorerTool, qui permet de récupérer les données de l’isolated storage de vos applications windows phone mais aussi d’injecter des données depuis votre pc vers le téléphone. Le seul problème est que l’outils n’est pas du tout convivial, voici par exemple à quoi ressemble un appel :

ISETool.exe ts xd 11111111-2222-3333-4444-555555555555 "C:\Data\My Files"

Où ts représente une importation, xd signifie « émulateur » suivi par l’identifiant de votre projet et enfin le répertoire de destination.

Il faut donc jongler régulièrement entre téléphone (de) et emulateur (xd) et récupérer l’identifiant de notre projet dans le WMAppManifest.xml ce qui peut être très fastidieux à la fin.

L’addin permet donc de simplifier cela, il récupère automatiquement l’identifiant du projet ainsi que la cible (téléphone ou émulateur) et garde en mémoire le dernier répertoire utilisé, il vous suffit donc de cliquer sur le bouton importer ou exporter sans vous soucier de tout cela.

 Installation de l’Add-In

Après avoir téléchargé l’add-in : Isolated Storage Tools

Cliquez sur le fichier « ISTools.vsix », la fenêtre suivante apparaîtra :

Cliquez sur installer et c’est tout, difficile de faire plus simple !

Utilisation

Lorsque vous ouvrez votre projet Windows Phone, il suffit d’aller dans le menu Outils et de cliquer sur Isolated Storage Tools :

ou encore dans le menu « Affichage » > Autres fenêtres > Isolated Storage Tools

Importer les données

Pour importer les données du téléphone, il suffit de cliquer sur le bouton d’importation, une fenêtre de l’explorateur windows apparaitra alors avec l’ensemble des fichiers de l’application courante :

Il suffit alors d’ajouter ou supprimer des fichiers, les modifier avec votre éditeur favori, etc… pour ensuite les réinjecter dans le téléphone ou l’émulateur, cliquez sur le bouton « exporter », les données de l’isolated storage du téléphone sera alors remplacé par vos nouvelles données.

Un petit article qui fait suite à une question sur le forum MSDN Windows Phone :

Juste pour comprendre et savoir si c’est normal, je viens de voir que si je binder un DateTime sur une textblock ma date s’affiche en format en-US alors que mon tel est en FR et qu’en inspectant mon objet je vois bien la DateTime au format fr.
Alors j’imagine qu’au moment tu binding il doit faire un ToString mais pourquoi il passe une InvariantCulture et pas la current ?

Et en effet, de premier abord ce n’est pas très logique, si ma « culture » de mon application ainsi que celle de l’interface (CurentUICulture) est française, pourquoi mon texte est au formalisme anglais ?

Prenons un example :

<TextBlock x:Name="TextBlockDate" Text="{Binding .}"/>

et dans le constructeur de la classe :

this.TextBlockDate.DataContext = DateTime.Now;

Le système de mon téléphone est en français, le langage d’affichage : français et le clavier : français (on sait jamais !)

et pourtant voici ce qui s’affiche :

FAIL!

Bon sur le coup, c’est pas vraiment à quoi on s’attendait !

La réponse

En fait en plus de CultureInfo.CurrentCulture et CurrentUICulture, il y a un 3ème élément de localisation, souvent oublié : FrameworkElement.Language.

Ce dernier représente la culture des contrôles XAML et à comme type XmlLanguage (XAML est du XML). C’est donc ce dernier qui est utilisé par l’UI lors de la conversion d’un objet en string, et si on regarde de plus près, quelle est sa valeur lorsque j’initialise la page ?

Voila donc le soucis, Language n’est pas lié à la culture et garde sa valeur par défaut : anglais, c’est donc à nous de l’affecter selon la culture courante.

On récupère donc la culture courante :

System.Threading.Thread.CurrentThread.CurrentUICulture

et il nous suffit de trouver un moyen pour la convertir en XmlLanguage.

Pour cela, on va passer par son nom tout simplement :

System.Windows.Markup.XmlLanguage.GetLanguage(maculture.Name);

ce qui nous donne au final :

this.Language =
  System.Windows.Markup.XmlLanguage.GetLanguage(
    System.Threading.Thread.CurrentThread.CurrentUICulture.Name
  );

que l’on va glisser dans le constructeur de la page et par « héritage récursif xaml », les contrôles utiliseront cette localisation.

Projet de test

Lorsque l’on crée une application windows phone, il y a un point qui est très important à faire attention : le choix du thème système par l’utilisateur. En effet l’utilisateur à la possibilité de modifier :
- la couleur ‘accent’ : un choix entre 10 (voir 11 si le constructeur/opérateur a rajouté une couleur)
- le thème : sombre (blanc sur fond noir) ou clair (noir sur fond blanc) qui modifie à la fois la couleur du fond, la couleur des contrôles, du textes, etc…

Toutefois, on souhaite parfois ignorer le changement de thème, on souhaite toujours que notre application ait un fond noir avec des écritures blanches, même si l’utilisateur à choisi le thème clair. C’est notamment le choix que j’avais fait pour TVShow, mais des applications « natives » ont aussi fait ce choix comme pour l’application Mail par exemple.

Forcer le thème sous Windows Phone 7.0

Il est très facile de forcer le thème sous windows phone 7.0, il suffit de se rendre dans le répertoire :

%ProgramFiles(x86)%\Microsoft SDKs\Windows Phone\v7.0\Design

Vous y trouverez l’ensemble des fichiers ressources des différents thèmes :

Chaque répertoire contient deux fichiers : System.Windows.xaml et ThemeResources.xaml, le premier étant identique pour chaque sous thème et le second étant quasi identique mis à part la couleur PhoneAccentColor entre les différents thèmes sombres et les différents thèmes clairs

Ceci dit, on peut simplifier tout cela en supprimant les références à la couleur accent et en supprimant les ressources qui ne change pas entre les thèmes clairs et sombres comme la taille des textes, les polices, etc… :

<Thickness x:Key="PhoneTouchTargetOverhang">12</Thickness>

correspondant à la marge nécessaire pour un élément « touch » et comme la taille des polices, etc…

On peut donc ne garder que deux thèmes : Light et Dark (je n’ai fait que de supprimer les brosses et les couleurs accents) :

forceTheme

Pour les utiliser, on pourrait les mettre directement dans le fichier App.xaml de la façon suivante :

<Application.Resources>

<ResourceDictionary x:Key="styles">

<ResourceDictionary.MergedDictionaries>

<ResourceDictionary Source="Dark.xaml"/>

</ResourceDictionary.MergedDictionaries>

</ResourceDictionary>

</Application.Resources>

Toutefois je le déconseille vivement, car si l’utilisateur à déjà un thème sombre à quoi bon perdre du temps et des resources à redéfinir les ressources inutilement.

Je conseillerais donc plutôt d’écrire dans le constructeur de la classe App

if(((Visibility)this.Resources["PhoneLightThemeVisibility"])==Visibility.Visible)

{

this.Resources.MergedDictionaries.Add(new Resource....)

}

ainsi, on ne redéfinit le thème seulement quand l’utilisateur à sélectionner le thème clair.

Attention toutefois, le fond d’une application n’est pas du Silverlight, il est forcément blanc avec un thème clair par exemple, donc si vous ne mettez pas d’images de fond, pensez au moins à forcer la couleur de fond de votre page.

Et sous mango ?

Bah sous mango, cela ne fonctionne pas…

Et effet, d’après Peter Torr, Program Manager dans l’équipe Windows Phone 7 Application Platform, la méthode que l’on utilisait jusqu’à maintenant était un bogue, et ce dernier a été corrigé depuis. Il propose toutefois deux alternatives :

Utilisez les styles implicites ajoutés à Silverlight 4, ou de mettre à jour les resources à la place de les remplacer de la façon suivante :

(App.Current.Resources["PhoneForegroundBrush"] as SolidColorBrush).Color = Colors.Red

Alors comme Peter Torr n’a jamais tort et que le tort tue, voilà donc une classe qui va vous permettre de forcer le thème de votre application, de plus comme tout es code-behind, nous aurons des meilleures performances qu’auparavant :

static public class ForceTheme
{

static public void ForceLightTheme(this Application application)
{
((SolidColorBrush)application.Resources["PhoneForegroundBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneBackgroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneContrastForegroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneContrastBackgroundBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneDisabledBrush"]).Color = Color.FromArgb(0x4D, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextCaretBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxBrush"]).Color = Color.FromArgb(0x26, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxForegroundBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxEditBackgroundBrush"]).Color = Color.FromArgb(0x00, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxEditBorderBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxReadOnlyBrush"]).Color = Color.FromArgb(0x2E, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneSubtleBrush"]).Color = Color.FromArgb(0x66, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxSelectionForegroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxBrush"]).Color = Color.FromArgb(0x26, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxDisabledBrush"]).Color = Color.FromArgb(0x00, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxCheckBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxCheckDisabledBrush"]).Color = Color.FromArgb(0x4D, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxPressedBrush"]).Color = Color.FromArgb(0x00, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxPressedBorderBrush"]).Color = Color.FromArgb(0xDE, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneSemitransparentBrush"]).Color = Color.FromArgb(0xAA, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneChromeBrush"]).Color = Color.FromArgb(0xFF, 0xDD, 0xDD, 0xDD);
((SolidColorBrush)application.Resources["PhoneInactiveBrush"]).Color = Color.FromArgb(0x33, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneInverseInactiveBrush"]).Color = Color.FromArgb(0xFF, 0xE5, 0xE5, 0xE5);
((SolidColorBrush)application.Resources["PhoneInverseBackgroundBrush"]).Color = Color.FromArgb(0xFF, 0xDD, 0xDD, 0xDD);
((SolidColorBrush)application.Resources["PhoneBorderBrush"]).Color = Color.FromArgb(0x99, 0x00, 0x00, 0x00);

}

static public void ForceDarkTheme(this Application application)
{
((SolidColorBrush)application.Resources["PhoneForegroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneBackgroundBrush"]).Color = Color.FromArgb(0xFF, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneContrastForegroundBrush"]).Color = Color.FromArgb(0xFF, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneContrastBackgroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneDisabledBrush"]).Color = Color.FromArgb(0x66, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneTextCaretBrush"]).Color = Color.FromArgb(0xFF, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxBrush"]).Color = Color.FromArgb(0xBF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneTextBoxForegroundBrush"]).Color = Color.FromArgb(0xFF, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneTextBoxEditBackgroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneTextBoxEditBorderBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneTextBoxReadOnlyBrush"]).Color = Color.FromArgb(0x77, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneSubtleBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneTextBoxSelectionForegroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxBrush"]).Color = Color.FromArgb(0xBF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxDisabledBrush"]).Color = Color.FromArgb(0x66, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxCheckBrush"]).Color = Color.FromArgb(0xFF, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxCheckDisabledBrush"]).Color = Color.FromArgb(0x66, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxPressedBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneRadioCheckBoxPressedBorderBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneSemitransparentBrush"]).Color = Color.FromArgb(0xAA, 0x00, 0x00, 0x00);
((SolidColorBrush)application.Resources["PhoneChromeBrush"]).Color = Color.FromArgb(0xFF, 0x1F, 0x1F, 0x1F);
((SolidColorBrush)application.Resources["PhoneInactiveBrush"]).Color = Color.FromArgb(0x33, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneInverseInactiveBrush"]).Color = Color.FromArgb(0xFF, 0xCC, 0xCC, 0xCC);
((SolidColorBrush)application.Resources["PhoneInverseBackgroundBrush"]).Color = Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF);
((SolidColorBrush)application.Resources["PhoneBorderBrush"]).Color = Color.FromArgb(0xBF, 0xFF, 0xFF, 0xFF);
}
}

Pour l’utiliser, il suffit d’ajouter la classe à votre application et d’écrire dans le constructeur de App :

this.ForceDarkTheme();

ou

this.ForceLightTheme();

selon votre souhait.

Attention encore une fois, le fond d’une application n’est pas du Silverlight, il est forcément blanc avec un thème clair par exemple, donc si vous ne mettez pas d’images de fond, pensez au moins à forcer la couleur de fond de votre page.

Conclusion

Niveau performance, on gagne sur l’ancienne solution, car pas de parsage xaml, toutefois attention, seuls les brush ont été redéfini, il est en effet impossible de redéfinir les Color, attention donc à bien utiliser les SolidBrush et non les Colors.

Enfin, n’hésitez pas à reprendre et adapter le code selon vos besoins et votre charte graphique !

ForceTheme Windows Phone 7

ForceTheme Windows Phone 7.1

[Original version here in french : http://www.rudyhuyn.com/blog/2011/08/13/mango-aura-til-plusieurs-resolutions/]

Since yesterday, a rumor starts run on the fact that a phone mango will present more pixels (800 × 480). I will analyzing the rumor, its source and find an answer.

pieces of evidence

The first piece of evidence is a presentation by Steve Guggenheimer at Microsoft World Partner few weeks ago, with a Samsung Windows phone saying « an amazing screen resolution » (0:26 into video)

The second piece of evidence is more recent, it’s a tweet of Brandon Watson: « telephone he saw with a great screen but can not say more. »

With these two incriminating evidence, Professor Thibault and WMPowerUser have deduced that mango phones come out with screens larger than 800 x 480. Those are the facts, it is now time to put his raincoat, his pipe and to study all the evidence.

The investigation

The beginning

The first thing to do is to study the official documents.

On April 16, Microsoft has introduced the new specifications, the common basis of all future phones mango, from the RAM to the buttons with also the screen pixels: 800 × 480.

Well, one would think that microsoft has changed his mind in the meantime, of course, continue our investigation.

Well, maybe microsoft has changed his mind since … let’s continue

Let’s study the phone

Let’s back to the past, Steve Guggenheimer showed us a phone with a « amazing resolution », but what is the brand of this phone ? Samsung

Then analyze the criminal record of the protagonist.

Samsung has released two windows phone, the Samsung Omnia 7 and Samsung Focus, two phone with a super AMOLED screen, the advantage of Super AMOLED on (super-)LCD is that the super AMOLED has true black, while a super lcd, due to its lighting, display black as gray.

However, this property gives it a drawback: the technology super-AMOLED has grains and we can see like a grid on the screen, to summarize: as if the pixel density appeared lower.

A pixel is composed of three sub-pixels, if you want to show a red pixel, you must only light the red subpixel where as if you want display white, you need to light all the subpixels.

a LCD screen

and if we zoom on a super-AMOLED screen ?

The arrangement of pixels is very strange, if you want to see it in motion, here’s a video: http://www.youtube.com/watch?v=9jJaeJ0gjos

The super amoled uses 8 subpixels to display 4 pixels, where as a LCD use 12 subpixels. If we display a red rectangle for example, the red sub-pixels are much farther in that Super AMOLED LCD, it’s why we see a sort of grid. For an UI like android / iphone, it’s ok because we have degraded, but for solid ink interface like Windows Phone with rectangles of solid color its not good.

Samsung was aware of this problem and has created the super amoled plus which takes the same subpixel pattern than LCD. So it has more subpixels per pixel, which removes the effect of grid and grain.

The new windows phone samsung, based on the Galaxy II, using the super amoled plus, it is obvious that the screen seems for Steve much better than the omnia 7.

Fatality !

Before continuing, let’s review the definition of a resolution: « The resolution is characterized by the number of pixels per unit length, it is actually the density of pixels in the image. » If I tell you: « This is the number of pixels of a screen » in fact I give you the definition of « screen dimension ».

The use of the word resolution for pixel number is a misnomer. The term “display resolution” is usually used to mean pixel dimensions, the number of pixels in each dimension (eg, 1920×1080), which does not tell anything about the resolution of the display on which the image is actually formed: resolution properly refers to the pixel density , the number of pixels per unit distance or area, not total number of pixels. In digital measurement, the display resolution would be given in pixels per inch .

So, I have the misfortune to inform you that you confuse ‘resolution’ and ‘dimension’ for years! I can say truthfully that the Samsung Focus has a higher resolution than the HTC HD7, both have 480×800 pixels, but as the screen HD7 is larger in size, so there are fewer pixels per inch!

You will have noticed that I have deliberately not used the term « resolution » to mean density from the beginning.

Conclusion

Mango has many « resolution » it’s true, but only one « screen dimension » !!!

The pixel density need to prepare applications for this and thus prevent upstream developers and it was not the case.

The only solution to change screen dimension, is to multiply by 2 the number of pixels in height and width to correctly display legacy applications (one pixel => 4 pixels), for us : 1600X960 which is clearly impossible

Ma réponse va être clair : NON !

Depuis hier, une rumeur commence a tourner sur le fait qu’un téléphone mango aura une plus de pixels qu’actuellement (800×480), et je vais essayer tel un détective, d’analyse la rumeur, sa provenance et trouver la réponse à notre question.

Les pièces à conviction

La première pièce à conviction est une présentation par Steve Guggenheimer au Microsoft World Partner il y a quelques semaines, des futurs windows phone, et notamment un téléphone Samsung avec dit-il   »an amazing screen resolution » (0:26 dans vidéo)

La deuxième pièce à conviction est plus récente, c’est des tweets de Brandon Watson sur « un téléphone qu’il a vu avec un écran formidable mais il ne peut en dire plus ».

Grâce à ces deux preuves à charge, Professeur Thibault puis WMPowerUser ont en déduit que des téléphones mango sortiront avec des écrans supérieurs à 800×480. Voilà les faits, il est maintenant temps de mettre son imperméable, sa pipe et d’aller étudier tout cela.

L’enquête

Le commencement

La première piste est d’étudier les documents officiels.

Le 16 avril dernière, Microsoft nous a présenté ce que l’on pourrait appeler vulgairement « le chassis 2″, pour résumer, la base commune de tous les futurs téléphones mango, cela passe de la quantité de mémoire aux boutons et passant par la le nombre de pixels de l’écran : 800×480.

Bon, on pourrait penser que microsoft a changé d’avis entre temps, certes, continuons notre enquête.

On étudie la piste du téléphone

Revenons en arrière, Steve Guggenheimer nous a montré un téléphone avec une « super résolution », certes, mais qu’en était la marque de ce téléphone : Samsung

Analysons donc le casier judiciaire de ce protagoniste.

Samsung a sorti deux windows phone, le Samsung Omnia 7 et le Samsung Focus, ce dernier n’étant pas sorti sur notre territoire, concentrons nous sur le premier. L’omnia 7 a la caractéristique de disposé d’un écran super amoled, l’avantage des dalles Super Amoled sur le (super-)LCD est que le super amoled dispose de vrai noir, alors qu’un super lcd, de part son éclairage, ne pourra s’approcher que du gris.

Toutefois cette propriété lui confére un inconvénient : la technologie super-amoled semble tramé avec du grain, comme si une grille était visible, pour résumer : comme si sa densité de pixels paraissait plus faible.

Rappelons qu’un pixel est formé de 3 sous-pixels, si l’on souhaite afficher du rouge, on n’allume que deux des sous-pixels, pour du blanc, on allume les 3.

un écran LCD vu à la loupe

et un écran AMOLED alors de près ça ressemble à quoi ?

La disposition des pixels est déja plus étrange, si vous voulez voir cela en mouvement, voici une video : http://www.youtube.com/watch?v=9jJaeJ0gjos

Le super amoled pour représenter 4 pixels, utilise ainsi 8 sous pixels, alors que le LCD 12 pixels. Lorsque l’on a rectangle rouge par exemple, les sous pixels rouge sont beaucoup plus eloigné en super amoled qu’en LCD, d’ou cet effet de grille et de résolution plus faible. Pour une interface android/iphone, cela va, car on a des dégradés, peu d’aplat mais l’interface métro des Windows Phone est basé sur justement des rectangles de couleur unie

Samsung a été conscient de ce problème et a donc créé le super amoled plus, qui reprend cette fois la disposition des sous-pixels des LCD, on a donc plus de sous-pixels par pixel, ce qui supprime l’effet de grille et de grain.

Le nouveau windows phone samsung, basé sur le chassis du galaxy II, utilisant le super amoled plus, il est donc normal que Steve trop l’écran bien meilleur que le omnia 7.

On enfonce le clou ?

Avant de continuer, faisons un point sur la définition d’une résolution : « La résolution se caractérise par le nombre de pixels par unité de longueur, c’est en fait la densité de pixels de l’image ». Si je vous dis : « c’est le nombre de pixels d’un écran » en fait je parle de « définition d’un écran ». Vous tiltez maintenant  ? C’est normal, j’ai le malheur de vous informer que vous confondez ‘résolution’ et ‘définition’ depuis des années ! Je peux donc dire sans mentir que le  HTC Mozart à une résolution supérieur au HTC HD7 alors que les deux ont 480X800 pixels, mais comme l’écran du HD7 est plus grand en taille, il y a donc moins de pixel au centimètre carré !

Pour plus d’informations sur la différence entre les deux termes : http://www.pixelvalley.com/appareil-numerique/definition-resolution.php

Vous aurez noté que j’ai volontairement pas utilisé le terme « résolution »  dans le sens densité depuis le début

Conclusion

Le changement de définition n’était pas possible ainsi, il ne peut se faire du jour au lendemain, il faut préparer les applications à cela et donc prévenir les développeurs en amont, sauf à faire comme l’iphone 4, c’est à dire multiplié par 2 le nombre de pixels en hauteur et largeur pour afficher correctement les anciennes applications (un pixel => 4 pixels), soit pour nous 1600X960 ce qui est clairement impossible à ce jour

Je continue la série trucs et astuces avec une petite découverte.

Si vous avez déjà soumis ou mis à jour une application sur le marketplace, vous savez comme moi que c’est assez laborieux, surtout quand l’application dispose de plusieurs langues.

Par exemple : si vous avez 3 langues, il vous faudra uploader trois fois 12 images (3 icones + 1 fond + 8 captures), pour peu que votre navigateur internet ne sauvegarde pas la localisation du dernier répertoire ouvert dans sa boite de dialogue ‘selection de fichier’, vous pouvez facilement passer 5 minutes à ne faire que ça.

Heureusement, le marketplace a été mis à jour récemment et une des nouveautés est qu’il n’est plus nécessaire de re-uploader les images quand on fait une mise à jour (pareil pour la description), un bon gain de temps.

Toutefois lorsque l’on publie son application pour la première fois, on est forcé de les uploader.

le nouveau marketplace

Pour nous faire gagner du temps, Microsoft a ajouté un nouveau lien « browse », assez discret il faut l’avouer (en haut de la capture) qui va vraiment nous aider. Il n’est plus nécessaire de sélectionner individuellement chaque image. En cliquant sur ce lien, une fenêtre de sélection de fichier s’affichera et il vous sera possible de sélectionner plusieurs images, le marketplace les analysera alors et définira lui même que tel image est le « small logo », tandis que celle ci est une capture d’écran.

Mettez donc toutes vos images dans un seul répertoire, nommé vos captures de 1.png à 8.png par exemple, il vous suffira alors de sélectionner le contenu du répertoire et c’est tout ! Un gros gain de temps il faut l’avouer !

Si vous ne le savez pas, j’ai créé il y a quelques moi sur facebook un groupe qui se veut communautaire autour du développement windows phone  : rejoignez nous

Sur ce groupe, j’ai l’habitude de donner des trucs et astuces afin de les partager avec les autres.

Je vais essayer de les compiler sur ce blog en allant plus loin dans les détails.

Comme d’habitude, le premier chapitre sera une introduction destinée aux débutants.

Qu’est ce qu’un input scope

Quand vous définissez un champ de saisie (TextBox), vous avez la possibilité de défnir quel type de contenu ce dernier hébergera via la propriété InputScope : mail, numéro de téléphone, adresse, etc…
Selon l’inputScope choisi, le clavier n’aura pas la même apparence, ni même les mêmes touches :

Sur cette capture, nous retrouvons dans l’ordre les inputScopes : Default, Url, Text, Number et EmailNameOrAddress

Si vous souhaitez connaitre la liste complète des dispositions possibles : http://msdn.microsoft.com/en-us/library/system.windows.input.inputscopenamevalue(VS.96).aspx

L’inputscope Number et mango

Sous Mango, un des InputScope a évolué : ‘Number’,  il représente maintenant uniquement un clavier numérique, alors qu’auparavant c’était le clavier chiffre+symboles

avant/après

Un bon choix je trouve car ce clavier manquait, on pouvait potentiellement faire quelque chose avec le clavier « PhoneNumber », mais il n’était pas idéal.

Que va devenir mon ancienne application ?

Si vous avez une application 7.0 même sous mango, c’est l’ancien clavier qui apparaîtra (histoire de ne pas empêcher les applications qui utilisaient ce clavier de bien fonctionner sous mango). Si vous passez votre application en 7.1, le nouveau clavier s’affichera, donc vérifiez bien qu’il correspond à vos besoins.

Attention aux synonymes

Une petite particularité de cette propriété, c’est qu’une disposition à parfois plusieurs noms, par exemple :

• Digits, TimeMinorSec, TimeHour, DateYear, DateMonth, DateDay et CurrencyAmount sont synonyme de « Number »

Alternative

Si vous préférez l’ancien clavier, vous pouvez toujours y avoir accès en utilisant un des inputs scope :

• Time, PostalCode, PostalAddress, CurrencyAmountAndSymbol ou AddressStreet

Attention à la conversion

Un dernier conseil pour terminer : ce n’est pas parce qu’il est possible de ne taper que des chiffres et un séparateur, qu’il faut penser que c’est forcément un nombre qu’il sera saisi ! Attention donc avant de convertir votre TextBox en int :

- L’utilisateur peut avoir saisi un nombre mal formaté comme « 51..44…4″

- Des téléphones comme le HTC 7 Pro ou le Dell Venue Pro ont un clavier physique et rien ne les empêche de saisir des lettres.