Google brengt bèta uit van iOS- en Android-ontwikkelplatform Flutter

Google heeft een bèta van Flutter uitgebracht. Dat is een gratis en opensource framework voor het ontwikkelen van native apps voor zowel Android als iOS. Flutter moet het eenvoudig maken om apps voor beide platforms te ontwikkelen.

Google claimt dat ontwikkelaars met behulp van Flutter hun apps sneller kunnen uitbrengen op de twee platforms. Het framework maakt gebruik van standaarddesignelementen in beide besturingssystemen, zodat de weergave van apps aangepast wordt voor weergave op Android en op iOS. Bovendien is Flutter compatibel met Fuchsia, een nieuw besturingssysteem voor laptops en smartphones waar Google aan werkt.

Flutter geeft ontwikkelaars toegang tot animaties, iconen en widgets die eenvoudig te gebruiken en aan te passen zijn. Het framework werd tijdens Googles ontwikkelaarsconferentie I/O vorig jaar aangekondigd en was al als alphaversie beschikbaar. Nu de bètafase is bereikt zijn er veel verbeteringen doorgevoerd en is er onder andere ondersteuning toegevoegd voor de iPhone X en iOS 11. Voor beginnende gebruikers is er een Flutter-handleiding online gezet.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (73)

[Craimasjien]

Flutter is dus een framework dat een hele verzameling aan widgets, componenten en handvatten faciliteert voor een app die geschreven wordt in de programmeertaal Dart, wat syntactueel veel weg heeft van Java. De Flutter engine zelf is geschreven in C++, wat er waarschijnlijk voor zorgt dat er een compatibiliteitslaag ontstaat. Dit is, voor zover ik weet, het eerste framework wat C++ gebruikt om native apps te bouwen vanuit 1 en dezelfde codebase.
Interessant, ben benieuwd waar de grenzen liggen, aangezien vrijwel alle "oplossing" gepaard komen met de nodige uitdagingen m.b.t. platform specifieke eisen.

[Elefant]

Dit lijkt me vooral gemaakt om Fuchsia een goede start te geven. Of we daar nu zo blij mee moeten zijn? Alles wat Google doet is steevast om hun macht nog verder te vergroten en hun tentakels nog verder uit te steken. Mensen die denken dat het allemaal zo heerlijk is om alle grenzen en barrieres tussen landen en systemen op te ruimen die hebben niet door dat dit helemaal niet de lokale en kleine bedrijven en ondernemers dient. Het werkt wel prijsverlagend, maar de kunst van de economie is nu juist dingen te produceren met een hoge toegevoegde waarde waar lokale mensen weer hun inkomen uitkrijgen.

Wat multinationals als Google doen is alle barrieres slechten zodat er een globale markt ontstaat die beheerst wordt door grootkapitaal middels corporaties. Het lijkt aantrekkelijk om grotere markten te scheppen voor developers maar in grotere markten neemt het aantal aanbieders juist af. Op de wereldmarkt vind je vaak nog maar een of enkele aanbieders omdat schaalvoordelen veel zwaarder gaan doorwegen als de aantallen gaan stijgen. Daarom beheerst Google nu vele markten met haar goedkope voortbrengselen.

Voor developers is het veel beter dat IOS en Android gescheiden markten zijn en blijven. Het is heel simpel, hoe meer systemen, hoe meer werk en hoe meer inkomsten. Het streven naar efficentie in grote organizaties leidt er in feite vooral toe dat alle toegevoegde waarde naar de kapitaalverschaffers gaat. Hoe meer je de factor arbeid uitschakelt hoe meer alles kapitaalintensief wordt en de macht naar de kapitaalverschaffers verschuift.

Een Goed voorbeeld is open source met zijn open code en standaarden, daar verdienen developers nog maar een fractie van wat in een vrije markt wordt verdient waarin bedrijven hun voortbrengselen kunnen beschermen door intellectuele eigendomsrechten en afwijkende standaarden en formaten.

Als je welvaart wil dan wil je diversiteit bevorderen en de barrieres in stand houden die diversiteit mogelijk maken. Als je eenheidsworst wil dan wil je alle barrieres slechten. Dat leidt dan tot grote corporaties die landen overspoelen met goedkope producten die ze laten maken op plaatsen waar ze mensen het beste kunnen uitbuiten. Nauwelijks belasting betalen, wel lokale bedrijven overnemen, veel mensen er uitschoppen en steeds alle kosten op de samenleving leggen.

