Xamarin–notes

Prise de notes : J’ai suivis deux tutos gratuit assez complet sur Xamarin, depuis la MVA (Microsoft Virtual Academy). Ces tutaux commencent a être un peut vieux (tout est relatif, il date de 2014 quand meme, l’année de lancement de Xamarin Forms). Cependant j’y ai appris pas mal de chose. Certaine question ont eu leurs réponses, mais beaucoup d’autre ont été soulevées. Je noterai ici mes notes concernants Xamarin. Ce n’est pas un tuto mais plutôt quelques réflexions, astuces, mémo et lien en tout genre. Ressouces : Développer une application cross-plateformes avec Xamarin Cross-Platform Development with Xamarin & Visual Studio Design Chaque OS possède son propre design. Par exemple ici le date picker : 3 écrans iOS Android et WP avec une même interface graphique (Xamarin.Forms) Xamarin permet de créer des applications natives respectant chaque UI. Mais il faut les construire une à une. Pour aller plus vite, on peut utiliser Xamarin.Forms qui va mutualiser la création d’interface graphique pour les 3 OS. Shared Project VS Portable Library ? Shared Project : Contient des éléments partagé (code, image data). Il n’est pas compilé mais importé dans chaque projet (WP, Android, iOS) et ensuite il sera compilé. MVVM + IoC + dependency injection. Peut inclure des #ifdef (if IOS, if Android…) Portable Class Library (PCL) : projet compilé puis importé par d’autre projet WP, Android, iOS. Ne contient que du code par définition (business logic). Peut contenir du data static (fichier xml, json… le passer en ressource embarquée). Xamarin PCL a une class nommé Device qui permet de de jongler avec les plateformes (Device.OS, Device.OnPlatform, Device.Idiom, Device.GetNamedSize) Plus d’info : Explication officielle de Xamarin Wiki de MvvMCross Device class de Xamarin article intéressant, retour d’expérience Mais attention, sous android, les données sont situées normalement dans le répertoire Ressource. A priori on ne peut pas charger des données sur android depuis un shared project. Du coup une image ne peut pas être mutualisée. A voir si ca a pas changé depuis (info de 2014)   Life Cycle iOS App + View (different state)   Android App + Activity   Astuce : sur android, lors d’un chargement de carte, il faut attendre qu’elle soit chargée avant de lui attribuer des markers. Astuce : sur android, les cartes google map on besoin d’une clé par device en dev, à ajouter manuellement dans l’API console en ligne. https://developer.xamarin.com/guides/android/platform_features/maps_and_location/maps/obtaining_a_google_maps_api_key/ Astuce : encore sur les maps android, il faut inclure des libs (GooglePlayServicesLib.dll et des Xamarin.Android.Support…) ou aller sur les prendre directement dans le components stores de Xamarin. Ou utiliser un package Nuget Xamarin Form Maps qui s’en chargera. Astuces : les cartes google on besoin de tout un tas de permissions.

DIY – Smartphone control RGB led strip with ESP8266

