App für iOS / Android mit Delphi, Konzept machbar?

[hedie]

Hallo zusammen

Kurz eine Beschreibung meines Vorhabens:

Ich habe eine Elektronik entwickelt, welche eine Last
wie z.B. eine Lampe oder sonstiges schalten kann.

Nebst der Schaltfunktion, misst das Gerät auch noch den Energieverbrauch.
Die Elektronk verfügt über ein WLAN Modul und befindet sich in einem lokalen Netzwerk.
Angesprochen wird diese über eine IP Adresse mittels UDP oder TCP/IP Paketen.

Ich habe bereits fürher einmal eine Elektronik entwickelt, welche eine RGB Lampe
über Kabelgebnundenes Netzwerk steuern konnte.

Damals wollte ich ebenfalls eine App für das iPhone programmieren.
Nach langer recherche, musste ich leider feststellen, dass für die Native Programmierung mit
X-Code ein Mac Computer notwendig ist. Deshalb habe ich damals einen MacMini angeschafft.
Zudem musste ich mich in X-Code und die zugehörige Sprache "Objective C" einarbeiten.

War nicht leicht zu beginn, da der Aufbau der Sprache doch etwas von dem üblichen abweicht.
Besonders da diese mit Messages anstelle von üblichen Funktionen arbeitet.

Wie dem auch sei, ich habe es dann geschafft, UDP Pakete zu versenden...

inzwischen ist einige Zeit vergangen (ca. 2 Jahre) und ich müsste wieder eine Developer Lizenz für ca. 100€ kaufen und mich wohl nochmals einiges tiefer in Objective C einarbeiten um ein ansprechendes GUI zu erreichen.

Am ende hätte ich dann zwar ein tolles App für iOS aber nicht für Android etc...

Deshalb meine Frage an euch:

Wie gut funktioniert das Crossplatform programmieren mit Delphi?

Ziel: eine App, mit welcher mehrere dieser "Knoten" auf eine ansprechende Art und Weise
bedient werden können. Zudem soll der Stromverbrauch grafisch dargestellt werden.
Da ich bereits seit einigen Jahren mit Delphi programmiere, dachte ich es wäre gut
wenn ich damit auch Apps erstellen könnte. DIe frage ist nur, wie gut das klappt und ob
man damit genau so schnell zum Ziel kommt wie bei der Programmierung für Windows!

Meine Anforderungen:

- TCP/IP - UDP Pakete senden und empfangen
- Ansprechendes GUI (vernünftige Buttons etc)
- Ich benötige etwas wie ein Kurvendiagramm
- Die App sollte sich so nativ wie möglich verhalten, eine pseudo App ala HTML5 ist nicht ok!


ICh danke euch schonmal für euer Feedback!
Gruss
Claudio

[Sir Rufo]

Also ich hätte da ja einen minimalen Webserver eingebaut mit einer Oberfläche und einer API (bevorzugt REST).

Denn per HTML kannst du eigentlich mit jedem Device kommunizieren und damit auch mit deiner Schaltbox. Und besser absichern kann man das auch noch.

Wenn du für Android/iOS entwicklen willst, dann ist das eigentlich kein Problem, denn beide verhalten sich ziemlich gleich und mit XE7 hast du auch die Möglichkeit die Oberfläche speziell für das Device anzupassen. Somit eine Codebasis und für viele Devices.

[Darlo]

Ggf hilft das folgende Thread:

http://www.delphipraxis.net/1280313-post26.html

[hedie]

Zitat:

Zitat von Sir Rufo (Beitrag 1286973)

Also ich hätte da ja einen minimalen Webserver eingebaut mit einer Oberfläche und einer API (bevorzugt REST).

Interessanter Vorschlag.
Dann müsste es in meinem Szenario jedoch einen zentralen Webserver geben, der dann die anderen Devices verwaltet.

Denn die Idee bleibt die gleiche...
Es sollte auf dem Mobile Device nur eine Seite/App aufgerufen werden um von dort aus alle
Knoten verwalten zu können.

Könntest du die REST API noch etwas erläutern? Ich habe gegooglet und eine sehr umfangreiche
Wikipedia Seite gefunden.