Jan Timmer ex-directeur van Philips zegt in een interview dat Nederland bezig is een kolonie te worden van de VS en dat de VS op zijn beurt weer beheerst wordt door bedrijven als Google. Moeten we niet eens een keer ophouden om alles wat Google maar verzint om haar macht nog wat groter te maken, toe te juichen en omarmen. Wat is Fuchia dan weer? Een systeem dat Google ook weer de macht over IoT moet brengen. Zijn we daar blij mee? Grote macht leidt tot grote corruptie, absolute macht tot absolute corruptie.

[Reactie gewijzigd door Elefant op 23 juli 2024 14:19]

[Verwijderd]

Zeer inzichtelijke post. De macht van Google is veel en veel te groot en de consolidatie zet door, gestaag. Wat het zo enorm gevaarlijk maakt is dat Google aan de buitenkant vaak geliefd is: gebruiksvriendelijk en developer friendly.

Daarom protesteren zo weinig mensen, het is een sluipmoordenaar. Een monopolie was vroeger veel duidelijker "evil", neem een Shell, een grote bank, een wapenhandelaar. Het was duidelijk wat er mis mee was.

Nu niet, mensen staan de machtsuitbreidingen zelfs toe te juichen omdat het henzelf een klein tijdelijk voordeeltje opleverd. De macht die al vergaard is, is niet te bevatten zo groot. Van ieder stukje digitale content, soms gemaakt met bloed, zweet en tranen, of het nu tekst of video is, bepaald Google of iemand het uberhaupt onder ogen krijgt. Zo ja, dan roomt men van ieder stuk content wat geld af.

De hele wereld in dienst van Google dus. En dat is Google. Neem nou een Uber. Wereldwijd mensen voor een stuiver laten werken terwijl zij in een kantoortje aan wat knoppen draaien en inkomsten afromen zonder de lasten. Ze hebben zelfs het lef dit een "deeleconomie" te noemen haha.

De digitalisering zal doorzetten. In iedere verticale markt zal een grote speler wereldwijd domineren. De mensen uitmelken totdat ze geheel door algoritmes vervangen zijn.

We gaan dit verliezen omdat mensen altijd voor gemak kiezen, en dat bied men. Neem nou die discussie over Netflix en lokale content. Kijk hoe de mensen Netlfix met hand en tand verdedigen en hoe veel haat er is tegen welke overheidsinmenging dan ook. Het heeft maar een mogelijk uitkomst: een enkele wereldspeler die bepaald welke content er uberhaupt mag bestaan, en uiteraard zal dat de meest winstgevende zijn.

Kortom, we verdienen deze toekomst.

[Verwijderd]

Te veel diversiteit wordt helemaal niet gewaardeerd, vandaar ook het "succes" van windows mobile. Jouw methode leidt tot inefficientie. Als toegevoegde waarde is iets op een dure manier te maken door de makkelijke manieren de nek om te draaien gaan we er als geheel op achteruit.

[Elefant]

Dat vind ik te kort door de bocht. Efficientie is goed als het gaat om het efficient omgaan met grondstoffen, bedrijfsmiddelen e.d.. Maar als we multinationals de factor lokale arbeid laten uitschakelen dan is het resultaat steeds grotere werkeloosheid. De opbrengsten gaan naar veelal buitenlands grootkapitaal en de kosten van werkeloosheid worden op de lokale samenleving geschoven.

De factor arbeid is anders dan de andere productiefactoren omdat zij tegelijkertijd ook het inkomen en daarmee de koopkracht is van de lokale bevolking. Het doel van de samenleving is niet buitenlandse grootkapitalisten rijk te maken maar te zorgen dat er genoeg inkomen is en een redelijk verdeling van inkomen binnen de samenleving. Daar ligt de eerste verantwoordelijkheid. Grote corporatie maken het een soort race to the bottom waarbij ze daar produceren waar het het goedkoopste is. Verkopen waar mensen het rijkst zijn en overal liefst gratis gebruik maken van de lokale infrastructuur (netbeutraliteit) en natuurlijk geen belasting betalen. Het is het aloude kolonialsime in een nieuw jasje.

Het gezonde principe was vroeger dat wij importeerden wat wij zelf niet hadden of redelijkerwijze zelf konden maken. Zo houdt je het geld en rijkdom in de eigen economie en houdt je je eigen bevolking aan de slag. Mensen aan het werk houden in goed betaalde banen geeft de beste inkomensverdeling. De grote winsten van corporaties kun je het beste zien als buitenlandse private belastingheffing omdat ze monopolies vormen waar je niet meer om heen kan.

Landen als China zijn veel slimmer dan wij en hebben wel door wat er gebeurd. Daarom zetten ze nationale alternatieven op en laten ze hun industrie niet zo maar opkopen.

