Proposta

[mattmezza]

Provo a raffinare l'idea di @grosa1 espressa qui: realizzare un notifier per i cambiamenti dei dati della carriera dello studente.

Mia idea

• Gli studenti richiedo tramite i client MyUnimol di sottoscriversi ai cambiamenti dei dati, accettano di inviare username e password per la memorizzazione su di un server.
• Gli studenti si possono sottoscrivere a diversi canali
  • Nuovo esame registrato
  • Nuovo appello disponibile
  • Nuova news pubblicata
    • in ateneo
    • in Dipartimento
    • in corso di studi (per i corsi di studi supportati)
  • etc... (aggiungere altre)
• Ad ogni cambio della configurazione corrisponde una chiamata ad una API da realizzare che fa cose su un db (CRUD operations basicamente)
• Il notifier gira (ogni tot minuti, da una certa ora ad una certa ora, diciamo dalle 8am alle 11pm ogni 15min) e per ogni utente nel db esegue una serie di chiamate alle API di MyUnimol (in base a quali servizi lo studente particolare sia sottoscritto) salvando le info risultato, l'md5 delle stesse e il timestamp nel db
• Ad ogni chiamata si effettua un controllo se i due digest (vecchio e nuovo) siano o meno uguali
  • se uguali skip
  • se differenti si controlla il campo (eventuale) already_notified
    • se true skip
    • se false si controlla il timestamp
      • se < di tot tempo skip
      • altrimenti si prende il contenuto vecchio (non il digest, ma tutta l'info), si fa un diff e si estraggono le info che sono cambiate, poi si notifica allo studente (a seconda del canale scelto)

Note: ad ogni chiamata si deve verficare che la password non sia stata cambiata, nel cui caso si deve inviare una notifica allo studente per fargli risettare la password.

Si hosta il notifier sulla stessa macchina delle api magari, cosi le mandiamo in localhost.

Che ne pensate?

[intersimone999]

Mi sembra un'ottima idea! Però salvare nomi utente e password mi sembra un po' rischioso. Se invece facessimo partire le richieste dall'app, con una frequenza un po' minore (es: ogni 1/2 ore)? La richiesta conterrebbe solo username e password (le subscription sarebbero comunque memorizzate lato server) e eviteremmo la memorizzazione. L'unico problema è che non so se Android e iOS (soprattutto) permettono di inviare richieste senza interazione da parte dell'utente. In quel caso saremmo costretti ad avere un database con username e password.

[grosa1]

Simone penso si possa fare. Comunque sarebbe utile anche una schermata delle impostazioni per decidere da quali canali di notifica si vuole ricevere. Magari ci facciamo un json delle preferenze che viene aggiornato ogni volta che si cambia la voce.

[mattmezza]

Ottima @intersimone999 in realtà ho paura proprio di questo! Dovremmo impostare un timer nelle app, non so se è un metodo reliable... Se non notifichiamo in maniera affidabile potrebbe non aver senso!
Tipo, impostiamo un timer in app tre volte al giorno per fare una chiamata http ad un'api che fa partire un check... Metti che non si ha campo? Non parte nulla... Poi dopo un giorno, accendi il telefono, parte il timer e arrivano le notifiche

[grosa1]

Credo che sia meglio evitare tutti questi problemi gestendo il servizio di notifica tutto nel server. L'app che ho già fatto era in ionic che prevedeva l'utilizzo di un token a parte per identificare il dispositivo(e quindi l'utente) nel il sistema di notifiche ionic. Secondo me prendendo spunto da questo evitiamo di salvare le credenziali e di cambiarle ogni volta, perchè il token sarà sempre lo stesso, lo facciamo cambiare magari ad ogni log in.