3.3 KiB
Swifty Companion
Application mobile Flutter : recherche d’un login 42 et affichage du profil (API Intra, OAuth2).
Prérequis
- Flutter SDK (voir flutter.dev)
- Un téléphone ou émulateur Android configuré (
flutter doctor) - Une application OAuth créée sur l’Intra : Applications API
Installation
À la racine de ce dépôt Git (dossier qui contient swifty_companion/) :
cp .env.example swifty_companion/.env
cd swifty_companion
Édite swifty_companion/.env : renseigne CLIENT_ID, CLIENT_SECRET et REDIRECT_URI (voir commentaires dans .env.example à la racine).
Puis :
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
Utilisation
- Ouvrir l’app → Se connecter avec 42 (une fois par session).
- Saisir un login → Rechercher.
- Consulter le profil (photo, informations, skills, projets validés ou en échec).
- 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
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)
flutter testflutter run→ connexion 42 → login valide → profil complet- Login invalide → message d’erreur
- Mode avion (ou réseau coupé) → message réseau
- Retour à la recherche → nouvelle recherche
- Rotation ou petit écran → interface lisible
- Bonus : expliquer ou montrer le refresh token si demandé
Structure du dépôt
.
├── README.md # ce fichier
├── .gitignore
├── .env.example # modèle (sans secrets)
└── swifty_companion/ # code Flutter (lib/, android/, test/, …)