Flutter & Dart

1

really aimed at @scott

what are you using for designing / building flutter / dart apps ?

would that also work for building flutter apps for the web ?

2

Norm!

So Xojo IDE is a WYSIWYG editor that your “paint” your interface with the IDE and the code to make it so it so it automatically done under the hood. For flutter I use VS Code with Hot Reload. If I am doing pure dart its cli and that is just done at a prompt.

Google’s Flutter Team (and to an extension the Google’s Dart Team) suggests using either VS Code (VSC) or Android Studio (AS) for doing Flutter. AS is pushed as it is their tool that they can push you into Android based devices. I used VSC and its plugins are just as good as the AS ones. BUT if you like $EDITOR as long as it is a true text/ascii editor, you can use it. you just loose out on the Hot Reload/Hot Refresh features. I know people that do all their coding in VIM.

When developing for Flutter, you either compile in AOT (Ahead of time) or JIT (just in time). AOT is for compiling for the final (semi final) product and is smaller exe (or apk or whatever). But if you want to make changes you have to recompile the whole app and go through the full build process. The “Hot Refresh” model (aka JIT), is a large exe() but when you Hot Refresh it just recompiles the sections of code that have changes since last titme and updates the running code with the new code. hence the large exe(). JIT is not designed for deploying apps with. it is designed so you can do rapid development.

if you are using AS/VSC with Google’s Flutter plugin, whenever you hit save in the editor, it does a Hot Refresh, compiling all the changes and pushing it live to the “device” (for mobile its either a real mobile device, or emulator. for desktop, it just runs next to the editor).

now back to the Xojo IDE you “draw/paint” the interface, with Flutter the interface is all code. But as you are writing the code for the interface, you can just hit save and instantiously see what the new UI looks like. Every object on the “screen” is a “widget” and unlike the control is Xojo that has 100 features, the Widgets are kept thin/lightweight. But there are some Widgets that you can not visually see that get added to other Widget to change their appearance/functionality. It took me a little while to get used to the new thought process but now seems very obvious.

Now the question Norm that I have been avoiding (or looks like I have been) is WEB. I have not done any WEB work myself. I am pretty sure it is the same basic setup as mobile/desktop but uses CHROME as the browser to view the app in.

talking about CHROME. Google has a thing called “DevTools” that in realtime gets down into how an app is working. Sorta like how Apple’s Instruments (I believe that is what it is called) works, This doesnt work with AOT code but the JIT code. And DevTools runs in a CHROME browser. Now for those of use that dont run CHROME but something that is based on CHROME (aka Brave Browser), there are unofficial docs on how to use that browser over chrome.

Now the one thing that I have not mentioned yet is that for a given app you can use the same code base for desktop, mobile and web. in the “lib” folder is where all the code is. then there is a mac, windows, linux, android, ios and web directories for the platform specific libraries (those are all provided by flutter/dart and rarely needs to be touched other that changing the default icons). then when it compiles your code, it compiles it for a specific platform with the specific platform libraries from its directory.

