Redface 2 — réécriture Android moderne du client HFR
 
Redface 2 est une réécriture complète de Redface pour Android : Kotlin, Jetpack Compose, architecture MVI, rendu natif des posts HFR, sans WebView pour la lecture.
 
Le but n'est pas de faire une démo technique, mais de retrouver un client HFR utilisable au quotidien : drapeaux, topics, écriture, MPs, recherche, médias, puis les features communautaires utiles.
 
État actuel — alpha lecture
 
Phase 0 et Phase 1 sont livrées.
 
Build courant : v36 / 0.1.0-phase1.5
Android minimum : Android 10 / API 29
Repo : https://github.com/ForumHFR/redface2
Specs : https://forumhfr.github.io/redface2/
Roadmap : https://forumhfr.github.io/redface2/specs/roadmap
Releases APK/AAB : https://github.com/ForumHFR/redface2/releases
Dernière release : https://github.com/ForumHFR/redface [...] ag/app-v36
Issues : https://github.com/ForumHFR/redface2/issues
 
Installation / test
 
- Play Store : test fermé alpha, ajout manuel des testeurs via email Google.
- GitHub : APK disponible dans les releases pour sideload.
- Attention : c'est une alpha. Ça lit déjà de vrais topics, mais tout n'est pas fini ni poli.
 
Lien Play Store, visible seulement pour les testeurs inscrits :
https://play.google.com/store/apps/ [...] r.redface2
 
Ce qui marche déjà
 
- Login HFR avec cookies persistants.
- Drapeaux réels via API REST HFR : mes sujets, lus uniquement, favoris.
- Forum / catégories / sous-catégories / listes de topics via API REST.
- Lecture réelle de topic HFR.
- Pagination longue des topics, navigation page précédente / suivante, aller à une page.
- Deep links HFR vers topic / page / post quand Android laisse l'app gérer le lien.
- Cache Room avec TTL, isolation par compte, purge logout / changement de compte.
- Prefetch anonyme des pages suivantes pour éviter de marquer les drapeaux comme lus.
- Rendu natif Compose des posts : texte, liens, citations, spoilers, couleurs, fixed/code, images, GIFs, smileys builtin et smileys perso.
- Pipeline release : APK/AAB signés automatiquement sur GitHub releases, upload Play Console alpha possible.
 
Ce qui ne marche pas encore
 
- Pas encore de réponse / quote / edit / création de topic dans l'app.
- Pas encore de MPs.
- Pas encore de vraie recherche HFR complète.
- Le rendu des posts reste en dogfood : HFR a des vieux cas HTML/BBCode bien sales.
- Les smileys perso sont utilisables, mais pas parfaits : le compromis actuel est 70x50 / Fit après crawl du wikismilies.
- Le retrait de drapeau depuis l'app est encore à faire.
- Les deep links https dépendent des limitations Android / Play Store quand on ne contrôle pas le domaine forum.hardware.fr.
 
Pourquoi une réécriture ?
 
Redface v1 a rendu service pendant des années, mais la stack est trop ancienne pour évoluer proprement : Java, XML, Retrofit 1.9, RxJava 1, ButterKnife, Otto, vieilles APIs Android.
 
Redface 2 repart sur une base actuelle :
 
- Kotlin
- Jetpack Compose
- Material 3
- MVI / StateFlow
- Hilt + KSP
- OkHttp 5
- Room
- Coil 3
- Coroutines + Flow
- Jsoup pour les pages HTML encore nécessaires
- API REST MesDiscussions quand elle existe et fonctionne
 
Licence : GPL-3.0-only.
 
Roadmap courte
 
Phase 0 — Bootstrap : livrée
Gradle multi-modules, CI, thème Material 3, Hilt, navigation, build signé.
 
Phase 1 — Lecture : livrée
Login, drapeaux, forum, topic, cache, prefetch, rendu natif des posts, images/smileys, release alpha.
 
Phase 2 — Écriture : en cours de préparation
Plan complet : https://github.com/ForumHFR/redface2/issues/151
 
Découpage prévu :
 
- 2A : vérifier le protocole réel HFR pour l'écriture.
- 2B : construire le socle éditeur, toolbar BBCode, preview.
- 2C : répondre et citer dans un topic.
- 2D : éditer un post puis le first post.
- 2E : créer un topic.
- 2F : médias éditeur, smileys, upload/rehost, dogfood rendu.
- 2G : retirer un drapeau et vraie recherche HFR.
- 2H : mesures perf, microbench/macrobench, boucle de test Android plus autonome.
 
Phase 3 — Messages
MPs classiques, MultiMPs, MPStorage, notifications.
 
Phase 4 — Extensions communautaires
Bookmarks, blacklist, Qualitay, Redflag, architecture d'extensions.
 
