Comparaison des Frameworks

Etude des Frameworks existants

Le marché actuel propose un certain nombre de Frameworks différents permettant de créer des applications mobiles. La plupart sont « cross-platform », c’est-à-dire qu’ils offrent la possibilité de créer un seul projet qui peut ensuite être utilisé sur plusieurs systèmes d’exploitation mobiles (IOS et Android, le plus souvent). Pour permettre le système « cross-platform », ces Frameworks n’utilisent pas le langage natif du téléphone (Java pour Android et Objective-C pour IOS) car il serait alors nécessaire de créer un projet pour chaque langage de programmation et donc pour chaque système d’exploitation mobile. Ils utilisent alors un langage différent des langages natifs (souvent Javascript pour la partie logique et HTML pour la partie visuel). Ces langages ne sont pas compris par les téléphones mobiles et doivent être exécutés dans un environnement spécifique : le « Runtime Environnement ». Ces environnements encapsulent les projets « cross-platform » dans une « boîte » qui comprend le langage du Framework. Cette boîte offre des entrées et des sorties permettant ensuite au Framework de communiquer directement avec les composants du téléphone (RAM, CPU, GPU, etc.).

L’environnement de runtime peut différer selon les Frameworks. La partie visuelle, quant à elle, est le plus souvent affichée dans une WebView. Cette dernière est une fenêtre prenant toute la place de l’écran et qui comprend les langages Web (HTML / CSS). Cette dernière est affichée à l’écran et la partie visuelle de l’application est, par la suite, « collée » sur cette WebView. Chaque langage possède son propre environnement de runtime. La WebView, quant à elle, est propre à chaque système d’exploitation mobile. Chaque plateforme propose nativement une WebView différente, laquelle est plus ou moins performante. Il faut faire attention à bien vérifier si les fonctionnalités visuelles misent en place sont compatibles avec la WebView native du système d’exploitation cible. Comme expliqué précédemment, il existe un grand nombre de Frameworks différents offrant la possibilité de créer une application « cross-platform ». Pour définir lequel est le plus adapté à la création d’une application d’échange de places de parking, je vais expliquer les avantages et les désavantages des trois Frameworks les plus connus et utilisés. Pour faire ce choix, je me suis basé sur un sondage réalisé par le site internet « Stack Overflow » (Stack Overflow, 2018).

Angular Angular est un Framework offrant la possibilité de créer des pages WEB et des applications mobiles de manière simplifiée grâce à des systèmes de déclaration de modèles, d’injection de dépendances et de binding de données. Angular va relier de manière simplifiée les données de la partie logique à l’affichage et inversement. On peut voir sur ce schéma le fonctionnement d’Angular. Chaque objet logique du site Web ou de l’application mobile (page, liste, bouton personnalisé, etc.) va être enregistré en tant que « composant ». Un composant désigne la partie logique de l’objet et est donc relié à un modèle écrit en HTML / CSS (l’interface affichée à l’utilisateur).

Cette liaison offre la possibilité de faire du « Property Binding » et de « l’Event Binding ». Le Property Binding permet de mettre à jour automatiquement les données de notre application. C’est-à-dire qu’au moment où une donnée est affichée sur le modèle et que la valeur de la variable représentant cette donnée change dans le composant, l’affichage de cette donnée va automatiquement être mise à jour dans le modèle. Ce système fonctionne aussi en sens inverse. Lorsque l’utilisateur va écrire du texte dans un champ, il est possible d’enregistrer son contenu, en temps réel, dans une variable du composant. L’Event Binding permet, quant à lui, le déclenchement automatique d’une méthode du composant lorsque l’utilisateur va faire une action sur le template (appuyer sur un bouton par exemple). Angular propose aussi un système d’injection de dépendance. Cela permet d’ajouter dans un composant un lien sur un autre composant ou un autre service (Accéléromètre, Network, etc.) afin d’accéder aux données et méthodes de ce dernier.

Architecture Comme expliqué précédemment, Xamarin offre la possibilité de créer un seul code logique et une ou plusieurs interfaces utilisateurs. L’image ci-contre représente la structure simplifiée d’une application Xamarin. Toute la partie logique et les accès aux composants natifs du téléphone se trouvent dans un bloc de code partagé et unique pour toutes les plateformes. Le seul code non partagé est le design de l’interface, pour autant qu’il ne soit pas créé avec Xamarin.Forms. (Altexsoft, 2018b) Les interfaces sont créées dans le langage XAML qui est une extension du langage XML. XAML permet l’intégration aux balises XML de commandes associées à des propriétés logiques. Ce système va fonctionner exactement de la même manière qu’Angular avec le binding de données. (Xaml.fr, 2012) Tout comme pour Ionic, les systèmes d’exploitation mobiles ne comprennent pas le langage C# et doivent donc avoir un environnement de runtime spécifique. Étant donné que ces plateformes n’ont pas cet environnement de manière native, Xamarin a pris la décision de l’ajouter dans le code source de l’application. De cette manière, quel que soit le système d’exploitation mobile sur lequel est lancée l’application, elle pourra fonctionner.

