Um deck é um conjunto de cartas com perguntas e respostas. Precisamos levar em consideração nessa estrutura, uma funcionalidade de versionamento.
Os decks serão carregados em memória na primeira vez que o aplicativo é aberto. Precisamos guardá-los em memória para facilitar a leitura destes decks, principalmente utilizando uma estrutura de paginação, algo que não temos caso os decks sejam carregados direto de JSONs toda vez que a aplicação abre. A proposta de modelagem de um deck é a seguinte:
{
'id': string,
'name': string,
'description': string,
'tags': [string], // Exemplos: algoritmo, variáveis, funcoes, etc.
'category': string, // Exemplos: java, python, swift, git, etc.
'cards': [
{
'id': string,
'question': [Block],
'answer': [Block],
}
]
}
Um block é um bloco de conteúdo. Podemos fazer a analogia com os blocos do Notion. A ideia dessa estrutura, é dispensar a utilização de WebViews e nos dar mais flexibilidade na hora da formatação do conteúdo do Deck. Assim, os Blocks possuem um tipo (BlockType
) e eles serão formatados conforme esse tipo.
{
'type': BlockType,
// If `type` is htmlText, will contain BASIC HTML tags
// If `type` is image, will be the imageUrl,
// If `type` is code, will have formatted code using tabs (\\t) and new lines (\\n)
'content': string,
}
Os tipos suportados de blocos. A principio, os tipos listados abaixo são os que serão utilizados pela ferramenta, não se fazendo necessário o uso de tipos como vídeos, GIFs, animações, etc.
Como tipos suportados de html para o tipo htmlText
, podemos utilizar os mesmos do plugin [flutter_html](<https://pub.dev/packages/flutter_html>)
, tendo em vista que muito provavelmente será o plugin utilizado devido sua popularidade e a nossa experiência prévia com o mesmo.
Para o tipo de code
, podemos usar uma biblioteca que suporta syntax highlight de diferentes linguagens. Uma das bibliotecas que parece cumprir bem essa papel, é a flutter_highlight
. Alternativamente, podemos também produzir o trecho de código em algum editor e criar uma imagem, porém essa seria uma alternativa caso não fosse possível criar o syntax highlight dentro da aplicação.
enum {
text,
htmlText,
image,
code,
}
Como vamos carregar os decks em memória, precisamos fazer uma migração do banco sempre que um deck é deletado, alterado ou adicionado. Para mantermos esse controle, vamos criar um documento de versionamento. Esse documento guarda uma relação Deck → Versão. A partir dessa relação, toda vez que a aplicação é atualizada, percorremos esse arquivos para verificar a versão de cada deck, para ver se ele foi atualizado. Todos os decks que tiverem com uma versão superior à atual, tem seu conteúdo SOBRESCRITO pelo conteúdo do JSON do deck.