Echte Business anwendungen mit Metro sind schweer bis garnicht möglich -- derzeit

Hiermal ein Link welcher aufzeigt mit welchen Problemen Entwickler richtiger Anwendungen derzeit mit WinRT kämpfen.

http://social.msdn.microsoft.com/For...2-45c7c51be1c0

Missing Functions in WinRT

http://social.msdn.microsoft.com/For...7-0d2afca4eac0

Webservices sag ich nur...damit sollte man praktisch alles erschlagen. Aber viele Firmen gehen noch direkt auf die Datenbank.

Bei Metro-Anwendungen geht es scheinbar in eine recht ähnliche Richtung was die Einschränkungen betrifft wie bei Silverlight. Dort bekommst du (von Windows Phone abgesehen) ja auch nur via WebServices Zugriff auf Datenbanken. Das bedingt dann natürlich immer eine andere Architektur (ich brauche eine Serverschicht, wie z.B. RIA Services).

Andere Dinge muss man sich ansehen. Bzgl. Drawing war es ja bei Silverlight auch so, dass man zunächst nicht so arbeiten konnte wie aus GDI+ gewohnt und halt einen VisualTree basteln musste um den dann in einer WritableBitmap zu rendern. Da gibt es jedoch zumindest für Silverlight abhilfe in Form von Libraries mit Extension Methods die einer WritableBitmap die Methoden hinzufügen die man aus GDI+ kennt und das halt im Hintergrund auf den neuen Weg umbiegen.

Wenn ich mir das so durchsehe sieht es stark danach aus als würde WinRT featuretechnisch irgendwo zwischen Silverlight 4 und WPF stecken (einiges was in WPF geht, geht ja in Silverlight nicht - ich vermute mal dass da vor allem Resourcenintensive Dinge weggefallen sind was Trigger, etc. betrifft).

Davon ausgehend, dass es aber doch etliche LoB-Anwendungen in Silverlight gibt würde ich daraus nicht ableiten dass es mit WinRT nicht möglich wäre sinnvolle LoB-Anwendungen zu entwickeln.

Ich denke (oder hoffe vorallem), dass Metro auf x86/x64 nie exclusiv wird und wir weiterhin (auch nach Windows 8) Desktop Programme sehen werden. Nicht nur die technischen Möglichkeiten, sondern vor allem auch die Darstellung in der klassischen Fensteransicht ist für bestimmte Zwecke einfach geeigneter (hatte Gestern z.B. wieder mal mehrere Liveticker nebeneinander laufen). Wenn also Desktop Programme bleiben, dann finde ich es sehr schade, dass die nicht auf die Charm Bar Funktionen zugreifen und keine Daten mit Metro Apps austauschen können. Ebenso schade finde ich es, dass sie keine Livetiles haben können, das wäre bei der einen oder anderen Anwendung sicher toll.

Wenn Microsoft WinRT nicht so beschränken würde dann könnte das durchaus was werden.
Aber Sie verstehen derzeit nicht wirklich das beste aus beiden Welten zu vereinen.

Mit Silverlight 5 war Micrsoft auf dem Sprung zu einer echten offenen Lösung die auch aus der Sandbox ausbrechen kann.
Zumindest wenn es als OOB (Out of Browser Anwendung) genutzt wird.

Wir haben derzeit ein relativ großes Projekt als Silverlight Frontend realisiert. Mit einem Ruby Backend.
Gründe die derzeit gegen HTML sprechen sind einfach die Browser Hölle. Viele unserer Kunden setzten noch Windows XP ein. Da geht garnichts mit HTML 5. Wir sind dank Json aber offen für alle Neuen Frontends sobald die wirklich gut laufen und die Zielplatformen das unterstützen.

Das schlimme an WinRT ist, das es eben nicht zwischen WPF und Silverlight anzusiedeln ist. Es ist total neu und kann vieles aus beiden Welten nicht abbilden. Wie gesagt derzeit. Und es ist leider Windows only. Wir müssen aber auch viele Kunden mit Mac only Clients beglücken. :)

Naja, das Problem hast du ja auch mit .net, das ist auch Windows onley. Aber bei WinRT kommt natürlich hinzu, das es Win8 onley ist, du Haus ein Problem. Dafür soll es sich aber leicht für Windows Phone portieren lassen, ist aber nur ein schwacher Trost.
Wirklich Platformübergreifend geht eben nur im Browser, aber wenn du da auf Plugins setzt schränkst du das auch wieder ein. Gibt's wirklich keinen HTML 5 Browser für XP? Kann der Firefox das nicht?

Mit der kostenlosen PocketPC.ch App von meinem TITAN X310e aus geschrieben.

Das Problem mit den Browsern und HTML5 ist, das selbst einfachste HTML5 Funktionen in jedem Browser der behauptet es zu können unterschiedlich aussehen. Das nächste Problem mit HTML5 ist die sehr unterschiedliche Performance bei JavaScript.
Das zum einen. Zum anderen gibt es nicht wirklich gute Entwicklungsumgebungen die es erlauben Programme und keine Websiten zu erstellen. Unser Frontend ist recht komplex und arbeitet mit vielen Listen und Tabellen.

Klar könnte ich einen Firefox oder Chrome auf ein XP installieren. Das erzähle aber mal bitte den Admins in großen Firmen. Die wollen die Software ausrollen und pflegen. Außerdem sind die ganzen Home Browser raus, weil viel zu schnell ungefragte Updates kommen. Welche im übrigen wirklich dafür sorgen das eine erstellte Anwendug die im Firefox oder Chrome x.1 läuft in Version x.2 nicht mehr läuft. Nächster Punkt ist, das viele Firmen Content Firewalls haben. Das sorgt regelmäßig dafür, das Java Scripts nicht ausgeführt werden.
Wir haben bisher ein HTML frontend. Wir haben uns bewußt für ein Plug in entschieden, weil es die Probleme minimiert.
Einmal erstellt läuft es nahezu wartungsfrei. Keine Unsicherheit bei einem evtl. Browser Update. Natürlich müssen wir auch hier einen Admin bitten das Plug in zu installieren. Das ist in der Windows Welt aber einfach weil.

