Reactor Blog

Des infos, des travaux, du partage...

NAVIGATION - SEARCH

Xamarin iOS retour d’expérience

Vous avez tous pu constater le buzz récent autour de Xamarin. J’étais à deux doigts d’acheter une licence iOS qui m’aurait couté dans les 700€. Un brave de chez Xamarin m’a conseillé d’attendre la build de Microsoft, ce que j’ai fait. Un grand merci à ce monsieur de chez Xamarin sans quoi j’aurai été bien bien vénère, il m’a fait économiser beaucoup…

Xamarin est donc gratuit ! Et c’est une excellente nouvelle. Car sans ça, les étudiants, les amateurs, les petit auto-entrepreneur comme moi voir même quelques TPE aurait bien eu du mal à se lancer sur cette techno.

Microsoft rachète donc Xamarin et l’offre dans toutes ses éditions Visual Studio 2015 (community, pro et entreprise). Par contre le reste des offres de Xamarin, à savoir les cours via l’university Xamarin et son centre de test restent payant. Je comprends que Xamarin doit trouver son modèle économique, mais maintenant que Microsoft est derrière, j’espère que les cours seront gratuit. D’autant plus qu’ils font des efforts fou pour que les développeurs codent pour Microsoft. Donc pourquoi faire payer des cours sur une technos qui permettrait d’universaliser nos apps, dont celle sur WUP. Bref, l’academy de Microsoft est gratuite, j’imagine qu’a terme on aura des cours Xamarin dessus aussi.

Autre bonne nouvelle, c’est l’arrivé depuis qq jours du simulateur iOS sur Windows. Oui oui, j’ai bien dit un simulateur iOS sur Windows. Il est inclu dans la version stable de Xamarin depuis début juin 2016. Je l’ai testé en version alpha puis stable depuis un mois. Et ca marche plutôt bien !

1) Situation

J’ai donc testé Xamarin iOS. J’ai une application (Trackus) que je développe depuis maintenant 2 ans sur divers plateformes (Windows Phone, Android, Web App, WUP), mais il me manquait iOS. Comment faire ?

- Choix 1 : natif (Objective C ou Swift). Je préfère en générale cette approche. Coder en natif permet d’apprendre pas mal de chose, d’avoir des ressources (docs, communauté, billet Stackoverflow…). Mais ici je n’avais même pas le matériel. Et chez Apple ça coute un bras. De plus il faut tout réapprendre. Je bosse sur Windows depuis toujours. Et le mac… je connais pas ou mal. Je galère pour faire des trucs tout simple. Mon temps d’apprentissage va devoir impacter en plus l’OS et les outils de l’OS. Ca fait beaucoup pour un noob.

- Choix 2 : Hybride (Cordova, Ionic). Pourquoi pas. J’ai passé un mois à me former sur AngularJS, Ionic aurait été un choix. Mais mon application nécessite de tourner en background, utilise des maps et le GPS… J’ai des doutes sur la fiabilité de tout cela en hybride. Peut être ai-je tort. Cela pourrait être un sujet prochain. Je n’ai pas vraiment étudier la question à fond.

- Choix 3 : Xamarin iOS. C’est mon choix. Plus par curiosité qu’autre chose. Je suis les divers évolutions de Xamarin et le ressenti des développeurs. Cette techno est prometteuse. Mais dans les faits ?

- Choix 4 : Xamarin Forms : autre solution, non étudié. Je voulais d’abord me rapprocher du natif et aborder éventuellement Xamarin Forms plus tard.

Pour info, mon application (http://trackus.reactor.fr) propose de géo-localiser un utilisateur A et de permettre à un utilisateur B de le suivre sur une carte. J’utilise pour cela un code alphanumérique sur 6 chiffres qui va identifier un parcours. L’utilisateur A envoi ce code à l’utilisateur B qui peut alors suivre sa trace. Ce code est modifiable ce qui permet de garder un certain anonymat. J’ai donc un serveur qui permet d’échanger ces informations (Web API2 + Entity-Framework). Voici les apps déjà en prod (bêta):

Je trouve le sujet intéressant car il aborde d’autre sujet que la classique “liste de tâches” ou le flux RSS qu’on affiche en liste. Ici on a du GPS (droits utilisateurs), du offline/online à gérer (perte de réseau pendant un déplacement, stockage des données, gestion http REST), une tâche en background (cycle de vie) et la manipulation de maps (iOS, Google, Bing). Bref ya du boulot mine de rien.

2) à fond les ballons

