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 bta 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 bta 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
Hoe native is native wanneer Google er gewoon even een Skia laag tussenpropt die pixel voor pixel de rendering overneemt? Het is niet native, de output lijkt verschrikkelijk veel op native.
Dat houdt al heel wat meer steek en is ook de manier waarop ik verwacht dat zoiets werkt.
Want een ARM-binary decompilen en omzetten naar JS daar valt denk ik niet aan te beginnen.
Er word voor hummingbird geen arm code om gezet naar JavaScript. Als een app maakt met flutter schrijf je die in Dart dat is een taal die naar andere talen ge compileerd kan worden waaronder JavaScript 1 is.

Also je technische wilt weten hoe ze dit doen moet je misschien “Hummingbird: Building Flutter for the Web” by Yegor Jbanov https://link.medium.com/dyPNUgbfqS eens lezen.
Waarom zou ARM die is geconverteerd naar Javascript zo veel performance vereisen?
Daarnaast bestaan er ook JavaScript frameworks waarmee dit kan. Zoals React Native, Nativescript of Titanium welke respectievelijk uit 2015, 2014 en 2009 komen. Dus dit is alles behalve nieuw. Maar ik verwelkom altijd nieuwe technologie!

Mijn ervaring met Flutter was niet heel positief though, het was vrijwel onmogelijk om een Google maps view toe te voegen aan een scherm, het lukte alleen als full-screen scherm, iets waar de bovengenoemde frameworks geen moeite mee hebben.
Dat geldt voor het PCL project, oftwel de shared code. Het gewone Xamarin.Android project is echt wel Java (of Androids implementatie van Java).

Kijk maar eens in de obj map van de broncode van je Android project ;)
Daar vind ik mijn code en teksten alleen maar in dll's met IL code, geen java. Er staan wel een aantal autogenerated files met java die voor oa project resources gebruikt worden.
Compilation. The platform has two major products: Xamarin.iOS and Xamarin.Android. In the case of iOS, the source code is compiled directly into native ARM assembly code (Ahead-of-Time compilation), while Android Xamarin apps are first compiled down to Intermediate Language and then – into native assembly code at runtime (Just-in-Time compilation). However, in both cases the process is automated and tailored to handle such issues as memory allocation, garbage collection, and platform interoperability by default.
https://www.altexsoft.com/blog/mobile/pros-and-cons-of-xamarin-vs-native/
Xamarin lost dat op met custom renderers en is niet echt moeilijk. Kan dat bij Flutter ook?
Amen,
Dat het naar native compiled laat het nog niet native aanvoelen.
@PPie en @kingofkamikaze , hebben jullie berhaupt al eens de Flutter site gelezen of een app gedownload? Flutter compiled naar een volledig native app met native UI elementen. Er is geen performance verschil tussen Flutter en native apps.
Flutter gebruikt dus zijn eigen renderer en tekent zelf controls en gebruikt niet de renderer/controls van het specifieke platform (android/ios/etc). Er hoeft dus geen performance verschil te zijn, maar dat kan zeker wel (beide kanten op). De makers van Flutter claimen dat ze sneller kunnen/willen gaan renderen dan de afzonderlijke platforms zelf doen.

Het verwarrende hier is, gezien ook meerder reacties het gebruik van de termen 'native' en 'native UI elementen'. Met name 'native' is op veel manieren te interpreteren. De een vind een Java-app op android native, de ander vind weer een ARM-gecompilede app met eigen rendering native.

Feit is in ieder geval dat Flutter zelf alles tekent en niet de UI controls van het systeem gebruikt. In deze is het erg vergelijkbaar met Qt bijvoorbeeld. Maar bijvoorbeeld totaal anders dan React Native, Xamarin en apps geschreven in Java/Kotlin (android) of Objective-C/Swift (ios).
Ik ontwikkel al 7 jaar met cross-platform technologie (in mijn geval Titanium, vergelijkbaar als React Native), en dit is helemaal niet waar.

Ja... er wordt JavaScript mee gecompileerd, maar alle elementen werken cross platform op de manier dat de daadwerkelijk native elementen gebruikt zijn, en dus voelen ze ook zo.

Wat je ziet momenteel met iOS UI op Android, of andersom, is de slechte keuze van meestal de designer/manager die WIL dat ze op beide platformen hetzelfde er uit zien. Dit is vrijwel altijd meer werk dan ze er native uit laten zien.