Om de nationale weerstand te breken wordt er door multinationals niet alleen vrij verkeer van goederen en diensten maar ook van personen afgedwongen middels internationale verdragen, waar een volk niets meer over te zeggen heeft. Dat leidt dan weer tot binnenlandse tegenstellingen die vakkundig tegen elkaar worden uitgespeeld. Zo ondermijn je het natonale verzet. Verdeel en heers. Je zag de zelfde spelletjes in het Communisme waar ook volkeren door elkaar gehusseld werden om hun nationale eendracht te breken. In de VS hebben ze een situatie geschapen waar de bevolking tot het bot verdeeld is door fanatieke activisten aan beide kanten op te ruien. Miljardairs sponsoren die activisten aan beide kanten, Een natie is alleen sterk als er eendracht is.

De gratis producten van deze bedrijven zijn in feite dumpingpraktijken om de hele markt in handen te krijgen. Maar geleidelijk aan gaan ze toch mensen laten betalen. Mensen trappen daar inderdaad in. Ik betwijfel of mensen Facebook zo geweldig vinden, maar het is gratis en Pietje en Anja zitten er ook op omdat het gratis. Daarom is het belangrijk dat de overheid door afschaffing van gratis gebruik van infrastructuur de werkelijke kosten laat betalen. En sowieso had de overheid de mededingswet moeten gebruiken om deze monopolievorming te voorkomen. Nog idioter is om ze alle competitie maar op te laten kopen. De vrije markt wordt niet goed genoeg verdedigd. Landsbelang hoort voorop te staan. Ook de EU laat zijn oren te veel naar de 50.000 lobbyisten hangen. Tijd om eens te laten zien dat wij nog steeds baas zijn in eigen huis. Wij hebben de multinationals niet nodig, zij hebben ons nodig om zichzelf te verrijken. Als de markt niet in staat is om alternatieven op te zetten dan moeten de overheden dat zelf doen. Dat schept gelijk weer werk en inkomen.

Hoe verder wij op deze weg gaan hoe meer we het zullen bezuren.

[Reactie gewijzigd door Elefant op 23 juli 2024 14:19]

[kozue]

Precies mijn gedachten als ik dit artikel zo lees. Een stuk software van Google dat je applicaties laat schrijven voor Android (Google), Fuchsia (Google) en oh ja, we doen er ook nog iOS bij om cross-platform over te komen.

Het enige dat je hiermee in huis haalt is een systeem dat Google bevooroordeeld met de belofte dat je niet speciaal voor iOS een aparte app hoeft te maken (misschien vergelijkbaar met wat MS geprobeerd heeft, maar iedereen links liet liggen?). Maar hoe willen ze de verschillen tussen de platformen af gaan vangen? Hoogstwaarschijnlijk door in je app hun play-framework te embedden en alle native iOS alternatieven te laten voor wat ze zijn, zodat de iOS app ook lekker data kan lekken naar Google servers. Dus geen Apple Maps maar alleen Google Maps, etc.

Ik hoop echt zo hard dat dit flopt. Dit soort frameworks zijn slecht voor de consument, en in het bijzonder voor degenen die juist een iPhone hebben gekocht om niet aan Google vast te zitten. Zoals ik.

[Rabb]

Ik zit al tijden te wachten op een platform als deze. Ik heb de tijd en energie niet om zowel voor Android als iOS te leren developen, waarbij iOS nog geld kost ook nog.

Een platform als deze is vergelijkbaar met java, dit draait op alles van je browser en je mobiel tot je koelkast.

Het zorgt er uiteindelijk voor dat zowel Android als iOS betere vooruitgang gaan boeken doordat apps makkelijker te maken zijn.

Ik ben het eens dat Google te groot is. Echter ga je dit tegen door goede alternatieven te ontwikkelen en het bezit dat de grote bedrijven hebben mbt personeel gaat begrenzen.

Als je bij Google zit ga je niet snel weg. Dat is momenteel het grote probleem. Developers worden opgekocht en contractueel vastgelegd, op zo'n manier dat ze vrijwel zeker niet weggaan. Waardoor de diversiteit aan ontwikkelde software een stille dood sterft.

[BrutalCoding]

Allereerst moet ik zeggen dat ik nog niet met flutter heb gewerkt, echter is er een vergelijkbaar platform genaamd Xamarin (al sinds een tijdje overgenomen door Microsoft). Heb met Xamarin wel enige ervaring opgedaan. Dus je had daarmee aan de slag kunnen gaan.

Je zei dat het voor iOS nog eens geld kost ook, bedoel je hiermee dat je een Mac moet aanschaffen zodat je bijv. met XCode een iOS app kan schrijven? Want volgens mij moet je nu alsnog een Mac hebben want Apple verplicht je om iOS apps te compilen op OS X, en ook als je apps wilt distribueren moet dat via je Mac computer gaan. Misschien dat ik je niet goed begreep, maar dit probleem is er dus nog steeds als ik het goed heb.

