Suite à la formation découverte de Windows Phone 8 du 28 mai à Caen, vous trouverez ci-joint les slides de la présentation ainsi que les démos.
J’en profite pour remercier Olivier et Nicolas de Nokia pour l’organisation de l’événement, Cédric, le directeur du TES de Caen ainsi que l’ensemble des personnes présentes. Tout le monde finalement !
Rendez-vous le 25 juin pour apprendre à coder une vrai application avec Windows Phone 8 !
Pour s’inscrire à cette deuxième journée, suivez ce lien !
Il était temps ! Le voila enfin disponible au téléchargement !
IsoStoreSpy l’application la plus cool pour explorer les fichiers et dossiers de l’IsoStore de vos appplications Windows Phone a enfin été mise à jour !
La grosse nouveauté de cette version est la possiblité d’utiliser des XAPs Windows Phone 8. Les XAPs Windows Phone 7 ne sont pas oubliés pour autant et seront également les bienvenus.
Avec son système de prévisualisation de données (Image, Texte, Données SQL, …), IsoStoreSpy est le compagnon idéal pour vos développement Windows Phone.
Aujourd’hui nous allons parler d’un sujet que je trouve particulièrement amusant : La mise en place d’un moteur de script dans une page XAML!
Mais qu’est ce qu’un script au juste et à quoi cela peut-il nous servir ?
Un script permet en général l’exécution de code sans compilation préalable. Dans notre cas le script sera représenté par une chaine de caractères qui sera interprétée et exécutée à la volée.
Cela peut être très pratique dans certain cas comme rajouter de l’intelligence à une page XAML chargée dynamiquement via un XamlReader par exemple (voir le dernier article de Rudy sur le sujet). Des systèmes de Widget ou des applications modulaires pourraient être aussi envisagés. La possibilité de laisser l’utilisateur modifier lui même certaine partie de votre application est aussi intéressante.
Quel moteur de script allons-nous utiliser ?
Plusieurs possibilités s’offrent à nous mais pour cet exercice je souhaite que le moteur de script soit capable d’exécuter des manipulations complexes de chaînes de caractères pour les Bindings de mes contrôles XAML.
Un bon candidat pour faire cela simplement est incontestablement le JavaScript. Pourquoi me direz vous ? Car celui-ci est déjà disponible par le biais du contrôle WebBrowser !
Description du control
Je désire mettre en place un contrôle dont le contenu sera du JavaScript. Sa propriété Result contiendra le résultat du script.
Le script utilisateur sera exécuté à l’intérieur d’une fonction JavaScript comportant quatre paramètres.
Cette fonction ne sera pas visible de l’utilisateur du contrôle afin de simplifier l’écriture.
function Execute(fromLoaded, parameter1, parameter2, parameter3)
{
// le script du contrôle est ajouté ici par le contrôle
}
Le premier paramètre détermine si la fonction est lancée au chargement du script ou plus tard. C’est utile pour ne pas exécuter le script au lancement par exemple.
Les autres paramètres sont, comme leur noms l’indiquent, des paramètres que l’on retrouvera du coté XAML et qui seront « bindables ».
Le script sera exécuté une fois au chargement du control puis pour chaque modification des paramètres. La propriété Result sera modifiée en fonction.
Réalisation du contrôle
Le control JavascriptExecutor est simplement dérivé de l’objet Control.
Il possède des Properties Dependency qui contiendront le script, les 3 paramètres et le résultat.
à l’initialisation du control on va créer un WebBrowser. Celui ne sera pas ajouté à l’interface graphique car il sera juste utilisé pour exécuter notre JavaScript. Via sa méthode NavigateToString on lui enverra un petit bout de code HTML contenant les tags minimaux pour une page HTML et la mise en place d’un script de type JavaScript :
Ensuite lors des modifications des propriétés Script, Parameters ou lorsque le chargement de la page HTML du WebBrowser est terminé, on exécute le script.
Cet article a été testé sur Windows Phone mais devrait également fonctionner sur des Apps Windows en remplaçant le WebBrowser par un WebView.
La méthode InvokeScript lance l’exécution de la méthode JavaScript « Execute » avec les paramètres du Contrôle.
La valeur de retour est stocké dans la propriété Result.
On aurait pu se servir de la fonction JavaScript « eval » au lieu de créer notre propre fonction « Execute » mais les performances seraient moins bonnes en cas d’exécutions successives ce qui est généralement le cas lors d’opération de Binding.
C’est en revanche une option intéressante dans le cas où plusieurs JavascriptExecutor cohabiteraient dans la même page XAML. On pourrait alors mutualiser le WebBrowser (en le passant en static) et effectuer des changements de Script sans que cela affecte les autres contrôles.
Bref, les deux choix sont acceptables.
J’appelle une méthode C#
Il est souvent utile pour un script de communiquer avec l’interface graphique par exemple pour que la méthode alert du JavaScript affiche un MessageBox C#.
Pour se faire il va falloir que notre script appelle du code C#.
Bien que l’interaction soit limitée, il est possible d’appeler à partir de JavaScript la fonction notify qui générera un évènement dans le WebBrowser coté C#.
On ne peut passer qu’une chaine comme paramètre de cette fonction.
Pour notre MessageBox on va commencer par redéfinir la méthode alert classique du JavaScript (ça c’est beau) pour lui appliquer notre propre fonction qui sera chargée d’appeler la méthode C#.
webBrowser.NavigateToString(
"<html><body><script type='text/javascript'>" +
// on redéfinie la fonction alert coté javascript
"window.alert = function (message) { window.external.notify('MessageBox' + '|' + message); };" +
"function Execute(fromLoaded, parameter1, parameter2, parameter3){" + script + "};\n" +
"</script></body></html>"
);
La fonction notify ne prenant qu’un seul paramètre on ruse en concaténant les deux paramètres contenant le nom de la commande et le message de l’alerte à l’aide d’un séparateur « | ».
Pour une utilisation plus professionnelle on pourrait encoder en Base64 les paramètres pour éviter toute collision avec des | utilisés dans le message.
côté WebBrowser on obtient ceci:
webBrowser.ScriptNotify += new EventHandler<NotifyEventArgs>(webBrowser_ScriptNotify);
/// <summary>
/// On recoit un script
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
void webBrowser_ScriptNotify(object sender, NotifyEventArgs e)
{
// On récupère la commande et le paramètre de alert
string[] data = e.Value.Split(new char[] { '|' });
string command = data[0];
string parameter = data[1];
switch( command )
{
case "MessageBox" :
// La commande coté C# est lancée
MessageBox.Show(parameter);
break;
}
}
La démo
La démos est composé de trois scripts.
Le premier permet d’inverser la chaîne de caractères saisie dans une TextBox et montre l’utilisation de la fonction JavaScript alerte en cas de chaîne vide.
Le second permet de créer une chaîne de caractère à partir de trois sources différentes :
Une TextBox, un Slider et une CheckBox.
Le dernier de mettre en place le Margin d’un rectangle selon les informations de deux Slider.
Tous ces scripts sont modifiables dynamiquement dans une boîte de dialogue.
Les limites de notre système
Voila notre système de script est pleinement fonctionnel et l’on peut déjà effectuer des Binding très puissant.
Mais nous ne sommes capables que de manipuler des chaines de caractères.
En rajoutant des fonctions notifiées comme nous l’avons fait pour alert/MessageBox il est possible de se constituer un petit Framework.
J’ai fait quelque test avec une méthode SetXamlString qui permet à partir d’une chaîne de caractères JavaScript d’écrire dans le Content d’un ContentControl. C’est puissant mais cela reste toujours compliqué de véritablement maîtriser les contrôles XAML de notre page.
Il est temps de passer à plus puissant : IronMan ? non ! IronRuby !
Ce prochain article sera publié dans le magazine Programmez! Ne le manquez pas on y verra des choses plus avancées encore comme l’appel d’événement ou la manipulation de l’UI !
Je suis en train de créer avec quelques amis une application Windows Phone 8 pour un concours. Cette application s’adresse aux enfants et aux adolescents.
L’application est découpée en deux parties. Une partie comportant le jeu proprement dit et une autre comprenant un store ou l’utilisateur peut acheter de nouveaux modules.
La carte de crédit de papa
Si je laisse un enfant jouer avec notre application, il pourra accéder à la partie achat ce qui peut être génant car l’achat peut être effectuer sans aucune autorisation.
On pourrait bloquer la partie achat par un code préalablement enregistré par l’adulte mais cela manque de simplicité à la fois pour l’utilisateur et le développeur qui doit rajouter une interface spécifique.
Pour résoudre notre problème il suffirait de savoir quand l’application est lancée par l’enfant ou l’adulte afin d’afficher ou pas la partie achat.
Le kid’s corner
La solution est de faire jouer l’enfant dans le « Kid’s Corner » appelé aussi « le monde des enfants » en français. Pour ceux qui ne connaissent pas cette nouveauté introduite dans Windows Phone 8, celui-ci s’active à partir des paramètres du téléphone. Il est possible de sélectionner des jeux, des vidéos, de la musique et, ce qui nous intéresse, des applications auxquels l’enfant sera autorisé à accéder.
On ajoute donc notre application à la liste et après activation il suffit de se rendre sur le lockscreen et de faire glisser son doigt vers la gauche pour faire apparaitre « le monde des enfants ». Un swip vers le haut et le monde des enfants laisse apparaitre les applications autorisées.
D’où viens-tu ?
La personne qui lance l’application depuis « le monde des enfants » sera considérée comme ayant des droits minimals.
Mais il reste à trouver comment notre application sera avertie de la source de son lancement.
Pour ce faire il suffit de consulter la classe ApplicationProfile n’importe où dans l’application :
if (ApplicationProfile.Modes == ApplicationProfileModes.Alternate)
{
MessageBox.Show("Monde des enfants ! Je n'affiche pas la partie paiement !");
}
else
{
MessageBox.Show("Ecran d'accueil ! j'affiche tout !");
}
Pour débugger rapidement une page ou tout simplement parce que vous voulez démarrer sur votre propre page il peut être intéressant de changer la page de navigation par défaut de votre application (MainPage.xaml). Dans cette article nous passerons de la page MainPage.xaml à SearchPage.xaml.
Avec Visual Studio
Si vous travaillez avec Visual Studio 2010, il suffit d’accéder au fichier WMAppManifest.xml dans le dossier Properties de votre projet.
Une fois le fichier XML ouvert, modifier l’attribut NavigationPage du tag DefaultTask.
En revanche, si vous utilisez VisualStudio 2012, c’est encore plus simple puisque lorsque vous accédez au fichier WMAppManifest.xml une interface de toute beauté s’ouvre (c’est la nouveauté). Une zone de saisie nommée « Navigation page » vous permet de modifier directement la page de démarrage.
Avec Blend
Pour les afficonados de Blend (il y en a) c’est également possible très simplement en parcourant le menu « Projet ».
Login