321–330 of 343 posts
Earlier quoted context omitted.
"I just don't trust it to be around long enough to be an investment for me." Normally I would be inclined to agree with you given that this is Google, but the good news is that Flutter is open source. So even if Google discontinues internal development on it, it's likely that the community will continue it anyway.
That's what I thought about Tcl/Tk.
I don't understand why Apple is the only one left that uses a strongly typed pre-compiled native programming language. It really isn't hard to use Swift compared to other programming languages. And it's a really nice to use, safe and if you want it to be also a language that allows you to write really fast algorithms.
As a UI dev, I'd much prefer the hot-reloading that you get from Flutter, React Native, and web UI development though. But I still care about battery life and global warming so it can be hard to justify the flashy new stuff for most the UI development I do, which is mostly just list views.
I'm also weary of the post-mortem debugging experience for these higher level frameworks. C++ is nice for this given that usually the OS and UI frameworks are implemented in it too, at least on Windows.
Disclosure: I work at Microsoft.
Earlier quoted context omitted.
Really? but Fuchsia isn't just a mobile operating system -- I think they want to own all the software at almost every level. I wouldn't be surprised if they started running their own hardware and laptops with Fuchsia as well if it was good enough. It's a bit cynical but I think they might even want to just bin linux as a base for Android and migrate off of it completely, get their notebooks/chromebooks on Fuchsia, an…
> I think they want to own all the software at almost every level That's what everyone wants to do. Guess what, Google might be big, but Android is big because Google has many partners. If they try to pull that off, all their partners will drop them like a hot potato. And I agree with you it's probably to ditch Linux cause Linux has too much political baggage, i.e. they want to fully control Fuchsia. For us, it's pro…
At that point, will they have a choice? I mean most partners already bow to Google's control over AOSP -- if they said tomorrow that android was actually switching to run on top of fuchsia (let's say they did all the work to make it happen, so it was "seamless"), everyone would just be like... "ok".
While I'm not sure I necessarily want Fuchsia to fail, I'm 100% with you on it being likely better for the world if google didn't own everything...
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 c…
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 `…
Ha, I wish! I've been down this road a few times and this list came from contemplating some of my old battle scars.
> ...as `coldtea` points out below, this is not really an issue in today's ecosystem.
That's not quite the same thing as it not being a problem. I know it can be done, but it's harder than when using native controls. This is something the "big dogs" can handle (they can bring massive resources to high-profile projects if need be) -- especially if they control the framework.
> ...cases where code-heavy app sizes have actually hindered app downloads... Well, look around for people complaining about bloat. It's not usually the download itself, by the way. Memory is filled and runtimes have to initialize, buffers allocated, etc. It all takes time and uses runtime resources. This is fine to a point, but once you use too many resources or take too much time, it has a negative impact on the app (and as the developer, you have to deal with it in some way... e.g., perhaps spend time to alleviate the issues or perhaps walk away from lower-end devices). Any app, no matter the tech used to develop it can face these issues as it grows. But with an engine you start off closer to the limits and have less control over resource usage, so you generally reach them more quickly.
> Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
Hey, if flutter solves cross-platform text in 1.0 as you suggest, then good for them. Believe me, that's a massive accomplishment. (Though I'll note: if they aren't using native facilities, they'll have to duplicate them, which goes back to the point on bloat.)
> Is this a remark on an incomplete cross platform framework...? No, I'm saying apps -- at some point -- generally eventually need to incorporate third-party libraries/tools to best accomplish their purpose. A PDF generator, a .csv parser, an image processor, an AI library, whatever. (A framework can't include an API for everything and shouldn't try, so it's not a matter of an incomplete framework). However whatever third-partly library you're interested in probably won't provide direct support for your framework, so you'll have to figure it out and do it yourself. It really depends on the library and the framework and how/whether they overlap how much harder this is.
E.g., suppose you want to incorporate an image rendering library of some sort into your app. The library supports iOS and Android and can output to UIImage on iOS and Bitmap on Android and their site provides samples showing how each of these work. But you're using a framework that has "XImage" and "XImageView". So now you need to delve into the platform's "XImage" to figure out how to load a UIImage into it on iOS and a Bitmap on Android. Maybe you find it works in terms of OpenGL textures and you realize going through a UIImage/Bitmap is an extra, inefficient step, so now you're learning about how to load directly from the library output into an OpenGL texture and you learn OpenGL textures can have different color formats so you start using the complicated low-level API of the image library to get output in the color format of the OpenGL texture. Whew! What would have been a few lines of code in each native app turned into a couple days of work, but you're done and release it.... and shortly thereafter, you start getting reports that the images are flipped on certain devices. Uh Oh... Now, maybe flutter doesn't have this particular problem, but this is just an example. This kind of thing will pop up as you integrate the third-party libraries you use with the UI platform. The more "opinionated" the UI platform is, the more quickly you'll run into these kinds of problems.
> This feels like an emotional assessment of having to learn something new. Oh, come on. I'm pointing out an additional cost to adopting this kind of platform. That's a real concern to anyone developing apps, not something you can dismiss as an "emotional assessment" (Not sure even what that means -- laziness?). Note, this is an additional cost since you'll need native expertise in any case.
Earlier quoted context omitted.
Why would they? I don't see any guidelines it violates, other than the loose suggestion to have your app be reasonably designed.
> Why would they? For reasons of business strategy. With this toolkit, the AppStore might lose its exclusivity on a lot of apps. Exactly what Google wants, and Apple does not want.
Earlier quoted context omitted.
Only one team needs to sync with another in this scenario. It's also assuming that the Flutter team wouldn't consider do that considering they have that kind of information available to them -- it's in their best interest, after all.
If only one team needs to sync, how is it any advantage for Flutter and Android to be within the same company? How is the situation any different from Flutter and iOS? I agree with the other commenter -- don’t expect any close cooperation between Flutter and Android because that’s just not how Google (and other huge companies) tends to work.
Earlier quoted context omitted.
or canvas or kodi (which has been improved now to not refresh the entire screen.)
you mean this Kodi https://kodi.tv/ ?
Earlier quoted context omitted.
> I assume things have changed since then Yes, tremendously so. It's still XML for basic UI, but Kotlin is the primary language of choice these days, Android Studio is a solidly world-class IDE, and the emulator is very fast. > but I wonder by how much and if Flutter's workflow skirts any of these issues altogether. Flutter uses the regular Android emulator, and although you have more editor choice the recommended wa…
Is there any alternative to XML? How often do you find yourself hacking XML directly?
It works fine.
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.
They just announced desktop and web support
Earlier quoted context omitted.
Tcl/Tk is 30 years old. I would be willing to bet my retirement that none of the now-popular presentation technologies will be mainstream 30 years from now. They just don't have that kind of shelf life. If Flutter lasts a decade, it will have lived gloriously. React should be so lucky.
React will definitely make 10 years. It’s almost at 5...
I have nothing against React (I use it) but I see no reason to believe it will not follow the lifecycle of every presentation technology that came before. Ten years is a long time. Of course people will be still be using React, but then people are still using GWT today.