Ladebeze66/swift_companion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

lot2

Browse Source
This commit is contained in:
Ladebeze66
2026-10-21 08:49:37 +02:00
parent 254497935d
commit 5d79d6c688
7 changed files with 446 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

83
docs/pedagogie/00-plan-preparation-soutenance.md Normal file
View File

@@ -0,0 +1,83 @@
# Plan de préparation — dépôt soutenance, doc et code
> **Méthode :** pour chaque lot, l’agent décrit ce qu’il compte faire → **tu valides ou ajustes** → on exécute → on coche.
**Dernière mise à jour :** lot 2 livré (README rendu + `.env.example`).
---
## Décisions validées (lot 0)
| Point | Décision |
|-------|----------|
| Branche `soutenance` | Même contenu que rendu école ; `main` = travail perso ; présentation portable sur `soutenance` |
| PC école | Clone perso → copie `swiftyCompanion/` → supprimer repo perso → `git init` rendu → push Vogosphere (détail §6 fiche dépôt) |
| `.env` | **Uniquement** `swifty_companion/.env` en local ; **jamais** dans Git ; `.env.example` versionné (sujet : échec direct si secrets publics) |
| Fiche orale (lot 3) | **Déroulé de soutenance** détaillé (sujet, points critiques, réalisation, commandes expliquées) — un fichier structuré logiquement |
| Commentaires code | **Français** — sujet ne l’interdit pas |
| Bouton DEBUG | Voir [fiche-depot-soutenance.md §8](fiche-depot-soutenance.md) — pas lié aux secrets ; visible seulement en build debug ; choix garder/retirer avant rendu final |
---
## Où vit quoi
| Zone | Chemin | Git |
|------|--------|-----|
| Travail | racine `swifty_companion/` | Gitea privé (`main`) |
| Rendu / soutenance | `swiftyCompanion/` | Vogosphere + branche `soutenance` |
| Oral long | `docs/pedagogie/` | perso uniquement |
---
## Ordre des lots
| Phase | Lot | Statut |
|-------|-----|--------|
| A | 0 Cadrage | ✅ Validé |
| B | 1 Dépôt + branche | ✅ [fiche-depot-soutenance.md](fiche-depot-soutenance.md) |
| C | 2 README rendu autonome | ✅ fait |
| D | 3 Fiche soutenance orale | ☐ à faire |
| E | 4 Commentaires `lib/` | ☐ à faire |
---
## Lot 2 — Livré
- `swiftyCompanion/README.md` réécrit (autonome, sans lien `docs/`).
- `.env.example` commenté (racine + `swifty_companion/.env.example`).
- `swifty_companion/README.md` : pointeur court vers le README racine.
**Prochaine étape :** dis **« OK lot 3 »** pour la fiche orale détaillée.
---
## Lot 3 — Fiche orale (aperçu du déroulé prévu)
Structure envisagée pour `fiche-soutenance-orale.md` :
1. Introduction (30 s) — sujet, objectif, stack
2. Sécurité & `.env` — encadré sujet, ce qu’est chaque clé OAuth
3. Architecture — 2 vues, services, flux token unique
4. Démo guidée — commandes `flutter doctor`, `test`, `run`, parcours écran par écran
5. Critères obligatoires — comment chaque critère est rempli (renvoi fichiers)
6. Erreurs & edge cases — quoi montrer
7. Bonus refresh — flux + option démo DEBUG
8. Questions fréquentes — réponses courtes
---
## Lot 4 — Commentaires code
`lib/` en français, sans lien vers doc externe ; décision DEBUG bouton documentée en oral.
---
## Suivi
| Lot | Fait ? |
|-----|--------|
| 0 | ✅ |
| 1 | ✅ |
| 2 | ✅ |
| 3 | ☐ |
| 4 | ☐ |

6
docs/pedagogie/README.md
View File

