Há uma categoria de software que normalmente nasce pensando em escala: muitos usuários, contas, servidores, analytics, sincronização e monetização.

O DD • Diário Dela nasceu exatamente pelo caminho contrário.

Ele foi desenvolvido para uma única pessoa: Giovanna, minha noiva.

A ideia inicial era simples: criar algo que ajudasse no acompanhamento do ciclo menstrual e do bem-estar dela, mas sem transformar informações extremamente pessoais em dados armazenados em algum servidor de terceiros.

O resultado acabou se tornando um projeto Android bastante interessante do ponto de vista de privacidade, armazenamento local, estatística, criptografia, migração de banco de dados e engenharia de software.

Repositório: https://github.com/Miranda3000-CPU/DD-Di-rio-Dela

---

O problema

Aplicativos de acompanhamento menstrual lidam com informações que podem ser extremamente sensíveis.

Datas de menstruação, sintomas, intensidade do fluxo, dor, humor, sono, energia, observações pessoais e outras informações relacionadas ao ciclo não precisam necessariamente sair do dispositivo para que um aplicativo seja útil.

Por isso, uma das premissas do DD foi:

Se o dado não precisa sair do celular, ele não deveria sair do celular.

Isso levou a uma arquitetura essencialmente offline-first.

Não existe conta de usuário.

Não existe login.

Não existe servidor próprio para armazenar os registros.

Não existe painel administrativo com os dados.

Não existe publicidade.

E o aplicativo não depende de uma conexão com a Internet para funcionar.

---

Por que "Diário Dela"?

O nome não é apenas uma marca.

O aplicativo não foi projetado como uma plataforma genérica para múltiplas usuárias. A interface foi concebida especificamente para a Giovanna.

Isso aparece inclusive na experiência de uso:

• "Olá, Giovanna 🌷"
• "Como você está hoje?"
• "Suas previsões"
• "Seu histórico"

A intenção é que o aplicativo tenha uma experiência pessoal, e não a aparência de mais um produto genérico de saúde.

Ao mesmo tempo, isso não significa que os dados estejam codificados no aplicativo. O nome apresentado pode ser ajustado nas preferências.

---

Privacidade como requisito arquitetural

A privacidade não foi tratada apenas como uma frase na tela de configurações.

Ela influenciou decisões técnicas do projeto.

O AndroidManifest.xml, por exemplo, não declara a permissão android.permission.INTERNET.

Além disso, o projeto não utiliza Firebase Analytics, Google Analytics ou SDK de publicidade.

Os dados principais ficam em um banco Room local.

A estrutura inclui, entre outras informações:

• registros de ciclos;
• duração;
• datas;
• registros diários;
• intensidade do fluxo;
• dor;
• sintomas;
• humor;
• energia;
• qualidade do sono;
• muco cervical;
• observações.

Tudo isso permanece no armazenamento local do aplicativo.

---

E se for necessário trocar de celular?

Aqui surgiu outro problema interessante.

Se tudo fica localmente armazenado, precisamos resolver a portabilidade dos dados sem simplesmente criar uma sincronização com um servidor.

A solução foi implementar um mecanismo próprio de backup e restauração utilizando o Storage Access Framework (SAF) do Android.

O aplicativo permite exportar os dados para um arquivo .ddbackup e posteriormente importá-los.

O backup pode ser protegido com senha utilizando:

• AES-256-GCM;
• PBKDF2WithHmacSHA256;
• salt aleatório;
• autenticação integrada ao modo GCM.

A restauração também foi pensada para não simplesmente apagar o banco existente.

O mecanismo realiza um merge dos registros utilizando identificadores estáveis e datas, permitindo importar dados sem destruir o histórico já existente.

---

Um detalhe importante: backup automático

Outro ponto que considerei importante foi evitar que a privacidade prometida pelo aplicativo fosse contradita pelo próprio sistema operacional.

O aplicativo utiliza:

android:allowBackup="false"

Além disso, existem regras específicas de backup e extração de dados.

A ideia é evitar que dados íntimos sejam silenciosamente incluídos em mecanismos automáticos de backup do dispositivo.

A filosofia é simples:

O usuário deve saber quando está exportando os próprios dados.

---