Voor de rest vind ik dit wel een leuke ontwikkeling, ik ga het in ieder geval proberen want Xamarin is ook niet ideaal.

Edit: Kleine toevoeging, naast Xamarin bestond er ook al React Native en anders van die HTML apps zoals Cordova of PhoneGap dacht ik.

[Reactie gewijzigd door BrutalCoding op 23 juli 2024 14:19]

[fdm391]

Qt heeft toch ook een mobile oplossing?

[Craimasjien]

Klopt, echter is het framework daarentegen weer qua visual layout vrij spartaans. Dit framework biedt, naar het schijnt, de bekende UI componenten voor beide platformen zodat de app gevoelsmatig klopt voor de eindgebruiker.

[reneflo]

Dat klopt. Ik moet wel zeggen dat de elementen voor Material Design beter zijn uitgewerkt dan die voor iOS. Je kan Material Design wel iets aanpassen dat het wat meer iOS lijkt. Het grote voordeel van Flutter vind ik dat je echt alles kan aanpassen, want je kan gewoon doorklikken in de code. Als je dus bijvoorbeeld de AppBar wil veranderen kopieer je gewoon die code en maak je ervan wat je wil. Een goed voorbeeld daarvan vind ik de Hamilton app, het is Material Design maar wel duidelijk met een eigen twist eraan:
https://9to5google.com/20...droid-flutter-fuchsia-os/

De tekst van dit artikel doet ook een beetje lijken alsof je de standaardelementen van het OS gebruikt:
"Het framework maakt gebruik van standaarddesignelementen in beide besturingssystemen",
maar het is dus juist zo dat Flutter alles zelf tekent. Vooral op Android is dat een groot voordeel omdat je dan zeker weet dat alles hetzelfde eruit ziet op alle telefoons. Op iOS is het hierdoor ook zo dat je nieuwere UI elementen van bijvoorbeeld iOS 11 kan gebruiken op oudere iOS versies, maar daar zitten iOS gebruikers volgens mij juist niet op te wachten, want daar is uniformiteit over het platform belangrijker.

[BikkelZ]

Geen idee welke elementen nieuw zijn in iOS 11?

[reneflo]

Je bedoelt neem ik aan in iOS 11?
Ik ben totaal geen iOS expert (ik gebruik Android), maar viel me wel op dat ze nu bijvoorbeeld grotere titels hebben op veel plekken: https://developer.apple.c...nes/bars/navigation-bars/

[BikkelZ]

Ah ja dat klopt op zich wel, de UINavigationBar zelf was al wel enorm oud maar je kunt hem nu groter maken. Dat zou een raar gezicht zijn in iOS 10 maar op zich zijn dat soort legacy problemen niet verder dan één versie terug.

[Menesis]

Dit is, voor zover ik weet, het eerste framework wat C++ gebruikt om native apps te bouwen vanuit 1 en dezelfde codebase. "

Niet als je C# tot C++ rekent: Ok, dat klopt niet
Anyway.. met Unity3D maak je native apps voor allerlei platformen: iOS, Android, PC, MacOS, Linux, Playstation, XBOX, Tizen etc etc.

Dus die probleemstelling die jij schetst is al heel vaak belicht in de mobile game wereld
Als je bijv voor iOS en Android kiest is het zo dat je in je code bepaalde delen alleen voor Android kunt laten compilen en andere delen alleen voor iOS. Verder ben je in het geval van Unity3D afhankelijk van welke APIs zij beschikbaar stellen, dus het is wel een beetje een soort box waarbinnen je werkt. Als je met native delen van een specifiek platform wilt communiceren kun je nog platform specifieke plugins aan je project toevoegen dan dan worden meegenomen als je voor dat platform compileert.

In het geval van games werkt dit iig erg goed gezien het grote aantal titels dat met Unity is gemaakt.

[Reactie gewijzigd door Menesis op 23 juli 2024 14:19]

[Boudewijn26]

Niet als je C# tot C++ rekent

Hoewel de grens tussen C++ en C vrij vaag is, is C# wel echt een ander beestje:
- Native vs. managed
- Totaal andere syntax
- Ga maar door

Laat je niet misleiden door een soortgelijke naam (Java en Javascript)

[Reactie gewijzigd door Boudewijn26 op 23 juli 2024 14:19]

[Verwijderd]

C# is meer gerelateerd aan VB.net dan aan C++ als je het mij vraagt.

[MartijnHavinga]

