Implementatie
Achter elke draai van de kubus zit een eigen systeem: een wiskundig model, een 3D-engine en een oplosser die rekening houdt met de lesdoelen. De Android-app gebruikt Kotlin en Jetpack Compose.
Momentopname van het project
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 en Material 3 bepalen de interfacecomponenten en thema's. Adaptive verzorgt de indeling op basis van de venstergrootte en Navigation 3 de navigatie en het herstel van schermen. De toestand komt via Coroutines en Flow; Hilt verbindt de appmodules.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileInterface, domeincontracten en gegevens zitten in aparte modules; Hilt verbindt de implementaties. Compose ontvangt onveranderlijke toestand en expliciete gebeurtenissen. Room bewaart geschiedenis en leervoortgang, DataStore de instellingen, en Navigation 3 herstelt de stacks van de secties.
android-ux.md
Cubiq past benaderingen toe die Google benadrukt in het Apps Experience Program: Compose, adaptieve indeling en edge-to-edge.
engine.glsl
GLSL-shaders berekenen PBR-materialen, ruwheid en omgevingsverlichting. Model en animatie blijven gelijklopen: een stap terug voert de omgekeerde zet uit, en de camera houdt rekening met de ruimte tussen panelen.
Getypeerde notatie wordt omgezet in zetten en consistente kubustoestanden. De rendererwachtrij animeert laagrotaties en behoudt de identiteit van stukken en facelets. Een formule speelt af als een reeks echte zetten, met afspelen, pauze en tempo-instelling.
Een stap vooruit animeert een nieuwe zet; een stap terug past de omgekeerde zet toe. Naar een positie springen herstelt de basisscène en doelreeks. Annulering stopt de uitgifte van volgende zetten; een gestarte draai wordt afgemaakt. De EGL-levenscyclus verwerkt pause/release; zonder GL blijft de leerroute zonder 3D beschikbaar.
solver.kt
De eigen oplosser bouwt een oplossing uit formules en hulpzetten van de huidige les. SolverRequest bevat kubustoestand, doelstukken, vergrendelde doelen, toegestane formules, gevallen en oriëntatie. De planner volgt de volgorde van leerdoelen en beschermt opgeloste stukken.
Fasespecifieke planning gebruikt begrensde BFS, beam search en herkenning van F2L-gevallen. Validatie controleert de samenstelling van stukken, flips, twists en permutatiepariteit. Het zoekbeleid begrenst diepte en bundelbreedte. Een leswissel annuleert de zoekopdracht en voorkomt een verouderd resultaat.
Het resultaat is PracticePlan: stappen, formuleverwijzingen, een weergavetijdlijn en een uitvoeringstijdlijn. De uitleg behoudt de leeroriëntatie; de engine krijgt de volledige uitvoeringsreeks. Uitkomsten: plan / solved / invalid input / no constrained path.
content.md
De theorie staat in 756 Markdown-documenten en de praktijk is vastgelegd in 336 gelokaliseerde scenario's. Gradle controleert de vertaalstructuur en verwijzingen naar 316 eigen illustraties. De afbeeldingen zijn voorbereid in Blender/Cycles; de Android-engine gebruikt aparte procedurele geometrie.
workflow.md
AGENTS.mdREADME.mdDe repository is ingericht voor ontwikkeling met agents: de AGENTS.md-hiërarchie bepaalt verantwoordelijkheden, architectuurgrenzen en validatiecontroles; README.md-bestanden beschrijven modulecontracten, KDoc API en invarianten.
Architectuur-, ontwerp- en lokalisatiecontracten worden samen met de code geversioneerd. PLAN.md legt de scope en overdracht vast; contractwijzigingen werken de verantwoordelijke documentatie bij. Controles en generatie lopen via Gradle; CI bouwt beide winkelvarianten.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationTests omvatten onmogelijke kubustoestanden, behoud van opgeloste lagen, leerplannen, annulering van verouderde verzoeken, sessieherstel en gegevensimport. CI bouwt beide winkelvarianten; releasecontroles omvatten R8, APK/AAB, checksums en uitlijning van native bibliotheken voor pagina's van 16 KB.
De Kotlin-omvang telt fysieke regels, inclusief commentaar, lege regels, buildSrc en benchmarkcode, zonder testmappen. Het aantal tests betekent 1 343 JVM-declaraties en 281 Android-declaraties, geen uitvoeringen. Documenten bevatten fallbacktekst; een aanwezig scenario betekent niet dat elke les een oefening heeft.
baselineprofile · @TestDe totale tekst telt fysieke regels in bijgehouden UTF-8-bestanden: broncode, tests, XML/JSON-bronnen, Markdown-inhoud, lokalisatie, documentatie, buildgereedschap en webbroncode. Commentaar, lege regels en taalkopieën zijn inbegrepen. Media, gegenereerde of builduitvoer, externe code, serviceconfiguratie en de tijdelijke PLAN.md zijn uitgesloten. Dit meet de tekstinvoer van het project, geen uitvoerbare LOC.