Browsed by
Month: March 2012

Fast App Resume est bien présent sur les Windows Phone Tango

Fast App Resume est bien présent sur les Windows Phone Tango

Le 7 mars, alors que je sortais d’une nuit blanche durant le hackathon “Le Mobile”, j’ai appris la rumeur provenant d’autres participants, que les windows phone tango n’avaient pas la fonctionnalité “Fast App Resume”. Plutôt surpris par cette nouvelle, sachant que l’on avait déjà eu la confirmation que les background agent allaient être désactivés, je n’arrivais pas trop à y croire car cela serait un retour à Nodo (les principales nouveauté de mango étant le fast app resume et les background agents).

J’avais eu l’occasion d’essayer le lumia 610 pendant quelques jours pendant mon escape à Seattle une semaine auparavant et je n’avais pas remarqué ce manque. Afin de confirmer mes doutes, il se trouve, que sur le salon, se trouvait un stand Nokia avec bien caché dans une mallette, des Nokia 808 (l’appareil photo est impressionnant), des Lumia 900 et surtout des Lumia 610 !

Donc je le confirme bel et bien, après quelques tests avec un vrai téléphone, le fast app résume est bien présent sur les téléphones tango !

Toutefois attention !

La mémoire de ces téléphones peut-être de 256Mo (ce qui ne sera pas le cas de tous les téléphones tango, qui pourront en avoir plus, mais chut pour l’instant), donc comme le fast app resume consiste à garder les données de l’application en RAM pendant l’exécution d’une autre, les probabilités sont plus fortes pour que le téléphone supprime ces données de sa mémoire suite à l’ouverture d’une ou plusieurs applications gourmande en mémoire.

Sachant qu’une application sous tango ne devra pas dépasser les 90Mo de RAM, on peut estimer qu’une grosse application peut rester en mémoire si plusieurs petites sont lancées. Deux grosses applications (2X90Mo=180Mo) n’auront pas forcément la possibilité d’être en mémoire toutefois.

Que dit la MSDN ?

Cette dernière est plutôt claire :

 Fast Application Switching is supported on 256-MB devices. However, because keeping applications in a dormant state for Fast Application Switching is dependent on the phone’s available memory, an application running on 256-MB devices will be terminated and tombstoned more often and more quickly than the same application running on a phone with more memory.

source  http://msdn.microsoft.com/en-us/library/hh202866(v=vs.92).aspx

Testons avec l’émulateur

Pour tester si une application revient du tombstoning ou du fast app resume, il suffit de regarder la valeur de IsApplicationInstancePreserved lorsque l’on passe dans la fonction App_Activated, ainsi si on écrit :


private void Application_Activated(object sender, ActivatedEventArgs e)
{
ComeFromFAR = e.IsApplicationInstancePreserved;

}

Et il suffit d’écrire dans la fonction Loaded de MainPage :


IsFARTextBlock.Text=(((App)Application.Current).ComeFromFAR?"TRUE":"FALSE");

Voici donc le résultat avec deux petites applications lancée en affichant le multitâche :

et si je sélectionne une des applications :

On voit bien que l’application revient de Fast App Resume.

Gestion de la zone de rendu

Gestion de la zone de rendu

Suite à l’article de mon excellent collègue et ami Samuel Blanchard http://blog.naviso.fr/wordpress/?p=1304 mais aussi celui de Patrick Tien http://pthien.com/2011/11/01/moving-from-xna-to-xnasilverlight-hybrid-on-wp7/

Je vais essayer de vous expliquer pourquoi on rencontre ce problème tout en expliquant comment fonctionne la zone de rendu sur windows phone.

Le rendu

Il est très important de différencier résolution de l’écran et zone de dessin. Il se trouve qu’il y a deux cas où la zone de dessin Silverlight ou XNA n’est pas de 800*480 :

  • Lorsque l’on affiche une systemtray avec opacité à 1
  • Lorsque l’on affiche une application bar avec une opacité à 1

Dans ces deux cas, il faut savoir que ces deux éléments font parti du système et ne sont pas Silverlight, c’est pour cela qu’ils sont toujours fluide, quelque soit les opérations que vous faites en Silverlight. C’est aussi pour cela qu’il n’est pas possible de binder les propriétés de l’applicationbar nativement.

Windows Phone considère qu’il est intéressant d’optimiser le rendu de silverlight en limitant celui-ci à la zone visible afin de gagner en performance. On gagne ainsi :

  • 32*480 pixels lorsque la systemtray est visible en mode portrait
  • 72*480 pixels lorsque la systemtray est visible en mode paysage
  • 72*480 pixels lorsque l’application bar est visible

Ainsi si on affiche à la fois la systemtray et l’applicationbar, notre zone de rendu est de 656*480 au lieu de 800*480, on perd ainsi 18% d’espace à dessiner, ce qui ne peut qu’améliorer les performances.

Et donc pourquoi ce problème avec XNA+Silverlight ?

En réalité, SharedGraphicsDeviceManager.Current.GraphicsDevice essaie toujours de rendre la partie XNA sur une texture de 800*480, la résolution native de l’ensemble des windows phone.