@@ -6,7 +6,11 @@ Parcours pour construire le projet **étape par étape**.
→ **[00-reprise-et-etat.md](00-reprise-et-etat.md)** — état du projet.
→ **[guide-soutenance-realisation.md](guide-soutenance-realisation.md)** — **cartographie sujet ↔ code** pour la correction (ne rien oublier).
→ **[00-plan-preparation-soutenance.md](00-plan-preparation-soutenance.md)** — plan (valider lot par lot).
→ **[fiche-depot-soutenance.md](fiche-depot-soutenance.md)** — branche `soutenance`, `.env`, push PC école, bouton DEBUG.
→ **[guide-soutenance-realisation.md](guide-soutenance-realisation.md)** — cartographie sujet ↔ code pour la correction.
## Prérequis

233
docs/pedagogie/fiche-depot-soutenance.md Normal file
View File

@@ -0,0 +1,233 @@
# Fiche — dépôt de soutenance, branche `soutenance`, PC école
> **Lot 1** du [plan de préparation](00-plan-preparation-soutenance.md).
> **Validé :** branche `soutenance` = même contenu que Vogosphere ; travail quotidien sur `main` ; `.env` local uniquement ; `.env.example` dans le rendu Git.
---
## 1. Ce que dit le sujet (sécurité — **éliminatoire**)
Traduction du PDF v4, chapitre IV (encadré page 5) :
> Les identifiants, clés API, variables d’environnement, etc. doivent être stockés **localement** dans un fichier **`.env`** et **ignorés par git**. Des identifiants exposés **publiquement** entraînent **l’échec direct** du projet.
**À retenir pour le rendu :**
| Fichier | Dans le Git école (Vogosphere) ? |
|---------|----------------------------------|
| `.env` (avec vrais secrets) | **NON — jamais** |
| `.env.example` (modèle vide + explications) | **OUI** |
| `.gitignore` qui ignore `.env` | **OUI** |
Le correcteur crée **son** `.env` sur sa machine à partir de `.env.example` + **son** app OAuth Intra (ou la tienne en démo, **sans** committer les valeurs).
---
## 2. Où mettre le `.env` pour que l’app tourne
Flutter charge le fichier déclaré dans `pubspec.yaml` :
```yaml
assets:
- .env
```
→ chemin **obligatoire pour l’exécution** :
```text
swiftyCompanion/swifty_companion/.env
```
| Fichier | Rôle |
|---------|------|
| `swifty_companion/.env` | **Secrets réels** — machine locale (portable, école en démo) — **gitignore** |
| `swiftyCompanion/.env.example` | **Modèle** à la racine du paquet rendu — **versionné** |
| `swiftyCompanion/.env` (racine paquet) | **Inutile** pour Flutter — à **ne pas** utiliser pour éviter la confusion (tu peux le supprimer en local) |
**Procédure correcteur / toi :**
```bash
cd swiftyCompanion/swifty_companion
cp ../.env.example .env
# Éditer .env : CLIENT_ID, CLIENT_SECRET, REDIRECT_URI
flutter pub get
flutter run -d <device>
```
*(Le lot 2 enrichira `.env.example` avec commentaires détaillés par variable.)*
---
## 3. Contenu exact du dépôt école (Vogosphere)
**Racine du dépôt Intra** = contenu du dossier `swiftyCompanion/` (pas le repo perso entier).
```text
swiftyCompanion/ ← racine Git Vogosphere
├── README.md
├── .gitignore
├── .env.example
└── swifty_companion/ ← projet Flutter
├── pubspec.yaml
├── lib/
├── android/
├── test/
└── …
```
**Ne doit pas apparaître dans Vogosphere :**
- `docs/` (sujet traduit, pédagogie, fiches orale)
- tout `.env` avec secrets
- dépôt Gitea perso, liens vers guides internes
---
## 4. Deux Git, deux rôles
| Dépôt | Remote typique | Contenu |
|-------|----------------|---------|
| **Perso** | Gitea privé | `docs/` + `swiftyCompanion/` (travail) |
| **École** | Vogosphere | **uniquement** `swiftyCompanion/` à la racine |
Sur le **portable**, tu continues à coder sur **`main`** (perso). Quand le rendu est prêt, tu mets à jour la branche **`soutenance`** (voir §5) — c’est la référence « propre » pour présenter et pour préparer le push école.
---
## 5. Branche `soutenance` (portable)
### Objectif
- Même **arbre utile** que Vogosphere : tout sous `swiftyCompanion/` à jour et fonctionnel.
- Tu **peux** continuer à développer sur `main` ; `soutenance` ne bouge que quand tu **décides** de figer une version pour correction.
- En soutenance sur **ton PC** : tu ouvres le projet dans `swiftyCompanion/swifty_companion/` (pas besoin d’afficher `docs/` à l’écran).
### Méthode recommandée (monorepo perso)
```bash
cd ~/projets/42School/swifty_companion
# 1) Finir les modifs sur main (swiftyCompanion + éventuellement docs)
git checkout main
git status # rien de secret à committer
# 2) Mettre à jour soutenance (merge depuis main)
git checkout soutenance # créer une fois : git checkout -b soutenance
git merge main # ou cherry-pick des commits rendu uniquement
# 3) Vérifier que seul le paquet rendu est cohérent
cd swiftyCompanion/swifty_companion
flutter analyze && flutter test
# .env présent en local, absent du git :
git -C ../.. ls-files | rg '\.env' # doit montrer seulement .env.example
```
**Présentation :** `git checkout soutenance`, lancer `flutter run` depuis `swifty_companion/`.
**Travail après soutenance :** retour sur `main`, nouvelles features ; avant rendu final, re-merge vers `soutenance`.
### Alternative (si tu préfères un repo Git **uniquement** dans `swiftyCompanion/`)
- `git init` dans `swiftyCompanion/`, remote Vogosphere.
- Branche `main` = école, branche `dev` optionnelle.
- Le monorepo perso ne versionne plus le code Flutter (plus lourd à maintenir). **Tu as choisi le monorepo + branche `soutenance`** — la méthode ci-dessus suffit.
---
## 6. Ton scénario **PC école** (push Vogosphere)
C’est le flux que tu as décrit — formalisé pour ne rien oublier.
### Prérequis
- Branche `soutenance` à jour sur Gitea **ou** dossier `swiftyCompanion/` prêt sur clé USB / copie.
- `.env` **sur la clé ou la machine école** pour la démo (fichier local, **pas** dans le commit).
- URL du dépôt **Vogosphere** (Intra 42).
### Étapes sur le PC école
```bash
# A — Récupérer le travail (une fois)
cd ~
git clone https://ton-gitea/.../swifty_companion.git
cd swifty_companion
git checkout soutenance
# B — Préparer le dossier de rendu (contenu école pur)
# Option simple : le rendu EST le sous-dossier swiftyCompanion
cd ~/chemin/attendu/par/l/ecole # répertoire de rendu du sujet
rm -rf ./* # seulement si dossier vide / dédié — attention !
cp -a ~/swifty_companion/swiftyCompanion/. .
# C — Retirer le dépôt perso de la machine école (optionnel mais ton choix)
rm -rf ~/swifty_companion
# D — Git ÉCOLE uniquement dans le répertoire de rendu
cd ~/chemin/attendu/par/l/ecole
git init
git remote add origin <url-vogosphere-swifty_companion>
git add .
git status # VÉRIFIER : pas de .env, pas de docs/
git commit -m "Rendu Swifty Companion"
git push -u origin main
```
### Contrôles avant `git push` (checklist)
- [ ] `git status` ne liste **aucun** `.env`
- [ ] `.env.example` est présent et **sans** vraies clés
- [ ] Pas de dossier `docs/` du dépôt perso
- [ ] `flutter test` OK dans `swifty_companion/`
- [ ] README à la **racine** du clone Vogosphere (pas un niveau au-dessus)
---
## 7. Portable = démo = même binaire « logique » que l’école
| Action | Portable (`soutenance`) | Vogosphere |
|--------|-------------------------|------------|
| Code Flutter | `swiftyCompanion/swifty_companion/` | idem |
| Secrets | `.env` local | jamais poussé |
| Doc longue oral | `docs/pedagogie/` (perso) | absent |
| README correcteur | `swiftyCompanion/README.md` | idem |
---
## 8. Point « DEBUG » dans l’app (éclaircissement)
Ce n’est **pas** un fichier `.env` ni un secret.
Dans `search_screen.dart`, un bouton **« DEBUG : simuler token expiré »** n’apparaît que si `kDebugMode` est vrai (build **debug**, ex. `flutter run`). Il **n’existe pas** dans un APK **release** (`flutter build apk --release`).
| Question | Réponse |
|----------|---------|
| Le sujet l’interdit ? | **Non** — rien dans le PDF sur les boutons de debug. |
| Risque en soutenance ? | L’évaluateur peut le voir en `flutter run` ; tu peux l’expliquer pour le **bonus refresh**, ou le retirer avant rendu final si tu veux une UI plus « propre ». |
| Décision à prendre (lot 4 ou avant push) | **Garder** (démo bonus) **ou** **retirer** le bouton — les deux sont défendables. |
→ Détails oraux : [fiche-soutenance-orale.md](fiche-soutenance-orale.md) (lot 3, à rédiger).
---
## 9. Commentaires en français dans le code
Le sujet n’impose pas la langue des commentaires. **Français = OK** (lot 4).
---
## 10. Prochaines étapes (autres lots)
| Lot | Document / action |
|-----|-------------------|
| 2 | README rendu + `.env.example` commenté (sans ton « IA ») |
| 3 | `fiche-soutenance-orale.md` — déroulé minute par minute + commandes |
| 4 | Commentaires `lib/` + décision finale bouton DEBUG |
---
## 11. Liens
- Plan global : [00-plan-preparation-soutenance.md](00-plan-preparation-soutenance.md)
- Sujet sécurité : [swifty-companion.md](../sujets/swifty-companion.md) § IV
- PDF : [originaux/swifty_companion_subject.pdf](../sujets/originaux/swifty_companion_subject.pdf)

