Rendre la smartwatch autonome

Mockups de l’application web

Comme pour les deux applications précédentes les mockups complets sont disponible à l’Annexe IV. Selon le descriptif du travail de TB. Il est prévu d’utiliser Firebase. Cette plateforme de Google offre plusieurs services :

• Base de données

• Système d’authentification des utilisateurs

• Gestion des notifications

• Prise en charge des tests unitaires et des tests d’instrumentations

• Etc.

Effectivement dans l’idée de rendre un prototype fonctionnel, il est vrai que Firebase est particulièrement bien adapté. Néanmoins la question de la sécurisation des données personnelles reste un point sensible. En particulier, dans cette période où le RGPD entre en vigueur dans l’Union Européenne le 25 mai 2018 (Seydtaghia, 2018). En second lieu, nous ne maîtrisons pas l’emplacement géographique des serveurs de Firebase. Cela a plusieurs conséquences mais nous relevons en particulier celle-ci : Perte de contrôle sur les données. L’interconnexion mondiale et l’utilisation de la mémoire virtuelle font qu’il est souvent impossible de localiser les données, notamment lorsqu’on a recours à des nuages publics. Le maître des données ne sait donc pas où les données qu’il a déposées dans le nuage sont enregistrées et traitées alors qu’il répond de leur utilisation. Il ignore souvent si des sous-traitants interviennent et s’ils veillent à une protection adéquate des données. L’utilisateur d’un nuage ne peut donc pas assumer ses obligations en matière de protection des données (garantir la sécurité des données, accorder un droit d’accès, corriger ou effacer des données) ou uniquement en partie. (Préposé fédéral à la protection des données et à la transparence (PFPDT), s.d.)

Tests d’instrumentations

De plus, notre volonté d’implémenter des tests d’instrumentations, nous amène à utiliser le Framework « Espresso » de Google. La mise en place est simple et correctement documentée6. Nous perfectionnons notre apprentissage avec YouTube sur la chaine de QA-Automated 7 Le principe d’Espresso est de manipuler l’interface graphique. Une méthode « onView » permet d’accéder aux objets des « Layouts8 ». Une fois l’objet désiré atteint, il est possible d’interagir avec celui-ci grâce à la méthode « perform ». Exemple avec le champ du mot de passe. Dans la gestion des tests, la notion de tâche asynchrone ou multithread nécessite l’implémentation d’une classe d’attente « IdlingResource ». C’est notamment le cas pour le processus d’authentification. D’ailleurs nous déployons les tests uniquement sur ce processus, durant la phase de faisabilité. Finalement, ce travail sur les tests d’instrumentations donne plusieurs rapports de résultats. Cela va du simple booléen « passé » ou « échec », jusqu’à l’analyse complète de la couverture du code fourni, rapport fourni par « Jacoco » Comme introduit dans le chapitre 5.4, nous exploitons le module « Tests Lab » de Firebase. L’objectif étant de tester notre application sur plusieurs périphériques, eux-mêmes installés avec des versions d’Android différentes. On peut simuler également les orientations et le choix des paramètres régionaux. Finalement on obtient un rapport détaillé du test. En particulier, la consommation de la mémoire, de la batterie et du CPU. Toutes ces données sont visibles sur la « timeline » de la vidéo des tests (cf. Figure 22).

Conclusion de la phase de faisabilité

