# Swifty Companion

Application mobile Flutter : recherche d’un login 42 et affichage du profil (API Intra, OAuth2).

## Prérequis

- 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)

## Installation

À la racine de **ce** dépôt Git (dossier qui contient `swifty_companion/`) :

```bash
cd swifty_companion
cp ../.env.example .env
```

Édite `swifty_companion/.env` : renseigne `CLIENT_ID`, `CLIENT_SECRET` et `REDIRECT_URI` (voir commentaires dans `.env.example` à la racine).

Puis :

```bash
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é.

**Photo :** l’URL est fournie par l’API (`image` sur la fiche user) ; le fichier JPEG est chargé depuis `cdn.intra.42.fr` avec le **même** access token OAuth (pas un second login).

## Vérifications avant soutenance

```bash
cd swifty_companion
flutter analyze
flutter test
```

## Critères du sujet (v4) couverts par l’app

| # | Exigence |
|---|----------|
| 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

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).

## Déroulé de démonstration (peer-eval)

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é

## Structure du dépôt

```text
.
├── README.md           # ce fichier
├── .gitignore
├── .env.example        # modèle (sans secrets)
└── swifty_companion/   # code Flutter (lib/, android/, test/, …)
```