Strategie für PDA Einsatz gesucht

[ibp]

Hi allwissende...

Es geht darum Daten aus einer DB-Applikation auf ein PDA zu schicken, dort abzuarbeiten, Daten wieder zurück an DB-Applikation senden und weiterverarbeiten.

Dabei soll das PDA sich nicht direkt auf die DB schalten, die DB soll auch nicht über Internet ansprechbar sein.

Das ganze soll Semimanuell ablaufen.

Es sollen möglichst alle PDA damit zurechtkommen.

Meine Fragen: Wie würdet ihr das realisieren und mit welchen Programmiersprachen?

Danke schon mal....

[WM_CLOSE]

Java, sonst ist alles irgendwie Betriebssystemabhängig, eine JRE hat fast jeder PDA

[Phoenix]

Die elementare Frage wird wohl sein: Was für PDA's?

Ansonsten ist hier der 'normale' Ansatz einen Application-Server hinzustellen auf den die mobilen Geräte dann verbinden und der die ganzen Geschichten wie Security und DB-Zugriff abhandelt. Da gibt es entsprechende Frameworks für, Du solltest dann nur Sicherstellen dass es auch auf allen benötigten mobilplattformen Client-Bibliotheken gibt oder der Server möglichst viele Protokolle (z.B. REST, ODATA, SOAP) beherrscht um die Clients anzubinden die keine direkte Verbindung mit dem jeweiligen nativen Protokoll hinbekommen (unmittelbare Verbindungen sind immer schneller, deswegen sollte man vermeiden alles über recht langsame Webservices zu machen.

Idealerweise nimmt man für die Clients irgendwas .NET-Basiertes, denn Java wird z.B. auf iOS-, und Windows Phone 7 Geräten nur schwerlich laufen, mit entsprechenden Tools kannst Du .NET Code neben so ziemlich allen anderem aber auch auf Blackberry und Android-Geräte packen.

[QuickAndDirty]

Wann kommt Copper?
Und wird es wieder über Emba teuer verbreitet oder
preisgünstig von RemObjects?

[alzaimar]

Ich habe das mal mit ASP.NET sehr einfach implementiert. Obwohl ich kaum Ahnung von HTML, ASP und dot.Net hatte, lief die Anwendung innerhalb weniger Tage!

Da mir die Eingabemöglichkeiten mit ASP.NET nicht sonderlich gefallen, habe ich mir dann eine kleine C# Anwendung gebaut, die auf einem PDA unter Windows Mobile läuft. Die Kommunikation hatte ich dann direkt mit der DB gemacht. Das C#-Programm kann man sehr einfach auf dem PC testen.

Mit VS geht das wirklich total einfach. Ich würde es auch gerne mit Delphi realisieren, hab aber keinen Bock, irgendwelche Experimentalteile auszuprobieren.

Da Windows Mobile nicht jedermanns Sache ist, sind andere Plattformen natürlich mindestens ebenso brauchbar.

Microsoft hat das aber wirklich klasse gelöst. Gibt es ähnlich elegante Alternativen (IDE+Emulator+einfacher Upload etc.)?

[mquadrat]

Ich würde den Server-Part mit einem Webservice ausstatten. Und die PDA Anwendung dann jeweils in der für den PDA passenden Sprache. Stellt sich halt wirklich die Frage was genau du unter einem PDA verstehst.

Die Alternative wäre eben eine Webseite, die vom PDA aus ausgerufen wird. Kommt halt auf die Anwendung an, ob du ggf. Zugriff auf Barcode-Scanner brauchst oder sonst wwas (wie gesagt PDA ist ein weiter Begriff)

[Phoenix]

Zitat von QuickAndDirty:

Wann kommt Copper?

Cooper (nicht Copper ) kommt dieses Jahr.

Zitat von QuickAndDirty:

Und wird es wieder über Emba teuer verbreitet oder preisgünstig von RemObjects?

Keine Ahnung (wirklich). Und wenn ich es wüsste dürfte ich wahrscheinlich (noch) nix sagen.

Was ich aber anteasern kann ist, dass es für RO/SDK und DA in entsprechend naher Zukunft auch 'native' Java-SDK's geben wird.

[ibp]

angedacht wäre grob (es geht um Arbeitsaufträge)

DB-Applikation -> XML -> PDA

PDA soll die Daten anzeigen und es müssen ggf. Daten ergänzt/bearbeitet werden. Bisher sind Barcodescanner etc. nicht angedacht.

Nachdem die der Auftrag abgearbeitet wurde schickt man die Daten zurück.

Dabei sollten die Daten nicht direkt wieder in die DB geschrieben werden, dass soll dann eine Zwischenschicht machen die die Daten vorher validiert.

Also grundsätzlich sollten möglichst viele PDA unterstützt werden.

[Phoenix]

Wie bereits angedeutet: XML ist ein äussert aufgeblähtes Format. Wenn Du die mobilen Clients einigermassen Performant anbinden willst würde ich nur wenn es auf einem System nicht anders geht auf normale Webservices / SOAP / XML setzen und alles was möglich ist schneller (JSON / ODATA) oder richtig schnell (Binärformate) anbinden.

Wenn ich jetzt wieder mit DataAbstract komme werde ich noch wegen Werbung gesteinigt, aber eigentlich ist genau das eines der Paraderollen für das System. Es kann Serverseitig nahezu jedes beliebige Format abbilden und Clientseitig kann man, wenn es das SDK für die Zielplattform gibt (derzeit iOS (native und alternativ via MonoTouch), Android (via MonoDroid, native in Mache), Blackberry (native) und Windows Phone 7 (native)) eben direkt mit dem gleichen Code andocken und andere Plattformen (z.B. Symbian) greifen dann halt z.B. via ODATA oder eben normale, langsame Webservices drauf zu.

Die ganze Logik liegt dabei dann eben auf dem Server.