O app Fomento Público foi pensar a partir de um workshop do Sebrae que eu fui no dia 12 de dezembro de 2019. E, pra ser sincero, até o momento eu não sabia o que o termo significava.
Quando vi o PDF que o Sebrae iria disponibilizar periodicamente uma relação dos editais, pensei em fazer um app para treinar o que tinha aprendido (Ah, eu coloquei como metas de 2019 aprender a programar e correr uma maratona. Estou escrevendo uma série explicando as aventuras :D)
A principal motivação de ter escolhido desenvolver esse app, foi porque o mesmo é super simples (momento babaca: em janeiro de 2019, eu não teria ideia como fazê-lo. Kekekekekke)
Como em 2010, montei uma empresa para desenvolver apps. Aprendi, do pior jeito possível, o que NÃO se dever fazer.
Aplicando o conhecimento que adquiri de gerenciamento de projetos, depois de definir a ideia básica do que o app deveria ter, defini o que NÃO deveria. E somente features não essenciais.
TER:
- UX em primeiro lugar.
- Usar componentes nativos.
- Funcionar offline.
- Favoritar os editais.
- Compartilhar os editais.
NÃO TER:
- Bugs. Parece obvio, e na verdade é :] Mas foi necessário criar todo um ambiente e protocolos para que esses bichinhos não surjam, e caso apareçam, dê para resolver rapidamente.
FEATURES NÃO ESSENCIAIS:
- Atualização em background: eu sempre desligava essa função dos apps, até que estudando na documentação do iOS, aprendi que o iOS gerencia as atualizações, escolhendo o melhor momento para tal.
Feito os objetivos macros, comecei a quebrar me pacotes menores, e usar nomes mais apropriados. Esse assunto está na série “Um Designer Aprendendo a Programar” que lançarei em 2020. Para não ficar um post TD; TL, vai um resumo.
- Conteúdo: após organizá-los, criei uma API que me fornecia um JSON.
- Layout: desenho das telas, usando componentes nativos e prototipação. Um recurso impressionante que me ajudou bastante foi poder usar o JSON citado para desenhar as telas, porque já me permitia ver como os dados iriam ficar. Me economizou horas de recodificação.
- Codificação: usando ambiente e métodos que me “obrigavam” ter um mínimo de qualidade no código. O que fiquei mais impressionado foi o lint ( no caso, swiftlint). Você cria regras para a escrita do código, tanto para manter o aspecto visual quando para evitar más prática de codificação. Outro recurso fundamental é o pipeline Continuous Integration / Continuous Deployment ou CD / CI. Resumidamente, o programador usa o git para gerenciar as versões, enviar o código escrito pro servidor e pede para alguém aprová-lo. Automaticamente, testes são feitos para garantir que o novo código não esteja quebrando o app e caso aprovado, é gerando, também automaticamente, versões do app, que pode ser para equipe interna, para beta testers ou mesmo entregar para as lojas de apps. Repito: tudo automaticamente.
Vou parar por aqui, o post, porque realmente, descobri que programar é um excelente e divertido hobby. Um quebra-cabeça que realmente faz a cabeça doer :]