36
swiftyCompanion/.env.example
View File

@@ -1,7 +1,37 @@
# Renommer / copier en .env — ne jamais committer .env
# Application OAuth : https://profile.intra.42.fr/oauth/applications
# =============================================================================
# Swifty Companion — modèle de configuration (PAS de secrets réels ici)
# =============================================================================
#
# 1) Copier ce fichier vers le package Flutter :
# cp .env.example swifty_companion/.env
# (depuis la racine de ce dépôt, dossier swiftyCompanion/)
#
# 2) Remplir les valeurs depuis ton application OAuth sur l’Intra 42 :
# https://profile.intra.42.fr/oauth/applications
#
# 3) Ne JAMAIS committer le fichier .env (le sujet prévoit l’échec direct si
# des identifiants sont exposés publiquement). Ce .env.example peut être
# versionné : il ne contient que des noms de variables et des exemples.
#
# =============================================================================
# CLIENT_ID — sur l’Intra, champ « UID » de l’application OAuth.
# C’est l’identifiant public de ton app (pas ton login 42).
# Exemple de forme : u-s4t2ud-xxxxxxxx...
CLIENT_ID=
# CLIENT_SECRET — sur l’Intra, champ « SECRET » de l’application OAuth.
# Sert à échanger le code OAuth contre un access token. À garder strictement
# privé : uniquement dans .env local, jamais sur Git ni dans le chat.
# Exemple de forme : s-s4t2ud-xxxxxxxx...
CLIENT_SECRET=
# Identique au champ « URI de redirection » sur l’Intra (une seule ligne, sans guillemets)
# REDIRECT_URI — URI de redirection enregistrée sur l’Intra (caractère pour
# caractère identique dans le formulaire et ici).
# Pour un téléphone Android avec ce projet : schéma custom + host callback
# (voir aussi android/app/src/main/AndroidManifest.xml).
REDIRECT_URI=com.example.swiftycompanion://callback
# Scopes à cocher sur l’Intra lors de la création de l’app (pas dans .env) :
# - public (données publiques utilisateur)
# - projects (liste projects_users sur le profil — sans cela, erreur 403)