1. Es kommt von Microsoft
2. Es läßt sich via Group Policies verteilen und warten.
3. Es gibt Sicherheitsupdates.

Einmal installiert läuft es auf nahezu 100% unser anvisierten Kundenplatform.
Tablets und Phones spielen dabei derzeit überhaupt keine Rolle.
Auf Windows 8 müssen wir bei unseren Kunden noch 8 - 10 Jahre warten :)


PS: Ein wirklicher Schritt von Microsoft wär es gewesen, wenn Sie WinRT als echtes Framework entwickelt hätten (Silverlight Reloaded V3 sozusagen). Als Installer lauffähig auf allen Windows Versionen bis runter zu Windows XP, auf Mac OS und auf einem großen Linux. Dann hätten sie mit ihrem Store Prinzip sogar einen echten Bonus. Weil dann würden die Leute mehrwert in der Entwicklung sehen.

Zitat:

---

Zitat von blau34

Zum anderen gibt es nicht wirklich gute Entwicklungsumgebungen die es erlauben Programme und keine Websiten zu erstellen.

---

Ich entwickle seit ca. 15 Jahren in Delphi und konnte mich aus den von dir genannten Gründen auch nie so recht für die Webentwicklung begeistern. Nun habe ich zum Glück ein Framework gefunden, das sich in Delphi integriert und mich zu ca. 97% so entwickeln lässt, wie ich das gewohnt bin. Auch unterschiedliche Browser bereiten i.d.R. keine Probleme. Nun bin ich glücklich: http://www.unigui.com ("Unified GUI for desktop and the Web", "Creates stateful Web applications", ...)

Schaue ich mir mal an. Derzeit bin ich vom Web geheilt und glücklich mit der Lösung die wir gebaut haben.
Das wichtigste war dabei der Feldtest mit Endkunden. Wir hatten vorab eine kleinen Teil unserer Anwendung (virtuelles Magazin) in Silverlight gebaut. Absolute begeisterung bei unserem Kunden und dem seine Kunden.

Ich warte da noch ein paar Jahre und schaue was es dann gibt.

Na ja, ich vergleiche WinRT und Silverlight auch eher in der Hinsicht, dass halt beide mit sehr ähnlichen technischen Konzepten arbeiten (so wie auch WPF und Silverlight (hieß ja mal WPF/E) - insofern kann man da einiges an Know-How mitnehmen.

Dass aber WinRT kein Silverlight-Ersatz ist, in dem Sinne, dass man es statt Silverlight einsetzen könnte ist ein anderes Thema. Silverlight ist in erster Linie eine RIA-Technologie gewesen, während WinRT klassisch zu Anwendungsprogrammierung gedacht ist. Was auch immer der Hintergrund ist wieso sich eine ganze Branche von RIAs abwendet (nämlich auch die RIA-Hersteller Microsoft und Adobe wäre mal eine interessante Frage).

Zu HTML5 derweil nur soviel, dass man relativ viel machen kann, da es einige Libraries gibt, die die Unzulänglichkeiten so manchen Browsers ausgleichen. Leider geht das nur beschränkt und gerade im Firmenumfeld hat man sich oft mit alten Versionen des IE zu beschäftigen. Die Sache mit den Libraries ist aber dass sie letzten Endes eben halt versteckte Workarounds sind und man sich dann doch oft damit beschäftigt wie man jetzt was zum laufen kriegt anstatt wie bei RIAs sich auf die Umsetzung des eigentlichen Projekts konzentrieren zu können.

Web-basierte Lösungen haben halt für Firmen oft den Vorteil des einfachen Deployments. Auf dem WebServer installiert, Windows Auth und wenn dann noch das Silverlight-Plugin auf den Clients ist, ist das quasi alles was nötig ist (kein installieren von x Anwendungen auf allen möglichen Maschinen).

Nichts destotrotz glaube ich durchaus, dass man brauchbare Anwendungen für den Business-Bereich mit der WinRT erstellen kann. Das WebService zwischen DB und Anwendung ist ja mit den RIA-Services mit endlichem Aufwand zu erstellen und bzgl. Visualisierung wird alles was nicht zum Release im Framework steckt (Charting-Controls sind da ein Klassiker) wohl rasch von Infragistics, DevExpress, usw. nachgeliefert werden (wie immer halt).

Hier mal eine Antwort von Pete Brown zu diesen Thema in seinem Blog zur Release Preview.

"Friday, June 01, 2012 at 2:52:22 PM

@sip

For sure, this release is more targeted towards the consumer side. There are LOB features, but those don't appear to be the primary scenarios.

I don't deal with marketing/licensing, but I suspect many companies who just upgraded to Win7 won't be looking at Win8 (or the ones after that) for quite some time.

Silverlight on the desktop is just as good in Win8 as it is in Win7 or even XP. Same with WPF, Windows Forms, and many other technologies. ** We didn't take anything away in Windows 8 **. In fact, for developers, we even added some things: Visual Studio 2012 comes with the Silverlight 5 tools pre-installed.

I'm not disagreeing with the need for more LOB features in Metro, though, trust me. I agree that Metro doesn't have the same types of APIs available, so it may not be a fit for many of the the same scenarios.

Pete"

Zu finden hier http://10rem.net/blog/2012/05/31/win...studio-2012-rc

Sagt eigentlich alles.