Devblog 9: Can we still be friends?

Photo by Joseph Chan on Unsplash

Devblog 9: Can we still be friends?

If you follow me on Twitter, you might already know, but I'm giving up on FlutterFlow once again. While I think FlutterFlow is an amazing tool, I also think it has a long way to go. For the last couple of weeks, I kept running into hurdles that slowed down my progression. In this article, I will give you some of the details.

Because I'm still struggling to find time to work on this project I decided to tune down the scope a little and made some other project decisions to make the project (hopefully) more manageable.

Why I've dropped FlutterFlow, again.

Let me start by saying FlutterFlow is an amazing tool. The way you can create UI, with a nice graphical user interface, is something I didn't know I missed this much.

Creating UI is smooth and fast. Just dragging widgets into place and adjusting some properties made it a very nice experience.

But then the UI also had to do something, for which we trigger actions. FlutterFlow contains a bunch of these actions to work with Firestore, navigation, local state and whatnot. If the action you are looking for doesn't exist, you can create your own.

Custom actions

This was the first hurdle for me. FlutterFlow is very Firestore-minded, meaning you often directly connect a screen with a Firestore query. But I wanted to work in the local state first without having to send write-requests on every change I made.

So, while there are plenty of actions to use to manipulate Firestore documents, working with the local state was lacking them. I ended up writing custom actions for them but that wasn't scalable. I had to write very specific actions for every DataType and every form of manipulation I wished to perform.

Not to mention the code editor has some weird quirks that sometimes just disable the analyzer. Also, I had to mark my actions as "not compile" because it broke the project.

Separated environments

As a Flutter developer, I'm used to having different environments for testing and production (or more). We don't want to experiment in a production environment, now do we?

Unfortunately, FlutterFlow has no support for this, which made me a little frightened for the future, after the initial release. How would I handle working on new versions without risking screwing up the production environment?

Testing the app

One of the biggest issues was not being able to test on real devices right from the editor.

I'm used to hookup any device to my MacBook and deploying my Flutter apps in seconds, allowing me to experience my app as close to production as possible.

With FlutterFlow you can run your app in the browser, but it has no access to sensors, which is kind of important for my Scavenger Hunts.

So is it over?

As I said, FlutterFlow is an amazing product but has a long way to go to match the capabilities of the vanilla Flutter experience.

I'm considering still using FlutterFlow for designing UI components since I'm not familiar with any other design tools. Other than that, I won't be using it, and I will not give it another shot for this project. All this switching also cost me valuable time. But it was a nice learning experience.

The future of the project

Working with FlutterFlow did give me some new insights into how I wish to approach this project. For example, in the way I want to store and handle data in the database.

Scope

My initial idea was to create an app that allowed the user to play different kinds of geographical games, Scavenger Hunts being one of them.

I decided to limit the app to just doing Scavenger Hunts. Hopefully, this will prevent me from trying to early-optimize.

Tech Stack

I might have partially mentioned this topic scattered over the previous devblogs, but this is the tech stack I will be using.

So I'm back to using vanilla Flutter for this project for the earlier-mentioned reasons.I will use Firebase as the backend, for things like Auth, Storage, Firestore, etc.

So actually, I'm back to what I initially started with...

Etos

I'm still going to use Etos, my self-created State Management package. I will develop Etos alongside this project to make it production ready.

Theming

Last week I triggered a discussion about theming in Flutter. I tweeted that I find theming in Flutter confusing. It seemed that I was not the only one.

While thinking about this topic, I came up with an idea, that I want to give a try in this project as well. If I like it, I will write an article about it.

What's next?

Last week I created a new project. Thus far, I've added flavors, added Firebase Auth, and added basic App State with Etos.

Next, I will work on the main page with the bottom navigation.

Until next time!