Voici un mini tuto qui va expliquer les quelques étapes pour réaliser un serveur web sur le board ESP8266, qui pilote une bande de led RGB. le tout contrôlé à distance via Wifi par une simple application windows phone (qui aurait pu être une app web directement hébergé par l’ESP, je viens seulement d’y penser…) L’idée, piloter à distance via son smartphone la couleur de la lumière d’une bande de led RGB. La démo : Outils / soft / materiel : 1 ESP 12 dev kit (ou avec un board moteur) 1 amplificateur (12V/24V) 4 fils de couleurs (blanc, rouge, vert, bleu) (connecteur male/femelle) 1 alimentation 12v ou 24v suivant votre bande led en sortie (optionnel un interrupteur) 1 ou plusieurs bandes led RGB (5050 pour moi) (exemple) 1 pince coupante ou a dénuder 1 tourne vis plat Node.js installé sur votre machine + le package esp8266 Lua Loader (windows) ou un autre soft de votre choix, ou en ligne de commande 1 smartphone (windows phone mais le code serait pas dur à réaliser sur iOS ou Android) Montage : Nous avons d’un coté l’application smartphone, autonome, connecté en wifi sur ma box. De l’autre le montage composé d’un module dev kit ESP 12 (ESP8266) relié par 4 fils (blanc pin 4, rouge pin 6, vert pin 7, bleu pin8) à l’amplificateur. Celui ci est alimenté en 12v et en sortie on a branché une bande led RGB avec 1 fil par couleur + un fil blanc (+12v). Vous n’êtes pas obligé d’avoir  un amplificateur. Vous pouvez à la place réaliser un montage supplémentaire avec 3 moftsets (ici pour plus d’info). Mais il faut impérativement isoler le circuit ESP (5v) de celui de vos leds (12v ou plus) Par mesure de sécurité, je vous conseille l’amplificateur + un transfo 12v, c’est simple et pas de risque de prendre du 230v. Faites attention quand même ! Fonctionnement : L’esp boot sur le fichier init.lua. Celui ci va se connecter en mode station (paramétrable en AP si besoin) et obtenir une adresse IP de ma box (DHCP). Celle ci s’affiche (notez la pour la suite). Ensuite le code lance un serveur web http très simple, écoutant le port 80. Le serveur va donc traiter des urls de ce type http://192.168.1.18/?r=125&g=30&b=240&on=1 Les paramètres r, g, b correspondent à la couleurs désiré. Le paramètre on sert pour allumer ou éteindre la bande led. A ce stade, le serveur attend un ordre que l’on enverra depuis un smartphone. Pour savoir que mon serveur est démarré, je lance une petite séquence de lumière Code ESP: J’avais l’habitude de séparer mon code en plusieurs fichiers, histoire d’uploader mon code plus facilement (car c’est long) sur l’esp. Ce code https://github.com/couscousbzh/ESP8266-RGBServer vous permet de jouer avec. Il fonctionne tant que vous êtes connecté par usb. Mais dès que vous rebootez, c’est la catastrophe. Et je ne sais pas pourquoi. Donc lors de mon dev, tout ce passe normalement. Mais dès que je passe en mode prod, c’est dire une alimentation simple par usb de l’esp, ca ne fonctionne plus. Si quelqu’un sait pourquoi, pourriez vous me laisser un commentaire svp ? J’ai donc tout réunit dans un seul fichier init.lua, et c’est un peu mieux (ou pas). Vous le trouverez ici : https://github.com/couscousbzh/ESP8266-RGBServer/blob/master/initallinone.lua (pensez à le renommer en init.lua) Explication du code : Pour afficher une couleur, par exemple le rouge, on balance un niveau haut sur le fil rouge. Donc 5 volts avant ampli puis 12v en sortie. On a du rouge si le vert et bleu n’éclaire pas du tout. Sinon on a de la lumière blanche si le rouge vert bleu éclairent tous. En informatique, on représente souvent la couleur par un integer sur 8 bits c’est à dire un chiffre entre 0 et 255. Ecrit comme cela RGB(255,0,0) signifiera que l’on veut du rouge seulement. Pour mieux vous familiariser avec une palette de couleur RGB je vous conseille un utilitaire de dessin comme paint.net, photoshop ou des extensions pratique comme la pipette sur Firefox (colorzilla) ou Chrome. Si on veut du marron on doit avoir une moitié de rouge, pas de vert ni de bleu. Ce qui donnerait RGB(127, 0, 0) Voila, maintenant que l’on comprend la couleur traduite en RGB il faut comprendre comment fonctionne une bande led. En faite pour afficher que du rouge c’est simple, on balance 12V dessus. Mais pour afficher une moitié de rouge ? Et bien nous allons mettre du 12v puis du 0v puis du 12v etc… Ceci se traduira par un signal dit « signal carré ». Pour obtenir un marron, il faut alterner du rouge et du noir. A haute fréquence, l’oeil ne pourra pas distinguer le rouge du noir, mais verra le marron. Si la fréquence est trop basse, 1Hz par exemple (1Hz = 1 période par seconde) donc 0.5s de noir et 0.5 rouge, ce sera perceptible par l’oeil. Mise en application dans l’esp : Pour réaliser ceci nous allons utiliser pwm (pulse width modulation ou modulation de longeur d’onde) qui est une fonction livré avec l’API NodeMCU. pwm.setup(redPin, 500, 512) : ici nous allons initialiser le pin ‘redPin’ (le 6 dans mon cas) à une sortie de type PWM avec une fréquence de 500 Hz et un duty de 512 (valeur entre 0 et 1023). Considérez le duty comme un pourcentage.  0 = 0% et 1023 = 100% il suffit de convertir le chiffre de tout à l’heure compris entre 0 et 255 en chiffre de 0 à 1023. Facile c’est un multiple de 4 ! Attention toutefois, ici 1023 correspond à lumière éteinte. Donc l’opération consiste à faire 1023 – 4 * r où r correspond au chiffre compris entre 0 et 255. Le reste du code (partie serveur) est expliqué dans mes précédents articles. Code partie smarphone : Comme je le disais précédemment, on peut très bien coder cette partie en app Web avec des appels ajax par exemple ou bien la coder sur Android ou iOS. Pour ma part je l’ai…

