Entwickeln für Windows CE 6 oder Windows Embedded Handheld 6.5???

[Codehunter]

Naja, im Prinzip ganz normale Webentwicklung. Serverseitig ein LAMP und clientseitig HTML+CSS+JS. In meinem Fall handelt es sich um mobile Terminals für Lageristen mit Barcodescanner. Das PHP-Backend dient dann auch gleichzeitig als Backend für eine Delphi-Anwendung unter Win32. Man muss halt schauen was die Mobilbrowser können. Als ich vor 5 Jahren damit angefangen habe war Opera Mobile eben der beste Browser unter Windows Mobile 2003. Heute gibts da ja eine größere Auswahl. Theoretisch könnte man auch Delphi@Win32 selbst als HTTP-Server für die mobile Anwendung nutzen über Intraweb oder Indy. Die Möglichkeiten sind da vielfältig. In meinem Fall wurde serverseitig PHP und Mysql durch äußere Umstände vorgegeben, daher bin ich auch für die mobile App diesen Weg gegangen. Delphi nuckelt via SOAP am LAMP. Dadurch funktioniert meine Datenbankanbindung ohne BDE, DBExpress, ODBC oder zusätzliche DLLs. Das hat den Charme daß man die Anbindung via SSL fahren kann und sich für Fernzugriffe umständliches VPN-Gebastel sparen kann. Serverseitige Kompression spart Bandbreite, das geht sogar über eine ISDN-Leitung flüssig. In Delphi habe ich da nur Indy 9 und die zlib benötigt. Als XML-Parser habe ich ECXMLParser von Eon Clash verwendet, der ist Freeware und der schnellste baumbasierte Parser den ich kenne.

[sh17]

Und schon irgend welche Ergebnisse? Stehe gerade vor dem gleichen Problem: Windows CE 6 - Per Browser würde aber wahrscheinlich ausscheiden, weil es ein Handgerät ist, welches
evtl nicht überall WLAN hat.

[Codehunter]

Kommt ganz auf den Verwendungszweck an. Ein paar Beispiele sind ja schon genannt: Lazarus und .Net

Mit Lazarus geht schon viel, allerdings ist die VCL dort noch sehr, sehr lückenhaft und die Standard-Komponenten verhalten sich zum Teil seltsam, kennen nicht alle Eigenschaften. Eventhandler sind auch noch nicht so die Stärke von Lazarus-Binaries auf Win CE.

Vielleicht kannst du noch irgendwo ein Exemplar des damals kostenlosen Embedded VisualStudio for Handheld (ca. 2003) auftreiben. Das begrenzt sich aber im Wesentlichen auf die MFC.

Inzwischen ist das Embedded VS im normalen VS Pro aufgegangen und dort dann eben das .Net Compact Framework.

[sh17]

Also VS 2008 und 2010 habe ich noch, Geht aber wohl nur mit VS 2008, richtig? Kann man das Compact Framework grundsätzlich empfehlen?

[Codehunter]

Zum Net CF kann ich leider keine Auskunft geben da ich eine hinlänglich bekannte .Net-Allergie habe.

[janiz]

Hallo,

ich stand vor kurzem vor einem ähnlichen Problem. Bei mir war es Windows Mobile 6.5 auf einem Motorolla 65A.
Zusätzlich sollte ich den Scanner dabei ansteuern. In meinem Fall entschloß ich mich das ganze mit C# zu machen.
Leider musste ich dazu erstmal VS2008 nachinstallieren, geht leider nicht anders da ich noch die Scannerabhängigen SDKs von Symbol fuer den Scanner benötigt habe.
Meine Erfahrung mit dem Compact-Framework sind zwiespältig.
Vieles was man von C# so kennt funktionierte auf dem CF (in Version 3.5) nicht, beispielsweise auch verschieden Strinoperationen.
Auch habe ich es nicht geschafft die kompakte Version der MS-Sql auf dem physikalischen Gerät zum laufen zu bringen.