Previsões sem "IA milagrosa"

Essa foi uma das partes mais importantes do projeto.

No início, seria tentador colocar no aplicativo algo como:

"Nossa inteligência artificial prevê seu ciclo com 96% de precisão."

Mas isso seria uma afirmação bastante problemática.

O ciclo menstrual possui variabilidade fisiológica e uma previsão baseada exclusivamente em histórico possui limitações importantes.

Por isso, o DD não tenta vender uma falsa precisão.

A implementação atual utiliza um modelo estatístico adaptativo e determinístico.

Entre os mecanismos utilizados estão:

• mediana dos ciclos;
• média móvel exponencialmente ponderada (EWMA);
• ponderação dos dados históricos;
• intervalos de incerteza;
• projeções para os ciclos seguintes.

A implementação utiliza EWMA com α = 0,40 e combina o resultado com a mediana histórica.

A ideia é evitar que um único ciclo atípico tenha influência desproporcional sobre a previsão.

---

Incerteza é uma informação

Outro detalhe importante foi abandonar a ideia de apresentar uma data futura como se fosse uma certeza.

Em vez de simplesmente:

"Sua menstruação será no dia X."

o aplicativo trabalha com janelas de incerteza.

A margem pode crescer conforme a projeção se distancia dos dados observados.

Isso é particularmente importante porque existe uma diferença entre:

previsão estatística

e

certeza fisiológica.

O aplicativo representa a primeira, não a segunda.

---

Projeção de 90 dias

O calendário também possui uma projeção de aproximadamente 90 dias.

Ela permite visualizar:

• ciclos futuros;
• menstruação estimada;
• janela fértil estimada;
• ovulação estimada;
• fases do ciclo.

Essas informações são visualmente diferenciadas no calendário.

Porém, existe uma distinção importante no próprio aplicativo:

Estimado não significa confirmado.

A janela fértil não confirma ovulação e não deve ser interpretada como método contraceptivo.

---

Um aplicativo de saúde precisa saber dizer "não sei"

Essa talvez seja uma das maiores lições técnicas do projeto.

Quando trabalhamos com informações relacionadas à saúde, existe uma tentação de transformar qualquer algoritmo em uma autoridade.

Não deveria ser assim.

Uma previsão calculada por um algoritmo a partir do histórico de uma pessoa continua sendo uma previsão.

Por isso, o DD inclui avisos explícitos de que as previsões são estimativas para acompanhamento pessoal e não substituem avaliação médica ou ginecológica.

O aplicativo também não deve ser utilizado como método contraceptivo.

---

Base científica

A implementação não foi construída apenas em torno de regras arbitrárias.

Entre as referências utilizadas no projeto estão trabalhos sobre variabilidade do ciclo menstrual e acompanhamento menstrual, além de referências clínicas do American College of Obstetricians and Gynecologists (ACOG).

Uma das referências utilizadas é:

Li et al. (2021) — Characterizing the normal menstrual cycle and its variations using mobile application data, publicado no Journal of the American Medical Informatics Association (JAMIA).

Também são consideradas referências do ACOG sobre o ciclo menstrual como sinal vital e trabalhos sobre variabilidade das fases do ciclo.

A intenção não é transformar o aplicativo em dispositivo médico.

É justamente o contrário: utilizar literatura científica para evitar que o software faça afirmações que os dados não sustentam.

---

A arquitetura Android

O projeto atualmente utiliza:

• Kotlin 2.2.10
• Jetpack Compose
• Material Design 3
• Room 2.7.0
• Kotlin Coroutines
• KSP
• Robolectric
• Roborazzi

A persistência está organizada utilizando Room.

Existe uma separação entre entidades, DAO, repositórios e camada de apresentação.

Algumas das principais estruturas são:

app/
└── src/main/java/com/example/
    ├── backup/
    │   ├── BackupCrypto.kt
    │   ├── BackupManager.kt
    │   └── BackupModels.kt
    │
    ├── data/
    │   ├── AppDatabase.kt
    │   ├── CycleDao.kt
    │   ├── CycleEntity.kt
    │   ├── CycleRepository.kt
    │   ├── DailyLogDao.kt
    │   └── DailyLogEntity.kt
    │
    ├── model/
    │   └── CyclePrediction.kt
    │
    ├── notification/
    │   ├── CycleAlarmReceiver.kt
    │   └── NotificationHelper.kt
    │
    ├── ui/
    │   ├── CycleViewModel.kt
    │   └── components/
    │
    └── util/
        └── CycleCalculator.kt

