Revision sheet: Gestion des Rendez-vous Médicaux sur Android

📋 Plan du Cours

1. Objectif du projet Android
2. Modèle de données des rendez-vous
3. Classe SQLlite et tables SQLite
4. Gestion des professionnels et des RDV
5. Interface de prise de rendez-vous
6. Tests unitaires instrumentés

📖 1. Objectif du projet Android

🔑 Notions clés & Définitions

• Visiteurs médicaux GSB : Contexte applicatif : l’application sert les visiteurs médicaux de l’entreprise GSB pour organiser leurs rendez-vous.
• Gestion des rendez-vous : Finalité fonctionnelle : permettre de gérer les rendez-vous pris avec des professionnels de santé via l’application.
• Base de données embarquée SQLite : Support de stockage : les données sont conservées directement sur le téléphone grâce à SQLite, sans connexion réseau.
• Android Studio en Java : Technologie : l’application est développée avec Android Studio en langage Java.

📝 Points essentiels

• Le projet vise une application mobile pour gérer les rendez-vous des visiteurs médicaux avec des professionnels de santé.
• Les données sont stockées localement dans une base SQLite intégrée au téléphone, donc sans besoin de réseau.
• Le respect des contraintes inclut une base SQLite, des commentaires Javadoc et des tests unitaires instrumentés.
• Le projet est réalisé dans le cadre du cours de développement Android en SIO2.

💡 Astuce mémo

GSB = Gérer Sur le Téléphone : SQLite embarqué, sans réseau.

📖 2. Modèle de données des rendez-vous

🔑 Notions clés & Définitions

• Table PROFESSIONNEL : Entité stockée : la table PROFESSIONNEL contient les informations d’un médecin ou pharmacien.
• Table PRENDRE_RDV : Entité stockée : la table PRENDRE_RDV enregistre chaque rendez-vous pris.
• Clé étrangère id_Enregistrer : Lien entre tables : id_Enregistrer rattache chaque rendez-vous au professionnel concerné.
• MLD professionnel et RDV : Schéma conceptuel : les champs et relations du modèle distinguent PROFESSIONNEL et PRENDRE_RDV.

📝 Points essentiels

• La table PROFESSIONNEL (id_Enregistrer PK, nom, prenom, type, adresse, mail, tel) stocke les professionnels de santé.
• La table PRENDRE_RDV (id_PrendreRDV PK, date, heure, rendu, id_Enregistrer FK) stocke les rendez-vous.
• La relation est établie via la clé étrangère id_Enregistrer de PRENDRE_RDV vers PROFESSIONNEL.
• L’horodatage du RDV est décomposé en deux champs : date et heure.

💡 Astuce mémo

1 pro = plusieurs RDV : le RDV porte id_Enregistrer.

📖 3. Classe SQLlite et tables SQLite

🔑 Notions clés & Définitions

• SQLiteOpenHelper : Superclasse : SQLlite hérite de SQLiteOpenHelper pour gérer création et mise à jour du schéma SQLite.
• onCreate : Cycle de vie BD : la méthode crée les tables lors de la première ouverture de l’application.
• onUpgrade : Mise à jour du schéma : la méthode supprime puis recrée les tables lors d’un changement de version de base.
• DATABASE_NAME gestion_rdv.db : Identifiant de base : le nom de la base utilisée est gestion_rdv.db.

📝 Points essentiels

• Le constructeur SQLlite utilise DATABASE_NAME et un numéro de version 1, déclenchant onUpgrade si la version change.
• onCreate crée d’abord la table professionnel puis la table prendre_rdv, car la seconde dépend de la première.
• onUpgrade supprime d’abord prendre_rdv puis professionnel, puis appelle onCreate pour recréer le schéma.
• Dans professionnel, id_Enregistrer est déclaré en integer primary key autoincrement ; dans prendre_rdv, id_PrendreRDV suit le même principe.

💡 Astuce mémo

Créer : professionnel puis RDV ; Mettre à jour : RDV puis supprimer pro (dépendance).

📖 4. Gestion des professionnels et des RDV

🔑 Notions clés & Définitions

• insertProfessionnel : Opération d’écriture : insère une ligne dans TABLE_PROF via ContentValues avant db.insert.
• getAllProfessionnels : Opération de lecture : renvoie un Cursor contenant toutes les lignes de TABLE_PROF via une requête SELECT *.
• getRDVByDate : Opération de lecture filtrée : renvoie un Cursor des RDV dont le champ date correspond à la date demandée.
• ContentValues dictionnaire : Objet d’insertion : associe chaque nom de colonne à une valeur, pour insérer une ligne en une seule fois.

📝 Points essentiels

• insertProfessionnel prépare un ContentValues (nom, prenom, type, adresse, mail, tel) puis insère dans TABLE_PROF via db.insert.
• getAllProfessionnels exécute une requête SELECT * sur la table professionnel et retourne un Cursor à parcourir avec moveToNext().
• getRDVByDate interroge la table prendre_rdv avec un filtre sur COL_RDV_DATE, puis retourne le Cursor du résultat.
• MainActivity insère 3 professionnels de démonstration si le compteur de lignes (check.getCount()) vaut 0 au lancement.