Cette analyse sur la faisabilité correspond à la US N°4 du sprint N°1. Lors du « Sprint Review » le résultat de l’entier du prototype est validé. Toutefois une interrogation subsiste : comment s’identifier à la plateforme de Firebase avec la smartwatch ? Le fait de coupler la smartwatch avec le téléphone permettrait de saisir les données de connexion directement depuis le smartphone et ainsi connecter les deux appareils. Cette solution ne satisfait pas entièrement notre client. Car cela restreint l’accès à « Smartphysio9 » uniquement aux possesseurs de smartphone Android. Pour un cabinet de physiothérapie, l’idéal serait de prêter une smartwatch autonome, sur laquelle on installe l’application. Ainsi on ne connecte le compte du patient qu’une seule fois lors de la livraison. Nous acceptons ce nouveau « use case » et nous planifions la US correspondante pour le prochain sprint. Le sprint N°2 est composé de plusieurs US. Mais rendre la smartwatch 100 % autonome modifie notre modèle. En effet nous ne devons plus envisager une application mobile Android composée de deux modules « watch » et « phone ». Mais bien de deux applications indépendantes. Cela rend toujours possible le partage de librairie commune, comme « smartphysiolibrary » décrit dans le chapitre 5.1. Cependant nous ne pouvons pas utiliser le smartphone pour s’identifier à Firebase via les « DataLayer »10 par exemple.

Conclusion

L’utilisation de la smartwatch est particulièrement bien adaptée à ce genre de besoins. Cependant l’ergonomie est une composante fondamentale dans ce type d’interface. Tout d’abord parce que l’écran est relativement petit, mais aussi parce qu’effectuer une tâche doit être aussi simple que possible. Finalement, malgré deux limitations majeures de Wear OS, qui sont :

• Pas d’authentification possible à Firebase en mode autonome

• « Web view » non prise en charge pour la connexion à Pryv,

Nous avons développé une application fonctionnelle et aussi ergonomique. Entre deux et quatre « clics » sont nécessaires pour sauvegarder un niveau de douleur. Du côté du smartphone, nous n’avons pas rencontré de problèmes particuliers. C’était également le périphérique sur lequel il y avait le moins de travail. Actuellement, si le patient est sous Android il peut grâce à son smartphone modifier un niveau de douleur et y ajouter un complément sous forme de texte. La troisième application est dédiée au physiothérapeute. Elle est développée en React (une bibliothèque Javascript). Elle permet de gérer des patients, d’analyser des statistiques et de créer des listes d’activités. La majorité des problèmes rencontrés dans ce développement étaient probablement liés à l’apprentissage des subtilités de Javascript. Ces trois applications « front-end » sont liées à un service de base de données cloud nommé Pryv. C’est un produit Suisse qui stocke les données en Suisse (mais également en France et aux USA). La documentation disponible en ligne est très complète. De plus la protection des données est l’une de leurs priorités en particulier dans le domaine médical. A titre personnel, ce travail m’a permis de regrouper toutes (ou presque) les connaissances acquises durant cette formation de quatre ans. Cela va de la gestion de projet à l’industrialisation en passant par les algorithmes, l’expérience utilisateur ou encore la communication.

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 chatpfe.com propose le téléchargement des modèles complet 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

