Megvalósítás
A kocka minden fordítása mögött saját rendszer áll: matematikai modell, 3D-motor és a lecke céljait figyelembe vevő megoldó. Az Android-alkalmazás Kotlin és Jetpack Compose használatával készült.
Projektpillanatkép
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 |
A Jetpack Compose és a Material 3 határozza meg a felület komponenseit és témáit. Az Adaptive az ablakméret szerinti elrendezést, a Navigation 3 a navigációt és a képernyők helyreállítását kezeli. Az állapot Coroutines és Flow használatával érkezik; a Hilt összeköti az alkalmazás moduljait.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileA felület, a doménszerződések és az adatok külön modulokban vannak; a Hilt köti össze a megvalósításokat. A Compose változtathatatlan állapotot és explicit eseményeket kap. A Room tárolja az előzményeket és a tanulási haladást, a DataStore a beállításokat, a Navigation 3 pedig helyreállítja a szakaszok vermét.
android-ux.md
A Cubiq a Google által az Apps Experience Program keretében kiemelt megközelítéseket alkalmazza: Compose, adaptív elrendezés és edge-to-edge.
engine.glsl
A GLSL shaderek PBR-anyagokat, érdességet és környezeti megvilágítást számítanak. A modell és az animáció összhangban van: a visszalépés az inverz lépést alkalmazza, a kamera pedig figyelembe veszi a panelek közötti szabad helyet.
A típusos jelölés lépésekké és egységes kockaállapotokká alakul. A renderer sora animálja a rétegfordításokat, megőrizve a darabok és faceletek identitását. Az algoritmus valós lépéssorként játszható le, lejátszással, szünettel és tempóbeállítással.
Az előrelépés új lépést animál; a visszalépés az inverz lépést alkalmazza. A pozícióra ugrás helyreállítja az alapjelenetet és a célzott lépéssort. Megszakításkor nem indulnak további lépések; a már elkezdett fordítás befejeződik. Az EGL életciklusa kezeli a pause/release műveleteket; ha GL nem érhető el, a tanulási út 3D nélkül megmarad.
solver.kt
A saját megoldó az aktuális lecke algoritmusaiból és segédlépéseiből készít megoldást. A SolverRequest tartalma: kockaállapot, céldarabok, zárolt célok, engedélyezett algoritmusok, esetek és orientáció. A tervező betartja az oktatási célok sorrendjét, és védi a kirakott darabokat.
A fázisspecifikus tervezés korlátozott BFS-t, nyalábkeresést és F2L-esetfelismerést használ. A validáció ellenőrzi a darabok összetételét, az átfordításokat, elcsavarásokat és a permutáció paritását. A keresési szabályzat korlátozza a mélységet és a nyalábszélességet. A leckeváltás megszakítja a keresést, és kizárja az elavult eredményt.
Az eredmény PracticePlan: lépések, algoritmushivatkozások, megjelenítési és végrehajtási idővonal. A magyarázat megőrzi az oktatási orientációt; a motor a teljes végrehajtási lépéssort kapja. Kimenetek: plan / solved / invalid input / no constrained path.
content.md
Az elmélet 756 Markdown-dokumentumban, a gyakorlat 336 lokalizált forgatókönyvben szerepel. A Gradle ellenőrzi a fordítások szerkezetét és a 316 saját illusztrációra mutató hivatkozásokat. A grafika Blender/Cycles használatával készült; az Android-motor külön procedurális geometriát használ.
workflow.md
AGENTS.mdREADME.mdA tárház ügynökökkel végzett fejlesztéshez szervezett: az AGENTS.md hierarchiája meghatározza a felelősségeket, architekturális korlátokat és validációs kapukat; a README.md fájlok a modulok szerződéseit, a KDoc az API-t és az invariánsokat írja le.
Az architektúra, a design és a lokalizáció szerződései a kóddal együtt verziózottak. A PLAN.md rögzíti a terjedelmet és az átadást; szerződésmódosításkor a felelős dokumentáció is frissül. Az ellenőrzés és generálás Gradle használatával történik; a CI mindkét áruházi változatot buildeli.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationA tesztek lefedik a lehetetlen kockaállapotokat, a kirakott rétegek megőrzését, a tanulási terveket, az elavult kérések megszakítását, a munkamenetek helyreállítását és az adatimportot. A CI mindkét áruházi változatot buildeli; a kiadási ellenőrzések kiterjednek az R8-ra, az APK/AAB-ra, az ellenőrző összegekre és a natív könyvtárak 16 KB-os lapokhoz igazítására.
A Kotlin-kód mennyiségét fizikai sorokban számították ki, beleértve a megjegyzéseket, az üres sorokat, a buildSrc-t és a benchmarkkódot, de kihagyva a tesztkönyvtárakat. A tesztek száma 1 343 JVM-deklarációt és 281 Android-deklarációt jelent, nem futtatásokat. A dokumentumok tartalmazzák a tartalék szöveget; egy forgatókönyv megléte nem jelent gyakorlatot minden leckében.
baselineprofile · @TestA teljes szöveg a verziókövetett UTF-8 fájlok fizikai sorait számolja: források, tesztek, XML/JSON-erőforrások, Markdown-tartalom, lokalizáció, dokumentáció, buildeszközök és webes források. A megjegyzések, üres sorok és nyelvi másolatok is szerepelnek. A média, generált és buildkimenetek, külső kód, szolgáltatáskonfiguráció és az ideiglenes PLAN.md kimarad. Ez a projekt szöveges bemenetének mennyisége, nem végrehajtható LOC.