Univerzális többplatformos UI keretrendszert fog kapni a .NET

Univerzális többplatformos UI keretrendszert fog kapni a .NET
2021-02-05T09:45:16+01:00
2021-02-07T14:10:57+01:00
2022-10-17T11:15:35+02:00
  • Az ördög mindig a részletekben rejlik. Az elõzõ projektünk amin dolgoztunk egy olyan 8 emberévnyi xamarinos projekt volt, elvben semmi extra csak mezei adatfelvitel/report, ami extra volt csak az, hogy lokálisan is kellett mûködjön és szinkronziálnia is kellett több szintre, plusz persze authentikáció/authorizáció és pár apróbb nyalánkság. De azért voltak benne szépen custom rendererek, mert a usernek elég határozott elképzelése volt arról, hogy mit és hogyan akar látni. Pluszban fontos volt az UWP, a xamarin forms-nak pedig vicces módon ez nem annyira az erõs oldala.
    Mutasd a teljes hozzászólást!
  • Viszont a programok 80%-ának nincsen szükségre többre, mint az alap vezérlők. Button, TextBox (egy és többsoros), ComboBox, talán menük, lista, TabControl, és egy lehetőség hogy berakd a saját kép-puffered (nem tudom erre mi a jó szó) egy vezérlőként. Ezzel az (asztali) program jó része bőven megelégszik. Tényleg kevés program van amit ezekkel ne lehetne megírni. Ezeknek is van egy nagyon egyértelmű feature-listája.
    Mutasd a teljes hozzászólást!
  • Nem egészen. Pl. C++ vonalon wrappel a wxWidgets, saját maga renderel Pl. a GTK, de szerintem a Qt is. Java vonalon saját maga renderel a swing, de wrappel az SWT amire az Eclipse épül. Mobil vonalon wrappel Pl. a Xamarin Forms, de saját maga renderel Pl. a Flutter.

    A wrappernek három nagy hátulütõje van: egyrészt minden platformmal külön meg kell szenvedni ha bármi egyedit is csinálni akarsz a beépített widgetek lehetõségein túl. Azaz csinálhatsz külön renderert droidra, UWP-re, IOS-re, ami elég jó móka tud lenni. A másik hátulütõ, hogy új platformra portolni elég nagy macera. A harmadik, hogy az egész pont olyan buta lesz, mint a lebutább platform. Azaz ha mondjuk egy buttonnak van A feature-e az egyik platformon, van B a másikon, és van C mind a kettõn, akkor te csak a C-t tudod beletenni a wrapperbe, vagy azt mondod, hogy van A feaure is, de az a másik platformon nem csinál semmit.
    Mutasd a teljes hozzászólást!
  • Hát react/jsx/tsx óta nem látom, miért jó egy olyan motor, mint a xaml. Mármint az a hagyományos fajta binding, amit kb úgy látunk a szerkesztőben, mint sima szöveg.

    Régebben voltak mobilfejlesztő munkatársaim. Egy ios-es fejlesztő, amikor xamarinozni kezdett, mondta is, hogy mekkora szívás, hogy a binding az csak egy text. :D
    Mutasd a teljes hozzászólást!
  • Jaigen. Ahogy írtad is, alkalmazásfüggő. Egyes esetekben jól jön, ha rajzolódnak a vezérlők, de sok esetben teljesen fölösleges azzal foglalkozni, pontosan hogyan is néz ki egy editbox az adott platformon. Sőt, néha még előny is, hogy platformspecifikusan néz ki illeszkedve a platformhoz, annak beállításaihoz) lásd pl. dark mode support) és a többi alkalmazáshoz.
    Attól még ez nem szerencsétlen ötlet, csak arra kell használni, amire lehet/való.
    Mutasd a teljes hozzászólást!
  • Nem, az xaml egy tökéletesen felesleges dolog volt. Anno az volt a koncepció, hogy majd jól elválasztják a kódot és a design-t, és ez utóbbit majd a mûvészlelkek fogják megcsinálni a Blend segítségével. Na most, ebbõl kb. semmi sem lett. Nem hiszem, hogy lenne élõ ember aki használja ezt. Kb. ugyanez a helyzet a visual studio vizuális xaml designerével is, ami amúgy is csak WPF-el mûködik, de ott is kb. a helló világ szintjéig. Ergo, a kódod így is úgy is te fogod összerakni, és akkor már 1000x tisztább lenne ez valami fluent API segítségével, mint xml-ben. Ráadásul, ha a fejlesztõt támogatni is akarják(nák) akkor ezzel millió tud lenni, ahogy ez látható is ha valaki Pl. xamarint fejleszt. Pl. komplexebb szitukban vagy van code competition vagy nincs, de általában inkább nincs.

    Ami jó ezekben a cuccokban az a data binding, illetve maga a dolog a WPF óta elég jól ki van találva, de maga az xaml mint olyan szerintem csak árt a dolognak.
    Mutasd a teljes hozzászólást!
  • Nem minden így működik. Még a HTML sem. És ami nem így működik, az úgy működik, hogy részben vagy teljesen saját maga rajzolja ki és kezeli a vezérlőket. Mindegyik megoldásnak vannak előnyei és hátrányai is.

    A saját rajzolásnak az, hogy akár minden platformon pixelpontosan ugyanúgy nézhet ki ugyanaz az alkalmazás. Az eredeti vezérlők használatának az, hogy az eredmény jobban illeszkedik a mindenkor aktuális futtatóplatform más alkalmazásai közé, illetve képes annak minden integrációját és specializációját kiaknázni.

    Ezeket a megoldásokat lehet vegyíteni is egymással. De a lényeg igazából az, hogy ízlések és pofonok, és hogy minden attól függ, hogy mik a prioritások.
    Mutasd a teljes hozzászólást!
  • Miért szerencsétlen ötlet a natív vezérlők wrappelése? Minden így működik, ami cross-platform. Lásd pl. html. Másképp hogyan is működhetne?
    Mutasd a teljes hozzászólást!
  • A XAML az egyik legjobb dolog ami a .NET-tel történt anno, de egyébként az Uno platform ezt és még többet is tud mint a MAUI tervez. Igaz ott UWP alapon történik a fejlesztés, de ettől függetlenül működik és stabil is.
    Mutasd a teljes hozzászólást!
  • Ez igaz, de szerintem alapvetõen a megközelítés rossz, ahogy a xamarin forms-é is.
    Ez a natív controllokat bewrappeljük dolog meglehetõsen szerencsétlen ötlet, ahogy a xaml-t is el kellene engedni végre. Ráadásul a szipi-szupi multiplatformos cucc nem támogatja a linuxot.
    Mutasd a teljes hozzászólást!
  • Ha valóban működik (nem a belekapunk, majd újba kezdünk... bár az MS erősen irányvonalat váltott, ami biztató), akkor komoly jövője lehet.
    Ugyen kevesebb az igény GUI-ra a WEB világ miatt, de amibe új fejlesztésben belekezdenek, azt mindenki multiplatformnak, sőt mobilbrátnak szeretné.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd