2013-05-09 3 views
11

Ich arbeite an der Erweiterung der Anzahl der unterstützten Plattformen für meine App, es unterstützt .NET4/Windows Store/Windows Phone, aber ich hoffe, auch Mono für Android und iOS. Ich habe alle Geschäftslogik, Modelle und Modelle auf Portable Class Libraries (PCL) übertragen, aber es ist ein großes Dilemma, auf welche Teilmenge von Plattformen ich zielen sollte. Jede Kombination bringt etwas zum Scheitern. Hier sind die Ergebnisse für 4 Plattformen, die ich verwenden könnte:Suche nach dem besten PCL-Profil für Cross-Plattform-Entwicklung

Profil 78 (NET45 + WP8 + Store): kein Problem mit TPL, erwarten/async und Unterstützung für CallerMemberName Attribut (in BindableBase Ansicht Modell Basisklasse). Aber das Mono.Android-Projekt, das eine solche Bibliothek referenziert, kann sich nicht über die nicht vorhandene System.Runtime.dll beschweren, auf die verwiesen werden sollte.

Profil 104 (NET45 + SL4 + WP75 + Store): erwarten/async nicht funktionieren, CallerMember Name nicht gefunden, aber wenn ich alle Verweise auf sie entfernen, baut Android Projekt gut.

Profil 147 (NET403 + SL5 + WP8 + Store): erwarten/async nicht funktionieren, CallerMember Name nicht gefunden, aber wenn ich alle Verweise auf sie entfernen, Android-Projekt baut gut.

Profil 158 (NET45 + SL5 + WP8 + Store): erwarten/async nicht funktionieren, CallerMember Name nicht gefunden, aber wenn ich alle Verweise auf sie entfernen, Android-Projekt baut gut.

Also ich bin mir nicht wirklich sicher, was ich wählen soll. Die Profile 78, 104, 147 sind begrenzt, das Profil 78 ist das einzige, das sowohl awaid/async als auch CallerMemberName BindableBase unterstützt, aber es scheitert an Android, das sich über System.Runtime.dll beschwert. Wenn Sie also wissen, welches PCL-Profil für PCL-Targeting am besten geeignet ist, teilen Sie uns Ihre Meinung mit.

+0

Achten Sie darauf, 'Microsoft.Bcl.Async' zu verwenden (was von' Microsoft.Bcl' abhängt). Diese fügen den Profilen 104/147/158 die Unterstützung async/await/CallerMemberName hinzu. –

+0

Microsoft.Bcl.Async kann (bisher) nur auf Windows-Plattform verteilt werden. Kein Mono. –

+0

@VagifAbilov Lizenzierung wurde auf Microsoft.Bcl.Async geändert http://www.hanselman.com/blog/PortableClassLibrariesJustGoTRALLYUsefulWithNewLicensingChanges.aspx –

Antwort

11

Denken über Profilnummern ist schwer - ich ziehe es vor, in Bezug auf die Plattformen zu denken.

Im Idealfall würde ich meine Projekte gerne unterstützen:

  • .Net 3.5 und höher
  • SL3 und höher
  • WP7.x Telefon und höher
  • MonoDroid 1.6 und höher
  • MonoTouch iOS6 und höher
  • (Mac desktop OSX Lion)

Das Haupt PCL-Projekt, das ich unterstütze, ist MvvmCross - das erfordert Mvvm 'Einrichtungen' wie ICommand. Diese Einrichtungen sind nur in Plattformen für .NET 4.5 und höher ... das ist eine harte Grenze - nichts, was ich dagegen tun kann - so ändert sich meine Bedürfnisse:

  • .Net 3.5 und höher .Net 4.5
  • SL3 und SL4 höhere und höhere
  • WP7.x Telefon und höher
  • MonoDroid 1.6 und höher
  • Monotouch iOS6 und höher
  • (Mac Desktop OSX Lion)

Mit dieser Auswahl an Ort und Stelle, so führt dies mich zu einer Profilnummer - 104 (keine Ahnung, wie die Plattform diese entschieden. .. hat aufgegeben vor langer Zeit gefragt!)

Also habe ich MvvmCross bei Profil 104 ausgerichtet - und es wird dort bleiben, während WP7.x Unterstützung noch benötigt wird.

Diese Auswahl bedeutet, dass MvvmCross nicht out-of-the-box-Unterstützung Dinge wie async/await und CallerMemberName - aber das ist ein Kompromiss, den wir entschieden haben, zu machen - wir haben Benutzer, die Notwendigkeit WP7.


jedoch fragen einige Leute über await/async ...

Um diese neuen Funktionen zu verwenden, gibt es einige BCL.Async Nuget hackt sie 104 im Profil arbeiten lassen ... oder diese Benutzer können ihre Apps auf ein neueres Profil ausrichten (eines, das WP7.x und SL4 nicht unterstützt). Dies führt dazu, dass sie ihre Apps in Profil 78 erstellen, aber Referenzen zu meinen Assemblys für Profile hinzufügen.

Keines dieser Sätze von Lösungen funktioniert derzeit sehr gut mit den Xamarin-Zwillingen - z. Sie haben Probleme wie die fehlende System.Runtime.dll-Assembly gefunden. Ich gehe jedoch davon aus, dass diese Probleme gelöst werden, wenn Xamarin offiziell PCLs unterstützt (und nach einigen Alpha/Beta-Tests). Diese offizielle Unterstützung ist jetzt sehr bald fällig -, weshalb ich nicht die Mühe zu viel von meiner Zeit aufwendet, um diese Probleme zu denken ...


ich auf mittlere Sicht erwarten, dass MvvmCross Unterstützung für WP7 sinken .x und SL4. Wenn das passiert, können wir auch die Kernbibliotheken bewegen 78. zum Profil


Die einzige andere große Plattform Ich weiß, dass PCL-Unterstützung gestartet ReactiveUI ist. Ich glaube, diese Plattform muss Profil 78 verwenden, da die PCL-Version von Reactive von Microsoft auf 78 ausgerichtet ist.

+0

Danke Stuart, tolle Antwort wie immer. Ich muss prüfen, wie wichtig BindableBase für meine App ist. Ich vermute, du hast in MvvmCross einen Ersatz dafür geplant. –

+0

Keine Ahnung - was ist BindableBase? Ist es nur https://github.com/slodge/MvvmCross/blob/v3/Cirrious/Cirrious.MvvmCross/ViewModels/MvxNotifyPropertyChanged.cs mit den 'CallerMemberName' Methoden hinzugefügt? – Stuart

+1

Der wesentliche Teil BindableBase ist dies: SetProperty (ref T-Speicher, Wert T [CallerMemberName] String property = null) So ist es mehr als MvxNotifyPropertyChanged. –