Als voorbeeld een app waar ik 3 jaar aan gewerkt heb:
https://play.google.com/store/apps/details?id=net.roamler
https://itunes.apple.com/app/roamler/id440588804
Als dit vanuit dezelfde code gegenereerd is dan moet ik toch toegeven dat het er wel erg netjes uitziet.
Dit is hoe het "moet". En ja, het is ongeveer 95% code-shared. De overige 5% is platform specifiek aangezien er natuurlijk verschillen zijn (navigatie structuur, knoppen zitten anders, andere native behaviour etc)

En voordeel, de designer en manager(s) weten dat het 2 verschillende platformen zijn en ook verschillend er uit moeten zien.
De enige mensen die dit beweren hebben nog nooit daadwerkelijk een app gemaakt met "dit soort tussenlagen". In praktijk is dit nl. gewoon onwaar naar mijn ervaring. De abstractie laag bij bestaande "tussenlagen" is naar mijn ervaring dermate strak opgezet dat het gewoon prima aanvoelt als een native app bij zowel iOS als Android.

Zo groot zijn de verschillen overigens ook niet. Over het algemeen heb je 2 soorten apps: Apps die bestaande native componenten gebruiken (die beschikbaar zijn als abstractie in die tussenlaag), en apps die vrijwel volledig bestaan uit custom elementen, en die voelen sowieso al niet aan als specifiek "een android app" of "een ios app".

De enige die niet-native aanvoelt naar mijn smaak is de ionic framework, maar misschien is dat gewoon mijn gebrek aan ervaring met ionic

[Reactie gewijzigd door Gamebuster op 5 december 2018 21:33]

Naja native, Google zet hard in op material design en vele iOS apps volgen die filosofie ook naar mijn weten, aangezien dit niet platform specifiek is maar een ontwerp filosofie. In een flutter project heb je ook gewoon een android project en een Swift project zodat je totaal iets native kunt maken als je er zin in hebt, dus het lijkt me ook wel mogelijk om de navigatie (wel/geen terug knop bijvoorbeeld) platform specifiek te maken, voor de specifieke content maakt het niet zoveel uit. Als je op de material.io website kijkt van Google zie je dat ze enorm flutter aan het ondersteunen zijn en al die elementen zijn wel ongeveer beschikbaar.

Ik heb me er nog niet helemaal in verdiept, maar toen ik het even uitprobeerde was het wel de eerst hybride optie die mij blij maakte. Het is loeisnel en er is geen enkel andere hybride optie dat dichtbij komt. Het zou helemaal cool zijn als je het in kotlin zou kunnen schrijven IPV dart maar misschien komt dat nog ooit :)

De instant run is zeer indrukwekkend, een druk op de knop en poef de app heeft de nieuwe code.

Dus ja, misschien zijn sommige bedrijven lui om twee designs te maken, maar flutter is 100x beter dan welke andere hybride oplossing, dus ik hoop te zien dat als een bedrijf dan toch een hybride oplossing kiest, er met flutter ten minste een fatsoenlijk resultaat uit komt.
Een commentaar op dat specifieke artikel is dat ze een hybride app probeerden te bouwen - native (iOS + Android) en React Native tegelijkertijd. Da's vragen om problemen, net als bijv. Facebook en Twitter jarenlang geprobeerd hebben om web views in apps redelijk werkend te krijgen (is ze niet gelukt). Is dat de schuld van het platform, of van de ontwikkelaars dat ze zich niet durven te specialiseren?

Vooral voor Facebook / Twitter en eigenlijk alle top 100 bedrijven vind ik het eigenlijk onaanvaardbaar dat ze niet gewoon het platform meester maken, ipv daarvan het denken beter te weten en kunnen. Of anders gezegd: dat weten en kunnen ze wel, maar ze kiezen voor de verkeerde technologie.
Het ligt er aan waarvoor. Maar vraag aan mij geen objectief advies in deze: ik ben Qt consultant en weet praktisch niets van de alternatieven.

Maar ja: Qt met QML is IMO zeer geschikt om ook apps mee te bouwen en het wordt ook snel beter, zeker als je (grotendeels) dezelfde apps ook bijvoorbeeld op een embedded device wil gebruiken.


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