Hallo Leute, ich habe ein -zumindest für mich- interessantes Projekt, bei dem es darum geht, verteilte Sensoren und Aktoren per App anzusprechen. Ich bin erfahrener Hardwareentwickler, so richtig beruflich und so aber mit Apps betrete ich völliges Neuland und Programmieren gebe ich meistens an Leute ab, die das besser können. Ich möchte aber so viel kapieren, das ich zumindest einen Überblick habe und mitreden kann. Darum sind die Fragen auch ziemlich grundsätzlicher Natur. Ich will mal kurz das Gesamtsystem beschreiben und dann meine Fragen loswerden. Es wäre Klasse, falls jemand einen sinnvollen Beitrag leisten könnte. Das ganze sieht so aus: Gebraucht wird ein System, bei dem etwa 500 Sensoren (DMS)über verschiedene Signalwege (IMS-Funk und Kabel) Daten in eine MariaDB bzw. MySql ablegen (macht eine kleine Software auf meinem Rechner). Umgekehrt gibt es einige wenige Aktoren (etwa 15) die angesteuert werden sollen. Zur Verbindung SQL- MC ist ja hier schon eine Menge beschrieben worden, das noch mal genauer zu beschreiben spare ich jetzt mal deshalb. Aber: wie sieht so eine SQL-DB Handyapp-Verbindung aus? Das ganze soll Plattformübergreifend, also Android, IOS und Blackberry funktionieren und über GSM Edge genausogut funktionieren wie über WLAN. Die App soll, wenn der Rest steht extern programmiert werden. Nur: ich hab gar keine Ahnung, welche Schnittstelle ich am besten auf dem Datenbankserver bereitstellen soll. Gibt es da APIs in den SDKs für (denke ich mal)?. Welches Frontend benutzt so eine App? Wie wird das ganze sicher gemacht? Https? Muss ja möglichst auch hinter Firewalls funktionieren. Hat jemand hier schon mal etwas ähnliches realisiert? was ich persönlich spitze fände, wäre das Ganze auf sowas wie einen Synology-Server umzuziehen (die MariaDB läuft jetzt als Prototyp auf meinem Laptop). Kann mich jemand aufschlauen?
:
Verschoben durch User
Plattformübergreifend wäre eine Website nicht schlecht(z.B. PHP). Dann brauchst du gar keine APP. Ansonsten brauchst du für jedes OS ja ne eigene APP.
Sebastian B. schrieb: > Aber: wie sieht so eine SQL-DB Handyapp-Verbindung aus? Das ganze soll > Plattformübergreifend, also Android, IOS und Blackberry funktionieren > und über GSM Edge genausogut funktionieren wie über WLAN. Das Konzept klingt mir ein wenig nach Fat-Client. Also eine App, die direkt SQL-Befehle an die Datenbank absetzt. Das Konzept mag bei einigen wenigen Usern in einem LAN funktionieren. Findet man daher öfters auch z.B. bei Warenwirtschaften für KMUs etc. Für Mobilgeräte ist es aus mehreren Gründen nicht gut geeignet: - hohe Latenz zwischen App auf dem Smartphone und Datenbankserver - Leichte Unterschiede zwischen den Plattformen und dort leicht unterschiedliche Updatezyklen machen Änderungen in der Datenbank sehr schwer, es fehlt eine Zwischenebene die diese Unterschiede ausgleichen kann - Datenbanken sind von der Sicherheit her typischerweise nicht dafür geeignet direkt aus dem Internet angesprochen zu werden Daher verwendet man für Dein Szenario typischerweise einen Applikationsserver, der eine Schnittstelle wie z.B. XML-RPC zu den Apps hin anbietet und selber der einzige ist, der mit der Datenbank spricht. Statt XML-RPC/SOAP kannst Du natürlich auch REST oder JSON-RPC verwenden. Überlege Dir auch, ob Du wirklich Apps auf den Geräten brauchst. Denn für 3 Plattformen (Du hast übrigens Windows Phone vergessen, wirklich plattformübergreifend wären also 4) jeweils eine App zu entwickeln und zu pflegen ist ganz schön Aufwand. Mittlerweile kann man sehr viel über HTML 5 lösen wofür man früher eine eigene App brauchte. Dann musst Du das nur einmal entwickeln und auf dem Server anbieten.
Also, erstmal danke für die schnellen Antworten! Das mit der Internetseite ist ein guter Vorschlag und es ist auch klar, dass das billiger wäre, als vier apps zu machen. Das Ziel ist aber, das auf dem Endgerät zusammengesetzte Daten angezeigt werden müssen, zum Teil auch Abbildungen - und das ganze soll auch bei schlechtem Empfang und sogar Offline noch möglich sein. Tatsächlich findet die Anwendung in ziemlich abgelegenen Gebieten im Ausland Anwendung. Im Endgerät sollen dauerhaft also die statischen Daten gespeichert sein und durch aktuelle Zustände ergänzt werden, bzw. Befehle eingegeben und versendet werden können, sagen wir mal z.B. Licht an - Licht aus. Dazu kommt, dass das ganze sicher funktionieren muss bzw. nicht ausgeführte Befehle angezeigt werden müssen (Also: Licht aus nicht durchgeführt). So richtig Fernwirktechnik eben. Irgendwie müsste die App so eine Art Sync zwischen lokaler und Server Datenbank hinbekommen und Änderungen verschiedener Daten als Alarm, Hinweis anzeigen können. Wichtiger als die Kosten sind die Datenintegrität, Datenvertraulichkeit und Zuverlässigkeit, deshalb suche ich ja auch eine Externe Firma, die das Programmieren übernimmt. Vielleicht findet sich ja sogar hier jemand, der sowas übernehmen will...
Geht alles auch mit einer Website. Dynamische Dinge lassen sich sehr gut mit HTML5/JavaScript abbilden.
Sebastian B. schrieb: > Das Ziel ist aber, das auf dem Endgerät zusammengesetzte Daten angezeigt > werden müssen, zum Teil auch Abbildungen - und das ganze soll auch bei > schlechtem Empfang und sogar Offline noch möglich sein. Unterschätze die Möglichkeiten von HTML5 und Javascript nicht. Daten zusammenzusetzen, Abbildungen/Charts zu errechnen etc. ist damit überhaupt kein Problem. > Irgendwie müsste > die App so eine Art Sync zwischen lokaler und Server Datenbank > hinbekommen und Änderungen verschiedener Daten als Alarm, Hinweis > anzeigen können. Sowas kannst Du auch mit Javascript machen. Wenn Du das nicht im Browser abschaltest oder beschränkst, dürfen "Webseiten" Daten lokal ablegen und wieder laden. Die "Webseite" selbst kannst Du dabei auch lokal auf dem Smartphone ablegen. Ich hatte mal ne Einkaufsliste gesehen die genau so programmiert war. Mir fällt nur der Name / Link dazu gerade nicht mehr ein. > Wichtiger als die Kosten Unterschätze die Kosten der App-Entwicklung nicht! Du musst das Ding 3 oder 4 mal fast komplett neu entwickeln lassen, denn die Plattformen verlangen verschiedene Programmiersprachen und teilweise auch -Konzepte. Und die verschiedenen Plattformen müssen dennoch hinterher identisch funktionieren.
Hmm ok, werde mir dass wohl nochmal genauer anschauen müssen. Meine Webkenntnisse kommen noch aus der Zeit, wo 1und1 noch Puretec hieß.... Was zum Beispiel Alarme angeht, denke ich aber, dass da sie Seite ja die ganze Zeit auf dem Endgerät geöffnet sein müsste, oder nicht? Ich hab für die erste Appversion pro Plattform ca. 7,500€ budget, denke das müsste machbar sein und ein teil des Quelltextes lässt sich ja immer portieren. Werde jetzt erstmal meine Hausaufgaben machen und eure ganzen Stichpunkte abarbeiten. Auf jeden Fall freue ich mich, das ihr mir so ausführlich geantwortet habt, danke! Ich melde mich mal, wenns Fortschritte in meinem Kopf gibt ;-)
Sebastian B. schrieb: > Was zum Beispiel Alarme angeht, denke ich aber, dass da sie Seite ja die > ganze Zeit auf dem Endgerät geöffnet sein müsste, oder nicht? ja, Alarme werden mit ner Webseite schwer. Vor allem wenn das Gerät in den Standby geht. Und es muss in den Standby gehen können, weil sonst ist der Akku in wenigen Stunden platt. Auch um den Lockscreen kommst Du mit ner Webseite nicht rum, was vielleicht gerade für das akustische Alarmieren und schnelle Bestätigen des Alarms wichtig wäre. Vielleicht kannst Du auch die Aufgaben aufteilen, also z.B. Anzeigen der Charts etc. über ne Webseite, die Alarme und den Sync der Steuerbefehle über eine dann deutlich kleinere App. > und ein teil des Quelltextes lässt sich ja immer > portieren. wie gesagt, die Plattformanbieter zwingen Dir verschiedene Programmiersprachen auf.
Oder halt die Alarme per Email oder ähnliches machen!? Gleich mit Zusammenfassung, Direktlink usw.
Frank schrieb: > Oder halt die Alarme per Email oder ähnliches machen!? > Gleich mit Zusammenfassung, Direktlink usw. ja, gute Idee. Wobei die Email auch wieder regelmäßig abgerufen werden muss, das ist nicht so zuverlässig wenn die Netzabdeckung schlecht ist. Aber ne SMS würde vermutlich gut funktionieren.
Gerd E. schrieb: > Frank schrieb: > Oder halt die Alarme per Email oder ähnliches machen!? > Gleich mit Zusammenfassung, Direktlink usw. > > ja, gute Idee. Wobei die Email auch wieder regelmäßig abgerufen werden > muss, das ist nicht so zuverlässig wenn die Netzabdeckung schlecht ist. > Aber ne SMS würde vermutlich gut funktionieren. Jupp, oder per Push-Mail
Also, ich tendiere nach euren Vorschlägen und ein bisschen Hausaufgaben zur Lösung App mit Xml. Gefällt mir einfach besser, wenn der user auf dem Endgerät eine eigene Umgebung nur für die Sensordaten mit Meldungen hat. Bei meinem Iphone wird bei manchen Apps das Vorliegen von Neuigkeiten schon im Sperrbildschirm dargestellt und mit einem roten Kuller an dem Appsymbol gekennzeichnet. Es kann auch nichts im Spamordner hängen bleiben oder im Emailpostfach untergehen. Weil es bei den Sensoren um DMS an teuren Infrastrukturbauwerken geht, darf das ganze ja auch was kosten und wenn es nur um eine Übersichtliche Darstellung geht. Ne andere Sache ist die mit den Alarmen. Für meine Emails habe ich die Benachrichtung ausgeschaltet um nicht nachts gestört zu werden. Bei einer App kann man das ja extra einstellen, mit einem Extraton versehen usw. Wie läuft das mit Datenbanken in Apps? Ist da auch xxSql Standard? Eine andere Möglichkeit, die mir über den weg gelaufen ist, ist Ms sync, hab ihr da Erfahrungen mit?
Sebastian B. schrieb: > Ne andere Sache ist die mit den Alarmen. Für meine > Emails habe ich die Benachrichtung ausgeschaltet um nicht nachts gestört > zu werden. Bei einer App kann man das ja extra einstellen, mit einem > Extraton versehen usw. Für SMS kannst Du normalerweise die Absender, in diesem Fall Deinen Server, in eine "VIP"-Gruppe (oder ähnlich benannt) einfügen. Deren Nachrichten und Anrufe werden dann auch laut signalisiert wenn das Gerät auf Stumm geschaltet ist. Wenn die Alarme so wichtig sind, dann würde ich die nicht nur von der App aus auslösen, sondern vom Server und mit verschiedenen Eskalationsstufen (SMS, Dauer-Anrufe, mehrere Personen, Sirene,...) versehen. Denn die App ist darauf angewiesen Daten vom Server zu bekommen. Und wenn die Internetverbindung schlecht ist, bekommt sie davon immer nur Bruchteile. Bis daraus dann das ganze Bild entstanden ist und berechnet werden kann daß jetzt Alarm ausgelöst werden sollte, ist es evtl. schon zu spät. Mir scheint daß Du da gedanklich noch zu weit in der Fat-Client-Welt bist. Pack so viele Aufgabe wie es geht in den Server. Denn das - musst Du nur einmal entwickeln statt für jede Mobilplattform - kannst Du leicht zentral warten und updaten - kannst Du automatisch überwachen In die App kommt nur so viel, wie für eine flüssige Bedienung ohne viel Bandbreite nötig ist. Die ganzen zentralen Entscheidungen fallen auf dem Server. > Wie läuft das mit Datenbanken in Apps? Ist da auch xxSql Standard? Hängt von der Mobilplattform ab. Bei Android verwenden die Apps z.B. meist sqlite um Daten abzulegen. Bei iOS gibts das auch. > Eine > andere Möglichkeit, die mir über den weg gelaufen ist, ist Ms sync, hab > ihr da Erfahrungen mit? Du meinst das hier? http://en.wikipedia.org/wiki/Microsoft_Sync_Framework Das gibts nur für .NET, gibts also wenn dann nur unter Windows Phone.
:
Bearbeitet durch User
Sebastian B. schrieb: > Appversion pro Plattform ca. 7,500€ budget, Ui. Das sind 3 Wochen Entwicklungszeit. Inkl. über Anforderungen klar werden, ein/zwei Muster um ein Verständnis bekommen, Programmierung, UI, Testen (auch die von dir beschriebenen schlechten Umgebungsbedingungen) und ein bisschen Doku. Die Serverseite ist dann auch noch nicht fertig. Falls deine APP dann nicht deutlich weniger können muss als ich mit denke, bekommst du mit seinen Gesamtbudget nur eine app + vllt. das Backend. Arbeite daran, mehr Geld für das Projekt zu bekommen.
JAVA ist von der Plattform unabhängig und läuft auch auf älteren Handys ohne OS recht flüssig. Wie sollen denn die Sensordaten übermittelt werden, Bluetooth, WLAN, LTE oder blinkende LEDs ? Wenn die Daten Offline zur Verfügung stehen müssen wäre XML wohl das sinnvollste Format und dann z.B. mit XSLT lokal in HTML wandeln um es anzuzeigen. Da anscheinend alles zentral erfaßt wird brauchst Du einen Server der dem Handy die Daten auf Nachfrage übermittelt, wie soll das gehen wenn Du schreibst es soll auch in entfernten Gegenden laufen ? Soll die APP die Sensoren auslesen können und an den Server weitergeben ? Dann ist GSM/LTE bei gutem Empfang wohl am sinnvollsten oder wird Dein Notebook als Server laufen ?
kalterkaffee schrieb: > JAVA ist von der Plattform unabhängig und läuft auch auf älteren Handys > ohne OS recht flüssig. Das mit dem "unabhängig" gilt aber nur so lange wie Du nichts darstellen musst. Außerdem gibts unter iOS kein Java.
Gerd E. schrieb: > kalterkaffee schrieb: >> JAVA ist von der Plattform unabhängig und läuft auch auf älteren Handys >> ohne OS recht flüssig. > > Das mit dem "unabhängig" gilt aber nur so lange wie Du nichts darstellen > musst. > > Außerdem gibts unter iOS kein Java. https://blogs.oracle.com/mobile/entry/oracle_brings_java_to_ios Und man kann es im Fall der Fälle als JAR im Browser laufen lassen und HTML erzeugen. Was aber nicht notwendig ist.
Mach eine Website als App https://blog.codecentric.de/2014/01/app-entwicklung-mit-cordova-erfahrungsbericht/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.