Android - push notifications

Fórumok

(Előre jelzem, hogy egyáltalán nem ismerem az Android körüli ökoszisztémát)

Jelenleg egyes rendszer-üzeneteket SMS-ben küldünk ki a munkatársak telefonjaira. Felmerült, hogy alternatívaként használjunk push notification-t. TL-DR jellegű, gyakorlatias kérdéseim:

1.) Jól értelmezem, hogy egy boltból frissen megvásárolt, "szűz" Android-ot tartalmazó, SIM kártyával és mobilnettel ellátott készülék önmagában nem alkalmas erre, mindenképpen valami egyedi alkalmazást kell fejleszteni és telepíteni hozzá a telefonra?

2.) A push üzenet elküldésére is praktikusan szükséges egy alkalmazást fejleszteni?

3.) Hogyan működik a címzés? A júzernek a feltelepített appja generál valami azonosítót/tokent, és ez alapján kell kiküldenünk az üzenetet?

Bónusz: Mi van akkor, ha a júzer kicseréli az Android-os telefonját mondjuk iPhone-ra? Ezt hogyan célszerű nekünk - üzenetküldő oldalon - lekezelni? Naprakészen kövessük, hogy a júzernek milyen telefonja van, és attól függően küldjünk Android vagy Alma formátumú push üzenetet?

Kösz/üdv.

Hozzászólások

fixme, de a push üzenet egy applikációnak szól. Nem kell neked saját app-ot fejleszteni, elég, ha egy tetszőleges - push üzenetet is kezelő - applikációt telepítesz.
Pl elég egyszerű megoldás erre a "prowl" amire akár emailt tudsz küldeni, de lehet Slack, Telegram, bármi - ami akár platform független.

Köszönöm. A prowl-t és a pushover-t megnéztem, ezek funkcionálisan valóban jónak tűnnek, ugyanakkor (adatvédelmi, rendelkezésre állási és egyéb szempontok miatt) jó lenne mindezt 3rd party szolgáltató bevonása nélkül megoldani. Magyarul, jó lenne kizárólag a Google által nyújtott, jelen esetben megkerülhetetlen infrastruktúra használatára szorítkozni, és a telefonon az üzenetek fogadását, valamint a küldő oldalon az üzenetek küldését vagy valamilyen open source, vagy pedig saját fejlesztésű szoftverrel megoldani.

1. igen

2. ???

3. igen

de egyszerubb dolgokra ott a prowl vagy a pushover app, amivel emailbol vagy http api hivassal tudsz pusholni.

2. ???

Ezen mit nem értesz? Idáig az SMS alapú üzenetküldés nagyjából úgy működött, hogy

/usr/local/bin/sms-send "+36xxxxxxxxx" "Ez egy teszt üzenet"

Ehelyett nyilván kell majd valami üzenetküldő kliens, már persze ha a dolog komplexebb annál, mint amit mondjuk curl használatával egy HTTP POST-ból meg lehet oldani.

Nem én leszek a téma szakértője, de egy időben utánanéztem a témának.

Mintha tetszőleges weboldal meg tudná csinálni service workerrel, de nekem azért nem volt szimpi a dolog, mert a google-n keresztül működik csak. Legalábbis én így emlékszem.

Tán ezek segítenek:

https://developers.google.com/web/ilt/pwa/introduction-to-push-notifica…

https://developers.google.com/web/fundamentals/codelabs/push-notificati…

Kis raadas, a google az android 5-6 kornyeken vezette be, hogy a push notification-ok a google frameworkon keresztul menjenek, mert igy az osszes notification-t az az o appjuk szedi le, es nem kell kulon ebren tartani az osszes app-et, csak hogy notification-t tudjanak csekkelni kulon-kulon.

