Google Flutter and AWS Lambda for a serverless mobile app
read.acloud.guru
read.acloud.guru
On the desktop, most Mac apps looked like most other Mac apps. On the web, authors often created their own components, and could completely customize their look. Mobile has largely tacked towards the web, where Airbnb looks more like Airbnb than it does like any other Android or iOS app.
Spotify uses its own skin, as does Windows iTunes. NetBeans uses Swing with the Nimbus look-and-feel. Firefox and Chrome use their own toolkits (e.g. on their Settings windows). Even Microsoft Word feels like 'its own thing'. UWP applications don't tend to feel native. At least RoboMongo and the CMake GUI feel like proper Windows applications, but they both use Qt.
Flash/AIR and desktop Java are other well-known technologies that controlled how the actual pixels were drawn. If you wanted a native-looking UI, you had to mimic one in framework code.
React lead Tom Occhino pointed this out at the React Native launch. With the React Native approach, your app matches the iOS N+1 style when the user upgrades. With the Flutter/Flash approach, your app matches N+1 when you upgrade your version of Flutter and push a new release.
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
Unless Apple starts implementing its own cross-platform sdk in swift... But judging by the slow pace at which swift is moving (compared to its "worl domination" ambitions, that is), i don't think it'll happen anytime soon.
Well of course it doesn't do that, they explicitly avoided it. And it's as you said, to make apps look and behave the same on all platforms. But that doesn't stop you from using their "Material" components on android and "Cupertino" components on iOS.
yes! And for those who have struggled with getting RecyclerView to work as expected, or with changing a text typeface in an action bar on some older android version, or felt that the Fragment plus ViewPager routine was a little more complicated than they'd hoped, in short for those who are looking for some different way to organize the UI and display logic, Flutter is an interesting alternative.
Usually either everyone gets the same kind of device, or the same UI regardless of the underlying OS.
I had a "pleasure" of working with Xamarin Forms and interactions between native UI, behaviour difference between Android manufactures and versions, etc. were a constant source of pain.
With Flutter, if something works on one device it will almost certainly work on all devices. You can also customize per platform.
It is also possible to run it on desktop (although not officially supported). IMO that's a big deal and a potential Electron killer.
Dart is meh though.
Curious that you mention fast, because it is something Electron definitely fails on.
Web apps are for my already installed browser.
QML is as pretty as the design skills of the developer, just like CSS. And better because the full power of the graphics stack is available to the developer, down to pixel perfect graphics, unlike CSS where Houdini still isn't a thing.
Any native application is faster than a Electron based app. It is quite trivial to achieve.
https://www.codementor.io/blog/worst-languages-to-learn-3phy...
[0] https://developers.googleblog.com/2018/02/announcing-flutter...
[1] https://arstechnica.com/gadgets/2018/02/google-starts-a-push...
- There's a catalog of simple but official examples in the Flutter repo, under the examples directory: https://github.com/flutter/flutter
- One Flutter user has contributed a pretty impressive list of examples and learning resources here: https://github.com/Solido/awesome-flutter
- One of my personal favorite examples is this restaurant app prototype, which is inspired by an Uplabs design: https://github.com/braulio94/menu_flutter
Please, that's a disclosure, not a disclaimer.
Keep up the great work, I'm really excited by Flutter!
Nothing here at all for Flutter, just words.
I can imagine they haven't had the time to flesh out docs yet.
I develop iOS, Android, Web and Mac apps, and I was honestly blown away by the quality of the intelliJ and VSCode plugins available for Flutter. In fact, they've kinda ruined me for other language SDKs now.
Granted, the lack of material, demos and discussions makes it difficult to tackle some problems, but that seems to be changing these days. It's hard NOT to enjoy coding in Flutter, though, and I think that end up being its biggest strength.
I'm a fuddy-duddy still doing UI in GTK and Qt, I haven't kept up in trends in web and mobile design, but I know that when our developers do the layout and design it comes out awful and unusable, but luckily with GTK and Qt we can just hand it off to our designer after the basic functionality is in place and he can do some layout tweaking with Glade or Qt Designer, and is comfortable with working with CSS to provide us with custom widget styling and images, and then he sends it back to us and we clean up the results and merge it.
All of the Flutter examples seem to have the UI written entirely in code, both layout and styling, and I don't think he'd be comfortable with that. You may note that we send it to him, he tweaks it, and sends it back to us to merge; we've never been able to teach him Git, but that's OK, because we don't expect him to teach us Photoshop and design.
So, I'm just wondering if Flutter is intended to always be like this, with the whole UI specified in executable code that needs to be compiled and run for each iteration, or if it is intended to add a way to separate out the design parts (layout and styling) in a way that they can be worked on at least somewhat independently of the code?
I know that there is IDE support for hot reload, which may be OK for a designer to work with, but I'm always a little skeptical of that since most developers I know use VIM or Emacs and not IDEs, so sometimes IDE tooling setup can break, and once a project gets complicated, the toolchain setup for running from within an IDE can get hard to install. The nice thing about Glade or Qt Designer is that they can work with purely declarative formats so that you don't need to worry about having to have your designer get the full toolchain installed.
And IMO, designers should stick to their favorite tool, and leave implementation details to programmers. Hot reload makes it easy (and IDE is not required for that).
I'm curious about how this would work if the designers have to use developer tools to do the final spit-and-polish.
I don't know about how other places do it, but what I'm familiar with is that a UI mockup is sketched out and requirements given to the developer, the developer implements something but in the process finds issues with the design as specified and iterates a bit while doing so, and eventually you have something that is functional but somewhat ugly because the original sketch was not specific enough or didn't anticipate some issues that came up or the like, and then finally you give it back to the designer to do the spit-and-polish.
In some cases, the spit-and-polish can be a lot of work, because you've used some new widgets that you don't already have standard styles and graphics for, or maybe it's your first app with a new toolkit and so you need to figure out how to get your branding and style to work with it.
For designers I've worked with, CSS is their favorite tool for styling, and they prefer UI tools for spit-and-polish layout tweaks. Are you saying that they should just deal with having to learn how to do all of that embedded in code, or that they should just hand off their assets and suggestions to the developers and the developers have to do the final spit-and-polish work?
* Ideally this app would be designed for a desktop browser.
* I'd like to see examples of how to gracefully render this app on a mobile device.
* I'd like to see how to do the UI in a really data-driven way so that I supply something like JSON and the UI just renders.
The download can also be an issue, especially when downloading over cell... more so in a rural or other poor signal area.
Also, making UIs with HTML/CSS/JS really isn't that nice. The workflow with Flutter is way more streamlined.
My phone's calculator app is about 14 MB and the gallery is 10 MB in size. Flutter versions would have been probably a tad smaller than these native Android apps.
Well, just check the file sizes of the apps which you have installed on your phone.
Instead of an actual Crosswalk with trucks of data trying to kill you.
Though I personally have an unmetered 100Mbps connection, my target market(s) for what I develop, are people who are very data sensitive.
A 7MB Hello World file might mean that my app with the world, universe and everything I need, might be bigger. It'd be great if y = m(x) + 7MB with a gentle gradient, but I'm already starting off bad.
I tried creating a hello world with most of the dependencies that I think I would need, but most couldn't load, so I don't know what size a specimen app could be.
Either way, a 15MB download for someone in my radar would mean them not installing the app. One also shouldn't underestimate how many phones in developing countries barely have enough space left. Google Play seems to need minimum 500MB for me to install/update apps on my high-end phone, so it might be dire for lower-end devices.
What did that mean? Downside of flutter is you can’t use any non Flutter UI control easily.
"Flutter widgets are built using a modern reactive-style framework which takes inspiration from React Native. " - https://flutter.io/flutter-for-react-native/#built-in-widget...
I’ve been working on Lambda apps in Golang too. Here’s a boilerplate app that can help you get started and understand the pieces:
> "Dart feels like Java — making it easy for many developers to jump in"
* Object-oriented with inheritance (sharing the same keywords such as 'class' and 'extends'
* Non-optional semicolons
* Constructors, method overriding, calling `super.whatever` in your overriden methods
* Presence of null
* A base Object class for all objects in Dart, with hashCode() toString() methods
These are mostly superficial observations, and it's not a criticism of the language, but it certainly feels like Java to me, more than Scala or Go does.
For instance, what's the point of those Java style getter methods in the Movie class? These are public instance variables after all, and Dart has special property syntax to transparently wrap instance variables if and when the need arises.
I know next to nothing about Dart. So maybe there is a reason for this weirdness. But I rather suspect that the author has written a lot of Java and almost no Dart in his life.
One of my pet peeves with Java.
Enterprise architecture looks the same in any language that gets adopted in this space.