They are, to be honest, pretty terrible, but for reading in the middle of the night when I can't turn on the light and use my regular Kindle, they beat using my phone.
Is it so hard or e-ink is something that is not manufactured there?
But I wouldn't try anything else on it, wouldn't want it to explode.
If you want to have a glimpse how Android team feels about Flutter, just check this year's Android Fireside and how they react to questions about JetPack Composer vs Flutter, or what should be the way to develop on Android.
Mostly political correct answers with some pauses trying to think how to best state them, and facial expressions revealing how they rather not answer it at all.
Let me make one thing very clear: nobody gives a flying fuck about Fuchsia. Nobody. It was and remains a project that people who want to do something fun go to when google thinks that they are valuable enough to keep around.
It is not the future of anything. It is not even remotely capable of doing anything serious. For fuck's sake, go look at the code - it is all out in the open! The scheduler is a JOKE. SMP support too. Power management is nonexistent. Driver support? HAHA!
The most important part about message-passing microkernels? The tuning for the message-passing. None of that is anywhere to be seen either...
Oh, and app support.. Where is that? Yeah, one could go the chromeos way and try to make an android compatibility layer - it is very hard and never 100% compatible, and relies on having a linux kernel. And then why bother with a new OS? Or one could go the microsoft way and pay app developers to write apps for the new SDK. How did that go for windows phone? Or one could make a VM and run android in it, but then why bother with a new kernel anyways, if everything will be in a linux vm? Linux runs just fine on hardware as is.
Basically a group of people did all the fun parts of writing an OS and did not do all of the boring hard-to-get-right pieces.
I have no idea why the whole world keeps thinking Fuchsia is serious, when they can see the code all along and note that it is a joke.
https://9to5google.com/2019/01/22/google-fuchsia-poaches-mac...
But yeah my impression is that it isn't meant to replace Andrdoid, but that they want to use it in places where a full Android doesn't make sense, like in their smart display devices or other future categories. Or maybe it's really just a retainer project for engineers.
Another reason people think it's real is that there was a lot of press a couple of years ago about something called "Andromeda" that was meant to combine Android and ChromeOS into one project. This was then supposedly shelved in favor of Fuchsia:
https://www.vox.com/2016/10/3/13149670/google-new-os-androme... https://twitter.com/hallstephenj/status/871456529160863745
But you'd probably know more about that than me :)
It seems to me they're trying to not fall into the same trap as Microsoft did trying to protect their dominance with one OS over all other innovation.
That said, the Android team really seems to hate the flutter team ( Jake Wharton lol) also the main flutter guys all come from chrome like Ian Hickson so if there was bad blood from chromeOs that will stay.
Personally I hope Flutter succeeds because I really hate the Android sdk. Fuchsia just seems like something they're experimenting with and putting into smart clocks or whatever.
I believe, that if they were both going into the same direction, maybe Longhorn would have successes, instead of having the detour of rebuilding its ideas in COM, going through multiple iterations of it (WinRT, UAP, UWP) and then complaining that most devs use the .NET projections anyway.
What I dislike in Flutter is its dependency in Dart, yet another eco-system starting from scratch, just to save a programming language, kind of.
As an Android developer I am kind of wary of how they push Kotlin for Android. I'm sure it is good, and I enjoy learning a new languages, but I already have a code base that I am worried they are going to make me rewrite.
Basically Web apps packaged in such a way that native APIs can also be exposed as browser APIs.
The Chrome/ChromeOS teams started with it, and Microsoft adopted them to UWP as well.
Safari also kind of support them.
https://developers.google.com/web/progressive-web-apps/
https://developer.microsoft.com/en-us/windows/pwa
Plenty of talks at Google IO and BUILD.
For example extension methods or suspend functions.
Hence why there is a guide on how to write Java friendly APIs from Kotlin.
Jetpack Compose is an interesting story, looks like it sprung into existence as response to Flutter, without any concrete ideas on how tooling should look like and total disregard for the ongoing efforts to sell constraint and motion layout editing on the graphical tooling to android devs still using the old layouts.
Having watched all SwiftUI tooling related talks, and from experience how Android Studio has evolved, I don't have great hopes that by Google IO 2020 we will see demos at the same level as WWDC 2019 SwiftUI ones.