Earlier quoted context omitted.
Not only that but if you reimplement the widgets then your always playing catch up when they change. It's better to just use the platform's 'primitive views' then constantly reinventing a wheel that looks similar. Someone else also mentioned accessibility which to me is a deal breaker if your app doesn't match a native apps accessibility.
Is there any such toolkit? What exactly is "platform's 'primitive views'"? Usually the "native" implementations are actually bindings to the native APIs which require heroic courage(a lot of manual tweaking), not to mention that you still need to catch up/update your bindings when these APIs change.
Exploring Flutter for Cross-Platform Mobile Development
21–30 of 92 posts
Re: Exploring Flutter for Cross-Platform Mobile Development
#22This may be off-topic but I'm wondering if there is any chance to see cross platform and cross language toolkits any time soon. Something based on WebAssembly so that we don't have to worry or bash about programming languages. Dart is cool but should we all learn Dart now?
Platform independence
Choice of tools/language
Control of customer data
Hardware independence
Here is what corporate platform owners (Google, Apple, Microsoft, Amazon etc) want: Platform lockin
Minimal support costs (one language, one SDK)
Control of customer data
Control of the ecosystem
Hardware independence
A vig on every transaction
There are very few intersections between the interests of developers and the interests of platform owners (be that Apple with iOS or MacOS, Google with Android, or MS with Windows). This is why the web will win IMO, it's one of the few platforms focussed on what customers and developers want, and not owned by a single corporation (though Google has come close).Re: Exploring Flutter for Cross-Platform Mobile Development
#23Dart feels somewhere in between JavaScript on the one hand and a more-static OO, GC'd lang w/type inference (like Kotlin!) on the other. You can probably look closely at some sample app code and start doing some basic stuff quickly if you've worked much with JS and something more static. (Further study seems worth it if you plan to do a lot, heh!)
As others note the UI model seems Reacty--you write "builder" methods that recreate a widget tree when things change, and something behind the scenes sorts out an efficient way to update the screen with just what really changed. I'm not hugely worried about performance: your UI rebuilds should be separated from your animations, and anyway, building your virtual widget hierarchy ideally shouldn't be too CPU intensive in the first place.
Hot reload is pretty great. I can't actually compare with "real Android" dev, but changes to my little app showed up in under a second in an Android phone, emulated or real. There were a couple surprising things about the basic libs, e.g. Flutter master only recently added a convenience object to bundle together a radio/checkbox and its associated label-stuff (RadioListTile).
The Flutter Gallery app is available on Google Play and its source is in the Flutter git tree. You can see a lot of the Material widgets implemented, including rich list types (e.g. tiles w/photos), pull-from-the-side drawers, top-of-screen tabs you can swipe through, bottom-of-the-screen nav bars etc. Even on iOS Google seems to follow Material guidelines a lot (or at least, the Daring Fireball guy complained that they do; I don't have iOS to check), so maybe it's the easiest fit if you're prepared to do the same. Someone who works on Flutter mentioned elsewhere in these comments that they're working on components that look more like the iOS-native ones, though.
Although Android Studio is _based on_ IntelliJ, you need to get actual IntelliJ if you want to use the plugin (Studio's component versions don't match the ones that the Flutter plugin works with, I think). Also, if you have Studio 3.0 canary installed (like to futz w/Kotlin, heh!), you need to either configure Flutter to look for the stable Studio 2.3's copy of Gradle (flutter config --gradle-dir=...) or just make sure 2.3 is located where the flutter tools look by default (~/android-studio for me on Linux). People working on Flutter helped some of us through this at https://github.com/flutter/flutter/issues/10236#issuecomment...
You get a lot of IDE-ish luxuries (as OP notes): Control-Space to offer identifiers, methods, or params available; autoformatting with dartfmt (right-click menu); lots of quick feedback when you mess something up.
Hixie (Ian Hickson) of the HTML5 spec works on Flutter which is kinda neat (he did RadioListTile just now! and there's a milestone on GitHub named 'Make Hixie Proud' haha :D). Outside of the tech specifics, Dart's an interesting creature in that it seems like it's got some key customers in Google (AdWords, so, like, the part that makes money) but comparatively little pickup outside. On Flutter GitHub you see people paying attention to outside-adopter issues (or even passerby issues such as my Gradle-version thing recently). There's apparently lots of tooling available publicly, e.g. a package manager (pub), dartfmt, IDE plugins, a playground (dartpad.dartlang.org) etc. Curious to see if there's any more pickup on the outside.
Re: Exploring Flutter for Cross-Platform Mobile Development
#24Earlier quoted context omitted.
[disclaimer: I work on the Flutter project] One of the reasons we picked Dart was that is compiles to ARM (native) code. Dart has been pretty efficient for the project so far, but we haven't yet looked very deeply at battery life. Something to keep an eye on!
Do you use GC or RC on iOS?
Re: Exploring Flutter for Cross-Platform Mobile Development
#25Earlier quoted context omitted.
[disclaimer: I work on the Flutter project] We're adding more Cupertino (iOS-flavor) widgets. A few that we already have: spinner, toggle slider, button, alert. Check out the library ( https://docs.flutter.io/flutter/cupertino/cupertino-library.... ) and let us know which ones you'd like to see next! https://flutter.io/issues Thanks!
Will your custom widgets work with all iOS accessibility features? Accessibility is often forgotten when something gets reimplemented.
https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Ai...
Notice that there are several open issues relating specifically to iOS accessibility features.
Accessibility is not complete yet, but it is definitely not forgotten.
Re: Exploring Flutter for Cross-Platform Mobile Development
#26Earlier quoted context omitted.
> 180M DEPLOYED APPS This is quite a claim... Edit: It's customary to include a disclaimer you work for the product your spruiking FYI.
They must be counting every single test app as being "deployed".
Re: Exploring Flutter for Cross-Platform Mobile Development
#27Earlier quoted context omitted.
Not as much for a product that's been around since 2012 and has a history that dates back to 2007
I guess your definition of 'app' is a lot more liberal than most other people's. iOS, Android, Blackberry, Windows Mobile has a combined 7m apps on their respective stores. Do you work for Codename One? Your HN history seems to suggest you're quite 'involved' with it.
Re: Exploring Flutter for Cross-Platform Mobile Development
#28Codename One ( https://www.codenameone.com/ ) runs circles around fluttr.
> https://www.codenameone.com/gallery.html The Codename One app gallery says otherwise.
Re: Exploring Flutter for Cross-Platform Mobile Development
#29In Flutter, everything is a nested pile of objects with too many APIs to keep track of. Take this example: https://github.com/flutter/flutter/blob/master/examples/stoc...
Why do I need to care if something takes a `child: (single object)` argument or a `children: [LIST of objects]`?
Flutter would be better with JSX: JSX hides how the puzzle pieces fit together. I don't care if it takes a child or children; just make everything connect the same way.
React Native's Flexbox also beats how Flutter did things. Why do I need to memorize which objects take which styling arguments? You want to center items on the screen? Re-nest everything inside a Center object! You want a column or a row of elements? Use a Column/Row object!
For a framework that's trying to bill itself as a great tool for prototyping, it feels like I'm sifting through a mountain of minutiae. I was able to guess my way through a React Native app and be right 99% of the time. With flutter, my luckiest guess would lead me to an abstract base class... Then I'd have to dig around to figure out what the hell I need to use to make a view scrollable. Seriously:
https://github.com/flutter/flutter/blob/c6b0f833af9e431df1e6...
Why?