Notifikationen

  • 30 Antworten
  • Letztes Antwortdatum
F

Flocke123

Ambitioniertes Mitglied
4
Hallo Community,

ich würde gerne meine App über Änderungen in einer SQL Datenbank aufmerksam machen. Das "System" läuft ausschließlich in einem geschlossenen privaten Netzwerk.

Ich versuche aktuell über Google Informationen zu sammeln, wie die Notifikationen generell funktionieren. Nur leider werde ich nicht fündig oder ich bin einfach nur blind.

Ich benötige eine Art Service, der auch dann läuft, wenn die App gar nicht gestartet ist, richtig?

Kann mir jemand konkrete Infos geben, mit welchen Klassen ich wie zu arbeiten habe, damit ich das bewerkstelligen kann?

Vielen Dank im Vorraus.

Gruß Flo

Der ursprüngliche Beitrag von 15:05 Uhr wurde um 15:17 Uhr ergänzt:

Habe gerade etwas mit GCM gefunden. Ich lese mich erstmal darin ein, was es damit aufsich hat.
 
Also du hast eine "entfernte Datenbank" und wenn sich dort etwas ändert möchtest du benachrichtigt werden?
Hab ich das Richtig verstanden...

dann ist auch hier das Stichwort GCM (Google Cloud messaging)

lg. Dagobert
 
DagobertDokate schrieb:
Also du hast eine "entfernte Datenbank" und wenn sich dort etwas ändert möchtest du benachrichtigt werden?
Hab ich das Richtig verstanden...

Ja genau. Ich habe eine SQL Tabelle 'notifications'. Diese Einträge werden automatisch generiert durch Datenaustausch mit einer SPS (Ist aber jetzt unwichtig). Die Tabelle enthält eine Boolean Spalte 'isNew'. Auf dem Server läuft eine Application (Windows Service mit C# geproggt), der dann das Android Phone darüber benachrichtigen soll, damit ein neuer Eintrag vorhanden ist. Der Android User kann nun den Eintrag quittieren, indem er die Spalte 'isNew' zurücksetzt.

dann ist auch hier das Stichwort GCM (Google Cloud messaging) [/QUOTE schrieb:
Darauf möchte ich eigentlich verzichten, da das System in einem privaten und gesicherten WLAN fungiert. Ich habe etwas gelesen mit dem AlarmManager und Broadcast Receivern. Werde mich da einlesen.

Vielleicht hilft dir das weiter: Hintergrundprozesse in Android (Teil 1): Started Services – What the droid?

Vielen Dank, das schau ich mir auch gleich an!

Und ein Dankeschön an alle, die bisher geantwortet haben! :thumbup:
 
Ja dann bleibt dir nur die Möglichkeit das ganze periodisch zu machen...
oder vllt noch mit nem SyncAdapter... ich weis ja nicht wie echtzeit relevant das ganze ist...

lg.
 
Normalerweise sind DB-Zugriffe ja für Verbindungen mit Hochverfügbarkeit ausgelegt, heißt LAN, WAN, Internet. Verbindungen von einem Smartphone / Tablet sind meist nicht so schnell und können früher oder später zu Problemen führen.

In meinem damaligen Abschlussprojekt wurde dies spührbar, wenn Querys zum Ausführen mehrere Sekunden benötigt haben, manche sich sogar festfuhren. Die Verbindung erfolgte via WLAN.

Ich rate von Echtzeit-Abfragen ab, zumal diese sowieso nicht möglich sind. Ein Intervall von 30 Sekunden sollte schon angemessen sein, weil es erzeugt ja auch eine gewisse Last auf der DB und wie gesagt, die Abfragen brauchen ihre Zeit.
 
Die Tabelle, die zyklisch ausgelesen werden soll, hat möglicherweise 10 - 20 Einträge (um den Daumen geprellt). Echtzeit ist nicht notwendig. Ich denke da an einen Intervall von 5 bis 10 sek.

Mal ins praktische:
Ich progge also einen Service, der mir periodisch einen Query ausführt, der den Eintrag/ die Einträge aus der DB holt, wo 'isNew' = TRUE, richtig?
Der AlarmManager scheint mir aber nicht das richtige zu sein. Da er bei Neustart des Gerätes nicht mehr läuft.

This class provides access to the system alarm services. These allow you to schedule your application to be run at some point in the future. When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running. Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted.

Ich benötige also einen anderen Service, der auch läuft, wenn die App nicht gestartet ist, bzw, der sich anschaltet, wenn das Gerät neu gestartet wird.
 
Ich hoffe dein Handy ist immer am Netzteil :p
Denn das ganze wird mega am akku saugen =/

lg. Dagobert
 
DagobertDokate schrieb:
Ich hoffe dein Handy ist immer am Netzteil :p
Denn das ganze wird mega am akku saugen =/

Kann doch nicht schlimmer als WhatsApp und Konsorten sein?

Aber dennoch verstehe ich deinen Einwand. Möglicherweise wäre es sinnvoll, den Dienst nur laufen zu lassen, wenn die App auch tatsächlich gestartet wird. Macht auch keine großen Probleme, da die App sowieso nur innerhalb des Gebäudes, bzw des WLANs funktioniert.
 
Doch das macht nen großen unterschied.. da wa und Konsorten mit GCM laufen...

lg.
 
Ich vertraue dem Cloude Messaging nicht. Alleine der Name 'Cloude' lässt mich, lebend in der Generation Abhörskandale und Datenklau, stuzig werden. Diese App läuft später auf Smartphones von Mitarbeitern weltweiter Konzerne.

Nennt mich paranoid, aber die Gefahr besteht und ist schon lange kein SciFi mehr
 
Naja du solltest dein Konzept nochmal überdenken ;)
Vorallen wenn es jetzt aufeinmal "weltweit" und auf mehreren Geräten Geräten laufen soll... bis gerade bin ich davon ausgegangen das du "home-bastler" bist ;)