133
swiftyCompanion/README.md
View File

@@ -1,87 +1,100 @@
# Swifty Companion
Application mobile — profil étudiant 42 via l’**API Intra** (OAuth2).
Application mobile Flutter : recherche d’un login 42 et affichage du profil (API Intra, OAuth2).
> **Dépôt de rendu école** : ce dossier est la **racine** du dépôt Git Vogosphere. Pas de `docs/` ni de sujet traduit ici (dépôt perso séparé).
## Prérequis
**État :** partie obligatoire + **bonus refresh token** (401 → refresh → retry API).
- Flutter SDK (voir [flutter.dev](https://flutter.dev))
- Un téléphone ou émulateur Android configuré (`flutter doctor`)
- Une application OAuth créée sur l’Intra : [Applications API](https://profile.intra.42.fr/oauth/applications)
## Lancer le projet
## Installation
À la racine de **ce** dépôt Git (dossier qui contient `swifty_companion/`) :
```bash
cd swifty_companion
# Créer .env ici (voir .env.example à la racine du dépôt école)
flutter pub get
flutter run -d <device>
cp ../.env.example .env
```
Le fichier **`.env`** doit être dans **`swifty_companion/.env`** (déclaré comme asset dans `pubspec.yaml`).
Édite `swifty_companion/.env` : renseigne `CLIENT_ID`, `CLIENT_SECRET` et `REDIRECT_URI` (voir commentaires dans `.env.example` à la racine).
Vérifications :
Puis :
```bash
flutter doctor
flutter devices
flutter pub get
flutter run -d <identifiant_appareil>
```
Lister les appareils : `flutter devices`.
## Configuration OAuth (résumé)
| Variable `.env` | Sur l’Intra 42 |
|-----------------|----------------|
| `CLIENT_ID` | **UID** de l’application |
| `CLIENT_SECRET` | **SECRET** de l’application |
| `REDIRECT_URI` | **URI de redirection** (ex. `com.example.swiftycompanion://callback`) |
Scopes à activer sur l’application : **public** et **projects**.
La redirect URI doit être la même sur l’Intra, dans `.env`, et dans la config Android du projet.
**Important :** le fichier `.env` reste sur ta machine uniquement. Ce dépôt contient `.env.example` sans vraies clés. Ne pousse jamais `.env` sur le Git de rendu.
Documentation API : [api.intra.42.fr/apidoc](https://api.intra.42.fr/apidoc)
## Utilisation
1. Ouvrir l’app → **Se connecter avec 42** (une fois par session).
2. Saisir un **login** → **Rechercher**.
3. Consulter le **profil** (photo, informations, skills, projets validés ou en échec).
4. **Retour** → nouvelle recherche avec le même token (pas de nouvelle connexion OAuth à chaque fois).
Certaines données peuvent s’afficher comme « — » : l’API peut masquer des champs selon la confidentialité.
## Vérifications avant soutenance
```bash
cd swifty_companion
flutter analyze
flutter test
```
## Configuration (`.env`)
1. App OAuth : [profile.intra.42.fr/oauth/applications](https://profile.intra.42.fr/oauth/applications)
2. Scopes : **`public`** + **`projects`** (projets sur le profil)
3. Redirect URI (ex. téléphone) : `com.example.swiftycompanion://callback` — identique sur l’Intra et dans `.env`
4. Ne **jamais** committer `.env`
API : [api.intra.42.fr/apidoc](https://api.intra.42.fr/apidoc)
## Parcours app
1. **Se connecter avec 42** (token réutilisé pour toutes les requêtes)
2. **Rechercher** un login
3. **Profil** : photo, champs, skills (niveau + %), projets validés et failed
4. **Retour** → nouvelle recherche
## Partie obligatoire (rappel sujet v4)
## Critères du sujet (v4) couverts par l’app
| # | Exigence |
|---|----------|
| 1 | Au moins **2 vues** |
| 2 | **Toutes** les erreurs gérées (login inconnu, réseau, …) |
| 3 | Vue 2 : infos du login s’il **existe** |
| 4 | **≥ 4 détails** + **photo de profil** |
| 5 | **Skills** : niveau + pourcentage |
| 6 | **Projets** réalisés, **y compris les failed** |
| 7 | Retour possible vers la **vue 1** |
| 8 | Layout **adaptatif** |
| 9 | **OAuth2** — **un token** réutilisé |
Certaines données peuvent être masquées par l’API (confidentialité).
| 1 | Deux écrans : recherche et profil |
| 2 | Erreurs gérées (login inconnu, réseau, session, etc.) |
| 3 | Profil affiché si le login existe |
| 4 | Au moins quatre informations + photo |
| 5 | Skills avec niveau et pourcentage |
| 6 | Projets terminés, y compris en échec |
| 7 | Retour vers l’écran de recherche |
| 8 | Mise en page adaptée (scroll, grands écrans) |
| 9 | Un seul flux OAuth, token réutilisé pour les appels API |
## Bonus
- Refresh token : `IntraAuthService.refreshAccessToken()` + retry dans `intraApiGet` sur 401.
Rafraîchissement du token d’accès lorsque l’API renvoie 401, puis nouvelle tentative de la requête (sans refaire l’écran de connexion 42).
## Soutenance — checklist peer-eval
## Déroulé de démonstration (peer-eval)
| # | Test | Démo |
|---|------|------|
| 1 | `flutter test` | Tests OK |
| 2 | `flutter run -d <device>` | Vue 1 → login valide → vue 2 |
| 3 | Profil | Photo + ≥ 4 champs + skills + projets (dont failed) |
| 4 | Login invalide | Message clair, pas de crash |
| 5 | Réseau coupé | Erreur réseau gérée |
| 6 | Navigation | Retour vue 1, nouvelle recherche |
| 7 | Petit écran / rotation | UI lisible |
| 8 | Bonus | Refresh token si implémenté |
1. `flutter test`
2. `flutter run` → connexion 42 → login valide → profil complet
3. Login invalide → message d’erreur
4. Mode avion (ou réseau coupé) → message réseau
5. Retour à la recherche → nouvelle recherche
6. Rotation ou petit écran → interface lisible
7. Bonus : expliquer ou montrer le refresh token si demandé
**Ordre suggéré :** connexion → profil → login faux → hors ligne → retour → `flutter test`.
## Structure du dépôt
## Fichiers de ce dépôt
| Fichier | Rôle |
|---------|------|
| `README.md` | Ce document |
| `.gitignore` | Exclut `.env`, build, etc. |
| `.env.example` | Modèle sans secrets |
| `swifty_companion/` | Projet Flutter (`lib/`, `android/`, …) |
```text
.
├── README.md # ce fichier
├── .gitignore
├── .env.example # modèle (sans secrets)
└── swifty_companion/ # code Flutter (lib/, android/, test/, …)
```

9
swiftyCompanion/swifty_companion/.env.example Normal file
View File

@@ -0,0 +1,9 @@
# Copier en .env dans CE dossier (swifty_companion/) :
# cp .env.example .env
# Puis éditer .env avec ton UID, SECRET et REDIRECT_URI Intra.
#
# Modèle détaillé (mêmes variables) : ../.env.example à la racine du dépôt.
CLIENT_ID=
CLIENT_SECRET=
REDIRECT_URI=com.example.swiftycompanion://callback

23
swiftyCompanion/swifty_companion/README.md
View File

@@ -1,17 +1,14 @@
# swifty_companion
# Package Flutter — Swifty Companion
A new Flutter project.
Le projet s’exécute depuis ce dossier.
## Getting Started
## Démarrage rapide
This project is a starting point for a Flutter application.
```bash
cp .env.example .env # ou : cp ../.env.example .env
# Éditer .env (CLIENT_ID, CLIENT_SECRET, REDIRECT_URI)
flutter pub get
flutter run -d <device>
```
A few resources to get you started if this is your first Flutter project:
- [Learn Flutter](https://docs.flutter.dev/get-started/learn-flutter)
- [Write your first Flutter app](https://docs.flutter.dev/get-started/codelab)
- [Flutter learning resources](https://docs.flutter.dev/reference/learning-resources)
For help getting started with Flutter development, view the
[online documentation](https://docs.flutter.dev/), which offers tutorials,
samples, guidance on mobile development, and a full API reference.
Instructions complètes (OAuth, soutenance, structure du dépôt) : **README.md à la racine du dépôt** (dossier parent).