http://de.wikipedia.org/wiki/Represe...State_Transfer

Ich dachte wenn du von API sprichts, meinst du etwas wie:

"Ich sende dies, dann sollte es so und so antworten"

Zitat:

Zitat von Darlo (Beitrag 1286976)

Ggf hilft das folgende Thread:

http://www.delphipraxis.net/1280313-post26.html

Danke für den Hinweis!
Die erstellte Oberfläche sieht sehr ansprechend aus...


Noch eine allgemeine Frage.
Ich habe aktuell Delphi Starter XE6
Damit ist ja crossplatform development leider nicht möglich.
Da ich das ganze Projekt nur im privaten Rahmen durchführe, möchte ich keine x-tausend Euro für
eine Pro Lizenz ausgeben.

Gibt es auch andere Möglichkeiten, CrossPlatform Development zu nutzen?

[Sir Rufo]

Wieso einen zentralen Webserver? Du kannst mit einem Device auch mehrere Webserver ansprechen. Und die API wird ja nun auch recht simpel sein:

• Schalten
• Abfrage Energieverbrauch

Allerdings dieses nun per JSON,XML, ... whatever und kann auch noch vernünftig abgesichert werden (wer darf schalten, wer darf abfragen).

Such einfach mal nach REST-API und PHP, bzw. schau, was für einen Webserver du auf den Schaltonkel packen kannst. Dann steht auch fest, ob da PHP überhaupt läuft. Dann kannst du dir ein REST-API-Framework dazu holen und diese Funktionen implementieren.

[hedie]

Zitat:

Zitat von Sir Rufo (Beitrag 1286980)

Wieso einen zentralen Webserver? Du kannst mit einem Device auch mehrere Webserver ansprechen.

Danke für deine Antwort.

Hmm eventuell verstehe ich deine Idee noch nicht ganz.

Ich hab deinen Vorschlag wie folgt verstanden:

Phone -> Webbrowser -> WLAN -> Knoten1 -> Webserver auf Knoten1

Nun sehe ich auf dem Phone die "Webseite" von Knoten1 mit Buttons und Daten.
Wenn ich nun die Daten von Knoten2 sehen möchte, dann muss ich dessen IP eingeben.

Deshalb dachte ich, einen zentralen server zu haben wäre leichter.
Dieser würde dann die Daten aller anderer Knoten sammeln und auf einer zentralen Webseite darstellen.

Oder hast du gemeint, dass eine APP auf dem Phone die unterschiedlichen Webserver mittels der API ansprechen würde?


Bezüglich PHP. Wenn du meintest, ob ich auf dem Knoten einen Webserver laufen lassen kann, welcher
eine PHP Seite darstellen kann, dann reicht dazu wohl die Leistung nicht aus.

Es ist lediglich ein 8Bit Controller mit etwas um 4MHz

[Sir Rufo]

Dann erkläre es mir doch mal wie es jetzt läuft.

Denn verstanden habe ich das so, dass du n Schaltboxen hast, die über jeweils eine IP-Adresse (n Boxen = n IP-Adressen) ansprechbar sind.

Mein Vorschlag ist ja nur gewesen, dass diese n Schaltboxen an ihren n IP-Adressen jeweils eine REST-API bereitstellen.

Wie kommst du denn jetzt an diese n IP-Adressen? Dieser Teil kann so bleiben, denn wir brauchen die IP-Adresse auf jeden Fall.

Und wie schickst du den Befehl zum Ein/Ausschalten? Da würde man nun die REST-API unter der IP-Adresse ansprechen.

Gut, wenn der Controller das nicht verträgt ... es bleibt aber unsicher, weil ja so jeder im WLAN diese Schaltboxen bedienen kann. Da wäre ja schon fast ein RasPi eine Alternative als Controller :stupid:

[hedie]

Zitat:

Zitat von Sir Rufo (Beitrag 1286985)

Dann erkläre es mir doch mal wie es jetzt läuft.

Denn verstanden habe ich das so, dass du n Schaltboxen hast, die über jeweils eine IP-Adresse (n Boxen = n IP-Adressen) ansprechbar sind.

