diff --git a/app/src/main/java/com/example/vdcscore/ui/gallery/Match.java b/app/src/main/java/com/example/vdcscore/ui/gallery/Match.java index 5dbd200..a3db68a 100644 --- a/app/src/main/java/com/example/vdcscore/ui/gallery/Match.java +++ b/app/src/main/java/com/example/vdcscore/ui/gallery/Match.java @@ -195,4 +195,16 @@ public class Match { public void setMatchReportUrl(String matchReportUrl) { this.matchReportUrl = matchReportUrl; } + + private boolean played; + + @PropertyName("played") + public boolean isPlayed() { + return played; + } + + @PropertyName("played") + public void setPlayed(boolean played) { + this.played = played; + } } diff --git a/docs/05_PROGRESSO_E_ESTADO_ATUAL.md b/docs/05_PROGRESSO_E_ESTADO_ATUAL.md index 0c9f39a..00f0c55 100644 --- a/docs/05_PROGRESSO_E_ESTADO_ATUAL.md +++ b/docs/05_PROGRESSO_E_ESTADO_ATUAL.md @@ -137,3 +137,34 @@ As notícias foram promovidas a ecrã principal (Ínicio) da aplicação. A sec **O que foi removido** - O cabeçalho estático no ficheiro `fragment_news.xml` foi removido para promover um design mais nativo e espaçoso. + +## Relatório de Intervenção (Preparação de Jogos em Direto - Live Matches) + +**Progresso Geral Atualizado** +Foi implementada a lógica para o Scraper detetar jogos que ainda não foram disputados (sem golos) e prepará-los automaticamente na base de dados para acompanhamento em direto. A estrutura base do jogo é injetada no Firebase de modo a que um árbitro ou gestor possa depois adicionar eventos em tempo real, sem o risco do Scraper apagar o seu trabalho a meio do jogo. + +**O que foi criado ou adicionado** +- Adicionada a extração inicial (usando um `ValueEventListener` com `CountDownLatch`) para obter todas as chaves (IDs de jornada) dos jogos já registados no nó `live_matches`. +- Adicionada lógica no processo de iteração dos jogos do `StandingsScraper.java` para injetar um objeto JSON preparatório nos jogos futuros. A estrutura inclui o nó `info` (com os nomes, logótipos, estado de agendado, e 0 golos) e o nó de `eventos` com o primeiro texto automático ("Partida iniciada em..."). + +**O que foi modificado e porquê** +- O `StandingsScraper.java` foi modificado para suportar o estado de "agendado". Para além de não enviar golos para a classificação nestes jogos, ele avalia ativamente se deve instanciar o jogo no Firebase. O bloqueio anti-overwrite (ler os `existingLiveMatches`) foi criado intencionalmente porque se o Scraper corresse a meio de uma partida, faria reset dos golos para `0` e apagaria as anotações do árbitro. + +**O que foi removido** +- Nada foi removido. Apenas foi expandida a robustez e conectividade do Scraper. + +## Relatório de Intervenção (Campo 'played' nas Jornadas) + +**Progresso Geral Atualizado** +Foi implementada a lógica para distinguir entre jogos já realizados e jogos agendados através de um novo campo booleano `played`. Esta melhoria permite à aplicação Android e a outros sistemas identificar rapidamente o estado de cada partida sem necessidade de inferência baseada na presença ou ausência de golos em tempo de execução. + +**O que foi criado ou adicionado** +- Adicionado o campo `played` (booleano) a cada objeto de jogo dentro do nó `jornadas` na Firebase. +- No projeto Android, foi adicionado o atributo `played` à classe `Match.java` (no package `ui.gallery`), juntamente com os seus getters e setters devidamente anotados com `@PropertyName("played")`. + +**O que foi modificado e porquê** +- **StandingsScraper.java:** Modificado para calcular o valor de `played`. A lógica baseia-se na presença de dados de golos (`homeGoals` / `awayGoals`) retornados pela API da AFAVCD. Se existirem golos registados, o campo é definido como `true`; caso contrário, é `false`. +- **Match.java (Android):** Atualizado para permitir que a aplicação consuma esta nova propriedade da base de dados, facilitando futuras implementações de UI (ex: esconder scores em jogos não jogados ou aplicar estilos diferenciados). + +**O que foi removido** +- Nenhuma funcionalidade foi removida. Trata-se de um enriquecimento do modelo de dados existente.