Az osszes push notification a google-n keresztul megy. Hat, illetve valszeg egy ebren levo app is tud kuldeni, de ha azt akarod, hogy alvo mobil is felebredjen es csipogjon, akkor google-n keresztul tudsz csak.

 A guglin keresztüli push notification előnye, hogy OOtB működik, viszont nem csak így lehet. Bármilyen alkalmazás figyelhet tcp porton és várhat adatot, ez nem korlátozza a telefont abban, hogy lepihenjen. A baseband cpu folyamatos kommunikációban van az alkalmazás cpu alvó állapota mellett is, és tcp csomag érkezésekor fel tudja ébredzteni azt.

Ami gond lehet, hogy a sok kretén béna programozó miatt az utóbbi évek androidjai nem szeretik ha valami a háttérben futkorászik, de némi beállítással ezt ki lehet küszöbölni. Írtam távmenedzsment service-t androidra, eleinte sokat szívtam vele, de végül kisimultak a dolgok, jól működik.

az a baj, hogy az android gyartok okos battery management-et csinalnak; lasd https://dontkillmyapp.com/

szoval lehet, hogy neked mukodik a custom notification, de hogy mindenkinek nem fog, az biztos.

es tovabbra is, hatekonyabb a kozos notification, mint kulon-kulon minden app poll-olni egy szervert, mind adatforgalomban, mint battery-ben.

"A guglin keresztüli push notification előnye" - hogy letiltható. És megkíméli magát az ember a telefon egész napos csipogásától. Ha időnként ránézek a kezdőképernyőre, elég látnom az ikonokon megjelenő kis piros "gombócokat". Ezt akkor teszem, amikor az időben jó nekem. (Nincs reklámszórás, hülye üzenetek.)

:) - Ja, hogy ez így kicsit antiszociális? De ez így jó nekem.

Szerintem nézd meg a Telegram-ot, ahol tudsz üzenetet küldeni a felhasználónak, elég jó a push-(j)a az app-nak, mindig megjelenik (Viber-rel nincs ez így nálam). Privát bot-ot csinálva tudsz beszélgetni is a küldővel: ne szóljon újra 30 percig, nyomja el ezt az üzenettípust 1 napig...

Ha felhasználó cseréli az eszközét, akkor arra is rak Telegram-ot. Nekem desktop-on is van, telón is van, amelyiket előbb olvasom, másikon eltűnik. Az okosház így szól, hogy égve maradt valami vagy szél lesz és egy ablak nyitva.

1) Nem alkalmas, amíg nincs egy google account a telefonra belépve. Onnantól viszont igen.

2) ha saját appot akarsz :) vagy használsz egy meglévőt. Pl amiket s többiek is írtak.

3) kb igen.

Ahogy korábban írtam, saját app esetén nem kell feltétlen a g framework, sőt, létezik g nélküli android is :) Simán lehet tcp csatornán figyelni, és várni a bejövő csomagokat, ez még a CPU sleepjét sem akadályozza. Ezzel csak annyi a baj, hogy az Android agresszív energia-menedzsmentje minden háttérbeli folyamatot alapból korlátozni igyekszik, nagyon erőszakosan, mert nagyon sok gond volt a rosszul megírt és összetákolt szarokkal. Ez a dolog a legtöbb eszközben korlátozható alkalmazás szinten, de ez manuális beállítást igényel, azaz lehet egyesével supportálni a telefon típusokat...

Szerkesztve: 2021. 09. 20., h – 23:22

dupla

1, Vannak alkalmazások, amelyek push notification kezelésére vannak, például Pushbots, nyilván előfizetéses, de vélhetően olcsóbb, mintha nekiállnál magad lefejleszteni.

2, Push üzenet küldésére egy API-t érdemes használni szerver oldalon. Firebase esetén ez egy access token és egy REST-en elküldött JSON.

3, A user kvázi feliratkozik, ha dobozos alkalmazást használsz. Ha magad fejleszted, akkor API hívással kapsz egy token-t, amit beküldesz a szervernek és attól kezdve a szerver tud üzenni ezzel a tokennel az adott telefonnak.