Retour d’expérience sur Angular JS + Web API 2 + Oauth2

    Démo live Listy : http://listy.reactor.fr Pour la petite histoire, on m’a demandé de faire un devis concernant une application web. Normalement on ne commence pas le travail tant qu’on a pas un acompte et surtout un cahier des charges bien ficelé. Surtout lorsque le client n’est au final plus trop sur de lui… qu’il doit réfléchir. Bref vous l’avez compris, j’ai travaillé à perte. Mais j’ai beaucoup gagné en compétence… En effet le sujet est simple : créer une liste d’envie sur internet. Il en existe déjà quelques une plus ou moins abouties. Le principe consiste à faire une liste de course avec des liens web et de sortir une liste au final à partager avec ses amis. Au premier abord, pas un énorme intérêt. Dans mon cas personnel j’adhère à l’idée pour noël, au lieu d’acheter des cadeaux pourris (chose que l’on fait quand même pour le fun), on se fait une liste d’objets utiles ou qui peuvent nous intéresser, chacun s’organisant comme il veut pour offrir le ou les cadeaux en question. J’avais besoin d’un projet comme celui ci pour enfin me former sur Angular. Entre temps j’ai fait une conf sur Angular 2 et bon… je tombe mal on va dire. Mais l’expérience en valait la peine. Ici je vais vous présenter ce que j’ai fait, les méthodes utilisées, les softs, plateformes… et surtout ce qui m’a posé problème en vous donnant les solutions. 1) Architecture :   Je voulais une architecture qui me permet de totalement découpler les services de l’application. Un peu d’historique : 1) Il y a quelques années, et ça se fait encore bien sur, on avait un site web (Asp.net WebForm) hébergé sur un IIS qui avait sa propre base de donnée. Du all in one. Très pratique. En effet pour accéder aux données on pouvait directement taper dans la BD pour afficher une donnée. Depuis les développeurs ont structuré leurs applications en ajoutant des couches, notamment la couche d’accès aux données (DAL) et une couche métier. Avantage : plus propre, réutilisable, maintenance plus simple, on peut changer de BD sans tout péter…Inconvénient, plus compliqué pour un débutant, plus de code donc un peu plus lourd à maintenir (oui c’est aussi écrit en avantage…) 2) On a vu ensuite apparaitre dans Visual Studio le modèle MVC. Depuis on ne parle que de lui. D’ailleurs j’ai cru lire quelque part que Microsoft allait laisser tomber WebForms dans ces prochaines versions de Visual Studio. J’ai personnellement mit du temps à m’y mettre. C’est une autre façon de concevoir son application qui a aussi ses avantages et inconvénients. Mais l’intérêt majeure face aux WebForms, c’est que l’on peut y faire des tests. J’en parlerai pas ici, c’est pas mon fort. La encore on avait tendance à accéder aux BD directement, soit en mode crado, soit via une couche. 3) Puis les sites webs ont proposé des fonctionnalités que l’on aurait bien vu dans nos mobiles, dans une application. Problème : comment accéder à nos données ? Sur le site web, on a quelques éléments de sécurité et fonctionnalités « intégrés » de façon native (la session, le système de fichier, droit utilisateurs, …) ce que j’appelle du all in one. Mais la le client, c’est à dire l’application mobile est totalement déconnecté de mon environnement de production. Qui plus est, sur un OS potentiellement différent et potentiellement dangereux, pas stable, hostile… pire entre les deux on a INTERNET le mal absolut si j’en crois mon ancien employeur Jaques Séguéla… Qui depuis à compris qu’il pouvait se faire du blé alors il a changé d’avis. Bref, comment faire ? Pour cela un web service était nécessaire. Jusque la j’avais travaillé avec SOAP. Mais bon SOAP c’est pas vraiment une archi, c’est plutot un protocole. Et puis SOAP c’est chiant. Depuis on ne parle plus (ou presque) que de REST. REST (Representational State Transfer) comme son nom ne l’indique pas est sans état (en fait dans le titre on parle d’état d’une ressource, et non de l’application). Ceci à des conséquences pour l’expérience utilisateur, surtout pour les « sessions » car en faite il n’y en a pas ! Vous pouvez laisser votre application dans un état et la retrouver dans le même état quelques temps après. En général, par exemple avec Asp.net WebForm, votre temps de sessions par défaut était de 20 min. Les développeur avait tendance à stocker pas mal de chose dedans. C’était très pratique mais on perdait tout ou presque à la fin de session (sauf bricolage ou stockage en BD). Ici pas de session. Cela va avoir un impact pour la sécurité de nos données (nous le verrons plus tard). Mais surtout, enfin pour moi, l’expérience utilisateur va en être affecté positivement : suivant le niveau de sécurité voulut, on peut maintenir un équivalent « session » sur plusieurs heure, voir jour. Comme sur Facebook ou l’on a pas besoin de se reconnecter toutes les heures. Un autre intérêt de REST c’est qu’au niveau maintenance et évolution des serveurs c’est plus simple à gérer. Mais le gros gros intérêt de REST, c’est qu’il vous permet de gérer n’importe quel type de client. Ici nous parlerons d’un client web Angular.js, mais rien ne vous empêche de créer une app Native Android ou un client Windows 10, le serveur n’aura besoin d’aucun update ! Il est prêt pour tout, ce qui change du tout au tout par rapport à un site php ou asp.net. (moins vrai avec la dernière version d’Asp.net qui combine MVC et API2) Coté client la encore, de la souplesse. J’utilise Angular principalement pour des raisons de formation, mais aussi pour éventuellement reprendre ce code et l’utiliser avec Ionic ! Ce formidable framework est basé sur Angular et propose de déployer son app, grâce à Cordova, sur plusieurs OS mobile comme iOS, Android ou Windows Phone. Donc vous l’aurez compris, utiliser ce genre d’architecture permet de voir loin ! 2) La construction Pour l’IDE, j’ai opté pour Visual Studio 2015, normal vu que je…

