L'Evoluzione delle Notifiche Email: Risparmiare Batteria con NotiMail

Stefano Marinelli — Thu, 16 Nov 2023 07:12:19 GMT

English version here

Da quando ho abbandonato BlackBerry anni fa, ho sempre cercato modi per mantenere i miei telefoni connessi ai miei account email. Mi piace ricevere email in tempo reale e, di conseguenza, ho sempre impiegato strumenti che mi permettono di ottenere notifiche immediate (o quasi) ogni volta che ricevo un messaggio.

Anni fa, utilizzavo persino le email come strumento di notifica per i miei server. Se un server diventava irraggiungibile, un'email mi avvisava e intervenivo immediatamente. Oggi, utilizzo anche altri sistemi (come bot di Telegram, Pushover, ntfy, ecc.), ma desidero ancora essere informato quando ricevo un nuovo messaggio.

Quando ho avuto il mio primo dispositivo Android (l'originale Android, l'HTC Dream), utilizzavo già IMAP IDLE, quindi il mio telefono era sempre connesso alla mia casella di posta. Con il passaggio ai primi iPhone, che non supportavano IMAP IDLE, sono passato a un'app chiamata PushMail. Questa app richiedeva di inviare copie delle email, dopodiché inviava notifiche mostrando mittente e oggetto. Non era l'ideale per la privacy, ma era efficace.

Negli anni successivi, sia con iPhone che con varie app email su Android, ho notato che i miei telefoni consumavano più batteria in modalità standby rispetto alla media. Indagando, ho scoperto che una parte significativa di questo consumo era legata alle attività in background dei miei account email. Il drenaggio energetico non era tanto legato al software, quanto all'attività di rete scatenata da qualsiasi evento nella mia casella di posta. Ad esempio, quando arriva un'email, il telefono la scarica e invia una notifica. Non controllo il telefono perché sono al computer, quindi apro l'email lì. In tempo reale, il telefono si attiva in background per segnare l'email come letta. Poi, se sposto l'email in una cartella, il telefono si attiva di nuovo per sincronizzare questa modifica.

Lo stesso processo avviene quando scrivo un'email sul mio computer. Ogni volta che il client email salva la bozza intermedia, il telefono si sveglia dal sonno per sincronizzare il messaggio. Una volta inviata, si sveglia di nuovo per rimuoverla dalle bozze e copiarla nella cartella degli inviati. Questo accade tutto il giorno, per ogni singola interazione.

Questo mi ha fatto ricordare PushMail e mi ha fatto rendere conto che non ho bisogno di tutta questa sincronizzazione continua. Tutto ciò che voglio è essere avvisato quando arriva un'email, sapendo chi l'ha inviata e di cosa tratta.

Con questo in mente, ho sviluppato NotiMail. Ho scelto di supportare più fornitori di notifiche, sebbene i miei test iniziali siano stati condotti con PushOver, che ho trovato efficiente sia su iPhone che su Android. Funziona esattamente come previsto.

Inoltre, ho compilato ntfy per FreeBSD. Ho anche generato chiavi Firebase e ricompilato l'app Android in modo da poter utilizzare il mio server sfruttando le notifiche push di Google. Questo aiuta a risparmiare ancora più batteria utilizzando la connessione dati sempre attiva ai server di Google. È un compromesso in termini di privacy, ma avevo bisogno di testare questo caso "estremo".

I risultati sono stati sorprendenti. Dopo alcuni giorni di utilizzo, ho osservato un risparmio medio giornaliero di batteria del 15% e anche un risparmio di dati variabile, ma notevole.

Sto anche testando, su un Pixel 7 con GrapheneOS, l'impatto dell'uso di notifiche push dirette con una connessione continua al mio server ntfy. È probabilmente meno efficiente in termini di batteria, ma risparmia tutti i dati associati alle operazioni della casella di posta.