Bónusz: ha dobozos alkalmazást használsz, akkor semmi teendőd nincs, ha magad írod meg, akkor igen, követned kell. Sőt, akkor is más token lesz, ha Android-ról cserél Android-ra. Sőt, lehet olyan is, hogy kettő telefonja van, külön-külön lehet azokra küldeni üzenetet, tehát arra is fel kell készülnöd, hogy egy felhasználód több eszközt használ.

Szerkesztve: 2021. 09. 21., k – 10:52

Fel kell tenni a kérdést hogy nyerni amúgy nyertek valamit?

Mert kompexitást, és legalább két szolgáltatótól függést (google és az adott app) azt igen.

Mármint az SMS-hez képest? Úgy tűnik, hogy tényleg nem, csak ehhez fel kellett mérni, mi is ez a push egyáltalán. Én naivan valami olyanra egyszerű dologra gondoltam, hogy az Android out-of-box tud értesítést fogadni, tehát mondjuk megnézem a készülék "About" menüjében az egyedi azonosítóját, majd egy mezei HTTP POST-tal elküldöm az üzenetet az egyedi azonosítóval egy megadott URL-re és kész... legalábbis, az SMS küldés pont ennyire egyszerű...

Ha SMS-ben küldöd a "nemmegya Zinternet" üzentet, közvetlenül egy GSM/{345}G eszközön keresztül, akkor át fog menni - ha push/emil/slack/telegram/viber/qtyaf@ca az "útvonal", akkor meg... Szóval n+1 plusz hibaforrás behozva a rendszerbe.

Az, hogy küldő oldalról "ugyanolyan egyszerű" (illetve annak néz ki) a dolog, a megbízhatósága/rendelkezésre állása nagyon más. Ahhoz, hogy az SMS "átmenjen", elég, ha a megcélzott telefonszámhoz tartozó SIM-et tartalmazó, GSM készülék honos vagy roaming hálózatra fel legyen jelentkezve. Semmi 2.5/3/4/5G, meg mobilnet és hasonlók, egy teljesen alap GSM (2G) elérés esetén oda tud érni az SMS.
Egy push üzenetnél IP-kapcsolat kell a telefonon (mobilnet/wifi), kell a push-t továbbító szolgáltató, kell a monitoringtól a push-t továbbító szolgáltató felé IP kapcsolat... Satöbbi.
 

Ezzel csak az a baj, hogy mindenki megreked abban a gondolatban amit épp szolgáltat. 100-as embertömegig az SMS értesítés főleg ha a vevő közeg ismert és keveset változik egy működő megoldás, de felette már nem triviális. 

Ennek eredménye az is, hogy sokszor 1-2 emberben gondolkodnak, ahol a visszajelzés lényegtelen, márpedig a legtöbb alkalommal ez szinte a legfontosabb.

A jó megoldás a tiering itt is, amit az erre specializált cégek aprópénzért meg is tesznek (pushover-nek van sms failbackje, nem minden országra, de véletlenül Magyarországra igen :), másik példa a signl4 ami ennél is specializáltabb szolgáltatást ad)

Igen, mindhez kell internet, de nem hiszem, hogy aki ezt komolyan gondolja és értelmes IT team-el rendelkezik annak globális internet problémán kívül aggódni kellene bármiért. Igen, valóban van esélye annak is, hogy a szolgáltató megáll. Mint ahogy annak is hogy az SMS szolgáltatás nem megy. Erre jó a BCP megoldás ami a legtöbb esetben megvan, hisz pont itt is legacy SMS megoldásról kívánnak áttérni.

Nem kell idekeverni a vészhelyzeti jelzést amikor maga az eszköz jelent magáról, vagy zárt környezetből. 

