UWP tot oder nicht? Bekannter Entwickler äußert sich zum aktuellen Stand

UWP tot oder nicht? Bekannter Entwickler äußert sich zum aktuellen Stand

In Anlehnung an einen berühmten TV-Spot könnte man diesen Beitrag prima mit dem Satz „Die Geschichte von UWP ist eine Geschichte voller Missverständnisse“ beginnen. Man würde damit voll ins Schwarze treffen, denn es sprechen sehr Viele darüber, nur Wenige wissen aber wirklich, wovon sie sprechen. Und um das gleich mal klarzustellen: Ich zähle mich ebenfalls eher zur zweiten Gruppe.

Das liegt einerseits daran, dass ich kein Entwickler bin, andererseits hat es Microsoft mir und allen anderen, die sich bemühen, den Begriff UWP richtig zu verstehen, alles andere als leicht gemacht. Nicht selten konnte man zuletzt lesen: UWP ist tot. Ich glaube, ich habe das sogar selbst schon so gesagt, das aber immer mit einem Untertitel versehen: Tot ist die Vision, die uns Microsoft einst zusammen mit UWP verkauft hat. Die Plattform als solche ist ein elementarer Bestandteil von Windows 10 und kann daher gar nicht „tot“ sein, allerdings ist es fraglich, welche Relevanz sie in Zukunft noch haben wird.

Nun hat sich der bekannte Entwickler Rudy Huyn zu Wort gemeldet, der vor allen Dingen zu Zeiten von Windows Phone so etwas wie ein Rockstar in der Community war. Er lieferte viele inoffizielle Apps zum Beispiel für Tinder und Instagram und verkörperte dadurch das „Lebensgefühl Windows Phone“: Kleine Guerillas im Kampf gegen die Ignoranz der Mächtigen.

Wer der englischen Sprache mächtig ist, der kann hier abbrechen und den Artikel „What is UWP in 2019?“ auf Rudys Blog lesen. Ich würde ihn gar als Pflichtlektüre bezeichnen, wenn man sich intensiv für die Windows-Plattform interessiert. Er schafft es, viele Dinge klarzustellen, ohne dabei aber jemanden anzugehen.

In dem Beitrag wird die klare Vision beschrieben, die Microsoft einst für UWP hatte: Apps, die auf allen Geräten gleich aussehen, gleich funktionieren und aus dem Microsoft Store kommen. Daran konnte man nichts falsch verstehen. Dann aber begann die Marketing-Maschinerie in Redmond alles Mögliche mit UWP zu verknüpfen, auch wenn das völlig unsinnig war. Das populärste Beispiel ist die Desktop Bridge. Sobald eine klassische Applikation im Store landete, bekam sie den UWP-Stempel aufgedrückt, weil sie ja ein paar Elemente dieser Plattform nutzte. Rudy Huyn vergleicht das mit dem Toyota Prius: Diesen als Elektro-Fahrzeug zu bezeichnen, weil ein kleiner Elektromotor verbaut ist, der den mit Benzin betriebenen Hauptantrieb unterstützt, wäre sicher nicht zielführend.

Ein weiteres Missverständnis hinsichtlich UWP ist, dass viele Nutzer damit in erster Linie den Gedanken „sieht überall gleich aus“ verbinden. Genau das ist es aber nicht. UWP ist alles, nur nicht Oberfläche. Die muss weiterhin dediziert für jedes Endgerät gebaut werden. Man kann den Leuten das nicht verübeln, man kann auch Microsoft nicht die Schuld daran geben. Das ist einfach so passiert, und wäre der Plan aufgegangen, dann hätte es ja auch niemand bemerkt.

Einfacher zu verstehen wird UWP auch in Zukunft nicht, denn es gibt kein charakteristisches Merkmal, das eine Universal App ausmacht – außer dem Umstand, dass sie grundsätzlich vom PC über Surface Hub und HoloLens bis hin zur Xbox auf alle Geräte gebracht werden kann.

