611–620 of 748 posts
> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…
Which flutter apps do I likely use?
Earlier quoted context omitted.
My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them. A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of…
What are some examples of good 'impossible to tell' UIs built with flutter on mobile?
I would love Swift to be forked so it becomes more usable outside of Apple's ecosystem.
Earlier quoted context omitted.
Sure, but not every cross-platform app developer wants their app to look "native to iOS". Especially if you want your app to look the same on all platforms and/or have some creative design.
I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun. I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. Of course, I recognise that, a. most peopl…
E.g., if you have Instagram on your iPhone, an Android user won’t be able to tell you “just click on this, this, then this to change your XYZ setting” because it will be in a different place than the Android app if developers follow native conventions 100% of the time.
The fact that Spotify or Instagram or any of those other platform-agnostic apps look and function the same on every platform is a huge benefit to practical usability.
I think the only time when nativeness matters is when you have an app that’s doing stuff that’s closer to being “low level” to operating system features. For example, an app that performs file system management, I don’t want that to have the exact same UI on Mac, Windows, and Linux, because those platforms have different conventions for where things go and how files are represented.
Earlier quoted context omitted.
I can’t imagine using Flutter for desktop development if only because like most newer UI frameworks, it’s mobile focused and doesn’t come with important desktop widgets like tableviews/datagrids and treeviews.
Canonical is contributing to desktop and is using Flutter for a lot of their desktop components now.
> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…
Haha. Oh, most people know! They might not be knowing it’s Flutter to be specific but they sure know it’s some hybrid/non-native crap. I recently started using Ente migrating from Authy and goodness it feels and looks awful. I wish 2FAS had a desktop app. There was a native alternative that allows exporting codes. (This is not against Ente devs. I am sure they are a small team bringing out a FOSS product. This is jus…
Earlier quoted context omitted.
you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
Do you have an example of a texting app that doesn't use native input? This just straight up doesn't seem accurate.
Earlier quoted context omitted.
What are some examples of good 'impossible to tell' UIs built with flutter on desktop or web?
My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them. A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of…
Browser zoom also only ever breaks if you are fighting the Browser's layout engine instead of embracing that. Just don't do that and it works fine.
Of course most web "apps" shouldn't be apps in the first place but if they must be "apps" at least stop reimplementing a crappier version fo the native browser functionality.
> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell. Electron-based apps are also everywhere and they are through and through bad and a step backward. I would take caution to not do appeals to authority. I would extend this assertion over any javascript-on-a-webview-based GUI framework.…
There are three ways cross-platform UI frameworks draw UI. 1) wrap platform controls, 2) use webview or 3) use low-level graphics API.
Option 1 has to design controls to cater for the lowest common denominator. And there is a higher chance that an OS update might break things that in options 2 or 3. Being based on wildly different APIs (for each platform) increases complexity of creating and maintaining custom controls.
Option 2 has to render UI through a high-level declarative language made for documents.
Option 3 uses same APIs as native UI frameworks use. It's basically alternative implementation of an UI framework. Downside is that it has it's own look and feel, which is mostly an issue, if native UI framework is more polished.
Flutter, being option 3, is more similar to a game engine, than to Electron. Low-level graphic APIs maintain good backwards compatibility, so OS updates don't affect the framework much. Less maintenance is needed.
Good hot reload makes use of XML unnecessary and allows to declare UI in an actual, more powerful programming language. Overall, this removes another layer of complexity. (MS take a hint)
AOT compilation enables fast startup times and less pauses. Which is good as end users are opening and closing applications all the time.
Earlier quoted context omitted.
Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?
Existing food delivery apps are not only indexable by google but actively make sure to spam the top google results for all possible food related searches. You couldn't have choosen a better example to disprove your argument if you tried.