Notifiche push via Chrome anche su Android: ecco i primi siti compatibili

Notifiche push via Chrome anche su Android: ecco i primi siti compatibili

Google ha rilasciato un nuovo comunicato in cui specifica nel dettaglio il funzionamento delle nuove notifiche push attraverso Chrome, che ci permetteranno di diminuire drasticamente la nostra dipendenza dalle app

di pubblicata il , alle 09:31 nel canale Telefonia
Google
 

La scorsa settimana Google aveva annunciato il rilascio di Chrome 42 con supporto alle notifiche push. A tornare sull'argomento è la stessa società, che sottolinea l'importanza della funzionalità, e come questa possa consentire al web designer di coniugare nel solo sito web i vantaggi di un'app nativa a quelli della presenza online. Vantaggi che si traducono per l'utente in una migliore esperienza d'uso e, soprattutto, nella liberazione dalla dipendenza dalle app installate sullo smartphone.

Ad oggi, per ricevere una notifica push sul proprio cellulare è necessario installare l'app correlata, mentre su desktop si deve tenere Chrome e la tab del servizio aperti. Le due nuove API, Push API e Notification API, di Chrome 42 per desktop e Android consentono di aggirare i limiti su entrambe le piattaforme, "risparmiando agli utenti la fatica di controllare manualmente gli aggiornamenti per tutta la giornata" e "consentendo nuove esperienze, dalla comunicazione in tempo reale agli aggiornamenti in diretta delle breaking news".

Chrome, notifiche push su Android

Parteciperanno alla novità una serie di siti di notevole caratura, fra cui Facebook, eBay e Pinterest, i cui servizi inizieranno ad inviare notifiche push su Chrome nelle prossime settimane. Il sito che supporta la feature chiederà al visitatore se attivarla o meno: in caso di risposta affermativa, sarà Chrome ad inviare le notifiche push, che potranno essere gestite in ogni momento dal browser web stesso. L'utilità di una funzione di questo tipo è chiara: permettere l'invio di notifiche ai servizi che non hanno app native ed eliminare la dipendenza dalle app.

Con le notifiche via Chrome, ad esempio, potremo non avere la necessità di installare l'app di eBay esclusivamente per seguire un'asta quando siamo in giro, o non dovremo tenere l'applicazione di Facebook installata se aspettiamo una risposta importante attraverso il servizio. In altre parole, parliamo di un risparmio consistente nello spazio d'archiviazione integrato dello smartphone, soprattutto considerando molti servizi informativi che preferiamo ancora consultare via desktop o attraverso browser, ma con cui vogliamo tenerci costantemente informati.

Considerata la diffusione di Chrome, è probabile che la funzionalità sarà abbracciata presto da molti altri servizi web, consentendo ai propri utenti di eliminare sullo smartphone parecchie applicazioni da decine di megabyte che utilizzano solo per ricevere le tanto agognate notifiche push.

20 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Unrealizer22 Aprile 2015, 09:47 #1
Originariamente inviato da: Articolo
Considerata la diffusione di Chrome, è probabile che la funzionalità sarà abbracciata presto da molti altri servizi web, consentendo ai propri utenti di eliminare sullo smartphone parecchie applicazioni da decine di megabyte che utilizzano solo per ricevere le tanto agognate notifiche push.


Chrome come IE6, ancora e ancora
aksh3722 Aprile 2015, 10:49 #2
I browser stanno diventando sistema operativi. Sembra la storia di emacs. Non so voi, ma io con il browser navigo e scarico roba e basta.
Bazzu22 Aprile 2015, 12:52 #3
Originariamente inviato da: Unrealizer
Chrome come IE6, ancora e ancora


Originariamente inviato da: emiliano84
straquoto, ma quando la capiranno, sara' troppo tardi...

...sempre SE mai lo capiranno, perche' e' di google mica di MS, quindi e' figo, va' tutto bene


potete essere più chiari?
GTKM22 Aprile 2015, 13:00 #4
Originariamente inviato da: aksh37
I browser stanno diventando sistema operativi. Sembra la storia di emacs. Non so voi, ma io con il browser navigo e scarico roba e basta.


Emacs è la cosa più bella che potessi conoscere nel panorama GNU.

Comunque è vero, Chrome sta diventando un piccolo sistema operativo.
damxxx22 Aprile 2015, 14:33 #5
Originariamente inviato da: Unrealizer
Chrome come IE6, ancora e ancora

Vabbè dai almeno in questo caso, se non ho capito male Google sta utilizzando le Push API del W3C
Unrealizer22 Aprile 2015, 14:39 #6
Originariamente inviato da: Bazzu
potete essere più chiari?


la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Chromium e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)
Pier220422 Aprile 2015, 14:49 #7
Originariamente inviato da: Unrealizer
la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Cromismo e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)


Non ci ho capito una mazza ma una cosa ho capito, Google fa come,.azzo gli pare comprese le schifezze che crea fuori standard.
Ma non era le la paladina dello standard W3C?
Bazzu22 Aprile 2015, 15:08 #8
Originariamente inviato da: Unrealizer
la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Chromium e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)


grazie della spiegazione..
acerbo22 Aprile 2015, 15:17 #9
io non faccio che spegnerle sulle app e c'é gente che vuole averle pure sul desktop le notifiche? Anche sul mac le ho disabilitate tutte.
andrew0422 Aprile 2015, 15:36 #10
Originariamente inviato da: Unrealizer
la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Chromium e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)


Sbagli su diverse cose:

-MS con IE il problema non erano le "estensioni proprietarie" il codice HTML e CSS, quello "base," che veniva interpretato a modo suo, e questo rendeva impossibile realizzare facilmente siti compatibili con gli altri browser... quindi IE e Chrome hanno 2 problemi COMPLETAMENTE diversi
Se rispetti gli standard del W3C il sito si vede uguale in tutti i browser
Con IE se rispettavi gli standard del W3, lo vedevi bene negli altri browser, ma non vedevi una mazza

-Collegandomi a sopra: Le specifiche proprietarie le hanno TUTTI i browser, Da Chrome a Opera e da Mozilla Firefox a Microsoft IE... sono gli sviluppatori web che vanno presi a calci nel sedere che usano quelle supportate solo da 1 browser/engine... ma ripeto il problema non sono le estensioni proprietarie

-E qui distorci completamente la realtà dei fatti: I Touch Event erano standard W3 (sviluppati dalla W3, Opera, Mozilla e Nokia, quindi Google non centra niente con la loro creazione) ed esistevano PARECCHIO PRIMA(Prima bozza 2011 contro prima bozza 2012) dei Pointer Event sviluppati da Microsoft e Mozilla, e diventati standard solo a febbraio 2015, quindi 2 mesi fa

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^