SXXXXXXX_FlightMonitor/todo.md

Certamente! È un'ottima idea avere un piano di sviluppo aggiornato e chiaro per tenere traccia dei progressi e dei passi successivi.

Ecco una versione rivista e dettagliata del piano di sviluppo, che include quanto fatto finora e i prossimi passi che abbiamo discusso. Ho cercato di mantenere la struttura a fasi, ma ho integrato le nuove comprensioni e priorità.

---

Piano di Sviluppo: FlightMonitor Application

🎯 Obiettivo Principale dell'Applicazione: Monitorare il traffico aereo in tempo reale (live) e analizzare voli passati (storico) tramite una GUI Tkinter, con visualizzazione testuale e grafica (mappa/lista).

🧱 Architettura Proposta (Modulare):

• GUI (Tkinter): MainWindow, Viste specifiche (Live, Storico), Widget riutilizzabili.
• Controller: Gestione eventi GUI, coordinamento moduli, logica applicativa principale.
• Data Layer:
  • Adapters: Moduli specifici per provider (es. OpenSkyLiveAdapter) che recuperano dati grezzi e li trasformano in...
  • Common Models: Modelli dati canonici (CanonicalFlightState) usati internamente dall'applicazione.
  • Storage: Gestione della persistenza dei dati (es. DataStorage per file SQLite giornalieri).
  • Configuration: Gestione delle impostazioni globali (config.py).
• Utils: Moduli di utilità (es. logger.py).
• Business Logic (Futuro): Filtri avanzati, analisi, allerte (potrebbero risiedere nel controller o in un modulo logic/ separato).

---

📋 Fasi di Sviluppo e Priorità:

✔️ Fase 0 – Fondamenta e Setup Iniziale (Completata)

• Struttura base del progetto (cartelle gui, controller, data, utils).
• Entry point __main__.py.
• Modulo di configurazione base (data/config.py).
• Modulo di logging robusto e configurabile (utils/logger.py) con output su console e GUI.

✔️ Fase 1 – GUI Minimale e Interazione Base (Completata)

• MainWindow (gui/main_window.py) con layout di base:
  • Controlli (selezione modalità Live/Storico, pulsanti Start/Stop).
  • Input per Bounding Box (lat/lon min/max).
  • Area di output iniziale (Canvas per la mappa).
  • Area per i log testuali (ScrolledText).
  • Status Bar con semaforo visivo e messaggi di testo.
• AppController (controller/app_controller.py) per:
  • Gestire gli eventi base della GUI (cambio modalità, start/stop).
  • Coordinare l'interazione tra GUI e logica dati (inizialmente placeholder).

✔️ Fase 2 – Modalità Live: Fetching Asincrono e Visualizzazione Base (Completata)

• Definizione Modelli Dati Canonici (data/common_models.py -> CanonicalFlightState).
• OpenSkyLiveAdapter (data/opensky_live_adapter.py):
  • Esecuzione in un thread separato (threading.Thread).
  • Polling periodico dell'API OpenSky (/states/all) per un bounding box.
  • Parsing della risposta JSON e trasformazione dei dati grezzi in oggetti CanonicalFlightState.
  • Gestione robusta degli errori API (incluso HTTP 429 Rate Limit) con strategia di backoff esponenziale.
  • Comunicazione asincrona con AppController tramite queue.Queue.
  • Invio di messaggi strutturati (dati di volo o messaggi di stato/errore) sulla coda.
• AppController aggiornato per:
  • Gestire il ciclo di vita dell' OpenSkyLiveAdapter (avvio/arresto).
  • Consumare messaggi (dati e stati) dalla coda dell'adapter.
  • Interpretare i messaggi di stato dell'adapter e aggiornare la GUI.
• MainWindow aggiornata per:
  • Visualizzare i voli (List[CanonicalFlightState]) sul tk.Canvas (punti e etichette base).
  • Utilizzare il metodo update_semaphore_and_status per riflettere lo stato comunicato dall'AppController.

✔️ Fase 3 – Persistenza Dati Live (Completata)

• DataStorage (data/storage.py):
  • Logica per creare e gestire file SQLite giornalieri (basati su data UTC).
  • Creazione automatica della directory dei database e delle tabelle (flights, positions) se non esistono.
  • Schema DB definito per memorizzare dati da CanonicalFlightState (inclusi timestamp, altitudini, velocità, ecc., e campi aggiuntivi come squawk, spi, raw_data_provider).
  • Metodi add_or_update_flight_daily e add_position_daily che accettano/usano CanonicalFlightState.
• Integrazione in AppController:
  • Quando si ricevono CanonicalFlightState dall'adapter, vengono passati a DataStorage per il salvataggio nel DB giornaliero appropriato.
  • Gestione dell'inizializzazione e chiusura della connessione a DataStorage.

