Implementering
Hver vridning av kuben bygger på et eget system: en matematisk modell, en 3D-motor og en løser som tar hensyn til leksjonens mål. Android-appen bruker Kotlin og Jetpack Compose.
Prosjektøyeblikksbilde
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 og Material 3 bestemmer grensesnittets komponenter og temaer. Adaptive håndterer layout etter vindusstørrelse, mens Navigation 3 håndterer navigasjon og gjenoppretting av skjermer. Tilstanden kommer via Coroutines og Flow; Hilt kobler sammen appmodulene.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileGrensesnitt, domenekontrakter og data ligger i separate moduler; Hilt kobler sammen implementasjonene. Compose mottar uforanderlig tilstand og eksplisitte hendelser. Room lagrer historikk og læringsframgang, DataStore innstillinger, og Navigation 3 gjenoppretter seksjonenes stabler.
android-ux.md
Cubiq bruker tilnærminger som Google fremhever i Apps Experience Program: Compose, adaptivt oppsett og edge-to-edge.
engine.glsl
GLSL-shadere beregner PBR-materialer, ruhet og omgivelseslys. Modell og animasjon er samordnet: et steg tilbake utfører det motsatte trekket, og kameraet tar hensyn til plassen mellom panelene.
Typet notasjon omdannes til trekk og sammenhengende kubetilstander. Rendererens kø animerer lagvridninger og bevarer identiteten til deler og facelets. Formelen spilles som en sekvens av virkelige trekk med avspilling, pause og tempojustering.
Et steg fram animerer et nytt trekk; et steg tilbake bruker det motsatte trekket. Hopp til en posisjon gjenoppretter grunnscenen og målsekvensen. Avbrytelse stopper utsendingen av flere trekk; en påbegynt vridning fullføres. EGL-livssyklusen håndterer pause/release; uten GL er læringsløpet fortsatt tilgjengelig uten 3D.
solver.kt
Den egenutviklede løseren bygger en løsning av den aktuelle leksjonens formler og hjelpetrekk. SolverRequest inneholder kubetilstand, måldeler, låste mål, tillatte formler, tilfeller og orientering. Planleggeren følger læringsmålenes rekkefølge og beskytter løste deler.
Fasespesifikk planlegging bruker begrenset BFS, strålesøk og gjenkjenning av F2L-tilfeller. Validering kontrollerer delenes sammensetning, vendinger, vridninger og permutasjonsparitet. Søkepolicyen begrenser dybde og strålebredde. Leksjonsbytte avbryter søket og hindrer et utdatert resultat.
Resultatet er PracticePlan: steg, formelreferanser, en visningstidslinje og en utføringstidslinje. Forklaringen bevarer læringsorienteringen; motoren mottar hele utføringssekvensen. Utfall: plan / solved / invalid input / no constrained path.
content.md
Teorien ligger i 756 Markdown-dokumenter, og øvelsene er definert i 336 lokaliserte scenarioer. Gradle kontrollerer oversettelsesstrukturen og henvisninger til 316 originale illustrasjoner. Grafikken ble klargjort i Blender/Cycles; Android-motoren bruker separat prosedyrebasert geometri.
workflow.md
AGENTS.mdREADME.mdRepositoryet er organisert for utvikling med agenter: AGENTS.md-hierarkiet angir ansvar, arkitekturbegrensninger og valideringskontroller; README.md beskriver modulkontrakter, KDoc API og invarianter.
Arkitektur-, design- og lokaliseringskontrakter versjonsstyres sammen med koden. PLAN.md registrerer omfang og overlevering; kontraktsendringer oppdaterer den ansvarlige dokumentasjonen. Kontroller og generering går gjennom Gradle; CI bygger begge butikkvariantene.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationTester dekker umulige kubetilstander, bevaring av løste lag, læringsplaner, avbrudd av utdaterte forespørsler, gjenoppretting av økter og dataimport. CI bygger begge butikkvariantene; utgivelseskontroller omfatter R8, APK/AAB, kontrollsummer og justering av native-biblioteker for sider på 16 KB.
Kotlin-omfanget teller fysiske linjer, inkludert kommentarer, tomme linjer, buildSrc og benchmarkkode, uten testmapper. Testantallet betyr 1 343 JVM-deklarasjoner og 281 Android-deklarasjoner, ikke kjøringer. Dokumentene inkluderer reservetekst; et scenario betyr ikke at hver leksjon har en øvelse.
baselineprofile · @TestDen samlede teksten teller fysiske linjer i versjonsstyrte UTF-8-filer: kildekode, tester, XML/JSON-ressurser, Markdown-innhold, lokalisering, dokumentasjon, byggeverktøy og webkilder. Kommentarer, tomme linjer og språkkopier er med. Medier, genererte og byggeutdata, tredjepartskode, tjenestekonfigurasjon og midlertidig PLAN.md er utelatt. Dette måler prosjektets tekstinndata, ikke kjørbare LOC.