Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google brengt toolkit uit voor maken iOS- en Android-apps met enkele codebase

Google heeft versie 1.0 van Flutter uitgebracht, een toolkit om vanuit een enkele codebase apps te maken voor Android en iOS. De bèta van Flutter kwam eerder dit jaar online. Nieuw is onder meer de functie om een bestaande app verder te ontwikkelen met de toolkit.

Flutter werkt het met het Dart-platform voor 32bits- en 64bits-ARM-code en gebruikt Skia 2D Graphics voor het tonen van de interface, schrijft Google. Met Flutter moet de ontwikkeling van apps voor iOS en Android sneller gaan, onder meer door de functie om wijzigingen in realtime te zien in apps voor beide platformen zonder te hoeven herladen.

Google laat Flutter werken met de standaardprogrammeertalen voor Android en iOS, Kotlin, Java, Swift en Objective-C. Google heeft de eigen toolkit al gebruikt voor het maken van de Ads-app en claimt dat sommige grote bedrijven, waaronder Philips Hue en Alibaba, apps ontwikkelen en uitbrengen die met Flutter zijn gemaakt.

De opensource-toepassing moet in de komende tijd ook naar desktops komen, waarbij het gaat werken met Windows, macOS en Linux. Dat gebeurt door ARM-code om te zetten in Javascript, via een tool die Google Hummingbird heeft genoemd. De bèta van de toolkit kwam in februari online. Flutter 1.0 is als download beschikbaar voor Windows, Linux en macOS.

Door Arnoud Wokke

Redacteur mobile

05-12-2018 • 18:38

49 Linkedin Google+

Submitter: GertMenkel

Reacties (49)

Wijzig sortering
"Dat gebeurt door ARM-code om te zetten in Javascript, via een tool die Google Hummingbird heeft genoemd."

Slaat het nu niet een beetje door? Een soort generieke code zoals JS om het makkelijk op elk platform te laten draaien tot daar aan toe.

Maar een app vervolgens "hardcoded compilen naar ARM" of hoe moet ik het noemen? En dan terug omzetten naar JS (wat waarschijnlijk gruwelijk inefficiënte code oplevert) om het vervolgens weer door een JS engine te laten uitvoeren? Gaat dat niet wat ver? Straks hebben we een i9 nodig om onze mails te syncen.
Ik weet niet hoeveel verstand de auteur van dit artikel precies heeft van Flutter, maar veel wat hier staat is raar opgeschreven of klopt niet.
Dart is gekozen omdat het werkt in een VM en kan compilen naar native code. Flutter is bedoeld om te draaien als native app, omdat dan de prestatie gewoon het beste is. Flutter is in eerste instantie gemaakt voor mobiel, maar wel met het idee dat het overal op kan draaien. Flutter komt inderdaad naar de desktop, zoals in het artikel staat, maar als "flutter desktop embedder" en dit gaat ook om compiled code. Daarnaast is Google bezig om Flutter ook naar het web te krijgen door te compilen naar javascript en dit is Hummingbird. Dit zijn dus 2 verschillende projecten waarvan de desktop embedder nu al te proberen is, maar Hummingbird publiek nog niets van te zien is.

De apps zijn dus daadwerkelijk gecompiled naar native arm-code, maar omdat Dart toevallig makkelijk naar javascript compiled is het Flutter team ook bezig om het te laten compilen voor web, maar daar is nog een lange weg te gaan.
Ik denk eerder dat je het moet vergelijken met een game engine.

Volgens mij worden games bijvoorbeeld in C++ geschreven en kunnen vervolgens gebruikt worden op iOS en Android middels een game engine. Zo heeft Flutter ook een engine die dus de knoppen tekent.

Ik vind dit genoeg om 'native' te noemen, ipv een bridge die zorgt dat de componenten van het OS zelf gebruikt worden vanuit shared code zoals andere cross-platform toolkits doen.
Op Android word vrij veel door SKIA gerenderd her word ook door Chrome gebruikt. Het verschil tussen native apps en flutter als je het heel simpel zou zeggen zijn flutter apps meer native dan Java/kotlin apps op Android en op IOs zouden ze hetzelfde moeten zijn als Swift/Objective-c. Het eind resultaat van een flutter app is alsof een app in C++ hebt geschreven ten opzichte van een Java die naar bytecode is compileerd zodat het binnen de Java VM kan draaien.
De code generator kan hiermee (enigszins) rekening houden met de code die ie uitspuugt. Als ie daarbij (voornamelijk) gebruikmaakt van code die door de JS engine goed te optimaliseren valt, dan zou het mee kunnen vallen met de inefficiëntie.

