In this article, we will tell you about our life after several months working with this technology created by Google in 2017.
Our first contact was strange. To begin with, we found that it uses the BLoC Pattern, which is recommended by Google's developers, and on the other hand, for the visual part it uses... objects? It broke our heads a bit — we were used to other things. But this wasn’t a negative; it was a new challenge.
After a week or two working with Flutter, it was surprising because we realized that we were working comfortably. For example, creating a view was easier than we expected. Those objects we mentioned are called Widgets, which have properties quite similar to CSS. We could create our own Widgets (we felt like working with React components!). If we wanted to send data to the view, we created a Stream<T> object (where T is the object type) in the bloc and received it in the view with the StreamBuilder, and vice versa, we sent data or actions from the view to the bloc using events... Anyway, we recommend you try it yourself — we’re only giving you a glimpse here, but now let’s move on to something important.
Testing
If we look at the Flutter documentation, we can see there are three categories:
- Unit tests
- Widget tests
- Integration tests
We could explain how to do each of them, but we’ll leave that for a future post. For now, let’s talk about our issues.
Actually, these tests are not very different from those in other technologies, but we did face some problems: some easy to solve, others… not so much. Most of them were in the Widget test category.
One problem was that a certain element wasn’t found in the GUI. Everything seemed correct, but… why wasn’t it finding that Widget? Before explaining what happened, let’s clarify: to run the tests we use the console command flutter test — pretty simple — but although we test components, we don’t see in real time how those actions are executed. That makes visual debugging harder. The solution was that we needed to scroll! But once you know about this, you’ll be ready for it next time.
Now, this next problem really gave us a headache. If your app is going to support multiple languages, keep this in mind. As of today, Flutter is a very young technology, so unexpected bugs, beta-stage packages or plugins, or missing features you’ll need to implement natively can happen. Our problem was that when the JSON file for languages reached a certain number of characters, it stopped working in Widget tests — no element was found! The “solution”? Use the key instead of the value. We’re not happy with that fix, but for now, it works.
You might encounter other issues like the ones we’ve mentioned, but we’re sure you’ll find a solution. Now we’d like to add one last topic to this post.
Application, package, and plugin
Most people will probably make applications, but we tried all of them. When creating a project, you can choose one of three types: a regular application, a package to consume features, or a plugin — which is almost the same as a package except that a package has no native code. In fact, if you create a package, you won’t have Android or iOS folders, and as expected, a plugin does include native code.
Conclusion
Our learning curve has been exponential. At first, it can be a bit shocking, but you get used to it quickly. We’ve had the opportunity to create applications, packages, and plugins. We faced a few issues when implementing features and a few more when writing tests, but that’s clearly due to the young community. We’re sure many more people will join the Flutter community.
Don’t you feel like trying it?
This article was first published in Spanish on the Lean Mind blog: Flutter, ¡una maravilla! ¿o... no?. It was written together with Noemi Delgado. This version has been translated using AI, so please keep in mind that coherence may be lost or there may be some unusual phrasing. Thank you very much for your understanding.