Redface 2 — Réécriture du client Android HFR [Etape 0 : specs & archi]

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Redface 2 — Réécriture du client Android HFR [Etape 0 : specs & archi]

garath_

Reprise du message précédent :
Ça me fait penser que je vais commencer un nouveau job sur lequel je ne maîtrise pas la stack techno.
Je crois que je vais me prendre un abonnement Claude pro pour la période d'essai [:transparency]

---------------
HFR Links Preview | HFR Giphy

Publicité

XaTriX

En dev android ?

---------------
Proxytaf ? non rien

garath_

Non, middleware embarqué

---------------
HFR Links Preview | HFR Giphy

XaTriX

ok pas du tout hs mais tu peux rester

@ezzz, tu penses quoi du KMP ? https://kotlinlang.org/multiplatform/

Message cité 1 fois

---------------
Proxytaf ? non rien

Je@nb

Kindly give dime

Drapal

Jileo

Bonjour [:gaga drapal]

XaTriX

Le genre de prompt utilisé pour travailler:

Spoiler :

# Prompt : Revue d'audit architecture + génération de règles LLM

## Contexte

Tu travailles sur le repo **ForumHFR/redface2** (`/work/xaat/redface2/`), un projet de spécifications pour un client Android HFR (forum.hardware.fr). Le projet est en phase spec — aucun code applicatif, uniquement des docs (Jekyll + GitHub Pages dans `docs/`).