Phase 5 — Polish / distribution
F-Droid, deep links, offline, notifications, widgets, thèmes, release grand public.
 
Sujets ouverts importants
 
Plan Phase 2 : https://github.com/ForumHFR/redface2/issues/151
Reply MVP : https://github.com/ForumHFR/redface2/issues/145
Quote MVP : https://github.com/ForumHFR/redface2/issues/146
Éditeur : https://github.com/ForumHFR/redface2/issues/86
Toolbar / preview : https://github.com/ForumHFR/redface2/issues/144
Médias éditeur : https://github.com/ForumHFR/redface2/issues/11
Recherche HFR : https://github.com/ForumHFR/redface2/issues/150
Deep links / domaine non vérifiable : https://github.com/ForumHFR/redface2/issues/127
F-Droid : https://github.com/ForumHFR/redface2/issues/137
 
Comment aider
 
- Tester l'alpha et remonter les bugs avec topic + page + post + version de l'app.
- Poster des cas BBCode tordus ici : citations imbriquées, code, fixed, spoilers, liens, images, GIFs, smileys.
- Relire les PRs si vous avez un compte GitHub.
- Commenter les issues quand vous connaissez le comportement réel de HFR.
- Comparer le rendu RF2 avec le rendu web HFR et signaler les écarts importants.
 
Infos utiles pour les retours
 
Quand vous remontez un bug, idéalement donnez :
 
- version RF2, par exemple v36 / 0.1.0-phase1.5 ;
- modèle de téléphone et version Android ;
- topic + page + numéro de post si possible ;
- action faite juste avant le crash / freeze / bug visuel ;
- capture d'écran si c'est un problème de rendu.
 
Remerciements
 
Merci à Ayuget pour Redface v1, à ezzz pour l'app iOS et les retours, aux auteurs de userscripts HFR, aux testeurs du topic, et à tous ceux qui postent volontairement des trucs immondes pour casser le parser.
 
Post par GPT-5 Codex

le bot qui fait un post pourrave
 
absolument tout est sujet à modification
 
étape actuelle : spec et faisabilité du projet

opus (claude) a fait des trucs un peu rapidos, c'est normal, premier jet, faut affiner avec le temps
 
=> le plus important pour l'instant c'est de valider la stack technique et l'archi

Audit architecture v0.2.0

Grosse revue des specs Issue #14

Les 9 pages de spécifications ont été passées au peigne fin. 26 points remontés, dont 6 critiques.

Les gros morceaux :

