C++ oder C# zu Programmieren mobile barcode-Gerät?

Ich habe Konzeption und Entwicklung von software für Windows Mobile und Windows CE in C, C++ und C# für ziemlich ein paar Jahre jetzt. Außerdem habe ich schon getan, für Honeywell (ehemals Hand Held Products, gekauft von Honeywell im Jahr 2007), wo ich gearbeitet habe, fast alle Aspekte der Geräte, die von Treibern und Diensten, um Line-of-Business-Benutzeroberflächen und utilities.

Zunächst, ich nicht sagen, Sie eine Sprache besser ist als die andere... ich wahrscheinlich verbringen eine 50/50-split, meine Zeit mit jeder, und jede Plattform hat definitiv Ihren eigenen Platz in der mobile-Entwicklung.

Werde ich jedoch den Vorschlag, daß Sie wahrscheinlich bleiben Sie Weg von jedem Gerät, das ein Betriebssystem so alt ist wie WinCE 4.2, vor allem wenn man noch in Betracht ziehen .NET Entwicklung. Der Grund dafür ist, dass 4.2 nur bei den meisten .NET CF 1.0 eingebettet in ROM (Teil des OS ROM image), was bedeutet, dass Sie benötigen würde, ein ~5MB CAB-Datei zu installieren, mindestens .NET CF 2.0 ja, Sie entwickeln könnte mit CF 1.0 ist, aber, wirklich, es lohnt sich nicht den Schmerz, der mit solch einem alten Rahmen. Die meisten WinCE 5.0-Geräten in diesen Tagen kommen mit CF (Compact Framework) 2.0 installiert die ROM, so würde ich zumindest sehen, dass für.

Auf dem gleichen, vergeblich, Sie möchten vielleicht sogar zu erwägen, ein Gerät mit Windows Mobile 6.0 oder 6.1 als Sie leicht zu Programmieren mit und wird immer in CF 2.0 vorinstalliert. Falls Sie sich Fragen, warum habe ich nicht erwähnt, CF 3.0 oder CF 3.5, es ist nur, weil die erste Mobile Plattform sein release mit diesen Versionen werden für Windows Mobile 6.5, welches noch nicht draußen ist. Jedoch können Sie immer installieren Sie die Rahmen, wenn Sie möchten (~8MB CAB).

Gewährt, WinCE jeden Fall gibt Sie eine "Windows" schauen und fühlen, um seine GUI über seine Windows Mobile-cousin, das ist also alles eine Frage der Programmierung Vorlieben und was Ihre end-Benutzer wollen und brauchen.

Bezüglich kgiannakakis ist Kommentare auf der SDKs nur eine Sache, die Ebene, dies ist einfach nicht wahr. Wenn Sie mit der richtigen SDK sollten Sie haben alle den gleichen Zugriff auf alle Geräte und Treiber in C++, aber mit der Einfachheit von C#. Zum Beispiel, bietet Honeywell ein umfangreiches SDK für alle unsere Geräte in C++, VB-und C# - und C# - Teil des SDK hat eigentlich mehr Funktionalität als C++ - Teil. Sie nie zu tun haben, ein P/Invoke mit unserem code von C#.

Wenn Sie möchten, werfen Sie einen Blick auf die SDK, die ich spreche, es ist frei verfügbar zum download hier und hat einige gute Beispiele.
IMHO würde ich tatsächlich überlegen das mitgelieferte SDK als wichtiger als die hardware in vielen Fällen, da die meisten der Zeit, die hardware der Geräte ist so ziemlich das gleiche. Sie alle haben ARM-CPUs, WLAN, Bluetooth, Laser-oder Image-basierte Scanner, etc.
Obwohl, ich schaute auf die Intermec-link, den Sie gepostet und es sieht nicht danach aus, das Gerät hat tatsächlich eine eingebaute scanner...sind Sie mit einem externen scanner süchtig auf das Gerät?
Werfen Sie einen Blick auf die Honeywell-Angebot, wenn Sie wollen hier. Wir haben Geräte mit den wohl besten imager based bar code scanner im Geschäft sind, gebaut und in alle unsere Einheiten. Und wir haben eine rock-solid-SDK (ich sollte es wissen, ich schrieb eine Menge it). Und die SDK bietet .NET extrem Zugang zu allen hardware auf dem Gerät. Ok...ich höre auf mein Verkaufsgespräch jetzt.

Als für die jeweils andere Sprache...es ist wirklich alles hängt davon ab, was genau Sie wollen zu tun.

Treiber und Dienste nicht geschrieben in alles andere als die Native (Win32) C oder C++. So .NET ist für so etwas.
C und C++ kann durchaus sein, Ihren Freund auf mobile Geräte in Bezug auf die Dinge zu halten leicht, da brauchen Sie nicht das ganze .NET framework zum ausführen der add. Denken Sie daran, Sie haben maximal 32 MB Speicher für jeden Prozess (nicht einschließlich DLLs..das ist eine andere Vorlesung), so dass, wenn Ihre Anwendung wird die Verarbeitung eine Tonne von Daten, C++ kann der Weg zu gehen.

