Konventionen für WPF-Anwendungen, die sowohl auf dem Desktop als auch auf der Oberfläche (PixelSense) 1.0 ausgeführt werden

Bearbeiten: Um Verwechslungen zu vermeiden: Es handelt sich um die Tabelle, die früher oder noch immer Microsoft Surface 1.0 genannt wurde. Es geht nicht um die Tabelle, die früher Microsoft Surface 2.0 genannt wurde, und es geht nicht um den Tablet-Computer, der jetzt Microsoft Surface heißt. Bearbeitungsende

Ich schreibe eine WPF-Anwendung, die sowohl auf Desktop-Systemen als auch auf MS Surface / PixelSense 1.0 laufen sollte. Ich suche nach Konventionen, wie dies normalerweise geschieht.

Ich bin mir bewusst, dass es einige Unterschiede zwischen den Plattformen gibt, weshalb die grundlegenden GUI-Skelette für den Desktop und die PixelSense-Version unterschiedlich sind (in diesem Fall ein Canvas in der Desktop-Version und ein ScatterView in der PixelSense-Version als root-GUI-Element).

Allerdings gibt es viele WPF-basierte Benutzersteuerelemente / GUI-Fragmente in der Desktop-Version, die in der PixelSense-Version mehr oder weniger genauso aussehen sollten.

Leider scheinen Standard-WPF-Steuerelemente in PixelSense nicht zu funktionieren. Steuerelemente wie CheckBox müssen durch SurfaceCheckBox ersetzt werden, um auf Benutzereingaben zu reagieren, was leicht verifiziert werden kann mit diesem kleinen Codebeispiel bei PixelSense:

Offensichtlich bedeutet dies, dass die WPF-Benutzersteuerelemente in PixelSense nicht ohne Änderungen angezeigt werden können, wie dies durch Anweisungen in Ressourcen wie Microsoft-Dokumentation auf der PixelSense-Präsentationsebene , die SO-Fragen stellt wie diese zu einer WPF-Baumansicht beziehen sich auch auf diesen Blogeintrag auf die PixelSense-WPF-Ebene oder diese SO-Frage zum erneuten Schreiben einer WPF-Desktopanwendung für PixelSense . Die letzte Seite ruft sogar die erforderlichen Änderungen minimal auf, aber sie sind immer noch Änderungen.

Außerdem, Reaktionen auf SO Frage darüber, wie man ein bestimmtes verwendet Die WPF-Desktopsteuerung in PixelSense impliziert, dass die Verwendung von .NET 4.0 die Dinge vereinfachen könnte, aber ich glaube nicht, dass .NET 4.0 vom PixelSense-SDK 1.0 unterstützt wird (es ist .NET 3.5-basiert) soweit ich das beurteilen kann.

Als Softwareingenieur kann ich immer noch nicht der Strategie zustimmen, dieselben GUI-Fragmente (die im Grunde aus denselben Steuerelementen im selben Layout mit dem gleichen Verhalten gegenüber dem Datenmodell bestehen) mit derselben Programmiersprache zweimal zu schreiben. Das scheint einfach falsch zu sein.

Also, drei mögliche Lösungen, die ich bisher gefunden habe:

• Schreiben Sie die GUI-Fragmente für Standard-WPF. Kopieren Sie dann die Bibliotheken, die diese GUI-Fragmente enthalten, mithilfe von Skripten und transformieren Sie alle relevanten Xaml-Dateien (z. B. mit XSLT) so, dass sie die Standard-WPF-Steuerelemente durch ihre Surface* -Partner ersetzen.
  Nachteile:
  • Erhöhte Wartung erforderlich, damit Skripts immer dann funktionieren und ausgeführt werden, wenn sich etwas in den WPF-Projekten geändert hat.
  • Außerdem kann es kompliziert sein, zu definieren, welche Xaml-Dateien berücksichtigt werden sollen und welche Steuerelemente durch was ersetzt werden sollen (zusätzliche PixelSense-Steuerelemente von Drittanbietern)
  • Schließlich wäre das generierte PixelSense-Projekt eine exakte Kopie des WPF-Projekts, abgesehen von den Xaml-Dateien, sodass kein PixelSense-spezifischer Code eingeführt werden könnte (oder wenn dies möglich wäre, würde dies die Skripts zum Generieren des PixelSense-Objekts machen) Projekte noch komplexer).
• Richten Sie nur PixelSense / Surface aus, und Desktopbenutzer müssen das Surface SDK installieren. Danke an den Benutzer Clemens für den Vorschlag!
  Nachteile:
  • Benutzer müssen das Surface 1.0 SDK installieren, was - auf aktuellen Systemen - ein nicht-trivialer Vorgang ist: Damit das Surface 1.0 SDK unter Windows ausgeführt werden kann 7 64 Bit Maschine, verschiedene Aktionen wie das Patchen von MSI-Dateien müssen ausgeführt werden.
  • Der PixelSense / Surface 1.0-Simulator ist die einzige Möglichkeit, Surface 1.0-Anwendungen auf einem Desktop-Computer auszuführen. Dieser Simulator ist nicht sehr gut benutzbar und auf manchen Systemen geradezu fehlerhaft: Auf meinem Computer sieht das so aus: (Die Ausgabe deckt ab nur einige 3/4 des Simulatorfensters, aber der Eingang wird im gesamten Fenster registriert, dhUm auf die untere rechte Ecke der Oberflächensimulation zu klicken, muss ich in die (scheinbar transparente) untere rechte Ecke des Simulatorfensters klicken.)
• Verwenden Sie beim Erstellen der grafischen Benutzeroberfläche anstelle der expliziten Verwendung von standardmäßigen WPF- oder PixelSense-Steuerelementklassen eine plattformspezifische Factory, die den entsprechenden Steuerelementtyp erstellt.
  Nachteile:
  • Die GUI-Fragmente können nicht mehr mit Xaml geschrieben werden; zumindest die meisten Steuerelemente und alle ihre Bindungen müssen in C # -Code erstellt werden.

Ich stehe derzeit auf die dritte Option, da es einfach ein akzeptabler Preis für die Plattformunabhängigkeit zu sein scheint. Ich denke jedoch, dass WPF das verbindende Element zwischen den Desktop- und PixelSense-GUIs sein sollte und dass dies ein häufiges Problem sein sollte, und ich frage mich, ob dies bisher nicht gelöst wurde. Also frage ich hier: Wie wird das normalerweise gemacht?

P.S .: Orientierung ist kein Problem. Die oben genannten GUI-Fragmente werden in drehbaren ScatterViewItems auf PixelSense und in ihrer normalen vertikalen Ausrichtung auf Desktops angezeigt.