UWP ist als Überbegriff für alle Bemühungen von Microsoft zu sehen, die Basis für moderne Applikationen zu legen, von .Net 5 über XAML und das gute alte Win32 sowie das noch junge Paketformat MSIX. Meiner Meinung nach wäre es an der Zeit , „UWP“ tatsächlich sterben zu lassen – und zwar als Begriff. Er steht, wie in der Einleitung schon geschrieben, für eine Geschichte voller Missverständnisse. Die ursprüngliche Idee und der aktuelle Status haben so gut wie nichts mehr miteinander zu tun, daher können die Diskussionen, ob UWP tot ist oder nicht, niemals zu einem Ergebnis führen, denn irgendwie haben alle Beteiligten immer Recht.

Über den Autor
Martin Geuß
  • Martin Geuß auf Facebook
  • Martin Geuß auf Twitter
Ich bin Martin Geuß, und wie unschwer zu erkennen ist, fühle ich mich in der Windows-Welt zu Hause. Seit mehr als zwölf Jahren lasse ich die Welt an dem teilhaben, was mir zu Windows und anderen Microsoft-Produkten durch den Kopf geht, und manchmal ist das sogar interessant. Das wichtigste Motto meiner Arbeit lautet: Von mir - für Euch!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.



Kommentare
  1. die UWP war wohl einer der besten Ideen von MS. Nur ist der Konzern und sein Windows dafür nicht stabil genug. MS schlägt gefühlt jede Woche eine Andere Richtung ein und Windows ist völlig fragmentiert. Auf jedem PC ein anderes Verhalten z.B. bei den Benachrichtigungen, den Apps , in der Foto App z.B. heißen die Kontakte auf dem einem System Personen, auf dem anderem Kontakte, völlig unterschiedliches Suchverhalten usw. Damit kann KEIN Entwickler umgehen.
    Bislang war ich ja nur ein passiver Leser, aber jetzt muss ich doch mal aktiv werden.
    Seit UWP verfügbar ist, erstelle ich Apps ausschliesslich damit. UWP ist für mich das Framework aus .NET Core und Xaml und ich kann damit wunderbar umgehen.
    Beruflich bin ich Web-Entwickler und muss mich da leider mit HTML und Javascript abgeben und daher weiss ich, dass UWP die beste Plattform ist um Apps auf einfache Art zu entwicklen. Z.B. verwende ich UWP auch zum Prototyping. Die UI ist mit XAML sehr schnell erledigt, das geht teilweise in Minuten, der Code ist keine Problem dank .Net Core. In HTML ist das dann eine andere Sache und wirft einen vor Problemen was daran liegt, dass HTML eine textorientierte Oberflächenspezifikation ist, wärend Xaml wie viele andere UI-Sprachen Layoutorientiert ist. Und dann ist da dieses Javascript bzw. TypeScript! Auch Oberflächen in Android sind einfacher als HTML, wobei zwischen Android und Xaml auch wieder welten liegen. Bei Android beispielsweise benötigt man Adapter was bei Xaml implizit durch Binding geht. UWP Anwendungen werden noch dazu native kompiliert und nicht etwa wie bei WPF virtualisiert. Gegenüber WPF hat UWP auch noch den Vorteil, das es jünger und moderner ist, und man damit viel coolere UI's erstellen kann. Als Beispiel nenne ich mal Acrylic oder Transitions.
    Für mich ist UWP die beste Plattform um Anwendungen zu entwicklen, sofern sie nicht zwingend als Webseiten agieren müssen. Auch Progressive Web Apps können das nicht ändern, denn die sind im Prinzip nichts anderes als Webseiten, deren Inhalte (HTML, CSS, Javascript, Images, etc.) bei bedarf lokal gecached werden. Man hat immer noch das Problem mit HTML und Javascript (Javascript ist für mich und viele Entwickler mit denen ich mich unterhalte keine Programmiersprache sonderen eine Beleidigung). Auch WebAssembly wird das nicht ändern. Überhaupt stellt sich die Frage auf PWA für Hobbyprogrammierer erst gar nicht. Im Gegensatz zu UWP müssen diese erst mal auf einem Server gehostet werden.
    Ich finde das größte Problem was die Windows 10 Apps haben ist, das der MS Store für den Desktop so desaströs ist. Als Entwickler finde ich es beschämend, was für einen Schrott MS den Kunden vor die Nase setzt und das sich nach mittlerweile vier Jahren einfach nichts tut. Ich finde es sehr interessant, wie sich die App-Plattform weiterentwickelt, aber damit sich die Situation verbessert, muss der MS Store einfach weg und durch etwas besseres ersetzt werden, sei es eine gute React Native Anwendung.
    UWP Developer, da muss ich dir auch voll zustimmen. Ich habe eine Zeitlang Webanwendungen mit JSP's auf Eclipse entwickelt und das ist im Vergleich zu UWP's eine Katastrophe.
    Allein C# gegenüber Java, Visual Studio gegenüber Eclipse und XAML gegenüber HTML sind um Welten besser.
    Ich habe als Entwickler alle Techniken durch - Forms, WPF, UWP und jetzt WPF mit .net Core. Für mich ist UWP das mit Abstand einfachste und am schönsten zu programmierende. Leider fehlen UWP einige essentielle Wpf Techniken wie Trigger und die Sandbox ist auch oft echt ein Hindernis für LOB Anwendungen, aber ich habe meine Wege und meinen Frieden gefunden und hoffe, dass sich UWP und WPF irgendwie annähern und idealerweise vereinheitlichen. Man kann ja noch träumen. Aber Microsoft hat eine miese Kommunikation diesbezüglich, was es Entwicklern nicht leicht macht. Man muss schließlich längerfristig planen können im Unternehmensumfeld.
    UWP ist eigentlich eine tolle Sache und sollte die Zukunft von Windows sein.
    "Eigentlich" - weil die bevorzugte Sprache C# halt nur bedingt zum Schreiben von GUI Applikationen tauglich ist (automatische Garbage Collection) und zum andern weil schlichtweg jede Menge GUI-Element fehlen oder Funktionialitaet fehlt.
    Anscheinend steckt da ein Prinzip bei Microsoft hinter: etwas Neues wird gepusht und wenn es "da ist" - dann landet es auf den Haufen der unvollendeten Projekte und wird auf Sparflamme weiterbetrieben.
    Der Store den die meisten bemaengeln ist dabei ueberhaupt gar kein Problem - das Problem ist das es zu wenig richtig richtig gute UWP Apps gibt wegen denen man den Store ueberhaupt aufrufen wuerde.
    Und das es die nicht gibt liegt halt an dem eigentlich unnoetigen Aufwand den die Programmierer bei UWP betreiben muessen. Da hat Microsoft einfach die falschen Prioritaeten gesetzt.
    Wuerde UWP so energisch vorangetrieben wie z.B. das OpenSource Projekt Visual Studio Code - UWP waere heute fantastisch, sowohl fuer die Entwickler und somit auch fuer die Anwender.
    Für mich stellt sich die Frage wen ich erreichen kann. UWP läuft nicht auf Android und iPhone. Da kann die Entwicklungsplattform noch so angenehm zu verwenden sein. Ich setze auf PWA Angular (Material).
    Ich entwickle von Berufswegen immer wieder mal UWP Apps. Ich entwickle auch auf nativ Android und hatte vor einigen Jahren auch einiges mit iOS gemacht.
    UWP ist und bleibt, auch vor WPF und MonoNet, für mich das schönste und stringenteste zum Entwickeln.
    Wie UWPDeveloper schon geschrieben hat... alleine das Prototyping geht so schön schnell und einfach.
    Allerdings muss MS wirklich den Kreis schließen wenn sie 2020 .NET5 geradeziehen wollen.
    UWP muss dringend einige Dinge bekommen, die man nur schwer ohne work/hackarounds von WPF bspw. her kennt, bzw. gewohnt ist.
    Hautpsächlich machen wir auf Windows-BAsis LOB für spezielle Einsatzzwecke (Events, Shows, Installationen, TouchTerminals) und wenn es geht, verwenden wir UWP. Allerdings klappt das nicht immer, vor allem wenn man schnell zu einem Ziel kommen soll und andere Technische Komponenten hat, wie Sensorik, POS Drucker, Scanner etc. ... ja, es wird besser in diesem Bereich, aber es fehlt einfach noch zu viel. Da muss ich dann manchmal schmerzlich entscheiden auf WPF oder Unity/MonoNet zu gehen (je nach Anforderung) - oder eben auf Android.
    Wäre schön wenn so manche Limitierungen fallen würden.
    Ich hoffe das UWP - egal unter welchen Namen - erhalten bleibt und erwachsen wird.
    Ach ja.. und der Store. Ich habe auch privat eine App im Store - und es wirklich grausam wie schlecht man gefunden werden kann.
    Ich dachte, UWP wäre ein Waschmittel oder Brotaufstrich. Es ist aber anscheinend eine proprietäre "Workbench". ;) Meinetwegen... den Nutzern von Geräten kann das wohl völlig egal sein. Es wäre natürlich schön, wenn die erstellte Software ressourcenschonend und robust wäre. Dann würde ich aber eher Assembler bevorzugen.
    UWP scheint mir wohl eher quick and dirty, oder?
    @kurz: UWP hat einen ueblen Design-Kardinalfehler - es ist nur sekundaer eine Loesung eines Programmierproblems. Primaer stellt die derzeitige Implementation die Loesung eines Hierachieproblems bei Microsoft da.
    Denn man hat UWP dazu "verdonnert" die Windows-APIs und vor allem Objekte zu benutzen.
    Das heisst ganz konkret: wenn man in UWP einen Button im Fenster anlegt, so wird in Wirklichkeit ein zweites Objekt in Windows (also nicht UWP) angelegt das dann dieser Button im Fenster "wirklich" ist.
    Diese Designentscheidung ist so tiefgreifend das UWP in dieser Form im Prinzip komplett "vermurkst" ist - nicht nur was das Thema resourcenschonend angeht.
    Die einzige Loesung waere da ein "Windows Lite" das UWP von diesen Fesseln befreit...
    @kurz @miine
    Hmm.. habt ihr wirklich ernsthaft mal damit gearbeitet? Ich finde es extrem robust und ressourcenschonend. UI Animationen sind superflüssig, GPU supported - und ich habe im Vergleich zu anderen Konstrukten einen minimalen Memory Footprint (man sollte natürlich auch entsprechend sowieso ein auge auf memory management haben).
    Schön ist auch eine Integration mit Win2d wenn man es etwas weiterspinnt und damit auch den Zugriff auf HLSL Shader etc. Also da geht schon einiges.
    Edit: Mir geht's beispielsweise andersrum.. wenn ich mal wieder in WPF oder MonoNet lande krieg ich fast schon Stresspickel ;) Ich bete für einen gelungenen .NET 5 Start 2020.
    Für mich war es UWP immer, 1. wenns ausm Store kam und mindestens auf 2 Plattformen von Windows lief^^ bzw per Maus nutzbar war oder mit Touch. Das wäre meine Definition gewesen dazu^^
    Also ich als bescheidener Hobbyprogrammierer bin von UWP(XAML + C#) auch begeistert. Es ist wirklich super einfach zu erlernen (Grundlagen) und hat eine gute Dokumentation. Es ist wirklich schade, dass die Plattform keinen Anklang findet. Aber ich sehe leider nicht, wie hier das Ruder nich rumgerissen werden könnte.
    @SeriousGeorge: ja habe ich. Sind wird mal ehrlich: C# ist Microsofts Java. Und Java wurde geschaffen um die uebelsten und haeufigsten Programmierfehler in C++ bereits durch die Sprachdefinition zu verhindern. Sprich: "betreutes Programmieren".
    Wie "fluessig" Sachen in UWP/C# laufen? Vergleich das mal mit Objective-C in iOS oder MacOS. Z.b. wenn man eine lange Liste scrollt. Das sind Welten dazwischen.
    Das ist auch kein Wunder: denn nicht nur ist Objective-C vom Syntax her genial, die Runtime ist es auch.
    Wo der Programmierer weniger betreut ist kann er dafuer aber dann auch wesentlich mehr Optimieren.
    Bei Businesslogic ist das natuerlich nicht nur wurscht sondern eher unerwuenscht - im Zweifelsfall muss der Anwender entweder warten oder eine schnellere Kiste kaufen. Bei GUI-Apps sieht es ganz anders aus, insbesondere im Mobilen Bereich.
    -
    Das was NeXT mit NextStep 1986 an Frameworks in Objective-C geschaffen
    hat, das wird heute noch eigentlich unveraendert (!!) in iOS und MacOS benutzt. Weil es so gut ist das man nichts anderes brauchte.
    Das Apple neuerdings Swift "pusht" um den Java/Javascriptlern beim Syntax entgegenzukommen - eigentlich eine Schande.
    -
    UWP ist hervorragend auf einen Fall ausgerichtet: man hat Businesslogic in "Managed Code" vorliegen und will daran ein GUI "klatschen". So sieht es dann auch aus. Z.b. wie die Kontakte-, Kalender- oder Mail-App von Microsoft. Und das sind noch die "gelungenen" Beispiele.
    -
    Kann man das Microsoft "vorwerfen"? Als Businesskunde ist man da ja gut aufgehoben. Als Consumer oder jemand der die als Zielgruppe hat - aber sowas von.
    @Mamagotchi: ich koennte Dir detailiert beschreiben wie man das Ruder rumreissen koennte. Das koennen bestimmt was die "technische Seite" angeht auch jede Menge Leute bei Microsoft sagen. Nur mit der "Umsetzbarkeit" in Bezug auf "Firmenpolitik" - wie man DA das Ruder rumreissen kann, dass wissen wohl nur die Goetter...
    @Miine: Das mit dem Button und dem zweiten Objekt ist totaler Quatsch. Falls Du Dich auf visual tree und logical tree beziehst, dann ist das was ganz anderes als wofür Du es hältst und gehört zum Design-Konzept von XAML und ist mitnichten eine Abhängigkeit zu irgendwas von Windows. Auf alle Fälle hat ein Button in UWP/XAML null mit irgendeinem Button in Win32 oder sonstwas von Windows zu tun.
    Ebenso ist UWP eben nicht mehr "managed code", denn Store-Apps kommen dank .NET Native wunderbar ohne Bytecode aus.
    Eine gelungene Zusammenfassung zum Thema UWP, hier auf Dr. Windows!
    Habe Windows 10 Mobile immer als sehr wichtiges Element in der Gesamtheit aller Windows 10 Plattformen gesehen. Grosser Verlust.
    @DonRolando: was glaubst Du denn warum es bei den UWP-UI Objekten keine "Draw" Methode gibt die man z.B. selbst implementieren könnte? Gehört das zum Design-Konzept oder liegt das eher daran, dass da ein zweites Objekt im Hintergrund ist das man eben nur über Parameter aber nicht Klassenänderungen/vererbung beeinflussen kann?
    Und nur mal so: Das was da im Hintergrund werkelt, das ist NICHT in C# geschrieben. Womit man dann bei Callbacks z.B. durch das ListView-Hintergrundobjekt lustige Memory-Leaks einhandelt wenn man es nicht 110%ig genau so macht wie es Microsoft sich denkt. Denn alle anderen Fälle wurden von denen schlichtweg nicht codiert *... Gut - man könnte das ja explizit dokumentieren, aber wozu?
    -
    Das die Kombination von HTML/CSS/JS im Vergleich zu XAML geradezu "elegant" erscheint ist dann nochmal ein ganz anderes Thema.
    -
    Ob nun "managed code" in der IL vorliegt oder nicht, abgesehen davon das Du dir das einmalige compilieren sparst - wo soll der grosse Unterschied sein? Es ist weiterhim eine Managed Code Runtime die benutzt wird.
    Ich bin da sogar für IL: mit native Code verbaut man sich da unnötig zukünftige Optionen..
    -
    *) wer da Zweifel an der Qualität der Bridge zwischen C# und C++ o.ä hat - zu Recht! Es ist da sogar eher ein Wunder das es überhaupt so gut funktioniert...
    @Miini: Ich will gar nicht hier den üblichen Stellvertreterkrieg der Plattformen ausbreiten. Ich habe sehr früh mit Objective-C gearbeitet und fand es super. Immer noch eine tolle Plattform. Swift ist bestimmt ein richtiger und konsequenter Schritt, auch wenn das nicht mehr aktiv mitbekommen habe.
    Anrdoid und Java.. ist.. uh.. naja. Kotlin ist auch ein konsequenter Schritt und viiel besser zu entwickeln - was ich auch beides verwende. Aber meiner Meinung nach immer noch nicht on par mit C#. Alle haben ihre Vor- und Nachteile. C# mit Java zu Vergleichen ist... naja... Ketzerei? :)
    Um den Bogen zu UWP zurückzuspannen... wie gesagt, ich finde es leicht da schnell Fluide Applikationen zu entwickeln. Und keine 0815, sondern auch anspruchsvollere Sachen. Und ja.. für Mobile Wp7 und Wp8.x hab ich auch entwickelt - auch als Wp7 noch Alpha und nicht publik war. Wir haben auch auf sehr lowlevel Hardware mit Unity und 3D UWP Builds laufen lassen die sehr gut gelaufen sind und haben parallel das ganze mit Android auf vergleichbarer Hardware gemacht. Da schnitt UWP besser ab und hat in dem Fall dann auch den Vorrang gehabt (wie ich aber vorher schon sagte.. ist das nicht immer so. Dann gewinnt halt die andere Plattform den Zuschlag für das Projekt).
    Also.. Apps mit UI Fokus auf UWP performancetechnisch zu versemmeln... da gehört meiner Meinung nach schon viel dazu :)
    Da ist das Listenbeispiel ja wunderbar... eine Adaptive Gridview mit Semantic Zoom (ja, ist schon wieder out) und zig Databindings mit Convertern, Animationen und haste nicht gesehen läuft 1a... das ganze auf Android - kann flüssig laufen, wenn man's richtig macht - ansonsten kann das dort auch schnell mal nen Bottleneck geben.
    Aber darum geht's ja eigentlich gar nicht. Ist UWP tot oder nicht? Ja, bezogen auf das originäre UWP App-Konzept. Nein, punkto Zukunft. Die Weichen sind längst gestellt worden. UWP wird wohl als Begriff sterben und MS nächstes Jahr mit .NET 5 einen anderen Marketing-Begriff aus dem Hut zaubern. Aber wenn Sie es schaffen, das mit "UWP" und .NET 5 dann das ganze nativ an WPF, WinForms etc. durch die dann neue WinUI-Komponente/Framework durchvererbt wird, ist das doch eine wunderbare Basis für alle. Dann mach ich WPF mit schicker und flüssiger UI oder ich mach eine native Windows 10 App - wie ich's halt brauch. Win/Win für alle.
    Das wäre meine Wunschvorstellung - evtl. träum ich da aber auch nur ;)
    Was eine UWP-App ist, ist für mich als Entwickler ziemlich klar. Es ist das was ich bekomme, wenn ich den Visual Studio-Compiler anwerfe und eine App für die Zielplattform UWP auswähle. Am angenehmsten ist mit dann C#. In C# durfte ich schon das eine oder andere Programm schreiben, leider als EXE und nicht als UWP. Beruflich bin ich leider immer noch an Windows Forms gebunden, obwohl die Plattform schon uralt ist. Von daher wäre mir XAML bzw. UWP lieber. Leider kenne ich für UWP keine - bevorzuge deutschsprachige Dokumentation - welche ich als gut bezeichnen würde. So bin ich bisher beim Hamburger-Button stecken geblieben. Insgesamt finde ich die UWP-Plattform trotzdem höchst interessant, vor allem wenn man sieht was man daraus machen kann, wenn man UWP richtig beherrscht. Da gibt es im Store so einige positive Beispiele.
    @Miini: "was glaubst Du denn warum es bei den UWP-UI Objekten keine "Draw" Methode gibt die man z.B. selbst implementieren könnte? Gehört das zum Design-Konzept oder liegt das eher daran..."
    -> Einfach mal nach "retained mode" googlen. Das ist tatsächlich Design-Konzept! Draw-Methoden findest Du bei "immediate mode" APIs. Auf den Rest brauch ich dann gar nicht weiter eingehen, das hat null damit zu tun, dass da weiterhin alte Windows-Objekte im Hintergrund laufen.
    -> Und wenn Du nach .NET Native kompilierst ist da keine managed code runtime im Spiel. Schon bemerkt, dass man UWP auch mit C++ und den selben UWP APIs entwickeln kann? Da kommt auch kein managed C++/CLI Code bei raus.
    Aber bringt nix zu diskutieren, Du willst Deine Annahmen als Fakt glauben. Bring mal Quellen für Deine "alte Windows Objekte im Hintergrund"-Theorie (mist, solche Quellen kanns ja gar nicht geben, sowas aber auch :D), ansonsten bin ich erstmal raus. ;)
    @DonRolando: ich lerne ja gerne dazu. Wenn also ein C# Objekt z.B. aus dem Windows.UI.Xaml.Controls namespace nicht ein zweites C++ Objekt im Hintergrund repraesentiert, wie funktioniert das denn dann? Ist ein C# Objekt in Wirklichkeit in C++ Objekt und kann somit ohne Performanceverlust von beiden Welten benutzt werden?
    @Miine: Das hat gar nichts mit C++ oder C# zu tun.
    Ohne jetzt hier den Umfang zu sprengen in vereinfachter Form: XAML bietet eine Menge visueller Elemente, welche dann wie in einem Baukasten beliebig zusammengestöpselt werden können. Ein Control bedient sich dann solcher Elemente (oder auch anderer Controls), um seine Darstellung zu beschreiben.
    Retained Mode bedeutet in dem Zusammenhang, dass man nur beschreibt wie etwas aussehen soll, das UI-Framework sich aber um das Rendering kümmert. Das ist vergleichbar mit einem Szenegraphen bei 3D-Anwendungen.
    Daher rufst Du niemals eine Draw-Methode auf, denn im konkreten Fall kümmert sich eben die Universal Plattform darum, dass stets das notwendige Delta gerendert wird, wenn Du irgendwelche Eigenschaften in dieser Szene änderst.
    Bei UWP ist das ein komplett neuer UI-Stack der nativ und hardwarebeschleunigt läuft, der aber fest in Windows 10 verankert ist und auch erst dafür entwickelt wurde. Also alles andere als eine Altlast. Dieser Stack kann aus allen möglichen Technologien (managed, unmanaged, web) heraus benutzt werden. Und UWP Apps werden für den Store wie gesagt i.d.R. mit .NET Native ebenfalls nach unmanaged kompiliert... tut aber dafür gar nichts zur Sache. (Zum Vergleich: XAML mit dem guten alten WPF fühlt sich zwar sehr ähnlich an, da ist tatsächlich alles managed code, selbst große Teile des UI Stacks. Die Performance ist hier signifikant schlechter.)
    Wie dem auch sei, wenn Du einen Button hast, lebt der ganz normal in Deiner UWP Anwendung und besteht aus Code und eben der Komposition seiner visuellen Elemente. Und Windows respektive die Universal Plattform kümmert sich darum, dass die visuelle Komposition gerendert wird und aktuell bleibt. Dass das Teil aber ein Button ist, das ist Windows/UWP relativ egal.
    Mit den XAML Islands werden übrigens die alten Windows Technologien (Win32, WPF, WinForms) ertüchtigt von diesem modernen System Gebrauch zu machen. Das ist (derzeit) natürlich ein Technologie-Bruch.
    Hoffe das war so im Schnellabriss dennoch halbwegs verständlich. :)
    Für ein Prozent ist das korrekt. Die restlichen 99 Prozent interessieren all diese Begriffe viel zu wenig, als dass sie sich diese Frage überhaupt stellen würden. Genau so ist das auch vollkommen korrekt. Wenn eine App nützlich ist, ist sie nützlich, wenn sie Schrott ist, ist sie Schrott. Ob das nun UWP, PWA, MFG oder ADAC ist - wen juckt das schon?
    UWP bedeutet für mich vor allem beschränkte Programme. Der Zugriff auf viele Teile des Systems ist virtualisiert oder verboten. Damit sind viele Programme unmöglich. Quasi alles was MS nicht vorgesehen hat. Das genaue Gegenteil der ursprünglichen Flexibilität von Windows.
    Optisch sind die meisten Programme für den Desktop ein Grauen. Funktional reduziert und optisch total inkompatibel zur Win32 Welt.
    @Nordlicht2112 / Martin: Dann gehöre ich wohl nach der Rechnung zum 101. Prozent. Ich finde UWP-Apps einfach super. Die Teile sind im positiven Sinne der reine Wahnsinn, vorausgesetzt natürlich sie sind gut programmiert. Wenn ich das richtig sehe sind viele System-Apps UWP-Apps, z.B. Groove Musik, Film & TV, ToDo, Mail, und und und. Sogar die sehr übersichtlich gelungene Einstellungs-App. Auch Apps welche nicht von Microsoft stammen sind hier zu nennen, wie z.B. der Birthday Hub oder Meine Mediathek. Die von mir genannten Apps zeichnen sich dadurch aus, dass sie gut zu bedienen sind und exakt das machen was sie sollen. Von mir aus könnten alles Programme unter Windows UWP-Apps sein, jedenfalls was das Design und die Bedienung betrifft.
    @ntoskrnl: Das UWP-Apps beschränkte Programme sind kann ich nicht erkennen. Natürlich kann es Ausnahmen geben. Wen man z.B. die Office-Apps mit Office 365 vergleicht, dann schon. Die o.g. Programme dagegen sehe ich in keinster Weiße als Beschränkt an, im Gegenteil. Optisch inkompatibel zur Win32-Welt sind sie sicherlich. Allerdings ist die Win32-Welt auch ein veraltetes Fossil. Leider versucht Microsoft zu allem möglichen kompatibel zu bleiben. So muss ich z.B. beruflich noch mit Windows Forms programmieren (Personen, welche auch programmieren, werden das Disaster sicher nachvollziehen können.). Wäre schön, wenn Microsoft den Mut hätte den Uralt-Krempel endlich mal abzukündigen. Den Nachfolger XAML noch ein wenig aufpoliert und die Optik wäre durchgehend einigermaßen durchgängig. Oder noch besser eine neue universelle Designsprache, welche alle bisherigen vereinheitlicht.
    In dem Zusammenhang setze ich meine Hoffnung auf (Windows) lite an dem Microsoft wohl arbeitet. Da hoffe ich auf möglichst wenig Kompatibilität zu Windows Altlasten und hoffe, dass es auch keinen 32 Bit-Modus gibt, sondern alles durchgängig 64 Bit ist. Eine Ausnahme zur Kompatibilität muss ich aber machen. Das System wäre ohne Office 365 nicht komplett. Eine derartig mächtige Office-Suite braucht man dann schon.
    Weil man eine neue Basis für die Programme braucht. Hätte MS W10M anständig entwickelt, dann würden die Smartphones in der Verbreitung der UWAs mit reinspielen, haben sie aber nicht. Es ändert aber nichts daran, das es eine neue moderne Basis braucht und hierbei ist wie Martin richtig sagt, der Name einfach vollkommen egal.
    Mit UWP kannst du z.B. kein OpenGL nutzen und keine CD Laufwerke ansteuern.
    Systemtools sind ebenfalls unmöglich, z.B. ein Registryeditor.
    Daher waren und sind diese Programme nur 2. Klasse gegenüber Win32.
    Ich vermisse die UWPs. Habe damit unter anderem Kleine Anzeigen, Wodel und auch andere Dinge programmiert und es war faszinierend wie einfach das ging, was für schöne UIs dabei herauskamen und wie gut sich das zwischen Desktop und Mobile übertragen ließ. Und man musste nie zwei Benutzeroberflächen schreiben für die Bildschirmgrößen, man musste sie nur clever genug schreiben, sodass sie je nach Fenstergröße entsprechend angezeigt werden. Leider hat Mobile hier keine Relevanz mehr, ich hatte gehofft, dass hier Xamarin nach der Übernahme in die Lücke springt, was aber wohl nicht der Fall ist und meine Entscheidung nach dem UWP/W10M Dilemma bekräftigt hat, auf React Native zu setzen. Hat sicher seine Nachteile, als größten Javascript an sich, aber na ja schade drum, war schön.
Nach oben