Isso tornou possível manter a lógica de cálculo relativamente independente da interface.

---

Migração de banco também é parte do produto

Existe uma parte do desenvolvimento de aplicativos que muitas vezes passa despercebida quando estamos fazendo protótipos:

o usuário já possui dados.

No caso do DD isso é particularmente importante.

A Giovanna já utiliza uma versão anterior do aplicativo.

Portanto, lançar uma nova versão não poderia significar:

"Instale novamente e comece tudo de novo."

O applicationId foi mantido como:

com.aistudio.ciclo.menstrual

e o banco possui migração entre versões.

A migração MIGRATION_1_2 foi criada para preservar o histórico existente enquanto novas estruturas foram adicionadas.

Esse tipo de preocupação muda completamente a forma de pensar sobre uma atualização.

Não estamos apenas atualizando código.

Estamos atualizando um software que possui memória.

---

Testes

O projeto também possui uma suíte de testes para algumas das partes mais sensíveis.

Entre elas:

• cálculo do ciclo;
• janelas de incerteza;
• sinais de atenção;
• migração do Room;
• backup;
• criptografia;
• restauração;
• merge de dados;
• notificações;
• renderização visual.

Também existem testes de screenshot utilizando Roborazzi.

Isso permite comparar a interface renderizada e detectar alterações visuais inesperadas.

---

Notificações privadas

As notificações possuem dois modos.

No modo normal, o aplicativo pode apresentar informações relacionadas ao ciclo.

No modo privado, o conteúdo exibido na tela de bloqueio é reduzido para algo genérico, como:

"Há uma atualização sobre seu ciclo."

Isso resolve um problema simples, mas importante.

Mesmo que o aplicativo não envie dados para a Internet, uma notificação pode revelar informações pessoais para alguém que esteja olhando para a tela bloqueada.

Privacidade também envolve esse tipo de detalhe.

---

Interface

A interface foi construída com Jetpack Compose e possui:

• tela inicial;
• calendário visual;
• histórico;
• gráficos;
• registro diário;
• sintomas;
• humor;
• energia;
• sono;
• configurações;
• notificações;
• backup e restauração.

Algumas telas do projeto também são documentadas no próprio repositório.

---

O que eu aprendi construindo isso

O mais interessante no DD não foi simplesmente criar um calendário menstrual.

Foi perceber como alguns requisitos aparentemente simples mudam completamente a arquitetura.

"Não quero que os dados saiam do dispositivo."

Isso implica pensar em:

• permissões;
• dependências;
• analytics;
• backups automáticos;
• armazenamento;
• exportação;
• criptografia;
• restauração;
• migração;
• atualizações.

"Quero fazer previsões."

Isso implica pensar em:

• variabilidade;
• incerteza;
• estatística;
• dados insuficientes;
• limites do modelo;
• comunicação responsável.

"E a Giovanna já usa o aplicativo."

Isso implica pensar em:

• compatibilidade;
• applicationId;
• assinatura;
• versionamento;
• migrações;
• preservação dos dados.

No fim, um aplicativo pequeno pode envolver problemas de engenharia bastante grandes.

---

O estado atual

O DD • Diário Dela é atualmente um aplicativo Android pessoal, offline e privado, desenvolvido especificamente para a Giovanna.

A versão atual utiliza:

versionCode = 5
versionName = "5.0"

O projeto permanece aberto no GitHub:

https://github.com/Miranda3000-CPU/DD-Di-rio-Dela

A ideia não é transformar o DD em uma plataforma de saúde para milhões de pessoas.

O objetivo original continua sendo o mesmo:

Construir uma ferramenta útil para uma pessoa específica, mantendo os dados dela sob o controle dela.

E, para mim, esse projeto acabou sendo uma forma bastante concreta de estudar uma combinação que considero interessante:

Android + privacidade + estatística + segurança + engenharia de dados + experiência pessoal.