Autoria de Swift PlaygroundBooks — parte 1
Estrutura do PlaygroundBook
Olá, mundo!
Desde que eu comecei o meu canal no Youtube, o Programa de Índio, eu tenho me aprofundado na criação de PlaygroundBooks e quero começar a compartilhar aqui com vocês um pouco dessa minha jornada de aprendizado.
Se você ainda não conhece o Programa de Índio, pare aqui um pouquinho e confira. Garanto que vai curtir! Aproveita e já se inscreva pra continuar acompanhando os vídeos, ok?
Minha vontade de trabalhar com o Swift Playgrounds aumentou quando a Apple começou a usar playgrounds para avaliar os alunos no famoso Scholarship para o WWDC: uma celebração de estudantes do mundo inteiro que visam se tornar desenvolvedores iOS e querem participar do maior evento para desenvolvedores iOS promovido pela Apple.
A cada ano que passa, vejo que o pessoal está elevando o nível dos playgrounds e tem surgido coisas realmente incríveis a partir daí.
Se você ainda não conhece o Playgrounds, corre pra conhecer. Ele tem essa cara bacana aqui:
Disponível para iPad e mac, é uma plataforma usada principalmente para estudo de lógica de programação em Swift por meio de PlaygroundBooks (estes livros interativos) bem divertidos. Este da imagem acima é o Aprenda a Programar 1, em que o personagem Byte apresenta os conceitos iniciais de programação.
Pode parecer bem simples, mas o aplicativo é uma ótima ferramenta par aprendizado e teste de código. Não é apenas quem está começando a aprender que pode se beneficiar dele. Desenvolvedores utilizam a plataforma para testar algum algoritmo antes de aplicar no projeto principal.
No aplicativo é possível utilizar alguns templates básicos para programar. São os chamados Starting Points!
Cada um deles apresenta uma estrutura bem definida que dá acesso a alguns dos principais frameworks da Apple e outros que foram criados especificamente para os Playgrounds.
Se você já desenvolve, fique de olho nas novidades! Este ano temos alguns novos templates que dão acesso aos frameworks de acessibilidade! Confira nos vídeos do WWDC2020
Mas nesta série de artigos que começo hoje, quero mostrar como ir além do básico e se tornar autor de playgroundbooks incríveis!
Cada template destes pode ser duplicado e alterado por qualquer usuário. Entretanto, se o arquivo é resetado, ele volta ao seu estado original. Se usamos um template do tipo padrão blank, quando resetamos, todo a nossa alteração é perdida.
Ao mesmo tempo que isso é interessante para o aprendizado, pois podemos sempre voltar atrás ao ponto de partida, em algumas vezes isso pode ser bem frustrante quando você distribui um trecho de código.
Veja algumas situações em que isso pode ser um problema:
Criando a partir de um template
No Programa de Índio eu tenho discutido muito sobre arte generativa e procurado criar algoritmos simples com efeitos visuais bacana. Em um dos vídeos eu falei sobre o algoritmo 10Print. Saca só:
E no vídeo, eu desenvolvi um playgroundbook com as classes principais que criamos.
Até aí tudo bem! Agora imagine que você quer criar algo em cima do que eu comecei. Se você duplicar este arquivo e começar a editar, você terá algo novo em poucos minutos. Mas imagine que você teve um problema no código, que travou o seu playground e você teve que resetar para poder continuar. Tudo o que você fez e tudo o que eu fiz foi apagado, uma vez que eu usei o template blank.
Uma forma que a gente tem para contornar este problema é gerar um playgroundbook que funcione como um template. Assim, ele terá a base do código que será mantida toda vez que for resetado.
Criando conteúdo para sala de aula
Se você é um professor e está criando o conteúdo da sua aula de programação, ou mesmo de qualquer outra disciplina, você pode querer deixar a base da sua aula imutável e permitir que o aluno continue editando apenas o que é conveniente para o momento.
Com um template bem definido, você pode determinar qual a parte do código pode ser alterada, criar cenas animadas de abertura para cada capítulo, avaliar o progresso do seu aluno e muito mais. E o mais interessante: você pode compartilhar a base com os alunos sem medo de que ela será perdida.
Estruturando
Ok! Agora que já falamos sobre o porquê de usarmos um playgroundbook customizado, vamos entender a estrutura deste arquivo.
Assim como um livro, o playgroundbook é formado por capítulos e páginas, que são apresentadas ao longo da experiência do aluno/usuário. O arquivo que é gerado no app Playgrounds, da Apple tem a extensão .playgroundbook.
Acessando a documentação da Apple é possível identificar as suas partes. mas reconheço que a documentação não é muito intuitiva e que é preciso navegar entre várias páginas para entender o funcionamento. Mas no fim, não é tão complicado. Vem comigo que eu te mostro!
Na prática, o arquivo no formato playgroundbook é apenas uma pasta compactada com uma estrutura de outras pastas e arquivos necessários para que o app funcione bem. Olha só o conteúdo de um arquivo deste tipo:
Simples não é?
Uma pasta Contents e outra Edits.
Tá bom, eu sei que não é só isso! Mas confia em mim que apesar de termos mais pastas e arquivos aqui, ainda assim a estrutura é bem tranquila.
A pasta Contents é responsável por abrigar todo o conteúdo base do seu playground. Ou seja, tudo aquilo que deve permanecer quando ele for resetado.
Já a pasta Edits é criada a partir do momento em que você roda o playground e começa a fazer suas alterações enquanto usuário. Ou seja, tudo o que você modificar em um playground, é salvo aqui.
Você vai ver que o conteúdo delas é bem semelhante. Vamos começar detalhando a pasta Contents, que vai ser o foco dessa série de artigos.
Dentro dela, temos duas novas pastas: uma para os capítulos e outra para os módulos de código do nosso projeto. Além disso, temos um arquivo chamado Manifest.plist
Manifest.plist
Vamos falar primeiro do arquivo. O formato plist (que vem de Property List) nada mais é do que um domínio específico de XML, um DTD. Falei grego? Vamos com calma! XML é um formato de arquivo de marcação que serve para determinar elementos e seus relacionamentos. Um DTD define quais são os elementos válidos neste domínio.
Olha só! Se eu abro este arquivo no XCode, ele tem essa cara:
Veja que ele é uma lista de propriedades. Cada propriedade tem o seu nome, ou chave (key), um tipo (type) e um valor (value).
Por exemplo, a última propriedade deste arquivo se chama UserModuleMode, é do tipo string e seu valor é Full.
O Xcode na verdade criou uma visualização bonitinha em forma de tabela deste arquivo XML. Mas na verdade ele é assim:
Aqui eu abri o mesmo arquivo no editor de texto comum do mac. Calma, não se assuste! Respira e olha de novo. Algumas palavras nesse código você já conhece!
Na imagem, as 4 primeiras linhas estão ali para dizer que este XML deve ser validado como um formato específico de propriedades criado pela Apple (o DTD, lembra?).
Depois, nós temos uma tag chamada dict. Tag em uma linguagem de marcação indica um elemento. Todo elemento precisa ser aberto, ter seu conteúdo indicado e depois fechado. No XML e linguagens derivadas, como o HTML, por exemplo, uma tag é delimitada pelos sinais < e >. Quando estamos falando de uma tag de fechamento, acrescentamos uma / depois do primeiro sinal.
Olhe de novo na imagem, na quinta linha temos a tag <dict> e na penúltima, a tag </dict>. Isso significa que todo o conteúdo entre as duas faz parte deste elemento chamado dict, que é uma abreviação para dictionary, ou dicionário, em Português. Logo, temos um dicionário de propriedades sendo criado aqui.
De forma análoga, podemos analisar as tags deste elemento. Veja que temos um padrão. Sempre temos uma tag key seguida de outra tag que pode variar de acordo com o contexto. Assim, a tag key representa o nome da propriedade e a tag que vem logo abaixo dela, representa o tipo e o valor.
Você consegue localizar a mesma propriedade que vimos no exemplo do XCode (UserModuleMode)?
Logo antes da tag</dict>, temos duas outras tags (nas duas linhas acima). Veja:
Olha só! Temos então a propriedade UserModuleMode, do tipo string (que é um formato de texto) e seu valor é Full.
Exatamente como conferimos no XCode.
Ou seja, o XCode apresenta o arquivo de uma forma mais amigável, mas você não precisa necessariamente ter este aplicativo para trabalhar com o seu playgroundBook. É possível editar estas propriedades em qualquer editor de texto.
Mas pra que serve este arquivo?
Ele vai servir para conectar as pastas que criamos de forma que o compilador (o app Playgrounds) possa entender.
Este arquivo é contextual, ou seja, ele determina as propriedades das pastas e arquivos que estão no mesmo nível dele.
No playgroundbook nós vamos encontrar outros arquivos como esse. Este é o primeiro e traz as propriedades do livro como um todo.
Ao longo desta série, vamos alterar várias propriedades deste arquivo, mas se você está curioso para saber quais são elas, aqui está o link da documentação oficial:
Capítulos e páginas
Cada capítulo de um playgroundbook é criado dentro da pasta Chapters:
Veja que dentro desta pasta nós temos uma pasta para cada capítulo. No caso deste exemplo, temos um capítulo só. O nome da pasta pode ser determinado por você e deve terminar sempre com .playgroundchapter.
Temos ali outro arquivo Manifest.plist, que agora trará as propriedades deste capítulo. E ainda, temos ali uma nova pasta chamada Pages.
E o que será que temos dentro da pasta Pages? Dou um doce se adivinhar!
Exatamente! uma série de pastas para cada página do nosso capítulo. Cada pasta de página tem um arquivo de propriedades (que surpresa!) e um arquivo swift com o código dela.
Veja que as pastas de páginas terminam com o formato .playgroundpage. Falaremos mais sobre elas e a pasta de template mais adiante.
Pronto! Simples assim. um conjunto de pastas, arquivos de propriedades e arquivos de código.
Falta alguma coisa? Ah sim, os módulos!
Módulos
Na pasta UserModules teremos todo o código em Swift que pode ser usado pelo usuário.
Veja que temos ali um arquivo SharedCode.swift. Nele nós podemos armazenar os primeiros algoritmos compartilhados com o usuário.
Mas vamos falar disso num outro artigo? Claro!
Finalizando
Não tenha medo fazer algo errado! Pode parecer muita coisa, mas aos poucos você vai se familiarizando com a estrutura.
Esta série de artigos está organizada de forma a te ajudar de forma crescente a ir trabalhando com o playgroundbook. Ao final de cada artigo estão os links para os demais.
Seja corajoso! Vamos criar algo maravilhoso ao final da série, ok? Não hesite em me chamar caso precise de uma mãozinha. E se até agora você não se inscreveu no Programa de Índio, corre lá!
Tchau
Índice da série
- Estrutura do PlaygroundBook
- Rosas Polares
- Adicionando uma capa
- Adicionando capítulos e páginas
- Cutscenes: cenas de transição
- Markup: criando o storytelling
- Customizando a barra de sugestão de código
- Tradução e Localização
- LiveView: alterando o código em tempo real
- Avaliando o aluno
- Performance e acesso: Escondendo os Módulos básicos e desabilitando Debug
- Playground Subscriptions: compartilhando o seu trabalho