---

📍 Punto Attuale (Dopo Fase 3):

• L'applicazione può recuperare dati live da OpenSky per un'area definita.
• I dati vengono aggiornati periodicamente senza bloccare la GUI.
• Gli errori API (come rate limit) sono gestiti con backoff.
• Lo stato dell'applicazione e del fetching è comunicato all'utente tramite una status bar con semaforo e messaggi.
• I dati live recuperati vengono salvati in file SQLite giornalieri.
• La struttura del codice è modulare e utilizza modelli dati canonici, preparandoci per future estensioni.

---

➡️ Fase 4 – Modalità Storico: Visualizzazione e Filtri Base (Prossima Priorità Alta)

• Caricamento Dati Storici:
  • Implementare la logica in DataStorage per interrogare i file SQLite giornalieri.
    • Metodo per ottenere voli e/o posizioni per un dato intervallo di tempo (che potrebbe coinvolgere l'apertura di più file giornalieri).
    • Metodo per cercare voli per icao24 o callsign in un range di date.
• GUI per la Modalità Storico (gui/history_view.py o integrazione in MainWindow):
  • Input per selezionare l'intervallo di date/ore.
  • Input per filtri base (es. ICAO24, callsign, forse aeroporto se avessimo quei dati).
  • Pulsante per caricare/visualizzare i dati storici.
• Visualizzazione Dati Storici:
  • Tabella (ttk.Treeview o un widget FlightTable personalizzato) per mostrare la lista dei voli e/o le loro posizioni.
  • Opzionale: Visualizzazione statica della traccia di un volo selezionato sul tk.Canvas.
• AppController:
  • Logica per start_history_monitoring e stop_history_monitoring.
  • Interazione con DataStorage per recuperare i dati.
  • Passaggio dei dati storici alla GUI per la visualizzazione.

➡️ Fase 5 – Funzionalità Avanzate e Miglioramenti

• Miglioramenti Mappa (Media Priorità):
  • Valutare l'integrazione di una libreria di mappe più avanzata (es. tkintermapview o folium se si considera un output web/HTML separato, anche se tkintermapview è più integrato).
  • Disegnare icone di aerei più realistiche (magari orientate in base al true_track).
  • Possibilità di cliccare su un aereo per vedere più dettagli.
  • Visualizzazione delle tracce dei voli (dallo storico o segmenti live).
• Analisi Semplice (Business Logic - Media Priorità):
  • Creare un modulo logic/analytics.py.
  • Funzioni per calcolare statistiche base dai dati storici (es. numero di voli per ora/giorno, rotte più frequenti in un'area, altitudini medie).
  • Visualizzazione di queste analisi nella GUI.
• Filtri Avanzati (Media Priorità):
  • Creare logic/filters.py.
  • Filtri dinamici applicabili sia ai dati live che storici (tipo di aereo, compagnia – richiederebbe dati aggiuntivi – altitudine, velocità).
• Recupero Dati Storici da API Esterne (Bassa/Media Priorità, come discusso):
  • Implementare la logica (magari in un OpenSkyHistoryAdapter) per scaricare dati storici da OpenSky (o altri provider) se mancano nei nostri DB giornalieri.
  • Questo si integrerebbe con la Fase 4, quando si cercano dati storici.
• Configurazioni Utente (Bassa/Media Priorità):
  • Salvataggio/caricamento delle preferenze utente (es. ultimo bounding box usato, tema GUI, API keys se necessarie).
  • Finestra di dialogo per le impostazioni.
• Esportazione Dati (Bassa Priorità):
  • Funzionalità per esportare i dati selezionati (live o storici) in formati come CSV o JSON.

➡️ Fase 6 – Pulizia, Test, Documentazione e Rilascio (Continua)

• Test Unitari: Scrivere unit test per i componenti core (modelli, adapter, storage, logica di business).
• Test di Integrazione: Testare il flusso completo dell'applicazione.
• Refactoring e Pulizia Codice: Continuare a migliorare la qualità del codice.
• Documentazione:
  • Migliorare docstring e commenti.
  • Scrivere/aggiornare README.md con istruzioni d'uso, setup, dipendenze.
• Gestione Dipendenze: (es. requirements.txt).
• Packaging (Opzionale): Creare un eseguibile distribuibile (es. con PyInstaller).

---

Questo piano è una guida; le priorità possono cambiare e nuove idee possono emergere. Spero che questa visione d'insieme ti sia utile! Abbiamo fatto ottimi progressi sulle fondamenta e sulla modalità live. La Fase 4 sulla modalità storico sarà il prossimo grande blocco di funzionalità.