Clearing the Clutter: Adopting Flutter

I was talking with a former coworker recently, and in the midst of the “how have you been? What have you done during the pandemic? How is work?” conversation he mentioned that he’d been focused on upgrading React Native for his company’s app…for the past 2 months. Two. months. I was overwhelmed, he was overwhelmed, and he was definitely over it.

This is in no way a unique story. Plenty of teams and engineers experience their own struggles (large and small) with React Native. Here at SmartLogic we have experienced our own variety of problems. Not only with upgrading React Native, but also with dependency/library changes causing the whole app to break on numerous occasions; and it takes a developer who is extremely well versed in RN and iOS or Android compilation to actually go about solving these problems. It’s time-consuming and a pain. After being burned one too many times, we took the chance to try something new when given the opportunity.

Why Flutter

“Why Flutter?” is probably what you’re wondering. From high-level research we knew that development in Flutter would be fast. Being built upon Dart and utilizing its JIT (just-in-time) compiler, the hot-reload feature of building an app in Flutter would allow us to quickly learn, debug, fail, and then learn some more. We also knew that in Dart we would be getting a language that was optimized for multi-platform development. Quickly toggling between an Android emulator and an iOS simulator? Sign me up. But in all honesty, we knew very little, and we were taking a leap of faith. Despite being granted some delightful in-between client projects time which we could dedicate to learning Flutter and Dart, it was still a risk.

Getting Set Up

As an aside, I’ve never been an app developer. I didn’t take an optional app development course in college, my first 3 jobs didn’t have apps as products, and I was doing almost entirely backend development in the two jobs previous to working at SmartLogic. You could say I’m an app newbie. I want to highlight that because I found getting set up with working in Flutter to be a breeze. Serious props to the Google team who developed Flutter and made it so simple to set up and get going. Bonus points to whoever made the decision to put Hamilton themed placeholder content through the boilerplate code.

Building our First Flutter App

I won’t pretend that given the easy app setup that the development of the app was easy. Given that Flutter is based around the idea of “everything is a widget,” it took some serious brain shifting to start feeling productive. From the Flutter docs, “Widgets describe what their view should look like given their current configuration and state.” Your entry point to the app? That’s a widget! The dashboard with a scrollable list? A widget of widgets within a widget! The app widget hierarchy is extremely important when developing a Flutter app; child widgets need to know about their parents and their parents need to know about them. Many of the problems we encountered getting started were related to widgets in the widget tree not knowing about their parents, or widgets that somehow ended up orphaned. But Flutter makes learning about your app’s widget tree extremely easy, another big plus. With the ability to inspect Widgets within Visual Studio Code (a preferred Flutter IDE), not only can you see a visual representation of the widget tree, but you can also make edits to certain widget properties and see in real time how they will change in your app.

In 3 months, we were able to build an application using a language none of us had ever used before. We, being a small team (2-3 developers), and the application is now being used to help restaurants serve thousands of meals to community members who are food insecure. Our lack of Flutter knowledge and experience may have slowed us down, but Flutter’s incredible documentation gave us the ability to work fast given our inexperience. I can’t stress enough how crucial the flutter documentation and pub.dev was to our success. We were so happy with the experience in fact, that we dove into developing another Flutter app for a different client, and are recommending all new mobile apps we develop be built using Flutter.

Onward with Flutter

Right off the bat, our next foray into Flutter was more complicated. While there was considerably less state management (something that was a challenge in our first Flutter app), there were two major Google integrations (maps and ads) that proved to be a hurdle.

You would think that three Google-owned products would all work in happiness and harmony right? Not so (at least at first). Implementing Native Ads proved to be such a challenge that we had to abandon the work, although we were able to successfully implement Banner Ads. Our biggest challenge was integrating Google Maps. Competing composition approaches between the libraries caused the app to stop rendering changes to the map. Updated dependencies allows us to enable the newer Hybrid Composition and remove the rendering conflict between Maps and Ads. Finding this problem taught us a few lessons about our development processes though.

In many ways it brought us back down to earth. Our first Flutter application had been so easy that we approached the second go-around with a lot of confidence. The difficulties we experienced during our second Flutter project led us to reapproach the way we had designed our app structure, as well as create new processes around testing. It’s provided us a better understanding of the way Flutter works, a better sense of how we need to go about testing, and a better footprint as we approach building more mobile applications. Which is great, because we’re just getting started on our third Flutter application. You know what they say? Third time’s the charm.

Header photo by No Revisions on Unsplash