Het enige VB.net aan C# is het ".net" gedeelte. C# lijkt veel meer op Java. Ik heb zelfs een keer een Java programma geport naar C# en dat was een kwestie van de frontend weggooien (stelde niet veel voor) en dan voor de backend alle .java files hernoemen naar .cs, import veranderen in using en java.x.y veranderen in system.x.y, vervolgens nog een paar compile errors oplossen en klaar.

[Verwijderd]

Ik heb het niet over de syntax maar over de opgeleverde code en kwaliteit van compilers. Daar zul je weinig of geen verschil in aantreffen.

[David Mulder]

In de play store kun je de flutter gallery app vinden en om eerlijk te zijn viel me de attention to detail toch echt tegen. 'kaart'/pagina openen ziet er mooi uit, maar klik je de back knop dan ziet er vreselijk uit bijvoorbeeld.

Sowieso, het idee om een native iOS widget na te maken en dan op een iOS device te gebruiken terwijl je ook de echte kon gebruiken... Weet niet zeker of dat het beste idee is. In de web dev wereld heb je veel implementaties van material design, maar daar is het ook het idee dat die componenten op alle platformen worden gebruikt en is dat klein beetje ongemak van componenten die zich net niet 100% gedragen zoals de native variant acceptabel. Maar bij native apps die enkel op mobieltjes kunnen draaien .

[Reactie gewijzigd door David Mulder op 23 juli 2024 14:19]

[2green]

In de play store kun je de flutter gallery app vinden en om eerlijk te zijn viel me de attention to detail toch echt tegen. 'kaart'/pagina openen ziet er mooi uit, maar klik je de back knop dan ziet er vreselijk uit bijvoorbeeld.

Sowieso, het idee om een native iOS widget na te maken en dan op een iOS device te gebruiken terwijl je ook de echte kon gebruiken... Weet niet zeker of dat het
idee is. In de web dev wereld heb je veel implementaties van material design, maar daar is het ook het idee dat die componenten op alle platformen worden gebruikt en is dat klein beetje ongemak van componenten die zich net niet 100% gedragen zoals de native variant acceptabel. Maar bij native apps die enkel op mobieltjes kunnen draaien .

De app is gebaseerd op een vroegtijdige Alpha versie van flutter. Laatste wijziging in april 2017.

App is zelfs significant eerder geschreven. Goede kans dat hij draait op een zelf nog oudere flutter als hij enkel is bijgewerkt.

Werkt verder erg fijn met flutter trouwens, maar gebruik nog wel veel java/kotlin erbij, wat ik hoopte te voorkomen.

[David Mulder]

Ah! Bedankt, bij een ander nieuws artikel werd gelinkt naar die demo app, en ik heb die enigszins blind gevolgd. Enig advies wat een goede demonstratie is van de huidige stand van zaken?

[2green]

Even terug nog op gezocht, maar kon geen up-to-date demo vinden. Wel staan er een aantal opensource apps op de flutter reddit die leuk zijn om te bekijken, ook qua source.

Mocht je iets beters treffen dan hoor ik het graag.

[Jeanpaul145]

Ik moet bekennen, zo lang ze niet ook het web ondersteunen ben ik zelf niet geinteresseerd.

Waar we met z'n allen heen moeten is "write once, compile to anything". Niet zo catchy als Java's oude slogan "write once, run anywhere", maar enfin.

Dit voelt als een 80/20 oplossing: Het kan (letterlijk!) hele mooie dingen op lekker vloeiende frame rates, maar het brengt me niet significant dichter bij dat doel.

[DeuTeRiuM]

Ik denk niet dat het ooit goed komt dat write once gaat werken. Bijvoorbeeld interactie met de camera verschilt per mobile-os. Daar kunnen wel abstractielagen tussen komen, maar dat dekt nooit 100% de functionaliteit zonder uitzonderingen te maken per OS.

Voorlopig dus: *Learn* once, run/compile/whatever anywhere.

[Jeanpaul145]

Ik heb het niet over Java's brakke JVM aanpak.

"Write once compile to anything" betekent: programmeer iets in een competente, safe, en statically-typed programmeertaal (dus geen PHP of JS) en compileer het naar elk willekeurig platform. Dat het kan staat niet ter discussie, het is een gegeven. De vraag is enkel: hoe duur is het om dat te doen? Ofwel, hoe economisch is het?

Voor de gemiddelde ontwikkelaar niet heel erg, want zoiets opzetten is een gigantenklus, significant groter dan het schrijven van een complete web render engine (en dat zijn al megaprojecten).

