Pierre's Embedded and Mobile Blog

Soulevons le capot des systèmes embarqués et mobiles

December, 2009

Posts
  • Pierre's Embedded and Mobile Blog

    OpenPlug lance un concours de développement d’applications mobiles cross-platform

    • 0 Comments

    Ceux qui me connaissent savent que j’aime parler d’autres technos que celles de Microsoft.. en l’occurence, parlons d’un outil basé sur Flex Builder (et donc Eclipse et de l’Action Script).

    Pour beaucoup de développeurs d’applications mobiles, ça serait bien pratique d’avoir un outil cross-platform pour développer des applications ciblant les différents marchés d’applications en même temps. C’est la promesse que veut tenir OpenPlug avec leur environnement ELIPS Studio 3. OpenPlug est une petite boite française qui a un lourd passé dans le mobile notamment avec leur suite d’application et leur stack mobile et pour avoir joué un peu avec ELIPS Studio 3 (même si c’est basé sur Eclipse, FlexBuilder et de l’ActionScript) c’est vraiment pas mal :)

    Ce concours d’applications mobiles propose de gagner l’inscriptions aux principaux stores d’applications (Appstore d’Apple, Marketplace Windows Phone, Android Market, et OVI Store) ainsi que la célébrité avec des présentations au CES! Pour cela il faut envoyer l’application avant le 31 Janvier, donc il faut se dépêcher :)

    Ce qui est encore plus cool c’est que ce concours favorise également de participer aux concours des différents acteurs dont AppFab, notre concours d’applications pour Windows Phone qui se termine au 31 décembre (plus que 2 semaines! soumettez si vous ne l’avez pas fait!!)

    Bientôt, je ferai un petit billet sur ce qu’on peut faire avec ELIPS Studio par rapport à Visual Studio :)

  • Pierre's Embedded and Mobile Blog

    Evènement: Windows Embedded dans l’industrie

    • 0 Comments

    Windows Embedded, c’est tout une famille de systèmes d’exploitations et d’outils à destination des fabricants de systèmes embarqués, notamment les industriels: c’est une plateforme qui va des capteurs aux serveurs, et qui peut servir dans tous les équipements de l’usine.

    Pour découvrir et démontrer tout ça, le groupe Windows Embedded organise un évènement  Mercredi 16 Décembre 2009, dans les locaux de Microsoft à Issy-Les-Moulineaux. La journée sera divisée en 2 parties:

    • Matin: Sessions Microsoft et Partenaires
      • Embarquez Windows XP Pro FES et Windows 7 FES dans vos systèmes industriels
      • Découvrez Windows Embedded Standard 2011
      • Mise en Œuvre du temps-réel sous Windows Embedded CE pour le développement d'équipements industriels: enjeux et solutions
      • XPE et Windows Embedded Standard 2009 en temps-réel: c’est possible!
    • Après-midi: 2 workshops techniques
      • Lab1: Découvrez comment générer une image Windows Embedded CE 6.0 R3 sur une carte TI OMAP 3530, en démontrant ses capacités temps-réel
      • Lab2: Découvrez comment générer une image Windows Embedded Standard 2009 incluant l’extension temps-réel RTX

    L’invitation sur le site Windows Embedded en Français

  • Pierre's Embedded and Mobile Blog

    Localiser votre Widget

    • 0 Comments

    Le principe de localisation d’un widget est d’une simplicité enfantine : le widget est découpé en un certain nombre de fichiers, et de dossiers, dont par exemple le dossier « js » qui contient les javascripts, le dossier « css » qui contient les feuilles de style, etc.
    Pour localiser un widget, il suffit, à la racine de ce widget, de créer un dossier pour la langue de votre choix (fr, dans mon cas) et de reprendre, par un simple copier/coller les dossiers et les fichiers que vous voulez localiser : une image valant mille mots…

    clip_image001

    Une fois encore, bien entendu, il faut que les ressources portent le même nom ! On peut stocker les chaines de caractères dans des ressources Javascript par exemple :

    • Dans mon HTML :
    <p><script type="text/javascript">document.write(maChaine);</script></p>
    <img alt="flag" src="img/flag.png"/>
    • Dans mon fichier Javascript par défaut (contenu dans le dossier js)  :
    var maChaine = "Hello, world!";
    • Et dans mon fichier Javascript Français (contenu dans le dossier fr/js) :
    var maChaine = "Bonjour, monde!";

    Vous voilà donc armé avec les outils pour localiser simplement votre application ou votre Widget :) Alors n’hésitez pas à viser un maximum de pays !

  • Pierre's Embedded and Mobile Blog

    Localiser votre Application .NET

    • 3 Comments

    Avec le découpage en région de Marketplace et les règles associées à la validation des applications, il devient nécessaire pour le développeur d’applications ou de widgets de se poser la question de la traduction, ou plus généralement de la localisation de ses applications.

    Les règles de localisation de Marketplace :

    http://developer.windowsphone.com/resources/fr-FR/MarketplaceMarketValidationGuidelines.pdf

    La localisation, c’est la pratique qui consiste à adapter son application au contexte régional : il s’agit bien-sûr de la langue, mais éventuellement aussi des ressources images, et dans les cas les plus extrêmes, d’une adaptation des fonctionnalités ou du contenu en fonction des lois en vigueur dans le marché visé.

    La localisation (localization dans la langue de Shakespeare) n’est pas à confondre avec la géolocalisation (geolocation), l’acte de situer des éléments dans un repère géographique J Pour ceux que ce dernier sujet intéresse : cette série de billets est faite pour vous :

    En l’occurrence ici, parlons de la localisation d’applications dans le sens, donner à son application le support de plusieurs locales :)

    La première question qu’on se pose quand on localise une application est bien entendue celle de la langue : Comment faire pour changer toutes ces chaines de caractères et ces images en fonction de la langue de l’utilisateur ? En fait il y a plusieurs choses à connaitre :

    Les règles pour localiser les WinForms

    Cette partie est très simple, car quasiment les mêmes règles s’appliquent pour le framework .NET « de bureau » et le Compact Framework :)

    Vous pouvez trouver un article sur MSDN sur le sujet, ainsi qu’un article du MVP Thomas Lebrun

    La méthode est la suivante : il faut commencer par créer son interface dans la langue « par défaut » c’est-à-dire celle qui sera utilisée quand aucune locale spécifique ne sera détectée. Il suffit de le faire comme à l’accoutumée, avec le designer Visual Studio.

    Une fois que cette interface est définie, il reste à la traduire ! D’abord il faut indiquer que le formulaire va exister dans plusieurs langues : c’est le but de la propriété « Localizable » du formulaire, qu’il faut mettre à la valeur « true ».

    clip_image001

    Ensuite, il faut changer la propriété « Language » pour la mettre à la locale que l’on veut : par exemple, Français (France), qui correspond, selon la notation ISO, à fr-FR

    Ceci étant fait, il ne reste plus qu’à traduire, directement dans le designer ! Changer sans vergogne le texte des boutons, des menus, etc.

    Une fois ceci terminé, vous pouvez repasser la propriété « Language » à ((default)) pour vous apercevoir que les ressources ont bien été sauvegardées dans chaque langue : en fait, chaque chaine de caractère traduite est stockée dans un fichier ressource (de type .resx) associé au formulaire : si vous cliquez sur le « + » devant votre formulaire principale dans la vue « solution », vous verrez qu’une notation « standard » est adoptée :

    • Form1.resx pour le formulaire par défaut
    • Form1.fr-FR.resx pour le formulaire en Français

    clip_image002

    Mais quid des autres ressources ? Les textes dans les boites de messages par exemple ? C’est très simple, nous allons utiliser le même principe, mais à l’échelle de l’application.

    Les règles pour les autres ressources

    Pour stocker des chaines de caractère ou n’importe quelle autre ressource localisée, nous allons utiliser… un fichier ressources (avec l’extension .resx donc).

    Pour ajouter un fichier de ce type au projet, il convient de cliquer à l’aide du bouton droit de la souris sur le projet, puis sur « Add New Item » et de choisir, dans la catégorie « General », le type « Resource file » : à le nommer, et cliquer sur Add.

    AddResourceFile

    Le fichier .resx apparait maintenant dans les fichiers du projet : reste à le remplir, en faisant bien soin au nommage des différents éléments : en effet, c’est par leur nom que nous utiliserons les ressources dans le code !

    Une fois ces ressources créées, il reste à les traduire. Pour cela, nous allons tout simplement copier/coller le fichier de ressources, et le renommer, en utilisant la convention « classique » : imaginons que votre fichier s’appelle Resource1.resx, pour la langue par défaut, alors la copie de ce fichier devra s’appeler Resource1.fr-FR.resx (ou tout autre locale de votre choix !)

    clip_image003

    Reste à l’utiliser dans le code : pour cela nous allons utiliser la réflexion (c’est un terme technique du framework .NET, rien à voir avec le fait de se servir de son cerveau !) et une classe qu’on appelle le ResourceManager : voici comment c’est fait :

    ResourceManager rm = new ResourceManager("DemoLMLocalisation.Resource1", typeof(Form1).Assembly);
    MessageBox.Show(rm.GetString("LocalizedMessage"));

    Dans ce code, on commence par initialiser le ResourceManager en lui donnant le nom de la ressource qu’on veut utiliser. Ensuite, on utiliser la méthode GetString, pour aller chercher la bonne ressource :) C’est aussi simple que 2 lignes de code !

    La question qui tue : Est-ce possible de changer la langue de l’application en cours de route ?

    Malheureusement, le .NET Compact Framework n’offre pas cette possibilité, qui dans le Framework .NET « de bureau » existe pourtant sous la forme de la propriété Thread.CurrentThread.CurrentCulture et Thread.CurrentThread.CurrentUICulture. Il faudrait trouver un autre moyen de le faire "programmatiquement", et ceci dépasse largement le cadre de ce simple article :)

Page 1 of 1 (4 items)