30 comments

[ 3.0 ms ] story [ 73.6 ms ] thread
Android and iOS, yes, but also THE official toolkit for making apps for Fuchsia, the project which will replace Android in a few years. Expect Google to highlight all of the companies who have started shipping Flutter apps and to highlight why developers would want to drop traditional Java/Kotlin development and move to Flutter because not only will your apps work today on Android, but they will run tomorrow on Fuchsia.
I really thought Flutter was going to just fade away, but it really seems to be picking up speed, in no small part due to Fuchsia as you mentioned.

Looking at the line up for Google I/O, hearing the rumors as we're about to head into it, and with the newest beta release, I'm starting to think Flutter is past the point of being abandoned any time soon.

The real question for me is when will it be stable enough so that I can put it into production without worrying about major API changes breaking everything on the best update.

I was super against Flutter when it was announced. I wrote my apps in objc and java and recently swift/kotlin. I had some downtime recently and tried out flutter for a simple crud app and I gotta say... it makes mobile dev wayyyy more fun.

There’s a bunch of stuff missing (maps, etc) and dart isn’t my favorite language (I like kotlin and swift way more) but it’s sooo much easier to prototype up and build cool apps in flutter than native. There’s just so much freedom and you can hot reload to instantly see what you change.

IDK that I would make a production app on it today, but it definitely has stuck in my mind.

What I really want to know is how it compares with React Native. I suppose one differentiator is Dart, which might draw in non-web devs who don't want to write JavaScript, or C# (as with Xamarin).

The list of React Native apps is quite impressive, however:

https://facebook.github.io/react-native/showcase.html

Disclaimer: I'm a product manager for Flutter at Google, so I'm paid to say nice things about Flutter :)

Probably the two most obvious architectural differences are that a) Flutter paints every pixel on the screen, whereas React Native uses the stock iOS and Android components; and b) Flutter uses Dart which can be compiled ahead-of-time to native ARM machine code, whereas React Native code is written in JavaScript.

We think the combination of the hardware-accelerated graphics engine, native-compiled code and customizable UI widgets is a powerful one, as exemplified by demos like this one: https://www.2dimensions.com/b/225-flutter-showcase

My favorite feature of this demo is that the translucent slider control is overlaid on the animated graphics beneath: this is often difficult to do with other frameworks because they don't have the same level of control over what is painted, or can't do it with the required performance.

Your results may vary, but this demo runs smoothly on my budget last-generation Nokia 6 phone, which I bought for about $200.

Hope this helps a little?

Is there plans for Flutter on desktop? How about support on ChromeOS maybe using the new GNU/Linux support using the KVM?
This could be really big, good middle ground between Electron and native desktop.
So far pretty impressive results on iOS.

I wonder if the strategy by Google is get development to Flutter for cross platform, Android and iOS and then launch Fuchsia.

Google now has a branch for ART on Fuchsia which suggests they will support Android apps on Fuchsia.

Also how they did GNU/Linux on ChromeOS would work with switching to Fuchsia. They are using a completely separate Linux kernel.

I am old and lived through many cross platform attempts that just never worked well. The four that worked well have been the Alpha/Vax. But died because of marketing reasons not technical.

Android is pretty amazing how well it works across platform. Then ChromeOS is the same. The last has been the Web and Chrome.

If someone can make it work it would be Google. I will be curious if Apple tries to kill it somehow.

Probably the two most obvious architectural differences are that a) Flutter paints every pixel on the screen, whereas React Native uses

Why is it bad that a framework uses native components?

"bad" does not feature in the sentence you quoted, nor in anything OP said.
He spoke as if it's an advantage. I honestly want to know if there is an advantage in redrawing the screen and not using native elements.
He gave an example of something that is not possible without writing native modules for each platform in React Native.
It's not bad for the framework; it's bad in the sense that widgets are similar but not identical across platforms -- if they exist at all. Flutter packing it's own widget layer guarantees uniform behaviour across platforms.
Flutter packing it's own widget layer guarantees uniform behaviour across platforms.

That's not a good thing...,we lived through that already with Java Swing.....

There's nothing bad providing you're using the native language of the platform. With React you have to go through bridge code to communicate with the native controls. So there's a level of indirection to and from the native control. Flutter communicates with its widgets directly so there's no level of indirection. The other major advantage is that it compiles to native code so performance is always going to be superior.
Since flutter paints every pixel on the screen, widgets will work same for every version of OSs. No more support library madness.
What he said. Flutter's widget set is neither HTML-rendered like hybrid or native OS widgets like Xamarin or React Native (or NativeScript) but use a C++ layer of its own. Putting that on Android was no surprise; getting it past the censors at Apple is a little more surprising. There's also no reason this widget layer cannot be ported to macOS, Windows, and Linux... I'll let y'all's imaginations run with that for a bit.

I told a wicked-smart colleague of mine about Flutter in general; a couple weeks later he came back and said he had written a sample app in Flutter and then decompiled the resulting IPA and APK files and examined the assembly. His report was that it looked very similar to apps he had written in C++ (like I said, he's wicked-smart).

If anyone from flutter can answer: by reading a little about map integration in the flutter sdk, i came to understand that there was some kind of design issue with the way flutter exposed the underlying open GL layers. Making it hard to plug anything wanting to use this layer directly (due to layer compositing ?).

What i just said is obviously pretty vague, so could anyone knowledgeable provide some answer to this long-term architectural concern ?

Hi, Wm Leler from the Flutter team. There are several map integrations available. I think what you might be thinking about is the integration with Google Maps. We have a solution and are working with the Google Maps team to implement. We will announce when this is ready. Meanwhile, there are three plugins that can do maps.

There is no "long-term architectural concern" with Flutter. We play well with video and other views.

If you have a more specific question, I'd be happy to give more specific answers. Feel free to contact us.

Ok, thanks. I tried to find the github issue that gave me this impression. Probably something related to game development, i’m not sure ( maybe this one : https://github.com/flutter/flutter/issues/179). I may have confused the two issues.

Glad to hear the map story is moving forward. Good job.

Does anyone know if there are any sip, webrtc, xmpp library for flutter? i was scrounging around for one and couldnt find one a year back ago dont know whats the landscape like right now
(comment deleted)
I think it's a little irresponsible for Google to recommend the use in production of a techno still in beta from developers. Especially since it's not just a version upgrade it's a new techno. That means that for most of those who will use it start from 0. And leave with a techno that has never passed the stable 1.0 must dare anyway.

____________________________________________________ https://showbox.software/ https://kodi.software/ https://luckypatcher.pro/