# Développement d'une application mobile hybride pour le recueil de données sur le terrain

Naima N. Dambrine

► To cite this version:

Naima N. Dambrine. Développement d'une application mobile hybride pour le recueil de données sur le terrain. Cahier des Techniques de l'INRA, 2019, 98, pp.17. hal-02624708

HAL Id: hal-02624708

https://hal.inrae.fr/hal-02624708v1

Submitted on 30 Jul 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY-SA 4.0 - Attribution - ShareAlike - International
License
# Développement d'une application mobile hybride pour le recueil de données sur le terrain

Naïma Dambrine<fnref n="1" />

**Résumé.** Quelque soit le thème de recherche et le projet d'étude abordé, les données de recherche, issues de l'observation, de l'expérimentation ou dérivées de sources existantes sont une part importante des travaux de recherche. Dans ce cadre, je présenterai une application mobile hybride capable de recueillir les données sur le terrain. Les données stockées localement sur l'appareil seront envoyées vers un serveur une fois la connexion internet rétablie. Le système est bâti sur un ensemble de technologie opérant ensemble dans une relation client-serveur. Sur la partie serveur sont hébergés la base de données et les web services, la partie cliente est l'application mobile.

**Mots clés** : Architecture n-tiers, base de données, Web Service, application mobile hybride

**Abstract.** Whatever the research problem or study project is, research data from observations, experiments or derived from existing sources are an important part of scientific research. In this scope, we will present an hybrid mobile application able to collect data in the field. Data stored locally on the application are sent towards a server once connected through internet. The system is then based on a client-server technology operating together. The server hosts database and web-services whereas the client party is the mobile application.

**Keywords** : n-third party architecture, database, web service, hybrid mobile application

<footnote n="1">¹ INRAE, UMR Epi-a, Vetagro-sup Lyon, France. Naima.dambrine@inrae.fr</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 1. Développement d'une application mobile hybride pour le recueil de données sur le terrain</figcaption></figure>

## Introduction

Dans de nombreux laboratoires, des agents récoltent des données sur le terrain et les intègrent dans des bases de données, pas toujours de manière uniforme et souvent en multipliant les saisies. On peut simplifier et sécuriser cette phase à l'aide de saisie sur tablette pour une intégration directe en base de données.

Afin d'illustrer mon propos, j'exploiterai le cas d'une étude portant sur les tiques et le climat comme indicateur de prédiction sur l'abondance des tiques.

Des campagnes mensuelles de collecte et d'échantillonnage de tiques sont orchestrées sur plusieurs sites en France.

Voici la liste, pour chaque site, des tâches mensuelles effectuées pour la collecte.

1. Saisir sur le terrain les données observées à l'aide d'une trame papier,

2. Scanner et envoyer par mail la trame saisie au centre Inra qui centralise le recueil des données,

3. Une personne ressource saisit chaque scan reçu dans un fichier Excel,

4. Le fichier Excel est repris dans une base de données Access par le doctorant travaillant sur le projet,
# Le Cahier des Techniques de l'Inra 2020 (98)

5. La base de données Access est mise à jour au fil de l'eau et constitue la base d'échange entre les chercheurs.

## Constat

On peut aisément déterminer les points faibles d'une telle organisation :

* risque d'erreur accru puisque une même donnée est saisie plusieurs fois par différentes personnes ;

* création d'un goulot d'étranglement au niveau du centre Inra centralisateur puisqu'une seule personne ressource est affectée à la saisie de toutes les fiches terrain pour tous les sites ;

* l'emploi d'une base de données Access ne permet pas le partage et il faut « s'envoyer la dernière version à jour », cela entraîne là aussi une lourdeur et le risque de se tromper de version.

## Proposition

Notre objectif dans le cas présent est de supprimer toutes les étapes mentionnées ci-dessus en développant une application mobile qui aura la charge de récolter les données sur le terrain en mode offline, c'est-à-dire, sans couverture réseau puisque les données seront stockées dans l'appareil. Au retour d'un signal internet, les données pourront être envoyées sur le serveur de données.

## Méthodes

Plusieurs technologies sont mises en œuvre dans ce projet et forment un environnement permettant à l'application de fonctionner. Ces concepts de base sont expliqués en soulignant les aspects directement couverts dans ce travail.