On y va on code. Ha oui, mais attends, d’abord le matériel… Peux importe ce que vous faites, si vous créez une app pour iOS il vous faudra un mac. Si vous êtes un peu short, il existe des solutions comme MacInTheCloud qui vous permet de louer un mac sur internet. Mais vous ne pourrez faire que du simulateur car impossible de brancher un device physique sur la machine. Sinon vous achetez un mac. Un mac mini fera l’affaire. J’ai acheté le mien sur le bon coin. Une pure affaire. Ca part comme des petits pains, donc sauter sur l’occasion.

Vous avez donc un poste Windows, un poste Mac, branché sur le même réseau. C’est parti. Faut tout installer. Yen a pour un moment si comme moi vous tourner max à 2 Mbps (oui ca existe encore !). Il faut installer Xamarin sur le mac et installer Visual Studio 2015 update 2 + le kit simulateur. Tout est dis sur le site de Xamarin :

https://developer.xamarin.com/guides/ios/getting_started/installation/

https://developer.xamarin.com/guides/cross-platform/windows/ios-simulator/

Quand tout est installé il faudra créer un projet iOS et tester la connexion avec le Mac (agent de build)

Il faut que votre icone soit verte. Sans ça pas de connexion avec le mac, donc pas de build ni de simulateur.

Dans l’ensemble le setup se fait pas trop mal. Xamarin améliore grandement la simplicité car avant il fallait gérer l’agent de build à la main (voir précédent post sur le sujet).

3) Les mains dans le cambouis

J’ai travaillé essentiellement sur Visual Studio avec le simulateur. Ce dernier propose pas mal de petites options intéressantes. Il y a même un simulateur de déplacement (à pied, en vélo et en voiture) ce qui permet de tester le GPS. Idéale dans mon cas. Il manque cependant un bouton pour couper le réseau ou un “dégradateur de réception 3G/4G” histoire de tester le mode offline. A part cela, c’est une petite merveille ce simulateur !

Je suis novice pour les applications iOS. J’ai du lire un peu de doc. Et celle de Xamarin est plutôt bien faite. J’ai parfois été bloqué mais l’essentiel est la. Bien présenté. Par contre la doc officiel de Apple… comment dire cela poliment… je déteste.

Il faut connaitre le cycle de vie d’une application sur iOS (comme sur Android ou WP). C’est essentiel. Pour le reste on code avec C#. Donc que du bonheur. Rien à redire la dessus. Reste l’interface graphique. Et la c’est pas top top…

Visual Studio possède un designer. Similaire à XCode, on a un storyboard sur lequel on place des vues que l’on relie à des ViewControlers. De la on a notre liaison avec le code.

Pour ma part j’ai avancé relativement rapidement au début. Mais quand il a fallut rendre l’application joli et “adaptative” j’entends compatible iPhone 4 5 6 +, c’est devenu franchement casse burne.

Le designer sous Visual Studio permet de facilement ajouter des éléments mais il est affreux pour les positionner. A priori il existe deux façons de faire pour positionner les éléments sur l’UI. L’ancienne méthode et la nouvelle qui implique les “contraints”. Cette dernière est une abomination intellectuelle. Quant à la première elle fonctionne mal sur Visual Studio.

J’en suis arrivé à un point ou j’ai carrément ouvert ma solution depuis Xamarin sur le Mac. Et en effet il y a moins de soucis de ce coté la. Mais du coup je perds l’intérêt de mon billet ! Moi je veux bosser sur Windows ! Franchement, ça serait à refaire, je coderai sur Xamarin sur le Mac. Problème, il n’existe pas de moyen de bosser avec Visual Studio Online (Team Services)…

Le designer d’interface utilisateur iOS sur Visual Studio n’est pas au point. Il est buggé et parfois me fou un merdier pas possible.

J’ai été très rapide sur le code, grâce à la puissance du C# et au simulateur super pratique. Par contre j’ai perdu un temps fou (70% facile) à essayer de rendre mon application joli et adaptative. Ni sur Android, ni sur Windows Phone je n’avais perdu autant de temps. Elle reste donc pas super joli et pas adaptative comme je le voudrais.

4) Debug

On a un retour des bugs via l’agent de build. Mais parfois c’est pas clair. J’ai eu un cas ou mon application plantait sans aucun message. J’avais bien mes break point, mais ca passait pas dans le catch de mon try/catch.

J’en ai profité pour ajouté hockeyapp. Un utilitaire fort pratique qui permet de faire du Crash Report. Il va même plus loin car il s’intègre dans la chaine du continious delivery et peut être plugé à Team Services (Visual Studio Online). On a donc des metrics users, des feedbacks et des rapports de bugs.

Le seul souci c’est que la dll fait 34 Mo !!! Mais il arrivait à me remonter des stacktraces que je ne voyais pas sur mon IDE.

