Implementación
Cada giro del cubo se apoya en un sistema propio: un modelo matemático, un motor 3D y un solucionador que tiene en cuenta los objetivos de la lección. La aplicación para Android usa Kotlin y Jetpack Compose.
Instantánea del proyecto
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 y Material 3 definen los componentes y temas de la interfaz. Adaptive ajusta la distribución al tamaño de la ventana y Navigation 3 gestiona la navegación y la restauración de pantallas. El estado llega mediante Coroutines y Flow; Hilt conecta los módulos de la aplicación.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileLa interfaz, los contratos de dominio y los datos se separan en módulos; Hilt conecta las implementaciones. Compose recibe un estado inmutable y eventos explícitos. Room almacena el historial y el progreso de aprendizaje, DataStore guarda los ajustes y Navigation 3 restaura las pilas de las secciones.
android-ux.md
Cubiq implementa enfoques que Google destaca en Apps Experience Program: Compose, distribución adaptable y edge-to-edge.
engine.glsl
Los shaders GLSL calculan los materiales PBR, la rugosidad y la iluminación del entorno. El modelo y la animación se mantienen sincronizados: retroceder aplica el movimiento inverso, y la cámara tiene en cuenta el espacio entre paneles.
La notación tipada se convierte en movimientos y estados coherentes del cubo. La cola del renderer anima giros de capas conservando la identidad de piezas y facelets. La fórmula se reproduce como una secuencia de movimientos reales, con reproducción, pausa y ajuste del ritmo.
Avanzar anima un movimiento nuevo; retroceder aplica el movimiento inverso. Desplazarse a una posición restaura la escena base y la secuencia objetivo. La cancelación detiene la emisión de nuevos movimientos; el giro iniciado termina. El ciclo de vida EGL gestiona pause/release; sin GL, la ruta de aprendizaje sigue disponible sin 3D.
solver.kt
El solucionador propio construye una solución con fórmulas y movimientos auxiliares de la lección actual. SolverRequest incluye estado del cubo, piezas objetivo, objetivos bloqueados, fórmulas permitidas, casos y orientación. El planificador respeta el orden de los objetivos de aprendizaje y protege las piezas resueltas.
La planificación por fase usa BFS acotado, búsqueda en haz y reconocimiento de casos F2L. La validación comprueba la composición de piezas, volteos y torsiones, y la paridad de permutaciones. La política de búsqueda limita profundidad y anchura del haz. Cambiar de lección cancela la búsqueda e impide un resultado obsoleto.
El resultado es PracticePlan: pasos, referencias a fórmulas, una línea temporal de visualización y otra de ejecución. La explicación mantiene la orientación de la lección; el motor recibe la secuencia completa de ejecución. Resultados: plan / solved / invalid input / no constrained path.
content.md
La teoría se almacena en 756 documentos Markdown, y la práctica se define en 336 escenarios localizados. Gradle valida la estructura de las traducciones y las referencias a 316 ilustraciones originales. Los gráficos se prepararon en Blender/Cycles; el motor Android usa una geometría procedural independiente.
workflow.md
AGENTS.mdREADME.mdEl repositorio está organizado para el desarrollo con agentes: la jerarquía AGENTS.md define responsabilidades, restricciones arquitectónicas y controles de validación; los README.md describen contratos de módulos y KDoc la API y las invariantes.
Los contratos de arquitectura, diseño y localización se versionan junto al código. PLAN.md registra alcance y traspaso; los cambios de contratos incluyen actualizaciones de la documentación responsable. Las comprobaciones y la generación pasan por Gradle; CI compila ambas variantes de tienda.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationLos tests cubren estados imposibles del cubo, la conservación de capas resueltas, los planes de aprendizaje, la cancelación de solicitudes obsoletas, la restauración de sesiones y la importación de datos. CI compila ambas variantes de tienda; las comprobaciones de publicación incluyen R8, APK/AAB, sumas de comprobación y alineación de bibliotecas nativas para páginas de 16 KB.
El volumen de Kotlin cuenta líneas físicas, incluidos comentarios, líneas en blanco, buildSrc y código de benchmark, y excluye los directorios de tests. El número de tests corresponde a 1 343 declaraciones JVM y 281 declaraciones Android, no a ejecuciones. Los documentos incluyen texto de respaldo; la existencia de un escenario no implica que cada lección tenga práctica.
baselineprofile · @TestEl texto total cuenta líneas físicas de fuentes UTF-8 bajo control de versiones: código, tests, recursos XML/JSON, contenido Markdown, localización, documentación, herramientas de compilación y fuentes web. Incluye comentarios, líneas en blanco y copias de idiomas. Excluye multimedia, salida generada o compilada, código de terceros, configuración de servicios y el PLAN.md temporal. Mide las entradas de texto del proyecto, no LOC ejecutables.