now you get to specify which version(s) of a plugin to use in you app. Like use version 2.1.3 or later but lower than 3.0.0 (generally when going from version N to N+1 there is code breaking api changes or potentially). or you can say use version 2.3.4 and it will only use that 1 specific version. And if you have a dozen apps on your system you are writing/supporting they all can have their own mix of versions independent from the other libraries/code on your system. This include which version of the flutter you are working with. you just note which version(s) you want to work with in the pubspec.yml file (also names the app, dependencies for both building and developing(1) the app, etc.

(1) you might need some plugin to help develop the code but not in the final build. like a test harness (comes to mind).

Now to get back to the original question I use this:

  • VS Code with Google’s Flutter plugin (which installs their Dart plugin).
  • plus a few more plugins that just make life easier.
  • git for source code management (with git GUI client).
  • iOS emulator (on the mac) for iPhone/iPad dev
  • Android emulator (on either mac/windows/linux) for Android phone/tablet dev.
  • for desktop, I have use an OS that I am targeting so either a physical or VM with MacOS, Windows or Linux on/in it.

for a reference point I was working on a GUI app for an embeded Android device (displays dashboard info on a TV) for a friend’s business and I was doing it on an 8yo Dell laptop with 4gig RAM and a 2nd GEN i5 processor (yeah that is old as ****) and running a light weight version of Linux Desktop (some desktop GUI’s take more horsepower to run than others), I was able to develop the app with no issues and the system was fast enough that it didnt hinder me. Now normally I use a machine that is 1-1.5yo and has much more resources.

sorry for the mind dump. its friday (aka “Dont Break Shit Friday”) and I wrote this instead of breaking thus at work. :slight_smile:

please let me know if you have any more questions…
–sb

4 Likes
3

this answers a pile of them

thanks for the info !

4

looking for flutter/dart nerds, in the INN, or am i back to being alone in the universe?

5

@Scott was one of a very few I knew that was using it

I’ve poked at it a bit but wouldnt consider myself fluent in either

6

Well shoot it seems Scotts emails bounce now so I’m not sure what he might be up to

7

One thing that users here, including me, might find useful is to take something familiar (like Eddies on iOS) and work through a series of tutorials to “port it” to Flutter & Dart

I figure I’ll tackle that in C# for iOS and Android one day when I get the time :slight_smile:

8

it is very different. it’s been an interesting few weeks.

9

The showstopper when I looked at it was that you couldn’t build multi-window apps (the workaround was essentially multiple instances). It looks like they’ve been talking about this for years and there is supposedly active work on it, but still not done, according to this (with links to the relevant issue). That the referenced discussion thread has been open for over five years does not bode well… basically, it wasn’t designed to make desktop apps.

1 Like
10

Yeah flutter & dart were, as far as I know, aimed at mobile devices initially and there multiple windows arent a thing like they are on the desktop

They have been discussing them for a white though

11

that is a great point that i hadn’t thought about. we haven’t written a desktop app in…omg it’s been 14 years.
but, since i’m thinking about switching us to something else, this is definitely something we’ll have to think about, because we would either have to:

  • convert desktop apps to web or
  • use a different tool
12

I have hunted and there are very few that try to address

  • web
  • desktop
  • mobile

Certainly you’ve seen Thorsten mention java with various tools (codename1, vaadin, etc)
And I’ve tested out C# and various IDE’s on Mac & Windows

A single project file that can be set up to generate multiple compiled outputs seems to be very doable - with each tool handling this in a different way

13

Why not just use HTML/CSS/JS?

Server software can be written in almost anything.

14

Increasingly, I think this is the future. The native APIs across all of these platforms are just too different, and with good reason. Any abstraction layer will have shortcomings, as we’ve seen. Web technologies take a different approach that naturally embrace a range of platforms. Users have become used to the variety of web interfaces, and with the OS developers weaving web or web-inspired UIs into native desktop and mobile, it’s starting to all look the same anyway.
I’m not saying this is a solved problem or that web technologies on desktop are great yet – they aren’t – but there’s a lot happening in the space.

1 Like
15

this seems to be the primary difference between html/css/js and other solutions: there is more activity. otherwise, it is an abstraction just like every other solution is an abstraction.

16

The only way to do that completely perfect: Android with Kotlin or Java and IOS with Swift and Swift UI. That’s the native way.

Best abstraction could be native UI with Kotlin multiplatform mobile.

With a non native UI we can speak about Flutter/Dart or Java / Codenameone. But Flutter has the better UI looking on Codenameone. No question.

Javascript isn’t the right way in my eyes. But everybody has to vote his own eay of doing things.

17

Well, of course; computer science is the science of abstraction. But my point here is that these two areas are abstracted from entirely difference bases. Traditional cross-platform UI kits are abstracted from the intersection (more or less) of the underlying UI kits they are attempting to cross. It’s the curse of having to deal with the lowest common denominator. They are built on widgets contained within windows (except mobile doesn’t really have those, which is why that breaks), etc. The abstractions map to actual underlying widgets, which is how you get your native look and feel (sort of).
HTML+JS+CSS comes from a completely different heritage: it’s based on documents, which are realized today through the DOM as the primary abstraction. In some sense, this is a bit of a force fit to make these behave exactly like a native interface; SPAs kind of do this, but no one is really fooled.
My points are:

  1. Users have been exposed to so many different looks and feels, they mostly don’t care about native, and in some cases (Windows…) couldn’t event tell you which of the many generations of UI frameworks is the native one. Given this, as long as a solution is performant, a desktop UI made with web technologies doesn’t seem to bother typical users, and in some cases, they prefer it (I’ve heard users say they think an actual native app looked “old fashioned”).
  2. There is much more activity focused on this second abstraction than on building new approaches to the first. In part, that may be related to the argument in (1) extended with recognition that a ton of work has gone into browser rendering – certainly the most complex UI rendering engines, right?, so why not just leverage that?

I should note there’s another class of approaches – render your own UI – that we see with immediate mode and OpenGL toolkits. The problem with these is someone has to build everything from scratch, relatively speaking, instead of building on top of existing stacks at a high level. (BTW, this is actually how Flutter works – it ultimately renders down to Skia and does not use native controls). Web technologies are somewhat similar in this respect and do a lot of the work for you (though, again, they are derived from a document-centric model). Moreover, via WebGL and WASM, they can effectively subsume these at native speeds (though this is not how Flutter for the Web works).

2 Likes
18

The inconsistencies between apps on a platform can be worse than between webapps too.

Windows IIRC has 3 different cleartype font renderers depending on the UI framework used. You have the older windowsXP one, the Windows 7 one, and the one that renders text for the universal windows apps. The newest one doesn’t render text consistently either.

It’s caused me a lot of pain.

19

Yeah, Windows is my go-to example of “exactly what is the ‘native’ UI here?” But even MacOS has morphed over time; in its case, it’s more about fundamental layout decisions. Compare the latest system preferences with previous iterations, for example.

1 Like
20

Native UI is always the best way on mobile devices when it shall be an award winning App. But what is when and if functionality counts? Which implementations are the best way? How can I reach my project targets? What about the ecosystem? What is with existing business logic? Answers to this questions may lead to another platform decision for mobile development. There can be kotlin, Flutter/Dart, Java or C# more interesting. Or even JavaScript, why not?

The question in the middle should always be: what do I need to do. With Flutter for example you can style beautiful apps for Android and IOS which you can also port to Desktop. But nobody has business logic in Dart language. Also you can compile CodenameOne apps for Ios, Android and Desktop from the same SourceCode. Here you can use your business logic on the entire platforms. Every Developer needs to consider what is the best choice for me and my projects.

There is no best way as we know all. And it becomes even more complex. You can use native UI for IOS and Android with Kotlin Multiplatform mobile. And also for Web and Desktop with the fitting UI. All possible. For me there is no best way but the needed way for the project.

1 Like