L’idée ici est de monitorer notre application une fois qu’elle sera dans la nature (sur le store) et pouvoir continuer à debugger, améliorer notre app.

5) Mise en prod

J’ai suivis ce guide :

https://developer.xamarin.com/guides/ios/deployment,_testing,_and_metrics/app_distribution/app-store-distribution/publishing_to_the_app_store/#Setting_the_Build_Configuration_for_your_Application

Après une dizaine de tentatives, je suis arrivé à cet écran libératoire :

Ca n’a pas été simple. Je n’avais jamais vraiment bien compris la gestion des certificats, des provisionnings profile etc il y a quelques années déjà, pour une autre appli. Je remarque que c’est toujours pas simple de ce côté la non plus en 2016. Coté Android et Windows, c’est nettement plus simple.

6) Conclusion :

Dans l’ensemble je suis satisfait. Les devices de chez Apple sont, je dois le dire, d’une grande fiabilité. Mon code à marché du premier coup, sans trop de pépins ! Sur Android et WindowsPhone j’ai du réaliser de nombreux tests grandeur nature qui se sont soldés par pas mal d’échecs. Mes premiers tests avec l’iPhone sur une grande distance, pendant 3h ont été un succès. Bon je m’emballe pas non plus… on verra avec le temps et le retour utilisateur.

Xamarin iOS est un pure outil pour les codeurs C#. Cependant le designer de l’interface graphique n’est pas au point. Et quand on sait à quel niveau il faut mettre la barre aujourd’hui pour le design d’une application, on est un peu déçu. Je pense qu’avec le temps que ça viendra.

Mon app est en cours de validation, je reviendrai certainement mettre à jour cet article.

7) Bonus vidéo

Mon premier screencast, soyez indulgent.

Yann Vasseur

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 :

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 :

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 :

  • 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 réalisé sur Windows Phone en C# en quelques minutes. J'ai d'abord utilisé un composant le radial color picker https://code.msdn.microsoft.com/windowsapps/Colorpicker-for-Windows-dd6095f8, mais j'ai un bug lorsque je sélectionne une couleur dans les tons rouge. J'ai donc préféré celui ci qui fonctionne à merveille : le ColorPicker par Tareq Ateik http://tareqateik.com/colorpicker-control-for-universal-apps/

Ensuite il suffit de récupérer la couleur donnée par le control XAML puis de l'envoyer avec une simple requête http get sur l'IP correspondant à votre ESP (affiché dans LuaLoader lorsque votre serveur démarre)

Conclusion :

C’est assez rigolo de jouer avec l’ESP et le wifi. La contrainte majeur que je rencontre en testant des objets connectés c’est justement la connexion. On aurait pu aussi utiliser le bluetooth pour la commande. Ici on va plus loin en créant carrément un mini serveur autonome, accessible sur votre réseau local.

Par contre j’ai vraiment du mal à avoir du code stable. Un coup ca marche super bien, un coup j’ai des problème de boot. Mon code ne démarre pas et je n’ai pas de message d’erreur. Le même code va qq minute plus tard bien fonctionner… J’ai remarqué qu’en déconnectant le V+ (fil blanc), reboot, attente que le serveur démarre, et rebrancher le fil blanc permet de booter correctement.

N’hésité pas à partager vos expériences en laissant un petit commentaire !

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

Démo live Listy : http://listy.reactor.frPour la petite histoire, on m'a demandé de faire un devis c




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 fais la partie serveur en Asp.net - Web Api 2.

Mais pour la partie cliente, Angular.

Question serveurs j'ai une version Express de SQL Server pour la base de données. La encore on peut changer mais je vais rester assez classique pour la gestion des données. J'utiliserai le Framework Entities code first. Evidement je vais prendre IIS pour mon serveur web en prod, et celui fournit avec VS2015 pour mon dev.

Lors de mon apprentissage, j'ai effectué 5 versions de mon client et 4 versions de mon serveur. Les deux évoluant tour à tour. Voici le code source sur Git : https://github.com/couscousbzh/Toyalist1

Pour l'association version client/version serveur, suivre ce fichier : https://github.com/couscousbzh/Toyalist1/blob/master/Versions.txt

Phase 1 : (AngularToyalistV1) jouer avec Angular seul, sans API. Une vue. Comprendre les routes, les controleurs, services bref les éléments de base.

Phase 2 : (AngularToyalistV2 + ToyalistAPIV1) on ajoute une API qui nous fournit des listes de gifts statique (pas de sauvegarde DB). Ajout d'une vue edit.