Mein Vorschlag ist ja nur gewesen, dass diese n Schaltboxen an ihren n IP-Adressen jeweils eine REST-API bereitstellen.

Mein ursprünglicher Ansatz sah vor, dass ein UDP Paket an die Schaltbox gesendet wird.
In diesem UDP Paket im Payload, hätte sich dann ein Strukt mit allen notwendigen Informationen befunden.

Die Schaltbox hätte diese dann ausgelesen und entsprechend ein UDP Paket zurückgesendet.
Die Gegenseite (Das Phone) hätte wiederum den Buffer (Payload) ausgelesen und in ein Strukt eingelesen.

Um zu erkennen, um welche Art von Daten es sich handelt, hätte ich wohl das erste byte als indikator verwendet, und aufgrund von diesem Wert, die Daten in das entsprechende Strukt geladen.

Vermutlich denken jetzt einige von euch "was macht der den da.." aber ich bin kein Profi und bisher
war dies eine Funktionierende Lösung.

Auf dem Phone hätte man dann in der APP für jede Lampe einen Button anlegen können.
Hinter dem Button, wäre dann die IP konfiguriert worden.



Die Idee mit der REST-Api klingt jedoch gut.
Nur konnte ich bisher noch nicht genügend Infos darüber finden.

Zum thema PHP controller und unsicherheit...
Braucht denn eine REST-API PHP?

Ein Webserver könnte man durchaus laufen lassen.
Auch Parameter wären wohl kein Problem.
Einfach einen vollständigen PHP Interpreter wäre nicht möglich oder sehr aufwändig.

Ein Zugriffsschutz wäre dennoch möglich.

[Sir Rufo]

Nein, PHP ist nicht erforderlich, es gibt nur gute und fertige REST-API-Frameworks in PHP die man dann nur noch mit ein wenig eigenem Code zum Laufen bringen kann. Es vereinfacht die Sache erheblich. ;)

rest api framework
oder was ich einsetze
https://github.com/Luracast/Restler
gerade noch gefunden
http://www.gajotres.net/best-availab...ro-frameworks/

[Mavarik]

Zitat:

Zitat von hedie (Beitrag 1286986)

Auf dem Phone hätte man dann in der APP für jede Lampe einen Button anlegen können.
Hinter dem Button, wäre dann die IP konfiguriert worden.

Moin...
Und wie findet die App die Knoten? Reagierst Du mit den Konten auf einer der Multicast IP-Adressen und sendest die eigene IP zurück?

Zitat:

Zitat von hedie (Beitrag 1286986)

Vermutlich denken jetzt einige von euch "was macht der den da.." aber ich bin kein Profi und bisher
war dies eine Funktionierende Lösung.

Ob Du nun TCP/IP UDP nimmst oder oben drauf eine REST Schnittstelle ist für "Deine" App sicherlich egal.
Aber da diese Art von "Devices" auch gerne anderen Programmierern eine Schnittstelle zur Verfügung stellen nimmt man gerne "etwas" das handlicher ist als eine Bytefolge.

Ich habe ewig gebraucht um das KNX/IP Protokoll um zu setzen... Mit REST wäre ich wahrscheinlich in 10 Minuten fertig gewesen.

Mavarik

Mavarik

[Jonas Shinaniganz]

Schau dir bei deiner Recherche doch auch einmal gezielt das Android-Studio an.

Hier ist alles rund um Sockets dokumentiert:
http://developer.android.com/referen...e-summary.html
Es gibt zahlreiche Tutorials online.

Rest wäre ebenfalls denkbar. Ist eine Runde Sache für Android. :stupid:

[Sir Rufo]

Zitat:

Zitat von Jonas Shinaniganz (Beitrag 1287075)

Rest wäre ebenfalls denkbar. Ist eine Runde Sache für Android. :stupid:

REST ist nicht nur denkbar sondern eigentlich das Mittel der ersten Wahl.

HTTP kann eigentlich jedes Device sprechen
Mit einer REST-API entkoppel ich die echten Funktionen. Ähnliche arbeitende Geräte mit völlig anderem internen Aufbau und Ansteuerung verpasse ich die gleiche API und schon sind die gleich

