Implémentation
Chaque rotation du cube repose sur un système propre : un modèle mathématique, un moteur 3D et un solveur qui tient compte des objectifs de la leçon. L'application Android utilise Kotlin et Jetpack Compose.
Instantané du projet
test* / androidTest* · @Teststack.kt
| Kotlin | 2.4.21 |
|---|---|
| Compose BOM | 2026.09.00 |
| Material 3 | 1.5.0-beta01 |
| Adaptive | 1.3.0 |
| Navigation 3 | 1.2.0 |
| AGP | 9.4.1 |
| KSP | 2.3.12 |
| Gradle | 9.7.0 |
Jetpack Compose et Material 3 définissent les composants et thèmes de l'interface. Adaptive adapte la disposition à la taille de la fenêtre, tandis que Navigation 3 gère la navigation et la restauration des écrans. L'état arrive via Coroutines et Flow ; Hilt relie les modules de l'application.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileL'interface, les contrats du domaine et les données sont répartis en modules ; Hilt relie les implémentations. Compose reçoit un état immuable et des événements explicites. Room stocke l'historique et la progression, DataStore conserve les réglages et Navigation 3 restaure les piles des sections.
android-ux.md
Cubiq met en œuvre des approches que Google souligne dans Apps Experience Program : Compose, disposition adaptative et edge-to-edge.
engine.glsl
Les shaders GLSL calculent les matériaux PBR, la rugosité et l'éclairage de l'environnement. Le modèle et l'animation restent synchronisés : revenir en arrière applique le mouvement inverse, et la caméra tient compte de l'espace entre les panneaux.
La notation typée devient des mouvements et des états cohérents du cube. La file du renderer anime les rotations des couches en préservant l'identité des pièces et facelets. La formule se lit comme une séquence de mouvements réels, avec lecture, pause et réglage du rythme.
Avancer anime un nouveau mouvement ; reculer applique le mouvement inverse. Le déplacement dans la séquence restaure la scène de base et la séquence cible. L'annulation arrête l'émission des mouvements suivants ; une rotation commencée se termine. Le cycle de vie EGL gère pause/release ; sans GL, le parcours d'apprentissage reste utilisable sans 3D.
solver.kt
Le solveur développé pour l'application construit une solution à partir des formules et mouvements auxiliaires de la leçon actuelle. SolverRequest comprend l'état du cube, les pièces cibles, les cibles verrouillées, les formules autorisées, les cas et l'orientation. Le planificateur respecte l'ordre des objectifs pédagogiques et protège les pièces résolues.
La planification par phase utilise BFS borné, recherche en faisceau et reconnaissance des cas F2L. La validation vérifie la composition des pièces, retournements, torsions et parité des permutations. La politique de recherche limite profondeur et largeur du faisceau. Changer de leçon annule la recherche et empêche un résultat obsolète.
Le résultat est PracticePlan : étapes, références aux formules, chronologie d'affichage et chronologie d'exécution. L'explication conserve l'orientation de la leçon ; le moteur reçoit la séquence complète d'exécution. Résultats : plan / solved / invalid input / no constrained path.
content.md
La théorie se trouve dans 756 documents Markdown et la pratique est définie dans 336 scénarios localisés. Gradle valide la structure des traductions et les références à 316 illustrations originales. Les graphismes ont été préparés dans Blender/Cycles ; le moteur Android utilise une géométrie procédurale distincte.
workflow.md
AGENTS.mdREADME.mdLe dépôt est organisé pour le développement avec des agents : la hiérarchie AGENTS.md définit les responsabilités, contraintes architecturales et contrôles de validation ; les README.md décrivent les contrats des modules, KDoc les API et invariants.
Les contrats d'architecture, de design et de localisation sont versionnés avec le code. PLAN.md consigne le périmètre et la transmission ; les changements de contrats incluent la mise à jour de leur documentation de référence. Vérifications et génération passent par Gradle ; CI compile les deux variantes de boutique.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationLes tests couvrent les états impossibles du cube, la préservation des couches résolues, les plans d'apprentissage, l'annulation des requêtes obsolètes, la restauration des sessions et l'importation des données. CI compile les deux variantes de boutique ; les contrôles de publication comprennent R8, APK/AAB, les sommes de contrôle et l'alignement des bibliothèques natives pour les pages de 16 KB.
Le volume de Kotlin compte les lignes physiques, y compris les commentaires, les lignes vides, buildSrc et le code de benchmark, hors répertoires de tests. Le nombre de tests correspond à 1 343 déclarations JVM et 281 déclarations Android, pas à des exécutions. Les documents incluent le texte de repli ; la présence d'un scénario ne signifie pas que chaque leçon comporte un exercice pratique.
baselineprofile · @TestLe texte total compte les lignes physiques des sources UTF-8 suivies : code, tests, ressources XML/JSON, contenu Markdown, localisation, documentation, outils de compilation et sources web. Les commentaires, lignes vides et copies des langues sont inclus. Sont exclus les médias, sorties générées ou compilées, code tiers, configurations de services et PLAN.md temporaire. Cela mesure les entrées textuelles du projet, pas les LOC exécutables.