Over het verschil in APIs: daar heb je een punt. Althans, dat zou je hebben, als het niet gelijk onderuit werd gehaald door het bestaan van Flutter zelf: het ondersteunt ios en android, en die 2 hebben idd hele andere APIs. Als Google daar goed genoeg mee om kan gaan door platform-onafhankelijke abstracties te bieden kan dat een heel eind komen. En idd, de platform-specifieke features komen wss niet beschikbaar, of anders onder een build flag ofzo. Dat is inmiddels prima, alle core functionaliteit is breed aanwezig overal. Dat impliceert ook meteen dat alles wat nu nieuw is misschien ooit wenselijk is, maar nu nogal niche. En dat is om maar te zwijgen over het feit dat een platform-specifieke API willen aanroepen ingaat tegen het hele idee van een platform-onafhankelijke code base, maw als devver moet je niet eens willen om die platform-specifieke APIs te callen.

[Verwijderd]

Typische reactie van een webontwikkelaar die nooit met hardware of OS beperkingen hoeft te interacten. Neem bv. alleen al het verschil in rechtenbeheer tussen Android 6 en hoger, Android 5 en lager en iOS. De hele logica is anders, dat kan je amper in een overkoepelende api vatten en qua workflow denk ik dat de gebruikers dat ook niet echt zien zitten.

[DeuTeRiuM]

Ik weet prima wat je bedoelt. Ik heb hier en daar wel een regeltje geprogrammeerd... veel web en app maar ook embedded.

Static en “safe”(?) heeft niets met write once compile to anything te maken. Maar zijn taaleigenschappen. Die runtime of compiletime worden gecheckt. Handig is t wel.

Als “anything” geen overeenkomstige apis biedt zal er een abstractielaag gemaakt moeten worden. C++ heeft bv een heel aardige standaardlib die het redelijk ok maakt om xplatform dingen te maken, echter blijf je per os uitzonderingen houden. Zelfs bij hele kleine applicaties.

Ik maak nu een app. Begonnen met react native ivm cross platform. Ben geen javascript (ecosysteem) fan, maar als het doet wat het moet doen, prima. Maar uiteindelijk toch native gegaan met swift. Toch avfoundation nodig, ook direct toegang per frame van de camera. Een crossplatform react native plugin bood dat niet. Eveneens face recognition niet (op de manier hoe ik het nodig had?). Ook dingen van het vision framework nodig. Na zelf een plugin te maken voor ios, toch overgestapt op native alleen voor ios. Jammer. Ik gebruik wel reswift want het redux pattern is heel aardig.

Mij ervaring is: Je wil al gauw iets natives. Kan heel lullig zijn zoals een schaduwtje om een plaatje of misschien een transition tussen twee views. Of er is weer gedoe tussen api versies in android waardoor er iets breakt. En zeggen dat je dat niet moet willen is geen argument, want soms wil of moet je het toch.

Met andere woorden: het kan! Maar is vooral nuttig voor platte business apps. Xamarin is daar ook aardig in schijnt. Het gaat gewoon mis op de api abstractielaag. Die is niet overeenkomstig te krojgen door fundamentele verschillen. Vandaar dus: learn once, write anywhere. Je leert bv flutter en maakt een app met uitzonderingen per os.

[Reactie gewijzigd door DeuTeRiuM op 23 juli 2024 14:19]

[David Mulder]

Het grote verschil tussen verschillende write once, run anywhere approaches is voor mij vooral hoe makkelijk het is om er een native componentje bij te schrijven. Moet zeggen dat ik erg positief ben verrast door React Native bijvoorbeeld, redelijk makkelijk om componenten bij te schrijven en je kunt bijna heel je code base behouden als je naar het web gaat.

[Verwijderd]

Is dit weer een manier van Google om hun programmeertaal Dart te forceren? Tot nu toe werd de taal nauwelijks gebruikt. Zelfde verhaal met Google Go.

Ik zie meer in WebAssembly waarmee je elke taal (C#, Java, C++, Go, Dart etc.) kan compileren naar iets wat door een webbrowser uitgevoerd kan worden.

[Mellow Jack]

Lol dus je wilt iets schrijven in bijvoorbeeld c++ om het daarna te compileren naar een webtaal om het uiteindelijk tijdens runtime weer terug laten compileren naar C++ ( want de browser engine is vaak in C++ geschreven).

Dat geeft een beetje een Google translatie gevoel wanneer je een verhaal van het Engels naar het Nederlands vertaald om dit uiteindelijk weer naar het Engels te vertalen

[Verwijderd]

Als jij een back-end schrijft in C++, Go, C# of Java dan is het wel zo handig dat je de front-end ook in die taal kan schrijven. Dit is één van de argumenten die men gebruikt voor NodeJS. Ik vind echter dat Javascript geen goede taal is voor een back-end. Ik vind dat je dit in een 'echte' programmeertaal moet schrijven.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:19]

[Diamondo25]

Embarcadero CBuilder kan dit al heel lang, eigenlijk... https://www.embarcadero.com/

[Verwijderd]

Google's Xamarin dus.

Nou, ik blijf wel bij het origineel.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:19]