Phase 3  : (AngularToyalistV3 + ToyalistAPIV2) Coté API on a ajouté le service de crawl (parcour d'une page web et extraction des éléments pertinents) Coté client les vues sont plus abouties, avec des boutons de test.

Phase 4 : (AngularToyalistV4 + ToyalistAPIV3) Ajout de la sécurité (bearer token) Owin + Asp.net Identity + Oauth2.0

Phase 5 : (AngularToyalistV5 + ToyalistAPIV4) Modification de la gestion de la sécurité (JWT Token) Owin + Asp.net Identity + Oauth2.0

Phase 6 : Listy bêta.

J'ai principalement suivis quelques excellents tutoriels de Taiseer Joudeh dont voici deux liens :

En faite je me suis aperçus que le premier tuto était un peu vieux, du coup j'ai bifurqué vers l'article le plus récent ce qui peut expliquer certain choix dans mon code (V4->5). Ces articles sont une mine d'or, c'est simple, ce sont les meilleurs tutos que j'ai expérimenté jusque la. C'est bien écrit (en anglais), c'est illustré et bien accompagné. Reco ++

Notez que pendant l'apprentissage, le nom du projet s'appelle 'Toyalist'. La version actuelle s'appelle Listy.


Info : je viens d'apprendre que le site officiel Toyalist va ouvrir, donc on m'a clairement raconté des cracks et qu'il a été développé ailleurs, ce qui ne me pose aucun problème sauf que ça a été géré par une ancienne camarade qui n'a pas eu le courage d'être transparante... Déséspérant... Du coup, Listy va passer en open source !





ESP8266 - troisième pas

Partie 1 : http://blog.reactor.fr/post/2015/12/20/esp8266-premier-pasPartie 2 : http://blog.reactor.


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 b


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 !









ESP8266 - premier pas

J'ai acheté cette petite bête après la lecture d'un article sur le magazine Programmez d'un certain


J'ai récemment acheté une nouvelle petite bestiole : un Nodemcu lua esp8266 ESP -12e



Mais c'est quoi ce truc ?

L'ESP8266 est un module Wifi qui se branche d'habitude sur un microcontroleur, mais ici il est livré directement avec ! Ya en plus une prise USB donc pas besoin de bricoler une liaison série tout est sur la carte. J'ai acheté en plus un support, le tout pour 10$ sur Banggood.

Après mon NetDuino et mon Arduino-Nano, j'avais besoin d'une carte relativement petite avec le Wifi et surtout pas cher. Car tout ce que j'ai besoin c'est un d'un "commutateur à distance". J'ai bien les ondes radio comme option mais il m'aurait de toute façon fallut une carte pour le piloter et faire la liaison avec internet. Ici on a tout en un !

Pour l'utiliser, il suffit d'avoir node.js sur son PC. Vous installez un package qui vous permettra de lancer quelques lignes de commande pour copier des fichiers dessus. Ces fichiers contiendront votre code qui sera exécuté car l'ESP8266.

Pour démarrer, le plus simple et de faire clignoter une led sur la carte. Dans un fichier blink.lua copier le code suivant :

-- Config
local pin = 4           
local value = gpio.LOW
local duration = 1000    --> 1 second

-- Initialise the pin
gpio.mode(pin, gpio.OUTPUT)
gpio.write(pin, value)

-- Create an interval
tmr.alarm(0, duration, 1, function ()
    if value == gpio.LOW then
        value = gpio.HIGH
    else
        value = gpio.LOW
    end

    gpio.write(pin, value)
end)

Ouvrez une invite de commande et copier ce fichier sur la mémoire du ESP8266 :

>esp file write blink.lua

Pour ensuite l'executer :

>esp file execute blink.lua

Ca y est la LED clignote !

Bien évidement ça ne va pas s'arrêter la. Le but étant de piloter quelque chose à distance via internet ou son réseau locale.

J'ai plusieurs idées en tête :
  • allumer une bande led derrière la télé depuis mon smartphone dans le canapé
  • allumer automatiquement  les lampes extérieures (déjà installées et reliées à des relais Chacon 433MHz) en fonction de sa position GPS (quand on rentre du boulot par exemple)
  • fermer une trappe à chien pendant 30 min sur l'appui d'un bouton de mon téléphone, histoire que mon chien sèche avant de le rentrer pour qu'il passe la soirée avec nous.
Bref on peut vraiment penser à des trucs bien délire !

Compilation - Deploiement - Debug avec Cordova sous Windows et Mac et avec ou sans VS2015

Je m'améliore pas en titre... J'ai mené pas mal d'essai sur Windows et Mac et je vais essayer ici de

(Je m'améliore pas en titre...)

J'ai mené pas mal d'essai sur Windows et Mac et je vais essayer ici de synthétiser mes résultats. J'ai pris le code openFB et j'ai suivis leur recette de cuisine pour l'installer proprement, sur le mac.

Sur le Mac OSx (Yosemite)

Appareil Android (Wiko Ridge 4G) et iPad2 branché en USB sur le mac.

  • $ cordova run android --> compile puis lance un run sur mon device android.
  • $ cordova run ios --> compile puis lance un emulateur.


--> Si quelqu'un sait comment on lance son app sur un device iOS branché en usb, je suis prenneur !

l'application s'ouvre dans un emulateur iPad2 et fonctionne normalement.


Sur Windows 10 :

J'ai copier coller le code du Mac sur Windows.

Appareil Android (Wiko Ridge 4G) et iPad2 branché en USB sur Windows.

  • $ cordova run android --> compile puis lance un run sur mon device android.
  • $ cordova run ios --> ne fonctionne pas, on est sur Windows, il faudrait utiliser le remote build

Avec Visual Studio 2015 :

  • run android appareil--> compile puis lance un run sur mon device android.
  • run ios appareil --> compile (remote build) puis install via iTunes l'ipa. qu'il faut ensuite installer manuellement sur l'iPad.


Pour info :l'application s'ouvre sur iPad. J'ai des problèmes d'affichage (bouton sous la barre du haut) et je n'arrive toujours pas a faire fonctionner OpenFB sur iPad en deployant de cette manière. En cliquant sur Login, une page blanche s'ouvre. Je soupçonne InAppBrowser de ne pas bien fonctionner.

  • run ios simulateur iPad2--> compile (remote build) puis lance un emulateur iPad2 sur le mac

idem, même problème que précédement (au moins le simulteur est fidèle)

  • run ios rippleiPad2--> ne compile pas  puis lance un chrome, l'affichage est correct, mais le clic sur login m'affiche ceci :


A priori, InAppBrowser a du mal avec Ripple aussi. Et c'est valable avec Android aussi (mais vu qu'il ne compile pas, on a une version web dans Ripple)


Et pour le debug ? :

D'une manière générale avec Cordova, il est plus simple de travailler en mode web et d'utilser un F12 sur son navigateur pour accéder à la console Javascript et pouvoir debuger son app.

Si l'on souhaite travailler sur une version compiler, Android est un plaisir, il fonctionne de la même manière sous Windows et sur Mac. De plus avec Visual Studio 2015, il est possible de debuger grâce à la console javascript. Bref ça marche !

Pour iOS c'est une autre pair de manche. On peut travailler avec Visual Studio 2015 sur un emulateur qui se trouve sur mac, à distance. Ce qui n'est pas rien. Par contre concernant le debug, je ne sais pas si c'est possible. J'ai une erreur de la part du serveur de build sur mac : Spawn ios_webkit_debug_proxy ENOENT que je n'est pas encore résolut.


Donc je reste avec mon pb de login sur iOS sous le bras, car je n'ai aucun moyen de debuger correctement.

J'ai appris que Ionic (basé sur Cordova) créer des projets xCode. Du coup il y aurait une piste pour pouvoir debuger depuis xCode des projets iOS. A suivre.


Conclusion :

En l'état, coder depuis Windows pour du multiplatforme de type Cordova n'est toujours pas intuitif. On doit installer tout un tas de truc avant de pouvoir voir du concret sur iOS et pour le cas d'OpenFb il est en plus difficile de debugger.

Travailler sur Android, que ce soit sur Mac ou Windows ça marche ! Donc de mon point de vu, autant rester sur Windows et profiter de Visual Studio 2015.

Pour iOS c'est vraiment compliqué. On peut compiler à distance avec un remote build. On arrive à faire des choses. Pour moi le debug ne fonctionne pas (sans doute un mauvais paramétrage). Le test OpenFB à montrer qu'en execution on avait un soucis lorsque l'on compilait/exécutait à distance, mais la compilation/exécution locale elle fonctionne.


J'ai encore du boulot...









VS2015 et le remote Build sur Mac OSX (Xamarin et Apache Cordova)

VS2015 nous promet de pouvoir créer du code pour une application iOS sur Windows. Je précise ici que
VS2015 nous promet de pouvoir créer du code pour une application iOS sur Windows. Je précise ici que je ne coderais pas une ligne, je souhaite simplement configurer mon environnement de dev pour compiler sur iOS et déployer sur mon iPad2 une app "Helloworld".

Pour cela trois moyens :
  • Xamarin
  • Apache Cordova
  • Natif
Ce qui n'est pas crié sur les toits, c'est qu'il faut absolument une machine Apple sous MacOSx (version Yosemite recommandé) pour pouvoir compiler du code iOS. (Apple l'exige !). Du coup vous avez deux choix : soit vous avez un mac et c'est tant mieux pour vous, soit vous pouvez utiliser macinthecloud. J'ai commencé avec macinthecloud, ça coute pas cher, mais j'ai préféré aller acheter une machine Mac, même si ça coute un bras.

