Newsgroup: it.lavoro.informatica
Titolo: Notifiche push su app android o iOS

Salve, chiedo a voi perchè il mondo delle app mi è sconosciuto ma mi incuriosice 
e c'e' un cliente anche amico che vorrebbe un aiuto per capire meglio.
 
Il mio cliente fornisce un app ai propri clienti per gestire gli ordini e le 
conseguenti consegne. Un app che nella duplice versione per iOS e Android conta 
circa 5mila installazioni.
 
Fino ad oggi a fronte di ogni cambiamento o richiesta mandava una mail al 
cliente, adesso vorrebe mandargli una notifica push sull'app, ma gli sono state 
richieste cifre secondo lui eccessive per l'implementazione di questa feature, 
motivandole comunque con i costi del server per l'invio delle notifiche.
 
Domanda mia: ma le Google per Android o Aple er iOS fanno pagare il servizio di 
notifica push sulle app?
 
Ho provato a cercare su google ma ho solo potuto vedere che esistono decine di 
piattaforme per l'invio dei messaggi, ma io direttamente dalla mia app non 
potrei gestire in autonomia l'invio della notifica? Mi serve proprio passare da 
una piattaforma di terzi?
 
TIA as usual a chi vorrà o potrà spiegarmi a grandi linee come funziona questo 
aspetto delle app.
 
-- 
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 servizio di notifica push sulle app?
 
Nah. E` un'operazione banale. Se usi Firebase Cloud Messaging(FCM) metti 
su un sistema un'app del genere in tre minuti.

 servizio di notifica push sulle app?
 
Google e Apple ti mettono a disposizione le API
 
Poi il backend ce lo devi metter te


eppure pochi,a  quanto ho avuto mdodo di vedere, pensano a mettersi in piedi 
'sto backend autonomamente, voglio dire per un'app con poche migliaia di 
installazioni quanto peserà in termini tecnico-economici implementare e gestire 
il backend?


 Poi il backend ce lo devi metter te
 
None. Come dicevo, usando FCM, non devi mettere in piedi nessun backend.
 

 implementare e gestire il backend?
 
Come dicevo nella mia risposta. Usando FCM non hai bisogno di mettere in 
piedi nessun backend.
 

 Usando FCM non hai bisogno di mettere in piedi nessun backend.
 
Ok, ce lo mettono loro il backend.
 
Ho dato una scorsa veloce quindi non mi atteggio ad espertone, ma 
leggendo che le chiavi di accesso ai server sono registrate dentro l'app 
mi ha fatto rizzare i (pochi rimasti) capelli...

 leggendo che le chiavi di accesso ai server
 
Quali chiavi? Link?


Leggo adesso che queste API sono legacy
 
Adesso usano OAuth2 (short-lived) tokens
 
Ma...
 
https://firebase.google.com/docs/cloud-messaging/manage-tokens
 
 
"Store registration tokens on your server"
 
e in altre pagine fanno riferimento a "Your app server or other trusted 
server environment"
 
ora di grazia chi ce lo mette questo app server o trusted server 
environment? 
https://firebase.google.com/docs/cloud-messaging/server
 
 
Se ce lo mettono loro stessi (e.g. 
https://firebase.google.com/docs/functions
) come fai ad assicurarti che 
un untrusted device - un malintenzionato che ha decompilato la tua 
mobile app - non fa casini?

 mobile app - non fa casini?
 
Non capisco cosa c'entri la decompilazione. Si sta parlando di "trusted 
server environment", non di "trusted device". Cosa c'entra la 
decompilazione?
 
Magari, se mi fai un esempio, capisco che vuoi dire.
 

 Magari, se mi fai un esempio, capisco che vuoi dire.
 
Quello che voglio dire e' che normalmente io voglio tenere sotto 
controllo la business logic (come la mia applicazione funziona) ecco 
perche' ho tirato fuori il discorso del backend.
Da quello che leggo il backend - che di solito e' sviluppato da chi 
sviluppa il client mobile - e' fornito da Google stesso.
Quindi Google ti fornisce l'infrastruttura di comunicazione (FCM) e il 
backend (business logic). Per ovvie ragioni backend e canale di 
comunicazione sono considerati trusted environment.
Sto cercando di capire che livello di "insulation" fornisce il loro 
backend contro tentativi di accesso non autorizzati, considerando che il 
client mobile e' un untrusted device (o untrusted environment) perche' 
puo' essere manipolato da malintenzionati. Le vecchie API avevano una 
chiave d'accesso che non scadeva mai: scoprivi quelle e avevi accesso al 
backend.
Adesso sto cercando di capire come hanno migliorato la cosa.
Perche' mi sa che in futuro (spero remoto) ci dovro' mettere le mani.

 backend contro tentativi di accesso non autorizzati
 
No, il client mobile non e` ne` un "untrusted device", ne` un "untrusted 
environment". Il meccanismo di autenticazione/autorizzazione della tua 
applicazione non ha niente a che vedere con FCM. Non sono loro a 
prevenire accessi non autorizzati. Sei tu che devi farlo.

 perche' ho tirato fuori il discorso del backend. 
 
