Flutter for Linux
snapcraft.io
snapcraft.io
On the web it's DOA for most use cases - it's just a canvas, so scrolling, text selection, shadow rendering, etc. is custom, doesn't feel native and must be downloaded and compiled.
It can have a future on desktop. One "cultural" obstacle is that the de facto default widget system is Material, which is simply a wrong approach to desktop UI.
They announced beta version for Windows in the last few weeks, so what to expect? I've been using it on linux desktop for 4 months so far, there were many problems, but it's absolutely the best framework so far. It's miles ahead of Qt (which I've been programming in since 2010). Dart and flutter are just years ahead of Java, C#, Qt and React Native in terms of positive programmer experience, productivity, good looking UI. There are so many bad things to say too, but all I can think about are only due to immature ecosystem, but that's changing literally daily.
Why do you feel C# is worse then Dart?
Got any eamples of ADTs, pattern matching, immutable collections, data classes, named parameters, etc.?
Coming from Scala and TypeScript the Dart language is pretty unappealing wrt syntax and functionality, kind of archaic actually. Flutter looks amazing and have been hoping that Dart would evolve more quickly than it has.
There’s about 4 different packages that provide immutable collections, built_collections might be the most popular.
Would you mind elaborating?
I founded the nested tree of widgets syntax good after getting over the (short) initial learning curve. Some basic good programming practice over shared bits and it was very maintainable even for complex screens.
Flutter Widgets, like HTML are declarative. They're just hierarchical information. This works in HTML, and it works in Flutter - there's nothing to get confused about.
Nested control flow (if statements, loops etc.) obscures the actual behaviour and so good practice is to break it up until it is clear and understandable.
Developing once for iOS and Android seems obvious and doable, but extending that to the web is a different game.
After shipping an app in it this year I've become a big fan of Kotlin Native, you can do enough code sharing to take the edge of doing two apps as a solo dev while having very little friction to access native views and APIs. The two apps feel like platform citizens on each OS but I have networking, persistence, utils and state management shared between them.
This sounds like Flash all over again. Let me guess - no native text select, copy & paste supported? Scrolling is "wrong" in a subtle way?
Here's an example of text fields: https://gallery.flutter.dev/#/demo/text-field
Right-click and you have access to the browser context menu; choose Inspect and you can see a <textarea> or <input> control.
Flutter for Web further feels like a nightmare for accessibility. I tried enabling the native Google screenreader on my device. It only says "No text found at that location" when I try to read any of the Flutter demo pages in either Chrome or Firefox. In addition to being extremely hostile to people with disabilities, it will soon actually be illegal to build new products with accessibility-hostile tech like Flutter for Web for large parts of the European public and private sector:
https://en.wikipedia.org/wiki/European_Accessibility_Act
> we're still in beta
From these viewpoints that feels more like an early alpha product. In 2020 no accessibility support is a non-starter.
There are so many obvious problems with it:
- Everything relies on 1500 nested custom elements with hardcoded transforms to put them in place
- This breaks default browser interaction with the page entirely. Because what may look like a page is actually a bunch of absolutely positioned controls with absolutely positioned canvas inside them.
- Scrolling, one of the most important things in a browser, is broken. It's janky and slow (manually re-implemented?). I'm guessing containers have to be explicitly marked as scrollable with correct sizes, because resizing the browser window does not make content scrollable (try it with the demo you linked).
- Text is broken. Because it's rendered onto a canvas. So, all text interactions + accessibility is broken. Fonts are rendered incorrectly. I mean, on the demo page you can't even copy code other than through the "Copy All" button.
- Navigation is broken. Navigating the demo apps (which have more than one page) is not reflected in the url, so the back/forward buttons are broken
- Keyboard navigation is broken. Nearly none of the elements can be tabbed to. Except some buttons in demo pages. I guess they are explicitly marked as such?
- When elements can be navigated to by keyboard, they can only be activated by Spacebar. Even though Enter also exists. I'm pretty sure forms cannot be submitted by pressing enter, either.
- iOS-style date pickers are clipped in Safari
- 2D transformations demo is broken in Safari
It's just me spending five minutes on the demo site.
The effort is certainly commendable. It's not beta yet. It's possible you may want to scrap this and go the Figma route. They implemented their own rendering engine in WebGL: https://www.figma.com/blog/building-a-professional-design-to...
-
And clicking around seems to completely ignore my back button.
And hotspots didnt change to the finger cursor.
It looked pretty slick, except for those points. Oh well...
Basic features like selecting the text doesn't work.
EDIT: thanks for the downvote. But you don’t have to take my word for it, this sentiment is (privately) shared by Googlers themselves working on Chrome and PWAs.
It wouldn't be a good idea to believe that though. Flutter website are just canvas paintings, and have nothing to do with the web. You can't add new html or js to it easily. can't make much use of new improvements in the web world.
Most importantly, if you are running a business, flutter web isn't really accessible, so please don't use it for any non internal tools
Internal tools should not exclude people needing accessibility features.
I'm not even sure Go would do better on image size. Tree shaking does wonders here.
FFI is quite a PITA, though. Soomer or later you will have to interface some platform libraries, and Dart doesn't make that easy.
And here's a 500-line version of the Kilo console text editor built with Dart: https://github.com/timsneath/dart_console/blob/master/exampl...
Unlike the original, it runs on both Windows and UNIX-based operating systems.
To be fair, last time I looked into dart, the idea of FFI was ports, which was too overcomplicated and undercapable, if you needed something like Gtk or Vulkan. Looking into it now, I see the dart:ffi package is shaping up nicely, so I will have another look at dart again.
But even if not, if there is a way to (given might be slow and tedious) to compile what would've been flutter_engine.dll statically linked to your main (host) app, and maybe somewhat hinting here is how to find the "GetProcAddr/dlsym/etc." functions - if one is to look for them.
Further on, the generated from dart .so file can be embded (as resource? or slapped at the end of the binary/.exe?) + slapping all other resource - resulting in single app :)
I know it's possible, just not so easy to support it (I guess). It's similar to have java/python can be packed into one executable with all C/C++ ffi functions they call (at cost of some build time and effort to achieve so).
Then you'll have killer platform for video conferencing (zoom, bluejeans, etc.), messaging (slack, etc.) - and just single binary to deploy.
(Oh, on top of that slap a web server into it, and make it that if called with specific command-line option, now it acts as web-server, and the app is visible through the web).
This is what made me nope out of it last time I experimented with a Flutter module in my app. I'm still watching it closely though as it could be a great fit for other projects.
dart:ffi (https://dart.dev/guides/libraries/c-interop) is a recent addition to Dart and from where I stand it's a decent FFI system.
Maybe not as good as PInvoke in C# or ffi in luajit but better than, say, jni in Java (and any other FFI system that requires you to write glue code in C i.e. python, ruby, nodejs).
UI performance was fine (not any better than native though), but RAM usage was pretty bad, a lot higher than native.
Really fantastic iteration workflow, though.
ya, I hear you. It's a very common annoyance. We've been adding some support in the form of https://pub.dev/packages/pigeon to make the interop calls and data class passing more "direct".
disclosure: in the Flutter team
And that I'm worried that Google might just pull the plug as I feel the community is not in the position to continue development without Google's involvement unlike React Native.
Also, I'm not entirely sure about the future of Dart language now that we have TypeScript. Overall I feel flutter to be a risky investment, I personally would rather develop PWA in-spite of Apple's explicit hurdles(which I think may change after couple of anti-trust litigations).
The end of the blog post talks about modifications to the snapcraft build tool to fully support flutter.
Even with docker hub I can find the sourcecode easily linked 99% of the time.
Snaps built from GitHub with snapcraft.io include a manifest and the build recipe in the `meta` folder in the root of the snap. This includes all the info about the source code and allow you to reproduce it. Publishers can enable this on their own build infrastructure using an environment variable.
Many snaps also link to the source repository in the "contact <publisher>" link.
See the stats for the Skype snap package for the range of Linux distributions, https://snapcraft.io/skype
Not if I can help it on fedora, and all things I ever tried form there did not work properly.
> See the stats for the Skype snap package for the range of Linux distributions, https://snapcraft.io/skype
Most of those are recycled Ubuntu. Still don't get how the reasoning there works: ah look a garbage distro, let's fork it and make it better? Pick literally anything else.
Correction: it's "the app store for Linux".
/s
If Linux has an "app store" it's Docker Hub. But "Linux" doesn't actually have an app store, and attempting to claim that status is tone-deaf hubris.
Canonical makes garbage software that is superficially easy to use but flimsy and flaky.
I can only speak for my own experience but if I had to choose between using Ubuntu for the rest of my life and losing a finger, I think I would lose a finger.
There is no worse operating system I have ever used. It is Linux made by people who never bothered to open a manpage, software engineered by people who think engineering is waste of time. It is basically the Robert McNamara of operating systems, I can just hear him now, "there is no such thing as planning or engineering, just crisis management". Funny thing is they probably think crisis management is too big an ask.
One of my biggest gripes with Windows is that many parts of it feels like it was created by people who never even tried it because it should be obvious to anybody who ever tried it that it is a horrible user experience.
Ubuntu is basically the dumpster fire version of this. It's like someone read about dumpster fires and thought "wow, that sounds nice, how can we make an operating system like that".
It's a shame, though, because the primary advantage I see with Flutter is its superior UI framework. It's leagues better than the AndroidX compatibility lasagna, in terms of architecture and DX. So it really stands out as a cross platform solution not just across iOS and Android, but especially across the Android ecosystem itself.
Calling it an "app" is somewhat laughable, since it's just their website packaged up in a standalone web browser, plus a minimal amount of platform-specific glue.
Maybe the Linux version of electron is neutered in some way? I read article you linked and I don't know what bouncing the dock means, maybe that's an important native feature for mac users?
The slack "app" is just their web site and a web browser zipped together in such a way that it doesn't actually quit when you tell it to quit. Why anyone wants that I cannot begin to imagine.
And there's an option to turn that behaviour off, if you don't like it.
But I would prefer if it wasn't all Electron because it really does feel like the resource overhead is unnecessary. But if it wasn't done with this tech, we probably wouldn't have a Linux client at all, and maybe not a Mac one either, and personally I prefer it to feel like an application instead of having to run it inside a browser.
Kind of hoping Flutter helps advance the situation of cross-platform desktop/web things in a positive way.
When you Command-Q Slack, it should close completely (which afaik it does).
To quit it, choose that from it's menu or use the cmnd-q shortcut IIRC.
You mean hiding the browser chrome? Becuase I've been looking for a decent way to do this for years. Do you use a profile for every app? My rationale against this is that I'd like to share the plugins and settings.
It would be an interesting project for someone to create a KDE type of desktop environment in Flutter. Can it be done?
https://medium.com/flutter/flutter-on-raspberry-pi-mostly-fr...
A DE written in flutter sounds like a great accelerator/toy project for making flutter desktop polished and ready for the masses.
* Ungodly amounts of whitespace (seriously, look at that sidebar, look at that search bar. WHY? too much optimisation for what "looks good on a screenshot", maybe?)
* Undecipherable symbols where there's plenty of f#cking space to write labels god damn it
* I bet bad/nonexistant keyboard support (remember alt-* to navigate menus?)
* Ugly to look at (subjective)
> remember alt-* to navigate menus?
I do, but most people reading this probably won't, or there will come a time shortly when most people won't remember. I think most people are used to everything being a web/Electron app. Users do not expect a standard design language (like Win32/Swing/Qt) for desktop apps anymore (and indeed a Win32-style desktop app will soon look as foreign as a webapp since even the Windows shell looks like a webapp now).
Flutter lets you create "webapps" (which is the new standard) but with native performance and ability to make syscalls (being native).
The only alternative tech stacks to this end are QML/QtQuick, JavaFX, an embedded WebView, or embedded Chromium (e.g. Electron or Chromium Emebedded Framework)--all of which having some sort of baggage. Flutter's baggage is you have to use Dart. The alternatives all also require that you use some sort of DSL (QML (Qt), FXML (JavaFX), JS (Electron)) so that's not a unique disadvantage. (It really isn't a disadvantage--imagine the hell if there weren't a DSL for the View layer and every language had to have bindings.)
GUI programming is downright suffering no matter which way you slice it. There are no interesting problems to solve, unless you're working on the GUI framework itself. Flutter makes this suffering slightly better. I don't see how it's not an absolute good.
> we’ve seen more than 80,000 fast, beautiful Flutter apps published to Google Play
thus somehow tying the app looks to the fact that they use Flutter.
Unlikely (GNOME market share) and I can't see why it'd be that important. Platform protocols can be implemented around GTK and as far as I understand GTK is just a vehicle for getting X11/Wayland compatibility, the rendering itself will always be done by Flutter's engine anyway.
I wish they had more funding, tho. I find Reason/OCaml more compelling than Dart.
They have mobile platforms on their roadmap for quite some time now, but somehow the project doesn't seem to get much traction.
I guess, Dart would be dead by now, if it wasn't for Google pushing it with Flutter.
It seems good for everybody that Microsoft seems to be putting so much work into cross-platform dev in both .NET 6 and RN.
.Net 6 is going to be beautiful.
I started my career writing single threaded Palm OS apps (64k limit) - there was like 10 possible widgets with 5 possible events on each widget and rest of it was application code. Mobile app development is a different beast now. Yes, I sound like old-man-yelling-at-cloud. Is this table-stakes for all UI and App development?
The same way you would in any other code base, with the ample use of names and modules, and breaking nested components and logic into their own classes and functions.
The problem is that it requires discipline, or at least a standard style guide, to adhere to. It's similar to JavaScript in that regard, where bad practices can seemingly be ignored or even encouraged.
E.g. instead of writing
Widget helloWidget(BuildContext context) {
final db = Provider.of<MyDatabase>(context, listen: false);
return Row(
children: <Widget>[
Text("Hello, "),
FutureBuilder<String>(
future: db.username,
builder: (ctx, snapshot) =>
snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(),
),
]
);
}
Widget helloWidget = (BuildContext context) =>
let db = Provider.of<MyDatabase>(context, listen: false)
in Row(
children: <Widget>[
Text("Hello, "),
FutureBuilder<String>(
future: db.username,
builder: (ctx, snapshot) =>
snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(),
),
]
);I found i was over this fear in days if not hours, and continued to improve with my ongoing discovery of helpful UI components. Furthermore, defining your own components and breaking out inline functions into proper functions in your UI classes goes a long way, too.
Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. For the reasons i stated, i don't think it is as important as you might think.
If you haven't tried Flutter, particularly for syntactical reasons, i would urge you dip your toes in.
So does VS Code. I stared writing my first Flutter app a couple of weeks ago. I’m using VS Code and I have to say the IDE support is pretty great.
Regarding syntax and nesting levels, what I don’t is the `git diff` from wrapping the top-most expression in a new class, thus causing everything inside/below it to be indented further, even though only a single class was added. So e.g. wrapping an outer Column in a SingleChildScrollView causes everything inside the column to change in the diff because of added indentation.
I’ve seen some horribly large components that would be much better if split up.
Google should really advise this.
Are especially those two things configurable by user? I mean - there has to be no animations at all (why does anyone insist on animating theme change? that is just ridiculous), and black text, not grey. If not, that is complete deal breaker. Please tell me I'm wrong and one can configure everything there.
Single word: accessibility. More words: normal accessibility without needing to re-set whole system to be "accessible" just because one app developer can't behave.
Similarly information overload is an issue, but of course too little information is as well. That's on the designers, though, you can certainly build information dense apps with Flutter if you want to.
From what I can tell there seems to be a platform multiplier for animations to enable slow motion mode (an important tool for developing good transitions), which I suppose you could just set to 0. And if it doesn't it's just on the developer again.
Basically: I won't deny that it can certainly influence decisions (actually I think it's an important thing to consider), but ultimately it's not really the plattform's fault if a developer decides to make an app you don't like.
Some folks do not have the luxury to spend hundreds of miliseconds to seconds each time they do some action (and believe me or not, they do A LOT of actions per day).
Some people are actually using computers to do stuff as fast as possible so they have fast computers. Having fast computer doesnt automatically mean someone is willing to spend those resources on some eye candy.
Stuff moving around actually increases information overload as it adds to state one needs to track (moving object). To some folks this this even causes problems from medical reasons.
When it comes to information density, this should actually be up to user as well (lets call it compact mode for example) but at least to me it is not as critical as movements. Best would be being able to set "margin sizes" or something like that. And even that should be completely trivial given that no one should really write fixed-widget-position applications these days (i havent done so in ages, i'm using vertical/horizontal containers and spacers).
As should be application color theme as we are/were used to for a loooong time. But I understand that it isn't something Windows users are aware of, since each and every program there forces you to look at completely different interface that behaves in other way and has other ux logic.
I do think we can both agree that being able to stop all and every animation (including fading and whatever else in this category) is very important for user inclusion and accessibility. And since (as you said) slowing those down is needed for their development, "disabling" that feature should already be trivial. It just has to be available to user. Otherwise it's just an arrogant negligence and showing over-supremacy by "i know better what you like to look at".
I'm curious about Flutter and Dart bindings and calling interfaces for other languages. If you can integrate a Flutter front end with a back end language of your choice, that would change a lot of things for the better. The only reactive UI offerings for cross-platform desktop development with multiple language bindings are QML, which is great, or Electron with React, which is not so great if you want to use anything but JavaScript for your back end.
Ugh. No, Canonical, no matter how much you'd like it to be, the Snap Store is not, and will never be, "the app store for Linux". The last thing the Linux community wants or needs is a closed-source[0], walled-garden approach to distributing applications.
[0] For the pedants out there: yes, you can create Snaps with open tools, but the only Snap server implementation is closed.
Material is well done, except I really don't like the actual design. Cupertino looks more like iOS 7 than iOS 14 and lacks something…
Up until this time I've been using Kivy for the application, but it has a ton of issues and doesn't seem to receive much investment or support, even if you wave money around.
Works pretty well until you start moving or resizing the window but once I did it crashed the app a couple of times.
I also couldn't start the app fullscreen on a 4K display - it just displayed a small black rectangle. Other than that it felt fast and smooth.
It is an alpha though, so I thought it was promising nonetheless.
Snap: nope!
Anyway, hopefully this will cause a push for flutter support on other distros that are snap free.
Their announcement also pointedly remarks that the Flutter work will benefit "most distributions" of Linux. That's another good sign that this work won't be too tied up in Canonical's fiefdom.
Is anyone considering writing flutter + rust desktop apps in linux?
Examples:
- Chain.capture() not working in tests https://github.com/dart-lang/stack_trace/issues/50
- Document exceptions thrown https://github.com/dart-lang/http/issues/245
- It's difficult to find content using normal browser find https://github.com/dart-lang/dartdoc/issues/2131
- SecurityContext.setTrustedCertificatesBytes fails with BAD_PKCS12_DATA https://github.com/flutter/flutter/issues/39190
- Add remote port information to Socket errors (2013!) https://github.com/dart-lang/sdk/issues/12693
- setTrustedCertificates doesn't work. Causes HandshakeException all the time https://github.com/dart-lang/sdk/issues/35462
- badCertificateCallback is called with issuer certificate instead of leaf certificate for LetsEncrypt published certificate https://github.com/dart-lang/sdk/issues/39425
- No way to preload Image from assets before first builder (needed for smooth splash screen with images) https://github.com/flutter/flutter/issues/26127
- Provide function to get the current system timezone name https://github.com/dart-lang/sdk/issues/21758
- Create an easy and consistent Exception base class https://github.com/dart-lang/sdk/issues/2909
- Google please provide a Location module https://github.com/flutter/flutter/issues/31453
- Widgets inserted in MaterialApp Navigator Overlay don't get theme https://github.com/flutter/flutter/issues/39379
- [firebase_messaging] PHONE_REGISTRATION_ERROR on Android API 18 with Google APIs https://github.com/FirebaseExtended/flutterfire/issues/1471
- Use layer style for colors in Design Kit for Sketch https://github.com/material-components/material-components/i...
It's just slightly behind macOS and Linux in maturity.
In general desktop support is "early alpha" quality.
I'm hoping that in a year or two Flutter will be a solid option for mac/linux/windows desktop apps.
For now we have to accept that it's an alpha quality software.
In the interests of completeness, Flutter.dev really ought to bundle an android-like webview component in the core libs.
It really breaks the WORA value prop if you need to if-elif your way around platform specific impls.
I would be very surprised if that happens.
The last time I checked it seems that if anything changes then that bit-by-bit some components get replaced with new ones written in rust.
Also I honestly would be very surprised if Gnome would move from gtk-based UI to a flutter based UI interface.
I mean besides political reasons the amount of rework you would have to do is probably in a degree which makes it unpractical.
And in context of libre5 and some other developments there was a lot of effort to make gtk-based UI ready to be used with handheld devices.
Also Gnome has had multiple language bindings since the early days, most of them have more use across Gnome apps than Vala.
That's not accurate. There are some Gnome contributors opting for Rust. Gnome is not adopting Rust.
As for C++ it looks pretty official to me, it is even considered an internal resource:
https://developer.gnome.org/references#api-bindings
As for being done with me, who cares when the official web site sends another message.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/...
It certainly matters. Without a team of dedicated developers maintaining the project, the APIs it depends on will become deprecated, and it'll slowly become unusable.
Flutter touches a lot of APIs across many platforms. It's a complicated project that needs to support virtually every popular operating system in a visually and behaviorally consistent way.
Flutter also depends on Dart's maintenance, which is another project without significant open-source contributor activity outside of Google employees.
> I'd assume that those of us (and there seem be a lot of people) invested in it will continue working on it.
Having contributed fixes to Flutter and Dart, Google does not go out of their way to build an open-source contributor community around the projects. I would be surprised to learn that any significant support is provided by open-source contributors to Flutter or Dart.
Nonsense. Even though it is open source, if Google drops it it will be effectively a dead project since the vast majority of the work is done by Google, and Flutter still isn't a mature project.
The downside is that in order to produce iOS or Android looking UIs someone needs to create every iOS and Android standard widget, with the same behaviour. If those widgets change in future versions of the OS, or new ones are created then more work needs to be done.
This is fine in the current project setup - the work is worth it to Google, but without a corporate backer that's the sort of thing that will fall behind.
And if they drop Fuchisa and flutter has enough (relevant) apps using it in the Android Ecosystem they probably would keep it still around.
But my guess is that one long play Google want's to keep open for them is to start replacing Android with Fuchisa and push for a ecosystem where they have control more similar to apple. I.e. directly push updates to phones without the phone manufacturer as middle man. As this is a source of a lot of problems with Android making it less competitive against iOs.
I hate to say it, but this is beginning to look like a real possibility. It looks like Google has been implementing into Android a lot of the modular, "make the system easier to update" aspects of Fuchsia with each release of Android. I think Oracle's continuing fight to make Google pay financially for using Java is doing more to keep Fuchsia alive anything else. If Oracle relents then it's possible that Nest devices (the only Fuchsia-based products currently shipping afaik) could eventually switch to an IoT version of Android... but since Oracle is a litigation firm that also happens to sell databases I don't see them ever stopping the lawsuits.
The runtime remains ART, though, but that wasn't the issue in the lawsuit.
As one can follow up on AOSP Gerrit comments, code from OpenJDK gets cherry picked into Android.
https://android-review.googlesource.com/q/project:platform%2...
as for java.* I don't see how one could have issues, for example Kotlin use and extend the java standard library without any lawsuit. I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Their reimplementation (dalvik & ci) is the root of all evil and is technically a mess with antic java support. It's such a shame that we can't have ZGC or senandoah on android...
Your belief is firmly incorrect. The "copied code" claim was for a 9-line rangeCheck function and was otherwise dropped. The main claim is entirely that the java.* API definitions are copyrighted, and therefore Google's clean room re-implementation of the APIs still violates the copyright of the API itself.
Which is a lawsuit that Oracle won, by the way: https://en.wikipedia.org/wiki/Google_v._Oracle_America#First...
The open question at this point is whether a clean-room re-implementation of a copyrighted API for the purposes of compatibility is considered fair use or not. Which so far Oracle has been winning. Which means approximately everything is in copyright violation in the tech world. POSIX, for example, took the API from commercial Unix OS's of the time. The current owners of Unix, Micro Focus, could sue approximately everyone if Oracle wins.
Not "end of story" at all - why should Android switch? You mentioned ZGC & Shenandoah, but why do you think that would be a benefit? Have you actually tried benchmarking your app in ART vs. OpenJDK? Do you have any clue at all if ZGC would even be an improvement in your workloads, or the workloads of a typical Android app for that matter? There's a lot of really cool work going on in that space, but for example ZGC's NUMA awareness won't do diddly shit for your Android app, so things like that are pretty moot.
Meanwhile ART has optimizations that OpenJDK doesn't, like importing profiles to AOT compile parts of an app that's never been run locally before: https://android-developers.googleblog.com/2019/04/improving-...
Similarly OpenJDK's startup time & memory usage is historically quite bad, because it's just not a primary use case for them in the same way it is for ART. OpenJDK finally got some improvements in those areas very very recently ( https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht... ), but it's still not good and far from being obviously superior on all metrics to ART. And ART isn't standing still, either, with new improvements like even faster incredibly fast FFI support: https://android-review.googlesource.com/c/platform/art/+/132... Which is important for achieving things like 120hz 2D UI rendering while also running on incredibly slow in-order non-speculating power saving little cores. Which is a use case & scenario OpenJDK has never been asked to deal with nor optimized to handle.
OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. After all, nobody ever accused a Java desktop application of being fast & responsive.
Indeed, that is why since around 2000 there are multiple JVM implementations, including plenty of them with AOT and JIT cache capabilities.
The now gone WebSphere Realtime JVM already supported importing profiles for their AOT/JIT compilers.
And in what concerns phone devices, Microsoft did it first with their Cloud compiler for MSIL on Windows Store, first with MDIL/Bartok taken from Singularity for Windows Phone 8.x, followed up by the .NET Native toolchain on Windows 10.
Google's marketing is good, but not very influential for those that actually know the Java eco-system and the offerings available across all major vendors.
Also here is the confirmation that they will carry on cherry picking OpenJDK features instead of full compatibility.
" u/dessert_maker: We pick additional OpenJDK APIs for each Android release based on inputs from our developers. Android 11 will support additional APIs from OpenJDK 9. Everyone that is developing in Java and Kotlin should be able to take advantage of these newer additions.
In addition, we have added library desugaring to the build toolchain in Android Studio to make a wide variety of APIs across OpenJDK 8, 9, 10, and 11 available regardless of what version of Android your app runs on.
We expect to add support to the platform for more modern APIs (11,13,14) based on the level of adoption we see from our broader developer community in future versions. As mentioned in last year's AMA, making the overall runtime updatable is something we are thinking about as part of Project Mainline."
-- https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_...
So thank you Google for Android Java and like J++, forcing Java library authors to code specifically for Android, or just ignore it and focus on the myriad of JVM compatible implementations instead.
If that's the case, it's higly unlikely.
In terms of migrating away from Android, I think they will use the newer AndroidX packages as the future abstraction layer, which would enable them to replace the underlying runtime with something more native for each platform. It would be a compilation target for Kotlin as well as Dart. All while not deprecating the massive amount of production code out there. But, this is also just a guess.
https://developer.android.com/reference/androidx/packages
It's current implementation uses classes that are part of the Android layer, mostly the old support library plus some new abstractions like LiveData and Room and Navigation. I see no reason why you could not use the public interface of that library as a compatibility layer for application level code and let it run on a different platform.
Not today, but given the fact that you can't just kill the worlds most used operating system, you either use virtualization like Apple now does again for ARM (and before when replacing Motorola with Intel) or you change the underlying dependencies of the libraries used and compile again.
Google needs to work on untangling it from Dart and start actively working on Kotlin support. Dart is actually compiled to native code and the most of the UI stuff is basically written in C++. Kotlin has a native compiler already, so that's not necessarily a show stopper. And given the huge amount of Android Kotlin developers out there, it's kind of an obvious thing to do. Yet they choose not to work on this.
Fixing this would result in a lot of existing developers having an easy transition to flutter that are currently not planning to go there.
The reasons they are not doing this are entirely political and can be summarized as "not invented here".
Kotlin is a problem for them because it's 1) popular 2) the main language for Android development and 3) controlled by a company that is not Google.
Flutter is their attempt to fix this. They can't kill Kotlin because it's popular but they can try to replace it and nudge developers away from it. The problem for them is that Dart is not good enough. It's a hard sell and effectively a downgrade if you are used to Kotlin. They've been trying to fix that by adding features to Dart that are clearly intended to narrow the gap.
Fuchsia exists for the same reason. Yes there are technical reasons for it as well but the real reason is control over the ecosystem. The combined strategy is risky and dependent on the success in the market of their pixel phones. So far this is not looking great. Google convincing OEMs to jump on the bandwagon is going to be very dependent on them being able to launch a fuchsia phone. I'm pretty sure none of the OEMs is keen of having more Google control and oversight. So effectively, Google would have to launch a Fuchsia phone, make sure it becomes popular, and then twist the arms of all their OEMs to abandon Android. Failing to do that would result in a new phone platform with tiny marketshare that users, developers and OEMs can safely ignore. The mere prospect of that is the reason I expect it will never make it to market.
Flutter may or may not survive that decision. What's going to be interesting is what everybody else does. Flutter and react native are so far the two dominant cross platform approaches. React native could get a lot more interesting with things like wasm opening up that space for Kotlin and Swift developers. A lot of Kotlin developers favoring React Native over Flutter would be a big problem for Google.
I have no love for what Android has become and where Kotlin is going. The web today feels like a PDF...huge amounts of movement but not necessarily progress.
I hope more than anything that Flutter continues to gain traction. To my mind it is perfectly reasonable for next generation tech to write to the canvas with the latest widgets as long as there is good accessibility support.
I think there's a case to be made for sticking to the defaults for consistency's sake but Flutter is just as native as any other UI toolkit on Linux.