[da Burp]

Daar stap ik ook niet zo snel van af. Hoewel dit volgens mij zelfs meer te vergelijken is met Xamarin forms. En dat vond ik zelf nou niet bepaald stabiel werken een jaar geleden, veel issues mee gehad. Ben dus wel benieuwd hoe goed de ontwikkelervaring is, want dat kan bij Xamarin soms ook traag en frustrerend zijn. En daar lijken ze hier wel aandacht aan te hebben besteed.

En vraag me af hoe goed ze 0-day support kunnen keveren voor nieuwe native api’s. Met name iOS, Android kunnen ze wrs wel goed op vooruit lopen.

[WoutervOorschot]

Er zijn nog steeds wel wat issues mee, vooral dat ze updates nogal makkelijk pushen, de voorlaatste versie is meestal het stabielst. Daarna werkt alles fantastisch als je binnen de gebaande functionaliteit blijft, anders is het veel werk om opeens volledige renders e.d. te moeten schrijven voor iOS/Android

[2green]

Klopt helemaal, neem vooralsnog aan dat het met de Alpha stadium van het project te maken had. Verwacht nu we een beta hebben dat het niet tot nauwelijks meer gebeurd.

[MrDucky]

Xamarin en flutter zijn kwa implementatie niet echt te vergelijken. De output van flutter en xamarin en de werking ervan is verschillend. Het enige wat ze delen is dat het beide crossplatform frameworks zijn..?

[biglia]

Ik heb lang geleden met Xamarin gewerkt. Je kan wel een gemeenschappelijke codebase hebben voor zowel Android en iOS, maar bij de UI ben je echt wel specifieke Android/iOS componenten aan het implementeren. Dan ben je dus nog bezig met manuals, tutorials, ... voor zowel Android als iOS uit te pluizen. Misschien verschilt Flutter hier wel in.

[capsoft]

Maar de design guidelines verschillen toch ook per mobiel os? Persoonlijk vind ik dat je als je een app maakt het passend bij het (mobiele) os moet maken om de uniformiteit van het platform aan te houden ipv jouw huisstijl en dus afwijken van het platform.

[landcross]

Met Xamarin.forms kun je ook een cross-platform UI maken

[mailis]

volgens mij is Xamarin van Microsoft...

[reneflo]

De enige overeenkomst is dat je cross-platform apps maakt, maar verder is ongeveer alles anders. Ik zie eigenlijk veel meer vergelijking met Cordova, omdat die alles zelf rendert in een WebView en Flutter rendert alles in een FlutterView, maar dan dus zonder de web laag ertussen.

[mailis]

aha, zo bedoelde je het

[raro007]

Gun hem om zoals gewoonlijk een azijn pisser te zijn man..

[nils83]

Wat is er mis met iets te kopiëren (als dat hier al zo is)? Heb jij ook graag maar 1 merk TV, stofzuiger, auto etc...

[SteveWoz]

Een beetje laat wat mij betreft. Volgens mij is het gebruik van apps echt zwaar gedaald de afgelopen tijd. De tijd van “there is an app for that” is allang voorbij. Ik verwacht niet dat apps opeens weer op gaan komen, tenzij er een compleet nieuwe technologie op de markt komt. En al helemaal niet omdat Apple 16GB telefoons blijft verkopen (heb er zelf ook een dus geen flamebait), waarvan iets meer dan 12GB beschikbaar is. Op die manier wil je het aantal apps zo laag mogelijk houden, want ik wil ook wel eens (lokaal) een liedje luisteren of fotootje schieten.

[Prullenbak84]

. En al helemaal niet omdat Apple 16GB telefoons blijft verkopen (heb er zelf ook een dus geen flamebait)

Ik geloof je "geen flamebait" opmerking, maar het is wel feitelijk onjuist. van de 8 en X zijn er al geen 16gb versies meer. Apple is daar dus mee gestopt.

Verder heb ik juist helemaal niet het idee dat apps op hun retour zijn. Heb je hier aanwijzingen voor?

[Reactie gewijzigd door Prullenbak84 op 23 juli 2024 14:19]

[SteveWoz]

Even Googlen lijkt mijn verhaal niet te bevestigen. Zie o.a. deze post. In mijn omgeving gebruiken mensen in ieder geval minder apps, maar dat blijkt dus geen goede graadmeter.

[BeeJee]

edit: fout gelezen

[Reactie gewijzigd door BeeJee op 23 juli 2024 14:19]