💡 Astuce mémo

Cursor = tableau : getCount pour compter, moveToNext pour parcourir.

📖 5. Interface de prise de rendez-vous

🔑 Notions clés & Définitions

• Spinner des professionnels : Composant d’interface : la liste déroulante affiche les professionnels chargés depuis la base.
• CalendarView dateChoisie : Sélection de date : l’utilisateur choisit une date utilisée comme paramètre pour charger le planning.
• majSpinner : Méthode de chargement : construit le tableau des noms depuis un Cursor puis l’associe au Spinner via un ArrayAdapter.
• majPlanning : Méthode d’affichage : lit les RDV de dateChoisie et formate le texte du planning dans txtResultat.

📝 Points essentiels

• majSpinner lit le Cursor de professionnel, construit un tableau noms avec prenom + espace + nom, puis l’assigne à spinnerProfessionnel via ArrayAdapter.
• majPlanning appelle getRDVByDate(dateChoisie) puis concatène pour chaque ligne : heure + ' - ' + rendu, affiché dans txtResultat.
• Le chargement du planning est exécuté dans un try, et toute exception est affichée via txtResultat.setText(e.getMessage()).
• L’interface inclut un bouton de réservation et une zone de texte pour afficher le planning du jour sélectionné.

💡 Astuce mémo

Spinner = noms ; Planning = heure + rendu, filtrés par dateChoisie.

📖 6. Tests unitaires instrumentés

🔑 Notions clés & Définitions

• InstrumentationRegistry : Accès au contexte : InstrumentationRegistry permet d’obtenir le contexte cible pour instancier SQLlite pendant le test.
• Test insertProfessionnel : Vérification unitaire : contrôle que l’insertion d’un professionnel augmente le nombre de lignes de la table.
• Test insertRDV : Vérification unitaire : contrôle que l’insertion d’un RDV augmente le nombre de lignes de la table prendre_rdv.
• getCount sur Cursor : Indicateur de réussite : le test compare nb1 et nb2 à partir des compteurs renvoyés par les curseurs.

📝 Points essentiels

• Le test testInsertProfessionnel compte nb1 avec getAllProfessionnels().getCount(), insère un professionnel, puis compare nb2 à nb1 + 1.
• Le test testInsertRDV insère d’abord un professionnel pour que la clé étrangère soit valide, puis compte avant/après insertion avec getAllRDV().getCount().
• Les deux tests utilisent un pattern identique : obtenir compteur avant, insérer, recompter, valider avec assertEquals(nb1 + 1, nb2).
• Les tests sont instrumentés et utilisent le bon emplacement androidTest (et une configuration spécifique de test est mentionnée comme difficulté).

💡 Astuce mémo

Avant = nb1, après = nb2, succès si nb2 vaut nb1 + 1.

⚠️ Pièges & confusions fréquents

1. Confondre le rôle des deux tables : professionnel stocke le médecin/pharmacien, tandis que prendre_rdv stocke les rendez-vous avec date et heure.
2. Oublier de pré-insérer un professionnel lors du test d’insertion d’un RDV, ce qui rend la clé étrangère invalide dans la logique du projet.
3. Prendre le mauvais curseur dans l’interface : getAllProfessionnels alimente le Spinner, alors que getRDVByDate alimente le planning.
4. Inverser les ordres de création/déletion dans onCreate et onUpgrade : l’implémentation crée pro d’abord puis RDV, et supprime RDV d’abord puis pro.
5. Croire que le compteur du test vient de db plutôt que du Cursor : la validation utilise getCount() sur les résultats de requêtes.

✅ Checklist Examen

1. Citer l’objectif du projet et les contraintes imposées (SQLite, Javadoc, tests instrumentés, sans connexion réseau).
2. Donner les champs et clés de la table PROFESSIONNEL (id_Enregistrer PK, nom, prenom, type, adresse, mail, tel).
3. Donner les champs et clés de la table PRENDRE_RDV (id_PrendreRDV PK, date, heure, rendu, id_Enregistrer FK).
4. Expliquer pourquoi SQLlite.onCreate crée professionnel avant prendre_rdv dans ce projet.
5. Expliquer le comportement de SQLlite.onUpgrade : quelles tables sont supprimées et dans quel ordre.
6. Décrire le rôle de SQLiteOpenHelper et le déclenchement d’onUpgrade via le numéro de version dans le constructeur.
7. Décrire le fonctionnement de insertProfessionnel avec ContentValues puis db.insert dans TABLE_PROF.
8. Décrire ce que retourne getAllProfessionnels et comment parcourir ses lignes avec un Cursor.
9. Décrire ce que fait getRDVByDate et l’usage du filtre sur COL_RDV_DATE.
10. Décrire comment majSpinner construit le tableau de noms depuis le Cursor et alimente le Spinner via ArrayAdapter.
11. Décrire comment majPlanning charge les RDV d’une date puis formate chaque ligne avec heure et rendu.
12. Décrire la logique des tests unitaires instrumentés : compteur avant, insertion, compteur après, assertEquals(nb1 + 1, nb2).