Redface 2
Le client Android communautaire pour Hardware.fr, en bêta publique.
Voir les spécifications Voir les guides Voir sur GitHub
Pourquoi une réécriture ?
Redface v1 a rendu service à la communauté HFR pendant des années. Mais sa stack technique a atteint ses limites :
| Redface v1 | Redface 2 | |
|---|---|---|
| Langage | Java 11 | Kotlin |
| UI | XML + ButterKnife | Jetpack Compose |
| Réseau | Retrofit 1.9 (!), OkHttp 3 | OkHttp 5 |
| Async | RxJava 1 | Coroutines + Flow |
| Injection | Dagger 2 | Hilt (KSP) |
| Event bus | Otto | StateFlow |
| minSdk | 16 (Android 4.1, 2012) | 29 (Android 10, 2019) |
Retrofit 1.9 n’est plus maintenu depuis 2016. RxJava 1 depuis 2018. ButterKnife est officiellement déprécié. Le minSdk 16 empêche d’utiliser les APIs modernes.
Un refactoring incrémental serait plus coûteux qu’une réécriture. Chaque brique dépend des autres — migrer Retrofit demande de migrer RxJava, qui demande de migrer les patterns async, qui touche toute l’architecture.
Vision
Redface 2 est conçu pour :
- La vitesse — Scroll fluide à 120fps, prefetch intelligent, cache agressif. L’objectif : que le forum semble local.
- Les extensions communautaires — Les meilleurs ajouts des userscripts HFR (alertes qualitay, bookmarks, blacklist, redflag…) intégrés nativement.
- La maintenabilité — Architecture modulaire, testable, où chaque feature est isolée. Facile à comprendre pour un nouveau contributeur.
- L’ouverture — Système d’extensions pour que la communauté ajoute ses propres features sans toucher au cœur de l’app.
Vue d’ensemble
graph TB
subgraph "Presentation"
A[Jetpack Compose] --> B[MVI ViewModels]
end
subgraph "Domaine"
B --> C["Repositories (interfaces)"]
end
subgraph "Données"
D["Repository implémentations"]
D --> E[OkHttp 5 + Jsoup]
D --> G[Room Cache]
end
C -.->|implémente| D
E --> F["forum.hardware.fr"]
style A fill:#e74c3c,color:#fff
style B fill:#e67e22,color:#fff
style C fill:#f1c40f,color:#000
style D fill:#16a085,color:#fff
style E fill:#2ecc71,color:#fff
style G fill:#3498db,color:#fff
style F fill:#95a5a6,color:#fff
État du projet
- Bêta publique 0.50.2 (1er septembre 2026, Play test ouvert + F-Droid) : sondages (vote, clôture par le créateur), liens HFR (ouverture externe sans rebond, gestionnaire par défaut), modération et rôles du staff, vue forum, citations et fiabilité. Détail par version dans
app/CHANGELOG.md. - Canal dev 0.52.x : Réglages → Affichage → Couleurs (huit presets d’accent, hexa, tons de fond clair et sombre, AMOLED, couleurs du système), zoom pincé interactif, largeur maximale des images et viewer plein écran (pinch/pan/double-tap).
- Livré : les phases 0 à 3 de la roadmap (bootstrap ; lecture ; écriture ; messages privés et MultiMP, MPStorage en lecture et en écriture opt-in) et la refonte UI de la phase 4 (vues Drapeaux #603 et Topic #604, passe images #876, EgoQuote et EgoPost #874, surface de lecture partagée Topic → MP/DT #1040). L’état fonction par fonction côté MP se lit dans la matrice de parité.
- Pilotage : depuis juin 2026 le travail est suivi par milestones de vue (Vue · Topic 2, Vue · Éditeur 2, Vue · Drapeaux 2, Vue · MP 1, Vue · Réglages 1, Vue · Compte HFR 1, Infra & dette), les phases restant des épics thématiques. Restent ouverts en fond : l’architecture d’extensions (#7) et la sync MPStorage entre appareils (#6).
Les specs restent la source de vérité du projet, mais elles doivent refléter le code réel : tout écart entre une page canonique et le repo est traité comme un bug de spec, pas comme une dette future. Voir /spec-reality pour la procédure d’audit cross-fichier.
Les contributions sont les bienvenues : ouvrez une issue, commentez les existantes ou proposez une PR sur dev. Les retours de test passent par le topic bêta et le topic dev sur HFR.
Sommaire
Spécifications
- Méthodologie — Comment le projet spécifie, prototype et teste
- Scope fonctionnel — Ce que l’app doit permettre de faire
- Stack technique — Pourquoi chaque techno a été choisie
- Architecture — Couches, modules, data flow
- Navigation — Écrans, flows, deep linking
- Modèles de données — Structures du domaine
- Pattern MVI — Architecture UI en détail
- Protocole HFR — Contrats externes, endpoints et edge cases
- Roadmap — Phases de développement
- Parité de lecture Topic ↔ MP — L’état de chaque fonction de lecture côté MP/DT
- Extensions communautaires — Les addons userscript qui deviennent natifs
- ADRs — Les décisions structurantes déjà prises
Guides
- Installation — Play, F-Droid (bêta et dev), GitHub Releases, signatures et cohabitation
- Contribuer — Environnement, tests, rendu visuel, Git
- Release — Canaux bêta et dev, registre
app-v<N>, promotiondev → main - Limitations connues — Compromis assumés et limites plateforme
- Pourquoi Redface 2 ? — Le contexte et les doutes assumés
- Nommage — Historique du choix du nom
- Références écosystème HFR — Clients tiers, docs MesDiscussions, outillage compagnon
- Proxy utilisateur — Router le trafic HFR via un proxy configurable dans l’app
- Profiling — Mesurer avant d’optimiser
- Icône de l’application — Sources et déclinaisons de l’icône
- Capturer une fixture de citation MP — Procédure de capture live