"Igen, mindhez kell internet, de nem hiszem, hogy aki ezt komolyan gondolja és értelmes IT team-el rendelkezik annak globális internet problémán kívül aggódni kellene bármiért." - ha a küldő gép és a nagyvilág (internet) között van saját eszköz, akkor annak rendelkezésre állása máris belejátszik a monitoring értesítések célba juttatásának a megbízhatóságába. Ha egy GSM-modem van a gépre dugva, és azon megy ki SMS-ben az üzenet, akkor az első lépcsőben a szolgáltatónak a hálózata következik, és onnantól kezdve neki kell az elérést/továbbítást biztosítania.
nem véletlen egyébként, hogy a kritikus eseményekről a riasztások küldésére a best practice az, hogy legalább(!) két módon történjen meg (sms+e-mail a jellemző).

"pushover-nek van sms failbackje" - de ahhoz már el kell érned őket, illetve még mindig ott van, hogy a címzettnek adott időpontban van-e aktív, működő internet-kapcsolata a telefonján, vagy sem? Vagy a címzett felé is megvan a push /nem fogadja / sms-t küld megoldás?

Jelenleg van nekik GSM SM > ez mehet BCP megoldásra ha a szolgáltató API-ja nem válaszol, ez a megoldás a szolgáltató hibájára, BCP kell mindig (hacsak nem játék).

Szigetes infrát nem belülről ellenőrzünk hanem onnan ahonnan használják, vagy annak egyenértékű helyéről. Ez megoldás arra, mi van ha az adott szolgáltatás megszűnik a kliens irányából. Belső szolgáltatás esetén a szigeten belülről akkor arra a redundancia a megoldás. Ha lecseréled másik közegre, akkor abban a csapdában vagy, mi van ha az a közeg áll meg.  Szóval látszólag kezeled a problémát, valójában pedig nem. Egy SMS BCP megoldást fenntartani nem egy kirívó összeg, ahogy az alerting rendszerre egy GSM backup sem az. De az rohadt drága és költséges, hogy megbízhatatlannak nyilvánítunk egy megoldást és helyette egy bevált, de ugyanolyan megbízhatatlant használunk. 

A pushover SM failback az a címzettre vonatkozik nem az API elérésre.

 

ps. Egyébként, az ilyen szolgáltatóknak több API hozzáférése van általában külön rendszeren (SMTP, HTTP itt a példa kedvéért és az említett két szolgáltató bőven négy kilenc fölött van, összesítve is a hibákat) 

> ha a küldő gép és a nagyvilág (internet) között van saját eszköz, akkor annak rendelkezésre állása máris belejátszik

egyreszt azert egy redundans netkapcsolat (ha mas nem akkor mobilnet backup) elvarhato...

masreszt a netkapcsolat mukodokepesseget kivulrol (pl. felhobol) illik monitorozni, es nem a belso halorol kuldeni sms riasztast hogy "elmentanett"

A belső monitoringból ki kell juttatni infót akkor is, ha az internetes irány "gatya". Persze, lehet két eltérő szolgáltató, eltérő nyomvonalon futó internet-kapcsolat plusz 3/4/5G backup a kifelé menő riasztásoknak.
Persze, kintről (is) kell monitorozni a dolgokat, de attól, hogy kintről a monitorozott linket döglöttnek látja, még biztosítanod kell azt, hogy erről megbízhatóan tudjon riasztást küldeni akkor is(!) ha a cél telefon bármilyen okból csak 2G-n van felcsattanva a hálózatra.

A kintről figyelő monitoring azt látja, hogy semmi nem érhető el, és elkezd vinnyogni, másrészt meg egy ilyen "dupla" hibára ha lőni akarunk, akkor a monitoringot/riasztást saját szünetmentessel kell ellátni, és onnan folyamatosan lifesign jelleggel ki kell nyúlni a külső monitoring gépre, ami ha ez az "életjel" kimarad, akkor riaszt, hogy nem tudja, mi van a benti monitoringgal.

Mert a "minden álló" belső jóval többet tud monitorozni, mint a külső, ami csak azt nézi, hogy a külső szolgáltatások működnek-e a nagyvilág felől, és fogadja a belső monitoringtól a "még élek" jelzéseket, ami ha elmarad, akkor riaszt, hogy "a belső monitoring nem küldött életjelet x ideje".