• Le diagramme d'architecture montre une dépendance réseau → parser qui n'existe pas dans le code (c'est le repository qui orchestre les deux)
• La couche "Domaine" revendiquée dans l'archi n'a pas de module Gradle — les 3 couches ne sont pas enforcées à la compilation
• Plusieurs bugs dans les exemples MVI (champ utilisé mais jamais défini, unreadCount passé comme numéro de page, mise à jour optimiste sans rollback)
• Le deep linking vers un post précis via #t{numreponse} n'est pas supporté par Compose Navigation — il faudra un traitement custom
• Des champs manquants dans les modèles de données pour supporter les features communautaires (Ego Quote, Color Tag, Blacklist)
• Aucune stratégie documentée pour la sécurité (stockage des credentials), la gestion d'erreur, l'accessibilité, ou la localisation

Tout est détaillé et priorisé dans l'issue. N'hésitez pas à commenter si vous avez des avis sur les choix proposés, notamment sur la question du module Domain (convention informelle vs. module Gradle strict).

Drapal

Osef des userscripts

Pour suivre  

Quand un message est cité, on le voit grâce à l'icône en bas à droite dudit message.

Mais quand on clique sur cette icône, il ne se passe rien (alors qu'on devrait être amené sur le message "citateur" ).

Il y a aussi des erreurs lorsqu'on fait l'inverse (on ne retourne pas forcément au message cité).

???

Faut reprendre les idées, c'est aussi en partie supporté par l'app ios et on va pas laisser ces richous avoir le dernier mot !!  

Wtf ?

Avant d'ajouter des features, faut commencer par fixer les bugs

pourquoi pas passer par Koin plutôt que Hilt (ça simplifiera bcp de choses) ? d'ailleurs si tu fais faire par claude, je suggère de partir sur une base KMP et donc de privilégier des libs kmp compatibles. ça permettrait de pas seulement se limiter à Android selon l'évolution future. et aussi prévoir un découpage modulaire d'au moins du parser et de features pour avoir un module spécifique android avec uniquement l'UI

et je pense que du multi-couche type clean archi pour ce type d'app c'est over-engineered et overkill. ça complexifie la compréhension et apporte peu dans le contexte d'avoir un gros niveau d'abstraction. pareil le MVI c'est souvent over-engineered sur android, tu peux garder du MVVM comme préco par Google c'est très adapté à ce qui est fait et plus facilement maintenable

Je parle de ce qui ne fonctionne pas sur Redface.
C'est si inutile que ça ici ?
 

C'est donc aussi ce que je me suis dit.  

autre chose, si tu veux publier sur le play store va falloir un compte google dev avec abo annuel et surtout va falloir que tu publies des données (très) personnelles auprès de Google

et j'y pense, mais si avant de lancer la génération de code tu peux lui demander de te générer un schéma d'architecture complet (de l'archi globale, d'un module spécifique et d'un écran spécifique) pour le faire aller dans la bonne direction. comme ça tu soumets ça ici et on peut faire une revue (on, je parle des gens du métier)

Je serais au moins sur la FP de ce topic d'anthologie sur une APP d'anthologie

Je suis au petit dej mais check ce qui a été fait niveau spec https://forumhfr.github.io/redface2/
Sachant que la mise à jour lié au premier audit n'est pas encore incluse (voir issue dédiée)
Mais oui sinon c'est l'idée

ah oui j'avais pas vu que ça avait été poussé aussi loin la spec
 
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
 
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

Y'a pas de bugs puisqu'il y'a pas de code, c'est un topic dev

même réponse
m'enfin je note qu'il faut travailler correctement les citations

en tout cas avec les deeplink le but c'est que ça marche correctement sur les liens hfr

regarde comme je t'ai cité les specs avec justification (en cours, rien de fixe)
KMP j'ai décidé que les probas de passer sur du ios à moment est d'à peu près 0%, il y'a une app avec dev actif à côté, d'ailleurs il y'a une refonte en cours. mais c'est à réfléchir, à voir en fonction de l'overhead, si le changement dans 2 ans serait fastidieux, l'incidence sur perf/archi/autres, etc

parser module je créé une issue pour être bien sur de

à réfléchir pour le multi-couche et MVI vs MVVM

je suis pas dev android donc ça reste bien évidemment un premier jet et on est là pour vérouiller la stack et l'archi avant de faire quoi que ce soit

putain t'as posté entretemps merci c'est exactement ce que je souhaitais pour le démarrage du topic
je note tout ce que t'as dit, je lui ferais manger et on verra l'évolution

j'aimerais 2/3 autres devs pour discuter en profondeur stack/archi

pour le parsing il a pas tout rebouffé mais il avait fait une analyse y'a quelques jours du code, et vu le taf pour faire évoluer je pense que la réécriture from scratch avec specs bien fichues et llm compatible ça sera plus simple (tout est ouvert à discussion bien sur)
y'a aussi du parsing sur l'app d'ezzz pur ios bien sur, donc on pourra lui faire bouffer les 2

je pensais aussi à une lib parsing qui pourra être utilisé par redface2 mais aussi le mcp (y'a un mcp hfr ) et pourquoi pas d'autres apps, pour l'instant je sais pas trop, c'est p'tet overkill
de toute façon le but c'est d'être le plus modulaire pour changer des briques si c'est possible

ouais le sujet est sorti sur l'autre topic, là j'ai déjà un compte play dev truc mes couilles et j'ai pas checké cette (nouvelle?) histoire d'abonnement mais j'avais vu passer une news je crois... jsais plus mais ça reste faisable. sinon dispo sur repo tiers mais bon, à voir.

l'issue sur le parser : https://github.com/ForumHFR/redface2/issues/15
je vais brancher claude sur le repos, on devrait pouvoir lui demnder des trucs avec @claude

PS: j'utilise uniquement opus 4.6, bref juste le meilleur modele, thinking à fond etc

Voilà, c'est le seul sens de mon message.  

Je pense parfois à D.ieu quand je fais bosser Claude sur des scripts & outils pour HFR. Je me dis qu'on est dans le monde d'après, dans le Next-HFR et qu'il n'est plus là pour voir ça  
J'espère cependant qu'avec ce travail on arrivera à lui rendre hommage et à faire perdurer ce forum jusqu'à la fin de la civilisation sur terre (donc 36 mois environ )

Dans la rubrique "à propos" de RF2, il faudra rendre hommage au C.réateur

C'est évident, et certainement des features douteuses à venir

Drap !  

des easter eggs à base de TT et de fessées

randomGoatse{
// post a goatse instead of a random post
}

c'est mentionné dans l'audit #1, je vais l'appliquer puis je vais soumettre tes réponses sur l'archi et on va voir
pour test & co le but est d'avoir une CI bétonné  
 
c'est là aussi où, semblerait-il, hilt est supérieur à koin parce que ça pète à la compilation et pas pendant le run

Ç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