Macros et scan de code-barres (Open Food Facts)

[Kaz229]

Le journal alimentaire ne suivait que les calories, saisies à la main. Il suit maintenant les protéines, glucides et lipides, alimentés par le scan du code-barres des produits.

Ce que ça change

Données — Meal porte les trois macros, le code-barres et la quantité pesée. Migration Room 1 → 2 non destructive : les repas existants gardent leurs calories et se retrouvent avec des macros à zéro.

Open Food Facts — lecture de l'API v2, sans authentification mais avec le User-Agent identifiant l'app que leur politique d'usage exige. Les produits sont mis en cache dans Room : ça respecte la limite de 15 requêtes/min/IP et permet de retrouver un produit déjà scanné hors ligne. Un seul appel HTTP, donc HttpURLConnection — pas de client HTTP tiers embarqué.

Scan — CameraX + ML Kit groupé, donc aucune dépendance à Play Services. Permission caméra demandée à l'usage, et repli explicite vers la saisie manuelle dans les trois cas d'échec : produit inconnu, produit sans valeurs nutritionnelles, coupure réseau.

Interface — quantité en grammes avec apport recalculé en direct, objectifs de macros dans le profil, avancement affiché sur l'accueil et en tête du journal. La saisie libre accepte des macros optionnelles : mieux vaut une ligne avec seulement des calories qu'un repas non enregistré.

La promesse du README a changé

Le README annonçait « aucune donnée ne quitte le téléphone, pas de réseau ». Ce n'est plus vrai : un code-barres scanné est envoyé à Open Food Facts avec l'adresse IP. La promesse est corrigée et la portée exacte du réseau documentée — rien d'autre ne sort, ni séances, ni repas, ni poids. La licence ODbL des données est mentionnée.

Tests

• 14 tests unitaires : calcul des portions, règle 4/4/9, extraction du serving_size, parsing des réponses de l'API (complètes, partielles, absentes), repli kJ → kcal
• 5 tests instrumentés sur appareil, avec le vrai réseau : recherche, cache, enregistrement, agrégation des macros. Une coupure de connexion ne fait pas échouer le build, mais l'abandon est tracé dans logcat — sans quoi un test vert masquerait une API cassée.

Vérifié sur émulateur : la migration a été réellement exercée sur une base v1 existante, et l'API a réellement répondu (Found(Nutella, 539 kcal, P 6.3, G 57.5, L 30.9, fromCache=false), puis fromCache=true au second appel).

Avant de fusionner

• Valider le scan de code-barres sur un appareil réel #1 — le scan n'a jamais été exercé avec un vrai code-barres. L'aperçu caméra fonctionne et la chaîne OFF est validée, mais la caméra virtuelle de l'émulateur ne permet pas de présenter une image à la demande. À valider sur téléphone.
• Trancher l'usage des médias Gym visual : licence et dépôt public #2 — question Gym visual, sans rapport direct avec cette PR mais ouverte sur le même périmètre
• Réduire le poids de l'APK : minification et split par ABI #3 — l'APK de debug passe de 17 à 40 Mo : le moteur de ML Kit est embarqué pour les quatre architectures

Un bug corrigé en route

Le premier bindToLifecycle se trouvait dans le update d'AndroidView, donc rejoué à chaque recomposition : la caméra s'ouvrait et se refermait en boucle et l'aperçu restait noir. Le binding est désormais fait une fois pour la vie de l'écran, avec libération explicite à la sortie.

🤖 Generated with Claude Code