[Devaqto]

Zelfs de iPhone 7 begint bij 32GB

[Mavamaarten]

Grappig genoeg wordt het opslaan van de huidige instance state nog niet ondersteund. Concreet betekent dat, dat als je app in de achtergrond wordt afgesloten om geheugen vrij te maken, de app gewoon terug opnieuw start in plaats van het vorige scherm te openen. Ik vind het dan ook erg opvallend dat Flutter al als beta wordt bestempeld.

Ik blijf er een beetje een too good to be true-gevoel bij overhouden. Zeker nu Kotlin voor Android Development zo populair is, komt men af met nog een nieuwe programmeertaal die helemaal niet zo aangenaam aanvoelt.

[Reactie gewijzigd door Mavamaarten op 23 juli 2024 14:19]

[Craimasjien]

[...]
Ik blijf er een beetje een too good to be true-gevoel bij overhouden.
[...]

Dat gevoel heb ik al jaren bij de verschillende frameworks die dergelijke opzetten beloven. Het is vrijwel nooit een alles overkoepelende oplossing waar werkelijk kwaliteit apps uit voortvloeien.

[biteMark]

Awesome! Ben heel benieuwd hoe dit werkt ten opzichte van Xamarin...

[DennusB]

Ziet er goed uit. Installer loopt hier op MacOS om even snel te spieken wat het is Fijne heldere instructies tot nu toe iig!

[Joppiez]

Ik heb liever dat er gewerkt wordt aan standaardisatie om diensten op het hardware/os bijvoorbeeld middels html aan te spreken (waar al de nodige stappen in zijn gemaakt natuurlijk). Dit is weer het zoveelste product die het multiplatform deployen faciliteert.

Het meerendeel van alle apps functioneert prima in (alleen) een html5/web omgeving. Bouw dus verder uit om meer optimalisaties daarvandaan door te voeren. Maarja, raamwerken als Flutter helpen natuurlijk Google weer potentieel meer invloed/inkomsten te grijpen.

[Reactie gewijzigd door Joppiez op 23 juli 2024 14:19]

[2green]

Ik heb liever dat er gewerkt wordt aan standaardisatie om diensten op het hardware/os bijvoorbeeld middels html aan te spreken (waar al de nodige stappen in zijn gemaakt natuurlijk). Dit is weer het zoveelste product die het multiplatform deployen faciliteert.

Het meerendeel van alle apps functioneert prima in (alleen) een html5/web omgeving. Bouw dus verder uit om meer optimalisaties daarvandaan door te voeren. Maarja, raamwerken als Flutter helpen natuurlijk Google weer potentieel meer invloed/inkomsten te grijpen.

Eerlijk gezegd weinig gedaan met mobiele html oplossingen, maar wat ik heb gelezen was niet veel belovend. Vrijwel alle noemenswaardige applicaties gebruiken iets anders of zijn van html weer teruggestapt naar iets anders. De bekendste daarvan is misschien wel facebook. Mogelijk mis ik iets? Hoor het graag aangezien ik binnenkort iets wil ontwikkelen.

[Joppiez]

Mijn comment slaat ook op het gegeven dat een (mobile) browser het meest aanwezige deployment platform voor handen is, dus toereikend voor interoperabiliteit van een app (mits binnen de constraints). Als je vanuit technisch oogpunt naar apps welke in de stores te vinden zijn kijkt kunnen ze ruimschoots draaien in een browser (met evt ondersteuning van html5 apis). Niet zelden draaien ze al in een web container overigens.

Dat Facebook/Google (etc) met eigen tech komen is logisch. Het hoeft bij lange na niet het meeste logische te zijn, want een boel gebeurt onder druk van stakeholders (hoe het meeste inkomen te genereren in de toekomst).

[AlphaPrinciple]

Lijkt mij dat het Google eigenlijk niet te doen is om ontwikkelaars een Android/iOS ontwikkelomgeving te bieden - ze willen vooral bij launch zoveel mogelijk apps beschikbaar hebben op Fuchsia. Dat is waar alternatieve smartphone OSen het al eens moeilijk mee hebben.

[Verwijderd]

Er zijn al jaren vergelijkbare SDK's op de markt zoals Xamarin en PhoneGap. Probleem is dat Google zijn eigen taal Dart gebruikt en niet een bestaande taal die breder geaccepteerd is, zoals Java of C#. Ik zie dit toch meer als een verkapte reclame voor Google Dart.

[Dark Angel 58]

klik hier voor youtube versie van bovenstaande video als tweakers' brakke videospeler niet wilt afspelen

tweakers.net, please kill your videoplayer

[Reactie gewijzigd door Dark Angel 58 op 23 juli 2024 14:19]