Résumé
Avant-propos
Remerciements
Table des matières
Liste des figures
Liste des tableaux
Liste des abréviations
Introduction
1 Présentation générale du besoin
1.1. Problématique
1.2. L’idée principale côté patient
1.2.1. D’autres concepts
1.3. L’idée principale côté physiothérapeute
1.4. Technologies
1.4.1. Front-end, Mobile et Web
1.4.2. Stockage
2 Déroulement du projet
2.1. Les étapes
3 Use cases & Mockups
3.1. Définir un cadre
3.1.1. Ergonomie de Wear OS
3.1.2. L’échelle de douleur
3.1.3. Choix de l’échelle de douleur
3.2. Use cases : patient
3.2.1. Smartwatch
3.2.2. Smartphone
3.3. Use cases : physiothérapeute
3.4. Le « Product backlog »
3.5. Mockups
3.5.1. Mockups smartwatch
3.5.2. Mockups smartphone
3.5.3. Mockups de l’application web
4 Analyse des systèmes de base de données
4.1. Realtime Database ou Cloud Firestore
4.1.1. Tableau comparatif
4.1.2. Conclusion
5 Architecture et mise en place de l’environnement de travail
5.1. Langage de développement des applications mobiles
5.2. Langage de développement de la web App
5.2.1. React
5.3. VCS avec Gitlab
5.4. Tests lab avec Firebase
5.5. Liste des applications utilisées
6 Faisabilité
6.1. Paramétrage de Firebase
6.2. Connexion de Firebase au projet Android
6.3. Premier prototype de la smartwatch
6.4. Premier prototype du smartphone
6.4.1. Tests d’instrumentations
6.4.2. Résultat du prototype
6.5. Prototype de l’application web
6.5.1. Création du projet
6.5.2. Connexion de Firebase à notre projet React
6.5.3. Développement du prototype WebApp
6.5.4. Résultat du prototype de la Web App
6.6. Conclusion de la phase de faisabilité
7 Rendre la smartwatch autonome
7.1. Analyse des possibilités de connexion
7.2. Compatibilité smartwatch avec Firebase
7.3. Proposition de solutions
7.4. Décisions et erreurs
7.5. Présentation du serveur API
7.5.1. Côté serveur
7.5.2. Côté smartwatch
7.6. Fin du sprint N°2
8 Implémentation de Pryv
8.1. Pryv en bref
8.1.1. Les données dans Pryv
8.1.2. Structures des données
8.1.3. Les Streams
8.1.4. Les Events
8.1.5. Compte utilisateur (patient)
8.2. Gestion des autorisations dans Pryv
8.3. Structuration des données dans Pryv
8.3.1. Côté patient
8.3.2. Côté physiothérapeute
9 Développement du sprint N°3
9.1. Connexion de la Web App (US : 88)
9.2. Connexion avec le smartphone (US : 85)
9.3. Connexion avec la smartwatch (US : 82)
9.3.1. Premier processus de connexion avec une smartwatch
9.3.2. Conclusion sur le processus de connexion d’une smartwatch
9.4. Ajout de patient dans la WebApp (US : 75)
9.4.1. Partager un « slice » dans Pryv
9.4.2. Comparaison des deux méthodes d’obtention des tokens
9.5. Fin du sprint N°3
10 Sprint N°4 : Consolidation et ergonomie
10.1. Gestion des activités sur la smartwatch
10.1.1. Récupération des activités publiques
10.1.2. Gestion des activités favorites dans la smartwatch
10.2. Liste des patients dans la WebApp
10.3. Affichage des statistiques par patient
10.4. Création des activités
10.5. Consolidation et utilisation de Redux
10.6. Architecture de notre application React
10.7. Sprint Review N°4
11 Sprint N°5 : Finalisation du prototype
11.1. Améliorer l’obtention des tokens (US : 155)
11.2. Moyenne mobile
12 Améliorations
12.1. Connecté à internet ?
12.2. Multi langue
12.3. Gestion publique des catégories et des activités
12.4. Obtention des tokens « follow & show watch token »
12.5. Moyenne mobile, choix des valeurs successives
12.6. Exportation depuis le graphique avec les données de texte
12.7. Smartphone iOS
13 Smartphysio en libre accès
Conclusion
Références
Annexe I : Product Backlog
Annexe I (suite) : Product Backlog
Annexe II : Mockups de la smartwatch Jacques Herren
Annexe III : Mockups du smartphone
Annexe IV : Mockups de l’application web
Annexe IV (suite) : Mockups de l’application web
Annexe V : Google-service.json
Annexe VI : firebase.js
Annexe VII : ModelUser.js
Annexe VIII : Réponse http du serveur REST lors de l’authentification
Annexe IX : Gestion des accès dans Pryv
Annexe X : Création de la structure des Streams du patient
Annexe XI : ApiRequest.js
Annexe XII : Générateur de tokens pour Pryv
Annexe XIII : Accès à la Web App Smartphysio
Annexe XIV : Installer Smartphysio sur une smartwatch
Déclaration de l’auteur