Le schéma ci-dessous représente l’architecture complète d’une application Xamarin, incluant l’environnement de runtime, le code partagé et les interfaces utilisateurs. En créant des interfaces utilisateur différenciées pour chaque plateforme cible, ses composants vont être natifs. Le seul code non natif sera alors celui partagé en C# qui tourne dans son propre environnement de runtime créé pour avoir des performances maximales. Si l’on décide d’utiliser Xamarin.Forms, l’interface utilisateur ne sera alors plus composée de composants natifs et perdra alors grandement en performance. Il sera néanmoins

Fonctionnement de l’API

Laravel est un Framework de développement WEB entièrement constitué en PHP. Il se base sur « composer » (https://getcomposer.org/) pour gérer ses dépendances. Laravel offre de multiples fonctionnalités, telles que le routage de requêtes, le mapping d’objets relationnels, l’authentification, la migration de base de données, la gestion des exceptions, les tests unitaires et l’affichage de page HTML (dans le format propriétaire Blade). Ce Framework est très complet et permet la création d’un site WEB comme d’une API complexe. Il est donc possible de créer un site WEB et une API tournant sur le même serveur et utilisant la même base de données. Le Framework est très bien conçu puisqu’il est séparé en plusieurs sous-dossiers ayant chacun un objectif bien défini (un pour la gestion de la base de données, un pour la gestion des vues, un pour la configuration du Framework, etc.). Il est très facile de se familiariser avec ce Framework et de le prendre en main.

Pour la gestion de l’accès à la base de données, Laravel a mis en place un système de modèle éloquent, qui est directement connecté à la bonne table dans la base de données. Il n’est donc pas nécessaire de créer soi-même les requêtes SQL. Il suffit de générer un objet « modèle » pour qu’il s’enregistre automatiquement dans la base de données. De même lorsque l’on veut récupérer des données dans la base de données, il est possible de faire des recherches directement via l’objet correspondant. Les données seront alors retournées sous la forme d’un tableau d’objet « modèle ». En ce qui concerne l’authentification, Laravel propose un système appelé « Passport ». Ce package permet de faire de l’authentification OAuth2 de manière simplifiée et très rapide. Pour sécuriser une route, il suffit de la placer dans le middleware « auth:api ». Lors de la connexion à l’API, Laravel créer un « access token » et l’enregistre dans la base de donnée. Ce token est ensuite fourni à l’utilisateur. Lorsque l’utilisateur essaye ensuite d’accéder à une route qui se trouve dans le middleware « auth:api », il devra ajouter dans sa requête le header « Authorization » et y mettre dedans le token recu précédemment. Le middleware vérifiera si le token fournit dans la requête correspond à un utilisateur et si ce n’est pas le cas, répondra avec une erreur 401, Unauthorized. Pour mettre son application Laravel en déploiement, il suffit de copier tous les dossiers et fichiers sur son serveur et de faire pointer son « sous-domaine » sur le dossier « public » de Laravel.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Déclaration
Remerciements
Résumé
Liste des tableaux
Liste des figures
1. Introduction
2. Etude des Frameworks existants
2.1 Ionic
2.1.1 Architecture
2.1.1.1 Apache Cordova
2.1.1.2 Angular
2.1.1.3 Ionic
2.1.2 Avantages
2.1.3 Faiblesses
2.2 Xamarin
2.2.1 Architecture
2.2.2 Avantages
2.2.3 Faiblesses
2.3 React Native
2.3.1 Architecture
2.3.2 Avantages
2.3.3 Faiblesses
2.4 Comparaison des Frameworks
2.4.1 Comparaison
2.4.2 Résumé
3. Etude de l’application
3.1 Fonctionnalités de l’application
3.2 Besoins techniques de l’application
4. Choix du Framework
4.1 Analyse détaillée du choix
4.2 Concordance avec l’application
5. Implémentation de l’application
5.1 Use-case
5.2 Modèle de données
5.3 Choix du système back-end
5.3.1 Les routes de l’API
5.3.2 Fonctionnement de l’API
6. Développement de l’application
6.1 Apprentissage du Framework
6.2 Environnement de développement
7. Rapport de test
8. Conclusion
Bibliographie