Avant de démarrer, il faut préparer votre Mac comme si vous allez créer une application normal avec XCode. Donc il faut
installer XCode avant. Il faut aussi un compte AppleId + un compte développeur (99$ par an). Ensuite avec XCode il faut créer un certificat développeur. Puis créer une application avec Xcode (ca permettra de générer un provisionning profile automatiquement). Pour l'iPad (ou votre iPhone), il faut aussi l'enregistrer..bref c'est trop long à détailler ici et cette page le fait très bien : http://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/

Commençons par le moyen le plus simple Xamarin :

Xamarin :

Xamarin permet de coder sur VS2015 (ou sur l'IDE de Xamarin) une application en utilisant que du C#.

Pour cela il faut installer Xamarin sur votre Windows ET sur votre Mac. Il faut aussi un compte Xamarin et démarrer un Trial ce qui vous permet d'accéder à toutes les fonctionnalités (et d'éviter des problèmes de licences...)

L'idée ici c'est de démarrer rapidement avec un projet de base que l'on nous propose dans iOS : (blank, MasterDetails...)


Prenons Master Detail app, c'est juste histoire d'avoir un truc à montrer à l'écran. On ne touchera pas au code.

Normalement sur votre interface vous allez avoir des petits boutons comme ceci :



Ici on est pas connecté au serveur de build qui se trouve sur le mac. Il faut l'associé (pair). Ici le guide officiel.