lg. Dagobert
 
Bin auch Bastler, dementsprechend mein Wissensstand. ;)
Die Geräte sind ja nicht verbunden. Jeder kocht sein eigenes Süppchen ;)
 
Jeder kocht sein eigenes Smartphone in dem der Akku glüht :D
 
ich merk schon :thumbsup:
ich tests einfach mal aus :rolleyes2:
 
Was haltet ihr von einer Client Server Socket Verbindung?
Das Smartphone läuft in diesem Fall als Server und der lokale PC als Client.

Pseudo Code*

Code:
class ServerThread

Socket socket = null;
serverSocket = new ServerSocket(PORT);

socket = serverSocket.accept();

// Hol mir paar Daten
// und erstelle Notifikation
 
Klingt schlecht :D

Im ernst, ka wie und ob der offene Socket alleine schon am Akku saugt.
Dann müssten die Smartphones auf jedenfall im gleichen Netzwerk sein UND in irgendeiner Form beim Server bekannt sein.

Spätestens wenn du das über Mobilfunk machen willst wird das scheitern, da die meisten mobilfunkbetreiber keine eigenen IPs an die Telefone verteilen, somit kannst du dich dann nicht richtung Handy verbinden.

Ich versteh deine Abneigung gegen die GCM nicht.
Deine Socketverbindung musst du auch noch am besten selbst verschlüsseln, wenn es da um sensible Daten geht.

Und beim GCM sendest du normalerweise halt keinerlei sensible Daten, darüber schickst du nur kurze Meldungen wie "Neue Daten vorhanden", mehr nicht.
Die Daten holt das Telefon dann ganz normal bei dem eigenen bekannten Server ab.
Also eine gesunde Skepsis in Sachen Cloud und Datenschutz ist ja ok.
Aber hier sehe ich da 0,null Probleme.

Man muss das Rad nicht andauernd neu erfinden.
 
Danke amfa

Im ernst, ka wie und ob der offene Socket alleine schon am Akku saugt.

Ihr und eure s... Akkus :D
Ich muss das mal austesten, inwieweit der Akku tatsächlich beansprucht wird.

Dann müssten die Smartphones auf jedenfall im gleichen Netzwerk sein UND in irgendeiner Form beim Server bekannt sein.

Die Smartphones MÜSSEN im gleichen Netzwerk liegen.
Dieses private Netzwerk ist Passwort geschützt und man braucht eine feste IP Adresse. Da es auch nur für eine Hand von User erlaubt ist, sich mit dem Netzwerk zu verbinden.

Spätestens wenn du das über Mobilfunk machen willst wird das scheitern, da die meisten mobilfunkbetreiber keine eigenen IPs an die Telefone verteilen, somit kannst du dich dann nicht richtung Handy verbinden.

Wie gesagt, die App soll und darf nur innerhalb des Netzwerks funktionieren.
Sie soll auch nicht öffentlich gemacht werden. Die Leute, die diese App nutzen werden/drüfen, bekomme die Installation von uns.

Vielleicht gehe ich mal weng genauer auf die Funktion ein.
Der Mitarbeiter bekommt eine Benachrichtigung, er solle doch mal bitte eine Probe aus Behälter X nehmen. Er läuft zum Behälter, nimmt die Probe und bestätigt die Aufforderung mit den Messergebnissen der Probe. Anderswo, aber nicht auserhalb des Netzwerkes ;), liest ein Labormitarbeiter: "Aha! Hanz hat die Probe genommen - Kaffeepause vorüber"
 
Und was spricht gegen CGM? Dann muss die App gar nicht laufen und benötigt weder RAM, Daten und Akku.

Und ob die Cloud nun weiß das Hanz und Otto gerade irgendeine Nachricht bekommen haben ist ja nicht sicherheitskritisch.

Aber du kannst natürlich auch sporadisch zufällig verteilt dummy Nachrichten versenden um das NSA zu ärgern ;-)

cu
 
Zurück
Oben Unten