Implementare
Fiecare rotire a cubului se bazează pe un sistem propriu: un model matematic, un motor 3D și un rezolvator care ține cont de obiectivele lecției. Aplicația Android folosește Kotlin și Jetpack Compose.
Instantaneu al proiectului
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 și Material 3 definesc componentele și temele interfeței. Adaptive gestionează dispunerea după dimensiunea ferestrei, iar Navigation 3 navigarea și restaurarea ecranelor. Starea ajunge prin Coroutines și Flow; Hilt conectează modulele aplicației.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileInterfața, contractele de domeniu și datele sunt în module separate; Hilt conectează implementările. Compose primește stare imuabilă și evenimente explicite. Room păstrează istoricul și progresul învățării, DataStore setările, iar Navigation 3 restaurează stivele secțiunilor.
android-ux.md
Cubiq implementează abordări pe care Google le evidențiază în Apps Experience Program: Compose, dispunere adaptivă și edge-to-edge.
engine.glsl
Shaderele GLSL calculează materiale PBR, rugozitate și iluminare ambientală. Modelul și animația sunt sincronizate: revenirea cu un pas aplică mișcarea inversă, iar camera ține cont de spațiul dintre panouri.
Notația tipizată se transformă în mișcări și stări coerente ale cubului. Coada rendererului animă rotirile straturilor, păstrând identitatea pieselor și faceleturilor. Formula se redă ca o secvență de mișcări reale, cu redare, pauză și reglarea ritmului.
Un pas înainte animă o mișcare nouă; un pas înapoi aplică mișcarea inversă. Saltul la o poziție restaurează scena de bază și secvența țintă. Anularea oprește emiterea mișcărilor următoare; o rotire începută se încheie. Ciclul de viață EGL gestionează pause/release; fără GL, parcursul de învățare rămâne disponibil fără 3D.
solver.kt
Rezolvatorul propriu construiește soluția din formule și mișcări auxiliare ale lecției curente. SolverRequest include starea cubului, piese țintă, ținte blocate, formule permise, cazuri și orientare. Planificatorul respectă ordinea obiectivelor didactice și protejează piesele rezolvate.
Planificarea pe faze folosește BFS limitat, căutare în fascicul și recunoaștere a cazurilor F2L. Validarea verifică alcătuirea pieselor, inversările, răsucirile și paritatea permutărilor. Politica de căutare limitează adâncimea și lățimea fasciculului. Schimbarea lecției anulează căutarea și împiedică un rezultat învechit.
Rezultatul este PracticePlan: pași, referințe la formule, o cronologie de afișare și una de execuție. Explicația păstrează orientarea didactică; motorul primește secvența completă de execuție. Rezultate: plan / solved / invalid input / no constrained path.
content.md
Teoria se află în 756 documente Markdown, iar practica este definită în 336 scenarii localizate. Gradle verifică structura traducerilor și referințele la 316 ilustrații originale. Grafica a fost pregătită în Blender/Cycles; motorul Android folosește geometrie procedurală separată.
workflow.md
AGENTS.mdREADME.mdDepozitul este organizat pentru dezvoltare cu agenți: ierarhia AGENTS.md definește responsabilități, restricții arhitecturale și praguri de validare; README.md descriu contractele modulelor, KDoc API și invariantele.
Contractele de arhitectură, design și localizare sunt versionate alături de cod. PLAN.md consemnează scopul și predarea; schimbările contractelor actualizează documentația responsabilă. Verificările și generarea trec prin Gradle; CI compilează ambele variante pentru magazine.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationTestele acoperă stări imposibile ale cubului, păstrarea straturilor rezolvate, planuri de învățare, anularea cererilor învechite, restaurarea sesiunilor și importul datelor. CI compilează ambele variante pentru magazine; verificările de lansare includ R8, APK/AAB, sume de control și alinierea bibliotecilor native pentru pagini de 16 KB.
Volumul Kotlin numără linii fizice, inclusiv comentarii, linii goale, buildSrc și cod de benchmark, fără directoarele de teste. Numărul de teste înseamnă 1 343 declarații JVM și 281 declarații Android, nu execuții. Documentele includ text de rezervă; existența unui scenariu nu înseamnă că fiecare lecție are practică.
baselineprofile · @TestTextul total numără linii fizice în fișierele UTF-8 versionate: surse, teste, resurse XML/JSON, conținut Markdown, localizare, documentație, unelte de build și surse web. Include comentarii, linii goale și copii lingvistice. Exclude media, rezultate generate sau de build, cod de la furnizori, configurări de servicii și PLAN.md temporar. Este volumul intrărilor text ale proiectului, nu LOC executabile.