Реализация
Зад всяко завъртане на куба стои собствена система: математически модел, 3D двигател и решател, който отчита целите на урока. Приложението за Android използва Kotlin и Jetpack Compose.
Снимка на проекта
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 и Material 3 определят компонентите и темите на интерфейса. Adaptive отговаря за оформлението според размера на прозореца, а Navigation 3 за навигацията и възстановяването на екраните. Състоянието постъпва чрез Coroutines и Flow; Hilt свързва модулите на приложението.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileИнтерфейсът, договорите на предметната област и данните са в отделни модули; Hilt свързва реализациите. Compose получава неизменно състояние и явни събития. Room съхранява историята и учебния напредък, DataStore настройките, а Navigation 3 възстановява стековете на разделите.
android-ux.md
Cubiq прилага подходи, които Google откроява в Apps Experience Program: Compose, адаптивно оформление и edge-to-edge.
engine.glsl
GLSL шейдърите изчисляват PBR материалите, грапавостта и осветлението от средата. Моделът и анимацията са съгласувани: стъпка назад прилага обратния ход, а камерата отчита свободното място между панелите.
Типизираната нотация се преобразува в ходове и съгласувани състояния на куба. Опашката на renderer анимира завъртанията на слоевете, запазвайки идентичността на частите и facelet елементите. Формулата се възпроизвежда като последователност от реални ходове, с пускане, пауза и настройка на темпото.
Стъпка напред анимира нов ход; стъпка назад прилага обратния ход. Преминаването към позиция възстановява базовата сцена и целевата последователност. Отмяната спира подаването на следващи ходове; започнатото завъртане завършва. Жизненият цикъл EGL обработва pause/release; без GL учебният път остава достъпен без 3D.
solver.kt
Собственият решател изгражда решение от формули и помощни ходове на текущия урок. SolverRequest включва състояние на куба, целеви части, заключени цели, разрешени формули, случаи и ориентация. Планировчикът спазва реда на учебните цели и защитава вече подредените части.
Планирането по фази използва ограничено BFS, търсене с лъч и разпознаване на случаи F2L. Валидацията проверява състава на частите, обръщанията, усукванията и паритета на пермутациите. Политиката за търсене ограничава дълбочината и ширината на лъча. Смяната на урока отменя търсенето и изключва остарял резултат.
Резултатът е PracticePlan: стъпки, препратки към формули, времева линия за показване и за изпълнение. Обяснението запазва учебната ориентация; двигателят получава пълната последователност за изпълнение. Резултати: plan / solved / invalid input / no constrained path.
content.md
Теорията се съхранява в 756 Markdown документа, а практиката е описана в 336 локализирани сценария. Gradle проверява структурата на преводите и препратките към 316 авторски илюстрации. Графиката е подготвена в Blender/Cycles; Android двигателят използва отделна процедурна геометрия.
workflow.md
AGENTS.mdREADME.mdХранилището е организирано за разработка с агенти: йерархията AGENTS.md определя отговорности, архитектурни ограничения и проверки за валидация; README.md описват договорите на модулите, KDoc API и инвариантите.
Договорите за архитектура, дизайн и локализация се версионират заедно с кода. PLAN.md записва обхвата и предаването на работата; промените в договорите обновяват отговорната документация. Проверките и генерирането минават през Gradle; CI компилира и двата варианта за магазините.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationТестовете обхващат невъзможни състояния на куба, запазване на подредени слоеве, учебни планове, отмяна на остарели заявки, възстановяване на сесии и импорт на данни. CI компилира и двата варианта за магазините; проверките за издание включват R8, APK/AAB, контролни суми и подравняване на native библиотеките за страници от 16 KB.
Обемът на Kotlin се брои във физически редове, включително коментари, празни редове, buildSrc и benchmark код, без тестовите директории. Броят тестове означава 1 343 JVM декларации и 281 Android декларации, а не изпълнения. Документите включват резервен текст; наличието на сценарий не означава практика във всеки урок.
baselineprofile · @TestОбщият текст брои физически редове във версионирани UTF-8 файлове: изходен код, тестове, XML/JSON ресурси, Markdown съдържание, локализация, документация, build инструменти и уеб изходен код. Включва коментари, празни редове и езикови копия. Изключва медии, генерирани и build резултати, код на доставчици, конфигурации на услуги и временния PLAN.md. Това е обемът на текстовите входове на проекта, а не изпълними LOC.