Open nelsonic opened 4 years ago
13 Reasons Why you should choose/ consider to move to Flutter by @ganeshsp1 (Jan 6, 2019 Β· 8 min read): https://medium.com/flutter-community/13-reasons-why-you-should-choose-consider-to-move-to-flutter-in-2019-24323ee259c1 Number 12 (Desktop & Web) is already available. (the article was published in early 2019...) I think it's worth him updating the article for 2020 given how much the ecosystem/community has grown!
I've also been testing Flutter the last couple of weeks.
The good:
The less good:
From a Flutter beginner point of view, once set up it is nice to see your app running on your phone. However when attempting to do some logic a bit less conventional (i.e. not using Firebase, https://github.com/dwyl/technology-stack/issues/16#issuecomment-569028546) it becomes really difficult to find an easy solution. So at this stage I haven't find it easy to be able to iterate quickly on features and to deploy a web app with Flutter.
@SimonLab thanks for sharing your thoughts on Flutter. β€οΈ
Indeed setting up on Mac was a bit tedious β³
because it requires XCode
in order to compile an iOS App. π±
But given that XCode
is always required for any Native iOS App,
this is discounted as "That's Life" ... π
And at least flutter doctor
simplified the process with a simple checklist. β
As for Sign in with Google ... we spent way too much time on that "SPIKE"βοΈ and ultimately we are going to use Server-side Auth (Elixir) and redirect back to the Native App as described in https://github.com/dwyl/learn-flutter/issues/22#issuecomment-579659198 This will work for all Native Apps (iOS, Android and Desktop) we simply need to pass a JWT back to the Native Client and then use the JWT for all subsequent API requests.
I don't see much advantage to using emulators when we have physical devices that run the actual App and allow for hot-reloading. π I think the Emulators are for the instances where people want to test on devices that they don't have access to ... e.g: "legacy" Android devices. π€·ββ It's good to have a simulator as a backup, but real devices are always better for testing. π
Flutter being coupled to Firebase is fairly logical from Google's perspective. They want to promote the use of Firebase both internally and externally in the wider dev community because they want to standardise the way mobile apps are built ... Obviously Firebase is not an open "standard" ... so the coupling is annoying. π€¦ββ We will be using both a REST API and WebSockets in our eventual Native Clients. Which is why we have decided to re-focus our efforts on the dwyl/app-mvp-phoenix π―
Building the Phoenix/Elixir App will mean that we get the REST/Realtime API (almost "free"). Which will in turn mean that people using the @dwyl App will be able to access their data using the API directly from very early on. And by doing API-driven development whereby API users are "first class citizens" we can allow people to build their own interfaces/dashboards to visualise and interact with their data. i.e. we build a platform for personal effectiveness that anyone can build on top of!
@miguelmartins17 should 100% continue
with the Flutter Todo List Tutorial https://github.com/dwyl/flutter-todo-list-tutorial/issues/2 and I will review all additions to the README.md
and code
.
Once the Flutter Todo List Tutorial is complete we will be able to extend it with the ability to:
(a) save data to the "backend" using the REST API https://github.com/dwyl/learn-flutter/issues/6 and
(b) modify the UI to match the @dwyl app (it's just Material UI so it won't be difficult)
(c) add task timer/tracking functionality! https://github.com/dwyl/app/issues/265
I am still very optimistic we'll be able to use Fluter
for both the @home and @dwyl Native Apps. π€
But for now we (@SimonLab, @iteles and I) need to focus on the Phoenix App.
Flutter Web is making good progress: π https://medium.com/flutter/flutter-web-support-updates-8b14bfe6a908
Flutter 1.17 is looking good: (a significant performance boost for iOS!) π± π https://medium.com/flutter/announcing-flutter-1-17-4182d8af7f8e
I'm still focussed on building the "backend" in Phoenix. π§βπ» But it's really great to know Flutter is making good progress. β€οΈ
Performance: https://medium.com/swlh/flutter-vs-native-vs-react-native-examining-performance-31338f081980
While this is a "synthetic" benchmark (as opposed to running a "real world" app written in the various programming languages/frameworks) it does have a pretty clear-cut conclusion:
React Native always uses more memory and CPU to perform the same tasks:
In some cases it uses 15x more resources and is 10x slower at returning the result of the calculation than the equivalent Swift or Flutter version. Which means it will drain the battery and overheat the device much faster.
There is limited real-world relevance for a "High CPU" app.
What would interest me is the memory consumption, refresh rate and battery consumption due to background processes. The fact is that most RN development still happens in JS as opposed to "native" C/C++ modules so the resulting App is bigger and slower than the equivalent Flutter binary.
Free (Official) Udacity course "Build Native Mobile Apps with Flutter":
https://github.com/flutter/udacity-course
https://www.udacity.com/course/build-native-mobile-apps-with-flutter--ud905
2022 and SEO is still not resolved for Flutter Web Apps: https://github.com/flutter/flutter/issues/46789#issuecomment-1007835929
That means for a certain class of Apps, e.g: those with public
user-generated content using Flutter for Web is a no-go.
E.g. imagine building a Recipe + Meal-planning Web App
where you want people to be able to add
their own recipes
or make a variant
of an existing recipe.
or allow people to review
recipes
leave comments or upload photos ... etc.
If all the content was locked up in a Canvas rendered UI with ZERO SEO it would fall flat on its' face.
If you're building something that needs to found (on the open internet) in order to get traction, Flutter is not the answer.
#finally
ready for review: #80
Our plan for the next 6-12 months is to create two apps:
These two Apps have a decent amount of overlap: Auth, UI/Layout, Notifications,
Given that we would like to make the @home App a Native Mobile App so that it functions as fast as possible, we spent a bit of time over the last few weeks investigating our options for writing a cross-platform native mobile app.
Our short-list included Ionic https://ionicframework.com and NativeScript https://www.nativescript.org but we quickly dismissed those because we want the benefits of native performance not a "wrapped" JS (WebView) app with native components and APIs.
Why Flutter?
@dwyl we have guiding principals for technology selection for the Apps we build: https://github.com/dwyl/technology-stack/issues/33
With that in mind we have tasked padawan @miguelmartins17 - who has experience of building Native Android Apps - with being our sherpa in exploring this exciting tech! He is on a mission to become a Flutter Expert in the next 6 months and make the journey as easy as possible for everyone that follows!
Google ...
Google is investing heavily in Flutter and they are using Flutter for several of their cross-platform Native Mobile Apps including Google Assistant, Google Adds (their main money maker) and Stadia their recently launched gaming platform. https://flutter.dev/showcase
This is not a reason to use a particular technology, but the fact that they are backing it and using it for their apps means it's a decent bet.
Proposal
I propose that we investigate using Flutter for cross-platform mobile apps. My first objective is to test Flutter Web and see how easy it is to build a PWA: https://github.com/dwyl/learn-flutter/issues/9 Then I will attempt re-use the same code for an Android Native App.