Implementazione
Ogni rotazione del cubo si basa su un sistema proprio: un modello matematico, un motore 3D e un risolutore che considera gli obiettivi della lezione. L'app Android usa Kotlin e Jetpack Compose.
Istantanea del progetto
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 e Material 3 definiscono componenti e temi dell'interfaccia. Adaptive gestisce il layout in base alla dimensione della finestra, mentre Navigation 3 gestisce navigazione e ripristino delle schermate. Lo stato arriva tramite Coroutines e Flow; Hilt collega i moduli dell'app.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileInterfaccia, contratti di dominio e dati sono in moduli separati; Hilt collega le implementazioni. Compose riceve uno stato immutabile ed eventi espliciti. Room conserva cronologia e progressi, DataStore le impostazioni, mentre Navigation 3 ripristina gli stack delle sezioni.
android-ux.md
Cubiq implementa approcci che Google evidenzia in Apps Experience Program: Compose, layout adattivo ed edge-to-edge.
engine.glsl
Gli shader GLSL calcolano materiali PBR, rugosità e illuminazione ambientale. Modello e animazione restano sincronizzati: tornare indietro applica la mossa inversa, e la fotocamera considera lo spazio tra i pannelli.
La notazione tipizzata diventa mosse e stati coerenti del cubo. La coda del renderer anima rotazioni degli strati conservando l'identità di pezzi e facelet. La formula si riproduce come una sequenza di mosse reali, con riproduzione, pausa e regolazione del ritmo.
Avanzare anima una nuova mossa; tornare indietro applica la mossa inversa. Spostarsi a una posizione ripristina scena di base e sequenza di destinazione. L'annullamento ferma l'emissione di nuove mosse; una rotazione iniziata si completa. Il ciclo di vita EGL gestisce pause/release; senza GL, il percorso di apprendimento resta disponibile senza 3D.
solver.kt
Il risolutore sviluppato per l'app costruisce una soluzione con formule e mosse ausiliarie della lezione attuale. SolverRequest comprende stato del cubo, pezzi obiettivo, obiettivi bloccati, formule consentite, casi e orientamento. Il pianificatore rispetta l'ordine degli obiettivi didattici e protegge i pezzi risolti.
La pianificazione per fase usa BFS limitato, ricerca a fascio e riconoscimento dei casi F2L. La validazione verifica composizione dei pezzi, capovolgimenti, torsioni e parità delle permutazioni. La politica di ricerca limita profondità e ampiezza del fascio. Cambiare lezione annulla la ricerca e impedisce un risultato obsoleto.
Il risultato è PracticePlan: passi, riferimenti alle formule, timeline di visualizzazione e timeline di esecuzione. La spiegazione mantiene l'orientamento della lezione; il motore riceve l'intera sequenza di esecuzione. Esiti: plan / solved / invalid input / no constrained path.
content.md
La teoria è in 756 documenti Markdown e la pratica è definita in 336 scenari localizzati. Gradle verifica la struttura delle traduzioni e i riferimenti a 316 illustrazioni originali. La grafica è stata preparata in Blender/Cycles; il motore Android usa una geometria procedurale separata.
workflow.md
AGENTS.mdREADME.mdIl repository è organizzato per lo sviluppo con agenti: la gerarchia AGENTS.md definisce responsabilità, vincoli architetturali e controlli di validazione; i README.md descrivono i contratti dei moduli, KDoc le API e le invarianti.
I contratti di architettura, design e localizzazione sono versionati insieme al codice. PLAN.md registra ambito e passaggio di consegne; le modifiche ai contratti aggiornano la documentazione di riferimento. Controlli e generazione passano da Gradle; CI compila entrambe le varianti per gli store.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationI test coprono stati impossibili del cubo, conservazione degli strati risolti, piani di apprendimento, annullamento delle richieste obsolete, ripristino delle sessioni e importazione dei dati. CI compila entrambe le varianti per gli store; i controlli di rilascio includono R8, APK/AAB, checksum e allineamento delle librerie native per pagine da 16 KB.
Il volume di Kotlin conta le righe fisiche, inclusi commenti, righe vuote, buildSrc e codice benchmark, esclusi i percorsi dei test. Il numero di test indica 1 343 dichiarazioni JVM e 281 dichiarazioni Android, non esecuzioni. I documenti includono testo di fallback; la presenza di uno scenario non implica una pratica in ogni lezione.
baselineprofile · @TestIl testo totale conta righe fisiche in fonti UTF-8 versionate: codice, test, risorse XML/JSON, contenuti Markdown, localizzazione, documentazione, strumenti di build e sorgenti web. Include commenti, righe vuote e copie delle lingue. Esclude media, output generato o compilato, codice di terzi, configurazioni di servizi e PLAN.md temporaneo. Misura gli input testuali del progetto, non LOC eseguibili.