Implementierung
Jede Drehung des Würfels beruht auf einem eigenen System: einem mathematischen Modell, einer 3D-Engine und einem Löser, der die Lernziele berücksichtigt. Die Android-App nutzt Kotlin und Jetpack Compose.
Projektstand
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 und Material 3 bestimmen die Komponenten und Themes der Oberfläche. Adaptive passt das Layout an die Fenstergröße an, Navigation 3 übernimmt Navigation und Bildschirmwiederherstellung. Der Zustand kommt über Coroutines und Flow; Hilt verbindet die App-Module.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileOberfläche, Domänenverträge und Daten liegen in getrennten Modulen; Hilt verbindet die Implementierungen. Compose erhält unveränderlichen Zustand und explizite Ereignisse. Room speichert Verlauf und Lernfortschritt, DataStore die Einstellungen, und Navigation 3 stellt die Stapel der Bereiche wieder her.
android-ux.md
Cubiq setzt Ansätze um, die Google im Apps Experience Program hervorhebt: Compose, adaptive Layouts und edge-to-edge.
engine.glsl
GLSL-Shader berechnen PBR-Materialien, Rauheit und Umgebungsbeleuchtung. Modell und Animation bleiben synchron: Ein Schritt zurück führt den inversen Zug aus, und die Kamera berücksichtigt den Platz zwischen den Bedienfeldern.
Typisierte Notation wird in Züge und konsistente Würfelzustände übersetzt. Die Renderer-Warteschlange animiert Schichtdrehungen und erhält die Identitäten von Teilen und Facelets. Eine Formel wird als Folge realer Züge abgespielt, mit Start, Pause und Tempoeinstellung.
Ein Schritt vorwärts animiert einen neuen Zug; rückwärts wird der inverse Zug angewandt. Ein Sprung in der Folge stellt Basisszene und Zielsequenz wieder her. Abbruch stoppt die Ausgabe weiterer Züge; eine begonnene Drehung endet regulär. Der EGL-Lebenszyklus behandelt pause/release; ohne GL bleibt der Lernpfad ohne 3D nutzbar.
solver.kt
Der eigene Löser erstellt eine Lösung aus Formeln und Hilfszügen der aktuellen Lektion. SolverRequest umfasst Würfelzustand, Zielteile, gesperrte Ziele, erlaubte Formeln, Fälle und Orientierung. Der Planer hält die Reihenfolge der Lernziele ein und schützt bereits gelöste Teile.
Die phasenspezifische Planung nutzt begrenztes BFS, Beam Search und F2L-Fallerkennung. Die Validierung prüft Teilezusammensetzung, Flips, Twists und Permutationsparität. Die Suchrichtlinie begrenzt Tiefe und Strahlbreite. Ein Lektionswechsel bricht die Suche ab und verhindert ein veraltetes Ergebnis.
Das Ergebnis ist PracticePlan: Schritte, Formelreferenzen, eine Anzeige- und eine Ausführungszeitleiste. Die Erläuterung erhält die Orientierung der Lektion; die Engine bekommt die gesamte Ausführungsfolge. Ergebnisse: plan / solved / invalid input / no constrained path.
content.md
Die Theorie liegt in 756 Markdown-Dokumenten, die Praxis ist in 336 lokalisierten Szenarien definiert. Gradle prüft die Übersetzungsstruktur und Verweise auf 316 eigens erstellte Illustrationen. Die Grafiken wurden in Blender/Cycles vorbereitet; die Android-Engine verwendet eine separate prozedurale Geometrie.
workflow.md
AGENTS.mdREADME.mdDas Repository ist für Entwicklung mit Agenten organisiert: Die AGENTS.md-Hierarchie legt Zuständigkeiten, Architekturvorgaben und Validierungsprüfungen fest; README.md-Dateien beschreiben Modulverträge, KDoc API und Invarianten.
Architektur-, Design- und Lokalisierungsverträge werden neben dem Code versioniert. PLAN.md hält Umfang und Übergabe fest; Vertragsänderungen aktualisieren die zuständige Dokumentation. Prüfungen und Generierung laufen über Gradle; CI baut beide Store-Varianten.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationTests decken unmögliche Würfelzustände, den Erhalt gelöster Schichten, Lernpläne, den Abbruch veralteter Anfragen, die Wiederherstellung von Sitzungen und den Datenimport ab. CI baut beide Store-Varianten; Release-Prüfungen umfassen R8, APK/AAB, Prüfsummen und die Ausrichtung nativer Bibliotheken für 16 KB große Speicherseiten.
Der Kotlin-Umfang zählt physische Zeilen einschließlich Kommentaren, Leerzeilen, buildSrc und Benchmark-Code, ohne Testverzeichnisse. Die Testzahl bezeichnet 1 343 JVM-Deklarationen und 281 Android-Deklarationen, keine Ausführungen. Dokumente enthalten Fallback-Text; ein vorhandenes Szenario bedeutet nicht, dass jede Lektion eine Übung enthält.
baselineprofile · @TestDer Gesamttext zählt physische Zeilen in versionierten UTF-8-Dateien: Quellcode, Tests, XML/JSON-Ressourcen, Markdown-Inhalte, Lokalisierung, Dokumentation, Build-Werkzeuge und Web-Quelltexte. Kommentare, Leerzeilen und Sprachkopien sind enthalten. Medien, generierte oder Build-Ausgaben, Fremdcode, Dienstkonfigurationen und die temporäre PLAN.md sind ausgeschlossen. Dies misst die Texteingaben des Projekts, keine ausführbaren LOC.