ESP8266 – troisième pas

Dans cet article, nous allons voir comment passer du mode AP (Access Point) utilisé dans l’article précédent, en mode station, c’est à dire en client simple, comme votre smartphone ou pc portable. Le ESP 12e dev kit est livré avec le firmware NodeMCU. NodeMCU est une plateforme Iot open source qui permet l’utilisation du langage de script Lua.Etant un peu débutant, je préfère que vous alliez vous même lire les définitions officielles de toutes ces notions. Lua va vous permettre d’écrire facilement du code pour faire fonctionner votre ESP. Il est basé sur le langage C. Pensez à gérer votre mémoire. Il faut savoir que l’ESP boot sur un fichier : init.lua. L’extension .lua signifie que le fichier n’est pas compilé. L’extension .lc indique que le fichier est compilé. LuaLoader vous permet de compiler les fichiers que vous souhaitez. Mais j’ai remarqué que beaucoup de code init.lua se charge de compiler le code au démarrage, puis efface tous les fichiers Lua. Cela permet de garder un peu de mémoire. Mon fichier init.lua fait ceci puis exectue main.lc (la version compilée de main.lua). Voici les fichiers sur le repo git : https://github.com/couscousbzh/ESP8266-Proto2 init.lua (ajouté) webserver.lua (inchangé) header.htm (inchangé) main.lua (modifié) Les modifications se trouvent dans le fichier main.lua. La premiere est simple, au lieu de charger webserver.lua je charge la version compilée webserver.lc (car je rappelle que les .lua seront effacés par le init.lua, lui meme compilé en .lc et effacé ensuite) La deuxième modification concerne le mode station/ap. Pour switcher il suffit de modifier la variable local modeStation = true/false. Il faudra aussi renseigner le SSID de votre box wifi et sa clé. Dans le proto 1, le mode était AP (Access Point), c’est à dire que votre ESP se comporte comme votre box wifi maison et va gérer son propre réseau (192.168.2.x). Il faudra alors changer de wifi et passer sur le wifi de l’ESP. Je préfère rester sur le même réseau wifi que celui de ma box, car je suis fainéant et je ne souhaite pas modifier mon wifi à chaque fois que je veux utiliser l’ESP. Donc je dois passer le mode en station. Le code prévoit 5 tentatives de connexion, cela peut prendre quelques secondes. Ensuite votre box wifi va attribuer une adresse IP à votre ESP (si la box est configurée avec un server DHCP, ce qui doit être le cas par défaut). Normalement vous pouvez lire l’IP s’afficher sur LuaLoader apres un reboot. Vous pouvez vous connecter dessus depuis votre browser préféré. A plus qu’à !