Einer der großen Nachteile, die ich gefunden habe, um C und C++ auf mobilen Systemen ist jedoch, dass eine GUI Weg schwerer, als es ist mit .NET Wirklich, die meisten C++ - apps, die ich Schreibe, sind völlig kopflos und haben keine GUI überhaupt... .NET CF nicht haben WPF (noch) nicht, und ist fest mit WinForms, aber es ist wirklich einfach zu Holen. Ziemlich viel drag und drop in den designer. Und erinnere mich auch, wie ich bereits erwähnt, dass WinCE hat einen komplett anderen GUI-Paradigma als Windows Mobile. Manchmal wird jedoch der Windows-Mobile Weg, ist irgendwie nett, weil es zwingt Sie dazu, halten Sie Ihre GUIs einfach und auf den Punkt.

Speicherverbrauch kann höher sein, wenn Verwendung .NET, aber nicht immer. Zum einen, dass ein Gerät mit der version der CF, die Sie verwenden, gespeichert in ROM bedeutet, dass Sie im Allgemeinen nicht mehr verwendeten Speicher auf .NET-Anwendung, vs der äquivalenten C++ - app. In einigen Fällen, .NETTO wird sogar weniger Speicher. Zum Beispiel, ein .NET-app-vs-C++ - app, die MFC verwendet oft verwenden weniger Speicher, da die C++ - app hat zu laden, bis das MFC-framework (da es nicht bereits geladen ist, durch die OS...).
Auch, weil C# ist managed, werden Sie oft am Ende mit weniger Arbeitsspeicher-Nutzung, da der garbage collector freigeben von Speicher, die Sie vielleicht vergessen haben zu tun in eine C++ - app.

Ausführungsgeschwindigkeit auf modernere Geräte ist in der Regel kein Unterschied zwischen den beiden. Zugegeben, Sie haben immer wenig Teile, die der jeweiligen Sprache, wo man schneller ist als die andere, aber .NET reif genug ist, an dieser Stelle, dass die Geschwindigkeit ist nicht wirklich ein Problem. Ich habe programmiert, extrem schnelle Anwendungen mit hoch-interaktive, animierte GUIs, die lief Prima auf einem Gerät mit 128 MB RAM und eine 420MHz ARM-CPU. Ich schrieb sogar eine app, die ich hatte, um verlangsamen, weil es Berufung war in eine native-DLL via P/Invoke und die .NETTO-Teil wurde im wesentlichen immer "Ungeduldig."

Ich habe noch nie irgendwelche Probleme mit der Lebensdauer der Batterie in einer Sprache gegenüber einer anderen. Aber ich habe noch nie explizit getestet, für die es entweder.

Ich glaube wirklich, dass, am Ende, es kommt immer noch nach unten an die SDK, die Sie mit Ihrem Gerät der Wahl. Wenn es schlecht .NET unterstützen, dann werden Sie finden, Ihr selbst zu tun eine Menge extra Arbeit, alles zu bekommen, um zu arbeiten, in dem Fall würde ich mit C++. Aber wenn es toll .NET-Unterstützung (wie der eine der ich arbeite) Sie finden sich mit viel weniger Arbeit und wahrscheinlich den job zu erledigen, deutlich schneller.

Denken Sie auch daran, dass es nicht nur das SDK der Hersteller der hardware, die Sie haben, zu berücksichtigen. Während Sie benötigen, die spezifische SDK, da jedes Gerät anders ist (also das SDK habe ich bereits verlinkt nicht Arbeit auf das Intermec-Gerät), die nicht mit der hardware zusammenhängt OS Zeug ist ziemlich standard auf der ganzen Linie, die ist, wo die Windows Mobile oder Windows CE SDK von Microsoft kommt. Ihre C++ - Unterstützung ist ziemlich gut, aber Sie sind wirklich drängen aller Dinge .NETZ in diesen Tagen, so wie Aktualisierung der OS, weniger updates sind gemacht, um die C++ - SDK und viel mehr Funktionalität setzt nun auf mithilfe .NET Nicht, dass Sie konnte nicht tun es in C++, es ist nur, dass Sie nicht getan haben eine Menge Arbeit für Sie, die Sie hat tun .NET SDK.

Ok...das war lang, aber ich habe versucht, dump die feineren Teile von meiner langjährigen Erfahrung in einer Sache. Ich hoffe, es hat Sinn.

Zunächst werde ich stark echo-Adam ' s Empfehlung gegen, läuft alles basiert auf CE .NET 4.2 an dieser Stelle im wesentlichen aus dem gleichen Grund. An diesem Punkt ist es eine alte version des OS und sofern Sie das terminal kostenfrei es lohnt sich nicht, und wenn Sie in der C# - Entwicklung der download der CAB ausführen .NET 2 ist einfach nur schmerzhaft.

Wir haben entwickelt eine Menge von Anwendungen für Motorola(Symbol) und Intermec-Geräte. Der aktuelle Satz von APIs für beide von Ihnen arbeiten zuverlässig, so würde ich keine sorgen mehr um die EIGNUNG des Gerätes als die spezifischen APIs. Sie haben auch beide einen angemessenen Probe-Programme, die machen es leicht zu schneiden und fügen Sie eine Lösung.

Habe ich bemerkt, einen anderen großen Unterschied zwischen Motorola und Intermec. Auf die Intermec-Geräte, mit denen ich gearbeitet habe (in C#), dauert es rund eine Sekunde, der decoder für jeden der Symbolik geladen werden. Dies ist in der Regel nicht eine große Sache, wenn Sie Gebrauch eine begrenzte Anzahl von Symbologien und Inbetriebnahme des Scanners bei start der Anwendung, kann aber zu erheblichen Verzögerungen führen, wenn Sie ändern Sie die Decoder(Symbologien) in der Anwendung.