Flutter first impressions

#flutter

Flutter first impressions

After hearing so much hype around the Flutter platform, I decided to give it a try and write about my first impressions on the developer experience. I’m an Android developer and the idea of writing the same code for Android and iOS is quite exciting.

Since I didn’t have any excuse to use Fluter on my company or a personal project, I searched for a few public APIs and decided to write the most simple app around it. I found Tronald Dump, an API & web archive for the dumbest things Donald Trump has ever said. (I think the archive is not being updated anymore but that was still ok)

Here’s the simple app I wrote:

(iOS version; Android version here https://youtu.be/aS14Eobn738)

What I liked:

Documentation: The official docs are helpful and cover most scenarios you’ll need to get started: widgets, networking, persistence, testing, etc.
Community: There’s already tons of tutorials on Dart and Flutter for things the official docs don’t cover. For instance, I used the MVP architecture and dependency injection described by Chema Rubio in his blog post.
Hot reload: As good as everyone says it is. It’s true that every now and then you need to rebuild the app, but for tweaking the UI its a great experience. I felt that it makes you learn faster, because you can quickly see what works and what does not.
Dart: Coming from the Java world, it’s not difficult to get used to it. The async/await reminded me of Kotlin’s coroutines and that was nice. It provides constructs for functional programming and a Streams API. Or if you come from RxJava world and can’t live without it, there’s also RxDart.
Testing: There is out of the box support for automated testing in Flutter. I tried each type separately (unit, widget, integration) and — comparing to Android — the experience felt very natural and I didn’t find any issue, just following the official docs. Even though my test tests were simple, I felt confident it could easily scale.

What I disliked:

Semicolon (;): Java requires a semicolon. Kotlin does not require a semicolon. Dart requires a semicolon. Javascript does not. Grrrrrrrrrrr… (would be cool to use Kotlin with Flutter, although that’s not happening anytime soon)
Start-up time: It’s not huge, but there is a noticeably larger start-up time than your standard hello-world on Android. I wonder how much of an impact this will be, when you have to initialise a bunch of dependencies typically required on a comercial app (crash reporting tool, network services, advertising services, analytics tools etc.)
Architecture: Or lack-of architecture. Flutter can be quite flexible in the way you want to write your apps. That is great. However Flutter seems to be in a position where Android was not so long ago, in the way that there wasn’t an official recommendation on how to build an app. And that led to too many apps becoming a big ball of mud — no separation of concerns, little testing, and difficult to maintain.

I understand that may not be a priority for the Flutter team but I’m afraid those issues can easily happen. On Android, a considerable part of the UI is written in the XML files, which forces programmers to separate (at least a little bit of) their UI and business logic. With Flutter, since everything is coded in Dart, I think we need to be a bit more careful to not violate these separation of concerns.

Another example: I found it very helpful to have a separate class file for strings, another for colours, another for routing, etc. But that was my choice. I could have been lazy and not done that. That could easily become a pain to maintain and refactor.

Also regarding architecture, there’s already several non-official patterns out there: Stateful/Stateless Widgets, InheritedWidgets, Streams/Sinks, Redux, etc. I don’t want so many choices… Which one should I pick? =)

Wrap-up

I wrote a very simple app and there were many topics I didn’t cover, but are still important on production-ready apps: local database, tools for crash reporting, analytics, advertising, etc.

Overall I was happy with the learning experience. You can find the source code here https://github.com/RicardoBelchior/TronaldDump/

Hope you enjoyed, please leave some comments or hit me up on Twitter https://twitter.com/belchii

Top comments (7)

rhymes • Oct 21 '18

Thanks for your review Ricardo, funny how you liked its documentation and I counted it as one of its weaknesses. Probably because I saw it from the poin of a total newbie in mobile development.

I bookmarked the MVP articles, thank you.

I guess Flutter needs a little more conventions before breaking into the big leagues :D

How hard it was for you to separate the iOS code from the Android?

Ricardo Belchior • Oct 21 '18

Thank you very much for the review.

All the code I wrote was delivered to both platforms. I did not write any custom/specific code.
The great thing is that using the "material" package already does all the work for you.

Anyway, there is a folder for Android/iOS , that contains their respective platform code. These folders are generated in the format you expect when developing android or ios.

Vince Ramces Oliveros • Oct 21 '18

Also regarding architecture, there’s already several non-official patterns out there: Stateful/Stateless Widgets, InheritedWidgets, Streams/Sinks, Redux, etc.

Strateful and Stateless Widgets are prerequisites in making widgets. Choosing Stateless would mean that this widget will not rebuild. Stateful may rebuild the Widget anytime like checkbox, radiobutton, and etc.

I think having many patterns have its own complexity when dealing the behaviour of the app. If you haven't watched Reactivate applications in Flutter from GOOGLE I/O 18. You'll see those patterns fit for the application.