ESP8266 – deuxième pas

Dans le précédent article, je présentais un petit bout de code pour faire clignoter une led sur le board. Simple mais pas plus efficace que sur une arduino nano. Maintenant tâchons d’exploiter pleinement l’intérêt de cet appareil : le Wifi ! Jusque la il fallait pas mal bricoler pour obtenir un objet connecté, en général fallait rajouter un shield ou un modume ethernet ou wifi. Fini tout ca, avec l’ESP12 E Dev kit on a une puce ESP8266 pour le wifi sur un board équivalent à l’arduino nano en un peu plus gros. Nous allons voir ici comment créer un simple serveur web qui répondra à deux boutons web pour actionner deux leds sur le board. Nous allons avoir besoin d’un petit outil LuaLoader qui permet de gérer les scripts que l’on balance sur l’ESP. On va lui uploader 3 fichiers : main.lua (code principal) webserver.lua (code concernant le serveur web) header.htm (page web envoyé au client) Pour obtenir ces fichiers, voici le repo git : https://github.com/couscousbzh/ESP8266-Proto1 Petite explication : main.lua va charger le fichier webserver.lua. J’aurais pu tout mettre dans un seul fichier mais vous allez vite vous rendre compte qu’uploader un fichier prends du temps. Donc autant bien répartir son code. header.htm contient du code HTML CSS et JS. Il est incomplet volontairement. La fin du code est géré par webserver.lua pour rendre dynamique les boutons (état on et off). Il faut charger ces 3 fichiers sur l’ESP avec LuaLoader. Ensuite il faut faire un dofile sur main.lua. L’application va alors démarrer et votre serveur devrait être opérationnel. Connectez vous sur le réseau wifi (il s’appelle « DoitWifi » et le mot de passe est « 12345678 »). Ensuite charger une page web sur un browser avec l’url suivante : http://192.168.2.111. Si tout ce passe bien, vous obtenez une page web très simple avec deux boutons. Cliquez dessus et admirez le résultat sur l’ESP12e, les leds s’allument sur ordre des boutons web !