OK. Leggi la risposta di One, corretta. Aggiungo il nostro esempio.
 
In questo momento abbiamo un backend, piuttosto corposo, frutto della riscrittura di una vecchia infrastruttura di qualche anno addietro. Non è roba piccola, è un anno e mezzo che ci lavoriamo, facendo la migrazione a blocchi.
Ora, essendo che uno dei front-end possibili è mobile (ci sono 3 app al momento), a un certo punto è sorta la necessità di avere le notifiche push. Io ho studiato e fatto prove con FCM per una giornata e poi ho integrato il tutto all'interno della parte di backend. Quando è necessario l'invio della notifica, il nostro backend invoca FCM (trovi le API già pronte) fornendo i registration tokens e i dati che servono (principalmente il messaggio) e il gioco è fatto. 
 
Voglio dire: il nostro backend resta li, ben isolato e protetto. FCM si limita a fornirci l'infrastruttura che ti serve per inviare le notifiche.
 
Altro spunto interessante che ti ha dato: le serverless functions. Le stiamo approfondendo: in questo momento i server sono nostri, presso un data center, ma ed è molto probabile che nel giro di qualche anno arriveremo li. La cosa interessante della questione è che nessuno ti vieta di avere le tue funzioni presso un fornitore (Azure? AWS? Google? altro?) e comunque sfruttare i servizi forniti da altri, se trovi che ti siano più funzionali.
 
-- 
Ciao!
Luca
 
 

 Altro spunto interessante che ti ha dato: le serverless functions. Le stiamo approfondendo: in questo momento i server sono nostri, presso un data center, ma ed è molto probabile che nel giro di qualche anno arriveremo li. La cosa interessante della questione è che nessuno ti vieta di avere le tue funzioni presso un fornitore (Azure? AWS? Google? altro?) e comunque sfruttare i servizi forniti da altri, se trovi che ti siano più funzionali.
 
Le serverless functions le sto studiando gia da qualche mese, per un paio di 
progetti noi abbiamo saltato lo stato di "dockerizzazione" e probabilmente 
arriveremo direttamente alle serverless anche se i modelli di pricing per il 
momento non mi sembrano stimolanti.


 momento non mi sembrano stimolanti.
 
Certo, bisogna fare bene i conti, tenendo in considerazione il TCO della soluzione da cui arrivi.
 
-- 
Ciao!
Luca

 Ma è un servizio a pagamento (FCM intendo) l'utilizzo delle API?
 
Come gia` detto, e` gratuito. Leggi i docs sul loro sito.


Se via fcm ti chiedono ua montagna di soldi, vai di sms
L'app, nel caso possiate modificarla o farla modificare, potrebbe 
intercettare l'sms e se riconosciuto mostrare a operatore una notifica
L'effetto sul telefono sarebbe pari pari a quello ottenibile sparando 
via fcm
In effetti non sarebbero equivalenti i due sistemi
Via fcm puoi 'svegliare' un telefono che pisola, attivare display, ed altro
Ma se ti basta 'far vedere' all'utente la notifica arrivata con tutte le 
funzionalita' legate al messaggio dentro la notifica, allora sei a posto
Tutto in casa, non disturbi google, meno roba c'e' e mono se ne puo' 
rompere, funzionamento assicurato

 Se via fcm ti chiedono ua montagna di soldi, vai di sms
 
Spero che tu stia scherzando.
 

 OK. Leggi la risposta di One, corretta. Aggiungo il nostro esempio.
[...]
 
Grazie a entrambi.
 
Per una volta ogni morte de papa ITLI si rivela utile e ben informato 
sulle tecnologie.
 
Poi vabbe' arriva quell'altro, tale RobertoA, a sfasciare l'idillio con 
la cagata galattica degli sms...