Vous allez d'abord lancer sur votre Mac Xamarin.iOS Build Host. Il vous propose un code. Notez le.
Dans Visual Studio sur Windows ouvrez les options dans le menu 'outils', puis descendez sur Xamarin puis iOS Settings



Cliquer sur le bouton "Find Mac Build Host". Connectez vous avec l'adresse IP de votre Mac et rentrer le code de pair.

Normalement ici vous êtes connecté au serveur de build iOS. Et vous voyez la petite icône verte !



Remarquez aussi que j'ai accès à mon iPad de Yann (relié en USB sur le Mac). Pour disposer de cela il faut au préalable faire tout un tas de truc pas cool avec des certificats, des provisionning truc bidule (vive Android pour ça).

Si je lance un run sur VS2015 (Windows) ça balance mon app direct sur mon iPad (USB sur Mac). Et je suis sur Windows !  Yeahhhh ! Trop trop bon !


Apache Cordova :

Pour Apache Cordova on va devoir écrire quelques lignes de commandes dans la console.

Mais d'abord il faut installer node.js (http://nodejs.org/) sur votre Mac.

Une fois que c'est fait, il faut suivre ce doc : https://msdn.microsoft.com/library/mt147405%28v=vs.140%29.aspx#ConfigureVS

Lancer sur la console la commande :

sudo npm install -g npm@2.6.0
Cela va installer npm qui est gestionnaire de package. Celui ci va vous permettre d'installer plein de truc super qui tourne avec Node.Js. Taper ensuite la commande qui va installer vcremote :

npm install -g vcremote
Ensuite vous aller lancer un serveur qui va faire tourner vcremote. Par défaut il vous propose un échange sécurisé avec un 'pin'. (comme avec Xamarin mais en ligne de commande). Personnellement j'ai désactivé la sécurité. Pour cela taper la commande

vcremote --secure false
Voici ce que vous affiche la console :



Super, le serveur est prêt, il nous attends. Pour info, si vous voulez arrêter le serveur, taper CTRL-C.

On retourne sur Windows, Visual Studio, outils, options, Multiplateforme, C++, iOS :



Il faut paramétrer le serveur. Nous avons choisi pas de sécurité donc la case n'est pas coché. Par défaut le port est 3030. Taper l'IP de votre machine Mac. Puis le bouton Coupler. Normalement votre serveur réagit et affiche ceci :


Et votre connexions est réussi sur Visual Studio.

Seulement lorsque vous tenter de builder votre application Apache Cordova depuis VS2015, vous avez une erreur. Il vous demande de configurer qq chose. Pour cela allez (sur Windows) dans Visual Studio, outils, options, Outils pour Apache Cordova, Configuration de l'agent distant.

Si vous renseignez les même informations, le serveur vous répondra : "GET /modules/taco-remote 404"



Alors la j'ai passé un bon moment avant de comprendre qu'en fait, l'agent de build for Apache Cordova n'est pas vcremote mais remotebuild !

Il faut se rendre sur ce site https://www.npmjs.com/package/remotebuild et installer remotebuild