Onnan indult, hogy a belső monitoringból ki kell juttatni a riasztást. Ha a nagyvilág felől nem érhetőek el a szolgáltatások, akkor arra ketyeg egy adott SLA, a belső működésre meg lehet, hogy egy szigorúbb, ergo attól, hogy a nagyvilág felé/felől nincs kapcsolat, még a belső eseményeket ugyanúgy kell monitorozni, és a megfelelő embereket riasztani, ha szükséges.

Azaz a belső monitoringból akkor is ki kell juttatni a riasztást, ha a nagyvilág felől nem látszik,mi a töcs van. Mert ha a kifelé adott szolgáltatásra van mondjuk 2 órás reakcióidejű sla adva, a belső xyz rendszerre meg van 30 perces reakcióidejű sla adva, akkor a "nem tudom, mi van bent" nem egy elfogadható állapot, akkor a benti riasztásnak a külső IP-hálózati kapcsolattól függetlenül ki kell jönni valahogy. Erre három útvonal lehetséges: telefonhívás (automata pléhmaca bemondja, hogy wtf), sms (ha a célzott telefon 2G-n fel tud jelentkezni a hálózatra, akkor megérkezik, és gyakorlatilag csak a mobilszolgáltató van közben, vagy lehet push, amihez a túlvégen _is_ IP-kapcsolat kell. A három közül az sms-küldés a legegyszerűbb.

Mik azok a hátrányok, amik miatt az élő mobilnetes kapcsolatot igénylő push jobb?

Esetleg vess pillantást a push notification feature listájára, például a prioritásokra (azonnali reakciót igényel vagy csak FYI üzenet), a TTL beállításokra (hasznos-e mire elolvassa egy órával később), az üzenet visszavonására (már nem igényel teendőt a probléma) vagy akár azzal, hogy ha valaki elolvassa egy csoportban, akkor a többiektől visszavonható és van még több apróság... Aztán vesd össze ezt azzal, hogy mit tud az SMS.

Az ár, illetve a "nem garantált szolgáltatás"-on túl... (Ha garantált elérés kell, akkor gsm-adapteren keresztül pléhmaca/hasbeszélő hívja fel az illetékest.)

Nagyon be van neked kattanva ez a GSM adapter. GSM backup internet nincs?

A push-hoz mindkét végén IP-kapcsolat kell - az SMS-hez elég 2G-n feljelentkezett eszköz. A GSM (2G) lefedettségből "kisétálni" jóval nehezebb, mint a mobilnettel stabilan ellátott területről. Ha a készülék fel tud jelentkezni a hálózatra (szervíz/jelzéscsatorna él), akkor az SMS is e tud hozzá jutni, satöbbi. Az SMS faék egyszerű a push-hoz képest, és amiket felhoztál, azok szép meg jó dolgok, csak ha nagyon baj van, akkor irreleváns, hogy ezeket tudja - a megkapott szövegből a címzett minimális agymunkával ki tudja találni, hogy mennyire gyorsan kell rámozdulni, illetve hogy x idővel korábbi eseménynél kell-e reagálnia vagy sem. Ha többen kapják a riasztást, akkor sem biztos, hogy az üzenetet elsőként elolvasó emberke ugrik rá (azaz a csoportból automatice "visszaszívni" nem jó ötlet) - egyeztessenek az érintettek, hogy ki az, aki rámozdul a problémára (ezt meg lehet beszélni előre, hogy ki az, aki elsődlegesen "ugrik", és ha neki nem megy/más dolga van, akkor az ő felelőssége, hogy a következő kolléga bevonásra kerüljön a tényleges hibaelhárításba)

A GSM (2G) lefedettségből "kisétálni" jóval nehezebb, mint a mobilnettel stabilan ellátott területről. Ha a készülék fel tud jelentkezni a hálózatra (szervíz/jelzéscsatorna él), akkor az SMS is e tud hozzá jutni, satöbbi.

Mondd már meg kérlek, mi a lófaszt csinálsz a 2G lefedettségű semmi kellős közepén ha kapsz egy SMS-t, hogy baj van? Tüzet raksz? Miért kellene megcélozni egy riasztással olyan embert, aki amúgy helyzetileg képtelen arra, hogy érdemlegesen beavatkozzon, de még arra is képtelen, hogy megfelelő információkat gyűjtsön be?

Értesül az eseményről, és fel tudja hívni azt, aki érdemben tudja orvosolni a problémát, ha szükséges.

Mért nem az kapja a riasztást közvetlenül, aki érdemben tudja orvosolni a problémát?

Vagy "csak" tud róla, mint a riasztott team egyik tagja.

Miért kell neki feltétlen tudnia róla, ha semmi lehetősége nincs beavatkozni, mert az SMS éppen csak átmegy a semmi közepén?

Azért, hogy legyen mibe belekötnöd. Egyébként nem tudom, hány évig dolgoztál olyan helyen, ahol 7x24-es rendszereket üzemeltetett egy team, mert én kifejezetten sokáig, és érdekes módon gyakorlatilag mindenütt az volt a módi, hogy a "nagyon ég a ház" riasztásokat minden rendszermérnök _és_ az üzemeltető csapat vezetője _is_ megkapta. Ugyanis a riasztás nem csak azért kell, hogy el tudd kezdeni a hibaelhárítást, hanem azért is, hogy a többi területet/felsőbb vezetőket/partnereket/felügyeleti szerve(ke)t legyen, aki tájékoztassa a problémáról. És ez nem az üzemeltető mérnök, hanem az üzemeltetésért felelős vezető.

Azért, hogy legyen mibe belekötnöd.

Te próbálod ismét igen nagy ellenszélben bebizonyítani, hogy az SMS az ultimate solution a problémára, a világ meg - huss - elment az SMS mellett, több éve már. Egyetlen előnye az, hogy akkor is megkapja a címzett - valamikor, ha semmit nem tud kezdeni a helyzettel (de akkor meg minek annyira fontos?), minden más esetben megérkezik a push notification is. Ráadásul normális ügyeleti és készenléti rend esetén meg fel se merül, hogy az ügyeletes vagy készenlétes olyan helyen van, ahol nincs olyan internet lefedettség, ami elegendő a probléma távoli elhárításához.

Egyébként nem tudom, hány évig dolgoztál olyan helyen, ahol 7x24-es rendszereket üzemeltetett egy team, mert én kifejezetten sokáig,

Dolgoztam hát, és?

és érdekes módon gyakorlatilag mindenütt az volt a módi, hogy a "nagyon ég a ház" riasztásokat minden rendszermérnök _és_ az üzemeltető csapat vezetője _is_ megkapta.

És miért jó az, hogy olyan valaki is megkapja, aki még csak telefonálni se tud senkinek, mert épp a világ vége után van kettő házzal? Ha visszatér a civilizációba, akkor megkapja a push üzenetet, ha annak nem járt le az élettartama. 

Ugyanis a riasztás nem csak azért kell, hogy el tudd kezdeni a hibaelhárítást, hanem azért is, hogy a többi területet/felsőbb vezetőket/partnereket/felügyeleti szerve(ke)t legyen, aki tájékoztassa a problémáról. És ez nem az üzemeltető mérnök, hanem az üzemeltetésért felelős vezető.

Aham, és mondd, erre alkalmatlan a push notification vagy horrible dictu egy email? Feltételezem, hogy a felügyeleti szervek nem SMS-t fognak kapni a problémáról...

"Te próbálod ismét igen nagy ellenszélben bebizonyítani, hogy az SMS az ultimate solution a problémára" - Ezt te látod bele - én csak azt mondom, hogy a push működőképességének, célba jutásának több feltétele van, mint az SMS-nek.

"És miért jó az, hogy olyan valaki is megkapja, aki még csak telefonálni se tud senkinek, mert épp a világ vége után van kettő házzal?" - Miért ne tudna? Ha 2G-re felcuppan a telefonja, akkor tud telefonálni. Igaz, ehhez be köll állítani a készüléket őgy, hogy ne 4G-only módon működjön...

"Aham, és mondd, erre alkalmatlan a push notification vagy horrible dictu egy email? Feltételezem, hogy a felügyeleti szervek nem SMS-t fognak kapni a problémáról..." Egy magasabb szintű vezetőt nem minden esetben kell értesíteni, erre való az üzemeltetési csapat főnöke, hogy eldöntse, adott esetben kit és hogyan kell/lehet értesíteni, illetve hogy hogyan kell/lehet tálalni a történteket. Utána lehet levelet küldeni, hogy írásban is meg legyen a dolog, de a jó vezető nem arra kíváncsi, hogy "baj van", hanem arra, hogy az adott probléma tételesen milyen következményekkel jár, és várhatóan mikorra lesz elhárítva, milyen erőforrásokat igényel, stb. (Hibajelzés =/= tájékoztatás)

Ezt te látod bele - én csak azt mondom, hogy a push működőképességének, célba jutásának több feltétele van, mint az SMS-nek.

Aham, szóval akkor ajánlod te is a push üzenet használatát? Vagy maradsz az SMS-nél? Mert eddig ami hozzászólást írtál, az mind arról szólt, hogy legyen SMS, mert az jó.

Miért ne tudna? Ha 2G-re felcuppan a telefonja, akkor tud telefonálni. Igaz, ehhez be köll állítani a készüléket őgy, hogy ne 4G-only módon működjön...

Na, ha van 2G és tud telefonálni, akkor van internet is, tehát bejön a push notification is. Problem solved.

Egy magasabb szintű vezetőt nem minden esetben kell értesíteni, erre való az üzemeltetési csapat főnöke, hogy eldöntse, adott esetben kit és hogyan kell/lehet értesíteni, illetve hogy hogyan kell/lehet tálalni a történteket. Utána lehet levelet küldeni, hogy írásban is meg legyen a dolog, de a jó vezető nem arra kíváncsi, hogy "baj van", hanem arra, hogy az adott probléma tételesen milyen következményekkel jár, és várhatóan mikorra lesz elhárítva, milyen erőforrásokat igényel, stb. (Hibajelzés =/= tájékoztatás)

Oszt ennek így összességében mi köze az SMS vs push notification meccshez? Ezt így lehetetlen megcsinálni push notification használatával? Csak SMS csatorna esetén lehetséges?

"Aham, szóval akkor ajánlod te is a push üzenet használatát? Vagy maradsz az SMS-nél? Mert eddig ami hozzászólást írtál, az mind arról szólt, hogy legyen SMS, mert az jó" Azt írtam, te nagyonkötekedős barom, hogy a push működésének, az üzenet célba juttatásának több feltétele van, mint az SMS-nek. És ha lehet,a kkor azt választom, ami kevesebb extra feltételt igényel.

"Na, ha van 2G és tud telefonálni, akkor van internet is" - Nem. Attól, hogy van GSM, még  GPRS/EDGE nem biztos, hogy van - viszont telefonálni már lehet.

"Oszt ennek így összességében mi köze az SMS vs push notification meccshez? Ezt így lehetetlen megcsinálni push notification használatával? Csak SMS csatorna esetén lehetséges?" - Azt írtad, hogy kvázi mehet nekik a push vagy az e-mail. Nem, nem mehet, hanem célszerűen az adott helyzet/időpont alapján dől el, hogy kit, hogyan kell/lehet tájéékoztatni. Nem értesíteni, hogy baj van, hanem tájékoztatni arról, hogy baj van, és az mit okoz, milyen lépéseket tesz az illetékes terület az elhárítására, satöbbi. És ha az üzemeltetési vezető épp olyan helyen van, ahol a push nem éri utol, attól még kell tudnia arról, hogy gáz van. Lehet persze azt mondani, hogy az ügyeletes mérnök hívja fel a főnökét, miután tájékozódott arról mekkora a zacc, de neki (mármint az ügyeletes mérnöknek) is értesülnie kell az eseményről valahogy - akkor is, ha épp nincs mobilnetje a telefonján... (Tudok mondani olyan helyet az országban, ahol van drótos net,d e a mobilnet épületen kívül is esetleges...)

 

Szerkesztve: 2021. 09. 21., k – 17:44

Nem egyszerűbb e-mail-t küldeni? Nem kell klienst fejleszteni, és tökmindegy, hogy a dolgozónak épp milyen kütyüje van.

A push üzenetnek akkor van értelme, ha amúgy is készítesz valamilyen applikációt, és hogy ne kelljen a dolgozónak az appot egész nap nyitva tartania, pusholod azokat az eseményeket, amikor rá kell néznie.

nálunk minden értesítés slackre és telegramra megy. egyszer kellett fél órát rászánni emlékeim szerint a beüzemeléshez. azóta mindenkinek az az üzenet megy, amit kér és meg kell kapnia. a kettő egyszerre ritkán hal le, és kb hűtőszekrényre is van alkalmazás.

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Sok válasz született, nem ismerjük a valódi felhasználást mögötte, ezeket sokat számítanak, ezért is jöttek fel később.

1, 5 évvel ezelőttig a push nem volt egységes, de aztán a Google csinált rá egy rendszer szolgáltatást, ezen keresztül érkezik az üzenet, de valamiben meg kell jeleníteni, szóval valamilyen alkalmazásra szükség van. 

2, Direkt is meg lehet oldani a kapcsolódást a Google-el, vagy használhatsz külön app-t erre mint átviteli közeget.

3, Megoldásfüggő, igen. Sokkal inkább csoportok alakíthatóak ki amik a regisztrált eszközre küldik ki az üzenetet.

 

Mivel közben el kezdted ismertetni a plusz dolgokat, erre vannak fejlesztett appok amik

1, push notification integration -> 3rd party API -> 3rd party app (pushover, signl4, etc) 

Ezekből nem tudok olyat ami end-2-end encryptiont tudna. Cserében nagyon jól össze vannak állítva arra amire ki vannak találva, (IT shift management, escalation, notification acknowledgement) pont olyan dolgok amik ezt értelmessé tehetik az egészet, hisz sokszor nagyon jó tudni mi történt azzal az értesítéssel.

2, Megírhatod az egész fenti folyamatot, nem hinném, hogy ez egy támogatott projekt tud lenni egy cégen belül, elég költséges megoldás

3, WebPush, 

Preparált webpage -> Chrome/firefox -> user beleegyezése üzenetek küldésére, vannak korlátai, és előnyei. Működik. A fenti részletességet amit az (1)-es pontban van ne várd..

4, Üzenetküldő alkalmazás 

a, Telegram: end-2-end encryption, a szolgáltató infrastruktúráját használod de az üzenet titkos lesz (kliens a te kezedben, ha akarod)

b, Signal, end-2-end encryption, saját szervert is építhetsz

Sokan manapság a Telegramot használják erre a megbízhatóság és az adatvédelmi megfontolások miatt. Emellett ehhez minimális befektetés kell, hogy működő szolgáltatás legyen belőle. 

 

Minden megoldásnak megvan az előnye, hátránya. El kell dönteni mi áll a (jövőbeni) igényekhez legközelebb. 

Subs

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"

"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Mi gotify-t használunk. G-mentes Androidokon (is) működik, free, open-source app, self-hosted szerver.
A Zabbix szerveren fut a gotify szerver, a Zabbixhoz van plugin is. (Gondolom más monitoring megoldáshoz is létezik)
Parancssorból egy üzenetküldés ennyi:

curl -X POST "https://gotify.szerverem.tld:8080/message?token=$token" -F "title=$HOSTNAME: $Message" -F "message=$Error" -F "priority=10"