Or comme notre zone de rendu est diminuée 768*480 si on affiche la systemtray, le système va faire ce qu’il sait faire de mieux pour afficher sa texture : la redimensionner afin qu’elle rentre dans la zone de rendu tout en gardant les proportions (comme le Stretch=”Uniform” des objets Image), celle-ci sera donc affiché avec les dimensions suivantes :

  • hauteur : 768
  • largeur : 480*RATIO= 480*(768/800) = 460.8

D’où les bandes noires sur le côté et l’effet de flou dut au redimensionnement de la texture (et donc de l’interpolation des pixels).

Comme on l’a vu auparavant, vous rencontrerez exactement le même soucis avec l’applicationbar, la texture xna sera alors de :

  • hauteur = 800-72=728
  • largeur : 480*RATIO= 480*(728/800) = 436.8

Et allons encore plus loin, si on affiche à la fois une systemtray et une applicationbar :

  •  hauteur = 800-72-32=696
  •  largeur : 480*RATIO= 480*(728/800) = 417.6

 

 

L'icône partager sous windows (phone/8)

L'icône partager sous windows (phone/8)

Edit : la consumer preview de windows 8 ne possède plus la même icône, Microsoft ayant préféré créer leur propre icône afin d’éviter les problèmes de trademark surement.

Pour changer un peu, on va parler un peu de design.

Afin de guider facilement l’utilisateur, on associe souvent des actions à des symboles.

Windows 8 et Windows Phone, qui partagent tous les deux la même philosophie d’interface nommée “Metro”, sont plutôt cohérents dans leurs choix icônes. On retrouve ainsi le sac pour le marketplace, la roue crantée pour les paramétrages, la bulle avec un smiley pour les messages, etc…

 

Malheureusement, dès que l’on sort des icônes fournies par défaut, on arrive parfois à des différences. Plusieurs applications majeures windows phone 7 utilisent l’icône suivante pour symboliser le partage de contenu :

Quelques exemples d’application utilisant cette icône :

(à noter que les applications first-party de windows phone évite d’utiliser une icône pour réprésenter le partage)

or sous windows 8, dans le “charm”, on trouve une icône bien différente pour représenter le partage :

 

Alors quelle icône doit-on utiliser et surtout pourquoi cette différence ?

Un peu d’histoire 2.0

La première icône à été créée par Alex King pour le plug-in WordPress “Share This”. Elle avait alors été designé pour bien se marier avec les icônes RSS et OPML.

Mise à disposition sous license open-source : GPL, LGPL, BSD et CC Attribution 2.5, de nombreuses applications et services commencent alors à utiliser cette icône, toutefois l’icône est rachetée par Nextumi, Inc. (DBA ShareThis) qui est donc le propriétaire de cette icône depuis, et c’est la que les soucis commencent. Malgré le maintien des licences open-source, plusieurs plaintes ont été déposé par Nextumi contre d’autres services utilisant cette icône, ce qui n’est évidemment pas très “social”.

Suite à cela, une nouvelle icône nommée “open share icon” a été créé par Shareaholic, un service web de partage, et mise à disposition sous licence creative common, la seule restriction d’utilisation est l’interdiction de l’utiliser comme logo ou comme favicon.

A titre de comparaison :

C’est cette dernière que Microsoft a choisi pour représenter ses fonctionnalités de partage sous windows 8 car moins contraignante dans l’usage et surtout plus libre.

Conclusion

N’utilisez pas l’icône originale, préférez plutôt l’icône “open share”, vous gagnerez en cohérence avec windows 8 et surtout, vous ne risquerez pas de poursuites.

Cadeau Bonus

Afin de vous facilliter la tâche, je vous ai créé une icône spécialement pour l’applicationbar windows phone 7 (avec transparence) :

Le rendu de l’icône dans une application :

Templates de projets windows phone indisponibles dans visual studio

Templates de projets windows phone indisponibles dans visual studio

Lorsque vous installez le SDK de windows phone, l’installateur va vérifier si vous avez visual studio d’installé sur votre poste, si ce n’est pas le cas, alors il installera visual studio express. Si par la suite vous installez visual studio, les templates de projets Windows Phone n’apparaitront pas lorsque vous créerez un nouveau projet.

A savoir, il se peut aussi qu’en installant le SDK alors que vous avez déjà visual studio, l’installateur ne trouve pas votre instance et ne vous installe pas les projets.

Dans les deux cas, ce n’est pas très grave, il est possible de les installer manuellement sans devoir désinstaller et reinstaller le SDK.

Comment faire ?

Lorsque vous créez un nouveau projet ou un nouvel item, visual studio va analyser deux répertoires :

C:Program FilesMicrosoft Visual Studio 10.0Common7IDE

et

C:UsersXXXXDocumentsVisual Studio 2010Templates

Le premier contient les templates préinstallés par visual, le second les templates installés par l’utilisateur (dans les répertoires projecttemplate et itemtemplate)

Il nous suffit donc d’ajouter les templates manquants au premier répertoire pour corriger notre problème. Pour cela, j’ai créé un zip contenant l’ensemble des templates, il suffit donc de le dézipper dans

C:Program FilesMicrosoft Visual Studio 10.0Common7IDE

Le zip : IDE

 Mettre à jour le cache

Etant donné que les templates sont mis en cache, il faudra penser à supprimer les dossiers ProjectTemplateCache et ItemTemplateCache pour mettre à jour la liste des templates