In questo modo, che io abbia 1, 5 o 50 account email "connessi", non gravano sulla mia batteria (escludendo l'aumento delle notifiche, ovviamente).

NotiMail è disponibile qui: https://github.com/draga79/NotiMail

Odio PHP. Punto.

Stefano Marinelli — Thu, 24 Sep 2015 21:18:14 GMT

Lo ammetto: non ho mai amato PHP. Anche recentemente ho spiegato perché ho preferito rendere il blog statico, evitando ulteriori "complicazioni" proprio col PHP. È sui server, funziona, ma se posso evito. L'ho utilizzato in molte occasioni, lo utilizzo in molte occasioni, scrivo anche qualcosina in questo linguaggio che, però, continua a restarmi sullo stomaco.

La ragione è semplice: secondo me è pericoloso per natura. Tra mille sforzi e con impegno, stanno tentando di renderlo migliore ma gli effetti, per ora, non sono eccelsi come si vorrebbe. Il problema è che PHP è nato come un piccolo linguaggio per fare piccole cose. Si è poi espanso in quanto semplice da impiegare (basta un web server con un interprete), meno semplice da apprendere come si deve, e induce, per natura, ad errori madornali di programmazione in quanto consente (o, a volte, richiede) di fare delle cose in un modo formalmente non propriamente corretto.

PHP ha permesso a molte persone di mettersi a fare programmazione web, pur non avendone le basi. E non le ha guidate verso una giusta direzione (le persone, pur senza basi, possono imparare e diventare brave) ma spinge a fare le cose in un modo insicuro. Il programmatore, a volte, deve risolvere dei problemi legati alle carenze del linguaggio stesso.

Alla gente PHP è piaciuto. Un commento su PHP che ho letto di recente diceva una cosa del tipo "people like php because php is cheap, and people like cheap things". Ecco, il punto è proprio questo: PHP è a buon mercato, non inteso come prezzo d'acquisto ma come prezzo da pagare per impararlo e utilizzarlo. Non è come il C, o come il Java. Purtroppo, allo stesso tempo, non è pulito come il Perl o il mio amato Python (recente passione). PHP fornisce tutti gli strumenti per fare qualunque cosa. Il problema è come questa cosa verrà realizzata.

È nato come un linguaggio per non-programmatori. Ricordiamolo. Ed è stato evoluto aggiungendo roba senza curarsi di rendere il tutto coerente con quello che c'era prima. Sembra quasi una corsa, e ora la rincorsa è a risolvere i problemi che, da sempre, lo affliggono.

Ovviamente c'è chi lo conosce bene, chi lo riesce a domare sul serio. In mano a queste persone, PHP è ottimo tanto quanto i più blasonati linguaggi di programmazione. Lavoro quotidianamente con degli ottimi sviluppatori PHP, e vedo quanta fatica fanno a tenere in piedi il tutto. Li ammiro, a me salterebbero i nervi molto prima di aprire l'editor di testo. Aggiungiamo, inoltre, che il guaio è che il 90% degli sviluppatori in questo linguaggio non sono particolarmente esperti né di PHP, né di programmazione, tantomeno di sicurezza informatica. Col risultato che quasi tutte le newsletter di sicurezza che mi arrivano quotidianamente parlano di PHP stesso o di software in PHP.

Parlandone in giro, mi sento rispondere che è normale che sia così in quanto è il più diffuso, quindi necessariamente il più bersagliato. In parte ciò è vero (nessuno noterebbe un bug di sicurezza di un linguaggio usato da piccole percentuali di sviluppatori), ma osservando attentamente la documentazione stessa di PHP si percepisce immediatamente l'idiosincrasia tra la buona programmazione e la programmazione "stile PHP".

Ho anche letto, recentemente, un interessante (e ormai famoso) articolo sui problemi di PHP. Ne consiglio la lettura, pur essendo un articolo molto lungo. A mio avviso spiega bene le cose.

Insomma, PHP c'è e ci sarà a lungo, ma a me è antipatico. Ci lavoro, ci lavorerò, lo userò quando necessario ma no, non mi piace e non credo potrà mai piacermi.

Stefano Marinelli's Blog (Articoli su python)

L'Evoluzione delle Notifiche Email: Risparmiare Batteria con NotiMail

Odio PHP. Punto.