Nous venons de voir au chapitre précédent comment organiser une navigation complexe et imbriquée pour une application avec une architecture grandissante.
Nous allons voir aujourd’hui comment stocker des données plutôt simple, par exemple des paramètres de l’application comme l’activation ou non d’un thème clair ou sombre.
On ne peut utiliser n’importe quel outils pour persister des données car nous sommes sur un projet Expo, nous empêchant d’accéder aux modules natifs de iOS et Android. AsyncStorage est un moyen fonctionnant avec des projets Expo.
AsyncStorage nous permet de persister des données en local sur le smartphone, de façon asynchrone et non crypté. Les informations sont sauvegardé en clair, donc éviter de stocker des données sensibles tel que des mots de passes.
Le stockage s’effectue sous forme de couple tel quel : <Clé, Valeur>.
On ne peut stocker que des string, donc pour des éléments plus complexe tel que des objets, on devra utiliser JSON.stringify() pour la conversion en JSON lors de la sauvegarde d’une donnée, et utiliser JSON.parse() pour lire un objet.
Sauvegarder des données
Pour un string
Pour un objet
Lire des données
Pour un string
Pour un objet
En pratique
On va faire un exemple tout bête, à savoir charger le nom d’un utilisateur à l’appui d’un bouton.
Méthode d’écriture & lecture de donnée
On commence par définir nos deux méthodes pour charger et sauvegarder une donnée :
On appellera la méthode initProfileName() dans l’entrée de notre l’application (App.tsx) pour initialiser notre donnée.
Mise à jour de notre vue
On crée un état initialisé à ‘Invité’. On aura une méthode appelant notre fonction pour lire notre donnée via AsyncStorage, définit précédemment. Et enfin une méthode render() pour afficher un champ de texte, et un bouton bindé avec la fonction de chargement de notre donnée locale :
Conclusion
On vient de voir comment stocker des informations simple en local. Nous allons voir au prochain chapitre comment stocker des informations plus complexe et surtout en quantités plus importantes.
Nous venons de voir dans le chapitre précèdent comment faire une barre de navigation principal. Mais comment faire si nous souhaitons naviguer dans de nouveaux composant à travers nos vues actuelle ?
Pour réaliser une navigation imbriqué de vue dans d’autres vues, nous allons ajouter un nouvel élément, une StackNavigation.
Pour faire de la navigation imbriquée, il va nous falloir dans une première partie créer un nouveau composant, une nouvelle page. Faisons une nouvelle page Profil, qui affiche mon prénom, par exemple :
Mise a jour des ROUTES
On va ajouter une nouvelle route dans notre constante globale des routes, amenant à notre nouvelle vue précédemment crée :
Création de la stack navigator
On va créer notre composant qui va gérer la navigation par pile. On doit lui définir nos deux composants (nos deux vues), leurs routes respectifs pour y accéder, et la route initiale lorsque le composant est crée :
Mise a jour de notre tab navigator
On va désormais fournir à notre navigation par tab, non plus mon composant WelcomePage comme initial, mais directement notre stackNavigator, crée précédemment :
Appel du changement de route par un bouton
On met à jour notre composant WelcomePage, via la méthode onPress, qui est appelé lors d’un clique sur notre item, permettant d’appeler le changement de vue en lui donnant la route que l’on souhaite. Je vous montre comment faire cet appel selon le type de composant que vous utilisez au sein de votre application :
Navigation via composant fonctionnel
Navigation via composant de classe
Conclusion
Nous venons de voir comment naviguer à l’infinie entre nos vues. Dans le prochain chapitre, nous nous attarderons à comment sauvegarder, à la fermeture de notre application, des données simples, comme des paramètres de l’application.
On va vu dans le chapitre 1 comment afficher un HelloWorld!, puis dans le chapitre 2 comment générer nos installeurs. Maintenant que l’on est capable d’utiliser notre application du code à notre smartphone, on va commencer le développement.
Objectif
Initialiser une petite architecture
Créer plusieurs écrans en affichant un titre différent
Créer une barre de navigation qui switch entre elles
On va devoir commencer à réfléchir à la structure de notre projet. En effet, nous codions toute l’app dans le même fichier auparavant. On va ajouter cette fois ci de nouveaux composants, et ça risquerai de faire plutôt brouillon par la suite de notre tutoriel. Je vous propose celle-ci :
Voici un squelette de base que j’utilise couramment pour débuter une application ReactNative. Quelques explications concernant leurs utilités :
– Service : dossier donnant des services à l’utilisateurs. Générer un pdf, initialiser des paramètres à l’ouverture de l’application, etc.
– Page : contient nos vues globales, affiché tel qu’elle à l’utilisateur
– Navigation : définit l’ensemble des éléments permettant de naviguer entre les vues (tab navigator, stack navigator, etc.)
– Database : contient l’ensemble des requêtes pour questionner une base de données SQL
– Shared : éléments utilisé à travers toute l’application, que ça soit des énumérations, constantes ou interfaces
– Assets : contient des images, des polices, et tout autre éléments ‘brut’ nécessaire pour remplir notre application
– Scripts : permet d’automatiser des tâches, comme le build des ipa ou apk
– Component : contient les différents composants de notre applications, avec une granularité concernant leurs tailles (Atome => Molécule => Organisme => Template )
App.tsx : Point d’entrée de notre application
App.json : fichier de configuration global de notre application
Package.json : contient l’ensemble des dépendances de notre app (paquets npm)
Biblio requises
Il nous faut de belles icones :
npm install --save @expo/vector-icons
Il nous faut notre lib de navigation, inclus depuis react :
Pour chaque écrans que l’on aura besoin, nous allons juste y inclure au milieu un texte, pour démontrer que l’on change bien d’écrans en naviguant. Je créer des interface minimaliste avec le code suivant :
Je le fais à l’identique pour mes deux autres écrans. Tout se passe dans le dossier /scenes/.
Définition de notre barre de navigation
Premièrement, on définit via la méthode createBottomTabNavigator(), une instance
On export le type MainTabNavigator()
On créer un <NavigationContainer>
On créer <Tab.Navigator>
Dans ce dernier on définit autant de <Tab.Screen> que nous souhaitons d’écrans. On lui fourni un nom, et un composant à afficher. Rappelez vous, ce sont les écrans définit précédemment via <View>
Le tabBarOptions nous permet de définir une couleur différente selon l’onglet qui est actuellement ouvert.
Ajout d’icone
Afin de rendre notre barre plus jolie, on va y ajouter des icones au dessus de nos écritures. Pour cela on va ajouter une nouvelles propriétés à la suite de tabBarOptions, dans le Tab.Navigator :
La propriété route nous permet d’assigner la bonne icone à la bonne page.
La propriété Platform.OS nous permet de savoir si nous sommes sur un iOS ou Android, permettant d’assigner la bonne icones selon les codes de bonne conduite UI/UX de chaque constructeur.
Ajouter notre tab barre au lancement de l’application
On ajoute simplement notre composant MainTabNavigator dans la fonction principale de notre App :
Soucis de superposition de status bar
Dans certains cas, il se peut que votre application déborde sur la status bar, engendrant des données au niveau de l’horloge ainsi que sur les icones de vos notifications. Pour régler ce problème, on va encapsuler notre MainTabNavigator, par une SafeAreaView :
Chargement local de fonts
J’ai déjà eu des soucis concernant certains texte qui étaient coupé au sein de mon application, lorsque je rendais le texte en gras. En me baladant un peu sur la toile, j’ai trouvé une petite soluce, qui consiste à charger une nouvelle font pour toute mon application, en local. Dans votre dossier Assets/, rajoutez un dossier Fonts/. Ajoutez y la police que vous souhaitez, je prends pour exemple la police Arial.
Installez le module correspondant :
expo install expo-font
On commence par définir nos variables dans le fichier d’entrée globale de notre application :
Je transforme notre composant de fonction en un composant de classe. Cela va nous permettre de définir un attribut nous permettant de savoir quand notre police sera chargé :
J’initialise le constructeur de la classe App :
On utilise la fonction componentDidMount(). Celle-ci est une routine appelé une seule fois la construction de la classe, et permet de lancer des fonctions une seule et unique fois durant tout le cycle de vie de l’application :
Elle appellera ma fonction ou je lui demande de charger ma police en local, et de mettre à jour ma variable fontsLoaded.
Le dernier changement consiste à laisser l’utilisateur patienter sur le splashscreen, tant que la police d’écriture n’est pas chargé. Une les assets voulu chargé, on lance notre application :
Faîte comme suit pour utiliser notre nouvelle police fraichement installé :
Conclusion
Nous venons de construire notre barre de navigation principale de notre application.
Je vous montre au prochain chapitre, comme faire de la navigation imbriqué avec des StackNavigator. Cela permettra d’ajouter autant de vue que l’on souhaite à travers nos onglets de notre barre principale.
Vous pouvez utiliser directement Expo pour lancer très facilement votre build sur leurs serveurs distants, avec la simple commande :
expo build:android
Pourquoi je ne l’utilise pas ?
Car lorsque que j’ai voulu lancer un build, leurs serveurs étaient down, laissant mon build en attente. Flemme de perdre plus de temps, je me suis lancé dans les recherches afin de savoir si l’on pouvait nous même générer notre build. C’est un peu plus tricky, mais ça marche.
A SAVOIR AVANT DE SE LANCER DANS LE DEV MOBILE
Je souhaite vous parler de compte développeur. ça vous évitera toute surprise comme j’ai pu avoir en développant ma première application sur les stores.
Si vous souhaitez distribuer votre application sur les stores :
iOS : Compte développeur nécessaire ( 100€ par an )
Android : Compte développeur nécessaire (25€ à vie )
Avec une licence, vous pouvez ensuite lancez autant d’application que vous le souhaitez, vous n’êtes pas limité en nombre.
Si vous souhaitez seulement builder votre application en local :
iOS : Compte développeur toujours nécessaires, sur un macOS exclusivement. Vous ne pouvez générer votre certificat, teamID et votre fichier de provision en local par vous même.
Android : Pas besoin de compte spécifique. Juste un macOS ou Linux d’obligatoire. Car votre fichier de clée nécessaire au build est générable en local, par vous même.
Prérequis
Bash
NodeJS
Build pour Android
macOS ou Linux ( pensez à avoir une VM )
JDK/JRE (Java Development kit) en version 8 exclusivement
Build pour iOS
macOS
Xcode (minimum v11.4)
Fastlane ( préférez l’installation par Homebrew, le plus simple et rapide moyen )
Si comme moi vous êtes pauvres et n’avez pas de macbook pour build votre .IPA, je vous ait fait un article qui vous sauvera un ou deux jours de recherche et de test pour avoir un macOS Catalina sur votre linux qui est proche d’avoir les performances d’une install native ! Oubliez windows, oubliez virtual box ou vmware. Même mon pc à 4000€ ne fait pas tourner macOS, car aucun de ces softs ne peut attribuer des ressources graphiques, entrainant de gros ralentissement lors de vos déplacement de souris et ouverture de logiciel. Bref, c’est inutilisable, à moins de passer par mon tuto qui utilise le combo QEMU/KVM, et qui fait tourner lui Catalina facilement sur mon portable à 2 coeurs de 2015 😁
On utilisera la TurtleCLI pour générer le build. Installez le via npm :
npm install -g turtle-cli
Signature de l’application
Android
La première étape consiste à signer l’application. Cela permet de créer des certificats concernant la sécurité, pour la distribution. On va utiliser l’outil keytool de java pour générer notre keystore :
Vous pouvez apercevoir aussi des clés avec l’extension « .keystore ». C’est une clée comme les « .jks » avec un format différent.
Cette commande va vous demander plusieurs questions vous concernant :
Un fichier va être crée. Veillez à bien mettre de côté de fichier. Il vous sera demander à chaque build de votre application
iOS
Il vous faudra un certificat, un apple Team ID, et un fichier de provision
Génération du certificat
Allez sur votre compte développeur Apple. Dans l’onglet certificat, cliquez sur le bouton + :
Choisissiez l’option iOS Distribution (app store and ad hoc ) :
Faîte continuer, et on arrive sur une nouvelle fenêtre nous invitant à envoyer un fichier CRC :
On va devoir générer un certificat. Pour cela, lancez l’application Trousseaux d’accès qui est dans le dossier Applications/Utilitaires de votre macbook. Dans le menu en haut à gauche, cliquez sur Trousseaux d’accès, puis sur Assistant de certification, puis sur Demander un certificat à une autorité de certificat :
Remplir les champs demandé, et faîte enregistrer en local :
Vous aurez un nouveau fichier sur votre bureau :
On retourne sur le compte développeur Apple ouvert précédemment, nous étions rester sur la fenêtre ou on nous demander notre fichier CSR. C’est le fichier que nous venons de générer sur le bureau que nous allons upload :
Nous pouvons désormais télécharger notre certificat ! Téléchargez le, et ouvrez le :
Il sera automatiquement ajouté à notre trousseau d’accès, attaché à notre session :
Sélectionnez votre certificat fraichement installé avec sa clé privée, et exportez les deux éléments :
Exportez au format .p12, et donnez lui un nom et mettez le de côté, ce fichier vous sera obligatoire pour builder :
Un mot de passe sera demandé, notez le bien de côté, il vous le sera demandé lors du build :
Vous avez maintenant un certificat au format .p12 sur votre bureau. Gardez le bien de côté.
Création du teamID
On revient sur le compte développeur Apple, et on va allez cette fois ci dans l’onglet Identifiers, cliquez sur + :
On coche App IDs, et on continue :
On sélectionne App, et on continue :
On remplis le champ Description qui est le nom de l’application, ainsi que son bundleID sous la forme recommandé. Dans Capabilities, vous cocherez les accès et autorisations que votre application à besoin. Par exemple si c’est une application photo, elle devra avoir accès à l’APN du smartphone. Vous cliquez ensuite sur Continue, puis Register :
Notez bien votre App ID Prefix, qui est votre Team ID. Vous en aurez besoin pour build par la suite.
Fichier de provision
Troisième et dernière étape. On va maintenant s’occuper de générer du fichier de provision, lui aussi nécessaire pour buid l’application.
Toujours sur notre compte développeur Apple, on va sélectionner cette fois ci l’onglet Profiles, et cliquer sur + :
On sélectionne ensuite App store, dans l’onglet Distribution. A savoir, les builds Ad Hoc ne sont pas pris en charge par Expo. On clique sur Continue :
Sélectionnez l’app ID précédemment crée, et faîte Continue :
Sélectionnez le certificat précédemment crée, et faîte Continue :
Donnez un nom à votre fichier de provision, et faîte Generate :
Téléchargez le, et gardez le de côté, vous en aurez besoin pour générer votre build :
Export de l’application
Android & iOS
La seconde étape consiste à exporter notre application. Cela permet de créer les bundles (iOS & Android) à partir des fichiers javascript. Vous devriez apercevoir la création d’un dossier « dist » dans votre répertoire courant via la commande suivante :
Attention à utiliser la bonne, selon si votre application contient du HTTP ou HTTPS.
Servir l’application
Android & iOS
On va maintenant lancer notre application à partir du bundle crée précédemment, en local. Pour cela on va utiliser python. Déplacez vous dans le dossier « dist » précédemment crée, et lancer la commande suivante :
Vérifiez bien que le serveur tourne, via curl, ou en lançant une connexion à votre localhost via votre navigateur :
Build l’application
Dernière étape, on va pouvoir lancer le build de nos fichiers. Revenez à la racine de votre projet et ouvrer une autre console.
Android
Lancez la commande suivante pour lancer le build via turtle-cli :
Voilà votre fichier APK, situé dans le répertoire annoncé dans la console.
iOS
Lancez la commande suivante pour lancer le build via turtle-cli :
Soucis fréquemment rencontré
EACESS permissions denied
Vous pouvez vous confronter à des erreurs d’accès aux fichiers pour installer des packets npm globaux ( pour turtle-cli ou encore expo ). Oubliez les sudo su et sudo en tout genre, qui m’ont fait juste galérer encore plus. Vous pouvez fix cela en deux étapes :
Utilisez l’option ‘–unsafe-perm‘ de NPM
Pour le dossier ‘lib/node_modules’ qui résisterait aux erreurs, passez un coup de chown -R votreNomUser pour donner accès à votre utilisateur courant de la session au dossier en lecture et écriture.
Conclusion
Nous venons de générer nos fichiers d’installation APK pour Android et IPA pour iOS, afin de distribuer notre application.
On s’attaque à la navigation entre plusieurs écrans sur notre prochain chapitre.
Nous avons des outils dans le développment web, permettant de développer rapidement un squelette de base pour une application :
CLI pour Angular
CRA pour React
CLI pour React Native
Mais pour créer mon premier projet pour découvrir ces technos mobile, je pars non pas sur ReactNative CLI, mais sur ExpoCLI. C’est comme Rails mais pour ReactNative, ou encore Phonegap pour Cordova. Il étends les fonctionnalité de ReactNativeCLI.
Qu’apporte t-il de plus par rapport à React Native CLI et quand l’utiliser ?
Avantage :
Pas besoin d’Android Studio ni de Xcode
Configuration bien plus simple & rapide ( hello world en moins de une minute )
Hot reload, sur smartphone physique et non par simulateur. Oui, via l’appli Expo, vous pouvez tester votre app sur votre smartphone iOS ou Android physique, et ce instantanément. En react native vanilla, vous avez droit au simulateur Android sur Windows, et simulateur iOS sous macOS exclusivement.
Inconvénient :
Poids de l’apk/ipa, du à l’ajout de librairie annexes (~50mo le hello world, ça fait mal…)
Accès aux modules natifs impossible. Vous ne pouvez ajouter de lib natif via Xcode ou Android studio, car tout est packagé via le sdk Expo. Certaines fonctionnalité sont impossible d’être utilisé, comme les achats in-app ou le bluetooth.
En résumé, pour débuter le dév mobile ou pour de simples application, vous devriez commencer par Expo. Pour des utilisateurs expérimentés ou souhaitant des fonctionnalités spécifiques à chaque plateforme, partez sur du ReactNative vanilla.
Prérequis
Il vous faudra de base :
NodeJS
Installez ensuite la CLI de Expo via une console :
npm install -g expo-cli
Pensez à avoir Python dans vos variables d’environnements, au risque d’avoir une erreur d’installation.
Initialisation du squelette
On initialise une nouvelle application via la commande :
expo init "Nom_de_votre_app"
Vous aurez l’architecture suivante :
assets/ : dossier contenant vos images
app.json : fichier de configuration du projet
app.tsx : fichier d’entrée de votre application
package-json : contient l’ensemble des dépendances et scripts du projet
tsconfig.json : fichier de configuration de typescript
babel.config.js : fichier de configuration pour la gen du bundle ( une sorte de webpack )
Lancement du serveur de dév
Simple :
npm start
Un nouvel onglet dans votre navigateur va s’ouvrir, vous proposant divers options :
Pour faire fonctionner le simulateur Android ou iOS, vous allez devoir installer les biblio natives. Mais on peut éviter cela en utilisant notre propre smartphone. On va devoir connecter notre smartphone au même réseau wifi que l’ordinateur sur lequel on développe.
Installez l’application EXPO, disponible sur l’iOS Store et GooglePlay store, selon votre type de device. Une fois l’application lancé sur votre smartphone, vous allez pouvoir scanner le QR code affiché sur la console, comme montré sur la capture d’écran précédent. Cela va permettre de transférer le bundle directement sur le smartphone.
Vous allez pouvoir ainsi voir vos modification en temps réel sur votre téléphone, de l’application que vous codez, à chaque sauvegarde.
Icone & Splash screen
Vous pouvez changer l’icone de votre application via le fichier « app.json ».
De même pour le splash screen, qui correspond a l’image qui sera affiché le temps que votre application soit chargé par votre smartphone.
Conclusion
Nous venons de voir comment réaliser un « HelloWorld » en quelques minutes, et ce directement sur notre smartphone.
On discutera dans le prochain chapitre sur comment générer les fichiers APK et IPA, permettant d’installer et de distribuer notre application.
Projet qui consiste à reproduire le fonctionnement d’un radar automatique.
Comment fait-il, à partir d’une photo, pour reconnaître l’emplacement d’une plaque d’immatriculation, afin d’en lire les caractères ?
On s’intéressera ici dans cette première partie à la constitution du dataset nécessaire pour entraîner des modèles de réseau de neurones pour réaliser un apprentissage profond.
Vous avez une multitude de technique en traitement de l’image pour réaliser une lecture de caractère sur une image. Mais j’ai souhaité rester dans le domaine de la data-science, en pensant au réseau de neurones à convolution français le plus connu au monde, à savoir leNet-5 de Y.Le Cun, qui permet de transcrire en texte des chiffres écrit à la main sur une image.
Qui dit deep learning, dit nécessité de beaucoup de données.
Quels types de données
Je suis partie sur l’architecture suivante :
Entraîner un premier réseau de neurones, pour qu’il puisse repérer une plaque d’immatriculation au sein d’une photo. On va utiliser un CNN des plus standard. Il va prendre en entrée des images de voiture, et nous extraire les coordonnées d’un rectangle contenant la plaque. Nous pourrons l’extraire par la suite de l’image pour la fournir à notre second réseau.
Notre premier dataset sera constitué de 2 parties :
partie 1 : regroupe des images de voitures.
partie 2 : un fichier CSV ou n’importe quel format permettant de stocker le nom d’une image de voiture (exemple: image1.png) associés aux coordonnées du rectangle contenant la plaque.
Entraîner un second réseau de neurones qui va prendre en entrée la sortie du premier réseau, à savoir une image sous forme de rectangle, contenant la plaque d’immatriculation de la voiture. Celui-ci encore sera un CNN standard. Il donnera en sortie, du texte, représentant les caractères présents sur la plaque d’immatriculation de la voiture.
Ce second dataset lui aussi sera en deux parties :
partie 1 : regroupe des images de plaques d’immatriculation.
partie 2 : un fichier CSV ou n’importe quel format permettant de stocker le nom d’une image d’une plaque (exemple: image1.png) associés au caractères présent sur la plaque.
Constituer son jeu de données
Je vais vous présenter quelques techniques afin de récolter et réunir des données.
Dataset pré-existant
Comme tout bon informaticien, on sait que c’est inutile de réinventer la roue. En effectuant quelques recherches, vous avez déjà de fortes chances que des chercheurs ou autres développeurs aient déjà fait le travail pour vous. En recherchant des articles scientifiques sur des moteurs de recherches spécifique ( Google Scholar, Arxiv, etc.), on peut trouver des travaux sur des reconnaissances comme celle que je souhaite réaliser. Vous pouvez des fois tomber pile sur ce que vous cherchez et gagner grandement en temps (phase de récolte, nettoyage & régulation des données, etc.), c’est tout bénéf pour vous. Ou des fois tomber comme pour moi, sur des données, mais qui ne s’adapte pas pleinement à mon cas précis pour plusieurs raisons :
Pas de dataset sur des plaques exclusivement françaises
Certains dataset ont des images de qualité médiocre
Certains dataset ont très peu de données ( une centaine… )
Comme expliqué dans le point précédent, j’ai un type de données bien précis. C’est d’ailleurs pour cette raison que j’ai repoussé x fois de faire ce tutoriel, car la constitution du dataset aller être un casse-tête terrible, me demandant des fois si je ne devrais pas passer des journées entières sur la rocade Bordelaise à photographier le passage du moindre véhicule 🤣
Crawling & Scraping
En effectuant des recherches sur le net, vous pouvez trouver des sites comme Google image, Twitter, Instagram, etc, contenant des images de voiture ou de plaque. Une première solution serait de réaliser des requêtes BigQuery afin de pouvoir tout télécharger (pour google), ou faire du web crawling et scraping (pour les autres réseaux). On va s’attarder sur cette seconde solution 😀
Cela consiste en quoi ? ( Théorie )
Faisons simple.
Le web crawling est le fait d’utiliser des robots afin de circuler et parcourir un site web de façon scripter, automatique, dans l’ensemble de son domaine.
Le web scraping est le fait d’utiliser des robots afin de récupérer des informations d’un site, de télécharger ses images, en bref récupérer l’ensemble de son DOM.
On va bosser avec des Dataframes Pandas, donc on va rester sur du Python. Et ça tombe bien, car il se prête bien à ce type d’utilisation. Les principales librairies de crawl/scrap sont les suivantes :
BeautifulSoup : libraire des plus simples, donc très pratique pour ce genre de petit projet. Je l’ai utilisé pour récolter des datas pour de la détection de harcèlement.
Scrapy : bien plus complet, il s’apparente à un framework à part entière, donc plus compliqué à prendre en main mais permet beaucoup plus de chose.
Pour un projet aussi simple j’aurais dû partir sur BS, mais pour le goût du défi je suis parti sur Scrapy pour découvrir de nouvelles choses. C’est vrai que BS nécessite que quelques lignes de code pour récupérer des données, chose un poil plus complexe avec Scrapy.
Initialiser un projet Scrapy
On commence par installer notre paquet :
pip install scrapy
Vous pouvez l’installer aussi via Anaconda.
Dans une console initialiser un nouveau projet :
scrapy startproject Nom_De_Ton_Projet
Vous allez avoir l’architecture suivante :
Projet
__init__.py
middlewares.py : permet de définir des customisations sur le mécanisme de comment procède le spider
pipelines.py : pour créer des pipelines. Les items scrapé sont envoyé là-dedans pour y affecter de nouvelles choses, comme vérifier la présence de doublon, de nettoyer des datas, qu’ils contiennent bien les champs souhaités, etc. ( on s’en fou )
settings.py : fichier de configuration du projet. Définissez vos vitesses de crawl, de parallélisation, nom de l’agent, etc.
scrapy.cfg : fichier de configuration de déploiement ( on s’en fou )
SPIDERS/
__init__.py
On a vraiment besoin que du strict minimal concernant les outils que nous propose ce framework.
On va juste s’attarder un poil sur le settings.py. Ce genre de technique est très peu apprécié car vous pouvez littéralement surcharger les accès à un site. Vérifier que le site ne possède pas une API publique permettant de récupérer les données souhaitées.
Pour rester courtois, renseignez les champs BOT_NAME et USER_AGENT. Ce qui donne pour ma part :
BOT_NAME = 'Crawl&Scrap'
USER_AGENT = 'Bastien Maurice (+https://deeplylearning.fr/)'
Utiliser des vitesses de crawl/scrap et un nombre de requête concurrente de façon raisonné :
CONCURRENT_REQUESTS = 16
Scrapy propose même des outils permettant d’ajuster sa vitesse de requêtes de façon intelligente :
AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_START_DELAY = 5
AUTOTHROTTLE_MAX_DELAY = 60
AUTOTHROTTLE_TARGET_CONCURRENCY = 1.0 (le plus important)
Squelette minimal d’un spider
Un spider est un composant qui va scrap un type de donnée. Nous souhaitons scrap deux types de données, nous aurons alors deux spiders. Voici le code minimal lors de la création d’un spider :
name est le nom du spider
allowed_domains est un tableau contenant les noms de domaines autorisés pour notre spider
start_urls est un tableau contenant les URL de points de départ par où commencer à scrap
La méthode __init__ est le constructeur de la classe. On va définir deux méthode (start et end) qui seront exécuté lors de l’appel de signaux (signals.spider_closed & signals.spider_opened) correspondant au lancement et à la clôture du scraper.
La méthode parse est la méthode appelé par Scrapy, c’est ici que toute la magie du scraping va se dérouler et ou on devra définir ce que l’on souhaite récupérer du site distant 😎
Coder notre spider pour le dataset 1 & 2 😏 ( Simple parsage )
La première idée était d’utiliser ces deux méthodes sur un maximum de site afin de récupérer un maximum de donnée. Seul bémol, j’aurais dû écrire à la main mon fichier CSV pour y ajouter le numéro des plaques. Mais j’ai réussi en creusant dans mes recherches, à trouver un site qui expose des images de plaques, avec diverses infos :
Choix de la nationalité de la plaque ( voiture française dans notre cas exclusivement )
Photo de la voiture en entier
Photo de la plaque d’immatriculation (généré automatiquement, ce n’est pas un crop de la plaque de la photo)
Date d’ajout
Pseudo de l’utilisateur qui a ajouté
On va pouvoir récupérer à la fois des données pour le dataset 1 et pour le dataset 2.
Créons un nouveau fichier, scraper.py dans le dossier ‘spider‘ de notre projet Scrapy. Ajoutons-lui les attributs suivants :
csvFilepath : chemin de destination vers mon fichier CSV, qui va contenir les données de ma plaque d’immatriculation. Je souhaite que à chaque donnée on récupère les données suivantes :
date : date à laquelle la photo a été upload sur le site distant
heure : heure à laquelle la photo a été upload sur le site distant
voitureMarque : marque de la voiture
voitureModele : modèle de la voiture
imgGlobalName : nom de l’image de la voiture global que je vais enregistrer en local
imgPlaqueName : nom de l’image de la plaque que je vais enregistrer en local
plateNumber : numéro de la plaque d’immatriculation
page : numéro de la page en cours de scraping
maxPage : nombre de page max à parser
DIRECTORY_IMG_PLATE : dossier de destination pour enregistrer les images PNG de la plaque seule
DIRECTORY_IMG_GLOBAL : dossier de destination pour enregistrer les images PNG de la voiture globale
GLOBAL_DATA : fichier CSV qui sera lu par la librairie Pandas
L’attribut urllib.urlopener va être extrêmement important. Il peut vous arriver que le site distant vous remonte une erreur, signifiant qu’il bloque les spiders qui scrap des datas. On va camoufler notre spider en lui associant une version pour le faire ressembler à une connexion venant d’un humain. Vous pouvez lui donner d’autres versions, peu importe qu’il vienne de Mozilla, Chrome, Firefox, de même pour les versions…
On va pouvoir ainsi scrap nos data comme souhaité 😁
Je connecte mes signaux :
Début du scrap : je demande à Pandas de charger mon fichier CSV contenant l’ensemble de mes datas
Fin du scrap : je demande à Pandas de sauvegarder mes nouvelles données en plus des anciennes en local
Et enfin la méthode parse qui permet de récupérer nos données, de les nettoyer :
Quelques infos utiles :
La méthode xpath me renvoi de base un object xpath
La méthode .get() me converti mon object xpath en string
L’attribut xpath du sélecteur text() me renvoi le champ text, d’une balise <division>Coucou</division par exemple
L’attribut xpath du sélecteur @src me renvoi le champ src, d’une balise <img src= »lien_vers_image« > par exemple
L’attribut xpath du sélecteur @altme renvoi le champ alt, d’une balise <img alt= »infos_utiles« > par exemple
Coder notre spider pour le dataset 2 😏 ( Utilisation de leur API )
Je me suis dit pour augmenter notre dataset de façon bien plus conséquente, qu’il serait intéressant d’avoir un générateur de plaque avec des caractères aléatoire. Une image de plaque d’immat est simple à réaliser en effet. Et il se trouve que sur ce même site il y a un système permettant de réaliser nos plaques sur mesure via leur API :
Comme vous pouvez le voir, on peut choisir nos plaques selon :
La nationalité
Le type de standard
Le nombre de rangé
Le département
L’ensemble des caractères de la plaque
Après avoir remplis l’ensemble de ces informations, le site vous génère la plaque selon vos numéros choisi. J’ai souhaité rendre ce processus de façon automatique. Etant donnée que c’est nous qui rentrons les lettres voulues, on pourra les récupérer pour les inscrire dans notre fichier de données CSV.
Avant de se lancer dans le code, il va falloir faire une petite analyse du site, pour savoir comment générer une plaque en utilisant l’API, sans que celle-ci nous soit indiqué explicitement. En effet, contrairement à des outils tel que Sélénium, Scrapy ne peut faire des interactions directement avec le javascript, comme par exemple simuler des clics de souris sur des boutons. On a donc besoin de l’accès de l’API.
En utilisant les outils de Chrome qui sont intégrés, on va aller chercher que fait ce bouton lors d’un événement (click), et lire le code source de la page. En remontant dans les parents du bouton, on aperçoit le formulaire qu’envoi le bouton lors d’un clique. Il envoi l’action « /fr/informer » avec comme méthode « post » :
On va maintenant aller voir du côté réseaux et des paquets qui y sont échangés. Vous pouvez enregistrer sur des périodes, l’ensemble des requêtes qui transite de vous au serveur, permettant de voir les informations qui y sont échangés. J’ai lancé mon enregistrement, puis j’ai cliqué sur le bouton pour générer une plaque. Dans l’onglet Network, vous aurez pleins de requêtes. A vous de les analyser pour récupérer les informations dont vous souhaitez.
J’ai réussi à retrouver l’action appelé par mon bouton :
On peut observer dans la partie Form Data, que plusieurs paramètres ont transités lors de l’appel à l’API. Celles-ci sont les données permettant de générer la plaque, donnée par les champs de texte vu précédemment et rempli par l’utilisateur. Nous devrons donc induire de nouvelles notions pour coder ce nouveau spider, afin d’y injecter des paramètres lors de notre requête au site distant.
Nous venons d’analyser brièvement le site. Passons à la pratique.
Créons un nouveau fichier, plateGenerator.py dans le dossier ‘spider‘ de notre projet Scrapy que voici :
Pas de nouvelles choses comparées à l’exemple précédant. On garde une version custom pour les en-têtes URL pour by-pass le 403 forbidden.
Je définis deux nouvelles fonctions. Celles-ci vont me permettre de me générer de façon aléatoire soit seulement des lettres, soit des chiffres, de longueur que je souhaite. Elles vont me permettre de générer les valeurs de mes plaques générées :
On va utiliser la méthode « start_requests ». Celle-ci est appelé de base, par rapport à notre url défini dans « start_urls » :
L’ensemble du code est documenté ligne à ligne.
La dernière ligne, avec le mot clé ‘yield’, va nous permettre de générer une requête basée sur des données de formulaires. On lui donne les données de la plaque que l’on souhaite générer à l’API. Le paramètre « meta » n’est utilisé que pour passer des informations de ma fonction « start_requests » à ma méthode « parse ».
Cette requête appelé va être interprété par notre méthode « parse ». Comme pour le premier cas, c’est ici que tout la magie du scrapping s’opère :
Ajuster ses données
Ajout des coordonnées de la plaque dans le dataset 1
Après avoir craw/scrap le site en question, on se retrouve avec la photo de la voiture, le numéro de sa plaque, mais pas la position (X, Y) où se trouve la plaque sur la photo de la voiture. Cela aurait été fait dans des datasets pré-existant. Etant donné que je le constitue moi-même, je vais devoir le réaliser moi-même.
Vous avez plusieurs logiciels sur Github vous permettant d’ouvrir des images, de placer des rectangles, et celui-ci vous renvoi les coordonnées et vous permet de constituer un fichier CSV avec l’ensemble des coordonnées des images de votre dataset. ça risque d’être long et répétitif. C’est pour cela que je suis parti pour créer mon propre logiciel me permettant de tout automatiser. Cela risque de me prendre du temps, mais à terme, d’en gagner pas mal de façon proportionnelle à la taille de mon dataset.
Coder son propre logiciel
Nous avons vu les limites pour constituer un dataset.
Que cela soit en reprenant le travail d’autres personne malgré qu’il ne corresponde pas à 100% de notre objectif. Ou le fait qu’il soit incomplet (manque de la positions X,Y de la plaque d’immatriculation au sein de la photo) lorsque on le réalise soit même par crawl/scrap. Ou encore que l’on manque cruellement de données.
Une possible solution pourrait être de créer son propre logiciel pour générer des images ?
On pourrait réaliser un système de génération de plaque d’immatriculation pour remplir le dataset 2 (comme le fait l’API du site précédent), ou encore coller ces plaques générées sur des photos aléatoires de Google. En effet, notre réseau de neurones 1 n’a pour but que de détecter, de localiser, et de fournir la position de la plaque au sein de la photo, rien de plus. Donc que l’on prenne de vraies photos de voiture avec de vraies plaques d’immatriculations placé au vrai endroit revient au même pour notre réseau que de générer une plaque aléatoire, et de l’insérer dans une photo aléatoire.
Je dit presque, car il y aura toujours une différences entre de vraies photos et des photos/plaques générés. Il ne faudrait pas entraîner notre réseau sur des données qu’il ne rencontrera pas à nouveau, du moins des données semblables. Les fonds générés ne devraient pas gêner notre système, contrairement à nos plaques que l’on va générer :
Plaque plus ou moins inclinés et non droite selon la prise de photo
Plaque plus ou moins éclairés selon le soleil
Ombre plus ou moins importante selon le soleil
Plaque plus ou moins propre (boue, moustiques, etc.)
On peut prévoir d’avance des risques d’avoir quelques soucis en utilisant notre système tel quel. Il ne pourrait reconnaître que des plaques parfaitement blanches, et droite, ce qui risque de peu arriver dans la réalité sur le terrain. Il faut donc permettre à notre réseau de mieux généraliser, et donc lui fournir des cas d’exemples pour qu’il puisse apprendre plus ‘intelligemment’. Il faudra donc ajouter à notre logiciel de génération de plaque le moyen de pouvoir répondre au problématiques précédents :
Permettre d’ajouter une rotation et
Permettre d’ajouter un effet de perspective
Permettre d’ajouter du bruit,
Permettre d’ajouter des assombrissement et/ou tâche
Ces effets permettront de se rapprocher un peu plus à la réalité des plaques d’immatriculation que l’on retrouve en service. Ces effets devront être généré de façon aléatoire, et ceux dans des proportions minimal et maximal définit par des intervalles.
L’article se faisant déjà assez long, je ferais un article dédié à mon logiciel de générateur de plaque, DeeplyPlate.
Conclusion
Au bout de cette première partie je vous ait données quelques pistes pour :
Circuler sur un site via Scrapy
Coder son premier spider pour récupérer des données sur le net
Les données que vous souhaitez ne seront pas forcement existante sur le net, ou sous un format spécifique à votre utilisation. C’est pour cela que je vous montre que vous pouvez réaliser votre propre logiciel assez rapidement, en 10-15 jours de travail régulier pour soit réaliser de façon artificielle vos données, ou encore créer votre propre logiciel de data augmentation afin d’augmenter la taille de vos données aussi petite soient-elles.
Je vous propose de passer à la Partie 2. On s’attaquera cette fois-ci à comment faire de la détection d’objets sur une image. Nous allons montrer comment entraîner un modèle pour qu’il puisse nous fournir les coordonnées sur une image donnée, de l’emplacement d’une plaque d’immatriculation. Nous pourrons ensuite découper cette partie de l’image afin de le donner à un second modèle, afin qu’il puisse nous lire et extraire sous forme de texte les valeurs de la plaque. Mais celle-ci se fera en Partie 3 😎
Remerciement
Le tutoriel n’aurait pu être possible sans le site Platesmania. Pour préserver la stabilité du site, ne crawler/scraper qu’avec un nombre de requête et parallèles raisonnable.
Lorsque j’ai voulu me lancer dans la data visualisation intégrée à un site web, j’ai directement voulu utiliser la librairie la plus célèbre en la matière, à savoir D3.js. Mais j’ai trouvé une alternative qui m’a interpellé car basé à la fois sur D3.js ainsi que Stack.gl, permettant de réaliser des graphiques plus interactifs, à première vue.
Celle-ci est disponible à la fois en Python, R, et enfin Javascript, celle qui nous intéresse dans notre article. Et c’est pour cette raison que je l’écris, car celui-ci n’est pas vraiment disponible en Typescript et bien intégré à l’écosystème d’Angular, qui a des notions de modules, de composants, etc.
On utilisera des données du Covid19 pour alimenter en data nos graphiques. C’est parti !
Quelques infos sur Plotly.js
Pour créer un graphique, on va avoir besoin de trois choses principalement qui se découpe de la façon suivante :
Data
Un objet data qui va contenir l’ensemble des points (ordonnées Y, et abscisse X) que l’on souhaite afficher sur notre graphique.
On le défini dans notre composant en Typescript.
Layout
Un objet layout qui définit les caractéristiques générales au niveau de l’UI de notre graphique, comme le titre, la taille de notre graphique, etc. Si l’on souhaite modifier l’allure d’une courbe en particulier, cela se fera dans l’objet data cependant.
On le défini dans notre composant en Typescript.
Config
C’est l’objet final crée, qui englobe notre objet Data ainsi que notre objet Layout.
On le défini dans notre composant en Typescript, et on ira le binder avec notre fichier de vue en HTML.
Intégration de Plotly.js
Je commence par initialiser un nouveau projet Angular pour illustrer notre exemple. Je vous renvoie sur un précédent article, expliquant comment initialiser une application Angular.
On installe via npm les modules nécessaires :
npm install angular-plotly.js plotly.js
On ajoute le module Plotly à notre module globall App :
Dans votre fichier de configuration tsconfig.json, passez ‘target’ en ‘es5’, si vous avez une erreur dans votre console comme quoi Plotly n’est pas défini dans votre document.
Création d’un graphique avec une courbe
Partie vue
On ajout un composant ‘plotly-plot’. Celui-ci est composé de plusieurs directives et attributs :
fxFlex & Style : directive FlexLayout de Angular, permettant à notre composant de prendre toute la hauteur et largeur du parent disponible
useResizeHandler : directive permettant de resize automatiquement le graphique selon la taille de la fenêtre
data: object contenant l’ensemble des données du graphique
config: object contenant la configuration général de notre graphique
layout: object contenant la configuration graphique de notre graphique
Partie composant
On déclare nos attributs généraux :
J’initialise mes précédents attributs dans le constructeur du composant :
Par la suite, je vais charger mon fichier de données. J’utilise un fichier CSV qui va être lu en local via le httpClient :
Enfin, ma fonction permettant de parser mon fichier CSV de string :
Le plus important sont les lignes suivantes :
4-5 : création de tableau temporaire, contenant nos données
14-15: on remplit nos tableau déclarés précédemment des données du fichier CSV en cours de parsage
23-24: ajout de nos nouvelles données
Voici le résultat de ce que l’on obtient selon le type de graphique que l’on choisit dans notre objet de data :
Vous avez une multitude de type de graphique selon ce que vous voulez donner comme aspect à vos données, je vous laisse lire la doc pour en savoir plus.
Création d’un graphique avec une multitude de courbe
On va reprendre l’exemple précédent, et y ajouter une nouvelle courbe concernant les cas soignés. Je vais enlever quelques données en début de pandémie, étant donné que l’on a eu des cas à partir du 1er Mars à peu près. Cela permettra une meilleure visibilité pour mon tutoriel.
On commence par ajouter une nouvelle courbe en ajoutant une donnée dans notre tableau de données. On fait cela comme précédemment, dans le constructeur du composant :
Vous pouvez apercevoir quelques changements comparé à la première partie de ce tutoriel :
marker : permet d’affecter une couleur à notre courbe
name : nom de la courbe dans la légende
legendgroup : permet de grouper plusieurs courbes dans un même groupe, et de pouvoir les cacher en cliquant dessus dans la légende pour toute les faire disparaître
La dernière étape va être de modifier notre fonction de parsing de notre fichier CSV qui contient nos données, afin de récupérer des informations pour une seconde courbes, qui sera elle concernant les cas soignés :
Lignes 4 : L’axe X des abscisses ne change pas, puisque on veut garder nos dates.
Lignes 6 et 18 : On va créer un nouveau tableau contenant des nombres, et le remplir de la même façon que précédemment, mais avec un indice différent et donc une donnée différente.
Lignes 29-30 : correspond à notre second objet de données créer précédemment. On fait attention de lui affecter en abscisses nos données DATE, et en ordonnés notre tableau contenant le nombre de cas soignés.
Voici le résultat de ce que l’on obtient selon le type de graphique que l’on choisit dans notre objet de data :
Quelques exemples de customisation de l’UI
Je vous présente quelques attributs plutôt chouettes pour changer rapidement le sous type de nos graphiques que je vous ai présenté précédemment, à savoir Scatter et Bar
Vous avez moyen de vraiment poussé beaucoup de chose dans l’UI du graphique, regardez la documentation si vous voulez des envies bien précises.
Sous-type de BAR
L’attribut ‘barmod’ se définit dans l’objet LAYOUT de notre graphique ( attribut ‘layout’ dans nos exemples précédents )
Espacement de BAR
Vous pouvez gérer l’espacement entre les bars pour optimiser la lisibilité de votre graphique. Vous avez deux arguments pour cela :
bargap : espacement entre les bars d’un même groupe
bargroupgap : espacement entre les bars de groupes différents
Ces deux arguments se définissent dans l’objet LAYOUT.
Sous-type de SCATTER
L’attribut ‘mode’ se définit dans l’objet DATA de notre graphique ( attribut ‘allData’ dans nos exemples précédents )
Conclusion
Vous avez donc accès pleinement à la librairie Plotly.js dans votre application Angular.
Rien de bien complexe sur son intégration donc, juste un zeste déroutant d’utiliser du Javascript dans du Typescript, on mélange du typage fort avec des objets que l’on remplit d’attributs à la volé.
Vous pouvez ajouter des events de clic, de listener, pour rendre tout cela un peu plus dynamique comme par exemple divers chargements de données pour combiner plusieurs sources, modifier en temps réel l’allure et l’UI des graphiques, etc.
Je vous propose aujourd’hui de réaliser une carte choroplèthe. C’est une carte de chaleur mettant en évidences certaines zones de différents gradients de couleurs pour montrer une intensité plus ou moins forte sur un type de donnée.
C’est d’actualité, je vous propose une carte de la France, découpé en Région, mettant en évidence l’évolution du COVID-19 sur une date donnée.
Leaflet, Openlayers pour ne citer que les plus grands, sont des librairies javascript permettant d’afficher des cartes, et d’y ajouter une multitude d’actions. Vous pouvez ajouter des dessins, des actions, des couleurs, zones, marqueurs, etc. Le but principal est de les rendre interactives pour mettre en évidences toute sorte de chose.
OpenLayers : considéré comme la référence actuellement, c’est un vrai framework à part entière. Permet donc de réaliser des choses très poussées.
Leaflet : certainement le plus populaire. Certaines fonctionnalités ne pourront pas être aussi poussé que Openlayers, car plus léger. Il marque cependant des points quant à sa prise en main, qui s’en fera plus rapidement.
Intégration de Leaflet
Intégration & affichage du fond de carte
Installation de la librairie
On installe Leaflet et son module NPM facilitant son utilisation via :
On installe les définitions de types pour se faciliter la vie pour coder : npm install --save-dev @types/leaflet
Import de la librairie
On intègre le module Leaflet dans la partie ‘Imports’ de notre fichier de définition de notre module principal :
Ajout du fond de carte
On commence par la mise en place de notre carte dans la vue. Pour cela on créer une division avec un composant leaflet :
Pour la partie back, on va définir un objet contenant les caractéristiques de notre carte qui sera bindé avec la vue :
Rien de bien complexe. On ajoute un layer à nos options qui est le fond de notre carte, en le faisant pointer au service de cartographie de Openstreetmap. On lui définit un niveau de zoom maximum utilisable par l’utilisateur, ainsi qu’un bandeau de droit d’auteur qui s’affichera en bas à droite de la carte.
On ajoute en plus des options d’initialisation que l’on retrouvera par défaut lorsque on arrive sur la page de la carte, à savoir le niveau de zoom actuelle de la carte ainsi que le point (latitude, longitude) à afficher au centre de notre écran.
Style de la carte
Si vous avez suivi les instructions, vous devriez vous retrouver avec une carte bien cassé, et c’est normal 😂
On va y remédier en ajoutant un fichier CSS de style, permettant un affichage correct de notre carte. Cet ajout de ce fichier de style se réalise dans notre fichier de configuration de notre application, à savoir angular.json :
Ajout de données GeoJSON
Type des données
Le GeoJSON est un format de donnée géospatial, suivant le format JSON. Pour faire simple, cela consiste à réunir une multitude de points GPS (latitude et longitude) afin de créer des marqueurs sur la carte. Selon le type des données, vous pouvez ainsi dessiner des traits, rectangle et toute sorte de polygone sur la carte via ces points. On va alors exploiter ces possibilités afin de découper notre France en région.
Il existe déjà une multitude de dataset GeoJSON avec toute sorte de découpage, que ça soit en fonction d’état, de départements, etc. Plus vous aurez de points au sein de votre fichier, et plus vos tracés seront précis. Cependant votre fichier sera alors plus lourd, alourdissant notre page et donc les temps de chargement.
Voici la structure de mon fichier des Régions de France :
Nous avons 18 objets, représentant nos 18 régions.
Chaque région comporte les éléments suivants :
properties : contient des données, comme le nom de la région. C’est ici que nous ajouterons le nombre de cas actifs de patient du Covid19.
geometry : contient les couples Latitude/Longitude de points permettant les tracés de chaque région.
Je vais ajouter mes données à la main dans mon objet properties, en ajoutant un nouvel attribut :
« confirmed »: « 10 »
Je le fais à la main car peu de donnée, et surtout choisit aléatoirement. Le but n’est pas de montrer les vraies stats mais de vous montrer comment afficher ces données. Je vous laisse le soin d’ajouter des vraies données avec des scripts Python pour manipuler ces objets ci 😎
Affichage des données
On va ajouter une nouvelle ‘couche’ contenant nos données des régions sur notre carte. Pour cela on ajout dans notre vue dans notre composant leaflet, l’attribut leafletLayers que l’on va bind avec notre contrôleur :
On initialise ce nouvel attribut dans notre composant :
On ajoute ensuite nos données de nos régions :
J’initialise nos données dans un hook Angular, ngOnInit, pour être sûr que la carte Leaflet soit bien déjà initialisée. J’utilise ensuite le module HttpClient pour lire note fichier de donnée en local, disposé dans mon dossier des Assets. Je vais ensuite les ajouter dans mon attribut layers, via la méthode geoJSON de Leaflet qui permet de lire des données GeoJSON. J’initialise mes régions avec une couleur bleu en fond, une certaine opacité et épaisseur de bordure, qui sert à délimiter les régions entre elle.
Changer l’UI d’une région à son survol
On va améliorer l’interface de notre carte, en mettant en évidence la région survolée.
Je vais définir deux objets définissant les états graphiques que peuvent prendre nos régions. Soit elle est normale, soit elle est en cours de survolage par la souris de l’utilisateur. On fait deux style différents afin de remonter l’information à l’utilisateur pour lui montrer sur quoi il pointe :
On va aller modifier la fonction qui ajoute notre layers de données de nos régions afin de lui affecter un style définit précédemment :
On en profite pour leur ajouter des listeners. Vous pouvez voir que sur mon layer des régions, j’ajoute deux listener :
mouseover : quand l’utilisateur passe la souris sur une région
mouseout : quand l’utilisateur enlève la souris d’une région
click : quand un utilisateur clique sur une région, mais je ne l’utiliserais pas pour ce tutoriel ci
On affecte à nos deux listener deux fonctions qui seront appelé à chaque fois qu’un event sera exécuté.
L’event pour mettre en surbrillance une région :
L’event pour rétablir les styles par défaut :
Notez la syntaxe qui diffère entre les deux, mais réalise la même action. a vous de choisir celle que vous préférez.
Coloriser la région en fonction des data
On va pouvoir passer au cœur du projet, à savoir créer nos gradients de couleurs sur nos différentes régions. On va créer une nouvelle méthode qui va être appeler lors de la lecture de notre fichier de donnée GeoJSON, juste après que l’on ait mis nos listener sur l’ensemble de nos régions :
On reviendra un peu plus tard sur l’action qu’effectue l’appel à la méthode updateLegendValues().
On ajoute deux nouveaux attributs à notre classe :
Le premier correspond à un tableau rempli de nombre. Il va nous définir plus tard les intervalles de valeurs, permettant des comparaisons afin de décider si telle région appartient à tel ou tel intervalle selon sa valeur de cas confirmés. Quant au second, il va contenir des string de code hexadécimal de couleur, il en aura autant que d’intervalle défini dans le tableau précédent.
On va les initialiser dans notre constructeur de notre classe :
J’ai crée le gradient de couleur à la main, vous avez des sites sur le net pour vous aider à les faire selon vos couleurs. Je suis parti dans mon exemple autour d’un gradient de rouge.
Pour la suite, on va simplement re-parser notre layer contenant l’ensemble de nos régions, et changer leur style. En parcourant nos régions, on va récupérer notre attribut confirmed représentant le nombre de cas confirmé au Covid19. On souhaite en fonction de leur valeur affecter une couleur différente. On va donc pour l’attribut fillColor, lui passer une fonction qui prendre en entrée l’attribut ‘confirmed‘ :
Cette fonction renvoi en fonction de son entrée, un code hexadécimal de couleur. Je pense que la fonction peut être optimisé. En effet je fais à la main les comparaisons entre 6 intervalles de valeurs, correspondant chacune d’entre elle à 6 couleurs d’intensités différentes.
Il nous manque juste une seule chose, vous vous souvenez de ma fonction updateLegendValues() ? Que j’ai parlé un poil plus haut, et qui est appelé au début de ma fonction updateStyleMap(). Celle-ci va nous permettre de remplir notre tableau des intervalles, que l’on utilise dans la fonction getColor() pour assigner une couleur du tableau selectedLegendColorGradient en comparant aux intervalles de selectedLegendInfos.
On va encore une fois parser notre layer des régions, pour y récupérer la valeur max de l’attribut confirmed. Celle fonction aussi peut être grandement optimisé mais j’ai opté pour la simplicité pour ce tutoriel. Une fois la valeur max récupéré, je vais créer autant d’intervalle que je souhaite pour faire autant de gradient que je souhaite. Je suis partie sur 6 gradients de Rouge différent. Je créer ces intervalles en fonction de ma valeur maximale de cas crée auparavant, de façon linéaire. A vous de choisir quel algorithme vous souhaitez pour créer vos gradients, si vous voulez des intervalles avec autant d’écarts entre eux comme j’ai souhaité le faire ou en fonction d’autre chose. C’est selon vos souhaits selon comment vous souhaitez mettre en valeur vos données une fois sur la carte.
Affichage d’une légende
On vient de coloriser notre carte, mais on ne sait guerre comment elles sont exposées avec des chiffres précis. C’est pour cela que je vous proposer d’ajouter une légende pour préciser à quoi correspond chacun de nos gradients de couleur.
Je commence par ajouter une nouvelle division dans notre vue pour cette légende :
J’y ajoute un titre.
J’y ajoute une première boucle pour itérer sur l’ensemble de nos gradients de couleur, que j’inclus sous forme de petits carrés.
J’y ajout une seconde boucle pour itérer sur l’ensemble de nos intervalles de valeurs.
Vous pouvez voir que j’ai des appels de type fx dans mes balises. C’est du à l’utilisation d’une bibliothèque disponible dans Angular, FlexLayout, permettant de manier les flexbox directement dans le fichier HTML plutôt que de style CSS, je trouve cela un poil plus clair, mais ce n’est que mon opinion. Vous pouvez l’installer via npm (npm i -s @angular/flex-layout @angular/cdk).
Pour finaliser ma légende, et avoir cet effet de superposition de ma légende sur ma carte, on va parler d’index. Pour cela on va ajouter attribuer des classes à nos division dans notre fichier HTML :
Ajout d’une classe lastPlan pour notre carte
Ajout d’une première classe firstPlan et d’une seconde classe legend, pour notre légende
On y ajouter le SCSS suivant :
La classe firstPlan permet de mettre en premier plan notre légende
La classe lastPlan permet de mettre notre carte en second plan. Vous pouvez jouer avec les index de façon infini pour créer autant de plan que vous souhaitez utiliser plus de deux plans.
La classe squareLegend permet de définir la taille des carrés contenant nos couleurs.
La classe legend permet de définir le conteneur de l’ensemble de notre légende, de sa position sur l’écran ainsi que sa taille.
Affichage de data via popup
Je vous propose d’ajouter sur notre carte un popup, qui s’affiche au survol d’une région en affichant le nombre de cas confirmé au Covid19 qu’elle a.
On commence par créer deux nouvelles variables qui seront affiché dans notre vue :
Comme les noms qu’elles portent, la première pour afficher le nom de la région et la seconde pour afficher le nombre de cas. On les initialise à null dans le constructeur de notre composant.
On modifie notre fonction lors de l’événement mouseover, afin qu’elle affecte la valeur de la région et du nombre de cas à nos deux variables précédentes :
On utilise la classe ChangeDetectorRef dans la dernière ligne de notre fonction, qui offre des possibilités pour forcer les mises à jour de l’interface. On n’oublie pas de l’instancier en privée dans le constructeur du composant :
On modifie la fonction concernant l’événement mouseout, afin qu’elle supprime nos deux valeurs lorsque l’on sort d’une région :
Nous venons de modifier la partie du contrôleur, passons à la vue. On va créer une nouvelle division contenant notre popup :
Celle-ci ne s’affiche que si regionName contient une valeur. Vous pouvez voir que l’on a attribuer la classe css firstPlan pour qu’elle s’affiche dessus notre carte Leafleat, ainsi que la classe legendTop, définit dans notre fichier de style scss :
L’article touche à sa fin, vous devriez avoir le résultat suivant 😎
Conclusion
Vous avez donc accès pleinement à la librairie Leaflet.js dans votre application Angular.
Rien de bien complexe sur son intégration donc, juste un zeste déroutant d’utiliser du Javascript dans du Typescript, on mélange du typage fort avec des objets que l’on remplit d’attributs à la volé.
Vous pouvez faire des choses bien plus pousser. Réaliser une multitude de layers, que vous pouvez contrôler leur affichage ou non, ajouter une multitude de données dans vos GeoJSON pour binder avec des éléments dans Angular, pour réaliser par exemple un suivi du Covid19 mais sur plusieurs jours pour réaliser quelque chose de plus dynamique. Ou encore dessiner tout une multitude de polygone complexes, rendre leur affichage dynamique au sein même de la carte pour faire bouger automatiquement des marqueurs par exemple.
C’est lassant, ça prend du temps, et c’est bien souvent idiot au premier abord. Je vous présente donc….. les TESTS ! 😒 On les évites bien trop souvent, mais il faut le dire moi le premier, que l’on a tous connus des projets auquel à force de rajouts de fonctionnalités, que certaines unes d’entres elles, ont sans le vouloir casser d’autres fonctionnalités. En effet, quand on est sur une branche et que l’on focus cette nouvelle feature, on test celle-ci exclusivement dans l’environnement de développement. Et il se peut que l’on casse d’autres chose à vouloir bouger, modifier et optimiser notre code. Et on s’en rend bien souvent compte trop tard lors d’éventuelle realease en production, ce qui peut engendrer d’importantes conséquences. Ou dans le meilleur des cas comme moi, passer pour un con lors de mes démos 😅
Objectif
Installer & adapter les environnements Jest et Spectron à Electron
Réaliser des tests end-2-end
Réaliser des tests unitaires
Spectron & Jest : pourquoi et comment
Lors de la création d’un projet Angular via CLI, vous aurez d’avantage de chance de connaître les noms de Karma, Jasmine, ou encore Protractor, qui sont proposé par défaut.
Pourquoi migrer de framework si ceux de base sont proposé par Angular ? 🤔
Et bien pour deux raisons :
Jest est vraisemblablement plus rapide que ses concurrents pour effectuer ses tests, car ils peuvent s’exécuter en parallèle. Vous gagnez donc au change, au fil du temps que votre application se développe.
La seconde est que même si on créer à première vu un site web, il a néanmoins pour but d’être utilisé sous forme d’application bureautique via Electron. Les framework de test cité plus haut sont formidable pour tester des sites web. Cependant, comme on fait appel à des fonctions de l’API de Electron, on ne peut ouvrir notre application Electron convenablement sur notre navigateur favori. Ceux-ci ne vont donc être utile que vous du test unitaire, mais on peut dors et déjà oublier les tests e2e. C’est pour cela que Spectron est idéal, puisque développé pour tester des applications conçu sous Electron.
Donne la couverture de code couvert par les tests
Pas besoin d’un navigateur web pour exécuter les tests, tout se fait depuis la console
Réalisation de ‘snapshot’, afin d’assurer que l’on ait pas de régression d’un point de vue UI
Jest
C’est le moteur de test développé par Facebook. Pratique, car tourne sur Angular, React, Vue.
Spectron
C’est un wrapper qui embarque à la fois Selenium, et WebDriverIO.
Selenium est un framework de test, qui permet de réaliser des opérations sur le navigateur web.
WebDriverIO quant à lui, est un autre framework de test qui reprend l’API de Selenium de façon customisé, écrit en javascript et exploitable par NodeJS. Il va ainsi ajouter des fonctionnalités de binding. On va pouvoir réaliser des opérations de click de souris sur des éléments, récupérer des champs de valeur, naviguer dans notre application, etc. Concrètement, on va pouvoir reproduire une utilisation du logiciel par un vrai utilisateur, mais en ligne de code.
Spectron, enfin, va ajouter des fonctionnalités pour avoir accès à l’ensemble de l’API de Electron
Optionnel : bibliothèque d’assertions
Lorsque on effectue des tests, on compare un état souhaité, avec l’état réellement obtenue lors de l’utilisation de l’application. J’utilise la librairie de base de NodeJS, à savoir assert. Simple et facile d’utilisation. Mais il est vrai que certains préférerons d’utiliser des styles d’écriture BDD ou TDD. Chai est une librairie que je recommande, qui permet de faire cela, tout en poussant les fonctionnalités de comparaison pour avoir des tests encore plus poussé.
Exemple de style que vous pouvez rencontrez, pour faire une comparaison de base :
Should : foo.should.equal(‘bar’);
Expect : expect(foo).to.equal(‘bar’);
Assert : assert.equal(foo, ‘bar’);
Spectron & Jest : utilisation
Installation
On commence par installer les modules nécessaire, en dépendance de développement via le gestionnaire de packets NPM :
Jest : npm install –save-dev jest
Auto complétion Jest : npm install –save-dev @types/jest
Spectron : npm install –save-dev spectron
/!\ Attention /!\
Veillez à bien respecter les versions entre Electron et Spectron, ou vous risquez d’avoir des soucis de compatibilité :
Electron Version
Spectron Version
~1.0.0
~3.0.0
~1.1.0
~3.1.0
~1.2.0
~3.2.0
~1.3.0
~3.3.0
~1.4.0
~3.4.0
~1.5.0
~3.5.0
~1.6.0
~3.6.0
~1.7.0
~3.7.0
~1.8.0
~3.8.0
^2.0.0
^4.0.0
^3.0.0
^5.0.0
^4.0.0
^6.0.0
^5.0.0
^7.0.0
^6.0.0
^8.0.0
^7.0.0
^9.0.0
^8.0.0
^10.0.0
Configuration
On va créer un fichier de configuration pour jest, jest.config.json, à la racine de notre projet :
testMatch : définit une regexp pour matcher le nom des fichiers de tests. Ici, on garde les fichiers dans le dossier /e2e/, et qui contient le mot .e2e. ou .unit. et qui est un fichier TS ou JS
Ensuite, on va ajouter un nouveau script pour automatiser le lancement de nos tests, dans notre fichier package.json :
config : pour renseigner la configuration crée précédent
runInBand : lancer les tests de façon séquentiel
detectOpenHandles : autorise Jest à fermer une session d’un test automatiquement si celui-ci ne se termine pas correctement, afin de continuer les tests
Squelette de base d’un test
Voici le template de base pour réaliser un test :
describe : c’est le mot clé pour définir un groupe de test
beforeEach : permet de retourner une application lancé a chaque début de test
afterEach : permet de fermer notre application une fois un test exécuté
it : mot clé pour définir un test
Vous pouvez observer la mise en place d’un timeout par Jest, mais aussi dans la définition de notre application. Cela permet de laisser un peu de temps à notre application pour s’ouvrir, avant de pouvoir l’utiliser.
L’ensemble des interactions possible via WebDriverIO sont disponible sur leur page de leur API.
Le code est exécuté de façon asynchrone. Vous allez donc devoir les rédiger soit en utilisant async/await, ou en utilisant des promesses. Chacun ses préférences, même si je trouve le code avec des async/await bien plus lisible et compréhensible.
Exemple de test
Je vous donne quelques exemple de tests simples, pour vous donnez des idées. Vous verrez les tests les plus simple à savoir cliquer sur des bouttons, récupérer des valeurs de champs de texte, accéder à l’API de Electron…
Vérifier que les outils de développement de Chronium ne sont pas ouvert
Lire le contenu d’un champ texte
Vérifier la navigation entre module et composant
Tester l’application en plein écran
Conclusion
Spectron est la librairie officiel pour tester des applications sous Electron.
Nous avons vu précédemment comment build et package l’ensemble de notre application en un .exe ou un installateur, si on souhaite le distribuer dans le chapitre précédent.
Je pensais avoir déjà fait un rapide tour d’Electron en 6 chapitres, mais à force de l’utiliser je pense pouvoir ajouter quelques chapitres supplémentaires qui pourrait bien vous servir et faciliter le développement autour de ce génial framework.
Objectif
Diviser les fonctionnalités de notre unique fichier du backend (main.js) en une multitude de fichiers
Permettre d’écrire le backend en Typescript et plus Javascript via un transpileur (TSC)
Pouvoir transpiler en instantané ( hot reload )
Le code source concernant ce chapitre est disponible sur mon Github.
Passage du Javascript vers le Typescript
Pour le moment, nous avons l’ensemble de notre application du frontend écrit via Angular en Typescript, mais le backend en Javascript. Il faut dire que le TS apporte beaucoup au JS traditionnel, et c’est pour cela que j’ai décider de migrer le backend. Il faut savoir que seul le pure javascript est compréhensible de nos navigateurs.
Comment Angular peut-il alors faire du frontend alors que l’on écrit notre application en TS ? 🤔🤔
De façon invisible, nous avons Webpack, planqué dans Angular, qui nous créer notre bundle en effectuant une multitude de transformation de nos fichiers, donc une que l’on va voir maintenant, est qui est la phase de transpilation. Celui-ci va transpiler l’ensemble de nos fichiers TS. Un mot bien complexe qui n’est rien d’autre que la conversion des fichiers TS en JS.
Script NPM pour la transpilation du typescript
Je suis parti sur TSC, qui est le transpiler de base de Typescript, car il est très simple d’utilisation, pas besoin de s’embêter avec un tas de paramétrage pour transpiler deux pauvres fichiers TS. Si vous souhaitez vous lancer dans des utilisations plus poussés, renseignez vous auprès de Webpack ou encore Babel.
On ajoute premièrement à notre package-json un nouveau script pour nous permettre d’appeler TSC :
backend-serve : nom du script
–project : argument pour fournir un fichier json de description pour le transpiler
–watch : argument pour compiler à la volé, dès qu’une sauvegarde de code est détecté
Si vous souhaitez transpiler seulement une fois sans avoir besoin du rechargement à la demande, vous pouvez supprimer l’argument ‘–watch’.
Une fois le script ajouté, on va créer un nouveau fichier comme vous avez pu le lire précédemment, tsconfig.backend.json, qui va nous permettre de décrire comment nous souhaitons transpiler nos fichiers TS.
Les arguments les plus importants sont :
include : on liste ici l’ensemble des fichiers TS que l’on souhaite transpiler
baseUrl : décrit la base du projet. On s’en servira plus tard lorsque je parlerais d’import de module en absolue ou relatif.
Ré-écrire son Main.js en typescript
Le but va être de ré-écrire son fichier d’entrée de notre application Electron, Main.js, en une version typescripté. Ouais je sais que ce mot existe pas, et alors c’est mon blog !😋
On va copier notre fichier Main.js et en faire un nouveau Main.ts. Vous risquez d’avoir quelques erreurs de lancé par votre linter, rien de bien complexe à modifier, vous devriez vous en sortir sans grand soucis. Un exemple dont vous pouvez avoir est la façon dont vous devez importer vos modules.
Je vais néanmoins quand même vous accompagner pour vos premières classes, car vous risquez d’avoir un petit soucis 😜
Architecture du backend
Jusqu’à présent nous n’avions qu’un seul fichier pour le backend, pour la gestion du cycle de vie de notre application. Au fur et à mesure des fonctionnalités que vous allez ajouter au backend, il se peut que vous souhaitiez éclater ce fichier ‘main.js’ en une multitude d’autres afin d’avoir une plus fine granularité, et ainsi d’améliorer l’extensibilité du code dans le futur. Je vous propose de suivre l’architecture suivante :
On va ajouter les deux classes suivantes :
StorageManager : on va lui déléguer l’ensemble des fonctionnalités de Main.js qui touche l’ensemble des serialization des données du module electron-store
CommunicationManager : on va lui déléguer l’ensemble des fonctionnalités de Main.js qui touche à l’échange d’informations entre le render et le main process, soit l’ensemble des fonctions du module IPC.
Erreur du loader/resolveFilename
Vous avez enfin une belle architecture, écrite en TS, et vous avez TSC de configuré. Aucune erreur sur l’ensemble de vos consoles, super, vous pouvez lancer Electron… et BIM ! Une belle erreur devrait apparaître, comme quoi vos nouveaux composants fraîchement crées ne sont pas trouvable 😒. Tsc étant un transpiler simple, il ne fait pas la liaison entre les composants lorsque on utile des imports absolue. Cependant si vous utilisez des importation de module avec des liens relatifs, vous n’aurez pas de soucis. Cependant, l’écriture de ces imports rend leur lecture complexe, en voici un exemple :
import * as test from ‘../../../../../../monModule’;
Mais pourquoi la console de TSC ne m’a pas indiqué d’erreur lors de la transpilation, mais seulement au moment de lancer Electron ? Car nous l’avons paramétré dans le fichier tsconfig.backend.json, avec l’argument ‘baseURL’ souvenez vous.
Si j’ai fais ce tutoriel avec TSC, c’est qu’il existe néanmoins des solutions, même si je vous avoue m’être bien cassé la tête sur ce problème. Pour résoudre ce soucis de chemin dans les require, vous avez deux petits modules à la rescousse disponible sur NPM.
Méthode 1 – La plus simple & basique
Son principe est simple, il va ajouter le répertoire parent de plus haut niveau dans le module de recherche de chemin de Node.
Il suffit d’installer le module suivant :
npm install app-module-path –save
C’est la méthode la plus simple, car il suffit d’ajouter une seule ligne de code, au début de notre fichier main.ts :
Pratique, car fonctionne lors du build, mais aussi en mode hot-reload durant le développement.
Cependant, si vous souhaitez seulement tester un fichier en particulier, une classe par example, et donc ne pas lancer votre application entière via le main.ts (faire simple un => node maclasse.js), cela ne fonctionnera pas car ayant ajouté le code précédent dans le main.ts, celui-ci ne sera pas lu. Pour cela vous êtes soit obligé de toujours lancer le main.ts depuis node pour que l’ensemble des imports soient modifiés, soit ajouter ce code dans l’ensemble des classes, ce qui peut vite devenir lassant. C’est pour cette raison là que je vous conseille la méthode 2.
Méthode 2 (recommandé) – Un poil plus complexe, mais plus flexible
Un second module vient à notre rescousse mais se comporte tout autrement. En effet, il va aller modifier les imports absolue de chaque fichier pour les remplacer par des liens absolue lors du build, dans les fichiers transpilé .js. Terriblement efficace, et pas bien plus complexe en ne nécessitant qu’une petite étape supplémentaire de configuration.
On installe ce module via:
npm install ttypescript --save
npm install @zerollup/ts-transform-paths --save
Héhé, je vous en fait installer un second en cachette car nous allons avoir besoin d’un wrapper, ttypescript, qui va nous permettre d’utiliser des plugins de transformation qui sont supporté dans notre fichier de configuration des options de compilation, disponible dans le fichier tsconfig.json.
Premièrement, on va modifier notre script NPM du fichier package.json de tout à l’heure pour qu’il utilise ttypescript que l’on vient d’installer :
On va ensuite modifier notre fichier de configuration qui permet de transpiler le backend, tsconfig.backend.json, afin de lui ajouter notre transformateur dans l’option ‘plugin’ pour qu’il puisse ré-écrire les imports :
Et on lui dit dans l’argument ‘paths’ de récupérer tout les fichiers à la base du projet et de les importer tel quel.
C’est finit, vous n’avez plus qu’a builder le backend depuis la console, avec notre script npm via la commande :
npm run backend-serve
Pour tester si tout fonctionne lancer le serveur de développement Angular avec:
npm run angular-serve
Ainsi que electron via :
npm run electron-serve
Mise à jour de la configuration du build
Afin de pouvoir continuer à builder, packager et distribuer votre application avec le module electron-builder, n’oubliez pas de modifier votre configuration de build disponible dans le fichier electron-builder.json ( ou dans votre package.json si vous n’avez pas dissocié les fichiers de configuration ). En effet, venant de modifier le backend en une multitude de nouveau fichiers TS et JS, nous devons mettre à jour notre configuration afin que celle-ci les prennes en compte dans le packaging de l’application. Pour cela, on va ajouter un nouvel item dans l’argument ‘files’, afin d’ajouter nos fichiers javascript précédemment transpilé :
Conclusion
On vient de voir la façon la plus simple pour pouvoir transpiler son backend Electron via TSC et un transformateur, pour résoudre les liens des imports absolue en relatif. Cela va nous permettre d’utiliser le typage et ainsi d’avoir un code source plus rigoureux grâce à Typescript.