## Qu'est-ce qu'une application mobile hybride ?

L'ensemble des applications mobile peut être classé en trois catégories : web, hybride et native.

Les applications web utilisent du code web, HTML, CSS et JAVASCRIPT et les applications natives utilisent un langage natif ciblant un appareil ou un système spécifique, Objective C pour iOS, Java pour Android par exemple.

Une application hybride est une combinaison des deux approches.

Evidemment, les applications web peuvent être exécutées depuis n'importe quel navigateur (sur PC, tablette ou mobile). Cependant, lorsqu'il s'agit de mobile, les applications natives offrent des fonctionnalités que les applications web n'ont pas, comme :

- la possibilité d'être distribuée en ligne depuis les stores Apple et Google

- la possibilité d'accéder aux API natives de l'appareil (Wifi, GPS ou camera)

L'inconvénient majeur est qu'il faudra utiliser pour chaque type de mobile (plateforme) un langage dédié.
C'est ici qu'entre en jeu l'intérêt d'une application hybride : un seul langage pour toutes les plateformes. Cela est rendu possible grâce aux Framework Cordova ou Capacitor, ces API vont envelopper l'application dans un Shell natif (une Webview) et agir comme une passerelle entre l'application et l'appareil.

<figure><img src="image_3.png" /><figcaption>Figure 2. Framework Cordova : interface entre le code web et les différentes plateformes mobiles</figcaption></figure>

Source : https://ionicframework.com/resources/articles/what-is-apache-cordova

## Modélisation des données

