70 lines
3.8 KiB
Markdown
70 lines
3.8 KiB
Markdown
# FightRate — monitoramento contínuo, histórico customizado e indicadores BPM
|
|
|
|
## Objetivo
|
|
Corrigir o fluxo para que o FightRate se comporte como um monitor contínuo de sensor cardíaco, e não como um app dependente da janela de treino. A janela de treino deve apenas destacar um intervalo dentro do fluxo contínuo. Também adicionar consulta histórica customizada por data/hora/minuto, estabilizar a UI do histórico e documentar indicadores úteis derivados de BPM.
|
|
|
|
## Problemas relatados
|
|
1. BPM em tempo real só aparece depois de abrir e fechar uma janela de treino.
|
|
2. Histórico precisa consultar intervalo preciso por dia, hora e minuto, inclusive múltiplos dias.
|
|
3. Histórico tem divisores redundantes entre controles, janelas salvas e registros.
|
|
4. Em “Uso Total”, o item expandido colapsa quando entra novo dado em tempo real.
|
|
5. É necessário mapear indicadores técnicos/científicos extraíveis de BPM para evolução futura.
|
|
|
|
## Critérios de sucesso
|
|
- Ao abrir o app, se o monitor estava ativo ou há sensor salvo, o app retoma o monitoramento contínuo automaticamente.
|
|
- Após conectar ao sensor peitoral, os dados começam a atualizar o app inteiro sem depender de janela de treino.
|
|
- Abrir/fechar janela de treino não interrompe nem inicia artificialmente o stream contínuo; só marca um intervalo para histórico.
|
|
- Histórico permite modo “Faixa” com início/fim definidos por dia, hora e minuto.
|
|
- Faixa customizada funciona no mesmo dia e entre dias diferentes.
|
|
- Uso Total mantém o item expandido mesmo quando novas amostras chegam em segundo plano.
|
|
- Divisores do histórico ficam lineares: uma linha sutil por seção/registro, sem duplicação visual.
|
|
- Pesquisa de indicadores BPM gera relatório com fórmulas, dados necessários, limites e recomendações.
|
|
- Sem dados fake; gráficos e métricas continuam derivados de amostras reais.
|
|
|
|
## Arquitetura proposta
|
|
### Monitoramento contínuo
|
|
- Manter BLE e background capture no serviço nativo Android.
|
|
- No hook RN, diferenciar claramente:
|
|
- `isMonitoring`: stream contínuo ativo.
|
|
- `isCapturing`: janela de treino ativa.
|
|
- `samples`: amostras contínuas em memória recente.
|
|
- Na inicialização do hook, depois de `getCaptureSnapshot`, se o snapshot indicar monitor ativo/sensor salvo, retomar/confirmar `startMonitoring` sem abrir janela.
|
|
|
|
### Histórico customizado
|
|
- Criar lógica pura para filtrar amostras por intervalo `[start, end]`.
|
|
- Usar a mesma fonte de verdade (`continuous_heart_rate_samples`) para “Uso Total” e faixa customizada.
|
|
- Representar a seleção com componentes simples sem dependência nova: campos de data e hora/minuto via `TextInput`, com validação e presets.
|
|
|
|
### Estabilidade do Uso Total
|
|
- Não usar ID derivado de `startedAt-endedAt-count` como única identidade quando blocos vivos mudam com novas amostras.
|
|
- Manter expansão por `startedAt` do bloco e re-resolver o bloco depois de cada atualização.
|
|
|
|
### Indicadores BPM
|
|
- Produzir documento separado com métricas implementáveis depois:
|
|
- FC média/mínima/máxima;
|
|
- zonas de intensidade;
|
|
- tempo em zona;
|
|
- carga interna/TRIMP;
|
|
- recuperação pós-esforço;
|
|
- deriva cardiovascular;
|
|
- variabilidade de FC quando houver RR intervals;
|
|
- alertas de limiar e anomalias.
|
|
|
|
## Fora de escopo
|
|
- Trocar BLE stack.
|
|
- Adicionar dependências nativas de calendário/data.
|
|
- Alterar design aprovado fora dos pontos pedidos.
|
|
- Criar diagnóstico médico automatizado sem validação clínica.
|
|
|
|
## Testes esperados
|
|
- Testes unitários para agrupamento de uso contínuo estável.
|
|
- Testes unitários para filtro de intervalo customizado.
|
|
- Testes existentes continuam passando.
|
|
|
|
## Verificação
|
|
- `npm run typecheck`
|
|
- `npm run lint`
|
|
- `npm test -- --runInBand`
|
|
- `npm audit --audit-level=moderate`
|
|
- `./gradlew assembleRelease -PreactNativeArchitectures=arm64-v8a`
|