sudo npm install -g remotebuild

et relancer un serveur remotebuild cette fois (j'ai gardé la sécurité cette fois). Les commandes ne sont pas les mêmes mais se ressemble beaucoup.

Sur Visual Studio paramétrer maintenant votre nouveau serveur (attention le port est 3000 par défaut)



Tenter maintenant une compilation sous iOS :



Vous verrez alors votre serveur s'agiter :



C'est bon signe votre app compile ! Ça prend aussi un certain temps..

Maintenant vous pouvez lancer un run sur votre appareil local, mais attention, ce coup ci, branchez votre iphone/ipad sur le connecteur USB de votre Windows.

Il vous faudra avoir installer iTunes avant et un panneau vous avertira si vous voulez remplacer l'application existante (pas la première fois bien sûr). Remplacer la pour la mettre à jour. Sur votre iTunes vous aurez l'application qui s'affiche dans le menu Apps :



Cliquez ensuite sur le bouton Installer puis sur le bouton appliquer. L'application se transfert depuis iTunes vers l'iPad2. Vous n'avez plus qu'à l'ouvrir.

Conclusion :

La tâche n'est pas évidente. Compiler depuis Windows sur un Mac n'est pas si simple.

De plus j'ai du mal à piger à quoi sert vcremote, j'ai pas osé le désinstaller pour voir si remotebuild est autonome. Donc vous pouvez tenter de votre coté (et me dire svp) si vcremote est bien nécessaire. Je n'ai pas voulu changer mon article car vcremote possède à peu prêt les mêmes commande que remotebuild. Et puis VS2015 s'est bien connecté donc c'est qu'il doit servir à compiler un type de projet "Multiplateforme"...Mais c'est quoi un projet multiplateforme si c'est pas du Xamarin ou du Apache Cordova ?

Mais bon l'essentiel est la, on peut coder sur Windows, avec Visual Studio une application iPhone/iPad !!!

Bon code !

UPDATE : Xamarin V4.0


A priori, la connexion à distance se fait maintenant par le login en session sur mac et il gère tout seul le mac agent.

My setup - Facebook Api using OpenFb on an Apache Cordova App

Facebook a évolué. So do I. Je vais présenter ici le résultat de mon expérience, un best practice à


Pourquoi j'écris mon titre en anglais moi... à force de jongler entre les langues je fais du français/anglais dans mon code et maintenant dans mes articles...


Pour cet article je vais essayer de détailler les étapes d'une construction d'application utilisant apache codorva autour de l'API Facebook.

Mon approche n'est peut être pas la meilleur, vous en faites ce que vous voulez, mais pour moi il est intéressant (important ?) de revoir toute l'approche et les étapes, car honnêtement on s'y perd.

Tout d'abord, je reste en "mode dev" pour cet article, c'est à dire que mon app n'ira pas en prod (sur les stores). Par contre je vais utiliser deux applications facebook, une en dev et l'autre pour la prod. (il faudra ici distinguer votre app (iOS/Android) et l'application facebook qui aura "deux modes" (prod et dev).

Avant de commencer, il est bon d'avoir deux comptes Facebook. Un compte de développeur et un autre de test (votre perso par exemple). Pour ma part j'utilise deux navigateurs différents (chrome pour le dev, Firefox pour le test). Ainsi j'ai pas besoin de me reconnecter et mes sessions sont bien distinctes.

Étape 1 : Création de l'application Facebook

Rendez vous sur https://developers.facebook.com, avec votre compte dev. Loguez vous

Sur l'onglet My Apps, cliquez sur "Add a new App", séléctionnez site web WWW, choisissez un nom, ensuite une catégorie et "create App ID". Moi j'ai choisi WebSite-Prod pour ma démo.

Ensuite je ré-itère l'opération avec une application de dev, pour cela il faut lui donner un nom comme WebSite-Dev et actionner oui pour le toggle "is this a test version of another app ?" , puis sélectionnez votre app prod (pour moi WebSite-Prod)


A ce stade nous avons deux applications Facebook, en réalité nous avons qu'une seule application Facebook qui possède une version de test.


Étape 2 : Paramétrage de l'application dev

Sélectionnez votre application dans l'onglet MyApp (pour moi WebSite-Dev). Vous êtes sur le Dashboard. Notez que votre AppID se trouve ici. Vous en aurez besoin plus tard.
Cliquez sur le menu Settings. Ajoutez une plateforme avec "Add Platform" et sélectionnez WebSite.

Ici j'ai rempli au début par http://localhost:8888/. Il s'avère qu'en test-dev pour l'instant ce champ n'est pas vraiment primordiale. Mais je laisse au cas ou je me tromperais sur ce point.

Voici ce que vous obtenez :


Cliquez maintenant sur "Advanced", dans la section "Client oAuth Settings", il faut renseigner le champ "Valid Oauth redirect URIs" avec ces deux entrées :

- https://www.facebook.com/connect/login_success.html
- http://localhost:8888/cordovaopenfb/www/oauthcallback.html


N'oubliez pas d'enregistrer la page après chaque changement.

Dans le menu, sélectionnez "Roles". Dans "Testers" ajouter votre second compte de test :


Si vous ne le faites pas, vous risquez de vous retrouvez avec des messages d'erreur de ce type :

"Application non configurée: Cette application est toujours en mode de développement. Utiliser un compte test enregistré ou demander à un administrateur de l’application de vous ajoutez les autorisations afin d’accéder à l’application."



Étape 3 : Paramétrage de l'application prod :

Dans un premier temps, nous allons paramétrer exactement de la même manière la version prod de notre application. En théorie nous ne devrions pas avoir besoin d'un testeur, mais Facebook impose que l'on fasse au moins une requête (login) de test durant les 30 derniers jours pour valider une review. Donc laissons le pour l'instant.

Normalement l'application est ouverte à tous amis par défaut elle ne l'est pas et n'est pas visible au publique. Pour y remédier,  il faut passer l'application en "prod réelle". Il faut vous rendre dans le menu "Status & Review" et cliquez sur Yes pour "Do you want to make this app and all its live features available to the general public"


Si tout va bien il y a un petit point vert qui indique que votre app est en ligne.

A ce stade vous pouvez déjà jouer avec votre app. Tout est prêt côté dev facebook. Vous allez pouvoir exploiter à fond toutes les possibilités de votre application Cordova.

Côté prod, tout n'est pas permit, mais on peut déjà faire quelques essais. Le login va fonctionner, vous allez pouvoir récupérer quelques infos permises par le scope de base :


Seulement vous n'allez pas avoir la possibilité de publier sur le mur par exemple (scope : publish_actions), sauf si vous êtes encore testeur, donc pensez a vous enlever quand vous aurez fait votre premier essai de login pour vous mettre en condition réelle, comme un user lambda.

Pour avoir les droits de publications il faut passer par une "Review" Facebook, une soumission à la validation de Facebook sur votre application... Facebook va donc tester votre application. Pour cela il vous faudra renseigner tout un tas d'information permettant aux testeurs de facebook de tester votre application.

Note :  Mais quelle application ? Mon app n'est même pas sur un store me direz vous... En théorie Facebook devrait pouvoir tester un site web, ce qui est beaucoup plus simple à mettre en place, même en dev. Mais pour Cordova c'est un lien localhost ! Faut il faire un site web en plus ?

Pour l'instant j'ai demandé une validation à l'aveugle, c'est à dire que j'ai fourni quelques screenshots, un semblant de descriptif et une sorte de manuel pour tester... Je rappelle que mon app est justement faite pour tester Facebook...Je te test, tu me testes... je sais pas comment ils vont le prendre...

--> réponse : Facebook a rejeté mon app.

Voici les éléments à remplir sur votre application Facebook prod avant de demander une Review :

  • menu settings : Contact Email
  • menu App Details :Short description & long description
  • menu App Details : Privacy Policy URL (exemple : http://reactor.fr/privacystatement/facebook/website.html )
  • menu App Details : App icon (en 1024px par 1024px, fond transparent de préférence si il est blanc)
  • + un test de login avec un compte de test sur votre application.

Normalement on est bon la...


Étape 4 : faire un essai sur une application mobile

J'ai testé sous android avec mon Wiko Ridge 4G. Voici mon code (fait sous Visual Studio 2015) :

https://github.com/couscousbzh/CordovaOpenFb

Pensez à remplacer les AppId par les votres (dev puis prod). Cette application vous permet de jouer avec les login/logout, d'afficher vos permissions et de les révoquer (pratique pour recommencer des tests). L'appli est un copier coller d'OpenFb qui vous trouverez ici : https://github.com/ccoenraets/OpenFB

J'ai rajouté quelques fonctionnalités supplémentaires :

  • L'access token est sauvegardé non plus dans la session (par défaut avec openFb) mais dans le localStorage, ce qui permet de pouvoir rouvrir l'app sans se re-loguer
  • Détection au démarrage pour savoir si le user est authentifié ou pas
  • Bouton post image sur mon mur (simple post avec une image sur le net)
  • Bouton post image sur mon mur (image issue d'un canvas qui possède une image stocké dans l'application, pour simuler une photo de la camera)
  • Bouton post image sur une page business


Bon code !