Une définition de la modélisation tirée de Wikipédia (Source : https://fr.wikipedia.org/wiki/Modèle_de_données) est donnée ci-après :

La modélisation des données est le processus par lequel on crée un modèle de données instance en appliquant une théorie de modèle de données. On emploie cette méthode pour se conformer à des exigences ou des attentes d'entreprises ou d'organismes publics.

Les besoins sont généralement exprimés à travers un modèle conceptuel de données et/ou un modèle logique de données. Ces modèles sont ensuite transformés en un modèle de données physique, qui décrit les bases de données physiques employées.

Pour une application spécifique, on définit les tables (objets, relations... les conventions de nommage dépendent du modèle général). Par exemple, on décrit "client", "commande", "article", ainsi que les relations entre eux ("un client commande des articles").

Si on utilise un modèle relationnel, on doit définir des ensembles de contraintes spécifiques (clé primaire, clé candidate, clé étrangère), en utilisant le langage approprié conformément au modèle général (par exemple SQL).
Cette étape est l'une des toutes premières. Elle va permettre de concevoir la base de données et vise à représenter fidèlement les caractéristiques des données de l'application ainsi que leur gestion.

Voici, à titre d'exemple, le modèle conceptuel obtenu pour notre cas d'étude :

<figure><img src="image_4.png" /><figcaption>Figure 3. Schéma modèle conceptuel des données</figcaption></figure>

Le modèle conceptuel est transformé en modèle physique des données et constitue une coque vide prête à recevoir les données.

Dans notre cas d'étude, des données existantes sont déjà présentes sous un autre format (ACCESS). Une opération de migration des données de l'ancien système vers le nouveau a été mise en œuvre. Il s'agit de pure technique SQL et cela ne sera pas abordé ici. On peut toutefois souligner l'importance d'une bonne modélisation afin d'être en mesure non seulement d'importer les données existantes mais aussi d'intégrer à ce moment-là les améliorations souhaitées ainsi que les données spécifiques de l'application qui seront utilisées pour en assurer la gestion.
## Architecture 3-tiers

On peut représenter comment s'articulent les différentes technologies entrant en jeu dans notre projet par le schéma suivant :

<figure><img src="image_5.png" /><figcaption>Figure 4. Schéma architecture 3-tiers</figcaption></figure>

Dans un tel modèle, on identifie le client comme l'utilisateur final (Tiers 1), l'agent sur le terrain qui, à l'aide d'une tablette ou d'un mobile (Android/iOS), va rentrer ses données d'observation.

Ces données seront envoyées, plus tard, via une connexion internet (Http), sur la partie serveur pour traitement.
Ce traitement est opéré entre deux tiers, une api ou web service, en charge de traiter la donnée (Tiers 2, authentification, validation des données) et la base de données (Tiers 3, stockage des données).

## Web Service

Par web service, on veut souligner le fait qu'il n'y aura pas d'intervention humaine mais une interaction entre machines. Dans notre cas, l'application mobile va dialoguer avec notre API Rest qui elle-même va dialoguer avec la base de données. Ces échanges « machine » repose sur le protocole Http, le langage du web. Il sera donc régi par les spécifications de ce protocole.

Le fonctionnement de ce type d'architecture REST se caractérise par deux notions :

- les ressources : le but de l'API étant de rendre accessible des ressources « resources » qui correspondent aux données de l'application ;

- les en-têtes : GET/PUT/POST/DELETE.

La combinaison des ressources et des en-têtes permet de construire une URL de type Rest :
## Le Cahier des Techniques de l'Inra 2020 (98)

* `/resources`, `GET`, récupère la liste des ressources,

* `/resources/:id`, `GET`, récupère la ressource selon l'ID,

* `/resources`, `POST`, crée une nouvelle ressource,

* `/resources/:id`, `PUT/PATCH`, met à jour une ressource,

* `/resources/:id`, `DELETE`, supprime une ressource.

Imaginons que nous souhaitions la liste des sites impliqués dans notre projet. Il faudrait interroger notre API en faisant une requête Http :

Request : `GET http://epia.clermont.inra.fr/vas/apiclimatick/public/api/sites`
Response : `"sites": [
{
  "site_id": 1,
  "site_abrev": "S1",
  "site_centre": "VetAgroSup Lyon",
  "site_collecteur": "EpiA INRA",
  "site departement": "69",
  "site_commune": "La-Tour-de-Salvagny",
  "site_lieudit": "Route de Lozanne"
},
{
  "site_id": 2,
  "site_abrev": "S2",
  "site_centre": "INRA Theix",
  "site_collecteur": "EpiA INRA",
  "site departement": "63",
  "site_commune": "Saint Genès",
  "site_lieudit": "Route des Volcans"
},
...

<caption>Figure 5. Requête HTTP</caption>

## Authentification JWT

La question que l'on est en droit de se poser est : est-ce que tout le monde peut accéder à toutes les ressources disponibles ? Evidemment, non. Les ressources doivent être protégées et cela nécessite la mise en place d'une
authentification. Nous utiliserons le standard ouvert JWT Json Web Token (RFC 7519), voici comment ce dernier fonctionne :

**on** s'enregistre une première fois auprès de notre api en monnayant un couple identifiant/mot de passe. Si tout se passe bien (i.e. une vérification en base de données confirme l'existence de l'identifiant et du mot de passe) alors l'api nous renvoie un jeton ou Token. C'est une chaîne de caractère qui équivaut à une signature numérique et garantit ainsi l'échange des données entre les parties (tiers) de manière compacte et autonome. Ce Token a une durée de vie limitée mais tant qu'il n'est pas périmé, il sera transmis dans toutes les requêtes que nous souhaitons faire au travers des en-têtes Http.

Si on reprend l'exemple donné précédemment, on transmet le Token reçu dans les en-têtes de la requête :

```
curl -H 'Accept: application/json'
-H "Authorization: Bearer eyJ0eXAiOiJJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9lcGhLmNsZXJtb250LmlucmEuZnJcL3Zhc1wvYXBpY2xpbWF0aWNrXC9wdWJsWNC2FwaVwvbG9naW4iLCJpYXQiOjE1Njk4NTc5NTEsImV4cCI6MTU2OTg2MTU1MSwibmJmljoxNTY5ODU3OTUxLCJqdGkiOiJVRmVONWxJaTJ1Y2dNNUJ5liwic3Viljo5LCJwcnYiOi4N2UwYWYxZWY5ZmQxNTgxMmZkZWM5NzE1M2ExNGUwYjA0NzU0NmFhIn0.s3VZAmgN1Q-iKW3sePW9LEowEfeoTIQcQ6Ek5o-1VJ9" http://epia.clermont.inra.fr/vas/apiclimatick/public/api/sites
```

<caption>Figure 6. Type de Token</caption>

Les en-têtes (-H) spécifient le type de données (mime) qui vont transiter durant l'échange : Json et le type d'authentification (Bearer) utilisé suivi du Token.

Chaque fois que nous aurons besoin d'accéder à une ressource, l'application injectera le Token dans l'en-tête Http. Côté serveur, l'API va vérifier que le Token est bien présent et de fait autorisera l'utilisateur à accéder aux ressources protégées.

## Description de l'App

L'application est développée avec le Framework Ionic dans sa version 4, Angular 7 et Capacitor pour l'accès aux API natives, caméra, système de fichier, etc.

Le découpage de l'App se fait comme suit :

Les pages sont les suivantes :

* Welcome : première page à l'ouverture de l'App,

* Login : connexion à l'App,

* Signup : création d'un profil,

* Profile : modification du profil,

* Site : synchronisation des sites,

* Campagne : liste des campagnes saisies,
## Le Cahier des Techniques de l'Inra 2020 (98)

* Detail : détail de la campagne,

* Tirage de 1 à 10 : liste des tirages.

Les services sont les suivants :

* Auth.service : gestion de l'authentification,

* Campagne.service : gestion des campagnes,

* Network.service : gestion de la connectivité,

* Photo.service : prendre et gérer les photos,

* Site.service : synchronisation des sites,

* User.service : gestion des utilisateurs.

Le menu de configuration est Setting-pop-over.

Les interfaces sont les suivantes :

* Campagne,

* Site,

* User.
## Workflow

<figure><img src="image_6.png" /><figcaption>Figure 7. Work flow</figcaption></figure>

## Interfaces TypeScript

En profitant du TypeScript et des interfaces, on va pouvoir générer les modèles de notre application : on obtient un code solide, débarrassé des problèmes coutumiers et autres effets de bord du JavaScript liés aux erreurs de type : les erreurs sont affichées dès l'exécution du code (annexe 1).

## Services

Les modèles de l'App étant définis, il nous faut un moyen de les gérer. Pour cela, on utilisera les services pour chacune de nos entités (campagne, user, photo, etc.). C'est une excellente pratique que de concentrer la logique applicative dans des services que l'on pourra utiliser où bon nous semble dans l'application chaque fois que nécessaire (annexe 2).
# Le Cahier des Techniques de l'Inra 2020 (98)

## Résultats

On peut voir l'App sur les store Apple et Google ici :

App Store: https://apps.apple.com/us/app/climatick/id1470038941

Google Play Store: https://play.google.com/store/apps/details?id=fr.inra.climatick&hl=fr_CA

:

<figure><img src="image_7.png" /><figcaption>Photo 1. Exemple de saisie des données tiques via mobile</figcaption></figure>

Les données saisies peuvent être consultées, a posteriori, sur le serveur via l'application Climatick en ligne à l'Curl suivante : http://epia.clermont.inra.fr/vas/climatick/public/
Et voici quelques illustrations tirées de l'application en ligne, ici, les sites participants au projet :

<figure><img src="image_8.png" /></figure>

Liste des campagnes de terrain envoyées via la tablette :

<figure><img src="image_9.png" /></figure>
# Le Cahier des Techniques de l'Inra 2020 (98)

Photos prises sur le terrain avec la caméra de l'appareil (tablette ou mobile) :

<figure><img src="image_10.png" /><figcaption>S6 octobre 2019-S6 octobre
2019</figcaption></figure>

<figure><img src="image_11.png" /></figure>

<figure><img src="image_12.png" /><figcaption>S6 octobre 2019-S6 octobre
2019</figcaption></figure>

<figure><img src="image_13.png" /></figure>

<figure><img src="image_14.png" /><figcaption>S6 octobre 2019-S6 octobre
2019</figcaption></figure>

<figure><img src="image_15.png" /></figure>

© 2018 Copyright INRA Naïma Dambrine

Données brutes de terrain, exportable au format csv/Excel :

Climatick (anciennement CC-EID)

Campagnes

Naïma Dambrine

Administration

Liste des collectes, données brutes relevées sur le terrain

Exporter

<table><thead><tr><th colspan="10">Site S6</th></tr><tr><th>Date collecte</th><th>Tirage</th><th>Début</th><th>Fin</th><th>N° Passage</th><th>Adulte Femelle</th><th>Adulte Mâle</th><th>Nymphe</th><th>Larve</th><th>Autre</th></tr></thead><tbody><tr><td>24-04-2014</td><td>Tirage T01</td><td>2014-04-24 09:38:00</td><td>2014-04-24 09:49:00</td><td>Passage 1</td><td>0</td><td>2</td><td>21</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T01</td><td>2014-04-24 09:38:00</td><td>2014-04-24 09:49:00</td><td>Passage 2</td><td>0</td><td>0</td><td>13</td><td>0</td><td>1</td></tr><tr><td>24-04-2014</td><td>Tirage T01</td><td>2014-04-24 09:38:00</td><td>2014-04-24 09:49:00</td><td>Passage 3</td><td>0</td><td>0</td><td>7</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T02</td><td>2014-04-24 09:50:00</td><td>2014-04-24 10:01:00</td><td>Passage 1</td><td>0</td><td>2</td><td>30</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T02</td><td>2014-04-24 09:50:00</td><td>2014-04-24 10:01:00</td><td>Passage 2</td><td>0</td><td>0</td><td>15</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T02</td><td>2014-04-24 09:50:00</td><td>2014-04-24 10:01:00</td><td>Passage 3</td><td>0</td><td>0</td><td>4</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T03</td><td>2014-04-24 10:01:00</td><td>2014-04-24 10:12:00</td><td>Passage 1</td><td>0</td><td>0</td><td>26</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T03</td><td>2014-04-24 10:01:00</td><td>2014-04-24 10:12:00</td><td>Passage 2</td><td>0</td><td>0</td><td>5</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T03</td><td>2014-04-24 10:01:00</td><td>2014-04-24 10:12:00</td><td>Passage 3</td><td>0</td><td>0</td><td>3</td><td>0</td><td>0</td></tr><tr><td>24-04-2014</td><td>Tirage T04</td><td>2014-04-24 10:14:00</td><td>2014-04-24 10:23:00</td><td>Passage 1</td><td>0</td><td>0</td><td>13</td><td>0</td><td>0</td></tr></tbody></table>

Site S6 - Total par campagne

<table><thead><tr><th>Date collecte</th><th>nb_nymphe</th><th>nb_Adle_Mâle</th><th>nb_Adle_Femelle</th><th>nb_Autre</th><th>nb_Larve</th></tr></thead><tbody><tr><td>24-04-2014</td><td>291</td><td>6</td><td>1</td><td>1</td><td>0</td></tr><tr><td>23-05-2014</td><td>168</td><td>7</td><td>0</td><td>0</td><td>0</td></tr><tr><td>20-06-2014</td><td>173</td><td>1</td><td>0</td><td>0</td><td>0</td></tr><tr><td>28-07-2014</td><td>41</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>25-08-2014</td><td>6</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>22-09-2014</td><td>6</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>17-10-2014</td><td>9</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>25-11-2014</td><td>40</td><td>3</td><td>1</td><td>0</td><td>0</td></tr><tr><td>23-01-2015</td><td>63</td><td>2</td><td>0</td><td>0</td><td>0</td></tr><tr><td>27-02-2015</td><td>26</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>28-03-2015</td><td>213</td><td>1</td><td>3</td><td>0</td><td>0</td></tr></tbody></table>
Conclusion

Supprimer les intermédiaires en faisant usage d'App mobile permet de faire l'économie d'erreur et de temps.

Un système d'information correctement bâti permet l'usage de ce type d'application, en bout de chaîne. Le développement final peut être généralisé sur tous types de projet.

Ce projet est autonome pour les applications suivantes :

* pour des projets orientés mono-utilisateur et ne nécessitant pas une base de données tiers, on peut imaginer un simple export csv pour une reprise des données sous R.

* d'autres solutions ont vu le jour, notamment à base de Raspberry Pi, où cette fois on embarque tout l'écosystème nécessaire : base de données + saisie en direct et/ou script de récupération des données issues de capteurs.

* enfin, nous pourrions imaginer rendre générique ce type d'application en générant à la volée les champs à saisir. Il faudrait préciser les champs et leur type et générer le masque de saisie idoine.

Ce projet peut être multi-utilisateur :

* dans ce cas de figure, il faudrait une API Rest générique également. Cela conviendrait particulièrement à des sauvegardes sur le Cloud, sous forme de fichiers. Dans le cas d'une base de données mutualisée sur un serveur, cela s'avère plus délicat en raison des contraintes d'intégrité des données inhérentes à tout système de gestion de base de données relationnel (SGBDR).

* on pourrait dès lors s'orienter vers des Web Services sémantiques, ce qui permettrait de réduire le couplage client-serveur et d'introduire de l'intelligence artificielle au sein des interfaces utilisateurs. Pour aller plus loin, une introduction au concept du modèle de maturité de Richardson :
  https://guide-api-rest.marm code.fr/api-rest/le-modele-de-maturite-de-richardson
  et une mise en application du modèle avec le framework passony
  https://openclassrooms.com/fr/courses/4087036-construisez-une-api-rest-avec-symfony/4343816-rendez-votre-api-auto-decouvrable-dernier-niveau-du-modele-de-maturite-de-richardson

Cet article est publié sous la licence Creative Commons (CC BY-SA).

<figure><img src="image_16.png" /></figure>

https://creativecommons.org/licenses/by-sa/4.0/

Pour la citation et la reproduction de cet article, mentionner obligatoirement le titre de l'article, le nom de tous les auteurs, la mention de sa publication dans la revue « Le Cahier des Techniques de l'Inra», la date de sa publication et son URL).
# Le Cahier des Techniques de l'Inra 2020 (98)

## Annexe

### 1. TypeScript

Le JavaScript permet de modéliser nos données ; ainsi, pour une campagne de terrain, on utilisera les interfaces suivantes :

```typescript
import { User } from '../interfaces/user';
export interface Campagne {
  id: string;
  nom: string;
  date: Date;
  heure_debut: Date;
  heure_fin: Date;
  comment: string;
  collecteurs: string;
  tirages: Tirage[];
  user_id: number;
  site_id: number;
  station_id: number;
  saved: boolean;
  photos: Photo[];
}
```

```typescript
export interface Photo {
  name: string,
  path: string,
  data: string,
  dateTaken: Date
}
```

```typescript
export interface Tirage {
  libelle: string;
  heure_debut: Date;
  heure_fin: Date;
  comment: string;
  passages: Passage[];
  saved: boolean;
}
```

```typescript
export interface Passage {
  libelle: string;
  adulte_m: number;
  adulte_f: number;
  nymphe: number;
  autre: number;
  larve: number;
  larve_fourchette: string;
  comment: string;
}
```
On peut ainsi profiter de ce typage pour, par exemple, mettre à jour une campagne :

```javascript
update(campagne : Campagne) : void {
    let index = this.campagnes.indexOf(c => c.id === campagne.id);
    this.campagnes[index] = campagne;
    this.save();
}
```

## 2. Les services

Voici un exemple d'utilisation des services : liste des méthodes proposées dans le service campagne.service.ts

```javascript
...
getCampagne(id): Campagne {
    return this.campagnes.find(campagne => campagne.id === id);
}

createCampagne(data): void {...}

renameCampagne(campagne, data): void {
    let index = this.campagnes.indexOf(campagne);

    if (index > -1) {
        this.campagnes[index].nom = data.nom;
        this.campagnes[index].date = data.date;
        this.campagnes[index].comment = data comment;
        this.campagnes[index].collecteurs = data.collecteurs;
        this.save();
    }
}

removeCampagne(campagne): void {
    let index = this.campagnes.indexOf(campagne);

    if (index > -1) {
        this.campagnes.splice(index, 1);
        this.save();
    }
}

...
```

Les méthodes offertes par le service pourront être utilisées depuis la page des campagnes : bouton faisant appel à la fonction `addCampagne()` depuis `campagne.page.html`

```html
...
<ion-button (click)="addCampagne()">
    <ion-icon slot="icon-only" name="add-circle"></ion-icon>
</ion-button>

...
```
# Le Cahier des Techniques de l'Inra 2020 (98)

Via le composant : campagne.page.ts, en important le service :

<figure><img src="image_17.png" /></figure>

Puis en l'utilisant lors de notre appel addCampagne() : campagne.page.ts

<figure><img src="image_18.png" /></figure>

On va pouvoir également gérer la prise de photo et déléguer toute la gestion de création, sauvegarde, etc. au service photo.service.ts

<figure><img src="image_19.png" /></figure>