41–50 of 55 posts
Earlier quoted context omitted.
> It renders every pixel I thought Qt was "native"? That's what's parroted around here when comparing it to Electron.
It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. But it does not interact with native APIs; it re-implements the native platform's look and feel.
So it's not native.
Earlier quoted context omitted.
It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. But it does not interact with native APIs; it re-implements the native platform's look and feel.
> It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. So it's not native.
https://www.quora.com/What-do-software-engineers-mean-when-t...
> Native (machine) code is code that is ran directly by the processor, in contrast to code that runs on a virtual machine or through an interpreter.
Web apps on JS are the most compelling example of an app ecosystem that has come unmoored from underlying OSs, but iOS and Android have brought back the dominance of native apps, because the underlying platforms and their capabilities are interesting and useful.
Maybe Flutter is a good UI stack for Fuchsia, and maybe easy Web app compatibility would be a boost to both Flutter and Fuchsia, but it will be tough sledding to get Flutter apps accepted by Android and iOS users. Flutter needs to find a place where it is essential, not a compromise for developers searching for a panacea.
The reason Java is the most widely used language is that Android turned Java into a platform-specific, UI-stack-specific app language.
The irony is that, because of the mountain of highly capable modern mobile apps, I'd bet that the Android runtime on ChromeOS quickly becomes the most widely used cross-platform runtime, in terms of the number of apps actually used by people and running on multiple platforms.
Earlier quoted context omitted.
> It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. So it's not native.
Live and learn. https://www.quora.com/What-do-software-engineers-mean-when-t... > Native (machine) code is code that is ran directly by the processor, in contrast to code that runs on a virtual machine or through an interpreter.
"Native" in the context of GUI frameworks doesn't have to do with code being interpreted vs compiled. It means the framework creates UI using the toolkit that ships with the OS you're targeting. It means Cocoa on MacOS and UWP or WPF or WinForms on Windows.
It means when you scroll past the end of the text in a textbox you get a bouncy effect on macOS just like every other Mac application, because it's ultimately calling the same function that every other Mac application calls.
If someone made a JavaScript library that wrapped Cocoa and UWP, it would be called a "native" toolkit, because it wraps the controls that are shipped with each OS. That's why React Native is called what it is - it's actually creating dialogs and views on iOS with the same functions you would call if you were doing it in Swift.
Earlier quoted context omitted.
(disclaimer: I work on the Flutter team) > What do I see when I'm running an older native version? You will see exactly the pixels that your designer intended and your developer coded. :) Apps built with Flutter ship the renderer and framework inside the app, which helps ensure consistency and fidelity across devices, OEMs, OS, and platform. This is particularly important for brands that want a brand-first design del…
Thank you for replying in this thread. Another question. Why is there no desktop support?
There are 100x mobile developers than desktop developers which is why there's so much more investment in mobile tools than desktop tools.
Also, this is Google-led project and Google doesn't write desktop apps (modulo few exceptions like Chrome). As every team, they have more work than they can manage, so they have to prioritize things that are important to them.
Earlier quoted context omitted.
Fair points. It's worth stating though that this only matters if you have a requirement to look 100% native. Many apps don't have this requirement whether mobile or desktop and so they may use a web ui. In our case we didn't have the 100% native requirement and used Qt. We still had a really slick user interface, it just wasn't native. Note that our customers are primarily concerned about the functionality of the app…
It's not just about the look, it's about the feel. From looking at the "gallery app" on android: Flutter's input-text has their own custom mark text handler - no double tap, long press opens a custom menu that is missing native options (Such as translate text). Changing the font size in the OS does nothing in the app. Clicking on buttons doesn't make a tap sound if the "sound on tap" option is set. I'm guessing no ac…
As a native mobile developer of several years, I've always been somewhat skeptical of the various cross-platform solutions that have emerged over the years. The WebView-based solutions weren't fast enough and sometimes behaved differently across devices because of different WebView versions. With React Native, the impression was far better because the performance actually can be quite good. But it's still hard to abs…
"Since every pixel on the UI is rendered by the framework" This is a deal breaker for me. It's not about the ui feeling a bit off - the drawer going over instead of pushing things or some such, it's about losing the integration with the native OS. For example the android version of the gallery app shown elsewhere doesn't adjust to font size changes (which can be done at the system level), won't make a sound when clic…
However, the question is whether a Flutter app will be Good Enough when the alternative is writing two separate apps. I would argue that even in the current alpha stage it's getting pretty close to Good Enough - the Hamilton app was written in Flutter and gets 4.7 stars on Google Play [1] so users aren't too bothered that double-tap doesn't select text.
Java Swing was slow, bloated and looked far less like a native app than Flutter. And in 2003 Windows had a 95% market share, so there was no major benefit to writing a cross-platform desktop application. Things may be different this time.
[1] https://play.google.com/store/apps/details?id=com.hamilton.a...
I wish you guys hadn't killed Apportable. It was such an awesome product! From what I could gather, Google acquihired the Apportable team, which then pivoted to Flutter.
For anyone that doesn't know, Apportable was an Obj-C to native Android compiler. It bypassed the JVM, compiling directly to the native architecture, and actually ran faster than comparable Java apps. As a compromise, it also had a Java bridging interface to hook into Android APIs. It was mainly targeted at games which used Cocos2D, but a UIKit bridge was in the works...
When I first heard about Apportable, I was incredibly wary of their claim, but it worked like absolute magic. I was able to successfully port several Cocos2D apps directly to Android with almost no intervention.
Anyway, assuming the core team is still intact, if there is anyone that can pull off what Flutter is claiming to do, it's these folks.
Earlier quoted context omitted.
"Since every pixel on the UI is rendered by the framework" This is a deal breaker for me. It's not about the ui feeling a bit off - the drawer going over instead of pushing things or some such, it's about losing the integration with the native OS. For example the android version of the gallery app shown elsewhere doesn't adjust to font size changes (which can be done at the system level), won't make a sound when clic…
The clicking sound on button presses has been fixed in the latest build, and the Flutter team is working on accessibility. But I agree that a Flutter app will always have some deficiencies compared to a native app. However, the question is whether a Flutter app will be Good Enough when the alternative is writing two separate apps . I would argue that even in the current alpha stage it's getting pretty close to Good E…
Life rpg was one that I remember (now its down to 3.9).
The alternative isn't writing two native apps, the alternatives are cordova, react-native and xamarin.
Frankly I haven't other people's compatibility issues with react native.