WPF Anwendungen in freier Wildbahn?
-
Zwergli schrieb:
asc schrieb:
Zu WPF weiß ich nichts, befürchte aber das kurz nach WinRT tatsächlich auch WPF ein solches Schicksal erwartet.
Die Beziehung WinRT und WPF ist ja ein wenig komplexer. WPF bleibt ja erstmal bestehen, als UI Technologie für nicht Metro Anwendungen basierend auf .Net.
Ich hoffe, aber bei MS sehr *hust* zurückhaltenden Aussagen bin ich mir inzwischen überhaupt nicht mehr sicher. Vielleicht versuchen sie nun WinRT und Metro auf biegen und brechen zur Hauptplattform zu ernennen.
Zwergli schrieb:
Das interessante ist ja jetzt, das man zwar mit WPF keine Metro Applikationen schreiben kann, aber sehr wohl XAML nutzen kann zum GUI Design und C# als Backendsprache.
Wenn auch mit anderen Controls, anderen Bibliotheken, anderen Klassen-/Eigenschaftsnamen etc.
-
asc schrieb:
Um nochmal das mit den WinRT-Datenzugriffen zu konkretisieren:
1. WinRT kann ohne Services nur auf bestimmte Ordner zugreifen (Sandbox).
2. Alle Zugriffe die über diese Ordner hinaus gehen (Darunter zählt auch der Zugriff auf beispielsweise einen SQL Server) erfolgen über Webservices.Und über welche API hat man dann Zugriff auf den ganzen Rest?
-
hustbaer schrieb:
Und über welche API hat man dann Zugriff auf den ganzen Rest?
Kommt darauf an womit du den Service schreibst, WinRT jedenfalls nicht xD
Nachtrag: Das ist doch nicht viel anders wie bisher mit Silverlight.
-
asc schrieb:
Ich seh die Differenzen hier nicht so gravierend, wenn ich die Codeausschnitte richtig deute sehen sie fast so aus, wie ich ohnehin bereits unter WPF hantiere (Ich nutze z.B. asynchrone Services...).
Wenn man die reine GUI-Entwicklung betrachtet, mag das stimmen.
Aber es soll ja auch so etwas wie WinRT-Komponenten geben. Wenn die z.B. nur irgendwelche Logik enthalten sollen, wird es schwierig, das so umzusetzen, dass man eine Codebasis in WinRT und normalen Windows-Anwendungen gebrauchen kann.
Ich hab mir das mal für bestehenden Code angesehen, der über TCP/IP mit einer Embedded-Hardware kommuniziert. Kein Problem das auch in C# für WinRT zu realisieren, aber man schreibt fast alles nochmal, weil es jetzt andere Netzwerk-Klassen gibt.
asc schrieb:
Kommt darauf an womit du den Service schreibst, WinRT jedenfalls nicht xD
Wenn man ein Programm in Frontend (WinRT) und einen Service (normales Windows) aufteilt, kann man das aber nicht am Stück über den App-Store vertreiben, oder ?
-
nn schrieb:
Wenn man ein Programm in Frontend (WinRT) und einen Service (normales Windows) aufteilt, kann man das aber nicht am Stück über den App-Store vertreiben, oder ?
WinRT-Programme sind in erster Linie wie Smartphone-Apps konzipiert, laufen daher also in einer Sandbox. Man kann sich über die Projekteinstellungen gewisse zusätzliche Zugriffsmöglichkeiten schaffen, nichts desto trotz kann WinRT nun einmal einiges nicht (wie ja auch bislang schon für Silverlight galt) - und ob Benutzer unbedingt Apps kaufen die auf die komplette Verzeichnisstruktur (sofern wirklich machbar) Zugriff haben, steht auch auf einen anderen Stern.
Und natürlich kann man WinRT-Programme mit einem WCF-Service vertreiben, dies wird ja auch in der Windows Phone Entwicklung (beispielsweise bei Multiuserspielen) durchaus gemacht. Wer die Serversoftware bereit stellt ist dann eine Frage die aber den Bereich des Marketplaces verlässt.
WinRT-Programme sollen ja grundsätzlich auch auf einen ARM laufen, was der wiederum im Desktopbereich konkret an Bibliotheken anbietet, und wo die Einschränkungen sind, muss man auch noch sehen.
nn schrieb:
Aber es soll ja auch so etwas wie WinRT-Komponenten geben. Wenn die z.B. nur irgendwelche Logik enthalten sollen, wird es schwierig, das so umzusetzen, dass man eine Codebasis in WinRT und normalen Windows-Anwendungen gebrauchen kann.
Ich rezitiere mal "Metro Apps kennen nicht das Konzept einer gemeinsamen Bibliothek (Shared Library), das heißt, jede Metro App muss ihre DLLs selbst mitliefern. Nur die WinRT-DLLs sind geteilt." (http://www.winrt.de/)
Aber vielleicht kann jemand ja Gegenteiliges sagen, meine Informationen sind nur eine Essenz von dem was ich bisher von WinRT verstanden habe (Und da ich beruflich wohl frühestens eine Windows-Generation später mit WinRT in Berührung kommen werde, bleibt es bei einer oberflächigen Recherche).
-
asc schrieb:
Ich rezitiere mal "Metro Apps kennen nicht das Konzept einer gemeinsamen Bibliothek (Shared Library), das heißt, jede Metro App muss ihre DLLs selbst mitliefern. Nur die WinRT-DLLs sind geteilt." (http://www.winrt.de/)
Und was willst du damit sagen ?
Das MSDN-Artikel wie "Creating Windows Runtime Components in C++"
http://msdn.microsoft.com/en-us/library/windows/apps/hh441569%28v=vs.110%29.aspx
für dich keine Komponenten beschreiben, weil sie nicht mit anderen Anwendungen geteilt werden können ? Vielleicht will man das als App-Entwickler ja gar nicht.Wie man in den Beispielen im MSDN sieht, kann man, Applikations lokal, in C++ oder einer .net-Sprache WinRT Komponenten erstellen. Die kann man dann auch wieder in einer in Html und Java-Script geschriebenen App verwenden. (In XAML-Anwendungen natürlich auch.)
Dieser Ansatz steht in Konkurrenz zum XAML-Modell. Deswegen bin ich mir da noch nicht sicher, was sich langfristig durchsetzt. Ich mag zwar C# als Sprache, doch der Ansatz mit der Html-App mit etwas, nicht so leicht dekompilierbarer, Logik in C++ scheint mir für kommerzielle Anwendungen plausibel.
-
nn schrieb:
asc schrieb:
Ich rezitiere mal "Metro Apps kennen nicht das Konzept einer gemeinsamen Bibliothek (Shared Library), das heißt, jede Metro App muss ihre DLLs selbst mitliefern. Nur die WinRT-DLLs sind geteilt." (http://www.winrt.de/)
Und was willst du damit sagen ?
Wie man in den Beispielen im MSDN sieht, kann man, Applikations lokal, in C++ oder einer .net-Sprache WinRT Komponenten erstellen. Die kann man dann auch wieder in einer in Html und Java-Script geschriebenen App verwenden. (In XAML-Anwendungen natürlich auch.).
Wie auch in dem von dir verlinkten zu lesen ist: Die Komponenten müssen dem jewiligen Projekt hinzugefügt werden, und werden zusammen zu einem Programm kompiliert. In sofern gibt es zwar Komponenten, aber halt keine die "gemeinsam" von mehreren Programmen genutzt wird. Entspricht dem statischen Linken, und nicht einer dynamischen, gemeinsam genutzten Bibliothek.
-
asc schrieb:
Entspricht dem statischen Linken, und nicht einer dynamischen, gemeinsam genutzten Bibliothek.
Nö, eher dem Konzept, das man bei normalen Windows Anwendungen mit registry free COM verfolgt. Insoweit die logische Weiterentwicklung davon.
Eine Html-Seite mit C++ Code statisch zu linken stelle ich mir spannend vor.
-
nn schrieb:
asc schrieb:
Entspricht dem statischen Linken, und nicht einer dynamischen, gemeinsam genutzten Bibliothek.
Nö, eher dem Konzept, das man bei normalen Windows Anwendungen mit registry free COM verfolgt. Insoweit die logische Weiterentwicklung davon.
Wenn die Komponenten mit dem Projekt zusammen in ein Paket gelinkt werden, ist das für mich näher an dem statischen Linken als an "registry free COM", letzteres war ja so das diese noch seperiert (wenn auch im gleichen Verzeichnis) waren. Das es unterschiedliche Sprachen etc. sind, ändert für mich nichts daran das man am Ende eine Datei hat.
nn schrieb:
Eine Html-Seite mit C++ Code statisch zu linken stelle ich mir spannend vor.
Zumindest für die Auslieferung ist es so (Ersetze aber "Seite" durch HTML/JS-Projekt).
-
asc schrieb:
Wenn die Komponenten mit dem Projekt zusammen in ein Paket gelinkt werden,
Sie werden eher gepackt als gelinkt, so wie in einer *.docx Datei von Word verschiedene XML-Dateien stecken.
Die Isolation dieser Komponenten ist also eher eine Folge der Sandbox. Falls diese neue Art von COM außerhalb von Metro auftauchen sollte, dürfte das nicht mehr der Fall sein.
By the way, bald gibt es Literatur zum Thema:
http://blogs.msdn.com/b/microsoft_press/archive/2012/04/21/mark-your-calendars-programming-windows-sixth-edition-is-coming.aspx
