Objectif du projet

Dans ce chapitre, nous allons construire une application Pokédex qui réunit les concepts de Kotlin et les pratiques de développement Android présentés dans les chapitres précédents.

1. Ce que nous allons construire

Notre application Pokémon Explorer permettra aux utilisateurs :

d’explorer tous les types de Pokémon dans une grille interactive ;
de consulter la liste des Pokémon par type ;
d’afficher la fiche détail d’un Pokémon (statistiques, sprites, informations) ;
de gérer une liste de favoris avec persistance locale.

2. Objectifs pédagogiques

Ce projet vous permettra de manipuler les briques essentielles d’une application Android moderne. Vous travaillerez sur les sujets suivants :

Jetpack Compose : vous apprendrez à construire une interface utilisateur moderne à partir d’une approche déclarative, plus lisible et plus simple à faire évoluer.
Navigation Compose : vous mettrez en place une navigation entre les écrans, avec une gestion plus sûre des routes et des paramètres grâce au typage .
Coroutines et Flow : vous utiliserez les mécanismes de programmation asynchrone et réactive pour gérer les traitements en arrière-plan et les flux de données .
Room Database : vous implémenterez...

Parcours utilisateur

Au premier lancement, l’utilisateur découvre une grille de types. En sélectionnant un type (ex. : Feu), il accède à la liste des Pokémon associés à ce type. En touchant une carte, il ouvre la fiche de détail : image, nom, types, quelques statistiques et un Switch Material « Favori ». Lorsqu’un Pokémon est marqué comme favori, cette information est persistée et visible dans la liste (icône/repère), même après redémarrage.

L’API (PokeAPI)

Pour ce projet, nous nous appuyons sur la PokeAPI, une API publique et gratuite qui expose les données de l’univers Pokémon. Elle permet de récupérer la liste des types, les Pokémon associés à un type, ainsi que les détails de chaque Pokémon (statistiques, sprites, etc.). C’est un bon support pour manipuler des données réelles tout en travaillant l’architecture Compose, MVVM et la persistance locale. Voici les principaux points d’accès que nous allons utiliser :

Types : le point d’accès /type (catalogue de tous les types). Chaque type référence une collection de Pokémon de ce type.
Liste par type : à partir d’un type sélectionné, on lit ses références de Pokémon (noms/URL) et on compose la liste.
Détail Pokémon : le point d’accès /pokemon/{name|id} fournit le nom, les types, les sprites (dont « official artwork »), les statistiques de base, etc.
Images : nous utiliserons l’URL « officielle » fournie par les sprites.

Prérequis

Avant de démarrer, vérifiez que vous disposez des éléments suivants :

Android Studio à jour (Compose/Material 3) ;
un émulateur ou un appareil physique prêt ;
connexion internet (pour PokeAPI).

Avant de coder, assurez-vous de pouvoir lancer l’application par défaut (écran Compose Hello Android!). Nous ajouterons la navigation, les appels réseau et la persistance dans les parties suivantes.

Mise en place du projet

Avant d’entrer dans le vif du sujet, nous allons préparer notre environnement de travail. Pour éviter de vous perdre dans des étapes fastidieuses de configuration, un projet Android de base est déjà fourni sur GitHub et est disponible en téléchargement sur le site des Éditions ENI.

Ce projet inclut déjà toutes les dépendances nécessaires (Compose, Material 3, Navigation, Retrofit, Room, Coil, Hilt, etc.) ainsi que la configuration minimale de Gradle.

Téléchargez le projet depuis GitHub : https://github.com/BoukhariAyoub/eni-kotlin-book.git

Une fois téléchargé, ouvrez le dossier dans Android Studio. L’IDE synchronisera automatiquement le projet grâce aux fichiers Gradle.

Vérifier le bon fonctionnement

Avant de commencer à coder, nous allons nous assurer que tout fonctionne correctement.

Lancez l’application sur un émulateur ou un appareil physique. Par défaut, l’écran principal affiche simplement un texte Hello Android! généré avec Jetpack Compose.

Si vous obtenez ce résultat, votre environnement est prêt et vous pouvez passer à la suite.

Architecture

Notre application suit les principes de la Clean Architecture avec trois couches distinctes.

1. Structure du projet

Ce projet de départ est déjà organisé pour refléter l’architecture que nous allons suivre :

ui/ : contient les écrans Jetpack Compose ;
data/ : gère les appels réseau (API PokeAPI) et la base de données locale (room) ;
domain/ : définit les modèles et la logique métier ;
di/ : configuration de Hilt pour l’injection de dépendances.

Cette organisation garde le code lisible et facile à faire évoluer.

2. Flux de données

Le flux de données suit un sens unique. L’UI déclenche une action via le ViewModel, qui passe par un UseCase puis un Repository (couche d’abstraction entre les sources de données et le ViewModel) jusqu’à la source de données (réseau ou base locale). Les résultats remontent ensuite à l’UI sous forme de Flow et StateFlow (flux d’état observable qui conserve la dernière valeur émise), ce qui assure la mise à jour automatique de l’écran.

Concrètement, l’interface utilisateur déclenche une action, par exemple lorsqu’un utilisateur consulte, ajoute ou supprime un favori. Cette action est transmise au ViewModel, qui relaie la demande...

Première fonctionnalité : écran des types

Nous commençons par l’écran d’accueil : une grille des types Pokémon. Cet écran sert de point d’entrée à l’application : l’utilisateur y choisit un type (Feu, Eau, Plante, etc.) avant de naviguer vers la liste correspondante.

1. Interface API Retrofit

À l’ouverture de l’application, l’écran déclenche une requête vers le point d’accès /type de la PokéAPI. La réponse contient la liste des types disponibles. Ces données sont exposées à l’UI via un ViewModel, selon le modèle MVVM.

En cas de succès, la grille est affichée. En cas d’erreur réseau, un message explicite est montré à l’utilisateur, avec la possibilité de réessayer.

2. ViewModel avec gestion d’état

Le ViewModel sert d’intermédiaire entre la couche données et l’UI. Il expose les données via Flow et StateFlow et gère les trois états classiques d’un appel API : état de chargement, succès, état d’erreur. Quand l’état change (nouvelle liste de types, échec réseau, réessai), la vue est mise à jour automatiquement.

3. Présentation visuelle

L’interface se compose...

Conclusion

En arrivant au bout de ce projet Pokédex, vous avez assemblé pièce par pièce les fondations d’une application Android moderne. L’interface utilisateur a été entièrement construite avec Jetpack Compose, en s’appuyant sur une architecture en couches qui sépare clairement la présentation, la logique métier et l’accès aux données. Les Pokémon sont récupérés depuis une API REST grâce à Retrofit et désérialisés avec Moshi, puis stockés localement dans une base Room afin que l’application reste utilisable même hors connexion. Hilt orchestre l’ensemble en fournissant les dépendances là où elles sont nécessaires, et tout cela repose sur Kotlin et ses outils asynchrones ; coroutines pour les opérations longues, Flow pour propager les données dans le temps.

Au-delà de l’application elle-même, ce parcours vous a fait travailler des compétences qui dépassent largement le cadre du Pokédex. Vous avez appris à découper une application selon les principes de la Clean Architecture, à construire des interfaces déclaratives et réactives en Compose et à exposer l’état de l’UI à travers StateFlow pour qu’elle reste toujours cohérente...

Projet pratique - Pokédex