Vergeet niet dat er ooit een tijd was waarin alles in assembly werd geschreven. Toen kwam C (en co) en tegenwoordig vinden we PHP (hoeveel abstractie-lagen zitten er tussen PHP en machinecode; hoeveel machinecode instructies worden er uitgevoerd als overhead voor één PHP-functieaanroep?) efficiënt genoeg voor talloze toepassingen. Het principe "compile alles naar JS, run JS overal" (een beetje vergelijkbaar met hoe netwerken het doen: elk protocol wordt bovenop IP gebouwd; IP kan over elk medium getransporteerd worden) is helemaal zo gek nog niet. Uiteindelijk is het vooral een afweging waar je inefficiënt bent: moet een programmeur tijd verspillen aan het schrijven van code voor verschillende platformen, of laat je hardware cycles verspillen aan generieke code en extra "vertalingen"?
Ik gebruik inmiddels een paar maanden Flutter en ik ga echt geen 'native' apps meer ontwikkelen. De ontwikkelomgeving (IntelliJ) werkt echt super en het verschil met de native os elementen is bijna niet te zien. De bounce van ios en de maan van Android werken gewoon.
Ze geven aan dat Flutter 60 fps haalt en tot nu toe geloof ik dat.
Dart is wel even wennen :)

Echt super blij met Flutter
Xamarin doet dit al lange tijd en is ook al vrij ver gevorderd met optimalisaties en zaken als Xamarin forms. Ook de performance is goed van dit soort apps. Tegenwoordig is Xamarin van Microsoft en werkt dus met een van de beste IDEs (Visual Studio).
Ik maak er sinds enkele maanden gebruik van. Hiervoor enkel ervaring met desktop applicaties en geen mobiele applicaties (of je moet een Unity export naar Android meetellen). Ik moet zeggen dat het heel fijn werkt. De meerwaarde ligt vooral in het snel prototypen. Als ik mijn telefoon aan mijn PC aansluit, en een wijzinging aan de code doe, wordt de app direct op de smartphone geüpdatet zonder dat ik de app opnieuw hoef te builden. Heel handig! En met heel weinig code maak je een visueel prachtige app.
Je bouwt de apps met widgets (in widgets, in widgets, etc). Het werkt als het ware als een boomstructuur. Echter kun je daarnaast ook met de taal Dart (dat wat weg heeft van Java) prima complexere classes schrijven.
Het nadeel is wel dat het platform nog niet volwassen is. Vooral qua core functionaliteit mist er nog het een en ander. Zo is er voor Bluetooth de package 'Flutter Blue', maar dat wordt gewoon door één persoon gemaakt. Echt alternatieven zijn er niet. Dus als hij dat niet had gemaakt dan was er geen Bluetooth ondersteuning? Als je het zelf wilt doen moet je wat dieper de Java of Kotlin van Android en de objective-C of Swift van iOS doorspitten.

[Reactie gewijzigd door Fleximex op 5 december 2018 19:29]

Xamarin is vergelijkbaar met .NET op Windows. De applicatie draait native, maar vereist ook dat Mono touch aanwezig is (en een aantal Xamarin specifieke libs).

En Xamarin.IOS / Xamarin.Android wordt gewoon "vertaald" naar Objective-C en Java. De PCL / managed code draait via Mono.
Nee. Op iOS wordt C# code vooraf (AOT) gecompileerd naar ARM assembly language, op Android wordt het gecompileerd naar IL dat door mono uitgevoerd wordt. Het draait daar dan naast Java en is daarom vaak sneller dan native Java apps.
https://docs.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/building-cross-platform-applications/understanding-the-xamarin-mobile-platform
Maakt niet uit dat het 'naar native compileert', het probleem is dat dingen die niet op alle platformen zitten, dan niet in dit soort abstractielagen zitten en vaak het moeilijk maken om alsnog iets toe te voegen.
Vroeger had je AWT op Java, dat was ook zo'n enorm succes, het werkte op alle platformen 'net niet'.

Las net deze:
http://www.takingnotes.co...act-native-accessibility/
Gaat over React Native, een vergelijkbaar iets, maar dan van Facebook.
Hier staat in dat het bijna niet te doen is om VoiceOver toe te voegen aan een app die gebruik maakt van React Native op iOS, omdat het framework het niet ondersteunt, juist dingen abstraheert die nodig zijn om Accessibility mogelijk te maken en het zelfs moeilijk maakt omdat het framework 'hidden buttons' gebruikt om de GUI te layouten. (Geen idee of een screen reader wel werkt aan de Android kant, maar het laat zien wat ik bedoel, mismatch in ondersteuning)
Het zijn alleen "namaak" elementen - dat is, Flutter tekent zelf de graphics die lijken op die van het native platform. Het probleem is dat ze achter gaan lopen als bijv. Apple met een nieuw design van hun UI komt. En dan heb je nog alles in die standaard componenten die je niet ziet - voor iOS moet je dan denken aan accessibility (text to speech, fontgrootte (wat trouwens veel apps niet ondersteunen), hoog contrastmodus), maar ook bijv. force touch en de haptic feedback. Dat zijn veel features die ze opnieuw moeten implementeren - en waarschijnlijk niet gaan doen of bijhouden.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True