Un audit architecture (issue #14) a été réalisé : 26 points identifiés, des propositions détaillées dans un commentaire, puis les corrections appliquées en 3 commits. Tu dois vérifier la qualité de tout ce processus.

## Mission

### Partie 1 — Vérification de l'audit

Compare **systématiquement** ces 3 sources pour chaque point :

1. **L'issue #14** : `gh issue view 14 -R ForumHFR/redface2`
2. **Le commentaire de propositions** : `gh api repos/ForumHFR/redface2/issues/14/comments`
3. **Le code actuel** : les fichiers dans `docs/`

Pour chaque point (1 à 26), vérifie :

- [ ] Le problème identifié dans l'issue est **réel** (pas un faux positif)
- [ ] La proposition dans le commentaire est **cohérente** avec le problème
- [ ] La correction appliquée dans les docs **correspond** à la proposition
- [ ] La correction est **techniquement correcte** (pas d'erreur Kotlin, pas de mermaid cassé, pas d'incohérence avec le reste des docs)
- [ ] La correction **ne casse rien** d'autre dans les specs (effet de bord)

Signale :
- Les points où la proposition était bonne mais l'application est incomplète ou divergente
- Les points où la proposition elle-même est discutable (over-engineering, mauvais choix technique, incohérence)
- Les effets de bord non anticipés (un changement dans models.md qui devrait se refléter dans mvi.md mais ne l'est pas, etc.)
- Les incohérences entre fichiers (un champ ajouté dans un fichier mais pas utilisé/référencé dans un autre)

### Partie 2 — Évaluation de la démarche

Évalue la **qualité du processus** (pas juste le résultat) :

1. **L'audit initial** : les 26 points étaient-ils bien priorisés ? Des choses ont-elles été manquées ? Des faux positifs ?
2. **Les propositions** : sont-elles pragmatiques ou over-engineered ? Les alternatives écartées étaient-elles correctement évaluées ?
3. **L'application** : est-ce que le code reflète fidèlement les propositions ? Les commits sont-ils bien découpés et documentés ?
4. **La cohérence globale** : après toutes les modifications, est-ce que l'ensemble des specs forme un tout cohérent, ou y a-t-il des contradictions introduites ?

### Partie 3 — Génération de règles LLM

À partir de cette expérience (audit → propositions → corrections → review), génère des **règles de travail pour LLM** à inscrire dans le `CLAUDE.md` du repo (ou équivalent). Ces règles doivent couvrir :

**Architecture & conception :**
- Comment proposer des changements d'architecture (toujours issue d'abord, jamais en direct)
- Comment évaluer si un changement est over-engineered vs nécessaire
- Quand demander un avis humain vs décider seul
- Comment gérer les dépendances inter-fichiers dans les specs (un changement dans models.md doit être propagé dans mvi.md, architecture.md, etc.)

**Qualité du code/specs :**
- Vérifier la cohérence inter-fichiers après chaque modification
- Les exemples de code dans les specs doivent être compilables conceptuellement (types corrects, imports cohérents)
- Les diagrammes mermaid doivent refléter exactement le texte qui les entoure
- Ne jamais utiliser de propriétés/méthodes inexistantes dans les exemples (cf. bug `uri.cat`)

**Process d'audit :**
- Comment structurer un audit (sévérité, catégories, format)
- Toujours proposer un fix concret, pas juste signaler le problème
- Toujours vérifier ses propres corrections avant de les pousser (self-review)
- Utiliser un agent reviewer séparé pour la vérification (pas de self-validation)

**Attribution & traçabilité :**
- Règles de `Co-Authored-By` avec modèle exact
- Format de commentaire d'issue (qui a demandé, qui a exécuté)
- Commit messages détaillés listant les points d'audit traités

**Règles spécifiques au projet :**
- HFR BBCode : `[fixed]` est block-only, jamais inline
- Pas de smileys non vérifiés (`:fleche:`, `:flechd:` n'existent pas)
- Français avec accents dans les docs, anglais dans le code
- `numreponse` est unique par catégorie, pas globalement — la clé est `(cat, numreponse)`

Formule ces règles de façon concise, actionnable, et directement intégrable dans un fichier `CLAUDE.md` ou `AGENTS.md`.

### Partie 4 — Commentaire de clôture sur l'issue

Rédige un commentaire à poster sur l'issue #14 qui :
- Résume ce qui a été fait (3 commits, 26/26 points)
- Liste les fichiers modifiés
- Mentionne les corrections bonus trouvées par la review (Poll, Bookmark, uri.getQueryParameter, :feature: search, etc.)
- Indique les éventuels points restants ou à surveiller
- Pose la question : faut-il fermer l'issue ou la garder ouverte comme référence ?

Format : `gh issue comment 14 -R ForumHFR/redface2 --body "..."`

Attribution : `> Revue finale par Claude (demandé par @XaaT)`

## Contraintes

- Lis TOUS les fichiers concernés avant de répondre. Ne devine pas.
- Lis l'issue ET ses commentaires via `gh`.
- Sois critique — le but est de trouver ce qui ne va pas, pas de valider.
- Les règles LLM doivent être testables/vérifiables, pas des platitudes.
- Le commentaire d'issue doit être concis (pas de wall of text).

Message cité 1 fois

---------------
Proxytaf ? non rien

Tronklou

❤❤ Vrp Bambulab à mi-temps ❤❤

[:spaydar]

---------------
Victime de girafophobie, mais se soigne.

Dintr-un lemn

in medio stat virtus

XaTriX a écrit :

Le genre de prompt utilisé pour travailler:

Spoiler :

# Prompt : Revue d'audit architecture + génération de règles LLM

## Contexte

Tu travailles sur le repo **ForumHFR/redface2** (`/work/xaat/redface2/`), un projet de spécifications pour un client Android HFR (forum.hardware.fr). Le projet est en phase spec — aucun code applicatif, uniquement des docs (Jekyll + GitHub Pages dans `docs/`).

Un audit architecture (issue #14) a été réalisé : 26 points identifiés, des propositions détaillées dans un commentaire, puis les corrections appliquées en 3 commits. Tu dois vérifier la qualité de tout ce processus.

## Mission

### Partie 1 — Vérification de l'audit

Compare **systématiquement** ces 3 sources pour chaque point :

1. **L'issue #14** : `gh issue view 14 -R ForumHFR/redface2`
2. **Le commentaire de propositions** : `gh api repos/ForumHFR/redface2/issues/14/comments`
3. **Le code actuel** : les fichiers dans `docs/`

Pour chaque point (1 à 26), vérifie :

- [ ] Le problème identifié dans l'issue est **réel** (pas un faux positif)
- [ ] La proposition dans le commentaire est **cohérente** avec le problème
- [ ] La correction appliquée dans les docs **correspond** à la proposition
- [ ] La correction est **techniquement correcte** (pas d'erreur Kotlin, pas de mermaid cassé, pas d'incohérence avec le reste des docs)
- [ ] La correction **ne casse rien** d'autre dans les specs (effet de bord)

Signale :
- Les points où la proposition était bonne mais l'application est incomplète ou divergente
- Les points où la proposition elle-même est discutable (over-engineering, mauvais choix technique, incohérence)
- Les effets de bord non anticipés (un changement dans models.md qui devrait se refléter dans mvi.md mais ne l'est pas, etc.)
- Les incohérences entre fichiers (un champ ajouté dans un fichier mais pas utilisé/référencé dans un autre)

### Partie 2 — Évaluation de la démarche

Évalue la **qualité du processus** (pas juste le résultat) :

1. **L'audit initial** : les 26 points étaient-ils bien priorisés ? Des choses ont-elles été manquées ? Des faux positifs ?
2. **Les propositions** : sont-elles pragmatiques ou over-engineered ? Les alternatives écartées étaient-elles correctement évaluées ?
3. **L'application** : est-ce que le code reflète fidèlement les propositions ? Les commits sont-ils bien découpés et documentés ?
4. **La cohérence globale** : après toutes les modifications, est-ce que l'ensemble des specs forme un tout cohérent, ou y a-t-il des contradictions introduites ?

### Partie 3 — Génération de règles LLM

À partir de cette expérience (audit → propositions → corrections → review), génère des **règles de travail pour LLM** à inscrire dans le `CLAUDE.md` du repo (ou équivalent). Ces règles doivent couvrir :

**Architecture & conception :**
- Comment proposer des changements d'architecture (toujours issue d'abord, jamais en direct)
- Comment évaluer si un changement est over-engineered vs nécessaire
- Quand demander un avis humain vs décider seul
- Comment gérer les dépendances inter-fichiers dans les specs (un changement dans models.md doit être propagé dans mvi.md, architecture.md, etc.)

**Qualité du code/specs :**
- Vérifier la cohérence inter-fichiers après chaque modification
- Les exemples de code dans les specs doivent être compilables conceptuellement (types corrects, imports cohérents)
- Les diagrammes mermaid doivent refléter exactement le texte qui les entoure
- Ne jamais utiliser de propriétés/méthodes inexistantes dans les exemples (cf. bug `uri.cat`)

**Process d'audit :**
- Comment structurer un audit (sévérité, catégories, format)
- Toujours proposer un fix concret, pas juste signaler le problème
- Toujours vérifier ses propres corrections avant de les pousser (self-review)
- Utiliser un agent reviewer séparé pour la vérification (pas de self-validation)

**Attribution & traçabilité :**
- Règles de `Co-Authored-By` avec modèle exact
- Format de commentaire d'issue (qui a demandé, qui a exécuté)
- Commit messages détaillés listant les points d'audit traités

**Règles spécifiques au projet :**
- HFR BBCode : `[fixed]` est block-only, jamais inline
- Pas de smileys non vérifiés (`:fleche:`, `:flechd:` n'existent pas)
- Français avec accents dans les docs, anglais dans le code
- `numreponse` est unique par catégorie, pas globalement — la clé est `(cat, numreponse)`

Formule ces règles de façon concise, actionnable, et directement intégrable dans un fichier `CLAUDE.md` ou `AGENTS.md`.

### Partie 4 — Commentaire de clôture sur l'issue

Rédige un commentaire à poster sur l'issue #14 qui :
- Résume ce qui a été fait (3 commits, 26/26 points)
- Liste les fichiers modifiés
- Mentionne les corrections bonus trouvées par la review (Poll, Bookmark, uri.getQueryParameter, :feature: search, etc.)
- Indique les éventuels points restants ou à surveiller
- Pose la question : faut-il fermer l'issue ou la garder ouverte comme référence ?

Format : `gh issue comment 14 -R ForumHFR/redface2 --body "..."`

Attribution : `> Revue finale par Claude (demandé par @XaaT)`

## Contraintes

- Lis TOUS les fichiers concernés avant de répondre. Ne devine pas.
- Lis l'issue ET ses commentaires via `gh`.
- Sois critique — le but est de trouver ce qui ne va pas, pas de valider.
- Les règles LLM doivent être testables/vérifiables, pas des platitudes.
- Le commentaire d'issue doit être concis (pas de wall of text).

Je n'imaginais pas qu'un prompt pouvait être aussi complexe [:wam]

muzah

Bal Musette @ HFR depuis 1997

Ce sera en licence libre j'espère

---------------
un instant monsieur ça-va-chier

Publicité

muzah

Bal Musette @ HFR depuis 1997

Ce sera en licence libre j'espère

---------------
un instant monsieur ça-va-chier

XaTriX

paiement libre mais nécéssaire

---------------
Proxytaf ? non rien

XaTriX

Specs 0.3.0 sorties : https://forumhfr.github.io/redface2/
Après l'audit #1, son issues, commentaire pour prendre des décisions et les 26 points traités : https://github.com/ForumHFR/redface2/issues/14

Maintenant les remarques Corran Horn et on peut avancer sur le choix de la stack !

---------------
Proxytaf ? non rien

XaTriX

Corran Horn a écrit :

ah oui j'avais pas vu que ça avait été poussé aussi loin la spec :jap:

je reste en désaccord pour la DI Koin est KMP, peut depuis les dernières versions générer le graphe au compil time et donc plus de crash au runtime.
sinon pour le reste ça a l'air d'être effectivement à l'état de l'art et le schéma d'archi reste assez simple et le MVI qu'il décrit se rapproche techniquement plus de ce que j'appelle un MVVM sur Android mais c'est de la terminologie, tant que l'implem est ok :jap:

le truc qui manque, je trouve, c'est vraiment l'approche KMP du projet dans sa globalité. après c'est pas une obligation mais je trouve ça intéressant parce que demain on pourrait faire des applis desktop ou des front webs super facilement par exemple.
un point non abordé également dans la spec c'est la partie TU. imho faut rester sur du JUnit 4, Mockk et Robolectric quand on peut pas mocker nous même les composants android. et faut une couverture de 100% pour les modules "métier" à savoir la partie DB, parsing et les classes de type VM.

en tout cas jpense qu'il est sur des bons rails. je sais pas si tu lui as déjà donné à manger le code d'Ayuget mais il y a clairement bcp de choses à reprendre dans la logique de parsing (tous le edge cases de merde, mais jpense ils sont déjà présents dans les TU) et dans la gestion de chargement des pages suivantes/passées (en utilisant un cookie d'un compte anonyme pour pas péter les drapeaux). faudra vraiment que tu challenges l'ia sur cette partie imho

Merci pour la review et les retours, c'est exactement pour ça qu'on pousse les specs avant le code :jap:

J'ai fait une analyse point par point avec recherches, c'est détaillé dans l'issue #2 : Analyse complète sur GitHub

Voici le topo :

Koin vs Hilt
T'as raison sur le compile-time safety, le Koin compiler plugin K2 (1.0.0-RC1) règle le problème historique. On garde Hilt pour l'instant (intégration Jetpack native, plus de contributeurs qui connaissent) mais on documente Koin comme alternative viable dans les specs. Si on part KMP un jour, Koin deviendra le choix naturel.

KMP
L'idée est bonne mais le bloqueur principal c'est Jsoup : y'a pas d'équivalent KMP mature pour parser du HTML aussi robuste. On a déjà préparé le terrain : le parser et les modèles sont dans des modules purs Kotlin/JVM sans dépendance Android. Le jour où on veut faire du KMP, c'est un refactor de dépendances, pas une réécriture. Mais pour la v1, Android natif.

MVI / MVVM
Tu as mis le doigt dessus, c'est de la terminologie. Ce qu'on décrit (StateFlow + sealed interface Intent + Channel Effect) c'est du MVVM + UDF, que certains appellent MVI. Le code est le même. On va clarifier dans les specs pour éviter la confusion.

Modules / Clean arch
Now in Android de Google c'est 60+ modules, Pocket Casts c'est 37. Nos 23 sont dans la norme. Mais les 8 modules extension (bookmarks, blacklist, etc.) arrivent en Phase 4, donc en pratique c'est 15 modules pour les Phases 0-3.

Tests
100% d'accord, c'était le trou dans les specs. On adopte JUnit 4 + MockK + Robolectric + Turbine (pour les Flow). Couverture 100% sur parser, DB et ViewModels. C'est ajouté dans contributing.md.

Code d'Ayuget
Pas encore donné à manger mais c'est prévu. Y'a 10 transformers, 17 fixtures HTML et 13 tests dans Redface v1, c'est une base solide pour les edge cases de parsing HFR. On va reprendre les fixtures comme point de départ pour les tests du parser.

Prefetch sans auth
Déjà prévu dans les specs, client OkHttp non authentifié pour le prefetch pour éviter de marquer les drapeaux comme lus :jap:

N'hésite pas à commenter directement sur l'issue GitHub si tu veux creuser un point, tout est ouvert.

Réponse rédigée par Claude Opus 4.6

Message cité 1 fois
Message édité par XaTriX le 12-04-2026 à 12:37:00

---------------
Proxytaf ? non rien

antiseptiqueIncolore

zzzzzzzzzdjhgdfcjdsc zedufkgkz

Puisque tu nous demande notre avis et une comparaison avev HFR4droid Si le mode compact pouvait être vraiment compact
En mode non connecté, pas de drapeaux, rien:

Message cité 1 fois
Message édité par antiseptiqueIncolore le 12-04-2026 à 12:38:48

---------------
-------------

XaTriX

antiseptiqueIncolore a écrit :

Puisque tu nous demande notre avis et une comparaison avev HFR4droid Si le mode compact pouvait être vraiment compact
En mode non connecté, pas de drapeaux, rien:
https://rehost.diberie.com/Picture/Get/t/505331
https://rehost.diberie.com/Picture/Get/t/505332

Faut voir quoi ?

---------------
Proxytaf ? non rien

antiseptiqueIncolore

zzzzzzzzzdjhgdfcjdsc zedufkgkz

Sur HFR4droid, on peut lire beaucoup plus de texte sur chaque ligne

---------------
-------------

XaTriX

Ok ça peut se faire facilement ça

---------------
Proxytaf ? non rien

Tronklou

❤❤ Vrp Bambulab à mi-temps ❤❤

C'est possible d'ajouter des options correspondant a certains scrypt populaires du forum ?
https://forum.hardware.fr/hfr/Discu [...] 6015_1.htm

:jap:

Message cité 1 fois

---------------
Victime de girafophobie, mais se soigne.

XaTriX

Tronklou a écrit :

C'est possible d'ajouter des options correspondant a certains scrypt populaires du forum ?
https://forum.hardware.fr/hfr/Discu [...] 6015_1.htm

:jap:

https://forumhfr.github.io/redface2/features.html

---------------
Proxytaf ? non rien

Tronklou

❤❤ Vrp Bambulab à mi-temps ❤❤

Non mais c'est pour être sûr ( j'ai honte :sweat: :fou: )

Merci :jap:

---------------
Victime de girafophobie, mais se soigne.

XaTriX

On peut discuter de cette liste, si y'a des trucs à rajouter, à virer.. ça reste très préliminaire tout ça

---------------
Proxytaf ? non rien

Corran Horn

lol

XaTriX a écrit :

Merci pour la review et les retours, c'est exactement pour ça qu'on pousse les specs avant le code :jap:

J'ai fait une analyse point par point avec recherches, c'est détaillé dans l'issue #2 : Analyse complète sur GitHub

Voici le topo :

Koin vs Hilt
T'as raison sur le compile-time safety, le Koin compiler plugin K2 (1.0.0-RC1) règle le problème historique. On garde Hilt pour l'instant (intégration Jetpack native, plus de contributeurs qui connaissent) mais on documente Koin comme alternative viable dans les specs. Si on part KMP un jour, Koin deviendra le choix naturel.

KMP
L'idée est bonne mais le bloqueur principal c'est Jsoup : y'a pas d'équivalent KMP mature pour parser du HTML aussi robuste. On a déjà préparé le terrain : le parser et les modèles sont dans des modules purs Kotlin/JVM sans dépendance Android. Le jour où on veut faire du KMP, c'est un refactor de dépendances, pas une réécriture. Mais pour la v1, Android natif.

MVI / MVVM
Tu as mis le doigt dessus, c'est de la terminologie. Ce qu'on décrit (StateFlow + sealed interface Intent + Channel Effect) c'est du MVVM + UDF, que certains appellent MVI. Le code est le même. On va clarifier dans les specs pour éviter la confusion.

Modules / Clean arch
Now in Android de Google c'est 60+ modules, Pocket Casts c'est 37. Nos 23 sont dans la norme. Mais les 8 modules extension (bookmarks, blacklist, etc.) arrivent en Phase 4, donc en pratique c'est 15 modules pour les Phases 0-3.

Tests
100% d'accord, c'était le trou dans les specs. On adopte JUnit 4 + MockK + Robolectric + Turbine (pour les Flow). Couverture 100% sur parser, DB et ViewModels. C'est ajouté dans contributing.md.

Code d'Ayuget
Pas encore donné à manger mais c'est prévu. Y'a 10 transformers, 17 fixtures HTML et 13 tests dans Redface v1, c'est une base solide pour les edge cases de parsing HFR. On va reprendre les fixtures comme point de départ pour les tests du parser.

Prefetch sans auth
Déjà prévu dans les specs, client OkHttp non authentifié pour le prefetch pour éviter de marquer les drapeaux comme lus :jap:

N'hésite pas à commenter directement sur l'issue GitHub si tu veux creuser un point, tout est ouvert.

Réponse rédigée par Claude Opus 4.6

ok je comprends les choix, c'est effectivement assez cohérent. effectivement dommage pour jsoup mais bon on fait une appli pour des nerds de 50 balais, yaura ptet plus besoin de l'appli dans 10ans

ya juste le nombre de modules où j'ai peur que ce soit ptet over-engineered par rapport à la taille du projet mais rien de franchement problématique, on est plus dans les préférences persos

je pense que t'as une bonne base de travail, si jamais j'arrive à trouver un peu de temps quand t'auras commencé les premiers modules je pourrais ptet prendre du temps pour faire un peu de revue de code. ça me rappelle un peu le taff pq j'ai aussi fait de la revue chez nous pour un dev back qui s'est mis au KMP full vibe coding
tu viens de quelles technos ? pour que j'ai un peu de contexte sur ton bagage
et t'as des tokens par ton taff ou tu paies de ta poche ?

en tout cas si ya un mcp hfr ça va énormément aider pour les reproductions de bugs et explorations d'edge case. ya aussi un mcp qui marche avec android/adb pour gemini (mais j'imagine qu'il doit exister l'équivalent pour Claude), tu lances un simulateur ou tu branches un device et tu peux lui décrire les bugs à tenter de reproduire.

je repense également à un truc, mais ça pourrait être intéressant de mettre en place un système de thème à partir d'un fichier yaml pour que chaque barbu du forum puisse se faire un thème aux petits oignons en passant par les couleurs, les espacements et pourquoi pas des set d'icones. vu que derrière c'est du jetpack compose ça s'intègrera super facilement. perso je m'en fous pour mon usage mais ça pourrait enfin faire migrer les fossiles d'hfr4droid

Message cité 2 fois

XaTriX

Corran Horn a écrit :

Pour Jsoup, l'équivalent est Ksoup on dirait, voir la réponse sur l'issue citée. Je sais pas si c'est ultra stable mais c'est noté.

Ok pour les modules

Moi je suis sysadmin/ingé sys/ingé réseau/devops/lead infra, bref j'évolue mais je suis pas un vrai dev. dans ma formation d'ingé j'ai fait de l'algo etc mais pas vraiment de pattern de dev et mon xp sur android est faible mais je maitraise mon claude d'amour [:calimefrog:5]

je paie les abo

le mcp hfr est là https://github.com/XaaT/hfr-mcp il avance peinard mais ouais avec un mcp je n sais quoi sui dirige une vm android ou autre, on va pouvoir avoir une boucle de feedback et le laisser faire son taf

j'sais pas, p'tet pour ton truc de theme yaml, pour partager alors ? parce que sinon des réglages fins pourront faire un truc du genre non ? bref pas fermé de toute façon !

j'intègre ta réponse et je le laisse maj les specs avec ce qu'il 'avait déjà prévu avec ton feedback

---------------
Proxytaf ? non rien

ezzz

XaTriX a écrit :

ok pas du tout hs mais tu peux rester

@ezzz, tu penses quoi du KMP ? https://kotlinlang.org/multiplatform/

C’est pas adapté à notre cas je trouve
Si tu pars de 0 avec plein de moyens et que tu veux faire une nouvelle app multiplateforme ok mais perso je suis pas dans ce délire, je suis pas une équipe de 15 devs même avec de l’ia
Et puis j’ai pas creusé mais je doute que ça soit aussi bien fini qu’une app iOS native avec toutes les spécificités que ça suppose.

Message cité 1 fois

---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk

XaTriX

---------------
Proxytaf ? non rien

Corran Horn

lol

ezzz a écrit :

j'avais pas forcément en tête de faire du cross avec iOS. mais si jamais ça t'intéresse, le KMP s'intègre bien dans une codebase iOS quand t'as un module métier (en gros tu t'arrêtes à la couche repository) que t'intègres comme dépendance native dans ton projet. mais t'as tout intérêt à utiliser swift ui et le MVVM iOS derrière pour avoir le meilleur des deux mondes.

dans notre cas ça aurait ptet de l'intérêt pour mutualiser la partie query http/parsing, prefs utilisateur et DB mais guère plus.

Message cité 1 fois
Message édité par Corran Horn le 12-04-2026 à 17:00:14

XaTriX

Maj spec : https://github.com/ForumHFR/redface [...] 03f8132646

Bon va falloir faire le tour des fixtures et checker les use cases / edge moisi sur les parser de RF1 et hfr4droid voir l'app ios

---------------
Proxytaf ? non rien

Dintr-un lemn

in medio stat virtus

Corran Horn a écrit :

[…] on fait une appli pour des nerds de 50 balais, yaura ptet plus besoin de l'appli dans 10ans […]

La violence [:profil horrible:2]

ezzz

surtout que c'est n'imp, y aura des nerds de 60 balais

---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk

ezzz

Corran Horn a écrit :

j'avais pas forcément en tête de faire du cross avec iOS mais si jamais le KMP s'intègre bien dans une codebase iOS quand t'as un module métier (en gros tu t'arrêtes à la couche repository) que t'intègres comme dépendance native dans ton projet. mais t'as tout intérêt à utiliser swift ui et le MVVM iOS derrière pour avoir le meilleur des deux mondes.

dans notre cas ça aurait ptet de l'intérêt pour mutualiser la partie query http/parsing, prefs utilisateur et DB mais guère plus.

:jap:

---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk

LaRoueEstTombee

Hortense ! Pour moi !

[:abakuk]

---------------
Votre couroux impitoiable Veut-il renverser l'Univers ?

nicko

Drapal

XaTriX

Bon bah en cours

* développement des skills pour bien dev et s'orga dans le repo
-> plus largement des guidelines pour le dev avec llm
* injection/query-docs à jour prévue avec context7 ou autre, toute la stack est supporté
-> opus 4.6 et codex 5.4 en discutent
* 2eme audit des specs/repo
* élargissemetn des fixtures par rapport à rf1 pour couvrir plus large même si on va pas forcémnet utiliser toutes les fonctionnalités, voir dans contributing https://forumhfr.github.io/redface2/contributing
-> j'ai aussi rajouté une vieile doc sur un sdk md.net
* continuer sur les specs "protocole HFR"/données/parsing avant les fonctionnels

---------------
Proxytaf ? non rien

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Technologies Mobiles

Android

Redface 2 — Réécriture du client Android HFR [Etape 0 : specs & archi]

Sujets relatifs
Droid2PC : continuité Android vers Mac sans workflow cloud imposé	La "prison" android.....
Passer d’un iPhone 12 à Android : oui mais lequel ?	Android va devenir une plateforme fermée au mois de septembre
[Aide] Choix téléphone Android après IOS	Choix clavier souris bluetooth pour tablette android
Résolu - Gmail android plus de synchro plus de notification	Linux versus AOSP : android va t-il rester OpenSource éternellement?
Que faire avec un smartphone dont l'OS Android est abandonné ?	ANDROID/REDMI/ Xiaomi [RESOLU] Car j'étais résolu
Plus de sujets relatifs à : Redface 2 — Réécriture du client Android HFR [Etape 0 : specs & archi]

Page générée en 0.102 secondes