Ansonsten war es sehr komfortable, d.h. es man kann z.B. direkt beim Build das Programm auf dem Gerät bereitstellen und Debuggen.

Ich muss allerdings auch sagen, dass mir Delphi bedeutend lieber ist.

Grüße

[Furtbichler]

Das eine Mal, wo ich für ein CE eine Applikation entwickelt habe, ging das innerhalb von 0.5 Tagen in VS2003 glaube ich oder 2005 und war vollkommen problemlos. Eine Allergie oder Aversion habe ich nicht. Wozu auch, denn mit VS/C# geht fast alles viel besser. q.e.d.

Das zweite Mal war es ein modifizierter Browser: Die Datenerfassung ging über einen Web-Client und ich musste nur den WebBrowser in eine Mini-App einbinden. Aber auch das ging ratz-fatz.

MSSQL CE habe ich allerdings noch nie benötigt.

Ich würde zu C#/VS raten.

[Codehunter]

Zitat von janiz:

Leider musste ich dazu erstmal VS2008 nachinstallieren, geht leider nicht anders da ich noch die Scannerabhängigen SDKs von Symbol fuer den Scanner benötigt habe.

Das versteh ich nun wieder nicht. Grad die Scanner von Symbol Tech lassen sich doch inzwischen fast bis ins Unendliche konfigurieren (gibt ja auf manchen WCE-Geräten schon 5 verschiedene Systemsteuerungs-Applets dafür) sodass alles, aber auch wirklich alles über den Tastaturpuffer laufen kann. Oder hast du die Scanner-Auslösung gleich mit implementiert? Dann könnte ich es verstehen.

@Furtbichler: Ich bestreite ja gar nicht, dass VisualStudio zur Zeit die beste Plattform ist um native Anwendungen für WCE zu schreiben. Java kann man ja inzwischen komplett vergessen, wäre auch nicht wirklich nativ. Und Lazarus ist noch weit davon entfernt, brauchbare Anwendungen auszuspucken. Dafür sind die Widgetsets für WCE noch viel zu unvollständig.

Doch dieser Zustand zeugt doch nur davon, dass WCE ein von vorn bis hinten proprietäres System ist, dessen Marktanteile inzwischen auch rückläufig sind. Ich sichte inzwischen in den Portfolios der verschiedenen Hersteller von Ruggedized Mobile Devices immer mehr Androiden. Einzig iOS spielt dort bisher überhaupt keine Rolle.

[JamesTKirk]

Zitat von janiz:

Leider musste ich dazu erstmal VS2008 nachinstallieren, geht leider nicht anders da ich noch die Scannerabhängigen SDKs von Symbol fuer den Scanner benötigt habe.

Hmm? Ich hab damals kein Visual Studio installiert, um an das SDK ranzukommen (ich benötigte die Header für eine Konvertierung nach Free Pascal). Kann aber auch sein, dass ich den Installer angepasst habe (war das ein *.msi?)...

Zitat von Codehunter:

Und Lazarus ist noch weit davon entfernt, brauchbare Anwendungen auszuspucken. Dafür sind die Widgetsets für WCE noch viel zu unvollständig.

Wir haben eine Windows Mobile Anwendung (für Symbol Geräte) im Produktiveinsatz. Soviel zu weit davon entfernt brauchbare Anwendungen auszuspucken...

Gruß,
Sven

[Codehunter]

Zitat von JamesTKirk:

Wir haben eine Windows Mobile Anwendung (für Symbol Geräte) im Produktiveinsatz.

Dann bist du damit weiter gekommen als ich. Ich bin an nicht funktionierenden Eventhandlern verzweifelt. Kommt eben ganz darauf an, was für eine Anwendung man benötigt und wie die Leute sie bedienen.

Zum Glück führen viele Wege nach Rom und das ist gut so.