Writing plugins/bindings for native code in flutter doesn't look fun. Almost 100 lines of code to write binding for function that doesn't take any parameters and returns simple 'int' (int getBatteryLevel()). This just looks even worse than JNI to me. Don't want to even thing how long time it would take me to write bindings for function that do image processing.
https://github.com/flutter/flutter/blob/master/examples/plat...
Which is sad because I would really want to have some fast and easy access to useful c++ libraries without wasting lots of time writing and maintaining tons of bindings for Java, ObjC, C.
We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time.
So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
> We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time.
I can't find any claim from Flutter team that 100fps video processing is even their goal. So that's a strange metric to measure it by - especially since it's competing against Javascript interpreted code which is far from fast by any metric.
> So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
On mobile? Qt really isn't pleasant or usable on mobile.
Since flutter runs as native ARM they can directly call C++ instead of having an expensive JNI bridge on android. If you're wanting something fast with native processing - flutter will be the best option out there IMO if that issue is resolved.
I came to the same conclusion (and I'm not a big company that can afford Qt), so I built my own. Before Flutter got a new team @ Google ~3 years back, it was a set of tools for building cross-platform apps with C++ shared libs. A few years ago, this is what many of the FAANG companies were doing with their apps. Then, React Native was released and (I guess) the management at Google decided to take a different tack.
I did some research and found that Dropbox open sourced their internal tool for building cross-platform mobile apps in C++. Djinni (https://github.com/dropbox/djinni) uses an interface definition language to generate bindings between C++ & ObjC & Java (via JNI). From this, I added some tooling to help get the build setup and define some basic UI elements while trying to keep it simple. If you happen to give it a try, I'd love to hear your thoughts: https://github.com/adamtait/ctheworld
Cross-platform frameworks that don’t use native controls have suffered from problems...
- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
- they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
- Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
- there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
- dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
- devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
- many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Building and maintaining an app twice is a very serious expense. But the expense of dealing with the issues with crosss-platform frameworks can be pretty big as well. Of course it depends on what you’re doing (shorter term and longer term) whether or not it makes sense. But go in with your eyes open. Consider other options (like examining your app architecture and see if you can’t find a way to factor some of your naturally cross-platform stuff into a shared library usable by the native apps of each platform you support).
>- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users.
We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
There's one place where none of this matters: Games engines.
Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market.
It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's".
Which means that in this scenario:
> devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
.. It becomes moot whether you're using an engine or an OS's own specific platform. You have either an 'engine developer' or a 'user-facing developer', where the former does everything needed on the target OS to support the latter.
My personal preference: treat onboard native UI frameworks as a plug-out interface to the engine, port the engine everywhere, have my apps look and feel and function the same, no matter where they are running. Screw the OS vendors and their UI's - they change their frameworks so frequently and for no good reason other than to lock in the poor developer who thinks he has to learn their framework, or else not be competitive.
That may be true, but the real competition is in building an app that functions - and functions well - wherever you port it. To accomplish that, you've gotta be willing to be both an expert at the native framework, while also abandoning it ...
I share your concern regarding text fields. That's the one area where I never want to mess with native behavior. The search results for "flutter ios text field copy paste" aren't encouraging.
These are all excellent points. I'm curious how Flutter stands to address these risks/issues in the early days.
I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).
> "devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems."
Good product is a team effort. The question is: Can you find the right people - not just any people but the right people - to come on-board, use / learn the tools you've chosen, and make magic happen?
Sheer technical prowess of tools and/or people is not enough.
That aside, to your points, there are __always__ tradeoffs. Some more detrimental than others. But again, preserving is a function of team. Someone somewhere is doing what your team is doing, and doing it better. They have the same technologies. So then the question is: why.
These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory).
>> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.
>> they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
If people are writing cross-platform apps and want to use new platform-specific features, wouldn't they have to write platform-specific code anyway if they were native? I'm not sure this is a newly introduced problem in any sense.
>> - Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
I guess that's valid; but I'm curious about cases where code-heavy app sizes have actually hindered app downloads. I don't really know, but I haven't heard that this has been a big problem? For reference, a hello world flutter apk clocks in at 5 MB.
>> - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
>> - dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
>> - many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?
>> - devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
This feels like an emotional assessment of having to learn something new. If this technology is meant to simplify/remove problems that people have today, then isn't it worth learning?
I guess you might feel this way if you felt that flutter isn't adding anything of value to other popular solutions today.
I have made an (unofficial/private clone of) Azul boardgame in Flutter (intended as a christmas present to my wife).
Whithout having any Dart or frontend or UI experience (I have always progammed backend and CLI apps), I could make a simple working game in maybe 10 hours - and it is mainly due to the instant feedback cycle.
The whole thing is less than 600 lines of Dart code. (and about 100 lines is to deep copy game state objects (for the undo functionality) as Dart can't do that automatically.
The design is simple, just circles, shadows and small animations (the player in turn gets magnified)[1], but with zero experience in the UI domain I actually barely beleive that I have made it ;)
Of course games are absolutely not affected by the native or not native widget issues, and also I did not use any advanced services from the platform, so can't say much about those weaknesses.
I was really happy with it, I would definitely recommend it to similar hobby/beginner projects.
I was looking for some new dev challenges and wanted to mess with some mobile app development that is outside of the React Native / Ionic / js world.
Gave Flutter a serious look, loved it, but ultimately decided to just skip and mess with Swift and Apple's tools - so no Android stuff for me for now. I just don't trust it to be around long enough to be an investment for me.
I know I'm just 1 developer working on a crappy hobby app for fun, but Google's quick lifecycle of products has real impact. But then on the other hand I love Firebase. Just wanted to share.
I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work.
UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I enjoy it more than Javascript but like Kotlin much more.
The app I built with Flutter was pretty straightforward, so I haven't stretched the platforms capabilities, but hoping I get the chance to.
I haven't touched Android development since 2012. I remember the experience being a terrible hodge-podge of XML and Java which effectively required an absolutely attrocious IDE and an impossibly slow emulator. I assume things have changed since then, but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Dart is "Fine" is the perfect description. It is pretty basic, but pleasant enough to use that it doesn't get in the way.
Kotlin, swift, rust, etc are more fun languages for me but Flutter is productive enough with Dart I am not about to ditch if becasue the language is decent at best.
Have you implemented any layouts using the Constraint Layout? Normally, I'd agree with you, but I find the Constraint Layout pretty great for designing UI's. The "glued together" approach makes responsiveness a breeze, imo.
I am a C++/mobile dev and I couldn't get myself amped about React Native because you have to do all the layouts through style-sheets. I am not a web dev, so style-sheets are pretty foreign to me beyond the basics. With flutter I can do all the same stuff but with auto-complete and in a hierarchy I understand.
I do wish the controls were native, but the customization you get instead is pretty powerful.
Haven't tried Flutter yet, but I feel the same way ever since React/Vue hot reload. It's a game changer. I really really miss it whenever I'm working on a site or game that doesn't support it. Once you get used to it, it feels painfully slow developing without.
Look at how many comments on this, or any other Flutter thread, mention hot reload.
What I take from that is this: if your toolchain makes rapid iteration easy people will figure out how to work around almost anything else.
Language/framework/tool creators rarely put enough time into the developer experience. And by that I mean the experience of a developer working with your tool for 8 hours a day. I can get more done with a crappy tool with 500ms compile time versus a perfect tool with 10s compile time.
I've been using Flutter for a little over a year and I absolutely love it. Hot reloading, Dart tree shaking, Static type checking, etc. What's not to love? Dart widgets are consistent, making UI design easy peasy. UI widgets are definitely skewed to Android (for now), but iOS work is moving quite fast.
I've been following and using Flutter since release 0.2. I think Flutter is an amazing project. It makes writing concise and beautiful apps very easy. I've come to love Dart and the whole Flutter framework. I really think it is the best framework to write Android applications. It also works great for iOS were you can either choose to use Material or Cupertino components. It is a huge improvement over the old Android SDK; which is quite outdated in my opinion. It's too hard to create a beautiful app with the current Android SDK. To many hurdless. Flutter feels like what developing an Android app should be like today.
Another thing about Flutter is that it's also ready to work with Google's (upcoming; maybe) Fuchsia OS.
One loose end is still the plugins for native features on either iOS and Android. There are many community driven plugins which aren't really maintained. Fortunately there is also a large set of plugins maintained by the Flutter team itself.
I've tried Xamarin, React Native and Cordova (god forbids) and native development on iOS and Android. My preference is Flutter.
I've done one big(ish) project with Flutter and it's called "My Leaf" and it is a third party alternative to the NissanConnect EV app. It's used for controlling the Nissan Leaf and Nissan e-NV200 (both EV's). It's open source and available on Android and iOS;
I've seen some of the comments in this post talk about developing plugins for Flutter. I actually think it is easy and does not require much boilerplate contrary to what people say. My guess is that they really haven't tried writing a plugin but only peeked at the documentation.
Flutter renders the whole UI, like a game engine. In the past, this has meant that if there isn't a Flutter implemention of a component (like a video player or map), you couldn't add it to your app. I don't know if that's still true.
Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make."
The comment from pzo points out an even worst of an adoption showstopper.
Here's some of the explanation about why they chose Dart:
> There’s a lot of nice properties of Dart, we talk some about this on our website
at our frequently asked questions. One of the nice properties of Dart is that it has a really fast
garbage collector, one of the choices that we made in Flutter was to have this reactive style
system where it’s very common to allocate thousands of objects in a – if not, tens of thousands
of objects in a single frame.
> In a span of a few milliseconds and then immediately let go of those objects again. There’s a
variety of ways to do that but Dart, having a generational garbage collector, can handle large
volumes of short lived objects very quickly. Dart also has some really nice performance
characteristics, it has an ahead of time compiled back end which allows us to compile straight to
native arm code, allow us to achieve really fast startup on really consistent performance and
Dart also has a nice focus on developer experience which really got along well with my team.
> Why they didn't just choose Typescript or go with native javascript is beyond me.
They needed to be AOT compiled. Can't ship a JIT on iOS, after all. And JS is very unfriendly to static compilation. Dart is considerably better suited for AOT due to static typing.
There are other languages that are GC'd & AOT friendly, though, so I can't help you with why they didn't use any of those, though. But why they wouldn't use JS is pretty straightforward.
> One of the challenges that React Native developers face, or have reported in the past — one challenge is that native React Native code is written in JavaScript, which means that it’s run using the browser’s JavaScript engine, which immediately kind of move this a little bit away from the native model of the platform.
Calling React Native “not native” while eschewing platform UI widgets is a bit thick. I’d actually of the opinion that React Native is “more native” than Flutter is; it might be a bit slower but it is much easier to build apps that could pass as actual “native” apps because the React Native team doesn’t need to try to emulate system controls.
One of the main issue with Flutter is that you can't embed a native view inside a flutter widget tree. This makes it limited as we can't have inline maps or custom video views.
There are people working on it. The progrss has been slow. I checked a couple of weeks ago and the issue was still open.
But as far as I know you can have a native view in its own activity.
Though not a blocker for simple apps which previously used Cordova or ionic, I don't think Flutter is ready to replace native development for immersive apps.
Embedding a native view in cross platform UI is possible with Xamarin and React Native, so they are more practical choice for certain types of apps that need this.
Google has a history of introducing products and then killing them. For developing mobile apps they currently support "vendor native" via Android Studio using Java or Kotlin, Progressive Web Apps, and now Flutter.
Will Google really support all three over the long term?
The widget layer of flutter is Skia which is written in C++ and Flutter apps compile to ARM binary (native) code. Someone else asked about whether a Flutter app can be ported to Linux; why not compile both the logic and the UI directly to WebAssembly?
Looks cool but not too much of cross-platform - iOS and Android only. It seems the only really cross-platform GUI technologies still are browser-powered and Qt.
I did a small app in flutter last week out of curiosity (fetching rss/atom feeds, rendering html content) and was surprised how easy it was to work with tooling that flutter provides. Also was pleasant surprised on how well Dart fits in to this use case. Go flutter!
[+] [-] pzo|7 years ago|reply
Which is sad because I would really want to have some fast and easy access to useful c++ libraries without wasting lots of time writing and maintaining tons of bindings for Java, ObjC, C.
We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time.
So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
[+] [-] smy20011|7 years ago|reply
https://github.com/flutter/flutter/blob/master/examples/plat...
I really hope flutter can provide a guide for FFI though.
[+] [-] izacus|7 years ago|reply
I can't find any claim from Flutter team that 100fps video processing is even their goal. So that's a strange metric to measure it by - especially since it's competing against Javascript interpreted code which is far from fast by any metric.
> So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
On mobile? Qt really isn't pleasant or usable on mobile.
[+] [-] rockwotj|7 years ago|reply
That being said - my personal usecase would like a direct C++ interop, and flutter is working on it. See https://github.com/flutter/flutter/issues/7053
Since flutter runs as native ARM they can directly call C++ instead of having an expensive JNI bridge on android. If you're wanting something fast with native processing - flutter will be the best option out there IMO if that issue is resolved.
[+] [-] thosakwe|7 years ago|reply
Dart C/C++ interop hasn't been a super-bright spot so far, and I am _beyond_ glad to see it's about to change.
[+] [-] sdinsn|7 years ago|reply
The rest is UI and application boilerplate
[+] [-] sebe|7 years ago|reply
[+] [-] adamtait|7 years ago|reply
I did some research and found that Dropbox open sourced their internal tool for building cross-platform mobile apps in C++. Djinni (https://github.com/dropbox/djinni) uses an interface definition language to generate bindings between C++ & ObjC & Java (via JNI). From this, I added some tooling to help get the build setup and define some basic UI elements while trying to keep it simple. If you happen to give it a try, I'd love to hear your thoughts: https://github.com/adamtait/ctheworld
[+] [-] Abishek_Muthian|7 years ago|reply
e.g. iOS HID requires navigation buttons for obvious reasons & not so for android.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] JustSomeNobody|7 years ago|reply
Use the right tool for the job. Always.
If Flutter can't handle it, it's not the right tool for the job.
[+] [-] jmull|7 years ago|reply
- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
- they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
- Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
- there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
- dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
- devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
- many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Building and maintaining an app twice is a very serious expense. But the expense of dealing with the issues with crosss-platform frameworks can be pretty big as well. Of course it depends on what you’re doing (shorter term and longer term) whether or not it makes sense. But go in with your eyes open. Consider other options (like examining your app architecture and see if you can’t find a way to factor some of your naturally cross-platform stuff into a shared library usable by the native apps of each platform you support).
[+] [-] coldtea|7 years ago|reply
We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
[+] [-] fit2rule|7 years ago|reply
Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market.
It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's".
Which means that in this scenario:
> devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
.. It becomes moot whether you're using an engine or an OS's own specific platform. You have either an 'engine developer' or a 'user-facing developer', where the former does everything needed on the target OS to support the latter.
My personal preference: treat onboard native UI frameworks as a plug-out interface to the engine, port the engine everywhere, have my apps look and feel and function the same, no matter where they are running. Screw the OS vendors and their UI's - they change their frameworks so frequently and for no good reason other than to lock in the poor developer who thinks he has to learn their framework, or else not be competitive.
That may be true, but the real competition is in building an app that functions - and functions well - wherever you port it. To accomplish that, you've gotta be willing to be both an expert at the native framework, while also abandoning it ...
[+] [-] jetako|7 years ago|reply
[+] [-] dmix|7 years ago|reply
I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).
[+] [-] chiefalchemist|7 years ago|reply
Good product is a team effort. The question is: Can you find the right people - not just any people but the right people - to come on-board, use / learn the tools you've chosen, and make magic happen?
Sheer technical prowess of tools and/or people is not enough.
That aside, to your points, there are __always__ tradeoffs. Some more detrimental than others. But again, preserving is a function of team. Someone somewhere is doing what your team is doing, and doing it better. They have the same technologies. So then the question is: why.
[+] [-] exacube|7 years ago|reply
>> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.
>> they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
If people are writing cross-platform apps and want to use new platform-specific features, wouldn't they have to write platform-specific code anyway if they were native? I'm not sure this is a newly introduced problem in any sense.
>> - Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
I guess that's valid; but I'm curious about cases where code-heavy app sizes have actually hindered app downloads. I don't really know, but I haven't heard that this has been a big problem? For reference, a hello world flutter apk clocks in at 5 MB.
>> - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
>> - dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
>> - many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?
>> - devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
This feels like an emotional assessment of having to learn something new. If this technology is meant to simplify/remove problems that people have today, then isn't it worth learning? I guess you might feel this way if you felt that flutter isn't adding anything of value to other popular solutions today.
[+] [-] szemet|7 years ago|reply
Whithout having any Dart or frontend or UI experience (I have always progammed backend and CLI apps), I could make a simple working game in maybe 10 hours - and it is mainly due to the instant feedback cycle.
The whole thing is less than 600 lines of Dart code. (and about 100 lines is to deep copy game state objects (for the undo functionality) as Dart can't do that automatically.
The design is simple, just circles, shadows and small animations (the player in turn gets magnified)[1], but with zero experience in the UI domain I actually barely beleive that I have made it ;)
Of course games are absolutely not affected by the native or not native widget issues, and also I did not use any advanced services from the platform, so can't say much about those weaknesses.
I was really happy with it, I would definitely recommend it to similar hobby/beginner projects.
[1] https://pasteboard.co/HQdDD4r.png
[+] [-] _7siz|7 years ago|reply
I was looking for some new dev challenges and wanted to mess with some mobile app development that is outside of the React Native / Ionic / js world.
Gave Flutter a serious look, loved it, but ultimately decided to just skip and mess with Swift and Apple's tools - so no Android stuff for me for now. I just don't trust it to be around long enough to be an investment for me.
I know I'm just 1 developer working on a crappy hobby app for fun, but Google's quick lifecycle of products has real impact. But then on the other hand I love Firebase. Just wanted to share.
[+] [-] wootie512|7 years ago|reply
UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I enjoy it more than Javascript but like Kotlin much more.
The app I built with Flutter was pretty straightforward, so I haven't stretched the platforms capabilities, but hoping I get the chance to.
[+] [-] weberc2|7 years ago|reply
[+] [-] rhodysurf|7 years ago|reply
Kotlin, swift, rust, etc are more fun languages for me but Flutter is productive enough with Dart I am not about to ditch if becasue the language is decent at best.
[+] [-] H1Supreme|7 years ago|reply
Have you implemented any layouts using the Constraint Layout? Normally, I'd agree with you, but I find the Constraint Layout pretty great for designing UI's. The "glued together" approach makes responsiveness a breeze, imo.
[+] [-] Ylodi|7 years ago|reply
[+] [-] rhodysurf|7 years ago|reply
I am a C++/mobile dev and I couldn't get myself amped about React Native because you have to do all the layouts through style-sheets. I am not a web dev, so style-sheets are pretty foreign to me beyond the basics. With flutter I can do all the same stuff but with auto-complete and in a hierarchy I understand.
I do wish the controls were native, but the customization you get instead is pretty powerful.
[+] [-] Reedx|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
Followed later by the Oberon OS.
Eiffel also offered a similar experience with their MELT VM and compilation to native code via C code generation.
[+] [-] habosa|7 years ago|reply
What I take from that is this: if your toolchain makes rapid iteration easy people will figure out how to work around almost anything else.
Language/framework/tool creators rarely put enough time into the developer experience. And by that I mean the experience of a developer working with your tool for 8 hours a day. I can get more done with a crappy tool with 500ms compile time versus a perfect tool with 10s compile time.
[+] [-] dkobia|7 years ago|reply
Try it, you'll love Dart.
[+] [-] tobiaswk|7 years ago|reply
I've tried Xamarin, React Native and Cordova (god forbids) and native development on iOS and Android. My preference is Flutter.
I've done one big(ish) project with Flutter and it's called "My Leaf" and it is a third party alternative to the NissanConnect EV app. It's used for controlling the Nissan Leaf and Nissan e-NV200 (both EV's). It's open source and available on Android and iOS;
https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...
https://itunes.apple.com/us/app/my-leaf-for-nissan-leaf/id14...
I've seen some of the comments in this post talk about developing plugins for Flutter. I actually think it is easy and does not require much boilerplate contrary to what people say. My guess is that they really haven't tried writing a plugin but only peeked at the documentation.
[+] [-] bsimpson|7 years ago|reply
[edit]: It looks like this has been addressed with the PlatformView widget: https://developers.googleblog.com/2018/12/flutter-10-googles...
[edit]: Sorry, bluetidepro - this was supposed to be a reply to you.
[+] [-] thrownaway954|7 years ago|reply
The comment from pzo points out an even worst of an adoption showstopper.
[+] [-] deweller|7 years ago|reply
> There’s a lot of nice properties of Dart, we talk some about this on our website at our frequently asked questions. One of the nice properties of Dart is that it has a really fast garbage collector, one of the choices that we made in Flutter was to have this reactive style system where it’s very common to allocate thousands of objects in a – if not, tens of thousands of objects in a single frame.
> In a span of a few milliseconds and then immediately let go of those objects again. There’s a variety of ways to do that but Dart, having a generational garbage collector, can handle large volumes of short lived objects very quickly. Dart also has some really nice performance characteristics, it has an ahead of time compiled back end which allows us to compile straight to native arm code, allow us to achieve really fast startup on really consistent performance and Dart also has a nice focus on developer experience which really got along well with my team.
From https://softwareengineeringdaily.com/2018/07/09/flutter-with...
[+] [-] kllrnohj|7 years ago|reply
They needed to be AOT compiled. Can't ship a JIT on iOS, after all. And JS is very unfriendly to static compilation. Dart is considerably better suited for AOT due to static typing.
There are other languages that are GC'd & AOT friendly, though, so I can't help you with why they didn't use any of those, though. But why they wouldn't use JS is pretty straightforward.
[+] [-] snaky|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] saagarjha|7 years ago|reply
Calling React Native “not native” while eschewing platform UI widgets is a bit thick. I’d actually of the opinion that React Native is “more native” than Flutter is; it might be a bit slower but it is much easier to build apps that could pass as actual “native” apps because the React Native team doesn’t need to try to emulate system controls.
[+] [-] pritambarhate|7 years ago|reply
There are people working on it. The progrss has been slow. I checked a couple of weeks ago and the issue was still open.
But as far as I know you can have a native view in its own activity.
Though not a blocker for simple apps which previously used Cordova or ionic, I don't think Flutter is ready to replace native development for immersive apps.
Embedding a native view in cross platform UI is possible with Xamarin and React Native, so they are more practical choice for certain types of apps that need this.
[+] [-] matt2000|7 years ago|reply
[+] [-] pritambarhate|7 years ago|reply
[+] [-] parvenu74|7 years ago|reply
https://developers.googleblog.com/2018/12/flutter-10-googles...
[+] [-] mikece|7 years ago|reply
Will Google really support all three over the long term?
[+] [-] parvenu74|7 years ago|reply
[+] [-] Andrex|7 years ago|reply
https://developers.googleblog.com/2018/12/flutter-10-googles...
[+] [-] rohan1024|7 years ago|reply
[+] [-] qwerty456127|7 years ago|reply
[+] [-] Gonzih|7 years ago|reply