Implementação
Cada giro do cubo depende de um sistema próprio: um modelo matemático, um motor 3D e um solucionador que considera os objetivos da lição. O aplicativo para Android usa Kotlin e Jetpack Compose.
Retrato do projeto
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 definem os componentes e temas da interface. Adaptive ajusta o layout ao tamanho da janela, e Navigation 3 cuida da navegação e da restauração de telas. O estado chega por Coroutines e Flow; Hilt conecta os módulos do aplicativo.
architecture.kt
app01Hilt / DIfeature07Compose / ViewModelonboardinglearninglessonpracticeprogresssettingseventsdomain07contracts / use caseslearninglessonpracticeportabilityprogresssettingseventsdata09repositories / storagecontentstoragelearninglessonpracticeportabilityprogresssettingseventscore14UI kit / cube / solvercommonmodeldesignsystemuikitnavigationanalyticscrashlyticsadsbillingpushhardwarecubescrambleimagesolverbaselineprofile01startup / frame timingfeature → domain ← data
modulesΣ 39app1baselineprofile1core14data9domain7feature7Kotlin · physical LOCΣ 136 019featurecoredataappdomainbuildSrcbaselineprofileA interface, os contratos de domínio e os dados ficam em módulos separados; Hilt conecta as implementações. Compose recebe estado imutável e eventos explícitos. Room armazena o histórico e o progresso de aprendizagem, DataStore guarda as configurações e Navigation 3 restaura as pilhas das seções.
android-ux.md
O Cubiq implementa abordagens que o Google destaca no Apps Experience Program: Compose, layout adaptável e edge-to-edge.
engine.glsl
Os shaders GLSL calculam materiais PBR, rugosidade e iluminação do ambiente. O modelo e a animação ficam sincronizados: voltar um passo aplica o movimento inverso, e a câmera considera o espaço entre os painéis.
A notação tipada se converte em movimentos e estados coerentes do cubo. A fila do renderer anima giros de camadas mantendo a identidade das peças e dos facelets. A fórmula é reproduzida como uma sequência de movimentos reais, com reprodução, pausa e ajuste do ritmo.
Avançar anima um novo movimento; voltar aplica o movimento inverso. Ir para uma posição restaura a cena-base e a sequência de destino. O cancelamento interrompe a emissão dos próximos movimentos; um giro já iniciado termina. O ciclo de vida EGL gerencia pause/release; sem GL, o percurso de aprendizagem continua disponível sem 3D.
solver.kt
O solucionador próprio monta a solução com fórmulas e movimentos auxiliares da lição atual. SolverRequest inclui estado do cubo, peças-alvo, alvos bloqueados, fórmulas permitidas, casos e orientação. O planejador respeita a ordem dos objetivos de aprendizagem e protege as peças resolvidas.
O planejamento por fase usa BFS limitado, busca em feixe e reconhecimento de casos F2L. A validação verifica a composição das peças, inversões, torções e paridade de permutação. A política de busca limita profundidade e largura do feixe. Mudar de lição cancela a busca e impede um resultado desatualizado.
O resultado é PracticePlan: passos, referências a fórmulas, uma linha do tempo de exibição e outra de execução. A explicação mantém a orientação didática; o motor recebe a sequência completa de execução. Resultados: plan / solved / invalid input / no constrained path.
content.md
A teoria fica em 756 documentos Markdown, e a prática é definida em 336 cenários localizados. Gradle valida a estrutura das traduções e as referências a 316 ilustrações originais. Os gráficos foram preparados no Blender/Cycles; o motor Android usa uma geometria procedural separada.
workflow.md
AGENTS.mdREADME.mdO repositório é organizado para desenvolvimento com agentes: a hierarquia AGENTS.md define responsabilidades, restrições de arquitetura e etapas de validação; os README.md descrevem contratos dos módulos, e KDoc descreve API e invariantes.
Os contratos de arquitetura, design e localização são versionados junto ao código. PLAN.md registra escopo e passagem de trabalho; mudanças nos contratos incluem atualizações da documentação responsável. Verificações e geração passam por Gradle; CI compila as duas variantes de loja.
physical text linesΣ 740 244Resources / localizationKotlin · non-testLesson MarkdownKotlin · JVM testsKotlin · Android testsBuild tooling / webDocumentationOs testes cobrem estados impossíveis do cubo, preservação de camadas resolvidas, planos de aprendizagem, cancelamento de solicitações desatualizadas, restauração de sessões e importação de dados. CI compila as duas variantes de loja; as verificações de lançamento incluem R8, APK/AAB, somas de verificação e alinhamento de bibliotecas nativas para páginas de 16 KB.
O volume de Kotlin conta linhas físicas, incluindo comentários, linhas em branco, buildSrc e código de benchmark, e exclui os diretórios de testes. A contagem de testes significa 1 343 declarações JVM e 281 declarações Android, não execuções. Os documentos incluem texto de fallback; a presença de um cenário não significa que toda lição tenha prática.
baselineprofile · @TestO texto total conta linhas físicas de fontes UTF-8 versionadas: código, testes, recursos XML/JSON, conteúdo Markdown, localização, documentação, ferramentas de build e fontes web. Inclui comentários, linhas em branco e cópias de idiomas. Exclui mídia, saída gerada ou compilada, código de terceiros, configuração de serviços e o PLAN.md temporário. Mede as entradas textuais do projeto, não LOC executáveis.