Das könnte man noch beliebig fortführen ...

[Jonas Shinaniganz]

Zitat:

REST ist nicht nur denkbar sondern eigentlich das Mittel der ersten Wahl.

Je nachdem auf welcher Technologie hedie's mysteriöse "Elektronik" beruht gibt es da noch nichts an Bibliotheken hardwareseitig. Wenn er einen yC in ASM oder C programmiert hat...

Und von UDP/IP | TCP/IP zu REST -> Da ist ggf. ein Ozean zu überqueren.

Zitat:

"Angesprochen wird diese über eine IP Adresse mittels UDP oder TCP/IP Paketen."

Ich bin gedanklich noch auf folgendem Weg: hedie möchte eine kompatible APP entwickeln, eigentlich wird aber grade überlegt, wie man die "Schaltbox" sinnvoll gestaltet.

(Falls du die "Schaltbox" Software anpassen möchtest, wurdest du ja bereits gut beraten)

LG

[Sir Rufo]

Wir sprechen hier doch über ein Konzept und da ist es doch zulässig auch einen anderen Weg vorzuschlagen wenn der erhebliche Vorteile bringt. Und die Frage nach dem Webserver ist doch schon beantwortet: geht.

Es muss ja keine PHP-REST-API sein, aber die Kommunikation per HTTP würde ich immer bevorzugen.

[hedie]

Vielen Dank für die zahlreichen Antworten!

Zitat:

Zitat von Jonas Shinaniganz (Beitrag 1287092)

Zitat:

REST ist nicht nur denkbar sondern eigentlich das Mittel der ersten Wahl.

Je nachdem auf welcher Technologie hedie's mysteriöse "Elektronik" beruht gibt es da noch nichts an Bibliotheken hardwareseitig. Wenn er einen yC in ASM oder C programmiert hat...

Und von UDP/IP | TCP/IP zu REST -> Da ist ggf. ein Ozean zu überqueren.

Du hast recht, die Firmware des Knotens existiert noch nicht.
Und diese wird von grundauf in C neu geschrieben.
Wobei jedoch der TCP/IP Stack bereits im Netzwerkchip enthalten ist.
Somit muss ich nur einen wrapper für die schönen HTTP Funktionen schreiben.

Wenn ich im Netz dann mal ein Protokoll finde für die REST API, welche mir mitteilt, wie die Daten denn formatiert sein sollte,
dann könnte ich dass auch entsprechend umsetzen.

Zitat:

"Angesprochen wird diese über eine IP Adresse mittels UDP oder TCP/IP Paketen."

Ich bin gedanklich noch auf folgendem Weg: hedie möchte eine kompatible APP entwickeln, eigentlich wird aber grade überlegt, wie man die "Schaltbox" sinnvoll gestaltet.

(Falls du die "Schaltbox" Software anpassen möchtest, wurdest du ja bereits gut beraten)

LG[/QUOTE]

Ich bin inzwischen zum entschluss gekommen, dass es vermutlich einfacher ist, zwei native Apps zu programmieren.
Somit eines in Objective C für das iPhone und eines i Java für Android.


Bezüglich des konzepts, hat sich noch was geändert.

Zuerst wollte ich die Daten der Knoten in der App speichern.
Doch dazu müsste die App ständig die Knoten abfragen, da die Knoten nur sehr begrenzt zwischenspeichern können und dies auch nicht sollten.

Deshalb ist die Idee nun, dass die Knoten ihre Daten auf einen zentralen Server (ob der nun extern oder intern ist sei mal dahingestellt.)
ablegen werden. Die App wird dann die Daten von dort abholen und diese darstellen.

Vorteil:
Der Aufbau der Apps wird vereinfacht, da die Datenaufbereitung auch bereits auf dem Server stattfinden kann.
Die App kann dann z.B. einfach ein Feld namens "TotalEnegryConsumption" abfragen und dieses direkt anzeigen
anstelle die Daten intern zu verarbeiten.

In der Webprogrammierung wie PHP mit MySQL bin ich auch einiges sicherer als mit Objective C und Java...