Développeur mobile Android

Maîtriser le langage de la stack choisie (Kotlin, TypeScript ou Dart) : types, fonctions, collections, classes, gestion des valeurs nulles et des erreurs, et savoir écrire une logique métier testée indépendante de l'interface.

Une association de commerçantes de Yaoundé gère sa tontine dans un cahier : chaque mois, les membres cotisent et l'une d'elles reçoit la cagnotte. Les erreurs de calcul créent des tensions, et l'association veut une application. Ce projet vous suivra jusqu'au sprint 7. Pour commencer, vous écrivez dans le langage de votre stack le cœur métier, sans aucun écran : membres, cycles, ordre de passage, cotisations attendues et versées, pénalités de retard, solde de chacun. Le code doit gérer les cas réels : une membre qui rejoint en cours de cycle, un échange de tour entre deux membres, une cotisation versée en deux fois. Vous accompagnez ce module de tests unitaires qui rejouent un cycle complet de douze mois. Le mentor évaluera la clarté du modèle et la façon dont vous traitez les valeurs absentes et les erreurs.

Construire des écrans avec le modèle déclaratif de la stack : composants réutilisables, mise en page adaptée aux différentes tailles d'écran, gestion de l'état d'affichage, thème cohérent et accessibilité de base.

L'association a validé le moteur de calcul. Elle a fait réaliser par une designer quelques maquettes : tableau de bord du cycle en cours, liste des membres avec leur situation, fiche d'une membre, historique des versements. Vous construisez ces écrans avec l'interface déclarative de votre stack, en les reliant au module métier du sprint 1 et à des données de démonstration. Vous créez des composants réutilisables (carte de membre, badge de statut, montant formaté en francs CFA) et un thème qui reprend les couleurs de l'association. Les écrans doivent rester lisibles sur un petit téléphone comme sur une tablette, avec des tailles de texte agrandies et en mode sombre. En soutenance, vous lancez l'application sur deux appareils de tailles différentes et vous montrez comment un changement de données met à jour l'affichage.

Structurer une application multi-écrans : graphe de navigation, passage de paramètres, retour arrière cohérent, et formulaires de saisie validés, confortables au clavier tactile et tolérants aux erreurs.

La trésorière de l'association veut pouvoir tout faire depuis son téléphone : créer un nouveau groupe, inviter des membres, définir l'ordre de passage et enregistrer chaque versement au moment où elle le reçoit, souvent debout au marché. Vous ajoutez la navigation de l'application : barre d'onglets, passage d'un groupe à ses membres puis à la fiche d'une membre, retour arrière prévisible, ouverture directe d'une fiche par un lien. Vous développez les formulaires de création de groupe, d'ajout de membre et d'enregistrement d'un versement, avec validation au fil de la saisie, clavier adapté à chaque champ et confirmation avant toute action irréversible. L'état des écrans doit survivre à une rotation ou à une mise en arrière-plan. Le mentor testera vos formulaires en saisissant volontairement des valeurs incohérentes.

Connecter l'application à un serveur : appels REST asynchrones, sérialisation, authentification par jeton, gestion des réseaux lents ou coupés, des erreurs et des états de chargement dans l'interface.

Plusieurs associations veulent utiliser Tontine+, et chaque membre souhaite consulter sa situation sur son propre téléphone. Une API de démonstration vous est fournie : connexion par code reçu par SMS simulé, groupes, membres, versements et notifications. Vous remplacez les données locales par des appels à cette API. Vous organisez le code en couches (accès réseau, dépôt de données, écrans) pour que l'interface ne dépende jamais directement du réseau. Vous gérez l'authentification et le renouvellement du jeton, les délais d'attente, les nouvelles tentatives raisonnables et les messages d'erreur compréhensibles. Chaque écran affiche clairement le chargement, l'absence de données et les erreurs. En soutenance, le mentor simulera une connexion 2G lente puis une coupure : l'application doit rester utilisable et honnête sur ce qu'elle affiche.

Rendre l'application fiable sans réseau : base de données locale, cache, file d'actions en attente, synchronisation au retour de la connexion et résolution des conflits, avec stockage sécurisé des données sensibles.

Les réunions de l'association se tiennent parfois dans une salle sans réseau. La trésorière doit pouvoir enregistrer les versements sur place, puis tout envoyer au serveur une fois rentrée. Vous ajoutez une base de données locale qui conserve groupes, membres et versements. L'application affiche d'abord les données locales, puis les met à jour quand le réseau répond. Les versements saisis hors ligne entrent dans une file d'attente, envoyée automatiquement au retour de la connexion, avec un indicateur visible pour chaque élément non synchronisé. Vous définissez une règle claire en cas de conflit, par exemple un versement modifié sur deux téléphones. Le jeton de session et les données personnelles sont stockés de façon chiffrée. Vous documentez la stratégie de synchronisation et ses limites, en langage compréhensible pour l'association.

Garantir la qualité de l'application : tests unitaires, tests d'interface et tests d'intégration, outils de débogage et de profilage, analyse des plantages et correction des fuites de mémoire et des lenteurs.

Une version de test circule dans trois associations. Les retours arrivent : un écran qui se fige sur un vieux téléphone, un total faux après une synchronisation, une liste qui saccade avec deux cents membres. Vous reproduisez et corrigez ces trois problèmes en vous appuyant sur les outils de débogage et de profilage de votre stack, et vous écrivez pour chacun un test qui empêche son retour. Vous complétez ensuite la stratégie de tests : tests unitaires des couches de données, tests d'interface des parcours principaux (connexion, enregistrement d'un versement, consultation du solde) et test de la synchronisation hors ligne. Vous intégrez un outil de remontée des plantages. Votre rapport décrit, pour chaque problème, le symptôme, la méthode d'enquête, la cause et la correction.

Préparer et automatiser la livraison : signature de l'application, variantes de build, pipeline d'intégration continue, fiche Play Store, publication sur une piste de test et suivi de la qualité après diffusion.

Les associations pilotes sont convaincues : Tontine+ doit être disponible sur le Play Store, et chaque correction doit pouvoir être livrée rapidement sans manipulation risquée. Vous configurez les variantes de l'application (développement, recette, production) avec leurs adresses d'API respectives, et la signature de la version de production, sans jamais placer les clés dans le dépôt. Vous mettez en place un pipeline qui, à chaque pull request, lance les tests et construit l'application, puis qui publie automatiquement une version sur une piste de test interne à chaque fusion. Vous préparez la fiche du Play Store : description, captures, politique de confidentialité et déclaration des données collectées. En soutenance, vous livrez une petite modification en direct et le mentor l'installe depuis la piste de test.

Réaliser une application Android à partir d'un besoin client réel issu d'une mission Formuloo, la livrer jusqu'à une piste de test du Play Store et la défendre devant un jury avec l'ensemble de son portfolio.

Ce dernier sprint vous confie un besoin client réel issu d'une mission Formuloo : une application mobile à créer ou une application existante à faire évoluer, par exemple pour une ONG de santé, une PME de livraison ou une plateforme de commerce en ligne. Vous recevez au début du sprint les maquettes, l'API ou sa documentation et les contraintes du client, anonymisées si nécessaire. Vous menez le projet comme en entreprise : reformulation du besoin, découpage en tickets, développement dans la stack choisie, fonctionnement hors ligne si le contexte l'exige, tests et livraison sur une piste de test. Le mentor tient le rôle de référent technique et un membre de l'équipe Formuloo celui du client. La soutenance finale se tient devant un jury : démonstration sur un appareil réel, présentation du portfolio des huit sprints et questions sur vos choix, vos compromis et vos pistes d'amélioration.